无论是深夜被夺命连环 call，还是眼睁睁看着用户反馈铺天盖地而来，那种感觉，相信大家或多或少都体验过。

当我们不幸经历了一次「刻骨铭心」的线上故障。痛定思痛，除了常规的复盘，我们也许要从一个更系统、更底层的视角，和团队的同学一起探讨：故障，究竟为何而来？我们又该如何防微杜渐？

今天，我们聊下安全管理领域的「老法师」——海恩法则（Heinrich’s Law），以及它的一众「智慧亲友团」。

海恩法则：事故背后的「1:29:300」金字塔

海恩法则的来历

海恩法则由美国工业安全先驱赫伯特·威廉·海因里希（Herbert William Heinrich） 在上世纪30年代提出。他在为保险公司工作时，通过分析数千份工伤事故报告，总结出了这个惊人的规律。最初应用于工业安全领域，但其揭示的事故发生规律具有普遍性，早已跨界影响到航空、医疗、乃至我们软件工程等多个领域。

海恩法则指出：

在一件重大的事故背后，平均有 29 次轻微事故，以及 300 个无伤害的隐患或未遂事件。

这个法则通常以 1:29:300 的金字塔比例来形象展示。

海恩法则的核心思想

1. 事故是可以预防的：严重事故并非天降横祸，而是此前一系列小问题和风险累积、演变的结果。如果我们能有效管理「29」和「300」，就能大概率避免「1」的发生。
2. 重视「未遂先兆」：那 300 个「隐患」和 29 个「轻微事故」是重大事故的「报警器」。忽视它们，就等于给灾难开了绿灯。很多时候，我们只关注已经发生的「1」，却对冰山下的「29」和「300」视而不见。
3. 安全管理需系统化：事故的发生往往与管理体系的漏洞、流程的缺陷、安全文化的缺失等系统性问题相关。预防事故需要从整个系统的角度出发，进行持续改进。

海恩法则的应用实例

• 工业生产：工厂通过定期的安全检查、员工安全行为规范、隐患上报奖励等机制，主动排查和消除那「300 个隐患」，处理「29 起轻微事故」，从而避免重大生产安全事故。
• 航空安全：每一次飞行前的详细检查、飞行员的严格培训、对飞行过程中任何微小异常的记录与分析，都是海恩法则的体现。一个螺丝的松动（隐患）如果不被发现，可能导致部件故障（轻微事故），极端情况下甚至引发空难（重大事故）。
• 医疗安全：医院对用药错误、手术流程中的小差错等「未遂事件」进行记录和分析，改进流程，以防止严重的医疗事故。

对于线上故障，海恩法则给我们的启发与教训

海恩法则对于我们维护线上系统稳定性，尤其是复杂的线上应用，具有极其深刻的指导意义。

教训与经验借鉴：

1. 「小问题」绝不小觑：线上一个偶发的 null 指针异常、某个非核心接口超时频率略增、用户反馈的一个「不太影响使用」的小 Bug，都可能是「29」或「300」的信号。如果仅仅是临时「hotfix」或者因为优先级不高而搁置，这些「小债」累积起来，迟早会引发“大雷”。
2. 「未遂」也是宝贵数据：一次灰度发布中发现的问题并回滚、一次压力测试暴露的瓶颈、一次配置错误在生效前被发现……这些都是「未遂事件」。它们暴露了流程或系统中的薄弱环节，是改进的绝佳机会，不能因为「没出事」就庆幸了事。
3. 故障复盘不能止于表面：发生故障后，不能仅仅定位到直接原因（比如某行代码写错了），更要深挖根本原因：为什么这行错误的代码能上线？测试为何没发现？Code Review 为何遗漏？发布流程是否有问题？这才是触及「300个隐患」层面的思考。
4. 建立「隐患上报」的文化：鼓励团队成员主动暴露系统中的潜在风险、不合理的设计、流程上的缺陷，即使这些问题短期内没有引发故障。要营造一个「说出问题是贡献」的安全文化氛围。

哪些算作「轻微事故」和「隐患」？线上 BUG 怎么算？

