Google Cloud Well-Architected Framework：可靠性

Last reviewed 2025-02-14 UTC

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

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

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

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

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

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

组织思维

为了确保系统可靠，您需要制定计划和一套成熟的策略。此策略必须包括教育和权威，以便将可靠性与其他计划一起列为优先事项。

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

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

全面规划和管理所有职能部门和团队的可靠性。 不妨考虑建立一个包含可靠性支柱的 Cloud Center 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)。如需了解详情，请参阅灾难恢复规划的基础知识。
  • 评估系统在各种故障场景下的弹性和容错能力。
  • 测试自动故障切换机制的有效性。

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

准备测试环境

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

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

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

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

模拟故障场景

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

引入负载测试和故障场景，以重现停机期间的真实使用情况。测试级联故障的影响，例如在后端服务不可用时前端系统的行为方式。

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

监控系统行为

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

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

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

对照 RTO 和 RPO 验证恢复情况

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

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

评估服务恢复情况，并确认所有服务均已恢复正常运行，对用户造成的影响降到最低。

记录和分析结果

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

突出显示测试期间观察到的瓶颈、单点故障或异常行为。为帮助确定修复优先级，请按严重程度和影响分类。

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

迭代和改进

如需验证持续的可靠性和弹性，请规划定期测试（例如，每季度进行一次）。

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

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

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

执行测试以从数据丢失中恢复

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

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

原则概览

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

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

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

建议

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

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

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

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

安排定期且频繁的备份

为了尽可能减少恢复期间的数据丢失，并达到 RPO 目标，请务必定期安排备份。确定符合 RPO 要求的备份频率。例如，如果您的 RPO 为 15 分钟，请将备份安排为至少每 15 分钟运行一次。优化备份间隔时间，以降低数据丢失的风险。

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

定义和监控 RPO

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

监控备份运行状况

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

针对备份以外的情况进行规划

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

进行彻底的事故分析

Google Cloud 架构良好的框架可靠性支柱中的这一原则提供了一些建议，可帮助您在发生故障和事故后进行有效的事故分析。

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

原则概览

事后分析是对突发事件、其影响、为减少或解决突发事件而采取的措施、根本原因以及为防止突发事件再次发生而采取的后续措施的书面记录。事后分析的目的是从错误中学习，而不是归咎于他人。

下图显示了问题排查的工作流：

事后分析的工作流。

问题排查工作流包括以下步骤：

  • 创建问题排查
  • 获取相关事实
  • 确定和分析根本原因
  • 为未来做规划
  • 执行方案

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

  • 超过特定阈值的用户可见宕机或服务降级。
  • 任何类型的数据丢失。
  • 值班工程师的干预，例如发布回滚或流量重定向。
  • 解决时间超过指定阈值。
  • 监控故障，通常意味着需要手动发现突发事件。

建议

在突发事件发生之前定义问题排查标准，以便所有人知道何时需要进行问题排查。

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

进行无责备事后分析

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

以下示例展示了归因反馈和无归因反馈之间的区别：

  • 归咎他人的反馈：“我们需要重写整个复杂的后端系统！过去三个季度，此问题每周都会出现，我相信我们都已厌倦了零散解决问题。真的，如果再给我发一次通知，我会自己重写…"
  • 不指责他人的反馈：“重写整个后端系统的操作步骤实际上可能会阻止这些页面继续出现。此版本的维护手册非常长，很难完全掌握。我相信，未来的值班工程师会感谢我们！”

使所有目标受众群体都能读懂问题排查报告

对于您计划在报告中添加的每条信息，请评估这些信息是否重要且必要，是否有助于观众了解所发生的情况。您可以将补充数据和说明移至报告的附录中。如有需要，审核员可以申请获取更多信息。

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

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

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

为了确保问题不会一直未解决，请向广大受众发布问题排查结果，并获得管理层的支持。问题排查的价值与问题排查后获得的学习成正比。当更多人从事故中学习时，类似故障再次发生的可能性就会降低。