Well-Architected Framework：可靠性核心

Last reviewed 2025-02-14 UTC

Google Cloud Well-Architected Framework 中的可靠性核心提供了相关原则和建议，可帮助您在 Google Cloud中设计、部署和管理可靠的工作负载。

本文档面向 Cloud Architect、开发者、平台工程师、管理员和网站可靠性工程师。

可靠性是指系统在指定条件下持续执行其预期功能并保持服务不中断的能力。可靠性最佳实践包括冗余、容错设计、监控和自动恢复流程。

作为可靠性的一部分，弹性是指系统在承受故障或意外中断并从中恢复的同时保持性能的能力。Google Cloud 功能（例如多区域部署、自动备份和灾难恢复解决方案）可以帮助您提高系统的弹性。

可靠性对您的云策略非常重要，原因有很多，其中包括：

  • 最短停机时间：停机可能会导致收入损失、工作效率下降和声誉受损。弹性架构有助于确保系统在发生故障时能够继续运行，或在发生故障后高效恢复。
  • 更出色的用户体验：用户希望与技术进行顺畅的互动。弹性系统有助于保持一致的性能和可用性，即使在需求量大或出现意外问题时，也能提供可靠的服务。
  • 数据完整性：故障可能会导致数据丢失或损坏。 弹性系统会实施备份、冗余和复制等机制，以保护数据并确保数据保持准确且可访问。
  • 业务连续性：您的业务依赖于技术来执行关键操作。弹性架构有助于确保在发生灾难性故障后业务连续性，从而使业务功能能够继续运行，而不会发生重大中断，并支持快速恢复。
  • 合规性：许多行业对系统可用性和数据保护都有监管要求。弹性架构可确保系统保持正常运行和安全，从而帮助您满足这些标准。
  • 降低长期成本：弹性架构需要前期投资，但弹性有助于防止代价高昂的停机、避免被动修复并提高资源使用效率，从而降低长期成本。

组织心态

为了让系统可靠运行，您需要制定计划并确立策略。 此策略必须包括培训，以及在其他计划中优先考虑可靠性的权限。

明确规定整个组织（包括开发、产品管理、运营、平台工程和站点可靠性工程 (SRE)）都负责可靠性。 即使是专注于业务的群组（例如营销和销售），也会影响可靠性。

每个团队都必须了解其应用的可靠性目标和风险。团队必须对这些要求负责。必须优先处理可靠性和常规产品功能开发之间的冲突，并根据情况上报。

从整体上规划和管理所有职能和团队的可靠性。 考虑设置一个包含可靠性支柱的云卓越中心 (CCoE)。如需了解详情，请参阅通过云技术卓越中心 (COE) 优化组织的 Cloud Journey。

可靠性重点领域

您为设计、部署和管理可靠的系统而执行的活动可归类为以下重点领域。此支柱中的每个可靠性原则和建议都与其中一个重点领域相关。

  • 范围界定：为了解您的系统，请对其架构进行详细分析。您需要了解各个组件、它们的工作方式和互动方式、数据和操作在系统中的流动方式，以及可能出现的问题。识别潜在的故障、瓶颈和风险，帮助您采取行动来缓解这些问题。
  • 观测：为帮助防止系统故障，请实施全面且持续的观测和监控。通过此观察，您可以了解趋势并主动发现潜在问题。
  • 响应：为了降低故障的影响，请采取适当的响应措施并高效恢复。自动响应还有助于减少故障的影响。即使有周密的计划和控制措施，故障仍可能发生。
  • 学习：为了防止故障再次发生，请从每次经历中汲取经验教训，并采取适当的措施。

使用智能体 skill 评估工作负载

如需让 AI 智能体根据此支柱中的原则和建议评估您的云工作负载，请使用 google-cloud-waf-reliability 技能，该技能可在 GitHub 的 Google 智能体技能代码库中找到。

如需安装技能，请在智能体的客户端或终端中运行以下命令：

npx skills add google/skills --skill google-cloud-waf-reliability

