SRE 到底是什么？

最近在找工作，挺难的，自己也有问题，高不成低不就，但是我还是想为自己的这点执念坚持一阵，不想碌碌而终，泯然众人。

不过这不是今天的主题，今天是想写一点关于 SRE 的浅见。「浅见」不是谦虚的说法，SRE 这个概念虽然盛名已久，但是看 SRE 的书还是第一次。

为什么要读？昨日去百度面试，又是问到一半，感觉不太想继续的那种，感觉自己应该也是凉凉了。面试的最后，面试官跟我聊到了这本书《Google SRE》，回来我就想，要不读一读，毕竟现在 DevOps 的概念满天飞，SRE 也说了不少年，我却还未读过这经典的原始史料。还有另一个原因就是，当年听说 DevOps 这个词的时候，我就觉得这个词的重点是先 Dev 后 Ops，换句话说就是用软件工程的方式做运维，和运维自动化完全是两个 level，我想看看我的理解对不对。

我现在读的是中文版，目前阅读进度是：前 5 章已读完。

阅读速度还算比较快，前面几章介绍了许多概念，以及 Google 的基础环境。可能是读过一点 Borg 的论文，也看过 k8s 的书，理解起来比较快。

到目前为止，我觉得要理解 SRE，应该先理解管理的艺术。管理就在于需要张驰有度，需要在触碰红线的时候敢于纠正。SRE 团队不是天生就能和开发团队和谐共处的，即使在 Google 这样的环境下，也需要管理者在局势不妙的情况发挥作用，所以 SRE 不是单独发挥作用的。SRE 不完全是 DevOps，因为如果是这样的话，这就仅仅是一个技术和组织架构的问题了。至少从目前的阅读进度来看，Google 有很多开放性的理念或经验是十分具有管理性质的（虽然可能是技术经验的总结），比如不追求 100% 的可靠性，而是依据用户期望满足可靠性特定的要求；比如错误预算，使团队有犯错误的空间；另外，他们在制定 SLO 时，相对用户预期会留有一定缓冲区（可以理解），但是实际 SLO 却也不能太高，因为会让用户产生依赖，因此他们还可能主动制造故障，降低 SLO。

第五章，讲了另一个原则：减少琐事（不是消除）。他们对琐事有一个相对明确的定义：运维服务中手动性的、重复性的、可以被自动化的、战术性的、没有持久价值的工作。这么讲还是有点抽象，书中有更详细的描述，这里举几个例子说明哪些是琐事，哪些不是。

1. 第一次做，第二次做的不算琐事，但是重复做的就是琐事。
2. 如果主观判断是必须的，那就不是琐事。
3. 与服务同步线性增长的任务，比如随着流量、规模变大，要做的事情也变多的任务就是琐事。
4. 甚至手动执行脚本也可能算作琐事（视情况）。
5. 管理类杂务不算琐事，比如团队会议、总结等。

希望感兴趣的同学直接看书，书中有更好的阐述。

SRE 的一个公开目标就是保持工作时间中琐事的比例低于 50%，其他时间用来干嘛呢？主要用在工程项目上，这些工程项目可以用来减少未来的琐事，或添加新功能等。如果长期低于这个目标，管理者还会介入调整。

不知道大家有没有觉得这和每个人本身的成长策略是一样的，如果工作忙得没有时间学习，那么个人的能力也很难提升，所以常说决定你能力的是下班时间在做什么，也就是留了多少时间给学习。Goolge 要求 SRE 利用工作时间的 50% 以上做价值更大的事情，促使他们可以构建更强大的系统。

至少目前来看，SRE 制度的施行不仅仅是一个工程目标，它需要多方通力配合。接受它，也需要公司有魄力，至少在试错这个问题上，我们的思维多是追求完美，不犯错误，更不会主动制造错误降低期望。

本文链接：https://blog.xiaoyuyu.cn/post/Google-SRE阅读笔记（一）.html，参与评论 »

--EOF--

发表于 2019-10-18 14:12:00。

本站使用「署名 4.0 国际」创作共享协议，转载请注明作者及原网址。更多说明 »

提醒：本文最后更新于 1800 天前，文中所描述的信息可能已发生改变，请谨慎使用。