针对高速团队的事件管理
事后析误
我们在 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% 错误,即针对所有这些出错情况添加警报。 |
修复导致运行中断的问题。 | (具体)安全地处理用户地址表单输入中的无效邮政编码。 |
确保工程师在更新之前检查数据库模式是否可以解析。 | (有限制)为模式更改添加自动的预提交检查。 |