从 15 年的软件事故管理中学到的十几个经验

作为一名软件工程师，处理突发事件是一件非常痛苦的事情。周六凌晨 3 点收到待命呼叫？这可能会让人感到恐惧、心力交瘁，而且是一件令人厌恶的事情。如果这种事情经常发生在你的工作场所，它确实会引发创伤后应激障碍 (PTSD)。

不幸的是，这是软件时代精神的一部分。如果说有什么不同的话，那就是真正的工程技术得以诞生的火焰。这些事件教会你如何构建坚固的系统，在很多情况下，也教会你如何避免这样做。

本文从两个方面探讨如何处理软件事故：

• 🛠️ 人们需要在他们的软件平台和团队中灌输实践，以防止和从这些经验中学习。

• 🧘 一个人需要有坚韧的态度，不仅能从这些经历中毫发无损地走出来，而且收获比经历的更多。

我们将讨论的主题是——

1. 尽可能实现系统自动化
2. 追踪领先指标与滞后指标
3. “可操作”警报应该是不言而喻的
4. 建立清晰的呼叫链和升级路径
5. 授权一线人员做出重大决策
6. 并非所有事件都是平等的
7. 先解决问题，再提问
8. 确保有一个人负责
9. 清晰且频繁地沟通
10. 无责事后分析至关重要
11. 尸检后续工作至关重要
12. 只要 MTTD 较低，事故就不算严重
13. 幽默是伟大的均衡器

让我们深入了解一些细节！

尽可能实现系统自动化

您确实希望尽量减少通过客户或事件发生后几天或几周内出现的严重会计差异而了解到的事件数量。虽然“自动化”在工程领域是一个被过度使用的词，但这是那些您真正想要找到信噪比的正确平衡的领域之一，并确保您和您的团队无需任何人工干预即可收到警报。

如果要选择的东西太多，那就选择超高层次。你能选择的最高层次指标是什么？如果组件系统无法按预期工作，会偏离常态吗？这可能是跟踪流经平台的收入（对于电子商务、金融或基于美元的平台），或当前活跃用户的数量（对于社交媒体平台）。

如果您发现数字下降或下降一两个标准差，请立即通知开发团队。将第一个（或最重要的）警报集中在业务脉搏或核心用户体验上将是一个很好的监控指标。随着您变得更加老练并更好地了解系统，您可以从可观察性的角度开始更深入地了解堆栈。

追踪领先指标与滞后指标

领先指标具有预测性，可能指出即将发生的问题，而滞后指标则是事后指标，代表问题已经进展到一定程度后的后果。如果您可以利用领先指标（例如“会话持续时间”开始下降）来补充或代替滞后指标（例如“下单数量暴跌”），那么您可能会避免一些非常灾难性的事情。

“可操作”警报应该是不言而喻的

您的警报必须不言自明，这样当警报触发时，下一步该怎么做就一目了然了。无论是确定问题的严重性、排除故障还是解决问题，警报都应该有足够的详细信息。您要确保不需要大量的前期讨论来确定如何处理警报。

您可以将这些详细信息粘贴在警报本身的内容中，或者如果它相当冗长，您可以链接到团队为这些类型的问题维护的运行手册。

建立清晰的呼叫链和升级路径

明确警报触发时会发生什么，包括根据服务所有权、时区意识等因素将警报路由给谁，对于确保快速响应至关重要。除了直接的第一道防线之外，确保事件响应者能够如何以及向谁升级事件也同样重要。

通常，如果问题很复杂或范围远大于一个人可以处理的范围，则可能需要更多高级人员（或团队中的多个人）以及跨职能利益相关者的参与。通过工具（如 PagerDuty、OpsGenie）或清晰的文档（运行手册、wiki 页面、repo README）使所有这些都易于访问，可能是灾难性事件和毫无意义事件之间的区别。

赋予一线人员做出重大决策的能力

虽然您需要明确的升级路径，但您不希望这是默认响应。您必须授权第一响应者能够采取实际行动来止血或做出现场补救决定，而无需咨询高级管理层。这既有利于公司限制后果，也有利于那些肩负重任、值得信赖做出重大决策的员工。减少繁文缛节，增加个人的自主权。

并非所有事件都是一样的

除了呼叫链和升级路径等内容外，另一个重要的附属资料是事件优先级等级。这通常是急救人员或事件指挥官的快速参考。它可以帮助他们快速确定事件的严重程度并对其进行标记，因为它可能需要不同级别的响应。