• 300 个隐患 – 系统中的「定时炸弹」：

  • 技术债：过时的库、临时的硬编码、缺乏注释的复杂代码、糟糕的架构设计。
  • 配置风险：配置项繁多且缺乏校验、配置管理混乱、关键配置依赖人工操作。
  • 监控盲区：核心业务指标未监控、告警阈值不合理、日志信息不全或格式混乱。
  • 测试覆盖不足：单元测试覆盖率低、缺乏有效的集成测试和端到端测试、对异常场景和边缘 Case 考虑不周。
  • 流程缺陷：发布流程不规范、变更管理随意、缺乏应急预案或预案未演练。
  • 知识断层：核心模块只有少数人懂、文档严重滞后或缺失。
  • 不规范的操作习惯：随意在线上环境执行高危操作、密码弱口令或共享。
  • 线上 BUG，未直接造成服务中断或核心功能严重受损的：例如，某个页面的 UI 显示错位、某个非核心功能的计算结果在特定条件下不准确但用户感知不强。这些 BUG 本身是问题，也是系统脆弱性的体现，属于「隐患」范畴，若不修复，可能在特定条件下与其他因素叠加，引发更严重问题。

• 29 次轻微事故 – 系统发出的「黄牌警告」：

  • 短暂的服务抖动：例如，某个服务实例重启导致短时间部分请求失败。
  • 部分功能不可用或性能下降：例如，图片上传功能暂时失败、某个 API 响应时间飙升但未完全超时。
  • 告警频繁触发但能自动恢复：例如，CPU 使用率短时超阈值后回落。
  • 线上 BUG，已造成用户可感知的、轻微的功能异常或体验下降：例如，用户无法修改头像、搜索结果排序偶现不符合预期但仍可使用。这类 BUG 已经对用户产生了一定影响，属于轻微事故。
  • 资源超限警告：数据库连接池满、磁盘空间接近阈值。

• 1 次重大故障 – 系统「拉响红色警报」：

  • 核心服务长时间中断。
  • 大面积用户无法使用核心功能。
  • 数据丢失或严重损坏。
  • 造成公司声誉或经济重大损失。

哪些指标能帮我们「看到」冰山？

有效的监控和度量是发现「29」和「300」的关键。以下一些指标可以帮助我们感知系统的健康状态：

• 线上 BUG 数量与趋势：

  • 新增 BUG 数/解决 BUG 数：反映研发质量和修复效率。
  • 遗留 BUG 数量与等级分布：高等级 BUG 积压是重大风险。
  • BUG 平均解决时长 (MTTR for bugs)。
• 代码质量指标：

  • 圈复杂度：高圈复杂度的代码往往难以理解和维护，是潜在的 BUG 温床和隐患。持续监控圈复杂度的变化趋势，对超标模块进行重构。
  • 代码重复率。
  • 静态代码分析告警数。
• 系统稳定性与性能指标：

  • 服务可用性 (SLA/SLO)。
  • 错误率：API 错误率、特定业务操作错误率。
  • 平均响应时间 (Average Response Time) 与分位值 (e.g., P95, P99)。
  • 资源利用率与饱和度：CPU、内存、磁盘I/O、网络带宽、数据库连接池等。
• 变更与发布相关指标：

  • 变更成功率。
  • 因变更引发的故障数。
  • 发布频率 (高频健康的发布是敏捷和稳定的体现，但需质量保障)。
• 告警与事件指标：

  • 告警数量与级别分布：过多低价值告警会造成“告警疲劳”。
  • 平均故障检测时间 MTTD
  • 平均故障恢复时间 MTTR

海恩法则的「亲友团」：这些智慧异曲同工

海恩法则并非孤军奋战，在安全管理和系统思维领域，还有许多理论与它遥相呼应，共同构成了我们理解和应对风险的知识体系：

1. 墨菲定律：「凡事只要有可能出错，就一定会出错。」 它提醒我们不要抱有侥幸心理，任何潜在的风险点都可能在某个时刻爆发。

2. 多米诺理论：同为海因里希提出，认为事故的发生像一连串倒下的多米诺骨牌，由五个阶段（社会环境/遗传因素 -> 人的失误 -> 不安全行为/条件 -> 事故 -> 伤害）连锁引发。切断其中任何一环，特别是「不安全行为/条件」，就能阻止事故。

3. 冰山理论：事故的直接损失（如设备损坏、人员伤亡）只是冰山一角，水面下隐藏着更大的间接损失（如生产延误、声誉受损、员工士气低落等）和深层原因（管理缺陷、安全文化缺失）。与海恩法则的 1:29:300 有异曲同工之妙。

