2026年DevOps与工程实践指南：从CI/CD到自动化运维，打造高效研发体系

一、写在前面：DevOps是研发团队的"高速公路"

2026年的夏天，我去一家互联网公司做技术咨询。这家公司，规模不小，有200多个研发人员，做的是电商业务。但是，他们的研发效率很低，问题很多。什么问题呢？第一，发布频率低。他们一个月才发布一次版本，而且每次发布都要加班到凌晨。因为发布的时候，经常出问题——不是这个功能有bug，就是那个服务启动失败，不是数据库连接不上，就是配置文件写错了。每次发布，都像打仗一样，惊心动魄。第二，开发和运维矛盾大。开发说：“我在我本地跑得好好的，为什么到你们环境就出问题了？肯定是你们环境的问题！“运维说：“你们写的代码太烂了，各种环境依赖，各种硬编码，我们怎么部署？肯定是你们代码的问题！“双方互相甩锅，矛盾很大。第三，故障恢复慢。线上出了故障，比如某个服务挂了，或者数据库慢查询了，他们要花很长时间才能定位问题，才能恢复服务。有时候，一个小故障，能搞几个小时，影响用户体验，也影响业务收入。第四，质量没保障。因为发布频率低，每次发布都攒了一大堆功能，测试时间不够，很多bug没测出来，就发到线上了。线上bug很多，用户投诉也很多。我去了之后，给他们做了一个全面的诊断，然后给他们开了一个"药方”——实施DevOps，打造高效的研发体系。什么是DevOps？简单来说，DevOps就是Development（开发）和Operations（运维）的组合，就是把开发和运维打通，让开发和运维协同工作，实现持续集成、持续交付、持续部署，提高研发效率，提高软件质量，降低故障风险。DevOps就像什么？就像一条高速公路。以前，开发和运维之间，是一条乡间小路，坑坑洼洼，弯弯曲曲，车开得很慢，还经常堵车，经常出事故。代码从开发到运维，要经过很多手工环节，效率很低，还经常出问题。DevOps，就是把这条乡间小路，修成一条高速公路。宽阔平坦，四通八达，车开得又快又稳，还不容易出事故。代码从开发到运维，自动化流水线，一键部署，效率很高，质量也有保障。这家公司，按照我开的"药方”，实施了DevOps之后，效果非常明显：- 发布频率，从一个月一次，变成了一天一次，甚至一天多次。- 发布时间，从加班到凌晨，变成了几分钟，一键部署。- 故障恢复时间，从几个小时，变成了几分钟，自动恢复。- 线上bug数量，减少了70%以上。- 开发和运维的矛盾，也少了很多，大家开始协同工作了。你看，DevOps的威力有多大！现在的互联网公司，竞争越来越激烈，业务变化越来越快，用户要求越来越高。谁能更快地发布功能，谁能更稳定地运行服务，谁就能在竞争中占据优势。而DevOps，就是实现这一切的关键。所以，不管你是开发、运维、测试，还是技术管理者，都应该了解DevOps，学习DevOps，实践DevOps。那么，DevOps到底是什么？包含哪些内容？怎么实施？有哪些工具和最佳实践？这就是我想在这篇文章里和大家聊的话题。—# 二、DevOps是什么？为什么要实施DevOps？## 2.1 什么是DevOps？在讲怎么实施DevOps之前，我们先搞清楚一个基本概念：什么是DevOps？DevOps这个词，是Development（开发）和Operations（运维）的组合。它的核心理念是：打破开发和运维之间的壁垒，让开发和运维协同工作，实现软件的快速、高质量交付。但是，DevOps不仅仅是开发和运维的协同，它还包含了更多的内容。DevOps是一种文化，一种理念，一种工作方式。它强调：- 协作（Collaboration）：开发、运维、测试、产品等各个角色，紧密协作，共同对软件的交付和运行负责。- 自动化（Automation）：把重复的、手工的工作，都自动化，减少人为错误，提高效率。- 持续集成（Continuous Integration）：代码频繁地集成到主干，每次集成都通过自动化的构建和测试来验证。- 持续交付（Continuous Delivery）：代码通过自动化的流水线，随时可以发布到生产环境。- 持续部署（Continuous Deployment）：代码通过自动化的流水线，自动部署到生产环境，不需要人工干预。- 监控（Monitoring）：对软件的运行状态进行全面的监控，及时发现问题，及时处理。- 反馈（Feedback）：建立快速的反馈机制，从用户、从监控、从测试中获取反馈，持续改进。DevOps就像什么？就像一个交响乐团。交响乐团里，有小提琴手、大提琴手、钢琴手、鼓手、长笛手等等，每个乐手都有自己的乐器，自己的部分。但是，他们不是各玩各的，而是在指挥的统一指挥下，紧密协作，互相配合，共同演奏出一首美妙的交响曲。DevOps也是一样的。研发团队里，有开发、运维、测试、产品等等，每个角色都有自己的职责，自己的工作。但是，他们不是各干各的，而是在DevOps的理念下，紧密协作，互相配合，共同交付高质量的软件。## 2.2 DevOps的发展历程DevOps不是凭空出现的，它有一个发展的过程。我们来简单回顾一下DevOps的发展历程：**第一阶段：瀑布模型时代（2000年以前）**最早的软件开发，用的是瀑布模型。什么是瀑布模型？就是软件开发分成几个阶段——需求分析、设计、编码、测试、部署，一个阶段完成了，才能进入下一个阶段，就像瀑布一样，从上往下流。瀑布模型的问题是什么？问题是周期太长，灵活性太差。一个软件，从需求到发布，可能要半年甚至一年。等发布出来的时候，需求可能已经变了，市场可能已经变了。而且，开发和运维是完全分开的。开发写完代码，扔给测试，测试测完，扔给运维，运维部署。各个环节之间，有厚厚的"墙”，沟通不畅，协作困难。**第二阶段：敏捷开发时代（2001年-2009年）**2001年，敏捷宣言发布，敏捷开发开始流行。敏捷开发强调：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。敏捷开发，把大的项目拆成小的迭代，每个迭代2-4周，交付一个可用的版本。这样，发布频率提高了，灵活性也提高了，能更快地响应需求变化。但是，敏捷开发主要解决的是开发环节的问题，运维环节还是老样子。开发写完代码，还是要扔给运维，运维还是手工部署，效率还是很低。开发和运维之间的"墙”，还是没有打破。这就出现了一个问题：开发敏捷了，运维不敏捷，整个交付流程还是不敏捷。就像一条水管，前面的管子变粗了，后面的管子还是细的，水流量还是上不去。**第三阶段：DevOps时代（2009年至今）**2009年，在比利时的O’Reilly Velocity大会上，John Allspaw和Paul Hammond做了一个演讲，题目是"10+ Deploys Per Day: Dev and Ops Cooperation at Flickr"。他们介绍了Flickr公司如何让开发和运维协同工作，实现每天部署10次以上。这个演讲，被认为是DevOps的起点。同年，Patrick Debois发起了第一届DevOpsDays会议，DevOps这个词正式诞生。从那以后，DevOps开始流行起来。越来越多的公司，开始实施DevOps，打破开发和运维之间的壁垒，实现持续集成、持续交付、持续部署。现在，DevOps已经成为了互联网公司的标配。几乎所有的大厂，都在实施DevOps，都在打造高效的研发体系。而且，DevOps还在不断发展。从最初的CI/CD，到后来的自动化运维、监控告警、AIOps，再到现在的GitOps、Platform Engineering、DevSecOps等等，DevOps的内涵越来越丰富，工具链越来越完善。## 2.3 为什么要实施DevOps？搞清楚了什么是DevOps，我们再来说说：为什么要实施DevOps？我总结了一下，实施DevOps，主要有以下几个好处：第一，提高研发效率，加快交付速度。这是DevOps最直接的好处。通过自动化的流水线，代码从提交到部署，全流程自动化，不需要人工干预，大大提高了效率。以前，部署一个版本，可能要几天，甚至几周。现在，部署一个版本，可能只需要几分钟，甚至几秒钟。发布频率，从一个月一次，变成了一天一次，甚至一天多次。这就像什么？就像以前寄信，要去邮局，贴邮票，投邮筒，然后等几天，对方才能收到。现在有了电子邮件，写完点一下发送，对方马上就能收到。效率提高了不知道多少倍。第二，提高软件质量，减少bug。DevOps强调自动化测试，每次代码提交，都会自动运行单元测试、集成测试、端到端测试，有bug马上就能发现，马上就能修复。而且，因为发布频率高，每次发布的功能少，变更范围小，出问题的概率也小。就算出了问题，也容易定位，容易回滚。这就像什么？就像以前的工厂，生产一批产品，生产完了再统一检验，有问题的话，可能整批都有问题，损失很大。现在的工厂，流水线生产，每个环节都有自动检测，有问题马上就能发现，马上就能处理，质量有保障，损失也小。第三，降低故障风险，提高系统稳定性。DevOps强调监控告警，对系统的运行状态进行全面的监控，有问题马上就能发现，马上就能告警。而且，DevOps强调自动化运维，故障可以自动恢复，不需要人工干预。比如，某个服务挂了，可以自动重启；某个节点挂了，可以自动摘除流量，自动切换到其他节点。这就像什么？就像以前的汽车，出了故障，要停车，自己检查，自己修，很麻烦，也很危险。现在的汽车，有各种传感器，有各种自动检测系统，有问题马上就能报警，有些问题还能自动处理，比如胎压低了自动充气，发动机有问题自动降功率，安全性和稳定性都提高了很多。第四，改善团队协作，减少矛盾。DevOps强调协作，打破开发和运维之间的壁垒，让大家协同工作，共同对软件的交付和运行负责。以前，开发和运维是"敌人"，互相甩锅，矛盾很大。现在，开发和运维是"战友"，一起工作，一起解决问题，矛盾少了，效率高了。这就像什么？就像以前的球队，前锋只管进攻，后卫只管防守，前锋不回防，后卫不助攻，球队配合不好，成绩也不好。现在的球队，前锋要回防，后卫要助攻，大家协同作战，配合默契，成绩自然就好。第五，降低成本，提高效益。DevOps通过自动化，减少了人工操作，降低了人力成本。通过提高发布频率，加快了业务迭代，能更快地响应市场变化，抓住商机，提高业务收入。通过提高系统稳定性，减少了故障损失，降低了运维成本。这就像什么？就像以前的农场，人工播种，人工收割，效率低，成本高，还容易受天气影响。现在的农场，机械化播种，机械化收割，自动化灌溉，自动化施肥，效率高，成本低，产量也高。总之，实施DevOps，好处多多。不管是对开发、运维、测试，还是对技术管理者，对公司业务，都有很大的好处。所以，如果你还没有实施DevOps，那就赶紧开始吧！—# 三、DevOps的核心实践## 3.1 持续集成（CI）讲完了DevOps的基本概念，我们来详细讲讲DevOps的核心实践。首先是持续集成（Continuous Integration，简称CI）。什么是持续集成？持续集成就是：开发人员频繁地把代码集成到主干分支，每次集成都通过自动化的构建和测试来验证，从而尽早地发现集成错误，提高软件质量。持续集成的核心是"频繁"和"自动化"。“频繁"是什么意思？就是开发人员不要等功能全部写完了，再一次性提交代码，而是要小步提交，频繁集成。最好是每天都提交，甚至每天提交好几次。每次提交的代码量不要太大，最好是一个小功能，或者一个小修改。为什么要频繁集成？因为频繁集成，每次集成的变更范围小，出问题的概率小，就算出了问题，也容易定位，容易修复。如果等功能全部写完了，再一次性提交，变更范围大，出问题的概率大，出了问题也很难定位，很难修复。这就像什么？就像你写论文，不要等全部写完了，再一次性保存，而是要写一点，保存一点，写一点，保存一点。这样，就算电脑突然死机了，你也不会丢失太多内容。如果等全部写完了再保存，电脑突然死机了，你可能就全部白写了。“自动化"是什么意思？就是每次代码提交，都会自动触发构建和测试，不需要人工干预。构建包括编译、打包、代码检查等，测试包括单元测试、集成测试等。如果构建或测试失败了，就会马上通知开发人员，开发人员马上修复。为什么要自动化？因为自动化可以减少人为错误，提高效率。如果每次提交都要人工构建、人工测试，那太麻烦了，效率太低了，而且人工操作容易出错。自动化构建和测试，又快又准，还能24小时不间断运行。持续集成的流程，一般是这样的：1. 开发人员在本地编写代码，写完后提交到代码仓库。2. 代码仓库收到提交后，触发CI服务器。3. CI服务器拉取最新的代码，进行编译构建。4. 构建成功后，运行单元测试、集成测试等自动化测试。5. 测试通过后，生成构建产物（比如jar包、docker镜像等），并上传到制品库。6. 如果构建或测试失败，就发送通知（邮件、短信、即时消息等）给开发人员，开发人员马上修复。持续集成的好处：- 尽早发现集成错误，降低修复成本。- 避免代码在最后时刻才集成，导致的混乱和延期。- 提高软件质量，减少bug。- 提高开发效率，减少手工操作。- 让开发人员更有信心，敢于频繁提交代码。常见的CI工具有：Jenkins、GitLab CI、GitHub Actions、Travis CI、CircleCI、TeamCity等。## 3.2 持续交付（CD）接下来是持续交付（Continuous Delivery，简称CD）。什么是持续交付？持续交付就是：在持续集成的基础上，把构建好的软件，通过自动化的流水线，部署到测试环境、预发布环境，进行更全面的测试和验证，确保软件随时可以发布到生产环境。持续交付的核心是"随时可发布”。也就是说，代码通过了自动化的流水线，经过了全面的测试和验证，随时都可以发布到生产环境，不需要额外的准备工作。但是，持续交付不等于自动发布到生产环境。是否发布到生产环境，什么时候发布，还是由人来决定的。持续交付只是保证软件随时处于可发布的状态，发布的决策权还是在人手里。这就像什么？就像你做好了一道菜，放在保温箱里，随时可以端上桌给客人吃。但是，什么时候端上桌，还是由你决定的。菜做好了，随时可以端，但是你可能要等客人到齐了，或者等其他菜做好了，再一起端上桌。持续交付和持续集成的区别是什么？持续集成，关注的是代码的构建和测试，确保代码是可构建的，是通过基本测试的。持续交付，关注的是软件的部署和验证，确保软件是可部署的，是通过全面测试的，是随时可发布的。可以说，持续交付是持续集成的延伸和扩展。持续集成是持续交付的基础，没有持续集成，就没有持续交付。持续交付的流程，一般是这样的：1. 持续集成阶段完成，构建产物上传到制品库。2. 自动化流水线把构建产物部署到测试环境。3. 在测试环境运行更全面的测试，比如接口测试、端到端测试、性能测试、安全测试等。4. 测试通过后，自动化流水线把构建产物部署到预发布环境（和生产环境一样的环境）。5. 在预发布环境进行最后的验证，比如冒烟测试、用户验收测试等。6. 验证通过后，软件就处于可发布状态，随时可以发布到生产环境。7. 发布的时候，只需要一键操作，或者点一下按钮，就能把软件发布到生产环境。持续交付的好处：- 让软件随时处于可发布状态，发布变得简单、可靠。- 减少发布的风险，因为软件已经经过了全面的测试和验证。- 提高发布频率，加快业务迭代。- 减少手工操作，降低人为错误。- 让团队更有信心，敢于频繁发布。## 3.3 持续部署（CD）接下来是持续部署（Continuous Deployment，简称CD，和持续交付的缩写一样，都是CD，要注意区分）。什么是持续部署？持续部署就是：在持续交付的基础上，把通过了自动化流水线的软件，自动部署到生产环境，不需要人工干预。持续部署和持续交付的区别是什么？持续交付，是软件随时可发布，但是发布还是需要人来操作，人来决定。持续部署，是软件自动发布到生产环境，不需要人来操作，不需要人来决定。可以说，持续部署是持续交付的终极形态。持续交付是"随时可发”，持续部署是"自动就发"。这就像什么？持续交付就像你做好了菜，放在保温箱里，随时可以端上桌，但是什么时候端，还是你决定。持续部署就像你做好了菜，自动就端上桌了，不需要你动手，也不需要你决定。持续部署的流程，和持续交付差不多，只是最后一步，不是人工发布，而是自动发布到生产环境。持续部署的好处：- 发布完全自动化，效率最高，不需要人工干预。- 发布频率最高，可以做到每次代码提交都自动发布。- 减少人为错误，因为发布过程完全自动化。- 加快业务迭代，能最快地把新功能推给用户。但是，持续部署的要求也很高。要实施持续部署，必须满足以下条件：- 自动化测试非常完善，覆盖率很高，能保证代码质量。- 监控告警非常完善，能及时发现线上问题。- 回滚机制非常完善，出了问题能快速回滚。- 灰度发布机制完善，能控制发布的范围和节奏。- 团队对持续部署有信心，敢于自动发布。如果这些条件不满足，就不要贸然实施持续部署。不然，自动发布到生产环境，出了问题，可能会造成很大的影响。所以，很多公司，都是先实施持续集成，再实施持续交付，等条件成熟了，再实施持续部署。一步一步来，循序渐进。## 3.4 基础设施即代码（IaC）接下来是基础设施即代码（Infrastructure as Code，简称IaC）。什么是基础设施即代码？简单来说，就是用代码来管理和配置基础设施，而不是用手工操作。基础设施包括什么？包括服务器、网络、存储、数据库、负载均衡器等等。以前，这些基础设施都是手工配置的——运维人员登录服务器，手动安装软件，手动配置环境，手动修改配置文件。手工配置有什么问题？第一，效率低。配置一台服务器，可能要花几个小时，甚至几天。如果有很多服务器，那工作量就更大了。第二，容易出错。手工操作，难免会出错——不是这里配置错了，就是那里漏了配置。而且，不同的人配置，可能配置的结果不一样，导致环境不一致。第三，难以复现。如果服务器出了问题，要重新配置一台，很难保证和原来的配置一模一样。而且，配置过程没有记录，出了问题也不好排查。第四，难以管理。基础设施多了，手工管理就很困难。哪些服务器配置了什么？哪些配置改了？什么时候改的？谁改的？都不清楚。基础设施即代码，就是为了解决这些问题。用代码来描述基础设施的配置，然后通过自动化的工具来执行这些代码，创建和配置基础设施。这就像什么？就像以前盖房子，工人手工砌墙，手工抹灰，手工装修，效率低，质量也参差不齐。现在盖房子，用预制板，用装配式建筑，在工厂里把构件生产好，到现场直接拼装，效率高，质量也有保障。基础设施即代码的好处：- 效率高。代码写好后，执行一下，就能自动创建和配置基础设施，不需要手工操作。- 一致性好。同样的代码，执行出来的结果是一样的，保证环境一致。- 可复现。代码是版本化管理的，随时可以复现任何一个版本的基础设施配置。- 可审计。代码的修改都有记录，谁改了什么，什么时候改的，都清清楚楚。- 易管理。基础设施的配置都在代码里，统一管理，统一维护。常见的IaC工具有：Terraform、Ansible、Puppet、Chef、SaltStack、CloudFormation等。其中，Terraform主要用于基础设施的编排（创建服务器、网络、存储等），Ansible、Puppet、Chef主要用于配置管理（安装软件、配置环境等）。## 3.5 微服务与容器化接下来是微服务与容器化。微服务和容器化，虽然不是DevOps独有的，但是它们是DevOps的重要基础。很多DevOps的实践，都是建立在微服务和容器化的基础之上的。先说说微服务。什么是微服务？微服务就是把一个大的单体应用，拆分成多个小的、独立的服务，每个服务运行在自己的进程中，服务之间通过轻量级的机制（比如HTTP REST API或者消息队列）进行通信。每个微服务，都围绕着一个业务能力来构建，并且可以独立开发、独立测试、独立部署、独立扩展。微服务的好处：- 独立部署。每个服务都可以独立部署，不需要等其他服务。发布一个服务，不会影响其他服务。- 独立扩展。每个服务都可以根据需要独立扩展，不需要整体扩展。比如，订单服务压力大，就只扩展订单服务，不需要扩展其他服务。- 技术异构。每个服务都可以用最适合的技术栈来开发，不需要所有服务都用同一种技术。- 容错性好。一个服务出了问题，不会影响其他服务，整个系统还能继续运行。- 团队自治。每个团队负责一个或几个服务，端到端负责，效率高，沟通成本低。但是，微服务也有挑战：- 复杂度高。服务多了，服务之间的调用关系复杂，运维难度大。- 分布式问题。服务之间通过网络通信，会有网络延迟、网络故障、数据一致性等问题。- 测试困难。服务之间有依赖，集成测试比较困难。- 部署复杂。服务多了，部署的工作量大，需要自动化的部署工具。这时候，容器化就派上用场了。什么是容器化？容器化就是把应用和它的依赖，打包到一个容器中，然后在任何环境中都能运行这个容器。容器和虚拟机有什么区别？虚拟机，是在物理服务器上，通过Hypervisor，虚拟出多个虚拟机，每个虚拟机都有自己的操作系统，然后在操作系统上运行应用。虚拟机比较重，启动慢，占用资源多。容器，是在操作系统层面，通过Linux的Namespace和Cgroups等技术，隔离出多个容器，每个容器共享宿主机的操作系统内核，但是有自己的文件系统、进程空间、网络空间等。容器比较轻，启动快，占用资源少。这就像什么？虚拟机就像一套一套的房子，每套房子都有自己的客厅、卧室、厨房、卫生间，独立完整，但是占地方，装修也慢。容器就像一个一个的胶囊公寓，每个胶囊公寓只有睡觉的地方，共享客厅、厨房、卫生间，轻便灵活，搬进去就能住。容器化的好处：- 环境一致。容器把应用和依赖都打包好了，在任何环境中运行都是一样的，不会出现"在我本地跑得好好的，到你环境就出问题"的情况。- 启动快。容器启动只需要几秒钟，甚至几毫秒，比虚拟机快很多。- 资源利用率高。容器共享操作系统内核，占用资源少，一台服务器上可以跑很多个容器。- 易于迁移。容器可以在任何支持容器的环境中运行，迁移很方便。- 易于自动化。容器的创建、启动、停止、删除，都可以通过API来操作，很容易自动化。现在最流行的容器技术，就是Docker。而容器的编排工具，最流行的就是Kubernetes（简称K8s）。微服务+容器化+K8s，已经成为了现在互联网公司的标准架构。而DevOps的很多实践，比如持续交付、持续部署、自动化运维，都是建立在这个架构基础之上的。## 3.6 监控与可观测性接下来是监控与可观测性。监控，是DevOps的重要组成部分。没有监控，就像盲人摸象，不知道系统运行得怎么样，出了问题也不能及时发现，更不能及时处理。什么是监控？监控就是对系统的运行状态进行持续的观测，收集各种指标和数据，当出现异常的时候，及时告警，通知相关人员处理。传统的监控，主要是监控一些基础指标，比如CPU使用率、内存使用率、磁盘使用率、网络流量、服务是否存活等。这些指标，能反映系统的基础运行状态，但是不够全面，不够深入。现在，随着微服务和分布式系统的发展，系统越来越复杂，传统的监控已经不够用了。于是，就出现了"可观测性"（Observability）的概念。什么是可观测性？可观测性就是通过系统外部的输出，来推断系统内部的状态。可观测性，比监控的范围更广，内涵更丰富。可观测性，主要包括三个支柱：第一，指标（Metrics）。指标，就是一些数值型的数据，用来衡量系统的运行状态。比如，CPU使用率、内存使用率、请求量、响应时间、错误率等等。指标的特点是：数值型的，可聚合的，可计算的。可以对指标进行统计、聚合、告警。常见的指标监控工具有：Prometheus、Zabbix、Nagios、Datadog等。第二，日志（Logs）。日志，就是系统运行过程中产生的文本记录，用来记录系统的运行情况、错误信息、用户操作等。日志的特点是：文本型的，离散的，不可聚合的。但是，日志包含了丰富的信息，出了问题，可以通过日志来排查。常见的日志工具有：ELK Stack（Elasticsearch、Logstash、Kibana）、Loki、Fluentd、Splunk等。第三，链路追踪（Tracing）。链路追踪，就是追踪一个请求在系统中的完整调用链路，记录这个请求经过了哪些服务，每个服务的处理时间是多少，有没有出错等等。在微服务架构中，一个请求可能要经过很多个服务，调用链路很长很复杂。出了问题，很难定位是哪个服务出了问题。链路追踪，就能帮你快速定位问题，找到瓶颈。常见的链路追踪工具有：Jaeger、Zipkin、SkyWalking、OpenTelemetry等。指标、日志、链路追踪，这三个支柱，合在一起，就构成了完整的可观测性体系。有了这个体系，你就能全面地了解系统的运行状态，出了问题能快速定位，快速处理。这就像什么？就像医生给病人看病。指标就像体温、血压、心率这些基础指标，能反映病人的基本健康状况。日志就像病人的病历，记录了病人的病史和症状。链路追踪就像CT、核磁共振这些检查，能深入到身体内部，看看哪个器官出了问题。三者结合，医生就能全面地了解病人的病情，做出准确的诊断。除了监控和可观测性，告警也很重要。告警，就是当系统出现异常的时候，及时通知相关人员处理。告警要注意以下几点：- 告警要准确。不要乱告警，不要告警风暴，不然大家会对告警麻木，真正重要的告警反而被忽略了。- 告警要分级。不同级别的告警，用不同的通知方式。比如，紧急告警，打电话；重要告警，发短信；一般告警，发即时消息。- 告警要可操作。每个告警，都应该有对应的处理手册，告诉大家收到这个告警该怎么处理。- 告警要持续优化。定期回顾告警，去掉没用的告警，优化不准确的告警，增加缺失的告警。## 3.7 DevSecOps：安全左移最后是DevSecOps。什么是DevSecOps？DevSecOps就是Development（开发）、Security（安全）、Operations（运维）的组合，就是把安全融入到DevOps的整个流程中，在软件开发生命周期的每个阶段，都考虑安全，实现安全的自动化和持续化。以前，安全是在软件发布之前，由安全团队来做的。开发写完代码，测试测完功能，然后交给安全团队做安全扫描、安全测试。安全团队说有问题，开发再回去改。这样，安全成了发布的瓶颈，也经常导致延期。而且，等安全团队发现问题的时候，代码已经写完了，这时候再改，成本很高，也很麻烦。DevSecOps，就是要改变这种状况。把安全"左移"，在软件开发的早期阶段，就考虑安全，就做安全检查。这样，安全问题能尽早发现，尽早修复，修复成本低，也不会成为发布的瓶颈。DevSecOps的核心理念是：安全是每个人的责任，不是只有安全团队才负责安全。开发、运维、测试，每个人都要对安全负责。这就像什么？就像以前的工厂，质量是质检部门的事，生产部门只管生产，不管质量。等生产完了，质检部门再检查，有问题再返工。这样，质量没保障，返工成本也高。现在的工厂，强调全面质量管理，每个人都对质量负责，每个环节都有质量检查，质量有保障，成本也低。DevSecOps的主要实践包括：- 代码安全扫描：在代码提交的时候，自动进行静态代码安全扫描（SAST），发现代码中的安全漏洞。- 依赖安全扫描：对第三方依赖库进行安全扫描，发现有漏洞的依赖库，及时升级。- 镜像安全扫描：对Docker镜像进行安全扫描，发现镜像中的安全漏洞和恶意软件。- 动态安全测试：在测试环境中，进行动态应用安全测试（DAST），模拟黑客攻击，发现安全漏洞。- 安全配置检查：对基础设施的配置进行安全检查，发现不安全的配置，及时修复。- 密钥管理：对密码、密钥、证书等敏感信息进行统一管理，不要硬编码在代码中。- 安全培训：对开发、运维、测试人员进行安全培训，提高安全意识，普及安全知识。常见的DevSecOps工具有：SonarQube、Snyk、Trivy、OWASP ZAP、Checkov、Vault等。—# 四、DevOps工具链## 4.1 代码管理工具讲完了DevOps的核心实践，我们来聊聊DevOps的工具链。DevOps的工具链，就是支撑DevOps实践的各种工具的组合。一个完整的DevOps工具链，覆盖了软件开发生命周期的各个阶段——代码管理、持续集成、持续交付、配置管理、容器编排、监控告警、日志管理等等。首先是代码管理工具。代码管理，是软件开发的基础。代码管理工具，用来管理代码的版本，支持多人协作开发。现在最流行的代码管理工具，就是Git。Git是一个分布式的版本控制系统，由Linus Torvalds（Linux之父）在2005年开发。Git的特点是：分布式、速度快、分支管理强大、支持离线工作。基于Git的代码托管平台，主要有：- GitHub：全球最大的代码托管平台，开源项目的聚集地。很多知名的开源项目，都托管在GitHub上。- GitLab：一个开源的代码托管平台，可以自己部署。很多公司都用GitLab来搭建自己的内部代码托管平台。GitLab不仅有代码管理，还有CI/CD、Issue管理、Wiki等功能，是一个完整的DevOps平台。- Gitee（码云）：国内的代码托管平台，访问速度快，界面是中文的。很多国内的开发者和公司，都用Gitee。- Bitbucket：Atlassian公司的代码托管平台，和Jira、Confluence等工具集成得很好。代码管理的最佳实践：- 使用分支策略。常见的分支策略有：Git Flow、GitHub Flow、Trunk Based Development等。选择适合自己团队的分支策略。- 小步提交。每次提交的代码量不要太大，最好是一个小功能，或者一个小修改。提交信息要写清楚，说明这次提交做了什么。- 代码评审（Code Review）。代码合并到主干之前，要经过代码评审，确保代码质量。- 保护主干分支。主干分支要保护，不能直接提交代码，必须通过Merge Request或者Pull Request的方式，经过评审后才能合并。## 4.2 CI/CD工具接下来是CI/CD工具。CI/CD工具，是DevOps工具链的核心。它负责自动化的构建、测试、部署，实现持续集成、持续交付、持续部署。常见的CI/CD工具有：JenkinsJenkins是最流行的开源CI/CD工具，用Java开发。Jenkins的特点是：功能强大，插件丰富，几乎支持所有的工具和平台；灵活可扩展，可以通过插件来扩展功能；社区活跃，文档丰富。Jenkins的缺点是：界面比较老旧，配置比较复杂，需要自己维护，运维成本比较高。GitLab CIGitLab CI是GitLab内置的CI/CD功能。如果你用GitLab来管理代码，那么用GitLab CI来做CI/CD就非常方便，不需要额外的工具，集成得很好。GitLab CI的特点是：和GitLab集成得好，配置简单，用YAML文件来定义流水线，支持Docker，支持并行构建。GitHub ActionsGitHub Actions是GitHub内置的CI/CD功能。如果你用GitHub来管理代码，那么用GitHub Actions就非常方便。GitHub Actions的特点是：和GitHub集成得好，配置简单，用YAML文件来定义流水线，有丰富的Action市场，可以复用别人写好的Action。其他CI/CD工具除了上面三个，还有一些其他的CI/CD工具，比如：- Travis CI：一个云端的CI/CD服务，和GitHub集成得很好，开源项目可以免费使用。- CircleCI：一个云端的CI/CD服务，速度快，性能好。- TeamCity：JetBrains公司的CI/CD工具，功能强大，界面友好。- Bamboo：Atlassian公司的CI/CD工具，和Jira、Bitbucket集成得很好。- Argo CD：一个基于Kubernetes的GitOps持续部署工具。- Flux：另一个基于Kubernetes的GitOps持续部署工具。CI/CD工具的选择，要根据自己的实际情况来。如果用GitLab管理代码，就用GitLab CI；如果用GitHub管理代码，就用GitHub Actions；如果需要更灵活、更强大的功能，就用Jenkins。## 4.3 容器与编排工具接下来是容器与编排工具。容器与编排工具，是现在DevOps工具链的重要组成部分。微服务架构下，服务很多，用容器来打包和运行服务，用编排工具来管理容器，已经成为标准做法。DockerDocker是现在最流行的容器技术。Docker的出现， revolutionized了软件的交付方式。用Docker，你可以把应用和它的依赖，打包到一个镜像中，然后在任何支持Docker的环境中运行这个镜像，保证环境一致。Docker的核心概念：- 镜像（Image）：一个只读的模板，包含了运行应用所需的一切——代码、运行时、库、环境变量、配置文件等。- 容器（Container）：镜像的运行实例。一个镜像，可以运行多个容器。- Dockerfile：一个文本文件，用来定义如何构建Docker镜像。- 仓库（Registry）：用来存储和分发Docker镜像的地方。常见的有Docker Hub、Harbor等。**Kubernetes（K8s）**Kubernetes，简称K8s，是现在最流行的容器编排工具。K8s最初是Google开发的，基于Google内部的Borg系统，后来捐赠给了CNCF（云原生计算基金会）。K8s的作用是什么？K8s用来管理容器化的应用，包括容器的部署、扩缩容、负载均衡、服务发现、滚动更新、故障恢复等等。有了K8s，你就不需要手动管理容器了。你只需要告诉K8s，你想要运行什么应用，运行多少个实例，K8s就会自动帮你部署，自动帮你管理。如果某个容器挂了，K8s会自动重启它；如果流量大了，K8s会自动扩容；如果流量小了，K8s会自动缩容。K8s的核心概念：- Pod：K8s中最小的调度单元，一个Pod中可以运行一个或多个容器。- Service：用来定义一组Pod的访问方式，提供负载均衡和服务发现。- Deployment：用来管理Pod的部署，支持滚动更新、回滚、扩缩容。- ConfigMap：用来存储配置信息，不需要把配置硬编码在镜像中。- Secret：用来存储敏感信息，比如密码、密钥、证书等。- Namespace：用来隔离资源，不同的Namespace之间的资源是隔离的。- Ingress：用来管理外部对集群内服务的访问，支持HTTP和HTTPS路由。其他容器与编排工具除了Docker和K8s，还有一些其他的容器与编排工具：- containerd：一个工业级的容器运行时，现在是Docker的底层运行时，也被K8s广泛使用。- Podman：一个无守护进程的容器引擎，可以作为Docker的替代品。- Helm：K8s的包管理工具，用Chart来打包和管理K8s应用。- Istio：一个服务网格（Service Mesh）框架，用来管理微服务之间的通信，提供流量管理、安全、可观测性等功能。- Harbor：一个开源的容器镜像仓库，可以自己部署，用来存储和管理内部的Docker镜像。## 4.4 配置管理与基础设施即代码工具接下来是配置管理与基础设施即代码工具。这类工具，用来自动化地管理和配置基础设施，实现基础设施即代码（IaC）。TerraformTerraform是HashiCorp公司的开源工具，是现在最流行的基础设施编排工具。Terraform用HCL（HashiCorp Configuration Language）语言来定义基础设施，然后通过Terraform的命令，来创建、修改、销毁基础设施。Terraform的特点是：- 多云支持。Terraform支持几乎所有的云平台，比如AWS、Azure、GCP、阿里云、腾讯云等等。你可以用同一套工具，来管理不同云平台的基础设施。- 声明式配置。你只需要定义你想要的基础设施状态，Terraform会自动帮你达到这个状态，不需要你写具体的操作步骤。- 执行计划。Terraform在执行之前，会先生成一个执行计划，告诉你它要做什么，你确认后才会执行，避免误操作。- 资源图。Terraform会自动分析资源之间的依赖关系，按照正确的顺序来创建和修改资源。- 状态管理。Terraform会记录基础设施的状态，下次执行的时候，会对比当前状态和期望状态，只做必要的修改。AnsibleAnsible是Red Hat公司的开源工具，是现在最流行的配置管理工具。Ansible用YAML语言来定义配置，然后通过SSH协议，连接到远程服务器，执行配置任务。Ansible的特点是：- 简单易用。Ansible用YAML来定义配置，语法简单，容易上手。- 无代理。Ansible不需要在被管理的服务器上安装Agent，只需要SSH连接就行，部署简单。- 幂等性。Ansible的大部分模块都是幂等的，也就是说，执行多次和执行一次的效果是一样的，不会重复配置。- 丰富的模块。Ansible有非常丰富的模块，几乎可以管理所有的东西——服务器、网络、数据库、云平台等等。- 角色（Role）。Ansible支持角色，可以把相关的任务、变量、模板等组织在一起，实现复用。其他配置管理工具除了Terraform和Ansible，还有一些其他的配置管理和IaC工具：- Puppet：一个老牌的配置管理工具，用Ruby语言开发，有自己的DSL（领域特定语言）。Puppet是主从架构，需要在被管理的服务器上安装Agent。- Chef：另一个老牌的配置管理工具，用Ruby语言开发，用纯Ruby来写配置。Chef也是主从架构，需要安装Agent。- SaltStack：一个配置管理工具，用Python开发，速度快，支持远程执行。SaltStack也是主从架构。- Pulumi：一个基础设施即代码工具，可以用通用的编程语言（比如Python、TypeScript、Go等）来定义基础设施，而不是用专用的DSL。- CloudFormation：AWS的基础设施即代码工具，只能管理AWS的资源。- ARM模板：Azure的基础设施即代码工具，只能管理Azure的资源。## 4.5 监控与日志工具最后是监控与日志工具。监控与日志工具，用来观测系统的运行状态，收集指标和日志，及时发现和处理问题。PrometheusPrometheus是现在最流行的开源监控工具，由SoundCloud公司在2012年开发，后来捐赠给了CNCF。Prometheus是云原生监控的事实标准。Prometheus的特点是：- 多维数据模型。Prometheus用指标名和一组键值对（标签）来标识时间序列数据，可以灵活地聚合和查询。- 强大的查询语言。Prometheus有自己的查询语言PromQL，可以对指标进行各种查询、聚合、计算。- 拉模式。Prometheus通过HTTP拉取的方式来采集指标，不需要在被监控的服务器上安装Agent，只需要暴露一个HTTP端点就行。- 服务发现。Prometheus支持多种服务发现机制，可以自动发现要监控的目标，不需要手动配置。- 告警管理。Prometheus有独立的告警管理器Alertmanager，支持告警分组、抑制、静默、路由等功能。GrafanaGrafana是现在最流行的开源数据可视化工具。Grafana可以对接各种数据源（比如Prometheus、InfluxDB、Elasticsearch等），然后用图表的方式，把数据展示出来。Grafana的特点是：- 丰富的图表类型。Grafana支持折线图、柱状图、饼图、表格、热力图、仪表盘等各种图表类型。- 灵活的仪表盘。Grafana的仪表盘可以自由拖拽、自由布局，可以创建各种复杂的仪表盘。- 丰富的数据源。Grafana支持几乎所有的主流数据源，可以统一展示不同来源的数据。- 告警功能。Grafana也支持告警，可以对图表设置告警规则，异常时发送通知。- 插件市场。Grafana有丰富的插件市场，可以安装各种插件，扩展功能。ELK StackELK Stack是现在最流行的开源日志管理工具栈，由三个工具组成：Elasticsearch、Logstash、Kibana。- Elasticsearch：一个分布式的搜索和分析引擎，用来存储和搜索日志数据。Elasticsearch的特点是：分布式、可扩展、搜索速度快、支持全文检索。- Logstash：一个数据收集和处理管道，用来从各种来源收集日志，处理后发送到Elasticsearch。Logstash支持各种输入、过滤、输出插件。- Kibana：一个数据可视化平台，用来展示Elasticsearch中的数据。Kibana支持各种图表，可以创建仪表盘，可以搜索和分析日志。后来，又加入了Beats（一个轻量级的数据采集器），组成了Elastic Stack。其他监控与日志工具除了上面这些，还有一些其他的监控与日志工具：- Zabbix：一个老牌的企业级监控工具，功能全面，支持监控各种设备和服务。- Nagios：另一个老牌的监控工具，主要用于监控服务和主机的存活状态。- Datadog：一个云端的监控和可观测性平台，功能全面，但是是商业软件，收费。- New Relic：另一个云端的应用性能监控（APM）工具。- Loki：Grafana Labs开发的日志聚合工具，轻量级，和Grafana集成得很好。- Jaeger：一个开源的分布式链路追踪工具，由Uber开发，后来捐赠给了CNCF。- SkyWalking：一个开源的应用性能监控和链路追踪工具，由华为开发，后来捐赠给了Apache基金会。- OpenTelemetry：一个统一的可观测性数据采集标准和工具集，由CNCF管理，支持指标、日志、链路追踪的统一采集。—# 五、DevOps实施路线图## 5.1 评估现状，制定目标讲完了DevOps的核心实践和工具链，我们来聊聊怎么实施DevOps。实施DevOps，不是一蹴而就的，需要循序渐进，一步一步来。我给大家整理了一个DevOps实施的路线图，供大家参考。第一步：评估现状，制定目标。在实施DevOps之前，首先要评估一下自己团队的现状，搞清楚现在处于什么水平，有什么问题，有什么痛点。然后，根据现状，制定实施DevOps的目标。怎么评估现状？可以从以下几个维度来评估：- 代码管理：用的是什么版本控制工具？有没有分支策略？有没有代码评审？- 构建集成：有没有自动化构建？有没有持续集成？构建需要多长时间？- 测试：有没有自动化测试？测试覆盖率是多少？有没有单元测试、集成测试、端到端测试？- 部署：部署是手工的还是自动化的？部署一次需要多长时间？发布频率是多少？- 环境：有多少个环境？环境是不是一致的？环境配置是手工的还是自动化的？- 监控：有没有监控？监控覆盖了哪些方面？有没有告警？告警是不是准确？- 团队：开发和运维的关系怎么样？有没有协作？有没有共同的目标？评估完现状，就可以制定目标了。目标要具体，可衡量，有时间节点。比如：- 3个月内，实现持续集成，代码提交后自动构建和测试。- 6个月内，实现持续交付，部署自动化，一键部署到测试环境和预发布环境。- 12个月内，实现持续部署，代码通过自动化流水线后自动部署到生产环境。- 发布频率，从一个月一次，提高到一周一次，再提高到一天一次。- 部署时间，从几个小时，缩短到几分钟。- 故障恢复时间，从几个小时，缩短到几分钟。- 自动化测试覆盖率，从30%提高到70%。目标制定好了，就有了方向，有了动力。这就像什么？就像你要减肥，首先要称一下自己现在多重，体脂率多少，身体状况怎么样。然后，制定减肥目标——3个月减10斤，6个月减20斤，体脂率降到20%以下。有了目标，才有方向，才有动力。## 5.2 搭建基础工具链第二步：搭建基础工具链。工欲善其事，必先利其器。实施DevOps，首先要把基础的工具链搭建起来。基础工具链包括：- 代码管理工具：比如GitLab、GitHub、Gitee等。- CI/CD工具：比如Jenkins、GitLab CI、GitHub Actions等。- 制品库：比如Nexus、Artifactory、Harbor等，用来存储构建产物和Docker镜像。- 配置管理工具：比如Ansible、Puppet、Chef等。- 监控工具：比如Prometheus、Grafana、Zabbix等。- 日志工具：比如ELK Stack、Loki等。工具的选择，要根据自己团队的实际情况来。不要盲目追求新工具、酷工具，要选择适合自己的，团队能驾驭的工具。而且，工具不要一下子上太多，要循序渐进。先把最基础的代码管理和CI/CD搭起来，然后再逐步加上制品库、配置管理、监控、日志等。这就像什么？就像你装修房子，首先要把水电、地板、墙面这些基础装修做好，然后再买家具、家电，再做软装装饰。不要一开始就买一堆家具家电，基础装修还没做好，家具家电都没地方放。## 5.3 实现持续集成第三步：实现持续集成。基础工具链搭好之后，就可以开始实现持续集成了。持续集成的实施步骤：1. 统一代码管理。所有的代码都放到代码仓库中，用Git来管理，制定分支策略。2. 编写自动化测试。开发人员要写单元测试，测试人员要写集成测试和端到端测试。测试要自动化，能通过命令行运行。3. 配置CI流水线。在CI工具中，配置流水线，代码提交后自动触发，自动拉取代码，自动编译构建，自动运行测试。4. 构建产物管理。构建成功后，自动把构建产物上传到制品库，版本化管理。5. 代码质量检查。在CI流水线中，加入代码质量检查，比如静态代码分析、代码覆盖率检查、安全扫描等。6. 通知机制。构建或测试失败了，自动发送通知给开发人员，开发人员马上修复。实施持续集成，要注意以下几点：- 流水线要快。CI流水线的运行时间不要太长，最好控制在10分钟以内。如果太长，开发人员就不愿意等，也不愿意频繁提交代码。- 测试要可靠。自动化测试要稳定，不要经常出现偶发性失败，不然大家会对测试失去信心。- 失败要修复。CI流水线失败了，要马上修复，不要带着失败继续开发。最好有一个规则，谁提交的代码导致CI失败，谁负责修复。- 小步提交。开发人员要小步提交，频繁集成，不要等功能全部写完了再一次性提交。这就像什么？就像你学开车，首先要学会起步、停车、转弯这些基础操作，然后再学上路，再学高速行驶。不要一开始就上高速，那样太危险了。## 5.4 实现持续交付第四步：实现持续交付。持续集成做好之后，就可以开始实现持续交付了。持续交付的实施步骤：1. 环境标准化。统一开发环境、测试环境、预发布环境、生产环境的配置，保证环境一致。最好用容器来打包应用，用IaC来管理环境配置。2. 部署自动化。把部署过程自动化，不需要人工操作。写部署脚本，或者用配置管理工具，实现一键部署。3. 配置CD流水线。在CI/CD工具中，配置CD流水线，CI完成后，自动把构建产物部署到测试环境，运行更全面的测试，然后自动部署到预发布环境，进行最后的验证。4. 数据库变更管理。数据库的变更也要自动化，纳入到CD流水线中。用数据库迁移工具，比如Flyway、Liquibase，来管理数据库变更。5. 灰度发布。实现灰度发布机制，发布的时候先发布到一小部分服务器，或者一小部分用户，观察没有问题了，再全量发布。6. 回滚机制。完善回滚机制，出了问题能快速回滚到上一个版本。回滚也要自动化，一键回滚。实施持续交付，要注意以下几点：- 部署要可靠。自动化部署要稳定，不要经常出问题。部署前要做好检查，部署后要做好验证。- 变更要小。每次发布的变更范围要小，不要一次发布一大堆功能。变更小，出问题的概率小，也容易定位和回滚。- 发布要频繁。发布频率要高，不要攒一大堆功能才发布一次。频繁发布，每次变更小，风险小，也能更快地把新功能推给用户。- 文档要完善。部署流程、回滚流程、故障处理流程，都要有完善的文档，大家都要熟悉。这就像什么？就像你学做饭，首先要学会做简单的菜，然后再学复杂的菜，再学做宴席。不要一开始就做满汉全席，那样太难了，也容易失败。## 5.5 完善监控与可观测性第五步：完善监控与可观测性。持续交付做好之后，就要完善监控与可观测性了。因为发布频率高了，变更多了，如果没有完善的监控，出了问题不能及时发现，就会造成很大的影响。监控与可观测性的实施步骤：1. 指标监控。搭建指标监控系统，比如Prometheus+Grafana，监控系统的基础指标（CPU、内存、磁盘、网络等）和业务指标（请求量、响应时间、错误率、订单量等）。2. 日志管理。搭建日志管理系统，比如ELK Stack，收集所有服务的日志，统一存储，统一搜索，统一分析。3. 链路追踪。搭建链路追踪系统，比如Jaeger、SkyWalking，追踪请求在微服务中的完整调用链路，快速定位问题和瓶颈。4. 告警体系。建立完善的告警体系，定义告警规则，分级告警，准确告警，避免告警风暴。每个告警都要有对应的处理手册。5. 仪表盘。创建各种仪表盘，展示系统的运行状态、业务指标、性能指标等，让大家一眼就能看到系统的状况。6. 故障演练。定期进行故障演练，比如混沌工程，模拟各种故障，检验系统的容错能力和恢复能力，检验监控告警的有效性，检验团队的故障处理能力。实施监控与可观测性，要注意以下几点：- 监控要全面。不要只监控基础指标，还要监控业务指标、应用指标、用户体验指标。从基础设施到应用，再到业务，都要监控到。- 告警要准确。不要乱告警，不要告警风暴。告警要精准，只在真正需要人工介入的时候才告警。- 日志要规范。日志的格式要统一，日志的级别要合理，日志的内容要有意义，方便搜索和分析。- 链路要完整。链路追踪要覆盖所有的服务，所有的调用，这样才能追踪完整的调用链路。这就像什么？就像你买了一辆新车，首先要装好仪表盘，能看到车速、转速、油量、水温、故障灯等。然后要装好行车记录仪，记录行车过程。还要装好导航，知道自己在哪里，要去哪里。有了这些，你开车才放心，出了问题也能及时发现。## 5.6 持续改进，文化建设第六步：持续改进，文化建设。DevOps不是一次性的项目，不是做完了就完事了。DevOps是一个持续改进的过程，需要不断地优化，不断地提升。而且，DevOps不仅仅是工具和技术，更重要的是文化和理念。工具和技术是"术"，文化和理念是"道"。没有"道"，"术"再厉害，也发挥不出最大的作用。所以，实施DevOps，最后要落到持续改进和文化建设上。持续改进的方法：- 定期回顾。定期（比如每个月或者每个季度）回顾DevOps的实施情况，看看哪些做得好，哪些做得不好，有什么问题，有什么可以改进的地方。- 度量驱动。用数据来说话，度量DevOps的关键指标，比如部署频率、部署前置时间、变更失败率、故障恢复时间等。通过度量，发现问题，找到改进方向。- 小步快跑。改进不要贪大求全，要小步快跑，一次改进一点，持续不断地改进。- 鼓励创新。鼓励团队成员尝试新的工具、新的方法、新的实践，不怕失败，从失败中学习。文化建设的方法：- 打破壁垒。打破开发和运维之间的壁垒，让大家协同工作，共同对软件的交付和运行负责。可以搞一些跨团队的活动，增进了解和信任。- 共同目标。建立共同的目标，比如提升发布频率、降低故障时间、提高用户满意度等。让大家朝着同一个目标努力，而不是各干各的，互相甩锅。- 鼓励协作。鼓励团队成员之间的协作和分享，比如搞技术分享会、代码评审、结对编程等，让大家互相学习，共同进步。- 容错文化。建立容错文化，不要因为出了故障就追责、就惩罚。要把故障当成学习的机会，做故障复盘，找到根本原因，改进系统，避免下次再犯。- 持续学习。鼓励团队成员持续学习，学习新的技术、新的工具、新的方法。可以提供学习资源，组织培训，支持大家参加技术会议等。这就像什么？就像你健身，不是练出一身肌肉就完事了，还要持续锻炼，保持身材，还要不断学习新的健身方法，提升健身效果。而且，健身不仅仅是锻炼身体，还要培养健康的生活习惯，比如合理饮食、规律作息、戒烟限酒等。习惯和文化，比一时的锻炼更重要。—# 六、DevOps的度量指标## 6.1 DORA四大指标讲完了DevOps的实施路线图，我们来聊聊DevOps的度量指标。实施DevOps，效果怎么样？有没有提升？提升了多少？这些都需要用数据来说话，需要有度量指标。现在最权威的DevOps度量指标，就是DORA的四大指标。DORA（DevOps Research and Assessment）是Google的一个研究团队，他们研究了几千家公司的DevOps实践，总结出了四个关键指标，用来衡量DevOps的效能。DORA四大指标是：第一，部署频率（Deployment Frequency）。部署频率，就是团队部署代码到生产环境的频率。比如，每天部署多少次，每周部署多少次，每月部署多少次。部署频率越高，说明团队的交付能力越强，能更快地把新功能推给用户，更快地响应市场变化。部署频率的等级：- 精英：每天多次部署。- 高：每周一次到每天一次。- 中：每月一次到每周一次。- 低：每月一次以下。第二，变更前置时间（Lead Time for Changes）。变更前置时间，就是从代码提交，到代码部署到生产环境，所需要的时间。变更前置时间越短，说明团队的交付效率越高，代码能更快地到达用户手中。变更前置时间的等级：- 精英：不到1小时。- 高：1天到1周。- 中：1周到1个月。- 低：1个月以上。第三，变更失败率（Change Failure Rate）。变更失败率，就是部署到生产环境的变更中，导致故障或者需要回滚的比例。变更失败率越低，说明团队的交付质量越高，发布的代码越稳定。变更失败率的等级：- 精英：0%-15%。- 高：16%-30%。- 中：31%-45%。- 低：46%以上。第四，服务恢复时间（Time to Restore Service）。服务恢复时间，就是生产环境出了故障之后，恢复服务所需要的时间。服务恢复时间越短，说明团队的故障处理能力越强，系统的可靠性越高。服务恢复时间的等级：- 精英：不到1小时。- 高：不到1天。- 中：不到1周。- 低：1周以上。这四个指标，两个是衡量交付速度的（部署频率、变更前置时间），两个是衡量交付质量的（变更失败率、服务恢复时间）。速度和质量，缺一不可。很多人以为，DevOps就是追求快，为了快可以牺牲质量。其实不是的。DevOps是既要快，又要好。精英团队，不仅部署频率高，变更前置时间短，而且变更失败率低，服务恢复时间短。他们是又快又好。这就像什么？就像赛车手，好的赛车手，不仅开得快，而且开得稳，不容易出事故。新手呢，要么开得慢，要么开得快但是容易出事故。又快又稳，才是真正的高手。## 6.2 其他辅助指标除了DORA四大指标，还有一些其他的辅助指标，可以用来更全面地衡量DevOps的效能。研发效率类指标：- 需求交付周期：从需求提出，到需求上线，所需要的时间。- 代码评审时间：从代码提交评审，到评审完成，所需要的时间。- 构建时间：CI流水线的构建时间。- 测试时间：自动化测试的运行时间。- 部署时间：部署一次所需要的时间。质量类指标：- 自动化测试覆盖率：自动化测试覆盖的代码比例。- 单元测试覆盖率：单元测试覆盖的代码比例。- 线上bug数量：线上发现的bug数量。- bug修复时间：从bug发现，到bug修复，所需要的时间。- 代码质量评分：用SonarQube等工具扫描的代码质量评分。- 技术债务：技术债务的数量和严重程度。稳定性类指标：- 系统可用性：系统正常运行的时间比例，比如99.9%、99.99%。- 故障数量：线上发生的故障数量。- 故障影响范围：故障影响的用户数量和业务范围。- 平均无故障时间（MTBF）：两次故障之间的平均时间。- 平均修复时间（MTTR）：从故障发生，到故障恢复，所需要的平均时间。团队协作类指标：- 部署成功率：部署成功的比例。- 回滚次数：回滚的次数。- 跨团队协作次数：跨团队协作的项目和任务数量。- 员工满意度：团队成员对DevOps实践的满意度。度量指标的选择，要根据自己团队的实际情况来。不要一下子度量太多指标，那样会眼花缭乱，抓不住重点。先把DORA四大指标度量起来，然后再根据需要，逐步增加其他指标。而且，度量指标的目的，是为了发现问题，持续改进，不是为了考核，不是为了KPI。如果把度量指标变成了KPI，大家就会为了指标而工作，反而会偏离DevOps的初衷。这就像什么？就像你体检，体检的目的是为了了解自己的身体状况，发现健康问题，及时治疗和调整。不是为了和别人比指标，不是为了考核。如果为了指标好看，就弄虚作假，反而会损害健康。—# 七、DevOps的常见误区与挑战## 7.1 常见误区讲完了DevOps的度量指标，我们来聊聊DevOps的常见误区与挑战。很多团队在实施DevOps的时候，会走一些弯路，会陷入一些误区。我总结了几个常见的误区，供大家参考，避免踩坑。**误区一：DevOps就是工具。**很多人以为，DevOps就是买一堆工具，搭一套工具链，就完事了。其实不是的。工具只是DevOps的一部分，不是全部。DevOps更重要的是文化、理念、流程、实践。没有相应的文化和流程，工具再厉害，也发挥不出作用。比如，你买了最先进的CI/CD工具，但是开发人员还是不写自动化测试，还是不频繁提交代码，还是手工部署，那这个工具就白买了。所以，实施DevOps，要文化、流程、工具一起抓，三者缺一不可。这就像什么？就像你买了最好的画笔、颜料、画布，但是你不会画画，没有艺术细胞，还是画不出好画。工具只是基础，更重要的是使用工具的人，以及人的思想和能力。**误区二：DevOps就是自动化。**很多人以为，DevOps就是把所有的事情都自动化，自动化构建、自动化测试、自动化部署、自动化运维，就完事了。自动化确实是DevOps的重要组成部分，但是DevOps不等于自动化。DevOps还有更丰富的内涵，比如协作文化、持续改进、快速反馈、质量内建等等。而且，不是所有的事情都适合自动化。有些事情，自动化的成本很高，收益很低，就不值得自动化。有些事情，需要人的判断和决策，就不能完全自动化。所以，实施DevOps，要合理地自动化，优先自动化那些重复的、耗时的、容易出错的工作。不要为了自动化而自动化。这就像什么？就像你家里买了扫地机器人、洗碗机、洗衣机、烘干机，把家务都自动化了。但是，做饭、照顾孩子、陪伴家人，这些事情就不能完全自动化，还是需要人来做。自动化是为了让人从繁琐的家务中解放出来，有更多时间做更有意义的事情，而不是为了自动化而自动化。**误区三：DevOps就是要快，越快越好。**很多人以为，DevOps就是追求快，部署频率越高越好，变更前置时间越短越好。为了快，可以牺牲质量。其实不是的。DevOps是既要快，又要好。DORA四大指标，两个是速度指标，两个是质量指标。精英团队，是又快又好，不是只快不好。如果为了快，牺牲了质量，线上bug很多，故障很多，那反而会更慢——因为要花很多时间修bug，处理故障，回滚版本。最后，欲速则不达。所以，实施DevOps，要速度和质量并重。在保证质量的前提下，追求速度。质量内建，在开发的每个环节都保证质量，而不是最后靠测试来把关。这就像什么？就像你开车，不是开得越快越好。开得太快，容易出事故，出了事故反而更慢。安全第一，在保证安全的前提下，合理地开快一点，才是真正的快。**误区四：DevOps是运维的事，和开发无关。**很多开发人员以为，DevOps是运维的事，是运维要搞自动化，搞部署，搞监控，和开发没关系。开发还是只管写代码，写完扔给运维就行了。其实不是的。DevOps是开发和运维的协同，是每个人的责任。开发人员也要参与到DevOps中，也要对软件的交付和运行负责。比如，开发人员要写自动化测试，要写部署脚本，要关注线上监控，要处理线上故障。不是写完代码就完事了，要对代码从开发到上线到运行的整个生命周期负责。所以，实施DevOps，要打破开发和运维的壁垒，让大家都参与进来，共同负责。这就像什么？就像一支球队，不是前锋只管进攻，后卫只管防守。前锋也要回防，后卫也要助攻，大家协同作战，共同对比赛的胜负负责。**误区五：DevOps是银弹，能解决所有问题。**很多人以为，DevOps是银弹，实施了DevOps，所有的问题都能解决——研发效率低，实施DevOps；软件质量差，实施DevOps；团队协作不好，实施DevOps；系统不稳定，实施DevOps。其实不是的。DevOps不是银弹，不能解决所有问题。DevOps主要解决的是软件交付和运维的问题，能提高交付效率，提高软件质量，提升系统稳定性。但是，DevOps不能解决所有问题，比如需求不清晰、产品设计不好、技术选型错误、团队能力不足等问题，DevOps就解决不了。而且，实施DevOps不是一蹴而就的，需要长期的投入和持续的改进。不要指望实施了DevOps，马上就能看到效果，马上就能解决所有问题。所以，实施DevOps，要有合理的期望，要循序渐进，要持续改进。不要把DevOps当成万能药。这就像什么？就像健身，健身能让你身体更健康，身材更好，精力更充沛。但是，健身不能解决所有问题，比如工作压力大、人际关系不好、经济困难等问题，健身就解决不了。而且，健身需要长期坚持，不是练几天就能见效的。## 7.2 常见挑战除了常见误区，实施DevOps还会遇到很多挑战。我总结了几个常见的挑战，以及应对方法。**挑战一：文化阻力。**这是最大的挑战。很多团队，特别是传统企业的团队，文化比较保守，大家习惯了原来的工作方式，不愿意改变。开发不愿意写测试，不愿意参与运维；运维不愿意放权，不愿意让开发部署；管理者不愿意冒险，不愿意频繁发布。应对方法：- 高层支持。实施DevOps，一定要有高层的支持和推动。高层要认可DevOps的价值，要给团队授权，要为DevOps的实施提供资源和保障。- 从小处着手。不要一开始就搞大变革，那样阻力太大。先从一个小团队，一个小项目开始，做出成效，让大家看到DevOps的好处，然后再逐步推广。- 培训和宣导。对团队成员进行培训，让大家了解DevOps的理念和价值，消除误解和恐惧。多分享成功案例，让大家有信心。- 激励机制。建立合理的激励机制，鼓励大家拥抱变化，参与DevOps。对做得好的团队和个人，给予奖励和认可。**挑战二：技术债务。**很多团队，特别是老系统，技术债务很重——代码质量差，没有自动化测试，架构老旧，部署复杂，环境不一致。这些技术债务，会严重阻碍DevOps的实施。应对方法：- 偿还技术债务。要花时间和精力，偿还技术债务。重构代码，补充自动化测试，优化架构，简化部署，统一环境。- 增量改进。不要一下子把所有技术债务都还清，那样不现实，也风险太大。要增量改进，在开发新功能的同时，顺便重构和优化，逐步偿还技术债务。- 质量内建。在开发的过程中，就要保证质量，写好代码，写好测试，做好设计。不要产生新的技术债务，一边还旧债，一边欠新债，那就永远还不清了。**挑战三：工具复杂。**DevOps的工具很多，也很复杂。很多团队，工具链搭起来了，但是太复杂，太难用，大家不愿意用，或者用不好。而且，工具之间的集成也很麻烦，数据不互通，形成了工具孤岛。应对方法：- 简化工具链。不要盲目追求工具的数量和功能，要选择适合自己的工具，简化工具链。能合并的合并，能简化的简化，让工具好用、易用。- 统一平台。尽量用统一的平台，比如GitLab，它有代码管理、CI/CD、Issue管理、Wiki等功能，一个平台就能搞定很多事情，不需要集成很多工具。- 封装抽象。对复杂的工具进行封装和抽象，提供简单易用的接口和模板。比如，把CI/CD流水线封装成模板，开发人员只需要填几个参数，就能用，不需要了解底层的复杂配置。- 培训支持。对团队成员进行工具使用的培训，提供文档和支持，让大家会用工具，用好工具。**挑战四：安全与合规。**很多团队，特别是金融、政府等行业，有严格的安全和合规要求。DevOps强调快速发布、自动化部署，这和安全合规的要求有时候会有冲突。安全团队担心，发布太快，自动化程度太高，会有安全风险，会不合规。应对方法：- DevSecOps。把安全融入到DevOps的整个流程中，实现安全左移。在代码提交、构建、测试、部署的每个环节，都做安全检查，自动化安全扫描，确保安全。- 自动化合规检查。把合规要求变成自动化的检查规则，纳入到CI/CD流水线中。每次发布，都自动进行合规检查，不通过就不能发布。这样，既保证了合规，又不影响效率。- 审计和追溯。完善审计和追溯机制，记录所有的操作和变更，谁在什么时候做了什么，都清清楚楚。出了问题，能追溯到责任人，能复盘改进。- 沟通协作。和安全团队、合规团队多沟通，多协作，让他们参与到DevOps的实施中，共同制定安全和合规的方案，而不是互相抵触。挑战五：度量与改进。很多团队，实施DevOps之后，不知道效果怎么样，不知道有没有提升，不知道哪里需要改进。没有度量，就没有改进。应对方法：- 建立度量体系。建立合理的度量体系，先从DORA四大指标开始，然后逐步增加其他指标。用数据来说话，用数据来驱动改进。- 定期回顾。定期回顾DevOps的实施情况，看看指标有没有提升，看看有什么问题，看看有什么可以改进的地方。- 持续改进。根据回顾的结果，制定改进计划，持续不断地改进。不要满足于现状，要追求卓越。- 分享最佳实践。在团队内部，在公司内部，分享DevOps的最佳实践和成功经验，让大家互相学习，共同进步。—# 八、写在最后：DevOps是一场持续的旅程写到这里，这篇文章也接近尾声了。让我来总结一下。DevOps，是Development（开发）和Operations（运维）的组合，是一种文化，一种理念，一种工作方式。它的核心是：打破开发和运维之间的壁垒，让大家协同工作，实现持续集成、持续交付、持续部署，提高研发效率，提高软件质量，提升系统稳定性。DevOps的核心实践包括：持续集成（CI）、持续交付（CD）、持续部署（CD）、基础设施即代码（IaC）、微服务与容器化、监控与可观测性、DevSecOps等等。DevOps的工具链，覆盖了软件开发生命周期的各个阶段——代码管理（Git、GitLab、GitHub）、CI/CD（Jenkins、GitLab CI、GitHub Actions）、容器与编排（Docker、Kubernetes）、配置管理与IaC（Terraform、Ansible）、监控与日志（Prometheus、Grafana、ELK Stack）等等。实施DevOps，要循序渐进，一步一步来：先评估现状，制定目标；再搭建基础工具链；然后实现持续集成；再实现持续交付；然后完善监控与可观测性；最后持续改进，文化建设。DevOps的度量，最权威的是DORA四大指标：部署频率、变更前置时间、变更失败率、服务恢复时间。这四个指标，两个衡量速度，两个衡量质量，速度和质量并重。实施DevOps，要避免常见的误区：DevOps不是只有工具，不是只有自动化，不是只追求快，不是只有运维的事，不是银弹。要应对常见的挑战：文化阻力、技术债务、工具复杂、安全与合规、度量与改进。最后，我想和大家说：DevOps不是一个项目，不是做完了就完事了。DevOps是一场持续的旅程，是一个持续改进的过程。在这个旅程中，没有终点，只有不断的进步。今天比昨天好一点，明天比今天好一点，日积月累，就会有巨大的提升。而且，DevOps不仅仅是技术和工具，更重要的是人和文化。工具会过时，技术会更新，但是协作、信任、持续改进的文化，会一直存在，会让团队不断成长，不断进步。所以，不要把DevOps当成一个一次性的任务，不要指望实施了DevOps就一劳永逸。要把DevOps融入到日常工作中，变成一种习惯，一种文化，持续不断地改进，持续不断地提升。希望这篇文章，能帮你更好地理解DevOps，更好地实施DevOps，在DevOps的旅程上走得更远、更稳。谢谢大家！—（全文完）