快准稳：值得所有运维学习的SRE故障处理经验

在网络上关于 SRE 的讨论中，故障相关的内容比比皆是，但关于故障发生时的应急处理过程的详细讨论却寥寥无几。然而面对故障，故障指挥官一定面临着较大的压力，需要快速、正确地处置故障，应对内外部的挑战。在这篇文章中，我们将重点探讨故障指挥官在故障处理过程中的具体行动思路。

值得注意的是，本文总结了作者在担任故障指挥官时，对故障感知、故障定级、故障处理以及故障恢复等环节的经验和心得，而并未涉及如何预防故障或进行故障复盘的内容。

1、故障感知

众所周知：故障一般来自两个部分的输入：监控系统和用户（客户）报障。

• 首先，监控系统在SRE工作中起着至关重要的作用。监控系统可以实时监测系统的业务指标和性能参数。当系统出现异常或达到预设的条件时，监控系统会自动触发告警并发送给SRE团队。这些告警包括基础设施监控（如服务器负载过高、网络延迟异常、存储空间不足等等），也包括业务层面的监控（如接口成功率、页面白屏化/JS错误等）。

• 其次，客户或用户的报障也是故障的输入来源。当客户或用户在使用系统时遇到问题或异常情况，他们通过电话、即时通信、工单等各种渠道向技术支持团队报障。我们可以通过程序去监控投诉关键字、重点客户客情，当有客情出现时，SRE可以进行故障排查和解决。

涉及监控系统的实现细节，不在此赘述。

2、故障的定级

在处理故障时，首先需要判断故障的影响范围，即确定是否构成故障。这可以通过以下几种方式进行判断：

• 系统维度判断：监控系统提供了实时的系统指标和性能参数，故障指挥官在收到告警后，可以通过监控数据来判断系统是否真实出现异常。例如，关键接口返回码成功率严重下降，关键接口耗时严重上升，由相关的接口指标数据来定义故障的级别。

• 用户维度判断：如果多个用户报告了相似的问题，根据报障的用户数量来判断、根据监控系统所体现的用户维度的数据，判断该故障可能影响了多少客户，从而定义故障的级别。

• 重点客户的反馈判断：重点客户通常是对系统稳定性和性能要求较高的客户。也是业务的重要收入来源， 他们的反馈对于判断故障的影响范围非常重要。如果重点客户反馈了故障或异常情况，可以根据客户的级别、受影响的业务规模、客情反馈情况等来定义故障的级别。

• 

3、故障处理团队的组织

当故障发生时，首要任务是立即召开在线故障会议。组织此类会议时，可以从以下几个方面进行考虑和动作：

• 判断要卷入谁：

  • 模块组件相关性：根据故障的性质和影响范围，确定与故障相关的模块或组件。然后卷入与这些模块或组件直接相关的团队成员，以确保有专业知识和经验来处理故障。

  • 最近的可疑的变更团队：如果故障与最近的变更点时间吻合，建议卷入该变更团队。

  • 历史出现过相似的问题：历史上出现过相似的问题，可以将当时处理过故障的人员卷入到会议。

  • 内部面向客户/用户相关人员：如果故障影响了重要客户或用户，可以单独拉取一个群组来同步与这些客户或用户相关的问题。这个群组应该包括与客户或用户关系密切的团队成员，以便及时响应和解决他们的问题。

• 会议中的挑战：在组织故障处理群组时，确保成员有效沟通和协作至关重要。然而，刚开始拉群时可能会面临以下挑战：

  • 信息缺乏同步：由于故障突然发生，每个被拉入群组的成员可能会询问当前问题的情况。故障指挥官可能会需要重复当前的情况。

  • 建议在拉入会议时同时创建一个工作群（如企业微信群、微信群），并在群里发布公告，公告里详细说明故障的影响范围、受影响的业务以及故障发生的时间。以免入会人员重复询问。

  • 信息不够聚焦：在故障处理群组中，有些技术人员可能会陷入讨论一些细节或不太关键链路的问题。

  • 在这种情况下，故障指挥官的角色至关重要，需要确保抓住重点主线：果断打断故障恢复主线无关的问题讨论（如果是疑似问题根因但未确认，可以组织相关人员到分会场讨论），优先恢复受损的业务，而将其他问题放在次要位置。如果故障受损的业务较多，可以考虑根据影响范围、程序等因素进行排序，以便更有效地处理故障。

4、故障的处理

故障发生后，需要指挥、协调相关团队进行及时止损及恢复：

• 讨论制定恢复措施：快速恢复的方法包括流量调度、流量限制、业务降级、紧急扩容、组件重启、版本回退、紧急补丁、数据恢复等。可以根据系统的能力、日常的演练结果等来综合决策。

  • 流量调度：业务具备多地/多SET部署能力，当某一部分模块有故障时，及时调度到其他地域/SET来恢复业务

  • 故障隔离：由于IaaS/灰度模块等局部原因造成业务故障时，可以考虑将相关设备/模块剔除以恢复业务。

  • 全局限流：故障由于业务流量增长引起，可以考虑在接入层、服务网关等组件上进行限流。限流的阈值可以参考历史峰值或者压测验证过的数值。

  • 紧急扩容：故障由于业务流量增长引起，在资源足够、能快速扩容的情况下，可以紧急对业务模块进行扩容。需要注意的是，如果用户或业务调用方有大量的重试行为，此时需要配合限流措施。

  • 组件重启：某些组件可能出现了故障，由于某些原因造成了CPU Hang死或者内存驻留，导致系统运营缓慢或业务逻辑错误，可以采用重启来恢复业务。

  • 版本回退：当确认故障是由于业务发版引起，可以采用版本回退来恢复业务。

  • 紧急补丁：故障因为触发到业务设计上的缺陷而无法使用以上手段恢复。需采用紧急补丁修复。

  • 数据恢复：由于问题涉及到数据损坏或丢失，需要进行数据恢复。

  • 其他：所采取的其他恢复方案