4. 帕累托法则 80/20 法则：大约 80% 的事故是由 20% 的原因造成的。这提示我们要集中资源解决那些最关键的风险点和隐患。

5. 鲍尔法则：系统越复杂，发生重大事故的概率越高。这警示我们在设计和维护复杂系统（如AIGC应用）时，要格外关注风险的累积和扩散。

6. 「四不放过」原则：事故原因不查清不放过、责任人未受到处理不放过、整改措施未落实不放过、相关人员未受到教育不放过。这是事故后处理的铁律，确保从错误中学习，防止重蹈覆辙。

7. 瑞士奶酪模型：由詹姆斯·里森（James Reason）提出。系统有多道防线（如代码规范、测试、监控），每道防线都像一片瑞士奶酪，上面有孔洞（缺陷）。当所有孔洞恰好对齐时，风险就会穿透所有防线，导致事故。这强调了单一防线的不足和多层防御的重要性。

8. 破窗效应：环境中一个未被修复的「破窗」，会暗示这里无人管理，从而诱发更多的混乱和破坏。对应到系统中，一个小 BUG、一个不规范的操作长期被容忍，会逐渐侵蚀团队的质量意识和纪律，最终导致大问题。

从「救火」到「防火」：我们的系统性行动指南

理解了这些法则和理论，我们不能仅仅停留在「哦，原来如此」，更要将其转化为行动，从根本上提升系统的稳定性和韧性。

1. 拥抱「小题大做」文化：对每一个「29」和「300」保持高度警惕，建立快速响应和彻底解决的机制。
2. 建立并严格执行「故障复盘」机制：深入挖掘根本原因，落实改进措施，并跟踪效果，形成闭环。
3. 强化「可观测性」建设：完善日志、指标、追踪体系，让系统的每一个角落都“透明可见”。利用好我们前面提到的各项指标。
4. 投资于「看不见的角落」：积极偿还技术债，优化系统架构，完善自动化测试，加强代码审查，推广混沌工程等。
5. 提升团队的「风险意识」与「系统思维」：让每个人都成为系统安全的守护者，理解自己的工作如何影响全局。
6. 持续演练，常备不懈：完善应急预案，并定期组织真实场景的故障演练，提升团队应急响应能力。
7. 数据驱动，持续改进：利用收集到的指标数据，分析趋势，识别瓶颈，指导我们的优化方向。例如，如果线上 BUG 数持续在高位，或圈复杂度高的模块频繁出问题，那就是明确的改进信号。

写在最后

线上系统的稳定性，是一场没有终点的马拉松，也是一场与熵增（系统混乱度增加的自然趋势）的持续对抗。故障不可怕，可怕的是从故障中一无所获，反复在同一个地方跌倒。

希望海恩法则和它的「亲友团」能像一盏盏明灯，照亮我们系统中的每一个阴暗角落，指引我们关注那些微小的信号和潜在的风险。通过系统性的思考、数据驱动的决策和持续不懈的改进，我们一定能逐步减少重大故障的发生，为用户提供更稳定、更可靠的服务。

以上。

我将整个复盘报告输入给到 chatGPT，其给我的回复如下：

从语雀的这次事故中，我们可以学到以下几个关键的教训：

1. 重视运维工具的测试和质量保证：在这次事故中，新的运维升级工具的 bug 是导致故障的主要原因。这说明，即使是运维工具，也需要进行足够的测试和质量保证。在实际使用之前，应该在相似的环境中进行充分的测试，确保其稳定性和安全性。
2. 灾备和恢复系统的重要性：即使有了数据备份，恢复仍然可能需要花费大量时间，这会导致服务中断时间过长。因此，除了定期备份数据外，还需要建立有效的灾备和恢复系统，以便在灾难发生时，能够快速恢复服务。
3. 灾难恢复演练的必要性：定期的灾难恢复演练可以帮助我们在真实的灾难发生时，更快地恢复服务。通过演练，我们可以发现并解决恢复过程中可能存在的问题，提高恢复的效率。
4. 高可用架构的重要性：高可用架构可以保证在部分系统组件发生故障时，整个系统仍能继续运行。在这次事故中，由于存储系统的故障，导致了整个服务的中断。如果有高可用架构，即使某个组件发生故障，也可以通过其他的组件提供服务，从而减少服务中断的可能性。
5. 灾难通信的重要性：在灾难发生后，应该及时向用户通报情况，说明故障的原因，修复的进度，以及预计的恢复时间。这样可以增加用户的信任度，减少用户的不安。在这次事故中，语雀做了很好的灾难通信，及时向用户报告了故障的详情，以及修复的进度。
6. 持续改进和学习的重要性：每次故障都是一次学习的机会。通过分析故障的原因，我们可以找出问题，改进系统，避免类似的故障再次发生。在这次事故中，语雀提出了一系列的改进措施，这表明他们有持续改进和学习的意识。

