效率提升 | 利用站点可靠性工程应对可靠性挑战

文 / Cheryl Kang，SRE

了解更多，请参与我们的

(详见次条) 。

假设您已经开发出完美、可靠的服务，并深受您用户的喜爱。当忙碌的前期发布工作结束后，您会发现，服务不仅需要运行，而且更需要由您负责维护！

在 Google，为确保服务正常运行和用户满意，我们会遵循站点可靠性工程 (SRE) 原则。在运用 SRE 原则开展工作多年后，我们发现 SRE 团队面临着一些共同的挑战，同时也找到了一些应对或规避这些挑战的重要方法。在这里，我们将分享这些小技巧。

根据我们的经验，压力主要有以下三种来源：

琐事 (Toils)
监控不当
不成熟事故处理流程

下文将详细介绍每一种压力源，以及解决的一些方法。

规避琐事

琐事的产生与运行生产服务密切相关，是趋向于手动、重复、可自动化、需要策略、缺乏持久价值的各类工作，并且这种趋势会随着服务的增长呈线性增长。

当然，这并不意味着琐事没有商业价值；而是我们能够找到更好的方法来处理琐事，无需每次都依靠手动方法去解决。

琐事会造成不良影响。如果不持续保持警惕，它可能会逐步失控，直至耗尽整个团队的精力。就像花园里随时会长出杂草一般，工作中也随时会遇到一些琐事，但您的团队应该定期评估琐事的可接受程度并对此积极进行管理。项目规划人员也需要一直为称作“琐事杀手”的项目预留足够空间。

以下是一些琐事的示例：

工单垃圾：大量是否需要采取行动的待确定工单，但需要手工进行分类（例如有关配额用尽的工单）。
基于改动代码的服务变更待签入：如果您只有五名客户，问题不大。但是，如果您有 100 名客户，为每个变更手动修改代码就会成为一件琐事。
手动应用少量生产变更（例如变更命令行、推送配置、点击按钮等）以应对不断变化的服务条件。此类操作如果每月只需执行一次，没有问题。但如果每日执行，则会成为琐事。
针对多个重复主题的用户常见问题。完善记录文档或自助信息服务中心是否会有帮助？

这并不意味着每个非编码任务都是琐事。举例来说，非琐事任务包括对揭露之前未知错误的复杂问题进行调试，或是为重要的大客户提供满足其独特需求的咨询服务。请记住，琐事是缺乏持久价值的重复性工作。

如何确定需要先处理的琐事活动呢？经验法则是优先处理随服务规模扩大而难以管控的任务。例如：

当我的服务的功能增多时，我执行 X 的频率也需增加
随着服务规模的壮大，Y 发生的次数也更多
页面数量随服务资源占用量的增加而增加

一般来说，对经常性琐事的自动化处理要优先于对复杂琐事的处理。

杜绝监控不当

所有完善的监控大都类似；而每个设置不当的监控均存在各自不同的问题。

设置性能完善的监控可帮助您提前发现问题，并加快解决问题的速度。完善的监控会针对可操作问题发出提醒。监控不力是经常性琐事，可能导致以下问题：

无法操作的提醒（如垃圾内容）
高呼叫量或工单量
客户重复问询同一件事
令人费解或杂乱无序的信息中心
服务等级指标 (SLI) 或服务等级目标 (SLO) 并未真正反映出客户的痛点。例如，用户可能投诉登录失败，但您的 SLO 信息中心错误地显示为一切正常。换言之，您的服务不应依赖于客户投诉来确定发生了什么故障。
文档记录不完善；操作手册没有实际用处。

您可以通过以下方式发现与监控不力有关的琐事源头：

将所有工单保存在同一位置
跟踪工单解决情况
识别通知/请求的常见来源
确保工作负载不超过《SRE 手册》中规定的 50%

建立健康的事故管理体系

不论您创建了什么服务，在运行过程中肯定都会遭遇严重的中断事故，这只是时间问题。在事故发生之前，确立完善的实践体系至关重要，这样可以尽量避免在处理中断的核心阶段出现混乱。以下一些操作可帮助您从容应对中断事故：

遵循事件管理原则

