针对高速团队的事件管理
事后析误
我们在 Atlassian 施行无指责的事后析误,以确保我们了解并解决严重性级别为 2 或更高的每个事件的根本原因。以下是我们内部文档的摘要,描述了我们如何在 Atlassian 执行事后析误。

获取印刷版或 PDF 版手册
印刷版《事件管理手册》限量供应,可应要求免费寄送。或者,也可下载 PDF 版本。
字段 | 说明 | 示例 |
事件摘要 | 用几句话概括事件。包括严重性、原因以及影响持续的时间。 | 在<日期>的<事件的时间范围,例如 14:30 到 15:00> 之间,<数量> 位客户遇到了<事件症状>。该事件是由在<导致发生该事件的部署或更改的时间>进行的部署引发的。部署包含一项代码更改,<更改的描述或原因>。该部署中的缺陷导致了<问题描述>。 <系统>检测到了该事件。我们通过<采取的决议行动>缓解了事件。 这一<严重性级别>事件影响了 X% 的客户。 <支持工作单和/或社交媒体文章的数量>与该事件相关。 |
致因 | 描述导致该事件发生的情况,例如,之前做出的更改引入了潜在缺陷。 | 在<日期> <时间>,(<距离客户受到影响的时长>)一项更改被引入到了<产品或服务>以...<引发该事件的更改描述>。这项更改导致了...<更改造成影响的描述>。 |
故障 | 描述哪些方面不符合预期。附上相关图表的屏幕截图或显示故障情况的数据。 | 在<时间段>期间,<数量> 个响应未正确发送至 X% 的请求。 |
影响 | 描述内部和外部客户在事件发生期间看到的内容。包括提出的支持案例数量。 | 在<日期> <时间范围>的<时长>中,遇到了<事件摘要>。 这影响了<数量>的客户(占<系统或服务> 所有客户的 X%),这些客户遇到了<客户遇到的症状描述>。 引发了<支持请求单和社交媒体文章数量>。 |
检测 | Atlassian 是如何以及何时检测到该事件的? 如何改进检测时间?作为一项思考练习,如何把该时间缩短一半? | 检测到事件的标志:<警报的类型>被触发,<呼叫的团队或人员>得到了呼叫。然后,他们必须呼叫<二次响应人员或团队>,因为他们不负责将服务写入磁盘,这导致响应延迟了<时长>。 <负责改进的团队>将制定<改进描述>,以便<改进的影响>。 |
响应 | 谁做出了响应?何时以及如何响应的?我们的响应存在任何延迟或障碍吗? | 在协调世界时 14:34 收到呼叫后,KITT 工程师于 14:38 在事件聊天室中上线。但是,待命的工程师没有足够的 Escalator 自动扩展器方面的背景,因此系统在 14:50 发出了进一步的警报,一名高级 KITT 工程师在 14:58 进入了聊天室。 |
恢复 | 描述服务恢复的方式和时间。您是如何找到减轻影响的方法的? 需要提出更多问题,具体取决于场景:如何缩短缓解用时?作为思考练习,如何把该时间缩短一半? | 恢复是三管齐下的响应:
|
时间表 | 按时间顺序提供详细的事件时间线,加注时区。 包括任何的致因;开始产生影响的时间;检测时间;上报、决策和更改;影响结束的时间。 | 所有时间均为协调世界时。 11:48 - K8S 1.9 的控制平面升级完成12:46 - Goliath 升级至 V1.9 完成,包括 cluster-autoscaler 和 BuildEng 调度器实例 14:20 - Build Engineering 向 KITT Disturbed 报告了一个问题 14:27 - KITT Disturbed 开始调查特定 EC2 实例 (ip-203-153-8-204) 出现的故障 14:42 - KITT Disturbed 隔离了特定节点 14:49 - BuildEng 报告该问题影响了不止一个节点。问题涉及 86 个实例,表明故障具有系统性 15:00 - KITT Disturbed 建议切换到标准调度器 15:34 - BuildEng 报告了 300 个单元出现故障 16:00 - BuildEng 终止了所有出现故障的构建并出具了 OutOfCpu 报告 16:13 - BuildEng 报告故障在新的构建中不断重新出现,而且不是暂时性的。 16:30 - KITT 将故障识别为事件,并将其作为事件执行。 16:36 - KITT 禁用了 Escalator 自动扩展器以防止自动扩展器删除计算,从而缓解该问题。 16:40 - KITT 确认 ASG 处于稳定状态,群集负载正常,客户受到的影响已解决。 |
五问法 | 使用根本原因确定法。 首先是影响,询问为什么会出现这种情况以及为什么会产生这样的影响。不断地问为什么,直至找出根本原因。 将您的“为什么”作为列表记录在此处或该问题随附的图表中。 |
|
根本原因 | 根本原因是什么?根本原因是指为了阻止此类事件再次发生而需要改变的东西。 | <导致缺陷的原因或出现缺陷的服务>连接池处理中的缺陷导致在出现故障的情况下泄露连接,以及对连接状态缺乏可见性。 |
待办事项检查 | 您的待办事项中的任务可以防止这种情况发生或大大降低其影响吗?如果可以,为什么没有这样做? 此处的如实评估有助于弄清过去围绕优先级和风险做出的决策。 | 未具体说明。对流类型的改进是已知的正在进行的任务,具有适当的固定程序(例如,在更改/创建文件时添加流类型)。修复集成测试的请求单已经完成,但在尝试时失败 |
重现 | 该事件(具有相同的根本原因)之前发生过吗?如果之前发生过,为什么会再次发生? | 这一相同的根本原因导致了事件 HOT-13432、HOT-14932 和 HOT-19452 的发生。 |
吸取的经验教训 | 我们吸取了哪些经验教训? 讨论哪些方面做得好、哪些方面本来可以做得更好,以及我们在哪些方面比较幸运,找到了改进机会。 |
|
纠正措施 | 我们要做些什么才能确保此类事件不再发生?谁将采取行动以及何时采取行动? 创建“优先行动”事务,以链接到跟踪每项行动的事务。 |
|
场景 | 直接原因及行动 | 根本原因 | 根本原因缓解措施 |
Stride “Red Dawn”队的服务没有 Datadog 监视器以及针对其服务的待命警报,或者它们未正确配置。 | 团队成员没有针对新服务配置监控和警报。 为这些服务配置监控和警报。 | 没有制定用于支持新服务的流程,包括监控和警报。 | 创建一个用于支持新服务的流程,并教导团队遵循该流程。 |
由于升级到无法在 IE 11 上运行的 Fabric Editor,因此 Stride 在 IE11 上无法使用。 | 依赖关系的升级。 复原升级。 | 未进行跨浏览器兼容性测试。 | 自动进行连续跨浏览器兼容性测试。 |
来自 Micros EU 的日志未到达日志记录服务。 | 为 Micros 提供的用以发送日志的角色不正确。 更正角色。 | 我们无法确定环境中的日志记录何时开始不工作。 | 针对任何环境中丢失的日志添加监控和警报。 |
由以前的 AWS 事件触发,Confluence Vertigo 节点耗尽了到 Media 的连接池,导致客户遇到间歇性连接和介质错误问题。 | AWS 出现故障。 获得 AWS 事后析误。 | Confluence 连接池处理中的缺陷导致在出现故障的情况下泄露连接,以及对连接状态缺乏可见性。 | 修复缺陷并添加监控,以便在未来检测类似的情况,防止它们产生影响。 |
类别 | 定义 | 您应该怎么做? |
缺陷 | Atlassian 对代码做出的更改(这是一种特定类型的更改) | 测试。金丝雀。逐步推出并观察它们。使用功能标志。与质量工程师沟通。 |
更改 | Atlassian 所做的更改(除代码之外) | 改进您进行更改的方法,例如,您的更改审查或更改管理流程。“缺陷”一栏里的内容也适用于这里。 |
规模 | 扩展失败(例如,无视资源限制或缺少容量规划) | 您服务的资源限制是什么?它们是否受到监控并会触发警报?如果您没有容量计划,请制定一份容量计划。如果您有容量计划,还需要考虑哪些新的限制? |
架构 | 设计与操作条件不一致 | 审查您的设计。您需要更换平台吗? |
相关性 | 第三方(非 Atlassian)服务出现故障 | 您是否要管控第三方出现故障的风险?我们是否做出了接受风险的业务决策,还是需要制定缓解措施?请参阅下面的“与依赖关系相关的根本原因”。 |
未知 | 不能确定(行动是提高诊断能力) | 通过添加日志记录、监控、调试和类似内容来提高系统的可观察性。 |
类别 | 要问的问题 | 示例 |
调查该事件 | “导致这一事件的原因是什么?为什么?”确定根本原因是您的最终目标。 | 日志分析、绘制请求路径图、检查堆转储 |
缓解该事件 | “我们采取了哪些立即行动来解决和管理这一特定事件?” | 回滚、择优挑选、推送配置文件、与受影响的用户沟通 |
修复该事件造成的损害 | “我们是如何解决该事件造成的直接或间接损害?” | 恢复数据、修理机器、删除流量重新路由 |
检测未来事件 | “我们如何缩短准确检测类似故障的用时?” | 监控、警报、对输入/输出进行真实性检查 |
缓解未来事件 | “我们如何降低此类未来事件的严重性和/或持续时间?” “我们如何降低此类事件下次发生时受影响的用户百分比?” | 优雅降级;排除非关键结果;出故障时自动打开;通过仪表板或手册增强当前的实践;更改事件流程 |
预防未来事件 | “我们如何防止此类故障再次发生?” | 代码库稳定性改进、更彻底的单元测试、输入验证以及错误条件的稳健性、配置更改 |
我们还采纳了 Lueder 和 Beyer 有关如何表述事后析误行动的建议。
表述事后析误行动:
能否正确表述事后析误行动,会带来不同的结果:轻松完成;或者由于不可行或拖延而导致无限期延迟。表述恰当的事后析误行动应该具有以下特征:
可操作:使用以动词开头的句子表述每项行动。行动应该产生有用的结果,而不是一个过程。例如,“列举出关键依赖关系的列表”是一项好的行动,而“调查依赖关系”则不是。
具体:尽可能狭隘地定义每项行动的范围,明确工作中包含和不包含的内容。
有限制:每项行动的措辞应该能够表明如何判断何时结束,而不是让行动没有最终期限或处于一直进行的状态。
原表述... | 修改后的表述... |
调查该场景的监控。 | (可行动)只要该服务返回 >1% 错误,即针对所有这些出错情况添加警报。 |
修复导致运行中断的问题。 | (具体)安全地处理用户地址表单输入中的无效邮政编码。 |
确保工程师在更新之前检查数据库模式是否可以解析。 | (有限制)为模式更改添加自动的预提交检查。 |
Setting up an on-call schedule with Opsgenie
In this tutorial, you’ll learn how to set up an on-call schedule, apply override rules, configure on-call notifications, and more, all within Opsgenie.
阅读本教程Learn incident communication with Statuspage
In this tutorial, we’ll show you how to use incident templates to communicate effectively during outages. Adaptable to many types of service interruption.
阅读本教程