但是从复杂系统的角度来看这个事件：复杂系统的性质使得它们在面临故障时，能够以我们意料之外的方式表现出来。尽管我们可能已经在设计和实施阶段做了很多工作来确保系统的稳定性，但是在实际运行中，仍然会出现我们没有预见到的问题。

高尔在讨论复杂系统时提到：「具备故障防备能力的系统出故障的原因恰恰就是故障防备能力的失灵」。这是因为在设计防备系统时，我们往往会基于我们对系统的理解来设计，但是实际上，系统的行为可能会超出我们的理解范围。当系统的行为超出我们的预期时，我们的防备措施就可能会失效。

这与这次语雀服务故障的情况非常相似。尽管语雀设计了一套备份恢复机制，但是在实际的故障中，由于对系统的理解不足，这套机制并没有发挥出应有的效果，反而延长了恢复时间。

在许多情况下，一些复杂系统的故障并不是单一的、孤立的事件，而是由一系列的因素相互作用、相互影响的结果。这通常包括了系统设计、运维策略、人为错误等多个方面。

具备故障防备能力的系统，其设计和运营目标是提供连续、稳定的服务，即使在面临内部错误或外部攻击等影响时也能持续运行。这种系统通常包含冗余的组件、自动故障切换机制、灾难恢复策略等措施，以保证系统的正常运行。

然而，这些故障防备能力本身可能成为系统故障的源头，原因可能有以下几点：

1. 复杂性：故障防备能力会增加系统的复杂性，复杂性本身就可能带来故障。例如，冗余的组件需要保持同步，如果同步机制出现问题，可能导致数据不一致，进而产生故障。

2. 人为错误：故障防备能力的维护和操作需要人工参与，人为操作错误可能导致防备能力失灵。如语雀故障案例中，运维工具的 bug 就是人为因素导致的。

3. 预期和实际的差距：故障防备能力的设计和实施都是基于对可能故障的预期，但实际发生的故障可能超出了预期，导致防备能力无法应对。

面对一个每天都在演化的复杂系统，我们应该做些什么呢？

面对复杂，我们第一个能想到的原则应该就是 KISS 原则了。

「KISS」 原则是 「Keep It Simple, Stupid」 的缩写，这是一种广泛应用于工程、设计和决策过程中的设计原则。其最主要的理念就是保持事物的简单性。

KISS 原则主张：

• 避免不必要的复杂性
• 优先选择简单、清晰和直观的解决方案
• 不要添加不必要的特性或功能
• 简单的设计更易于维护、理解和修改

这个原则并不是说所有的事物都必须以最简单的方式来完成，而是鼓励我们在设计和决策过程中，优先考虑最简单和最直接的方法，除非有充分的理由去选择更复杂的方案。

简单性是一个非常重要的设计目标，因为它可以降低错误的可能性，提高系统的可靠性，减少维护的难度，提高效率，以及其他许多好处。

我们如果应用了以下的一些建议，应该可以往 KISS 原则靠近一些：

1. 明确需求：首先明确我们试图解决的问题是什么。这有助于避免在设计和实现过程中添加不必要的功能或复杂性。

2. 简化设计：在设计过程中，始终问自己是否可以把事情做得更简单。避免过度设计，只实现真正需要的功能。

3. 模块化：把大问题分解成小问题，每个小问题都可以用简单的方式解决。这样，每个模块都保持简单，而整个系统则由这些简单模块组成。

4. 避免不必要的优化：过早的优化可能会增加复杂性。除非确定优化会带来显著的好处，否则最好先实现功能，然后再考虑优化。

5. 使用已有的解决方案：如果有已经存在的工具或库可以满足我们的需求，那就使用它，而不是从头开始创建。这样可以降低复杂性，同时节省时间。