根据提示，指定要为哪些 AI 智能体安装 skill，并设置安装范围（项目或全局）。

核心原则

Well-Architected Framework 的可靠性核心中的建议与以下核心原则相对应：

贡献者

作者：

其他贡献者：

根据用户体验目标定义可靠性

Google Cloud Well-Architected Framework 可靠性核心中的这一原则可帮助您评估用户体验，然后将评估结果映射到可靠性目标和指标。

此原则与可靠性的范围界定 重点领域相关。

原则概览

可观测性工具会提供大量数据，但并非所有数据都与对用户的影响直接相关。例如，您可能会观察到 CPU 使用率高、服务器操作缓慢，甚至任务崩溃。但是，如果这些问题不影响用户体验，则不构成服务中断。

为了衡量用户体验，您需要区分内部系统行为和面向用户的问题。重点关注用户请求成功率等指标。不要仅依赖于以服务器为中心的指标（例如 CPU 使用率），这可能会导致对服务可靠性的结论产生误导。真正的可靠性意味着用户可以持续有效地使用您的应用或服务。

建议

为了帮助您有效衡量用户体验，请考虑以下部分中的建议。

衡量用户体验

为了真正了解服务的可靠性，请优先考虑反映用户实际体验的指标。例如，衡量用户的查询成功率、应用延迟时间和错误率。

理想情况下，应直接从用户的设备或浏览器收集这些数据。如果无法直接收集这些数据，请逐步将系统中的衡量点移离用户。例如，您可以使用负载均衡器或前端服务作为测量点。这种方法可帮助您在问题对用户产生重大影响之前发现并解决问题。

分析用户体验历程

如需了解用户如何与您的系统交互，您可以使用 Cloud Trace 等跟踪工具。通过跟踪用户在应用中的历程，您可以找到可能会降低用户体验的瓶颈和延迟问题。Cloud Trace 会捕获服务架构中每个跃点的详细性能数据。这些数据有助于您更高效地识别和解决性能问题，从而提供更可靠、更令人满意的用户体验。

设定切合实际的可靠性目标

Google Cloud Well-Architected Framework 可靠性核心中的这一原则可帮助您为 Google Cloud中的工作负载定义在技术上可行的可靠性目标。

此原则与可靠性的范围界定 重点领域相关。

原则概览

在设计系统时，应确保其可靠性足以让用户满意。这可能看起来有悖常理，但 100% 可靠性的目标通常不是最有效的策略。更高的可靠性可能会导致成本显著增加，这既体现在财务投资方面，也体现在对创新的潜在限制方面。如果用户已经对当前的服务水平感到满意，那么进一步提高满意度的努力可能会带来较低的投资回报率。相反，您可以将资源更好地用在其他地方。

您需要确定让用户满意的可靠性水平，并确定增量改进的成本开始超过收益的时间点。确定了足够的可靠性水平后，您就可以有策略地分配资源，并专注于为用户带来更大价值的功能和改进。

建议

如需设定切合实际的可靠性目标，请考虑以下各子部分中的建议。

接受部分故障并确定组件的优先级

力争实现高可用性（例如 99.99% 的正常运行时间），但不要将目标设置为 100% 的正常运行时间。承认有些失败是不可避免的。

100% 正常运行时间与 99.99% 目标之间的差距就是故障容许度。这种差距通常称为错误预算。错误预算可以帮助您承担风险并进行创新，这是任何企业保持竞争力的基础。

优先考虑系统中关键组件的可靠性。 接受不太重要的组件可以具有更高的故障容忍度。

平衡可靠性和费用

如需确定系统的最佳可靠性级别，请进行全面的成本效益分析。

请考虑系统要求、故障后果以及组织对特定应用的风险承受能力等因素。请务必考虑您的灾难恢复指标，例如恢复时间目标 (RTO) 和恢复点目标 (RPO)。确定在预算和其他限制条件下可接受的可靠性级别。

