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