• 进行恢复措施评估：

• • 措施是否得力、有效。恢复业务为第一要务，该措施是否能够有效恢复业务。

  • 措施是否相对较优，如果评审中有异议，提出并讨论优化方案。

  • 如果恢复方法对业务有影响，卷入利益相关方评估影响是否能够接受。

  • 考虑相应的回退措施。

• 及时决策：由于故障对客户的业务有损，所以及时决策非常重要，最小化故障时间有利于减少损失。故障指挥官需要有相应的担当，及时决策相关处置措施的实施。如果涉及到业务流程相关，需要提前考虑紧急变更的业务流程。

• 实施恢复措施：确定恢复措施后，经过关键人员审批后，及时实施到业务环境。如果措施未生效，则需要决策回退。

• 观察判断业务是否恢复：观察关键的监控指标是否恢复，客户的反馈是否消失。

5、故障信息的透明与同步

故障发生期间，会有不同的群体通过相关渠道来向故障指挥官了解进展，如：相关领导和同事来询问并给出他们认为有效的意见，客户技术支持团队/运营团队来询问故障的原因及什么时候恢复。

为了有效向各相关团队同步业务进展，保持统一的口径，需要考虑以下几点：

• 故障由谁来同步比较好：

  • 内部：建议由故障指挥官来进行同步，也可以由故障指挥官指派相关的同事来准备文字素材，故障指挥官整合确认后同步。所以对故障指挥官有一定的要求：故障指挥官应熟悉IT系统的基础理论，并对应用系统技术架构有积累，具备严谨的逻辑思考能力，以确保故障形成的原因经得起推敲与挑战。

  • 有关是否需要向客户同步进展：建议由故障指挥官（或故障指挥官指派相关人员）提供素材，同步给运营团队或TAM（技术支持经理）来主导，相关对客团队来准备合适的话术，以确保信息清晰易懂。

• 故障信息同步需要包含的内容：故障同步时，因为内部和外部的受众和需求不同，信息口径有一些差异，主要的差异点是如下：

  • 内部同步：主要面向组织内部的成员，包括技术团队、管理层和其他相关人员。确保团队成员了解故障的详细情况、进展和解决方案，以便有效地参与故障处理和提供支持。通常会涉及更多的技术细节和操作细节，以满足团队成员对故障处理的需要。

  • 外部同步主要面向外部的利益相关者，包括客户、渠道合作伙伴、和其他相关方。信息要足够准确、透明，以便用户了解故障的影响和恢复进展。通常需要使用更简洁、易懂的语言，避免过多的技术细节，以让外部用户感知上透明、可控。

因此，为了满足内部和外部受众的不同需求，故障同步时对不同的内外受众需要采用不同的口径和信息呈现方式。

• 故障指挥官需要在内部同步的内容如下：

  • 故障开始时间：什么时候开始的（可以根据监控系统的指标变动时间，极个别情况，监控系统未体现的话也可以根据客户反馈的时间）

  • 影响范围：影响了哪些功能，哪些客户，多少设备量、业务量等

  • 预计恢复时间：预计什么时候可以恢复，一般在这里要同步一个初步预估的时间。后续可以随着处理的进展来刷新。

  • 当前进展情况：怀疑方向是什么，谁在处理，当前处理的进展如何，一般可以先概括一下处理的整体方案，整体方案一共有几步，目前进展到哪一步了。预计什么时候可以执行完。

  • 需要哪些帮助：有时候这一点尤其重要，当前执行预案的时候，碰到了什么棘手的问题，需要什么资源。

• 故障指挥官需要向外部同步的信息如下：

• • 故障的现象：发生了什么问题，该故障的触发条件是什么。

  • 问题原因：故障原因是否已经查明，如果已经查明，简洁地描述原因。

  • 问题处理的进展：对故障进行了怎么样的处理，如果有多个恢复止损的步骤，目前进行到第几步了。

  • 并预计恢复时间：预计什么时候能够恢复。

  • 规避方法：如果在用户侧有办法临时规避，可以告知规避方式。例如业务切换、降级等。

以上描述的信息框架可以用来做为故障信息同步的参考框架。故障指挥官应保障内部和外部团队对故障的知情权，同时也应当保证信息的一致性和权威性。

故障恢复后，可以向各相关方推送相关的故障恢复信息。可以参考包含以下信息：

• 内部同步

  • 故障现象

  • 影响范围

  • 故障原因

  • 恢复时间及恢复方法

• 外部同步

  • 故障现象

  • 故障时段

  • 官方的故障原因

由于故障涉及到用户的业务，可以同时请外部用户予以验证。

总 结

总的来说，本文详细探讨了SRE工作中故障指挥官处理故障的各个环节，包括故障的感知、定级和处理过程。

故障指挥官在这个过程中的非常重要，既需要具备技术架构、技术细节的理解，又需要有良好的沟通和协调能力。以便在故障发生时，能够迅速组织团队，制定并执行恢复措施。

同时，故障指挥官还需要负责向内外部团队同步故障进展，这需要他们有清晰的思考能力及语言文字组织能力。

当然，一个优秀的SRE不仅能够镇定应对故障，他们还会通过优化业务部署、完善可观测体系、组织完善应急预案并充分验证等手段来预防故障或缩短故障的持续时间。在故障恢复后，他们还需要负责组织深度的故障复盘，识别故障的根源，并制定策略以防止同类问题的再次发生

转自：高效运维

作者：李雄政