区分重大事件（如系统中断或财务数据损坏）和小问题（如调色板故障）对于响应者避免误报至关重要。这还可以确保团队的响应保持有效和专注。

先解决问题，再提问

毫无疑问，最重要的事情之一就是尽快解决事件。在事件发生时，您不想花时间思考为什么会发生某事或如何防止它发生。您可以将这些留到事后分析。目前，只需全神贯注地解决事件，稍后再提出棘手的问题。

确保有一个人负责

有时，事件可能会变得太大。它们涉及太多服务，跨越多个业务领域，或者对收入或声誉产生重大影响。这时，任命一个人来“指挥”整个事件就绝对至关重要。在 Place Exchange，我们设立了“事件指挥官”，他们是一小群接受过复杂事件响应培训的人。

之所以有这样的角色如此重要，是因为当涉及多方时，需要有人来指挥交通。工程师们通常会开始深入研究问题的复杂性或试图了解如何解决问题。

事件指挥官的作用是让团队专注于快速解决事件。他们确保每个人都有行动的倾向，虽然侧面调查可能很重要，但确保向前发展的势头更为重要。他们还负责确保与内部和外部利益相关者及合作伙伴保持清晰和持续的沟通。

事件指挥官通常会启动同步语音通信线路，例如 Slack 会议或 Google Meet 会议。这可确保对解决事件至关重要的人员保持持续联系。与仅允许人们使用聊天异步解决问题相比，这件小事的有效性令人惊叹。

事件指挥官还负责确保明确授权需要完成的任务，并确保对这些任务的回应或结果负有责任。

俗话说，如果你让两个人喂马，马就会死。事件指挥官会阻止这种情况发生，并最终负责迅速解决事件。

清晰且频繁地沟通

如果人们能及时了解团队如何努力解决事件，他们通常会原谅自己最喜欢的应用程序或软件的关闭。试图隐瞒事情，无论是因为您觉得自己无法完全掌控事件，还是您和您的团队对此感到尴尬，都不是阻止沟通的理由。

确保与内部和外部合作伙伴的沟通简洁、频繁且透明，因为这将有助于建立良好的关系。

无责事后分析至关重要

事后分析或事后回顾对于建立学习文化非常重要，而且绝对不能责备任何人。批评过程而不是批评人。没有人比可能造成这种情况的人对自己更严厉，公开鞭笞他们不会给你带来任何好处。如果有的话，所有研究都表明，这样做实际上会给你带来损失。Etsy 的人更擅长谈论它，所以如果你想了解更多，请阅读https://www.etsy.com/codeascraft/blameless-postmortems 。

事后分析的后续行动至关重要

虽然自行进行事后分析对于提高认识和从这些事件中吸取教训的反馈循环很重要，但讨论如何防止此类事件再次发生的行动项目可能更为重要。如果小组发现了系统中的一系列漏洞或漏洞，那么集中精力及时解决这些问题以防止再次发生同样的问题就显得至关重要。

很难防止事故发生，这通常需要与企业和客户进行艰难的对话。但如果同一事件一再发生，那么辩护难度就会加大，也表明团队的健康和技能存在严重问题。

只要 MTTD 较低，事故就不算严重

每个人都明白这一点。即使是商务人士也明白这一点。构建软件很难，而且在一个所有软件都有数百上千个依赖项的世界里，故障线可能会破裂，这是无法预测的。事情会变得一团糟，这没关系。我们无法阻止事故发生。然而，真正有帮助的是确保事故的 MTTD 非常低。

平均检测时间 (MTTD) 是一项关键绩效指标 (KPI)，用于衡量组织识别事件或安全威胁所需的平均时间。考虑到业务领域、影响严重程度等，很难一概而论，但如果您能够将 MTTD 缩短至几秒到几分钟，那么您可能能够显著降低事件的影响，而不是几小时到几天（更不用说几周或几个月了，不幸的是，这完全有可能）。

幽默能缓解你此刻的痛苦

这一切都太严重了！钱都白白浪费了！顾客的体验很糟糕！然而，在这一切之中，我发现保持幽默感至关重要。我们不应该忘记，在这个过程中，每个人都是人，都会经历不同程度的压力。在适当的时刻注入幽默有助于缓解一些压力。

它建立了一种友爱精神，让团队感觉他们是在一起的，而不是在地狱里的一座孤岛上。

就到这里。谢谢阅读！

⭐ 如果您喜欢此类内容，请务必关注我或订阅https://a1engineering.substack.com/subscribe ！⭐

特色照片由 Julien L 在 Unsplash 上拍摄