寻找在不影响基本可靠性功能的前提下提高效率和降低成本的方法。

通过资源冗余构建高可用性系统

Google Cloud Well-Architected Framework 可靠性核心中的这一原则提供了规划、构建和管理资源冗余的建议，可帮助您避免故障。

此原则与可靠性的范围界定 重点领域相关。

原则概览

在确定所需的可靠性级别后，您必须设计系统以避免任何单点故障。系统中的每个关键组件都必须跨多个机器、可用区和区域进行复制。例如，关键数据库不能仅位于一个区域，元数据服务器不能仅部署在一个可用区或区域。在这些示例中，如果唯一的可用区或区域发生服务中断，则系统会发生全球服务中断。

建议

如需构建冗余系统，请考虑以下各子部分中的建议。

确定故障域并复制服务

从单个虚拟机到区域，规划出系统的故障域，并设计跨故障域的冗余。

为确保高可用性，请将服务和应用分布并复制到多个可用区和区域。将系统配置为自动故障切换，以确保在可用区或区域服务中断时，服务和应用仍可继续使用。

如需查看多可用区和多区域架构的示例，请参阅为 Google Cloud中的工作负载设计可靠的基础设施。

及时检测和解决问题

持续跟踪故障域的状态，以便及时检测和解决问题。

您可以使用Google Cloud Service Health 信息中心监控所有区域中 Google Cloud 服务的当前状态。您还可以使用 Personalized Service Health 查看与项目相关的突发事件。您可以使用负载均衡器检测资源健康状况，并自动将流量路由到健康的后端。如需了解详情，请参阅健康检查概览。

测试故障切换场景

与消防演习类似，定期模拟故障，以验证复制和故障切换策略的有效性。

如需了解详情，请参阅模拟区域级 MIG 的可用区服务中断情况和模拟 GKE 区域级集群中的可用区故障。

利用横向可伸缩性优势

Google Cloud Well-Architected Framework可靠性核心中的这一原则提供了相关建议，可帮助您使用横向可伸缩性。通过使用横向可伸缩性，您可以帮助确保Google Cloud 中的工作负载能够高效扩缩并保持性能。

此原则与可靠性的范围界定 重点领域相关。

原则概览

将系统重新设计为横向架构。为了应对流量或数据量的增长，您可以添加更多资源。您还可以在不使用资源时将其移除。

如需了解横向伸缩的价值，请考虑纵向伸缩的限制。

纵向伸缩的一个常见场景是将 MySQL 数据库用作包含关键数据的主数据库。随着数据库使用量的增加，需要更多 RAM 和 CPU。最终，数据库会达到宿主机的内存上限，需要进行升级。此过程可能需要重复多次。问题在于，数据库的增长量存在硬性限制。虚拟机大小并非无限制。数据库可能会达到无法再添加更多资源的程度。

即使资源不受限制，大型虚拟机也可能会成为单点故障。主数据库虚拟机出现任何问题都可能会导致错误响应，或导致影响所有用户的系统级中断。避免单点故障，如通过资源冗余构建高可用性系统中所述。

除了这些伸缩限制之外，纵向伸缩往往成本更高。随着购买的机器计算能力和内存不断增加，费用可能会呈指数级增长。

相比之下，横向伸缩的成本可能更低。在专为伸缩而设计的系统中，横向伸缩的潜力几乎是无限的。

建议

如需从单虚拟机架构过渡到水平多机架构，您需要仔细规划并使用合适的工具。为帮助您实现横向伸缩，请考虑以下小节中的建议。

使用托管式服务

托管式服务无需手动管理横向伸缩。例如，借助 Compute Engine 托管式实例组 (MIG)，您可以添加或移除虚拟机，以横向扩缩应用。对于容器化应用，Cloud Run 是一个无服务器平台，可根据传入流量自动扩缩无状态容器。

推行模块化设计

模块化组件和清晰的接口可帮助您根据需要伸缩单个组件，而不是伸缩整个应用。如需了解详情，请参阅性能优化支柱中的促进模块化设计。

