发布、升级与版本管理

章节导言：变更——故障的第一大根源

在服务治理的宏观视角中，我们指出故障的三大根源为：软硬件升级与配置变更、软硬件环境故障、终端用户请求。其中，软硬件升级与配置变更是故障的第一大问题源头。

发布、升级与版本管理看似是一个工程效率问题，但从服务治理的角度看，它本质上是一个风险控制问题——如何在持续交付业务价值的同时，将变更引入的风险降到最低。

版本管理的基础是版本号语义。语义化版本（Semantic Versioning）是行业标准：

text

MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]

版本段	含义	变更规则	兼容性影响
MAJOR	主版本号	不兼容的 API 变更	破坏性变更
MINOR	次版本号	向后兼容的功能新增	不影响现有行为
PATCH	修订号	向后兼容的问题修复	纯修复，无新功能
PRERELEASE	预发布标识	alpha / beta / rc	不保证稳定性
BUILD	构建元数据	构建编号 / commit hash	不影响优先级

图表渲染中…

一个完整的发布流程包含以下关键环节，每个环节都承担着风险过滤的职责：

图表渲染中…

灰度发布是降低变更风险的核心手段。常见的灰度策略包括：

图表渲染中…

版本的兼容性管理是大型系统中极具挑战性的课题。核心原则：

服务端 API 兼容性的特殊挑战：客户端可以强制升级，但服务端 API 的消费者往往不可控。因此服务端 API 的变更必须遵循更严格的兼容性纪律——接口只增不改不删。

策略	逻辑	适用场景
高频小批量	每次变更小，风险低，回滚快	互联网产品、SaaS
低频大批量	集中发布，测试充分，但单次变更量大	传统企业软件、嵌入式系统

核心洞察：发布频率越高，每次发布的风险越低。这不是反直觉的——每次变更越少，引入缺陷的概率越小，回滚的代价也越低。持续交付的本质不是"更频繁地发布"，而是"让每次发布变得足够安全，从而敢于更频繁地发布"。

合理策略：低风险变更自动化，高风险变更人工确认。风险等级由变更影响面和回滚难度决定。

当线上出现问题时，有两种选择：

策略	优点	缺点
回滚	恢复速度快	丢失已上线功能
前进修复	不丢失功能	修复速度不确定

最佳实践：优先回滚恢复服务，再择机修复。 保证回滚能力是发布系统的底线要求。

将大量功能集中在一个大版本中发布。看似"测试更充分"，实则：

Google 的发布工程（Release Engineering）团队建立了一套完整的发布基础设施：

很多团队对代码发布有严格的流程，但对配置变更（如开关翻转、参数调整）缺乏管控。配置变更与代码变更一样属于"变更"，必须纳入同样的灰度和回滚流程中。

数据库 schema 变更是发布中最棘手的问题之一。标准做法：

每个阶段都是一次独立发布，每次只做一件事。

交叉引用：发布引发的故障检测见第50讲，故障恢复与预案见第51讲，工程师思维在发布系统中的体现见第48讲。