像 Google SRE 一样 OnCall

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

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

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

1. 职业停滞：如果花在工程项目上的时间太少，你的职业发展会变慢，甚至停滞。Google确实会奖励做那些脏活累活的人，但是仅仅是该工作是不可避免，并有巨大的正面影响的时候才会这样做。没有人可以通过不停地做脏活累活满足自己的职业发展。
2. 士气低落：每个人对自己可以承担的琐事限度有所不同，但是一定有个限度。过多的琐事会导致过度劳累、厌倦和不满。
3. 造成误解：我们努力确保每个SRE以及每个与SRE一起工作的人都理解SRE是一个工程组织。如果个人或者团队过度参与琐事，会破坏这种角色，造成误解。
4. 进展缓慢：琐事过多会导致团队生产力下降。如果SRE团队忙于为手工操作和导出数据救火，新功能的发布就会变慢。
5. 开创先河：如果SRE过于愿意承担琐事，研发同事就更倾向于加入更多的琐事，有时候甚至将本来应该由研发团队承担的运维工作转给SRE来承担。其他团队也会开始指望SRE接受这样的工作，这显然是不好的。
6. 促进摩擦产生：即使你个人对琐事没有怨言，你现在的或未来的队友可能会很不开心。如果团队中引入了太多的琐事，其实就是在鼓励团队里最好的工程师开始寻找其他地方提供的更有价值的工作。
7. 违反承诺：那些为了项目工程工作而新入职的员工，以及转入SRE的老员工会有被欺骗的感觉，这非常不利于公司的士气。

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

管中窥豹，Google SRE 的工作方式，不是谁都有条件学，也不是谁都