管理持续交付

一句话

这是《持续交付》全书唯一一章不讲技术的：前十四章把部署流水线（deployment pipeline）造了出来，这一章讲怎么把它推进一个真实组织。它交出三件东西——一张按六个实践域展开的成熟度模型（maturity model）用来定位短板、一条把运维与合规提到最前的项目生命周期、一套把风险管理落成具体提问的清单——并给出全书最反直觉的主张：面对审计与合规，自动化比文档更有说服力。

Glossary · 术语表

坐标

本章是 Part III「交付生态」的收官，也是全书结尾：上承 Ch13（组件与依赖）、Ch14（版本控制）这些工程细节，把话题从「怎么造」拉回「怎么推行」。它对应现实里最常见的一类处境——一家已经装了 CI 服务器、测试也在自动跑，却仍然一个季度才发一次版的中大型企业。

这章要解决什么

流水线是技术物件，放行却是组织决定。前十四章的所有实践，最终都要穿过一道非技术的闸门：谁批准、凭什么证据批准、出事谁负责。这一章处理的就是技术实践与组织现实之间的那道落差。

不解决会怎样？书里点到三种典型烂尾：

• 流水线沦为摆设——持续集成天天在跑，上线还是手工清单加周末窗口，自动化只覆盖了最便宜的那一段。
• 改进四处开花、哪也没进展——测试自动化、环境标准化、数据库迁移、监控体系同时上马，半年后每项都做了三成。
• 合规越管越紧——运维与审计只在最后一刻被叫进来，唯一能做的就是加签字；于是批次更大、间隔更长、风险更高，下次更不敢发。

给个量级锚：传统企业一次「大版本」发布窗口常是 4–8 小时、20 人以上、排在周六凌晨，外带一份几十上百步的手工清单；按本书标准做到位的团队，一次部署是分钟级、由提交自动触发、单人即可。差的是两三个数量级，不可能靠「大家再细心一点」补上。

核心内容，讲透

成熟度模型：六条实践线 × 五个格子

是什么：一张 6×5 的网格。六个实践域是构建与持续集成、环境与部署、发布管理与合规、测试、数据管理、配置管理；五个级别从低到高是 −1 退化（流程不可重复、被动救火）、0 可重复（有文档、部分自动化）、1 一致（自动化覆盖整个生命周期）、2 可量化管理（流程被度量与控制）、3 优化（持续改进流程本身）。

直觉：它不是给公司打一个总分，而是六张体检单。真实团队几乎从不在一条水平线上——很可能构建已经到了 1 级，而「环境与部署」还在 −1 级：生产环境是历年手工改出来的，没人敢重建。

机制：如实在每条线上标一个点，连成锯齿线，然后从最靠左的那条开始改，一次只推一格。

为什么这样设计：交付能力受最弱环节约束——测试再自动化，只要环境还得手工搭，前置时间仍然按天算。「一次一格」则是为了让每次改进在几周内就能看到指标变化，避免三年规划式的转型。代价很明确：成熟度模型天生招人打分排名，书里自己就警告过——它是找下一步的地图，不是发奖状的成绩单。

项目生命周期：把运维与合规提到最前

本章把一个项目拆成五段：识别 → 立项 → 启动 → 开发与发布 → 运营。真正的主张不在分段本身，而在谁在什么时候在场：传统做法里运维、测试、安全、DBA 是被「交接」到的下游；本章要求他们从立项起就在同一张桌子上，并且在「启动」阶段——一行业务代码都还没写的时候——就把部署流水线和类生产环境先搭起来，让第一个能端到端跑通的「骨架」尽早上线。

为什么：最贵的返工几乎都来自环境差异与非功能需求（容量、安全、可运维性）。这两类问题留到发布前夜才暴露，修它意味着改架构；在启动阶段暴露，往往只是改一个配置。把流水线当作项目的第一个交付物，本质上是把这类风险从项目末尾搬到开头。

风险管理：提前问对问题，而不是写更厚的文档

