在Google工作的头十年，我是一名普通工程师：我在地图上启动了公共交通工具，改善了搜索范围，并在YouTube上发现了垃圾邮件。 在某个时候，事实证明，在SWE（软件工程师）团队附近，有一些神秘的SRE（站点可靠性工程师）生活在生产环境中，并且了解有关基础架构，配置和监视的一切。 通常，他们带着难以理解的时间表来找我们，强烈建议在我们的服务中重写某些内容，以使它整洁地，成碎片地爆炸，而不是与所有邻居全部爆炸。 或者，他们建立了一些基础设施，以神奇的方式彻底解决了我们所有的问题。 或者据报道，本周将没有第二次发布，因为一个数据中心被飓风冲走了，一匹马被埋在了另一个旁边，并且干线被切断了。 一段时间后，很明显，您可以遇到这些问题的人，而可以通过比您自己的产品低几个抽象级别的解决方案找到解决方案（“当然，您为所需的流量支付了费用，但是这里他不会愚蠢地放入机架顶部的交换机中”）。
结果，我对SRE从内部的外观变得很感兴趣，然后我去了
Mission Control ，这是一个轮换计划，使我可以在SRE中度过半年的时间，获得宝贵的生产经验，如果需要的话，可以返回我之前的团队来分享所获得的知识。 相反，我留下来了，就像我目前的Video Processing SRE同事中的三分之二一样，也接受了常规工程师的培训。 现在，我本人以令人难以理解的图形吓S SWE，并从正在燃烧的数据中心撤离YouTube视频，并暂停进行和平的创意编码。 事实证明，在十五年的时间里，一个健康，有效的SRE组织在Google的实践，原则和方法中不断成长-但没人知道它们，因为那些人到了那里，还没有人回来。
解决Google SRE黑洞中的值班信息，SLO和验尸消失的问题的方法是
“ Site Reliability Engineering”一书 ，其中详细介绍了我们的SRE实际工作方式。 实际上，整个发布是为了两个新闻：
- 两周前，发布了上述SRE书籍的俄语翻译 。 如果您想知道如何在公司中获得健康的DevOps实践，则本书非常适合您。 如果您怀疑自己有SRE倾向，那么这本书就更适合您。
- 为了追求第一本书，《 网站可靠性工作手册》以及来自Google Cloud Platform生命周期的实用示例刚刚出版（到目前为止仅以英文出版）-我也强烈推荐它。