本篇要回答的问题：发布是事务最繁重、心智负担最大的治理环节——“变更是故障之源”。那么我们的发布哲学到底是什么？怎么用工程师思维把发布这件复杂事务彻底解决？
承接上一讲的工程师思维（系统化、产品化地 Close 问题），本讲落到服务治理的第一个具体环节——发布与升级。它不讲具体系统怎么实现，而是先确立一套可用来评估任何发布系统的发布哲学。
一次发布的典型步骤
| 步骤 | 做什么 |
|---|---|
| 构建 | 从源码仓库检出，编译出新版本目标文件 |
| 测试 | 验证新版本质量符合期望 |
| 打包 | 软件 + 配置文件等一起打包并记版本号 |
| 部署 | 更新到线上，通常需灰度而非一步全切 |
| （配置变更） | 不发新软件，仅改线上配置参数（配置文件或配置库） |
关键判断（七字箴言）：变更是故障之源。 发布事务复杂、心智负担大，要用系统化、产品化的工程师思维来对待。
发布哲学一：密闭性与可重复性
关键洞见：可重复性是核心目标，而要做到可重复就必须保证密闭性（Hermetic，即环境的完整性）。
| 概念 | 含义 | 要求 |
|---|---|---|
| 可重复性 | 同一版本反复发布无副作用 | 才能安全升级、安全回滚 |
| 密闭性（源码） | 按版本号检出的内容完整、一致、可重复 | 编译时不再额外检出外部依赖源码 |
| 密闭性（构建） | 两人在两台机器上基于同一源码构建结果相同 | 指定版本的编译器/依赖库，不受构建机已装软件影响，过程自包含 |
发布哲学二：从自动化到自服务
单次发布的自动化远远不够（发布既复杂又频繁）。为应对大规模扩张，每个团队必须自给自足：
| 角色 | 职责 | 边界（“吃自己的狗粮”） |
|---|---|---|
| 工程效率团队 | 开发发布平台/工具、制定最佳实践 | 为发布平台的效率负责 |
| 产品研发团队 | 自己掌控和执行发布流程、自定发布节奏 | 为产品负责 |
自服务的目标：发布自动化到"基本不需要工程效率工程师干预"，工程师仅在出问题时才介入。
发布哲学三：追求速度——少量发布、频繁发布
在质量保障、能力满足的前提下，发布越频繁越好：
| 角度 | 为什么要频繁发布 |
|---|---|
| 市场竞争 | 迭代速度=竞争力，甚至"测试通过即发布（Push On Green）" |
| 工程质量 | 版本间变更更小，测试、调试、定位更简单 |
关键判断：少量发布、频繁发布。并从数据驱动角度监测核心指标，例如"从代码提交到生产环境的发布速度"。
发布哲学四：重视质量，尊重流程
发布中需质量保障的环节及其审批：代码评审、批准创建发布版本、批准部署、批准配置修改。
关键洞见：只有指定的人才能执行指定操作，不能随意跳过环节；同时自动化发布系统要能整合并提供每次发布的全部改动报告（源码修改、Bug Issue、配置修改），以便出问题时快速在线调试。
配置管理：线上不稳定性的重要来源
配置管理看起来很小，却是线上不稳定的重要源头。七牛云的演进暴露了用代码仓库管配置的弊端：
| 方式 | 优点 | 弊端 |
|---|---|---|
| 代码仓库管配置 | 配置变更可跟踪、可严格评审 | 配置变更不止来自发布——线上故障（如 A 机下线迁 B 机）也引发变更，规模大后变更极频繁，应对硬件故障很拙劣 |
理想情况下硬件故障的响应应免操作。两种解法：
| 方案 | 思路 |
|---|---|
| 引入配置中心 | 把高频配置变更做进应用逻辑（"服务发现"即此思想） |
| 与物理硬件彻底解耦 | DCOS 在做的事，本质同样是把高频配置变更交给基础平台实现 |
总结
发布与升级包含构建、测试、打包、部署、配置变更五个子过程。本讲不谈具体系统实现，而是给出一套可评估任何发布系统的发布哲学：密闭可重复、自服务、少量频繁、尊重流程、管好配置。发布事务工作量大，工程师思维（系统化彻底解决）是关键支撑。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 变更是故障之源 | SRE 七字箴言，发布需极度谨慎 |
| 密闭性（Hermetic） | 环境完整性，源码与构建都自包含、可复现 |
| 可重复性 | 同版本反复发布无副作用，是安全升级/回滚的前提 |
| 自服务 | 团队自给自足发布，工程师仅出问题时介入 |
| Push On Green | 测试通过即发布 |
| 配置中心 / 解耦 | 把高频配置变更做进应用逻辑或交给 DCOS 平台 |
一句话速记
变更是故障之源——所以发布要做到密闭可重复（能安全回滚）、自服务（团队自治）、少量频繁（变更更小更好查）、尊重流程；而配置管理才是线上不稳定最隐蔽的源头。
几条值得记住的判断
- 可重复性靠密闭性保证：源码与构建都必须自包含、可复现。
- 少量发布、频繁发布比攒大版本更安全。
- 配置变更不止来自发布，故障引发的变更才是规模化后的大头。
思考题
文中说"硬件故障的响应应该是免操作的"。回到你的系统：当一台机器故障下线时，恢复服务需要人去改配置吗？如果需要，这部分高频变更能否下沉到配置中心或基础平台，从而真正做到免操作？