本章把风险管理去神秘化：它不是一份风险登记册，而是在固定时点向交付团队提一组具体问题。那组问题大致长这样：

• 我们怎么知道「做完了」？验收标准写在哪、由谁来判？
• 谁有权部署到生产？部署一次要几个人、多长时间？
• 回滚要多久？上一次真的回滚过是什么时候？
• 测试环境与生产的差异清单有多长？环境是脚本生成的，还是人手工改出来的？
• 从一次提交到它跑在生产上，平均要多久？

判据很朴素：这些问题答不上来或答案含糊，风险就在那里——文档写多厚都不改变事实。本章还把几类常见交付问题归了因（见下表 2），共同点是：症状都在发布那天爆发，病根都埋在更早的地方。

合规与审计：用自动化取代文档

这是全章最该记住、也最反直觉的一节。审计真正想要的其实是三件事：可追溯（生产上跑的每个制品能回溯到一次提交和一个工单）、不可绕过（没有人能跳过既定流程把东西放上生产）、可复现（环境与配置能被重建）。

传统做法用文档和签字提供这三件事，但一个签好的字只证明「有人签过」：它既说不出线上那个二进制究竟是哪次构建的产物，也拦不住有权限的人绕过流程直接改生产。流水线给的更硬——每个制品带着构建号与提交号、每个阶段的通过记录自动入库、每次生产部署留下「谁、何时、哪个产物」。证据是机器在正常干活时顺手产生的，不是事后补的。

职责分离在这套做法下并没有被取消，而是换了实现方式：不是「开发不许碰生产」，而是没有人能绕过流水线——放行动作变成对流水线上某个按钮的授权，按下去的人、时间、对象全部留痕。书里对 CAB 的批评也落在这里：定期开会、靠几页幻灯片审批一批自己并不熟悉的变更，审批者既没有能力也没有信息去判断技术风险，这道闸门买到的是延迟，不是安全。

关键权衡与选型

表 1 · 四种「放行」模式：谁批、多久、审计拿到什么、代价是什么

表 2 · 四类常见交付问题：症状在发布日，病根在更早的地方

为什么重要 / 落到真实系统

本章 2010 年写下时，这些主张多半还是从项目经验里提炼的断言。2014 年起，DORA（DevOps Research and Assessment）用连续多年的大规模问卷，把其中几条变成了统计结论——这条线后来结集成《Accelerate》（本站已有精读），可以看作本章的实证延长线。

落到今天的工具：GitHub Actions / GitLab CI / Argo CD 里的「环境保护规则 + 必需审批人 + 部署历史」，几乎就是本章那套「授权按钮 + 全链留痕」的工业化实现；SOC 2、ISO 27001 审计中被广泛接受的证据形式，也正是流水线记录而非手工表格。

易错点与争议

• 成熟度模型最大的风险是变成打分游戏：一旦和考核挂钩，团队会去优化分数而不是优化交付。书自己就提醒它是地图，不是成绩单。
• 「自动化取代文档」不等于免除控制：在金融、医疗、航空这类强监管领域，控制点一个都不会少，变的只是证据形式——从签字页换成机器留痕。想当然地砍掉审批环节，审计不会买账。
• 时代局限：本书写于 2010 年，早于容器、基础设施即代码与云上按需环境。当年「环境与部署」是最难爬的一条线，今天门槛低了一个量级；也正因如此，组织侧的阻力占比反而更高——技术借口没了。
• 对 CAB 的批评当年只是经验之谈，要到 2018 年前后才有大规模数据支持；而数据支持的是「重量级外部审批无效」，不是「不需要任何变更管理」——清晰、轻量、发生在团队内部的审批仍然有效。
• 别把持续交付当成一次工具采购：装了 CI 服务器不等于做了持续交付。这一整章的存在本身就是在说这件事。
• 高频部署不是普适目标：嵌入式固件、医疗器械、卫星软件这类场景，部署频率受物理与监管约束。此时该从本章拿走的是可追溯、可复现、快速反馈，而不是「一天上线十次」。

要点