Google Cloud 架构框架中的本文档提供了管理服务和定义响应突发事件流程的最佳实践。所有服务都会出现突发事件，因此您需要一个有详尽文档记录的流程来高效响应这些问题并缓解这些问题。
突发事件管理概览
精心设计的系统最终会有无法达到 SLO 的时候，这是不可避免的。在缺少 SLO 的情况下，根据他们以往的经验来确定可接受的服务等级。无论 SLA 包含什么内容，客户都会上报给您的技术支持团队或类似团队。
为了给客户提供合适的服务，请制定并定期测试突发事件管理方案。该方案可以只有短短一页，是包含 10 项内容的一个核对清单。此过程可帮助您的团队缩短检测时间 (TTD) 和缓解时间 (TTM)。
TTM 优于 TTR，其中的 R 是英语 Repair（修复）或 Recovery（恢复）的首字母，它通常用于表示完全修复（而不是缓解）。TTM 强调快速缓解措施，以快速结束服务中断对客户的影响，然后再启动通常需要时间更长的流程来完全解决问题。
如果系统设计良好、运营出色，则其故障间隔时间 (TBF) 也会增加。换句话说，可靠性（包括良好的突发事件管理）的运营原则旨在降低故障频率。
如需运行可靠的服务，请在突发事件管理过程中运用以下最佳做法。
指定明确的服务所有权
所有服务及其关键依赖项都必须有明确的所有者，负责遵守其 SLO。如果存在重组或团队调优，则工程主管必须确保将所有权明确移交给新团队，一并移交所需的文档和进行适当的培训。服务的所有者必须很容易被其他团队发现。
利用经过微调的提醒来缩短检测时间 (TTD)
在缩短 TTD 之前，请查看并实施架构框架可靠性类别中的将可观测性内置到您的基础架构和应用中和确定您的可靠性目标部分中的建议。例如，区分应用问题和底层云问题。
一组完善的 SLI 会在适当的时间向您的团队发出提醒，而不会触发过多提醒。如需了解详情，请参阅架构框架可靠性类别的构建高效的提醒部分或“优化您的 SLI 指标：CRE 经验谈”。
通过突发事件管理计划和培训，缩短缓解时间 (TTM)
如需降低 TTM，请制定一个经过实践检验的突发事件管理方案。轻松获取环境变化数据。确保团队知道他们可以快速应用通用缓解措施以最大限度地缩短 TTM。这些缓解技术包括排空、回滚更改、增加资源容量以及降低服务质量。
如另一份架构框架可靠性类别文档中所述，创建可靠的操作流程和工具以支持安全、快速回滚更改。
设计信息中心布局和内容以最大限度地缩短 TTM
整理服务信息中心布局和导航，以便操作员可在一两分钟内确定服务及其所有关键依赖项是否正在运行。为了快速查明问题的潜在原因，操作员必须能够扫描信息中心上的所有图表，以快速查找在触发提醒时变化显著的图表。
您的信息中心上提供了以下示例图表列表，以帮助排查问题。突发事件响应者应该能够在单个视图中对它们一目了然：
- 服务等级指标，例如成功请求数除以有效请求总数
- 配置和二进制文件发布
- 每秒向系统发出的请求数
- 每秒从系统返回的错误响应数
- 每秒从系统到其依赖项的请求数
- 每秒从系统依赖项到系统的错误响应次数
其他有助于排查问题的图表包括延迟时间、饱和度、请求大小、响应大小、查询费用、线程池利用率和 Java 虚拟机 (JVM) 指标（如果适用）。饱和度是指一些限制（例如配额或系统内存大小）导致变满。线程池利用率会查找由于池耗尽而导致的回归。
针对少数中断场景测试这些图表的位置，确保最重要的图表靠近顶部，并且图表的顺序与标准诊断工作流相匹配。您还可以使用机器学习和统计异常值检测功能来显示这些图表的子集。
针对已知的中断情况记录诊断过程和缓解措施
编写策略方案并从提醒通知链接到它们。如果这些文档可以从提醒通知中访问，那么运营商可以快速获得排查和缓解问题所需的信息。
利用无责备事后分析来了解服务中断情况并防止再次发生
构建无责备的事后分析文化和突发事件审核流程。无责备表示您的团队会客观地评估和记录问题，而不会加以责备。
错误是学习的机会，而不是批评的原因。始终以提高系统弹性为目标，使其能够从人为错误中快速恢复，甚至更好地检测和防止人为错误。从每个事后分析提取尽可能多的学习信息，并严格关注每个事后分析待办项，以降低中断频率，从而增加 TBF。
突发事件管理方案示例
已检测到生产问题（例如通过提醒或页面）或上报给我。
- 我应该委托给其他人吗？
- 是的。如果您和您的团队无法解决问题。
- 此问题是否侵犯隐私权或违反安全规定？
- 如果是，请委托给隐私权或安全团队。
- 此问题是紧急事件还是存在风险的 SLO？
- 如果不确定，请将其视为紧急事件。
- 我是否应该让更多人参与？
- 是的，如果受影响的客户超过 X%，或者解决时间超过 Y 分钟。如果不确定，请务必让更多人参与，尤其是在工作时间。
- 定义主要沟通渠道，例如 IRC、Hangouts Chat 或 Slack。
- 委托以前定义的角色，例如：
- 突发事件指挥官：负责整体协调工作。
- 沟通主管，负责处理内部和外部沟通。
- 运营主管：负责缓解问题。
- 定义突发事件的结束时间。此决策可能需要支持代表或其他类似团队确认。
- 协作完成无责备的事后分析。
- 参加突发事件事后分析审核会议，讨论相关事宜并采取行动。
建议
如需将架构框架中的指导运用到您自己的环境，请遵循以下建议：
- 制定突发事件管理方案，并培训您的团队使用该方案。
- 如需缩短 TTD，请实施建议以将可观测性内置到您的基础架构和应用中。
- 构建一个“变化内容”信息中心，以便在发生突发事件时轻松查看变化。
- 记录查询代码段，或构建包含频繁日志查询的 Looker 数据洞察信息中心。
- 评估 Firebase 远程配置以缓解移动应用的发布问题。
- 测试失败恢复（包括从备份恢复数据），以降低部分突发事件的 TTM。
- 设计并测试配置和二进制文件回滚。
- 跨区域复制数据以进行灾难恢复，并使用灾难恢复测试，以在发生区域服务中断后缩短 TTM。
- 如果企业需要高可用性来证明费用合理，则可以设计多区域架构以应对区域服务中断，从而增加 TBF。
后续步骤
详细了解如何利用以下资源构建协作式事件管理流程：
探索架构框架中的其他类别，例如系统设计、卓越运营以及安全性、隐私权和合规性。