序言
云计算行业已经有十多年的发展了，话题早已从“要不要上云”转向“如何用好云”。“要不要”其实是一个决策性的话题，直到决策出来一个结果了，话题就算结束了。而“如何用好云”却是一个持续性的话题。
一般来说，在规划阶段开始，企业就会开始思考“如何用好云”，这个话题会伴随用云的整个过程。如果简单地从工作类型划分，除了业务代码的研发（Dev），其他的部分都可以称为运维（Ops），包含资源创建（环境部署）、应用部署、资源管理、资源监控、报警、故障排查等工作。
笔者从事云计算工作超过五年时间，参与开发过多款云产品，可以说既是云计算产品的消费者，也是云计算产品的生产者。在这里，笔者谈一谈对云上DevOps能力体系的多年思考和总结，希望对准备上云或是已经上云的运维人员有所帮助。
1 自动化运维等级金字塔
从运维自动化等级和程度来看，DevOps其实是一种非常高级的自动化，不仅自动化程度比较高，而且对于自动化的完成方式有着非常严格的定义。关于运维自动化与DevOps的关系，其实可以非常好地参考汽车自动驾驶技术分级标准，笔者做了个对比图，如图1。
如图1，自动化运维可分为5个等级，分别是手动运维、半手工/半自动化运维、高度自动化、标准化运维和AIOps，分别对应自动化驾驶的6个Level，其中运维自动化L2对应了自动驾驶的Level 1和2。为了方便说明和对比这5个自动化运维等级，请参考如下的表格。
Level 1：手动运维。一些技术能力一般的企业，在上云初期运维工作主要是纯手动，只能依赖云服务商提供的控制台进行操作。
Level 2：半手工/半自动化运维，运维自动化工作比例还不超过30%。运维人员可以通过命令行（CLI）完成部分运维工作。
Level 3：高度自动化，运维自动化程度可达到50%。企业运维人员会使用云平台的SDK调用API进行日常运维工作，同时自行开发运维系统，但运维系统通常无定制化和平台能力，和内部系统紧耦合。
Level 4：标准化自动化，运维自动化程度超过90%。企业的运维系统已具备平台化、模版化和代码化的能力，可根据自身的运维需求定制化开发系统。与此同时，运维人员已具备使用具备模板化的产品来实现运维工作的标准化和自动化。
Level 5：AIOps，即智能运维，运维自动化程度达100%。不再需要值班人员，生产力完全解放。这是当前很多大型互联网企业的运维目标，也是头部企业重点投入的方向。
2 DevOps 是自动化运维的进阶模式
2.1 模板化是最DevOps的自动化方式
这里，笔者想着重谈一下Level 3-高度自动化运维与Level 4-标准化自动化运维的区别。大多数自研的运维系统是在Level3 类型，例如在内部运维系统上开发了一个功能，可以立即创建10台云服务器，下次需要创建其他资源时，如创建3个消息队列，还是需要额外再开发创建消息队列功能。所以，Level 3-高度自动化运维可以理解为是一个聚焦具体场景的单一“系统”。
而Level 4-标准化自动化运维更具备普遍性，完成了更高一级的抽象。当前，大多数的云平台都提供了自动化部署相关产品，如AWS CloudFormation、阿里云的资源编排工具ROS等，所以Level 4标准化自动化运维系统其实是一个平台型的产品。
使用Level 4阶段的产品创建资源只需要创建一个模板，当需要创建新资源时，只需要套用模板即可，无需额外开发。多提一句，这里说的模板通常是YAML或是JSON文件，最近业界又开始将这类YAML和JSON代码化，面对资源的代码方式，思路和模板还是一致的，对于DevOps先锋者建议可以关注下AWS CDK和Pulumi类的产品。
实现模板化后，即可以将模板的管理方式和代码一致，使用Git等版本控制软件管理起来，使得模板的修改和发布过程可以享受类似代码一样的福利——评审、构建和持续发布，这就是最DevOps的自动化方式。
2.2 模板化或代码化是AIOps基础
AIOps（智能运维）可能是我们所有人的目标，不过理想和现实的差距还是存在的。现阶段的AIOps 只在少数的特定场景下才有，比如弹性扩容场景下，可以对历史扩容数据进行学习后进行预扩容，或用AI的方式来检测某个指标是否异常等，所以AIOps还远没有达到完全自动化的程度。建议在特定场景里可进行AIOps的调研，在方向上对AIOps保持关注即可。
即便如此，笔者还是愿意表达自己的观点，模板化或代码化自动化运维（即Level 4），应该会是AIOps的基础，因为只有所有运维工作都可以被自动化、所有自动化工作都非常规范和标准时，AI才有机会进行学习，AIOps 才可能成为现实。
3 DevOps基础核心：CI/CD，基础设施即代码
通常，云上自动化运维系统的第一步是环境部署，这是基础同时非常重要的一步。一旦部署完成，后续想要再去修改代价会非常大。尤其是上线以后，会是一个环境迁移的工程量了，所以环境部署是最先需要开始设计的。
3.1 CI/CD 流水线的系统运行环境
以实际项目中运用DevOps模式的例子——CI/CD流水线应用“基础设施即代码”的实践为例，看一下自动化部署的整个流程。
通常流水线的源头是从Git开始的，所以也有人将这种模式称之为GitOps，显然这里的Git也可以替换成其他的版本控制系统，如SVN等，因为思路是一样的，所以本文依旧称之为DevOps。
相信大家对CI/CD流水线都很熟悉了，如图3，这里的流水线不仅包括了业务代码Repo，还包括了DevOps Repo，那么DevOps Repo应该用来存什么内容的呢？这里重点强调的是系统所依赖的运行环境的配置，这里的运行环境通常也叫“基础设施”，即包括了云服务器、网络、数据库、负载均衡和中间件等业务应用所依赖的系统环境，目录可参考图4。
在图4中，environment.yml是一个环境所需要的完整模板，modules里是各个资源模块，分别是云服务器、数据库、负载均衡和VPC网络，这里只包含了最最基本的云资源，对于有经验的DevOps工程师还可以增加更多的资源，如消息队列、kafka等中间件，NoSQL类型的数据库以及监控和报警规则。
环境的配置信息可以存储在流水线上，这样在部署时可以先部署环境、后部署业务。那部署环境时，可以根据实际情况选择创建一个新环境或是更新环境。一个环境配置通常包含以下信息：
环境类型：如日常测试环境、预发环境和生产环境。
环境地域：如杭州、北京和上海等。
环境其他参数：如账号、AccessKey/Token和角色等。
资源相关配置：如服务器数量、域名等。
3.2 云上标准化部署三大能力
云上环境与传统数据中心的环境最大的区别是，云上的一切服务是以API为核心，资源的创建、修改和删除等所有操作都可以通过API来完成，因此云上部署是天然的规范化，从而提高了云上的部署效率，即实现了高效而统一的标准化部署。其中，典型的需重复部署的场景有以下四类：
环境部署，如日常测试环境、预发环境和生产环境，只需要构建一个部署，即可以通过新增stage的方式达到重复部署。通常由日常环境开始，然后重复到预发和生产环境。
多地域部署，如先部署在杭州、后需部署到北京和上海等其他地域，可以快速地重复部署。一般只需要在流水线上新增一个新地域stage，添加配置参数即可实现一键部署。
集群部署，如先部署了几个集群，再重复部署多个集群，同样也可以快速地重复部署。可以通过在流水线上新增一个新集群stage，添加配置参数即可实现一键部署。
容灾环境部署，如先部署了一个主要的生产环境，后需要部署一个容灾环境时，采取集群部署的同样方式来实现。
通常，云上高效而标准化部署具备三大能力——消除环境差异、环境的快速复制能力和环境的重建能力。
• 消除环境差异，实现环境一致性。环境的微小差异即可带来业务上非常大的差异，而且排查起来非常困难，比起代码的Debug要费时费力许多，毕竟大部分的代码逻辑可以在本地复现和Debug，但是环境造成的差异则非常繁琐，需要进行非常细致的排查才能找到问题的症结所在。而云上标准化部署能够消除环境差异，实现环境的一致性，大大地简化了运维工作。
• 一键部署，快速复制能力。从日常环境到生产环境，从A地域到B地域，从单集群到多个集群，无一不需要高效的复制能力，而环境的复制能力是其中的第一步，且是最为关键的一步。标准化部署能将原来的数天工作量缩短为几个小时，甚至一键部署的能力，可以说极大地提升了运维效率。
• 重建的能力。很多环境问题是问题历史悠久造成的，各种不规范、不标准的操作日积月累最终导致环境混乱。因此，对于日常测试环境来说，定期地推倒重建是非常有必要的，理由类似自动化测试，越干净的环境越能验证、复现和Debug业务问题。因此，当一个测试环境有问题时，应该可以做到随时释放并能够一键重建。
所以，如果在项目规划阶段就考虑到自动化部署能力，那么后续的部署无疑会平滑许多。然而，对于已经存在的项目是否也可以使用这个模式呢？答案是肯定的，这要求对应的服务有能力将已有的云资源转化成部署模板的能力，然后再根据修改这个模板以便可以重复使用。
4 完整DevOps体系应具备哪些能力？
如果说，100% 自动化是DevOps理想中的形态，那么任何环节的缺失都可能成为实践DevOps的障碍。通常，按照运维工作的流程来看，DevOps 往往会包括八个环节：计划、编码、构建、测试、发布、运维、监控，然后重新回到计划，开始新一轮迭代。
值得重点强调的是，利用上述部署模板的方式，也是可以包括监控、报警等设置。因为一切皆是云产品、一切云产品都提供API缘故，因此才成就了部署模板是可以做到统一集中的。
笔者所在的阿里云，DevOps体系不仅环境部署实现了模板化，连运维编排也可以模板化的，即自动化运维（阿里云提供运维编排工具OOS），业界也把这种模式叫做Ops as Code、Automation as Code或是Runbook as Code了。因为产品的设计原则和思想和部署模板一致，所以不再赘述其详细步骤。
作为云计算产品的生产者，笔者同时也从一个云资源的全生命周期梳理了一个DevOps的闭环，如图5。这张图笔者在今年2020云栖大会的分享中也做了阐述，熟悉北京的朋友喜欢用“四环图”来称呼它。
一环：最核心的云资源，有服务器类资源，虚拟机服务器和裸金属，也可以包括容器实例。
二环：云服务器的生命周期的六个阶段：创建、镜像、补丁升级、诊断修复、监控和运维和实例配置。
三环：云服务器全生命周期的六个阶段，可以利用不同的工具可以提升效率。如实例的监控和运维，除了有云厂商提供的监控产品外，还有很多第三方的监控产品。运维方面，建议使用自动化运维类产品，如运维编排OOS，可以把最常用的运维任务模板化，从而提供运维的规范性，减少因为人肉执行的失误，避免让运维背锅。
最近，我们已经将三环的这一整套“ECS自动化运维套件”正式对外发布，帮助企业实现从IT架构的规划、迁移、部署、弹性扩缩容，到日常管理全生命周期的自动化运维。利用这套工具，每一家云上的企业都可以低成本构建属于自己的自动化运维体系。
四环：除了使用云平台工具之外，还可以利用第三方的工具，如Terraform、Ansible等。另外，很多工具都不约而同地选择了模版的方式， 如YAML、JSON、Hashicorp自定义的HCL等。基于模板，可以构建一个生态，方便外部的参与者共同贡献内容，不仅丰富了DevOps的世界，最终达到了更高的DevOps效率。
图6不仅包含了阿里云的DevOps工具，也包括了业界较为流行的运维工具，它们的设计思想都是类似的，因此在工具的采用上可以根据实际需要分别采用。一般来说，如果使用的是单一云平台的云资源时，使用云平台一方的产品有着最一致的体验，集成度也最高，成本也是相对最少的。
这里，笔者还想简单提一下容器DevOps和云服务器DevOps的区别。当前，K8S已经是容器编排（管控）领域的事实标准了，几乎所有的云服务商也都实现了各类托管K8S产品，甚至局部的Serverless K8S。
很多云服务器的使用者对于K8S是心向往之，却又因为各种原因需要继续使用云服务器。笔者曾经这样评价过K8S，“K8S本身并不是什么技术上的重大创新，更多的是把DevOps里面的很多最佳实践产品化了”——这一说法也得到了部分容器专家的认同。
5 DevOps落地的阻碍：如何和财务流程实现平衡
事实上，DevOps并不是一个新鲜的概念，但是真正做到DevOps的企业少之又少，背后的原因是多种多样的。以笔者多年的经验看来，其中最大的两个因素：一个是财务，二是运维开发人员的习惯。
财务人员是典型的计划式模式，需先预估、再采购，这里最大的挑战在于没人能够精准地预测明天的事情，所以最终的结果要么是预估多了，要么就是预估少了，预估多了下一次的预估必定要收紧，预估少了再放松，然后循环重复这个过程。
财务上的限制对于DevOps的发展有时是致命的，这种“计划式”的模式直接影响到了云上资源的创建和释放模式，财务上喜欢“包年包月”，因为看起来比较划算，而DevOps运维开发人员则偏向于“按需分配，弹性伸缩”。
所以，笔者最后想呼吁各位财务专家多考虑下，给予技术架构上在预算上一定的灵活性，可以非常有效地帮助并促进业务高速发展。
