有效的事故管理是尽可能降低事故影响、缩短服务中断时间、尽快恢复正常业务运行的关键。如果没有事先演练过潜在事故的应对方案那么真正遇到事故时原本清晰的原则和流程很可能会在混乱中失效。本文将先描述一起因临时、无序处置而逐步失控的事故随后概述一套妥善的事故管理流程最后回到同一场景看看如果采用成熟运转的事故响应机制结果会有何不同。未受控的事故事故响应为何会失控想象一下你是玛丽这家公司的一名值班工程师。周四下午两点你的寻呼器突然响起。黑盒监控显示整个数据中心的服务已经停止。你叹了口气放下咖啡开始着手修复。几分钟后第二条告警响起第二个数据中心也停止服务。紧接着五个数据中心中的第三个也崩溃了。更糟的是剩余数据中心承接的流量已经超过处理能力开始过载。很快整个服务彻底瘫痪无法处理任何请求。你盯着日志看了很久仿佛过了几个世纪。成千上万行日志显示最近更新的某个模块似乎出了问题于是你决定将服务器回滚到之前的版本。可回滚之后问题依旧存在。你打电话给约瑟芬。她编写了这项崩溃服务的大部分代码。她提醒你在她所在的时区现在是凌晨三点半但还是睡意朦胧地答应登录查看。你的同事萨布丽娜和罗宾也开始在各自的终端上检查问题。“我们随便看看。”她们告诉你。这时一位公司高管打电话给你的老板怒气冲冲地质问为什么没人告知他“这项关键业务服务已经彻底崩溃”。与此同时几位副总裁也不停催问你预计何时恢复并反复追问“这怎么可能发生”你本想表示理解但那会耗费宝贵的精力而你正忙着排障。这些副总裁凭借过去的工程经验提出了一些看似有道理、实则无关紧要却又很难当场反驳的建议比如“把页面大小调大”时间继续流逝剩下的两个数据中心也彻底瘫痪了。你不知道的是睡眼惺忪的约瑟芬又给马尔科姆打了电话。马尔科姆突然想到也许问题与 CPU 亲和性有关。他确信只要把这个简单改动部署到生产环境就能优化剩余服务器进程于是他照做了。几秒钟内服务器重启并应用了这项改动。然后它们又崩溃了。事故失控的原因分析请注意在上面的场景中每个人都在努力做好自己的工作。那么事情为什么会恶化到这种地步这起事故之所以失控是由几个常见隐患共同导致的。过度关注技术问题我们通常会雇用像玛丽这样技术能力很强的人。因此她忙于对系统进行操作层面的修改竭尽全力解决问题并不令人意外。但由于眼前的技术任务过于繁重她已经没有余力从更宏观的角度思考如何控制事故影响、协调资源和推进恢复。沟通不畅同样因为玛丽已经应接不暇她也无暇进行有效沟通。没有人清楚其他同事正在采取哪些行动。公司领导层愤怒不已客户怨声载道而其他本可以协助调试或解决问题的工程师也没有被有效组织起来。擅自行动马尔科姆的出发点是好的但他在没有与其他人协调的情况下修改了系统甚至没有与正在主导排障的玛丽沟通。结果他的改动让原本已经糟糕的局面雪上加霜。事故管理流程的关键要素事故管理技能和实践的目的是将那些积极投入、急于解决问题的人的精力引导到正确方向。一些海外技术团队的事故管理体系基于事故指挥系统即 Incident Command System简称 ICS。这一体系以清晰、可扩展而著称。一个设计良好的事故管理流程应具备以下特点。递归式职责分离确保事故中的每一位相关人员都清楚自己的职责并且不越界行事这一点至关重要。看似有些反直觉但明确的职责划分反而能赋予个人更大的自主权因为他们不必反复质疑同事的决定也不必担心自己的工作被他人随意覆盖。如果某个成员的工作量过大该成员应向规划负责人申请增派人手。随后他们可以将部分工作委派给其他人这有时可能需要创建子事故。或者角色负责人也可以将某个系统组件委派给同事负责由该同事向上汇报关键状态。事故处理中应将若干不同角色明确委派给具体人员。事故指挥官事故指挥官负责掌握事故的整体态势。他们负责组建事故响应团队并根据需要和优先级分配职责。事实上所有尚未明确委派的职责都默认由事故指挥官承担。必要时他们还应清除阻碍团队高效行动的障碍。运维执行负责人运维负责人负责与事故指挥官协作使用各种运维工具应对事故。在事故处理期间运维团队应当是唯一可以修改系统的团队。沟通协调负责人沟通负责人是事故响应团队对外发声的代表。其职责包括定期向事故响应团队和相关利益方发布更新通常通过电子邮件完成也可能包括确保事故文档准确、及时更新等工作。规划支持负责人规划角色通过处理较长期的问题来支持运维工作例如提交缺陷报告、安排餐食、组织交接班以及跟踪系统偏离正常状态的方式以便在事故解决后将系统恢复到正常状态。明确事故响应的指挥中心所有相关方都需要知道如何与事故指挥官互动。在许多情况下将事故处理成员集中到一个指定的“作战室”办公是合适的做法。也有一些团队更倾向于在各自工位上工作并通过电子邮件和 IRC 持续关注事故进展。一些海外技术团队发现IRC 在事故响应中发挥了重要作用。IRC 非常可靠可以作为事故沟通日志使用而这样的记录对于掌握详细的状态变化至关重要。相关团队还编写了机器人来记录事故相关的通信内容以便事后分析也编写了其他机器人用于记录频道告警等事件。对于分布在不同地理位置的团队来说IRC 也是一种便捷的协调工具。维护实时事故状态文档事故指挥官最重要的职责之一是维护一份动态更新的事故文档。这份文档可以保存在 Wiki 中但理想情况下应支持多人同时编辑。许多团队会使用在线协作文档工具不过负责此类协作文档工具可靠性的团队往往会选择另一类内部站点工具来承载事故文档。毕竟在事故管理过程中依赖正处于故障中的软件通常不是一个好主意。在实际落地中团队也可以借助 PingCode 这类智能化研发管理工具将事故处理过程中的需求、缺陷、任务、发布、测试和复盘知识沉淀到统一的研发流程中并通过 Wiki 记录关键经验同时打通研发过程中使用的其他工具让事故数据、任务状态和后续改进项能够顺畅流转。可参见“事故状态示例文档”中的事故文档样例。这份动态文档可能并不整洁但必须实用。使用模板可以简化文档创建过程将最重要的信息放在文档顶部可以提升文档的可用性。事故结束后应保留该文档用于事后分析必要时也可用于更高层面的复盘分析。建立清晰、实时的交接机制在工作日结束时必须明确交接事故指挥官职责。如果需要将指挥权移交给其他地点的人员可以通过电话或视频通话将情况清晰、安全地交接给新的事故指挥官。当新任事故指挥官充分了解情况后卸任指挥官应明确完成交接例如说“你现在是事故指挥官了明白吗”只有在对方明确确认之后才应结束通话。交接信息还应通知给参与事故处理的其他人员确保所有人始终清楚当前由谁负责事故管理工作。受控的事故规范事故管理如何发挥作用现在让我们回到同一起事故看看如果按照事故管理原则来处理结果会有什么不同。下午两点玛丽已经喝到今天的第三杯咖啡。寻呼器刺耳的提示音让她吓了一跳她赶紧一口喝完咖啡。问题来了一个数据中心停止服务。她开始调查。很快第二条告警响起五个数据中心中的第二个也出现故障。由于问题正在迅速扩散玛丽知道她需要启动现有的事故管理框架。她一把叫住萨布丽娜“你能负责指挥吗”萨布丽娜点头同意。玛丽迅速向她汇报了目前掌握的情况。萨布丽娜将这些细节记录下来并发送给预先设定好的邮件列表。萨布丽娜意识到自己还无法评估事故影响范围于是请玛丽做一次影响评估。玛丽回复说“用户目前还没有受到影响希望我们不要再失去第三个数据中心。”萨布丽娜将玛丽的回复记录到事故日志中。第三条告警触发时萨布丽娜在 IRC 调试频道中看到了告警并迅速在邮件线程中跟进更新。这个邮件线程让副总裁们能够及时了解总体状态而不必陷入技术细节。萨布丽娜请一位外部沟通负责人开始起草用户通知。随后她联系玛丽询问是否应该叫醒值班开发人员也就是约瑟芬。得到玛丽同意后萨布丽娜将约瑟芬拉入了事故响应流程。约瑟芬登录系统时罗宾也主动提出帮忙。萨布丽娜提醒罗宾和约瑟芬她们应优先处理玛丽分配的任务如果准备采取任何其他行动必须先告知玛丽。罗宾和约瑟芬迅速阅读事故报告了解当前情况。这时玛丽已经尝试过回滚到旧版本二进制文件但效果并不理想。她低声告诉罗宾罗宾随即在 IRC 上更新消息说明这次修复尝试失败了。萨布丽娜将这条更新粘贴到了实时事故管理文档中。下午五点萨布丽娜开始寻找接替人员因为她和同事们即将下班。她更新了事故记录。五点四十五分团队召开了一次简短电话会议以便交接当前状态。下午六点他们将工作移交给另一地办公室的同事。第二天早上玛丽回到岗位时发现大西洋彼岸的同事已经接手了这个缺陷缓解了问题关闭了事故并启动了事后分析。问题解决后她给自己煮了一杯咖啡开始规划结构性改进防止此类问题再次困扰团队。何时宣布事故与其等到问题迅速恶化数小时后才启动事故管理框架不如尽早宣布事故如果随后发现解决方案很简单再结案即可。团队应明确声明事故的触发条件。我的团队遵循以下几条基本准则。只要满足其中任意一项就应将其视为事故是否需要第二个团队参与解决问题客户是否能够感知到此次故障经过一小时的集中分析后问题是否仍未解决事故管理技能如果不经常使用就会迅速退化。那么工程师如何才能保持事故管理技能的熟练度从而更好地处理更多事故呢幸运的是事故管理框架也可以应用于其他需要跨时区、跨团队协作的运维变更。如果你将该框架作为变更管理流程的常规组成部分并经常使用它那么在真正发生事故时团队就能更自然地遵循这一框架。如果你的组织会进行灾难恢复测试那么事故管理也应成为测试流程的一部分。我们也经常进行角色扮演模拟处理已经解决的值班问题有时这些问题是由其他地点的同事解决的。通过这种方式团队可以进一步熟悉事故管理流程。总结用事故管理降低恢复成本我们发现提前制定事故管理策略确保该策略能够平滑扩展并定期执行这一策略可以缩短平均恢复时间也能为员工提供一种压力更小的方式来应对突发问题。任何重视可靠性的组织都可以从采用类似策略中获益。事故管理最佳实践确定优先级。先止损恢复服务并保留证据以便后续查明根本原因。做好准备。事先与事故参与者协商制定并记录事故管理流程。建立信任。给予所有事故参与者在指定角色范围内充分自主权。保持自省。在应对事故时留意自己的情绪状态。如果开始感到恐慌或不堪重负请寻求更多支持。考虑替代方案。定期审视各种选择重新评估继续当前做法是否仍然合理或者是否应在事故响应中采用其他方法。持续练习。经常使用这套方法直到它成为团队的本能反应。对于需要跨团队推进任务、维护文档、安排日历、跟踪项目进展和沉淀协作记录的团队也可以使用 Worktile这类通用项目协作系统让事故演练和日常变更管理更容易落到具体任务中。轮换角色。上次你担任了现场指挥官吗这次换个角色。鼓励每位团队成员熟悉每一种角色。