53 lines
6.2 KiB
Markdown
53 lines
6.2 KiB
Markdown
# 当声明事故成为大家最爱用的变通手段
|
||
|
||
- **期号**: SRE Weekly Issue #532（2026-08-31）
|
||
- **作者**: Brent Chapman
|
||
- **链接**: https://greatcircle.com/blog/2026/08/11/declaring-incidents-for-side-effects/
|
||
|
||
## 简介
|
||
|
||
需要另一个团队立刻办事？一个神奇小技巧就能搞定：声明一次事故！这篇文章解释了为什么显而易见的解法（限制事故声明）并不是个好主意。
|
||
|
||
## 正文
|
||
|
||
你看到有人声明了一次 Sev-2 事故，于是好奇：等等，这为什么算事故？什么都没宕，客户也没受影响。但原来是一位经理需要把自己团队的问题推到另一个团队的优先级队列最前面，而事故流程恰好是达成这一目的最可靠的方式。这并非事故流程的本意，但它管用，那又有什么坏处呢？
|
||
|
||
问题在于，一旦大家发现这招好使，它就会越来越频繁地发生。产品经理声明事故，是因为事故通知是把问题送到领导面前最快的方式——这个问题已经在积压清单里躺了几个星期。客户团队声明事故，是因为他们需要工程支持来搞定一次面向重要潜在客户的大型演示，而事故流程是短期内把工程师从冲刺开发里拉出来最简单的方式。工程师声明事故，是因为这比走正式的变更冻结豁免流程容易得多。
|
||
|
||
损害是累积性的。当所声明的"事故"里越来越大的比例并非真正的紧急情况，紧急信号本身就会退化。当真正的 Sev-1 到来时，人们响应得不再那么紧张，因为他们已经被训练得预期这又是一个变通伎俩。而且激励会自我强化：钻流程空子的人能更快解决自己的问题，这教会了所有人——钻空子才是办事之道。每一次单独的声明都是一个需要办成事的人做出的可以理解的决定；是这些行为的叠加在腐蚀流程本身。
|
||
|
||
每一次非紧急声明都依然承担着一次真实事故的全部开销。响应者被从计划内的工作中拉出来。有人放下手头一切去当事故指挥。干系人切换上下文来跟进事态。当你运转足够多的这类"事故"时，团队就有可观比例的时间花在紧急模式上，而实际上并没有紧急情况——事故的所有间接成本（项目被打断、上下文切换、恢复时间）一样样照收。
|
||
|
||
这里有一个讽刺之处：人们之所以去用事故流程，恰恰是因为它管用；他们亲眼看到它能按需稳定地交付协调、优先级和紧迫感。
|
||
|
||
## 本能反应是错的
|
||
|
||
当公司注意到这个模式，本能反应往往是收紧声明标准。他们加上把关：也许声明事故需要经理批准，或者必须先完成一份事前检查清单，又或者事后有人审查这次声明是否"正当"。意图是合理的，综合效果却是腐蚀性的。
|
||
|
||
给事故声明设置门槛是适得其反的。你设置的每一个减速带，同样会拖慢真正的事故。因为不确定问题是否"够严重"而犹豫是否声明——这本来就是事故响应里最常见的失败模式。再加一道正式审批步骤，或者事后审查声明是否合理，只会让这种犹豫变得更糟，而不是更好。
|
||
|
||
你也错过了钻空子行为在告诉你的事：人们伸手去用事故流程，说明你的常规流程已经不够用了。如果只打击钻空子，你只是压制了症状，而没有从中学到任何东西，底层问题会继续存在。
|
||
|
||
## 修复逃脱路径，而不是惩罚逃跑者
|
||
|
||
换个思路：看看人们在声明可疑事故时想触发哪些副作用，然后把这些能力用其他途径提供出来。
|
||
|
||
如果绕过变更冻结最简单的办法是声明事故，那就为紧急变更建立一个非事故的豁免流程。这不必复杂；一个由指定发布管理员做的轻量审批，加上清晰的升级路径，就能覆盖大多数情况。
|
||
|
||
如果把自己问题挪到另一个团队优先级队列最前面最简单的办法是声明事故，那就创建一个不需要事故的优先级升级路径。跨团队的工单分诊会议、一个明确的加急请求机制，甚至一个相关人士真的会盯着的专属 Slack 频道，都能吸收掉大部分压力。门槛不必高到"宣布紧急状态"，只要低于"等六个星期直到下一个规划周期"就行。
|
||
|
||
如果短时间内聚集跨职能团队最简单的办法是走事故流程，那就为非事故场景创建一个轻量协调机制。有些公司称之为"蜂群"（swarm）、"老虎队"或"协调请求"。叫什么名字不重要；重要的是人们有一条路能拿到所需的协作，而不必借用事故流程。
|
||
|
||
反复钻事故流程的空子来获取资源优先级或跨职能协调，不是一系列一次性的变通手段；它是一个系统性问题表现出来的症状，需要系统性的回应。Google 的 SRE 组织为此建立了正式的 [Code Yellow 和 Code Red](https://www.theengineeringmanager.com/growth/code-yellow-code-red/) 机制：当一个问题的严重程度足以要求跨职能关注、但还不构成事故时，用结构化的方式来调集资源、提升优先级。
|
||
|
||
## 诊断性问题
|
||
|
||
回顾你最近十来次事故，逐一自问：这次声明是因为发生了紧急情况，还是因为事故流程是拿到团队所需东西的更省事的路径？
|
||
|
||
你不需要正式的审计。找几位有经验的事故指挥和值班工程师聊聊；他们早就知道哪些是真的、哪些不是。然后去和那些声明了可疑事故的人谈谈（当然是本着无指责、摆事实的态度）。如果你愿意听，他们会准确地告诉你常规流程里缺了什么。
|
||
|
||
人们钻事故流程的空子只是症状。底层问题通常是常规流程太僵化、太慢、太不敏感，事故流程成了阻力最小的路径。修复底层问题，钻空子自然停止，因为再也没有什么可钻的了。你的事故紧急信号恢复如初，团队不再把紧急模式的周期烧在不紧急的事情上，当真正的 Sev-1 到来时，人们会像对待重要事件一样去响应它。
|
||
|
||
而如果你正在处理这个问题，请花点时间欣赏一下这说明了什么：人们借用事故流程，是因为它*管用*。修复之道不是让它失效，而是让其他一切也都像它一样好使。
|
||
|
||
## 最新评论 |