Table of Contents

Unpacking the On-Call Divide

拆解On-Call鸿沟

关于谁应该负责on-call[1]角色的分歧，一直是我职业生涯中的一个基石。这些争论都是有道理的，推理也是合理的。然而，尽管有所有的逻辑和公平的观点，参与辩论仍然是一项有争议的工作。

可以预见的是，一旦每个人都有机会分享他们的观点和个人故事，就会达成休战，而关于谁应该为数字服务on-call这个问题的答案是“视情况而定”。

这取决于众多的情景和考虑，所有这些不仅在行业中是独特的，而且在组织内的不同业务和团队中也是独特的。由于on-call的情况是无限的，所以存在无数种on-call的情况。

但问题是：“视情况而定” 的橄榄枝声明并没有真正解决或结束辩论，也没有触及争论持续存在的核心问题。当你解开对这个问题持有强烈感情和意见的理由时，你不得不问为什么我们觉得有必要继续提出谁应该待命的问题。这解决了什么问题？

无论你属于DevOps二元世界观(DevOps bimodal view of the world)的哪一方，系统的设计、构建和运行方式都有很大不同，但大多数人都同意两个重要的观点：1.on-call的角色是必要的 2.大多数人宁愿不做

我们都在这件事上留下了伤痕，但要想让辩论结束，我们个人的on-call经历必须首先得到认可和承认。我们每一个人的经验都是有效的，并且对于集体了解on-call的情况是非常重要的制度知识。

我的经历。你的经历。它们都代表了一幅高保真的画面，比任何日志或度量都更能理解发生了什么——也就是说，如果你的目标是以一种解决我们真正困扰的方式来改善on-call角色。我们要改善的是发生的个人现实情况和人影响的质量。

实施工具来帮助我们尽量减少业务影响是很容易的。耶！董事会和股东会很高兴。但是，我们有没有为未来的自己和后来的人做过任何改善on-call体验的事情呢？

这就是要解决的问题，首先要提供时间和空间来分享和倾听，探索在应对问题之前、期间和之后的认知情况，不幸的是，这些数据并没有显示在成绩单、系统日志或时间序列数据中，而我们在回顾性分析中通常最关注的就是这些。

到目前为止，我们还没有找到一种有意义的方式，将认可和探索纳入人们所经历的心理训练以及他们的认知推理、判断和决策机制的回顾练习中。

然而，为了解决on-call的分歧，我们需要开始探索我们之间的差距。on-call是什么样子的？询问发生了什么，希望了解原因，以便我们能够预防，这不过是治疗更深层次问题的外用药；更多的东西隐藏在伤疤之下。

如果我们能看到表面之下，我们会发现，只要花一点额外的时间和精力，仅仅通过创造空间和安全来揭示我们在on-call时发生的更完整的情况，就可以将on-call的烦恼降到最低，同时缩小鸿沟。

我们如何构建本书的结构

SRE虽然涉及复杂的技术系统，但归根结底是一种文化实践。文化是人的产物，这启发我们根据你在组织中的SRE数量来组织本书的各个部分–你具体处理什么，你的一天是怎样的，取决于有多少个SRE工程师。我们将本书的文章分为 “SRE新手” 、0-1个SRE、1-10个SRE、10-100个SRE和 “SRE的未来 ”。

读者如果想找寻先从哪里开始的指导，可以直接跳到最适用于自己的部分；但是，你仍然会发现阅读那些目前并不适用于你日常的部分的文章的价值。

在0到1个SRE时，还没有人被指定为SRE，或者你已经找到了你的第一个SRE，这个角色看起来几乎是孤独的。

在1到10名SRE时，你正在组建一个团队，有知识共享和分工的能力。

在10到100个SRE时，你已经成为一个组织，你需要思考的不仅仅是你所从事的系统，还需要思考如何组织这么多SRE。

“SRE新手” 涵盖了基础性的话题（尽管并不详尽！），对于那些刚刚开始SRE之旅的人来说是很有帮助的，即使是最有经验的SRE，也是一种复习。 “SRE的未来” 包含了一些文章，这些文章探讨了SRE潜在的发展方向，或者是（目前）坐拥时代潮流。

没有必要按照任何特定的顺序阅读本书。你可以从头到尾读一遍。或者，如果你对某个特定的主题感到好奇，可以翻到索引，在那里你可以找到关于该主题的所有文章。把它作为参考指南，或者是灵感的来源–可以在需要的时候提供一个震撼。或者，也许可以建立一个阅读俱乐部，每周一次挑选一篇文章与同事讨论。这就是散文集的魅力所在。我们希望你和我们一样喜欢阅读它们。

结语

SRE系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢

翻译不易，转载时请注明原文链接，谢谢

延伸阅读

1.on-call