实现无状态设计

将应用设计为无状态，即不存储任何本地数据。这样，您就可以添加或移除实例，而无需担心数据一致性。

利用可观测性检测潜在故障

Google Cloud Well-Architected Framework 的可靠性核心中的这一原则提供了相关建议，可帮助您主动识别可能发生错误和故障的区域。

此原则与可靠性的观察 重点领域相关。

原则概览

如需维护和提高Google Cloud中工作负载的可靠性，您需要使用指标、日志和跟踪记录来实现有效的可观测性。

  • 指标是指您希望在特定时间间隔内为应用跟踪的活动的数值衡量结果。例如，您可能需要跟踪请求速率和错误率等技术指标，这些指标可用作服务等级指标 (SLI)。您可能还需要跟踪特定于应用的业务指标，例如已下订单和已收付款。
  • 日志是应用或系统内发生的离散事件的时间戳记录。该事件可能是故障、错误或状态变化。日志可能包含指标，您也可以将日志用于 SLI。
  • 跟踪记录表示单个用户或事务通过多个单独的应用或应用组件的历程。例如，这些组件可以是微服务。跟踪记录可帮助您跟踪历程中使用了哪些组件、瓶颈在哪里以及历程花费了多长时间。

指标、日志和跟踪记录可帮助您持续监控系统。 全面的监控功能可帮助您找出错误发生的位置和原因。您还可以在发生错误之前检测到潜在的故障。

建议

为了高效检测潜在故障，请考虑以下小节中的建议。

获取全面的数据洞见

如需跟踪响应时间和错误率等关键指标，请使用 Cloud Monitoring 和 Cloud Logging。这些工具还可帮助您确保指标始终满足工作负载的需求。

如需做出以数据为依据的决策，请分析默认服务指标，以了解组件依赖项及其对整体工作负载性能的影响。

如需自定义监控策略，请使用 Google Cloud SDK 创建和发布您自己的指标。

执行主动问题排查

在 Google Cloud中，为工作负载的所有组件实现强大的错误处理机制并启用日志记录。启用 Cloud Storage 访问日志和 VPC 流日志等日志。

配置日志记录时，请考虑相关费用。如需控制日志记录费用，您可以在日志接收器上配置排除过滤器，以排除某些日志，使其不被存储。

优化资源利用率

监控 CPU 消耗、网络 I/O 指标和磁盘 I/O 指标，以检测 GKE、Compute Engine 和 Managed Service for Apache Spark 等服务中预配不足和预配过度的资源。如需查看受支持服务的完整列表，请参阅 Cloud Monitoring 概览。

确定提醒的优先级

对于提醒，请重点关注关键指标，设置适当的阈值以最大限度地减少提醒疲劳，并确保及时响应重大问题。这种有针对性的方法可让您主动维护工作负载可靠性。如需了解详情，请参阅提醒概览。

从设计上支持优雅降级

Google Cloud Well-Architected Framework 可靠性核心中的这一原则提供了相关建议，可帮助您设计 Google Cloud 工作负载，使其能够优雅地处理故障。

此原则与可靠性的响应 重点领域相关。

原则概览

优雅降级是一种设计方法，当系统遇到高负载时，会继续运行，但性能或准确性可能会降低。即使系统的工作不是最佳状态，优雅降级也可确保系统持续可用并防止完全故障。当负载恢复到可管理的水平时，系统会恢复完整功能。

例如，在负载较高期间，Google 搜索会优先显示排名较高的网页中的结果，这可能会牺牲一些准确性。当负载降低时，Google 搜索会重新计算搜索结果。

建议

如需设计可优雅降级的系统，请考虑以下各小节中的建议。

实现节流

确保您的副本可以独立处理过载，并可以在高流量场景中限制传入请求。这种方法有助于防止因可用区之间过量流量的转移而导致的级联故障。

使用 Apigee 等工具控制高流量时段的 API 请求速率。您可以配置政策规则，以反映您希望如何缩减请求。

