像Google SRE一样OnCall，文尾有福利

在 Google SRE 的著作《Google运维解密》^[1](原作名：Site Reliability Engineering: How Google Runs Production Systems)中，Google SRE 的关键成员们几乎不惜用了三个章节的篇幅描述了在 Google 他们是如何 OnCall 的。

Google SRE 实践中，有一个广为人知的理念：减少琐事，用软件工程的方式解决运维问题。具体到实际操作层面，Google SRE 设定了一个重要的、公开的目标：保持每个SRE的工作时间中琐事比例低于50%，SRE 至少花 50% 的时间在工程项目上，以减少未来的琐事或为服务增加新功能。

Google SRE 团队认为，琐事过多，会产生以下不利的后果：

根据统计数据显示，琐事的第一大来源是中断性工作，另一个主要来源是OnCall。前者大多为与服务相关的非紧急事务，后者则为紧急的应急事务。在 Google，一个 SRE 团队至少要保持6~8人的规模，才能保证因 OnCall 轮值产生的琐事低于30%。

管中窥豹，Google SRE 的工作方式，不是谁都有条件学，也不是谁都可以学的来的。需要从文化 机制 工具层面综合考虑，以国内的运维现状来看，这是有一些实际困难和阻力的。

文化

首先，在文化层面，Google SRE 倡导以人为本，关注人的发展，着眼长期结果。在国内加班文化盛行，996甚嚣尘上。具体到 IT 运维领域，表现为：

1. 技术人员工作和生活很难平衡，上班与下班没有明确界限，最终变成了只有值班，没有轮换，7x24小时响应。
2. 工作规划以短期目标驱动，缺乏长期主义，导致技术人员每天忙于“战术性”的工作，琐事缠身，而无暇通过软件工程的手段一劳永逸的解决长期问题，久而久之堆积为技术债务。
3. 35岁IT打工人困境较为普遍。归根结底，是人的发展，没有得到足够的重视，由于不断的有大量新人进入到 IT 行业，使得很多企业选择了不断“汰换人”而非“发展人”这样的路线，自然也就无从谈起“费力减少琐事”了。

机制

其次，在机制层面，Google SRE 明确执行“琐事不能超过50%”的机制，确保一个独立的 SRE team 最少保持6人的规模，以支撑轮换 OnCall，同时给予工作时间之外的 OnCall 工作以额外的补贴。

在国内这个操作难度很大，国内的大多数企业，SRE人数 vs 研发总人数的比例普遍接近1:100，要保持6人的SRE team，几乎是不可能的。

工具

最后，在工具层面，Google SRE 内部使用的 OnCall 工具为 Outalator。在 Outalator 中，SRE 们在一个集中的平台上，管理着告警的全生命周期过程，具体的来讲，功能包括：

1. 告警聚合：将多个告警信息“聚合”成一个单独的故障，SRE 以“故障”为维度来跟进和处理，大大降低了告警的发送量，避免重复性工作，降低了告警中的噪音，提高处理效率，以及减少工作失误。
2. 加标签：给不同的故障，加上标签，用来额外描述故障的信息，方便SRE 以标签为维度来筛选、统计、分析，提高告警处理效率。
3. 提供告警数据分析能力：从不同的维度，比如团队、个人、服务、机房等不同的维度，分析告警的数量变化趋势、告警的响应效率、处理效率，以便SRE能从宏观层面分析OnCall工作的不足之处，并有针对性的加以改进。
4. 一键生成报告和公告：Outalator 中对一线SRE更有用的功能是可以选择一系列故障，将它们的标题、标签和“重要的”记录信息用邮件格式发送给下一个OnCall工程师（也可以CC其他人或邮件列表）。这样可以很容易地进行交接工作。Outalator同时支持一种“报告模式”，为周期性的生产服务评审（大部分团队每周进行一次）提供帮助。

Outalator 大概长下面这样：

总结来讲，通过使用专业的 OnCall 工具，可以有效的解决日常工作中运维和研发人员面临的以下困扰：

我们可以像 Google SRE 一样 OnCall 吗？

通过以上的分析，坏消息是文化和机制层面，我们学不来，好消息是工具层面，Google 的 OnCall 工具可选项还不少。