6. 代码和设计的清晰性：代码应该易于理解，设计应该直观。这不仅提高了可维护性，也让其他团队成员更容易理解你的工作。

7. 定期回顾和重构：随着时间的推移和需求的变化，我们可能需要调整或简化现有的设计。定期回顾我们的代码和设计可以帮助我们找出可以简化的地方。

作为一个技术管理者应该作些什么呢？我认为最应该做的是拒绝那些让系统变得复杂的不合理需求，守好技术实现的大门。

面对复杂系统，我们需要对系统有深入的理解，尽可能地简化系统，避免不必要的复杂性。通过模块化设计，将复杂系统分解为相对独立的部分，每个部分都可以单独理解和测试。并且设计出健壮的错误处理和恢复机制，同时也需要进行持续的监控和回顾。只有这样，才能提升系统的稳定性，减少服务中断的可能性。

2018 年 10 月 31 日 GitHub 通过官方博客发布了 2018 年 10 月 21 日「挂掉」的事件分析。GitHub 指出此次事件发生的原因是在 10 月 21 日 22:52UTC 进行日常维护——更换发生故障的 100G 光学设备时导致美国东海岸网络中心与美国东海岸数据中心之间的连接断开。更具体地 GitHub 分析，虽然两地的连接在 43 秒内恢复，但这次短暂的中断引发了一系列事件，这才导致了长达 24 小时 11 分钟的服务降级。

2020 年 7 月，Cloudflare 的 DNS 服务遭受了大规模的中断，影响了许多依赖其服务的网站。该故障的原因是 Cloudflare 的路由器中的一个错误配置。

以上是在网上搜索各大平台的故障描述，可以看到这些故障都是由于生产环境的变更导致的，有些是网络设备变更，有些是配置变更，有些是维护人员在线上执行了某个操作…… 如此种种。

这些问题最终都是开发人员通过系统化的建设，一个坑一个坑的填完了，但是当我们带着一个团队急速前进时，可能来不及做这些系统化的建设，此时通过流程对生产环境的变更进行管理，快速解决或规避一些问题以控制线上故障的出现。流程能保证的是我们做事的下限。

在做生产环境变更管理流程之前一定要明晰生产环境的概念和范围，在团队内达成共识，然后再去做流程，以规避因为对生产环境的概念和范围不一致，导致的误解和乌龙。

1 生产环境的概念

生产环境，也称为「产品环境」或「线上环境」，是指实际运行并对外提供服务的环境。这个环境中的软件版本、配置和数据都应该是最新的、经过充分测试的，以保证系统的稳定性和性能。线上环境需要提供24小时不间断的服务。

一个应用或环境是否属于线上环境，主要取决于它是否直接对外提供服务。例如，如果一个应用接收并处理来自最终用户的请求，那么它就是线上环境的一部分。同样，如果一个环境中的数据被用于生产服务，那么这个环境也应该被视为线上环境。

通常，生产环境包括以下 4 个部分：

• 硬件资源：例如服务器、网络设备、云服务中的硬件部分等；
• 软件资源：包括操作系统、数据库、中间件、云服务中的软件部分等；
• 应用程序：实际运行的业务代码和与之相关联的部分，如 CI/CD 工具；
• 数据：实际的用户数据和业务数据。

定义了生产环境，从生产环境衍生出生产环境的变更。

2 生产环境变更的概念和分类

生产环境的变更是指在生产环境中对任何一部分进行的修改，包括应用程序的更新、配置的修改、硬件设施的更换等。而线上故障大多来源于生产环境的变更，对生产环境的变更进行管理和控制，在较大程度上可以减少对系统稳定性产生影响。

生产环境的变更从其组成出发，再加上外部流量，可以分为 5 类：

2.1 硬件资源变更

硬件资源变更主要包含所有与物理硬件和云服务硬件配置相关的更换、升级或维护。

• 硬件规格调整：例如，升级处理器（CPU）、扩充内存（RAM）、更换硬盘等。
• 网络设备更新：包括替换路由器、交换机或进行固件更新等。
• 存储设备变动：磁盘扩容、存储设备更换等场景会包含在内。
• 云服务硬件调整：如云计算服务中服务器规格的调整、增减虚拟机实例、增减 POD 数、网络设备变更等。

2.2 软件配置变更

