查看原文

本文是 Google Cloud Platform 团队的工程博客新文章，通过不少例子介绍了在 Google 内部是如何在开发和保障服务可靠性之间做权衡。简单介绍 Google SRE 团队的现状：两个 Shard 在欧洲和美国两个时区的团队各值守 12 小时，两班倒，监控核心的 10 个最高流量的服务外加十几个小一些的服务。这个团队的监控指标既有关于用户使用体验的顶级 SLO 指标，也有核心组件可用性的细粒度的 SLO 指标。一旦出了问题，SRE 团队可以将任何单一相对应的 SLO 指标转给相关的开发团队去核查。服务会配置 error budget，举个例子，对于某个服务，如果一小时内烧掉九个小时的错误预算就报警；如果一周的错误预算超过上周的，那就提工单建档排查。

从 Escalation policy 的目的来看，它既要能保证快速响应，又要减少不必要的误报，并保持测量项的准确度。对此，Google 的做法是设定多个层级的阈值，进入越高层级的阈值，就投入更多的资源去响应。

从 Escalation Policy 的结果来看，并不是说把挂掉的服务复活就算完了，要想将事故标为解决，必须以下三者其一： 1) 找到 root cause, 或者 2) 引入自动修复可以避免人工干预, 或 3) 等一段时间评估认定不太会频繁出现或威胁到 SLO。

从 Escalation Policy 的定义来看，它分为了四级：

1. 停在 SRE 这一层，SRE 得到通知并快速响应。根据设定的 Runbook，应急处置，采取 mitigating actions(例如负载均衡重定向流量，或者回滚）。开发团队不会被通知，只会得到 SLO 被影响的报告。
2. SRE 搞不定，开始寻求 开发团队的帮助。找到 dev lead & oncall, 迅速定位 root cause。当事故处理到回到正常 SLO 时，SRE 开始回滚一些应急处置，搞 postmortem，甚至如果认定当前 SLO 不够用，就改进 SLO 本身。
3. 错误持续了好几天，但还是没搞回 SLO，或者 30天的错误预算花光了，SRE 会停掉 feature release，让团队专注修这个问题。在接下来的几周，只上线修问题的那些变更，开发团队以解决这个问题作为 P0。
4. 如果更严重，那就牵涉 leadership 还有更多人进来解决问题。

这个机制里面有让团队可以自主解决问题，比较灵活，也有引入团队制衡的考量，比如说让开发团队关注 error budget ，以及不解决完问题不让上线新功能等等。

衍生思考：这篇文章各个部分相应成章，做完简介后写目的，再写结果，最后写怎么操作，是一篇很棒的工程文章。另外， 这套流程本身也是我所在组的日常工作，我的工作其实就是探寻这些 SLO 指标，以指导全组应急事故处置时的操作。我认为这篇文章基本上将 Escalation Policy 这个概念讲的很透彻，工程师们可以以这篇文章作为标杆结合自家企业本身的需求去完善 Escalation 流程。