第五阶段：响应与学习
您的应用程序响应中断事件的方式会影响其可靠性。从经验中吸取教训，并了解您的应用程序如何应对过去的中断，对于提高其可靠性也至关重要。
响应与学习阶段重点介绍您可以实施以更好地应对应用程序中断事件的实践。它还包括一些实践，可帮助您从运营团队和工程师的经验中汲取最大价值。
创建事件分析报告
事件发生时，首要行动是尽快阻止对客户和业务的进一步损害。应用程序恢复后，下一步是了解所发生的事件并制定防止再次发生的措施。这种事件后分析通常以报告的形式收集，其记录了导致应用程序受损的一系列事件，以及中断对应用程序、客户和业务的影响。此类报告将成为宝贵的学习构件，应在整个企业内广泛共享。
注意
进行事件分析时，切忌归咎责任。假设所有运营人员都根据所掌握的信息采取了最好且最恰当的行动方案。不要在报告中提及运营人员或工程师的姓名。将人为错误作为损害原因可能会导致团队成员为了自保而有所顾虑，从而使收集到的信息不准确或不完整。
一份优秀的事件分析报告，如 Amazon 更正错误（COE）流程
这种对历史事件的详细记录是极具价值的教育工具。团队应将这些报告存储在可供整个企业使用的中央存储库中，以便其他人能够查看事件并从中学习。这可以提升团队对生产环境中可能出现问题的直觉。
详细事件报告存储库也成为运营人员培训材料的来源。团队可以使用事件报告来激发桌面或现场实际试用的灵感，团队将从中获得重现报告中所记录时间线的信息。运营人员可以使用时间线中的部分信息演练场景，并描述其将要采取的行动。然后，实际试用的主持人可以根据运营人员的行动，指导应用程序应如何响应。这可以培养运营人员的故障排除技能，因此他们可以更轻松地预测问题并对其进行排查。
负责应用程序可靠性的集中式团队应将这些报告保留在一个可供整个组织访问的集中式库中。该团队还应负责维护报告模板和培训团队如何完成事件分析报告。可靠性团队应定期查看报告，以检测可以通过软件库、架构模式或团队流程变更改进的业务趋势。
进行运营回顾
正如第四阶段：运营中所述，运营回顾是回顾最近发布的功能、事件和运营指标的机会。运营回顾同时也是一个与组织内更广泛工程群体分享功能发布与事件经验教训的契机。在运营回顾期间，这些团队会回顾已回滚的功能部署、发生的事件以及这些事件的处理方式。这为整个组织的工程师提供了学习他人的经验并提出问题的机会。
向公司的工程群体开放运营回顾，以便他们可以更多地了解运营业务的 IT 应用程序以及他们可能遇到的问题类型。设计、实施和部署其他业务应用程序时，他们会运用这些知识。
检查告警性能
如运营阶段所述，告警可能会导致控制面板提醒、创建工单、发送电子邮件或寻呼运营人员。 应用程序将配置许多告警，以监控其运行的各个方面。随着时间的推移，应检查这些告警的准确性和有效性，以提高告警精度、减少误报并整合重复的提醒。
告警精度
告警应尽可能具体，以减少您解读或诊断导致告警的特定中断所花费的时间。当应对应用程序受损而发出告警时，接收告警并作出响应的运营人员必须首先解读告警传达的信息。这些信息可能是一个简单的错误代码，对应某个操作流程（例如恢复过程）；也可能包括应用程序日志中的几行，您必须查看其内容才能了解告警发出的原因。当您的团队学会更有效地运行应用程序后，他们应该完善这些告警，使其尽可能清晰简洁。
您无法预见应用程序可能出现的所有中断，因此总会有需要运营人员进行分析和诊断的一般告警。您的团队应努力减少一般告警的数量，以缩短响应时间并缩短平均维修时间（MTTR）。理想情况下，告警与自动化响应或人工响应之间应存在一对一的关系。
误报
随着时间的推移，运营人员会忽略不需要其采取任何操作，但会生成电子邮件、寻呼或工单的提醒。 定期（或作为事件分析的一部分）检查这些告警，以确定经常被忽略或不需要运营人员采取任何行动的告警（误报）。 您应该努力消除告警或改进告警，使其向运营人员发出可操作的提醒。
漏报
在事件发生期间，配置为在事件发生期间发出提醒的告警可能会失效，这可能是因为某个事件以意想不到的方式影响了应用程序。 作为事件分析的一部分，您应该查看本应发出但未发出的告警。应该努力改进这些告警，使其更好地反映事件可能引发的各种情况。或者，您可能必须创建其他告警，这些告警虽然对应相同的中断事件，但由不同的中断症状引发。
重复提醒
影响应用程序的中断可能会导致多种症状，并可能产生多个告警。 您应定期（或作为事件分析的一部分）查看已发出的告警和提醒。 如果运营人员收到重复的提醒，请创建汇总告警，将其合并为一条提醒消息。
进行指标检查
您的团队应收集有关应用程序的运营指标，例如按严重性划分的每月事件数量、检测事件的时间、确定原因的时间、修复的时间以及创建的工单数量、发送的提醒数和发出的寻呼数。至少每月检查一次这些指标，以了解运营人员的负担、其处理的信噪比（例如，信息警报与可操作提醒），以及团队是否提升了其控制下的应用程序的运营能力。利用此检查了解运营团队可衡量方面的趋势。向团队征求有关如何改进这些指标的建议。
提供培训与赋能
详细记录导致事件或异常行为的应用程序及其运行环境并非易事。此外，模拟应用程序的韧性以预测此类场景也并不简单。您的组织应投入资源，为运营团队和开发人员提供培训与赋能资料，帮助他们参与韧性模拟、事件分析、实际试用和混沌工程实验等活动。这将提升团队生成报告的准确性和所掌握知识的深度。这些团队也将能够更好地预测故障，而无需依赖少数经验丰富的工程师团队通过定期检查来提供其洞察。
创建事件知识库
事件报告是事件分析的标准输出。即使应用程序没有受到损害，也应使用相同或类似的报告来记录检测到异常应用程序行为的场景。使用相同的标准化报告结构来收集混沌实验和实际试用的结果。该报告显示了导致事件或其他意外行为的应用程序及其环境的快照。您应该将这些标准化报告存储在可供企业内所有工程师访问的中央存储库中。
然后，运营团队和开发人员可以搜索此知识库，以了解过去哪些原因中断了应用程序、哪些类型的场景可能导致中断，以及哪些因素可以防止应用程序受损。该知识库成为提升运营团队和开发人员技能的加速器，使他们能够分享知识和经验。此外，您可以将这些报告用作实际试用或混沌实验的培训材料或场景，以提升运营团队的直觉和排查中断的能力。
注意
标准化报告格式还能让读者感到熟悉，并帮助他们更快地找到所需的信息。
深入实施韧性
如前所述，高成熟度的组织会针对一次告警实施多重响应。由于无法保证响应一定有效，因此通过分层响应，应用程序能够更好地实现优雅降级。我们建议您为每个指标至少实施两种响应，以确保单一响应不会成为可能导致 DR 场景的单点故障。 这些响应层应按顺序创建，这样仅在上一个响应无效时，才会执行后续响应。您不应该对单个告警运行多个分层的响应。相反地，应使用告警来指示响应是否失败；如果是，则启动下一层响应。