软件配置变更涵盖了所有与操作系统、数据库、中间件以及云服务软件设置的修改。

• 操作系统参数调整：比如，优化操作系统性能通过调整系统参数等。
• 数据库设置变动：例如，数据库参数调整或修改索引，导致数据库负载提升甚至锁表导致的无法读写等线上事故。
• 中间件配置更新：如修改消息队列的设置，调整缓存策略导致缓存穿越或者缓存雪崩等线上问题时有发生。
• 云服务软件配置调整：包括了云服务的安全规则更新、网络配置变动等。

2.3 应用程序变更

应用程序变更主要包含了所有与业务代码和将业务代码发布到生产环境的 DevOps 工具的更改。

• 代码变更：代码变更是我们最最常见的变更类型，主要是通过修改代码改变应用程序并通过发布系统发布到生产环境。这也是我们变更管理中风险最大的地方，因为变更的人，变更的位置和逻辑等都是不确定的。除了正常的发布变更，应用的回滚也是应用变更的回滚，因为其改动了线上的应用。实际中，代码变更在逻辑上包括了修复 bug、优化性能、增加新功能等，都需要对应用程序代码进行更新。
• 配置变更：指应用系统的配置变更，一般是通过配置系统来变更，触发线上应用的热更新或滚动，配置如果是写死在代码中，会变为代码变更。
• 依赖库更新：实际业务中需要对应用程序所依赖的库或框架进行更新，有些更新可能需要改代码，或者代码本身已经是这么个逻辑，在构建的时候就会带出去。
• DevOps 工具变更：例如，升级工具版本，或者对某些功能进行调整。
• DevOps 工具配置变更：如发布脚本中对于 dev 或 prod 环境的配置修改等等，都是高风险操作，线上有着血淋淋的故障。

2.4 数据变更

数据变更很少被人当作变更处理，因为很多时候就是正常的业务操作，如管理后台的批量操作这些，但是这些批量操作如果发生在高峰时期，可能会对线上业务带来较大的影响，轻则速度变慢，重则线上事故。数据变更可以分为线上数据的清理、迁移、更新等操作。

• 数据清理：如定期删除过期数据，清理无效数据节省成本等等，基于不同的目的，将数据清除，除了可能会影响性能，如果清理错了，将会导致用户丢失，以至用户资产的损坏，这将会是很大的线上事故。
• 数据迁移：如将数据从一个数据库迁移到另一个数据库，或者因为业务升级，数据需要从一种逻辑迁移到另一种逻辑，除了负载压力，更多的可能是数据错乱或者数据丢失，这两种情况都会引发用户投诉。
• 数据更新：如前面说的管理后台批量更新，或者上线新模块在已有的数据库上初始化数据等等，这种最多的情况是其引发的 DB/ES 等存储类中间件的高负载导致服务的异常或引发线上事故。

2.5 流量变更

流量变更和上面四个类别不同，其是从外部来看的，主要包含了流量变化的情况。这里不考虑攻击类的流量。流量一般是带来高负载，或者由高负载引发的链路异常或雪崩，从而导致整体服务异常或线上事故。

• 负载调整：如对调整负载均衡策略，更改流量路由等由于考虑不周引发某些节点过热或流量过大，引发级联反应，从而出现异常或事故。
• 后台投放或大型促销活动：如没有提前通知的后台投放或大型促销活动、特殊事件导致的流量激增，可能需要进行负载调整或资源扩容等，如果某些链路存在容量上限，或者达到扩容的上限，就会引起线上异常或事故。

以上 5 种类型画成简单的脑图，如下：

3 变更管理

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更，从而减少变更对业务和服务质量的影响，快速处理变更可能带来的问题，提升系统的稳定性。

变更管理，咱们从组织和流程机制两个方面来看。

3.1 组织

一个事情要想有力的执行下去，一定是有一个组织来保障事情的整体节奏和推进。

从组织的角度，整个变更管理的组织成员角色可以分为以下几种：

• 变更管理主导者：一般来说，这个角色通常由技术团队的高级管理者来担任，并且这个事情它本身是一个从上向下的事情，需要更上层的负责人来推进事项，一般是 CTO 或 VP，或质量的负责人。他们需要确保变更管理策略和流程的成功实施，对整个变更管理过程负责，并需要对所有的变更决策拥有最后的决定权。

