事后分析流程
对于每一次重大事件(SEV-2/1),我们需要进行事后分析。这是一个无责备的、详细的描述,确切地说明是什么导致了事件的发生,以及一系列步骤,以防止未来再次发生类似事件。事件响应过程本身也应包括在内。
不要忽视事后分析
不要在事件后忽视事后分析。没有事后分析,你就无法认识到你做得对的地方,你可以在哪里改进,最重要的是如何避免下次犯同样的错误。一个设计良好、无责备的事后分析允许团队持续学习,并作为一种迭代改进你的基础设施和事件响应过程的方式。
负责人指定#
第一步是指定事后分析的负责人。这是由IC在重大事件通话结束时或非常短的时间后完成的。如果你是事后分析的负责人,IC会直接通知你。负责人负责填充事后分析,查找日志,管理后续调查,并让所有相关方了解情况。请使用Slack协调后续行动。详细的步骤列表如下:
负责人职责#
作为事后分析的负责人,你负责以下事项:
- 安排事后分析会议(在共享日历上)并邀请相关人员(这应该在SEV-1的3个日历日内和SEV-2的5个工作日内安排)。
- 调查事件并从其他团队中拉入你需要的人协助调查。
- 更新页面上的所有必要内容。
- 创建后续JIRA票证(你只负责创建票证,不负责跟进解决)。
- 在会议前与适当的各方审查事后分析内容。
- 在事后分析会议上讨论主题(IC将“主持”会议并保持讨论的焦点,但你可能会做大部分的谈话)。
- 在内部传达事后分析的结果。
状态描述#
我们的事后分析有一个“状态”字段,表示事后分析目前在我们流程中的位置。以下是值的描述以及我们如何使用它们。
状态 | 描述 |
---|---|
草稿 | 表示事后分析的内容仍在进行中。 |
审查中 | 事后分析的内容已完成,并准备在事后分析会议上进行审查。 |
已审查 | 会议结束,内容已审查并达成一致。 如果有“外部消息”,客户支持团队将接受消息并在适当的情况下更新我们的状态页面。 |
已关闭 | 事后分析不再需要进一步行动(未解决的问题在JIRA中跟踪)。 如果没有“外部消息”,一旦会议结束,你可以直接跳到这个状态。 如果有“外部消息”,那么支持团队将在消息发布后更新到这个状态。 |
事后分析#
一旦你被指定为事后分析的负责人,你应该开始创建一个并更新所有相关信息。
-
(如果IC尚未完成)为事件创建一个新的事后分析。
-
安排一个事后分析会议,SEV-1在3个日历日内,SEV-2在5个工作日内。你应该在填写事后分析之前安排这个会议,只是为了让它出现在日历上。
- 在“事件事后分析会议”共享日历上创建会议。
-
开始用你拥有的所有信息填充页面。
- 时间线应该是主要的焦点。
- 时间线应包括状态/影响的重要变化和响应者采取的关键行动。
- 通过Slack的历史记录识别响应者并将他们添加到页面。
- 在这个列表中识别事件指挥官和抄写员。
- 时间线应该是主要的焦点。
-
用更详细的信息填充事后分析。
- 对于时间线中的每一项,识别一个指标或第三方页面,数据来自哪里。这可以是一个Datadog图表的链接,一个SumoLogic搜索,一条推文等。任何显示你在时间线中试图说明的数据点的内容。
- 添加事件通话录音的链接。
-
对事件进行分析。
- 捕获有关事件的所有可用数据。是什么原因导致的,受影响的客户有多少,等等。
- 你用来查找数据的任何命令或查询都应该发布在页面上,以便其他人可以看到数据是如何收集的。
- 捕获对客户的影响(通常在事件提交、延迟处理和缓慢通知传递方面)
- 识别事件的根本原因(发生了什么以及为什么发生)。
- 捕获有关事件的所有可用数据。是什么原因导致的,受影响的客户有多少,等等。
-
写下将发送给客户的外部消息。这将在事后分析会议期间审查后发送。
- 除非真的是全面中断,否则避免使用“中断”这个词,使用“事件”或“服务降级”代替。客户通常看到“中断”并假设最坏的情况。
- 查看其他以前的事后分析示例,看看你应该发送的内容。
-
在Slack中发布事后分析的链接,供内部各方审查风格和内容,你应该在会议安排前大约24小时尝试这样做。
- 有经验的事后分析作者会给你反馈事后分析的详细程度和内容。这避免了会议中的浪费时间。
-
参加事后分析会议(见下文部分了解更多信息)。
-
创建任何后续行动JIRA票证(或记下需要讨论的主题,如果我们需要决定一个方向在创建票证之前),
- 通过Slack的历史记录识别任何TODO项目。
- 给所有票证打上严重级别和日期标签。
- 任何可以减少事件再次发生的行动。
- (这里可能有一些权衡,这没关系。有时投资回报率不值得投入的努力)。
- 识别任何可以使我们的事件响应过程更好的行动。
- 小心创建太多票证。通常我们只希望创建P0/P1的东西。绝对应该处理的事情。
-
在内部传达,以便我们可以从事件中学习。
- 向相关利益相关者发送内部电子邮件,描述结果和关键学习。
- 包括事后分析的链接。
事后分析会议#
这些会议通常应持续15-30分钟,旨在作为事后分析过程的总结。我们应该讨论发生了什么,我们可以做得更好,以及我们需要采取的任何后续行动。目标是解决事实、分析或推荐行动上的任何分歧,并获得一些更广泛的意识,了解哪些问题正在导致我们的可靠性问题。
你应该邀请以下人员参加事后分析会议,
- 总是
- 事件指挥官。
- 事件指挥官的影子(如果有)。
- 事件中涉及的服务所有者。
- 事件中涉及的关键工程师/响应者。
- 受影响系统