尽早丢弃多余的请求

将系统配置为在前端层丢弃多余的请求，以保护后端组件。丢弃部分请求可防止全局故障，并使系统能够更平稳地恢复。采用这种方法，部分用户可能会遇到错误。不过，与断路（在过载期间丢弃所有流量）等方法相比，您可以最大限度地减少服务中断的影响。

处理部分错误和重试

构建应用，以无缝处理部分错误和重试。这种设计有助于确保在高负载场景中尽可能多地处理流量。

测试过载场景

为了验证限制和请求丢弃机制是否有效，请定期模拟系统中的过载情况。测试有助于确保您的系统已准备好应对实际流量激增。

监控流量高峰

使用分析和监控工具预测并应对流量激增，避免其升级为过载。及早检测和响应有助于在需求高峰期保持服务可用性。

开展故障恢复测试

Google Cloud Well-Architected Framework 可靠性核心中的这一原则提供了相关建议，可帮助您设计和运行测试，以便在发生故障时进行恢复。

这一原则与可靠性的学习 重点领域相关。

原则概览

为确保系统能够从故障中恢复，您必须定期运行测试，包括区域故障切换、版本回滚和从备份恢复数据。

此测试可帮助您练习对可靠性构成重大风险的事件（例如整个区域的服务中断）的响应。此测试还有助于验证系统在中断期间是否按预期运行。

万一整个区域发生故障，您需要将所有流量故障切换到另一个区域。在工作负载的正常运行期间，当数据被修改时，需要从主区域同步到故障切换区域。您需要验证复制的数据是否始终是最新的，以便用户不会遇到数据丢失或会话中断的情况。负载均衡系统还必须能够随时将流量转移到故障切换区域，而不会造成服务中断。为了最大限度地缩短区域服务中断后的停机时间，运维工程师还需要能够手动且高效地将用户流量从某个区域转移出去，并尽可能缩短转移时间。此操作有时称为耗尽区域，这意味着您停止向该区域的入站流量，并将所有流量转移到其他位置。

建议

在设计和运行故障恢复测试时，请考虑以下各子部分中的建议。

确定测试目标和范围

明确定义您希望通过测试实现的目标。例如，您的目标可以包括以下内容：

  • 验证恢复时间目标 (RTO) 和恢复点目标 (RPO)。如需了解详情，请参阅灾难恢复规划的基础知识。
  • 评估系统在各种故障场景下的弹性和容错能力。
  • 测试自动故障切换机制的有效性。

确定哪些组件、服务或区域在测试范围内。范围可以包括特定的应用层级（例如前端、后端和数据库），也可以包括特定的 Google Cloud 资源（例如 Cloud SQL 实例或 GKE 集群）。范围还必须指定任何外部依赖项，例如第三方 API 或 Cloud Interconnect。

准备测试环境

选择一个合适的环境，最好是复制了生产设置的预演或沙盒环境。如果您在生产环境中进行测试，请确保已准备好安全措施，例如自动监控和手动回滚程序。

创建备份方案。对关键数据库和服务进行快照或备份，以防止在测试期间丢失数据。确保您的团队已做好准备，以便在自动故障切换机制失败时进行人工干预。

为防止测试中断，请确保您的 IAM 角色、政策和故障切换配置设置正确。验证测试工具和脚本是否具有必要的权限。

向利益相关方（包括运营、DevOps 和应用所有者）告知测试时间表、范围和潜在影响。向利益相关方提供预计时间表和测试期间的预期行为。

模拟故障场景

使用 Chaos Monkey 等工具规划和执行故障。您可以使用自定义脚本来模拟关键服务的故障，例如多可用区 GKE 集群中的主节点关停或 Cloud SQL 实例停用。您还可以使用脚本，通过防火墙规则或基于测试范围的 API 限制来模拟区域级网络服务中断。逐步升级故障场景，以观察系统在各种条件下的行为。

