DevOps运维开发实战指南

DevOps 运维开发实战指南：一次发布的完整旅程

导读：这本教程不按"概念、工具、流程"的词典顺序讲 DevOps，而是跟着一次真实的代码提交走完它的发布旅程——从开发者敲下提交的那一刻起，经过构建、测试、部署、监控，直到异常发生时的回滚与复盘。CI/CD 流水线是贯穿全册的主线，每一站解决旅程中的一个真实问题。

这本教程怎么读

传统的 DevOps 教材像一本工具目录：先讲定义，再列八大实践，然后罗列几十个工具。读完记住了名词，真到凌晨两点线上告警炸响的时候，还是不知道该按哪个按钮。问题不在读者，在于知识没有被组织成"可以走一遍的路线"。

所以我们换一种组织方式。想象你是一名刚加入某互联网公司平台组的工程师，周一上午十点，你把一段修改数据库连接池的代码推送到了远端仓库。接下来的几个小时里，这段代码会经历什么？谁替它跑测试？它怎么变成一个可以部署的制品？它先去哪个环境、后去哪个环境？谁来决定它能不能上生产？上了生产之后，谁盯着它？如果它把服务搞挂了，怎么救回来？

这一连串问题，就是全册的暗线。CI/CD 流水线是主线骨架，DevOps 的理念、实践、工具、度量，全都挂在旅程的相应站点上。你在第 2 章会看到这次提交如何触发持续集成，在第 3 章看它如何晋升到测试环境、预发环境，在第 4 章看它上线后被监控系统和日志系统盯梢，在第 6 章回头看这次发布的所有数据——部署花了多久、失败率多少、恢复用了几分钟。

发布之旅全景图

图里这条路线不是理论模型，是绝大多数成熟工程团队每天都在跑的循环。全册六章恰好对应旅程的不同区段。

各章内容与旅程的对应关系

第 1 章是出发前的装备检查。 讲清楚 DevOps 到底是什么、不是什么。它不是"开发兼做运维"，也不是"买一套 Jenkins 就算完成"，而是一组围绕"让代码更快、更安全地到达用户手中"的原则与文化。这一章解释了为什么旅程要这样设计：为什么小批量提交比大批量发布安全，为什么反馈越早越便宜，为什么 Blameless 复盘比追责会议更能降低故障率。

第 2 章是旅程的第一站：从代码提交到持续集成。 你的那次推送会触发什么？版本控制与分支策略决定了"谁的代码、什么时候、以什么顺序进入主线"；持续集成决定了合并之后几分钟内能否得到"这版代码能不能编译、测试过不过"的答案；自动化测试金字塔决定了答案本身可不可信。这一章有真实的流水线配置片段、真实的失败日志和修复过程。

第 3 章是第二站：持续交付与环境管理。 测试通过的代码变成制品之后，它要去的地方——测试环境、预发环境、生产环境——必须足够相似，否则"测试环境好好的"这句话毫无意义。基础设施即代码和配置管理解决的就是"环境不能靠手搓"的问题。蓝绿部署、金丝雀发布这些让部署变安全的手段也在这一章。

第 4 章是第三站：上线运行与安全守护。 发布不是终点。监控与日志是这次旅程的"行车记录仪"，DevSecOps 把安全检查点嵌进旅程的每一站而不是等到上线前才扫描，协作与沟通则决定了出事时一群人能不能高效地围上来。凌晨两点告警响起的场景，会在这一章正面描写。

第 5 章是第四站：工具链全景与选型。 旅程的每一站都有工具在工作，这一章把它们拼成一张完整的地图——从 Git、Jenkins、GitLab 到 Docker、Kubernetes、Ansible、Prometheus，讲清楚工具之间的衔接关系，也讲清楚选型时最容易踩的坑：先选工具再想流程，是无数团队 DevOps 转型失败的起点。

第 6 章是终点，也是新的起点。 用生命周期模型和流程设计把整段旅程串起来，用部署频率、变更前置时间、变更失败率、平均恢复时间这四个关键指标量化旅程的质量，最后讲组织如何真正完成 DevOps 转型。度量会告诉你：你的团队走完这段旅程的平均速度，比业界精英团队慢在哪里。

这本教程写给谁

写得最用心的读者画像有三种。第一种是工作一到三年的后端或运维工程师，天天听说 CI/CD 但对"流水线背后到底发生了什么"只有模糊印象，读完能独立搭建并维护一条完整的发布流水线。第二种是技术管理者，需要判断团队该往哪个方向投入，第 6 章的度量体系和第 5 章的选型方法可以直接用于决策。第三种是准备系统学习的在校学生，建议不要跳章——旅程的站点顺序本身就是知识依赖顺序。

阅读不需要你先精通任何具体工具，但假定你写过代码、用过命令行、大致知道"服务器"和"环境"指的是什么。每一章的支柱页都标注了前置知识，如果某站觉得吃力，回头补对应章节即可。

学习建议：动手走一遍

只读不练，这段旅程对你而言永远是他人的游记。建议准备一台云主机或本地的虚拟环境，跟着第 2、3 章的示例搭一条最小可用的流水线：一个 Git 仓库、一份流水线配置、一个容器化的示例应用、一个模拟的生产环境。全册出现的配置片段都刻意保持了可直接抄写验证的完整性——它们不是伪代码。

另外提醒一点心态：DevOps 的核心矛盾永远是"快"与"稳"。教程里每一处工程取舍，本质上都在回答"这次变更值得多快、需要多稳"。工具和配置只是手段，判断力才是你真正的收获。愿你读完之后，下一次提交代码时，能清楚地看见它即将踏上的整段旅程。

一句话概括这本教程：让每一次代码提交，都成为一次安全、可观测、可回滚、可改进的发布之旅。