运用 SRE 原则降低生产事故影响：CRE 实战经验与可靠性优化方法

如果你运营任何类型的互联网服务，就会知道生产事故几乎不可避免。无论架构设计多么稳健，发布流程多么严谨，最终总会有某些因素叠加失控，导致客户无法正常使用你的服务。

你努力打造用户喜爱的产品，不断推出新功能，既是为了提升现有用户的满意度，也是为了吸引更多新用户。然而，发布新功能，或者引入任何形式的变更，都会增加生产事故发生的风险。换句话说，某些用户可见的环节可能会出现问题。生产事故会削弱客户信任。如果想持续发展业务并留住用户，就必须在服务可靠性和功能迭代速度之间找到恰当的平衡。

好消息是，一旦找到这个平衡点，你就有机会同时提升可靠性和迭代速度。

本文将生产事故周期拆解为若干阶段，并分析每个阶段如何影响用户体验。随后，我们将进一步探讨如何以尽可能低的可靠性工程成本降低事故影响，从而实现用户与业务的双赢。除此之外，本文还会介绍站点可靠性工程（SRE）中的若干基本原则，例如设定可靠性目标、衡量事故影响，以及从故障中学习。这些原则可以帮助你基于数据做出判断，明确应该优先改进生产事故周期中的哪个环节。

什么是生产事故周期？

生产事故，是指对服务用户造成足够明显的负面影响，以至于用户能够感知并受到影响的事件。

你的服务及其运行环境始终处于变化之中。例如，大量新用户涌入，这当然是好事；基础设施发生故障，这就不妙了。这些变化都会对服务可靠性构成威胁。生产事故虽然令人不快，却也是复杂系统持续变化所带来的必然结果。

我们可以从生产事故周期的角度，理解它如何影响用户满意度。

用户满意度在生产事故期间下降，并在服务恢复可靠后趋于稳定

需要注意的是，两次服务故障之间的间隔时间，包含故障本身的持续时间。这与一些传统衡量方式不同，因为现代互联网服务可能以彼此独立、相互重叠的方式发生故障。采用这种口径，是为了避免在分析中出现负数。

服务级别目标（SLO）代表服务应达到的可靠性水平。一旦服务可靠性低于这一水平，用户就会在某种程度上感到不满。因此，你的目标很明确：让服务可靠性尽可能维持在 SLO 之上，从而保障用户满意度。

可以设想一下，如果事故检测时间更短，缓解时间更短，事故发生期间可靠性下降得更慢，或者两次事故之间的恢复时间更长，那么整体可靠性曲线会发生怎样的变化？显然，服务跌入“红色区域”的风险会降低。

换句话说，只要能减少生产事故的持续时间、影响范围和发生频率，就能降低事故对用户造成的实际影响，并帮助你维持用户满意度。

生产事故、用户满意度与可靠性成本的关系

既然只要将可靠性维持在服务级别目标（SLO）之上，就能让大多数用户满意，那么可靠性是否越高越好？我们究竟应该把目标设定在 SLO 之上多少？

显然，可靠性低于 SLO 的程度越高，用户满意度就越低。但一个容易被忽视的事实是：当可靠性已经高于 SLO 之后，继续提升可靠性，用户能感知到的价值反而会逐渐降低。

故障仍然可能发生，用户也可能注意到个别异常。但只要服务的平均可靠性高于 SLO，故障发生频率就足够低，用户整体上仍会感到满意。也就是说，当可靠性已经超过 SLO 后，继续追求更高可靠性，对用户而言边际价值并不明显。

最佳 SLO 阈值既能让大多数用户满意，又能最大限度地降低工程成本。

可靠性是有成本的。它不仅会消耗工程时间，还会带来机会成本。例如，更高的可靠性要求可能会延缓产品上线节奏，影响功能交付速度。并且，可靠性成本往往不是线性增长，而是呈现出陡峭上升的趋势。一项可靠性提高 10 倍的服务，其运行成本可能远高于原先水平。

服务级别目标（SLO）定义的是最低可靠性要求，而这一要求通常低于 100%。如果你的服务可靠性长期远高于 SLO，就说明你在可靠性上的投入可能已经超过实际需要。

好消息是，你可以把这部分“多出来的可靠性”，也就是错误预算，用在更有价值的事情上，而不是继续维护用户几乎感知不到的额外可靠性。

例如，你可以更频繁地发布产品，可以对生产基础设施进行压力测试以发现隐藏问题，也可以让开发人员把更多精力投入新功能开发，而不是继续追求过度的可靠性。高于 SLO 的可靠性，本质上是一种缓冲，用来防止用户感知到系统不稳定。只有将可靠性控制在稳定、合理的水平，才能最大化错误预算的价值。

不稳定的可靠性曲线会妨碍你有效地利用误差预算。

如何运用 SRE 原则降低生产事故影响？

在思考如何改进生产事故周期的各个阶段时，有三项 SRE 原则尤其重要。讨论可靠性问题时，应始终牢记这些原则。

1. 创建并维护服务级别目标 SLO

当 SRE 讨论可靠性时，服务级别目标（SLO）几乎一定会被提及。SLO 是错误预算的基础，它定义了服务所需达到的、可衡量的可靠性水平。

SLO 会影响整个生产事故周期，因为它决定了你需要投入多少准备工作。

如果你的用户只需要 90% 的 SLO，也许当前“一次性发布”的策略已经足够。如果你的服务需要达到 99.95% 的 SLO，那么就应该考虑采用分阶段发布、自动回滚等机制。