引入负载测试和故障场景，以模拟中断期间的实际使用情况。测试级联故障影响，例如后端服务不可用时前端系统的行为。

为了验证配置更改并评估系统对人为错误的恢复能力，请测试涉及配置错误的场景。例如，使用不正确的 DNS 故障切换设置或不正确的 IAM 权限运行测试。

监控系统行为

监控负载均衡器、健康检查和其他机制如何重新路由流量。使用 Google Cloud Cloud Monitoring 和 Cloud Logging 等工具在测试期间捕获指标和事件。

在故障模拟期间和之后，观察延迟时间、错误率和吞吐量的变化，并监控总体性能影响。找出用户体验中的任何降级或不一致之处。

确保针对关键事件（例如服务中断或故障切换）生成日志并触发提醒。您可以使用这些数据来验证您的提醒和突发事件响应系统的有效性。

根据 RTO 和 RPO 验证恢复

衡量系统在发生故障后恢复正常运行所需的时间，然后将此数据与定义的 RTO 进行比较，并记录任何差距。

确保数据完整性和可用性符合 RPO。如需测试数据库一致性，请比较故障发生前后的数据库快照或备份。

评估服务恢复情况，并确认所有服务均已恢复到正常运行状态，且对用户造成的干扰降至最低。

记录并分析结果

记录每个测试步骤、失败场景和相应的系统行为。 提供时间戳、日志和指标，以便进行详细分析。

重点说明测试期间观察到的瓶颈、单点故障或意外行为。为了帮助确定修复的优先级，请按严重程度和影响对问题进行分类。

建议改进系统架构、故障切换机制或监控设置。根据测试结果，更新所有相关的故障切换政策和策略方案。向利益相关方提交事后分析报告。报告应总结成果、经验教训和后续步骤。如需了解详情，请参阅进行全面的事后分析。

迭代和改进

为验证持续的可靠性和恢复能力，请规划定期测试（例如每季度一次）。

在不同场景下运行测试，包括基础设施更改、软件更新和流量负载增加。

通过使用 CI/CD 流水线将可靠性测试集成到开发生命周期中，自动执行故障切换测试。

在事后分析期间，使用利益相关方和最终用户的反馈来改进测试流程和系统弹性。

开展数据丢失恢复测试

Google Cloud Well-Architected Framework 可靠性核心中的这一原则提供了相关建议，可帮助您设计和运行测试，以从数据丢失中恢复。

此原则与可靠性的学习 重点领域相关。

原则概览

为确保系统能够从数据丢失或损坏的情况中恢复，您需要针对这些情况运行测试。数据丢失可能是由软件 bug 或某种类型的自然灾害引起的。发生此类事件后，您需要从备份中恢复数据，并使用新恢复的数据再次启动所有服务。

我们建议您使用以下三个标准来判断此类恢复测试的成功与否：数据完整性、恢复时间目标 (RTO) 和恢复点目标 (RPO)。如需详细了解 RTO 和 RPO 指标，请参阅灾难恢复规划的基础知识。

数据恢复测试的目标是定期验证您的组织能否继续满足业务连续性要求。除了衡量 RTO 和 RPO 之外，数据恢复测试还必须包括使用恢复的数据测试整个应用堆栈和所有关键基础设施服务。这是确认整个已部署应用在测试环境中正常运行所必需的。

建议

在设计和运行数据丢失恢复测试时，请考虑以下各子部分中的建议。

验证备份一致性并测试恢复流程

您需要验证备份是否包含一致且可用的数据快照，以便您能够恢复这些数据，从而立即恢复应用服务。如需验证数据完整性，请设置自动一致性检查，以便在每次备份后运行。

如需测试备份，请在非生产环境中恢复备份。为确保备份能够高效恢复，并且恢复的数据符合应用要求，请定期模拟数据恢复场景。记录数据恢复步骤，并培训团队在发生故障时有效执行这些步骤。

安排定期频繁备份