我们熟知的 Kubernetes 是 Google 内部容器编排工具 Borg 的开源实现，Prometheus 是 Google 内部监控工具 Borgmon 的开源版本。那么 Google 内部的 OnCall 工具 Outalator 有没有相关的产品呢？今天就给大家带来市面上两款典型的 OnCall 工具的介绍和分析。

• PagerDuty^[2] 是全球范围内OnCall产品的领导者，可以仅以21$/人/月的价格，就可以用起来。
• FlashDuty^[3] 是开源监控工具夜莺^[4]背后的开发者团队推出的 OnCall 产品，相比 PagerDuty 对国内的各种监控工具、IM工具适配性更好，产品体验也更简洁。

没有度量就没有改进，在实际工作中，运维负责人表面看到的是告警太多、团队成员疲于奔命，但苦于看不清告警处理的工作量，没法规划协调补充人力，更严重的是看不清优化告警的方向，导致情况持续恶化，最终团队散了，故障频发。在告警处理的领域，落地 OnCall 实践，推荐关注下面 5 个关键的度量指标：

1. 降噪比：即告警的压缩比，通过算法、规则将众多相关的告警聚合后，再通知到值班人员。告警聚合能有效降低告警风暴，减少值班人员的工作量，提高信息处理的效率（该指标越高越好）。
2. 响应比：被认领的告警占所有告警的比例。在告警管理领域，需要响应或者认领的告警，才是有用的告警，因此通过统计和观察“响应比“，能整体的评估告警是否足够有效和有用，并持续的推动提升告警”响应比“（该指标越高越好）。
3. 告警总量：一段时间窗口内产生的告警数量。过高的告警总量，意味着值班的压力越大，对技术团队注意力的干扰越多，潜在的意味着告警的噪音可能也过大，因此过多的告警，会让整个系统处于不可运维的状态，应该该尽力的降低告警总量，譬如采用基于SLO的告警，就可以答复降低该指标（该指标越低越好）。
4. MTTA（平均响应或认领用时）：从告警发生到值班人员响应或者认领的时间间隔。越快的 MTTA，标志着越高的告警处理效率，潜在的代表着越高的服务稳定性。通过MTTA我们可以有效的度量团队的工作压力，以便决策合适的资源投入，确保团队始终处于可持续发展的状态（该指标合适就好）。
5. MTTR（平均恢复或解决用时）：从告警发生到问题解决的时间间隔。越快的 MTTR，往往意味着团队拥有更先进的观测技术、更强大的基础设施平台、更熟练的工作技能、以及对业务系统有更深入的理解（该指标越快越好）。

下面笔者将从产品、价格与服务三个维度，来探讨国内外这两款 OnCall 产品 Flashduty 和 Pagerduty 的差异。

产品

集成能力

故障管理系统作为流程处置中心，存储了全部的告警和故障数据。此类系统应该支持强大的数据接入和外呼能力，以便和其他各类系统或工作流集成，加速响应、增强协同。

故障处置

故障处置为系统的核心操作，该维度下主要考察产品功能的丰富度和灵活性。

平台能力

平台能力主要在成员管理、值班响应和通知能力层面，系统要具备基本的审计和单点登录功能。通知渠道越丰富越好，本地化支持越多越好，值班管理最好能满足组织内的特殊场景。

价格

PagerDuty 和 FlashDuty都提供多种订阅方式。选择的时候在满足自身需求的情况下，哪一款更具性价比，确保实际使用不超预算，计价方式的简单性都很重要。

• Pagerduty 价格页：https://www.pagerduty.com/pricing/incident-response/^[5]
• Flashduty 价格页：https://flashcat.cloud/flashduty/price/^[6]

服务

服务维度主要考察供应商服务响应的方式、专业性、及时效性。

注册福利

FlashDuty 给运维帮的用户准备了专属福利，现在点击专属链接 （复制该 https://flashcat.cloud/product/flashduty?from=yunweibang 链接到PC浏览器打开）完成注册，即可自动获得 FlashDuty专业版 30 天使用，立即开始在 IM 中处理告警。