服务水平目标 (SLO) 越接近 100%，维持起来就越困难，因此要慎重选择目标。

在事故发生期间，SLO 还能帮助你衡量事故影响。它不仅能告诉你何时发生了严重问题，更重要的是，它能用整个组织都能理解的方式，准确说明问题到底有多严重。无论是值班工程师、研发负责人，还是高层管理者，都可以基于同一套可靠性指标形成共识。

如果你需要学习如何制定高质量的 SLO，可以参考海外某些公司和在线教育平台公开发布的相关课程与实践资料。

2. 撰写生产事故复盘报告

海外某些公司在可靠性工程实践中有一个很形象的说法：生产事故是一种计划外投资，而且所有成本都已经预先支付。

你可能会损失收入，也可能会损失生产力，但几乎一定会损失用户信任。这项“投资”的回报，就是你从事故中提炼出的经验教训，并借此避免未来再次发生类似问题，或者至少降低类似事故的影响。

事故复盘报告，正是提取这些经验教训的重要机制。它记录事故如何发生、为何发生，并指出系统在哪些方面需要改进。一份高质量的事故复盘报告可能需要一天甚至更久才能完成，但它能帮助你保留这次计划外投资的价值，而不是让事故带来的损失白白流失。

找出事故的技术原因和非技术原因，是防止事故再次发生的关键。

什么时候应该撰写事故复盘报告？

每当服务级别目标（SLO）受到显著影响时，都应该撰写。事故复盘报告会成为可靠性工作的反馈循环。你应当将工程改进工作聚焦在那些反复出问题的事故周期阶段。

有时，你也可能只是侥幸逃过一劫：SLO 本来可能受到影响，但因为某些偶然因素，最终没有真正受损。即便如此，也应该进行复盘。因为这类“险些发生的事故”同样揭示了系统中的薄弱环节。

有些组织更倾向于通过会议讨论事故，而不是协作撰写复盘文档。无论采用哪种方式，都务必要留下书面记录，以便日后识别趋势、沉淀经验，并推动持续改进。在实践中，团队也可以借助 PingCode 这类智能化研发管理工具，将目标、需求、开发、测试、发布与 Wiki 知识沉淀连接起来，让事故复盘中的经验教训、改进项和研发数据在同一流程中持续流转；对于更偏通用项目协作的团队，也可以使用 Worktile 管理任务、文档、日历、审批和跨团队协作事项，确保复盘结论真正落地。

不要把可靠性寄托在运气上。正如 SRE 领域常说的那样：希望不是策略。事故复盘报告，正是将希望转化为具体行动的最佳工具。

要让事故复盘真正有效，相关人员必须相信：只要他们如实描述事故经过，就不会因此受到惩罚。要做到这一点，就需要第三项关键原则。

3. 倡导无责文化，提升事故响应质量

无责文化承认这样一个事实：人在特定情境下，会基于当时掌握的信息做出他们认为合理的选择。

事后复盘往往会表明，这些选择并不是最优的，有时甚至会适得其反。但如果某个人的行为引发了生产事故，或加剧了已有事故，我们不应将责任简单归咎于个人。相反，我们应该改进系统，使人在下一次紧急情况下更有可能做出正确行动。

无责文化意味着团队成员假定同事的行为出于好意，并寻求技术手段来解决人性的弱点，而不是要求人做到完美。

例如，假设一位工程师半夜接到告警，确认后又回到床上继续休息，而此时生产事故正在发生。第二天早上，我们当然可以解雇这位工程师，并认为只要团队里剩下的都是“称职”的工程师，问题就解决了。

但这样做完全误解了问题的本质。

胜任力并不是工程师与生俱来的固定属性，而是人与系统互动的结果。真正可以被改变，并能持续影响未来结果的，是系统本身。

值班工程师接受过哪些培训？告警是否清楚传达了事故的严重性？这位工程师是否收到了超出其处理能力的告警数量？相关升级机制是否足够清晰？这些才是事故复盘中真正应该调查的问题。它们的答案，远比简单认定某个人失职更有价值。

营造无责文化至关重要。它能让人们在紧急情况下毫不犹豫地寻求帮助，也能让他们在事故复盘中保持诚实和开放。只有这样，复盘才能真正发挥学习作用。

如果缺少这种文化，事件响应的压力会大大增加。团队的首要任务可能会变成保护自己和同事免受指责，而不是尽快帮助用户恢复服务。事故调查也可能因此流于表面：如果某些细节可能导致某人，甚至是你自己，被惩罚或解雇，那么调查结果很可能无法触及根因，最终也无法形成有价值的改进方案。

最终受损的，仍然是你的服务用户。

无责文化并非一朝一夕就能建立。如果组织尚未形成这种文化，推动它落地可能会相当困难。它需要各级管理者的坚定支持。但一旦无责文化扎根，团队就能更轻松地专注于识别和解决系统性问题，从而持续降低生产事故对用户的影响。

总结：用 SRE 方法持续提升服务可靠性

生产事故无法被彻底消除，但可以被更好地管理。通过设定清晰的服务级别目标（SLO）、建立错误预算机制、持续撰写事故复盘报告，并推动无责文化落地，团队可以更系统地降低生产事故影响。

真正优秀的可靠性工程，并不是一味追求 100% 的稳定，而是在用户满意度、工程成本和产品迭代速度之间找到平衡。SRE 的价值，正是在于帮助团队用数据和机制持续改进服务可靠性，让每一次事故都转化为下一次进步的起点。