为最大限度地减少恢复期间的数据丢失并达到 RPO 目标，必须定期安排备份。建立与您的 RPO 一致的备份频率。例如，如果您的 RPO 为 15 分钟，请安排至少每 15 分钟运行一次备份。优化备份间隔，以降低数据丢失的风险。

使用 Cloud Storage、Cloud SQL 自动备份或 Spanner 备份等 Google Cloud 工具来安排和管理备份。对于关键应用，请使用近乎连续的备份解决方案，例如 Cloud SQL 的时间点恢复 (PITR) 或大型数据集的增量备份。

定义和监控 RPO

根据业务需求设置明确的 RPO，并监控 RPO 的遵守情况。 如果备份间隔超过定义的 RPO，请使用 Cloud Monitoring 设置提醒。

监控备份运行状况

使用 Google Cloud Backup and DR Service 或类似工具跟踪备份的健康状况，并确认备份存储在安全可靠的位置。确保备份在多个区域之间复制，以提高弹性。

针对备份以外的场景进行规划

将备份与灾难恢复策略（例如“双活”故障切换设置或跨区域复制）相结合，可在极端情况下缩短恢复时间。 如需了解详情，请参阅灾难恢复规划指南。

进行全面的事后剖析

Google Cloud Well-Architected Framework 可靠性核心中的这一原则提供了相关建议，可帮助您在发生故障和事件后进行有效的事后分析。

此原则与可靠性的学习 重点领域相关。

原则概览

事后分析是对突发事件、其影响、为缓解或解决突发事件而采取的措施、根本原因以及为防止突发事件再次发生而采取的后续行动的书面记录。事后分析的目标是从错误中学习，而不是追究责任。

下图展示了事后分析的工作流程：

事后分析的工作流程。

事后分析的工作流程包括以下步骤：

  • 创建事后分析
  • 捕获事实
  • 识别并分析根本原因
  • 为未来做规划
  • 执行方案

在发生重大事件和非重大事件（例如以下事件）后进行事后分析：

  • 用户可见的停机时间或性能下降超过特定阈值。
  • 任何类型的数据丢失。
  • 值班工程师的干预措施，例如回滚版本或重新路由流量。
  • 解决时间高于指定阈值。
  • 监控失败，通常意味着需要手动发现突发事件。

建议

在突发事件发生之前定义事后分析标准，以便每个人都知道何时需要进行事后分析。

如需进行有效的事后分析，请考虑以下各小节中的建议。

进行不责罚的事后剖析

有效的事后分析侧重于流程、工具和技术，不会将责任归咎于个人或团队。事后分析的目的是改进技术和未来，而不是找出谁有罪。人人都会犯错。目标应该是分析错误并从中学习。

以下示例展示了指责型反馈和不指责型反馈之间的区别：

  • 推卸责任的反馈：“我们需要重写整个复杂的后端系统！在过去三个季度中，它每周都会出现故障，我相信大家已经厌倦了零敲碎打地修复问题。 说真的，如果我再收到一次寻呼，我就自己重写…
  • 不指责的反馈：“重写整个后端系统的待办项实际上可能会阻止这些页面继续发生。此版本的维护手册非常长，很难完全掌握。我相信，我们未来的值班工程师一定会感谢我们！”

确保所有目标受众群体都能阅读事后分析报告

对于您计划在报告中包含的每条信息，请评估该信息是否重要且必要，能否帮助受众群体了解发生了什么情况。您可以将补充数据和说明移至报告的附录中。如果审核者需要更多信息，可以提出要求。

避免使用复杂或过度设计的解决方案

在开始探索问题的解决方案之前，请先评估问题的重要性和再次发生的可能性。为了解决不太可能再次发生的问题而增加系统的复杂性，可能会导致不稳定性增加。

尽可能广泛地分享事后分析

为确保问题得到解决，请向广大受众群体发布事后分析的结果，并获得管理层的支持。事后分析的价值与事后分析后获得的经验成正比。当更多人从突发事件中吸取经验教训时，类似故障再次发生的可能性就会降低。