• 变更管理委员会：这是一个跨部门的团队，包括来自业务、开发、运维、质量保证等部门的代表。他们的任务是评审即将进行的变更，评估其对业务的影响，以及是否符合公司的战略目标。他们还负责改进变更管理流程，并对变更管理的效果进行监督和评估。在实际的实施过程中可能没有正式的名称叫委员会，可能叫 XXX 质量小组，或者就是某个研发中心的管理团队兼任。

• 变更经理：这个角色负责确保变更管理流程的日常运行，是实际的变更控制推进者，他们需要协调变更的执行，确保所有的变更都通过了必要的评审，已经准备好了回滚计划，并且变更后的效果已经得到了验证。在实际的实施过程中，变更经理大概率是某个 Leader 或者质量的负责人，或者 PM。

• 变更执行人：这个角色负责协调变更的具体实施，例如安排变更的时间，通知相关人员，收集反馈，等等，一般这种变更由一线的开发，SRE 来做，也有大一些的公司有专门的职位。

3.2 流程机制

变更管理有一个理想状态的标准流程，其大概如下：

1. 变更申请：在我们的流程中可能是创建发布记录，或者申请紧急发布
2. 变更评审：变更评审主要是检查变更过程是否完备，以降低变更的风险，其包括如下内容：
   1. 就绪分析：材料是否完备，人员、设备、软件、网络是否就绪，测试是否达到上线要求等。
   2. 风险分析：架构、性能、业务、合规等方面的风险评估，变更内容是否属于需求范围，变更是否可控。
   3. 重要程度：变更属于一般、重要、紧急、标准哪一种。
   4. 变更审查：内容是否满足业务需求，内容是否通过测试，测试是否全面、有效。
   5. 应急管理：变更步骤、应急方案、回滚方案、应急预案是否完备。
   6. 变更实施：变更计划时间如何安排，发布及回退操作步骤是否完备，自动化步骤情况。
   7. 变更验证：变更涉及的业务、技术验证方法与时间安排。
3. 变更审批：相关负责人对于变更评审的结果进行确认，并审批通过。
4. 变更执行
   1. 根据发布计划执行发布操作，一般应该有一个灰度的过程；
   2. 验证线上功能并回归主流程；
   3. 持续灰度，观察用户直到灰度完成。
5. 变更验收
   1. 对发布的功能进行验收，对于影响范围内的功能进行验收，对业务主流程进行回归验收；
   2. 留守，并观察日志、监控服务负载等，这个操作是为了及时发现验收检查漏掉的问题，或者及时处理隐藏的问题，以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰，还是僵化的惯性，还是能真正地解决问题，是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前，即我们变更线上环境前需要自己做 Code Review，以及交叉的检查，以尽量减少问题流转到后面的操作中，节省问题的处理成本。

在标准流程之外，另外还有两个特别重要的点，一个是周知，一个是盘点。

周知在形式上可以是邮件、群通知、群消息，通过这些方式，将研发自己做的前面所定义的线上变更周知给相关方：「我们做了 XXX 操作，可能会影响 XXX ，你们看下对你们自己有没有影响，如果有相关告警可以找我。」

变更虽然有流程，但是流程保证的是过程，对于过程中的问题通过变更盘点的方式，阶段性回顾问题和成果，在变更委员会中达成共识并继续迭代。在每次迭代的时候我们可以问自己如下的一些问题：

• 与上次回顾相比，变更对线上的影响有更严重吗？有影响到稳定性吗？
• 变更流程是否有什么问题，是否需要专项来解决？是否应该解决？
• 上次回顾安排的事项落实了吗，对应的情况如何，是否有更新到流程或系统中？

以上的回顾操作我们建议以某个管理系统来承载，并且这个管理系统是带有通知等功能，以更好的将变更相关的信息周知出去。当然，也可能直接共享文档+群通知来搞。

4 小结

上面的变更管理只是流程方面的，对于实际中变更管理最好是能在类似于 DevOps 系统中的落地，最少也是在项目管理或流程系统中落地。

生产环境的变更管理是一项复杂而重要的任务。通过对生产环境的良好理解，结合有效的组织、流程和系统工具，我们可以实现对生产环境变更的有效管理，保证业务的稳定运行，提升用户的使用体验，同时也提升了我们自身的运维效率和质量。这也是我们做研发管理必须要完成的任务之一。