事故管理通过构建一个层级分明的结构体系，并明确列出角色、任务和沟通渠道，能够告知您如何规划紧急应对措施。这套体系制定了统一的标准化方法，用于处理紧急事故和规划有效应对措施。

确保相关人员随时待命

在发生紧急状况时，您绝不希望手忙脚乱地寻找合适的处理人员。我们建议您执行以下操作，帮助自己脱离困境：

针对紧急情况创建您自己的团队专属邮件列表。此列表应包括所有技术主管和经理，甚至所有工程师（如果有需要）。
编写一份简短的文档，列出在紧急情况下可以联系到的专家。这能让您更加轻松快速地找到处理故障的合适人选。
通过实时更新文档或编写简单的工具，轻松找出指定服务的待命负责人员。
在 Google，我们拥有一支由高级 SRE 专家组成的团队，称作事故响应团队 (IRT)。他们的职责是帮助协调、缓解和/或解决重大服务中断问题。组建这样的团队并非强制性要求。但是，如果您遭遇的中断事故涉及多个服务，则这样的团队可能会给您带来很大的帮助。

建立沟通渠道

调查中断事故时，首先需要在团队的事故处理程序中建立沟通渠道。我们的一些建议如下：

确定一个统一的消息传递平台，Internet Relay Chat、Google Chat、Slack 等均可
启用共享文档，供协作者在中断诊断期间添加注释。该文件将为事后分析提供有力的依据。限制此文档的权限，以避免泄漏个人可识别信息 (PII)。
请注意，PII 不属于消息传递平台、提醒文本或全公司范围内可访问的注释内容。如果您需要在排查中断问题期间共享 PII，请使用错误跟踪系统、Google 文档等来限制权限。

建立上报路线

假设现在是凌晨 2 点，一个网页问题将您惊醒。睡眼惺忪的您在各种令人眼花缭乱的信息中心之间胡乱摸索，此时您意识到自己需要一些专业建议。您该怎么做？

别害怕上报问题！寻求帮助是正常操作。您决不可拖延，让问题变得更糟糕。智囊团就在您的周围，时刻准备提供支援。

您的团队需要确定自己的上报路线。以下是该路线模式的示例：

如果您自己不在待命状态，则寻找您的服务的待命人员。
如果待命人员未响应或需要帮助，则寻找您团队的负责人 (TL) 或经理。如果您是团队负责人 (TL) 或经理，请确保告知您的团队，在工作时间以外也可以联系您处理紧急情况（除非您有充分理由拒绝）。
如果依赖项发生故障，则寻找团队的待命人员。
如果您需要更多帮助，则寻呼团队应急人员列表上的成员。
（可选）如果您团队的成员无法确定故障根源，或者您需要他人以及多个团队的协助和协调，则寻呼事故响应团队 (IRT)（如果您有组建这样的团队）。

编写非指责性事后调查报告

问题解决后，您需要编写事后调查报告。您可以建立事后审查流程，让您的团队一起从过去的错误中学习，提出问题，并坦诚告知彼此后续问题已得到妥善解决。

编写事后调查报告的主要目的是：确保事故被记录在案，透彻追查造成问题的所有根源，并实施有效的预防措施以减少事故再次发生的可能性甚至造成的影响。

Google 的所有事后调查均为非指责性事后调查。非指责性事后调查认为事故所涉每个人都有良好的意愿，并已利用所掌握的信息尽全力做出了最好的应对。这意味着事后调查着重于确定事故的起因，不会因不良或不当行为指责任何个人或团队。

感谢在此过程中协助你的人

要实现生产服务的可靠运行需要借助集体的力量，SRE 便是团队合作的结果。每当您想在私人聊天中写“非常感谢您做了某事”时，请考虑在电子邮件中也写下相同的话语并抄送给感谢对象的经理。这样做花费的时间相同，但却带来了额外的好处，能为您的帮手提供引以为傲的证明。

希望您的问询流程和寻呼路线永远不会投入使用！要了解详情，请参阅《SRE 手册》和《SRE 工作手册》。

* 感谢 Chris Heiser 和 Shylaja Nukala 的特别贡献。

如果您想详细了解 本文讨论 的相关内容，请参阅以下文档。这些文档深入探讨了这篇文章中提及的许多主题：