本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
第 5 阶段：回应和学习
您的应用程序如何响应破坏性事件会影响其可靠性。从经验中学习，以及您的应用程序如何应对过去的中断，对于提高其可靠性也至关重要。
“响应和学习” 阶段侧重于您可以实施的实践，以更好地响应应用程序中的破坏性事件。它还包括一些实践，可帮助您从运营团队和工程师的经验中获得最大限度的学习。
创建事件分析报告
当事件发生时，第一步是尽快防止对客户和业务造成进一步损害。应用程序恢复后，下一步是了解发生了什么，并确定防止再次发生的步骤。这种事后分析通常以报告的形式获取，该报告记录了导致应用程序受损的一系列事件，以及中断对应用程序、客户和业务的影响。此类报告成为宝贵的学习工具，应在整个企业中广泛共享。
注意
在不指责任何责任的情况下进行事件分析至关重要。假设所有操作员都根据所掌握的信息采取了最好、最合适的行动方案。不要在报告中使用操作员或工程师的姓名。将人为错误作为损伤原因可能会导致团队成员为了保护自己而受到警惕，从而导致捕获不正确或不完整的信息。
一份好的事件分析报告，如 Amazon错误更正 (COE) 流程
这张详细的历史事件照片是一种强大的教育工具。团队应将这些报告存储在可供整个企业使用的中央存储库中，以便其他人可以查看事件并从中学习。这可以提高你的团队对生产中可能出什么问题的直觉。
详细的事件报告库也成为操作员培训材料的来源。团队可以使用事件报告来激发桌面或现场比赛日的灵感，在这些日子里，球队可以获得回放报告中捕获的时间表的信息。操作员可以使用时间表中的部分信息浏览场景，并描述他们将要采取的行动。然后，游戏日的版主可以根据操作员的行为提供有关应用程序如何响应的指导。这可以培养操作员的故障排除技能，因此他们可以更轻松地预测问题并对其进行故障排除。
负责应用程序可靠性的集中式团队应将这些报告保存在一个供整个组织访问的集中式库中。该团队还应负责维护报告模板并培训团队如何完成事件分析报告。可靠性团队应定期审查报告，以发现整个业务的趋势，这些趋势可以通过软件库、架构模式或团队流程的更改来解决。
进行运营审查
正如第 4 阶段：运营中所述，运营审查是审查最近发布的功能、事件和运营指标的机会。运营审查也是与组织中更广泛的工程界分享从功能发布和事件中获得的经验的机会。在运营审查期间，这些团队会审查已回滚的功能部署、发生的事件以及如何处理这些事件。这为整个组织的工程师提供了从他人的经验中学习和提出问题的机会。
向贵公司的工程界开放运营审查，以便他们可以更多地了解运营业务的 IT 应用程序以及他们可能遇到的问题类型。他们将在设计、实施和部署其他业务应用程序时随身携带这些知识。
查看警报性能
如操作阶段所述，警报可能会导致仪表板警报、创建工单、发送电子邮件或呼叫操作员。 应用程序将配置许多警报，以监控其运行的各个方面。随着时间的推移，应审查这些警报的准确性和有效性，以提高警报精度，减少误报并整合重复的警报。
警报精度
警报应尽可能具体，以减少解释或诊断导致警报的特定中断所花费的时间。当针对应用程序缺陷而发出警报时，接收警报并做出响应的操作员必须首先解释警报传达的信息。这些信息可能是一个简单的错误代码，它映射到操作流程（例如恢复过程），也可能包括应用程序日志中的几行，您必须查看这些行才能了解警报发出的原因。当您的团队学会更有效地操作应用程序时，他们应该完善这些警报，使其尽可能清晰简洁。
您无法预见应用程序可能出现的所有中断，因此总会有需要操作员进行分析和诊断的常规警报。您的团队应努力减少常规警报的数量，以缩短响应时间并缩短平均维修时间 (MTTR)。理想情况下，警报与自动或人工执行的响应之间应该存在 one-to-one 关系。
误报
随着时间的推移，操作员会忽略那些不需要操作员采取任何操作但会以电子邮件、页面或工单形式发出警报的警报。 定期或作为事件分析的一部分，查看警报，以确定那些经常被忽略或不需要操作员采取任何行动（误报）的警报。 您应该努力移除警报，或者改进警报，使其向操作员发出可操作的警报。
假阴性
在事件发生期间，配置为在事件发生期间发出警报的警报可能会失败，这可能是因为某个事件以意想不到的方式影响了应用程序。 作为事件分析的一部分，您应该查看本应发出但未触发的警报。您应该努力改进这些警报，使其更好地反映事件可能出现的情况。或者，您可能必须创建其他警报，这些警报映射到相同的中断但由不同的中断症状引发。
重复警报
影响应用程序的中断可能会导致多种症状，并可能导致多个警报。 您应定期或作为事件分析的一部分，查看已发出的警报和警报。 如果操作员收到重复的警报，请创建汇总警报，将其合并为一条警报消息。
进行指标审查
您的团队应收集有关您的应用程序的运营指标，例如每月按严重性划分的事件数量、检测事件的时间、确定原因的时间、补救的时间以及创建的工单、发送的警报和提出的页面数量。至少每月审查一次这些指标，以了解运营人员的负担、他们处理的 signal-to-noise 比例（例如，信息警报与可操作警报），以及团队是否在提高其控制下操作应用程序的能力。使用这篇评论来了解运营团队可衡量方面的趋势。向团队征求有关如何改进这些指标的想法。
提供培训和支持
很难详细描述导致事件或意外行为的应用程序及其环境。此外，对应用程序的弹性进行建模以预测此类场景并不总是那么简单。您的组织应投资于培训和支持材料，供运营团队和开发人员参与弹性建模、事件分析、游戏日和混沌工程实验等活动。这将提高您的团队生成的报告以及他们捕获的知识的真实性。这些团队还将更有能力预测故障，而不必依赖规模更小、经验更丰富的工程师团队，他们必须通过定期的审查提供见解。
创建事件知识库
事件报告是事件分析的标准输出。即使应用程序没有受到损害，也应使用相同或相似的报告来记录检测到应用程序异常行为的场景。使用相同的标准化报告结构来捕捉混沌实验和游戏日的结果。该报告显示了导致事件或其他意外行为的应用程序及其环境的快照。您应该将这些标准化报告存储在中央存储库中，供企业内所有工程师访问。
然后，运营团队和开发人员可以搜索此知识库，以了解过去哪些原因中断了应用程序，哪些类型的场景可能导致中断，以及哪些因素可以防止应用程序受损。该知识库成为提高运营团队和开发人员技能的加速器，使他们能够分享知识和经验。此外，您可以将这些报告用作比赛日或混乱实验的培训材料或场景，以提高运营团队的直觉和排除中断的能力。
注意
标准化的报告格式还可以为读者提供熟悉感，并帮助他们更快地找到所需的信息。
深入实现弹性
如前所述，高级组织将对警报实施多个响应。无法保证响应会有效，因此，通过对响应进行分层，应用程序将更有能力顺利地失败。我们建议您为每个指标至少实现两个响应，以确保单个响应不会成为可能导致灾难恢复场景的单点故障。 这些层应按顺序创建，以便只有在先前的响应无效时才会执行连续的响应。您不应该对单个警报运行多个分层响应。取而代之的是使用警报来指示响应是否失败，如果是，则启动下一个分层响应。
