DevOps 已经成为了近年来运维的主要趋势之一,越来越多的企业在拥抱和实践 DevOps 文化,也越来越多的企业在公有云中使用 DevOps,但是绝大部分企业都认 为自己没有发挥和使用 DevOps 的核心能力。本章节将分享我们对这个问题的看法, 并提出我们的解法:CloudOps。
DevOps 本质是为了协同公司内多个不同团队快速朝着同一个业务目标前进,而衍生出来的一系列流程和自动化工具,强调的就是组织和业务的敏捷性。
DevOps 理念囊括团队文化、组织协同和研发运维多个方面,希望消除研发、运维 之间的利益差异和差距,促进团队协作,专注于端到端的能力交付和系统建设,让 软件交付的全生命周期中的开发、部署、维护和扩展等各个步骤更加有效率,降低 故障次数和故障时长,充分体现了以产品和效率为中心来进行软件开发和交付。
通过 DevOps 理念的实践,企业提高了研发效率,缩短了业务从研发到上线的周期, 从而提升应用交付质量和交付效率。
DevOps 模型定义了几个成功的关键分组,这些对于应用成功和提升效率非常有帮 助。
敏捷开发的过程管理:实现高效协同,定义人与人之间的协同,业务和技术之 间的协同,组织和团队的治理以及需求管理等多个要素和因子。
持续交付:通过定义更好的 CI/CD 工具来完成灵活变更和持续交付部署,更好 地构建环境以及提升可视化能力。
技术运营提升:可以快速构建所需要的基础设施和资源保证,对于监控预警、 问题发现、容量管理、变更管理和成本管理等,提供体系化的支撑。
随着 DevOps 越来越成熟,众多的企业通过 DORA 指标来衡量交付的效率,以及交 付和变更的质量,主要包括部署频率(Deployment Frequency)、变更提前期(Lead Time for Changes)、平均恢复时间(Mean Time to Recovery)和变更失败率(Change Failure Rate)这四个维度,这几个指标体现了企业对应用交付的敏捷程
度以及对于故障处理的时效性和效率。
在 DevOps 文化被广泛采用的同时,也有越来越多的企业借助云计算来实现数字化转型。云平台提供了巨大的计算力资源,规模化的弹性优势、丰富的标准化云产品、 自动化工具,自助服务的模式不仅能帮助企业 IT 设施云化,按需取用随取随用的业 务场景和自助服务的模式大大增强了企业基础设施需求和变更的敏捷性,借助于云 平台和开源的监控以及运维自动化能力可以大幅提升应用的可观测性,提升故障的 发现率,降低故障的恢复时间。
然而,研究表明,越来越多的企业在公有云中使用 DevOps,但是绝大部分企业都 认为自己没有发挥和使用 DevOps 的核心能力。
这是因为,将传统的 DevOps 直接搬到云上,并不能充分利用云的优势,因为相比 于传统的 DevOps 的运维模式,云上自动化运维的模式和思维仍然有着不小差异。 这也是部分企业上云之后,建立一套云原生自动化运维体系的挑战。
操作对象的差别
传统运维:直接操作的是物理的计算、网络、存储的硬件。
云端运维:大多通过软件暴露接口或 OpenAPI 来进行操作经过抽象的资源。
资产和资源的区别
传统运维面向的服务器是企业资产,需要提升单机的利用率,并提前很久规 划资源。
云端运维则是在弹性租赁资源,除了提升单机利用率,还可按需扩缩容,利 用 OpenAPI 和应用分组来管控资源。
统一化规模化差异
传统运维一般操作的规模相对较小,管理的机房相对明确和有限。
云端运维可快速通过资源的弹性能力轻松的管理数百台、跨机房的服务器。
强调安全可审计
云端操作来源和对象相对复杂,对操作审计和操作来源及报警的时效性要 求比较高。
云端可将服务通过命令直接暴露在公网中,需要更多安全和网络规划能力 来降低系统风险。
高频的可编程自动化运维需要有比较好的审计和问题追踪能力,避免越权 和不容易被追踪的问题。
可见,DevOps 需要根据云的特性进行一系列改造,才能与云进行更好地融合。
我们看到越来越多的企业在云上实践 DevOps,为了更好地发挥 DevOps 和云的双 重敏捷特质,我们在 2021 年提出了 CloudOps(云上自动化运维)的思路来帮助企 业在云上更好的落地 DevOps,充分的利用云平台和 DevOps 的技术优势。我们认 为 CloudOps 可以更好地贯彻 DevOps 的理念和精神。
CloudOps 是运维领域的 DevOps 理念与云原生理念的融合,通过在云平台上借助 于云原生架构实现运维的再进化,充分帮助企业降低 IT 运维成本、提升交付速度和 系统灵活敏捷度、增强系统可靠性,构建更加安全可信开放的业务平台。
基于阿里云服务数千家企业客户的十多年的经验,我们总结了一些常见的最佳实践, 撰写了这本《云上自动化运维白皮书》(简称《CloudOps 白皮书》),并在其中提 出了 CloudOps 成熟度模型,我们会从五个方面建设和评估 CloudOps 能力,期许 提供云上自动化运维的最佳实践和参考,帮助客户更加充分地利用云带来的优势, 进一步提高业务交付质量。
这套模型可以简称为 CARES 模型,即成本管理(Cost)、自动化能力(Automation)、 可靠性(Reliabilty)、弹性(Elasticity)和安全与合规(Security)五个方面。CloudOps 成熟度模型是对云上企业 Ops 能力的的评估,也是对云厂商产品能力和自服务能力 的评估,评估云厂商是否有提供足够全面的工具和能力,让客户便捷地实现这些功能。
DevOps 给应用软件开发带来了极大的便利性。由于云服务有着“软件定义一切” 和“弹性敏捷”等特点,跟 DevOps 的理念非常一致,这两者带来的优点是非常类 似的。
采用 DevOps 理念,有以下四个方面优点和目的:
降低整体成本支出:打通不同团队来降低人员冗余,通过持续的自动化投入, 例如 Infrastructure as Code(IaC)、Ops as Code 等,来降低人工成本。
提升整体的交付速度:通过敏捷形态和自动化达到。
提升灵活性:更快的交付速度意味着可以快速迭代、提升效率。
增强系统的可靠性:通过标准化、工具化、自动化实施避免人为错误,以及问题
排查的 MTTR(平均修复时间,Mean time to repair)。
使用云服务管理的也有类似的优点:
降低整体成本支出:减少对硬件的采购和运维的相关人力;企业按需消费,合 理选型与计费,避免闲置。
提升整体的交付速度:云提供大量开箱即用的资源,分钟级创建与释放,加快 部署速度。
提升灵活性:更快速、更细颗粒度交付资源,能够快速的适应市场需求与各种 运营活动需求。
增强系统的可靠性:云服务天然提供了高可用的系统设计,例如多可用区、备 份恢复、热迁移等手段,降低物理资源故障带来的损失;通过云服务厂商提供 的工具和服务化能力,可以大幅降低部分问题和故障的排查难度,创建更具弹 性、安全性和标准化的系统。
近几年来,我们欣喜地看到越来越多的企业和个人开发者将自己的测试环境和生产 环境迁移上云。我们能看到云和 DevOps 之间有着许多相似的优点,通过将 Cloud 和 DevOps 结合,将能发挥更大的价值,包括降成本、提升交付速度、更灵活、提 升系统可靠性等。
结合了云计算的 DevOps,不仅仅可以提升效率和优化 TCO,同时它还使我们的系 统能够在不断变化的复杂环境中更可靠地工作。
相信基于以上论述,读者们能够更加了解我们为什么认为云端的 DevOps,需要有 一套更为成熟和体系化的理念,才能帮助企业在云时代更好地发挥云和 DevOps 的 优势。我们提出的新思路——CloudOps(云上自动化运维),就是在此背景下诞生。
阿里云弹性计算团队内部,联合十多位专家,共同编撰了一套 CloudOps 成熟度模 型。如前所述,这套模型的几个维度我们可以称为 CARES,即成本管理(Cost)、 自动化能力(Automation)、可靠性(Reliabilty)、弹性(Elasticity)和安全与合 规(Security)五个方面,来评估企业的 CloudOps 成熟度。每个维度如何理解,我 们将在下面章节展开。
《CloudOps云上自动化运维 白皮书2.0》系列文章二:CloudOps的主要衡量纬度和定义
《CloudOps云上自动化运维 白皮书2.0》系列文章三:CloudOps成熟度模型整体及等级说明
《CloudOps云上自动化运维 白皮书2.0》系列文章四:自动化能力Automation
《CloudOps云上自动化运维 白皮书2.0》系列文章五:弹性能力Elasticity
《CloudOps云上自动化运维 白皮书2.0》系列文章六:可靠性能力Reliabilty
《CloudOps云上自动化运维 白皮书2.0》系列文章七:安全和合规能力Security
《CloudOps云上自动化运维 白皮书2.0》系列文章八:成本和资源量化管理能力Cost
《CloudOps云上自动化运维 白皮书2.0》系列文章九:CloudOps成熟度模型全景图
《CloudOps云上自动化运维 白皮书2.0》系列文章十:CloudOps成熟度自评
各位产业专家、引领浪潮的创业者们,阿里云正在进行“客户云支出趋势”的调研,完成10题问卷(仅需2~3分钟,每家企业限填一次),即有机会获得小礼品!
问卷请见链接:https: //survey.aliyun.com/apps/zhiliao/wvN2aaIiA
也可扫码:
2023年9月21日,阿里云正式推出阿里云创业者计划,联合知名投资机构、加速器、创服机构以及大企业创新力量,旨在为初创企业提供全方位的赋能与服务,助力创业公司在阿里云上快速构建自己的业务,开启智能时代创业新范式。