良好架构框架：可靠性支柱

Last reviewed 2025-02-14 UTC

Google Cloud 架构完善框架中的可靠性支柱提供了原则和建议，可帮助您在 Google Cloud中设计、部署和管理可靠的工作负载。

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

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

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

可靠性对您的云端策略至关重要，原因有很多，包括：

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

组织心态

为了确保系统可靠，您需要制定计划并确立策略。此策略必须包括教育和授权，以便在其他计划中优先考虑可靠性。

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

每个团队都必须了解其应用的可靠性目标和风险。团队必须对这些要求负责。必须确定可靠性和常规产品功能开发之间的冲突的优先级，并相应地进行上报。

从整体上规划和管理可靠性，涵盖所有职能和团队。 不妨考虑设置一个包含可靠性支柱的 Cloud Centre of Excellence (CCoE)。如需了解详情，请参阅通过 Cloud Center of Excellence 优化组织的云转型之旅。

可靠性重点领域

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

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

核心原则

架构完善框架可靠性支柱中的建议与以下核心原则相对应：

贡献者

作者：

其他贡献者：

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

Google Cloud 架构完善框架的可靠性支柱中的这一原则可帮助您评估用户体验，然后将评估结果映射到可靠性目标和指标。

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

原则概览

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

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

建议

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

衡量用户体验

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

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

分析用户体验历程

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

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

Google Cloud 架构完善框架的可靠性支柱中的这一原则可帮助您为 Google Cloud中的工作负载定义在技术上可行的可靠性目标。

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

原则概览

设计系统时，可靠性应足以让用户满意。虽然这看起来有悖常理，但以 100% 可靠性为目标往往不是最有效的策略。更高的可靠性可能会导致成本大幅增加，无论是财务投资还是创新方面的潜在限制。如果用户对当前的服务水平已经很满意，那么进一步提高用户满意度的努力可能会带来较低的投资回报率。这样一来，您就可以将资源更好地用于其他方面。

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

建议

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

接受部分失败并确定组件的优先级

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

100% 正常运行时间与 99.99% 目标值之间的差距是允许的故障时间。 这种差距通常称为“误差预算”。错误预算有助于您冒险和创新，这对于任何企业保持竞争力都至关重要。

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

平衡可靠性和费用

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

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

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

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

Google Cloud 架构完善框架可靠性支柱中的这一原则提供了有关规划、构建和管理资源冗余的建议，可帮助您避免故障。

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

原则概览

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

建议

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

确定故障网域并复制服务

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

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

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

及时检测和解决问题

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

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

测试故障切换场景

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

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

利用横向可伸缩性

Google Cloud 架构完善框架的可靠性支柱中的这一原则提供了一些建议，可帮助您使用横向可伸缩性。通过使用横向可伸缩性，您可以帮助确保Google Cloud 中的工作负载能够高效地进行扩缩并保持性能。

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

原则概览

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

若要了解横向伸缩的价值，请先了解纵向伸缩的限制。

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

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

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

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

建议

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

使用托管式服务

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

推广模块化设计

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

实现无状态设计

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

使用可观测性检测潜在的故障

Google Cloud 架构完善框架的可靠性支柱中的这一原则提供了一些建议，可帮助您主动识别可能发生错误和故障的领域。

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

原则概览

为了在Google Cloud中保持和提高工作负载的可靠性，您需要使用指标、日志和轨迹来实现有效的可观测性。

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

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

建议

如需高效检测潜在故障，请考虑以下各子部分中的建议。

获取全面的数据洞见

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

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

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

主动排查问题

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

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

优化资源利用率

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

确定提醒的优先级

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

设计用于实现平缓降级

Google Cloud 架构完善框架的可靠性支柱中的这一原则提供了一些建议，可帮助您设计 Google Cloud 工作负载，使其能够优雅地处理故障。

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

原则概览

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

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

建议

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

实现节流

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

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

尽早舍弃多余的请求

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

处理部分错误和重试

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

测试过载场景

为了验证节流和请求丢弃机制是否有效，请定期在系统中模拟过载情况。测试有助于确保您的系统能够应对实际流量高峰。

监控流量高峰

使用分析和监控工具预测并应对流量高峰，以免高峰演变成过载。及早检测和响应有助于在高需求期间保持服务可用性。

执行故障恢复测试

Google Cloud 架构完善框架可靠性支柱中的这一原则提供了相关建议，可帮助您设计和运行故障恢复测试。

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

原则概览

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

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

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

建议

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

定义测试目标和范围

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

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

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

准备测试环境

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

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

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

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

模拟故障场景

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

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

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

监控系统行为

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

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

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

根据 RTO 和 RPO 验证恢复情况

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

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

评估服务恢复情况，并确认所有服务都已恢复到正常运行状态，且对用户的干扰最小。

记录并分析结果

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

突出显示测试期间发现的瓶颈、单点故障或意外行为。为了帮助您确定修复的优先级，请按严重程度和影响程度对问题进行分类。

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

迭代和改进

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

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

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

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

执行数据丢失恢复测试

Google Cloud 架构完善框架可靠性支柱中的这一原则提供了一些建议，可帮助您设计和运行数据丢失恢复测试。

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

原则概览

为确保系统能够从数据丢失或损坏的情况中恢复，您需要针对这些情况运行测试。数据丢失可能由软件 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 架构完善框架的可靠性支柱中的这一原则提供了一些建议，可帮助您在发生故障和事件后进行有效的事后分析。

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

原则概览

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

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

事后分析的工作流程。

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

  • 创建事后分析
  • 捕获事实
  • 确定并分析根本原因
  • 规划未来
  • 执行方案

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

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

建议

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

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

进行无责备的事后分析

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

以下示例展示了指责性反馈与无指责反馈之间的区别：

  • 指责性反馈：“我们需要重写整个复杂的后端系统！过去三个季度，它每周都会出现故障，我相信我们都厌倦了零散地修复问题。说真的，如果我再收到一次寻呼，我就自己重写…"
  • 无责反馈：“重写整个后端系统的行动项实际上可能会阻止这些页面继续发生。此版本的维护手册非常长，很难完全掌握。我相信，我们未来的随叫随到工程师会感谢我们！

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

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

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

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

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

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