DevOps/SRE 成长计划

本文最初目标是写给加入我们基础设施团队的新同事看的。个人觉得对所有人都是一个参考，所以就公开了。

以下是正文：

基于工程讨论，而非职位

说到DevOps/SRE成长计划，一开始笔者也把DevOps/SRE当职位来思考，因为只有人才会有“成长计划”。但是越写越发现写不下去。因为笔者无法给DevOps/SRE这两个职位的职责进行定义。

思来想去，个人觉得应该把它们当作工程来看，即DevOps工程和SRE工程。

把它们看作工程而不是职位的好处是避免职位所带来的局限性，也更适合独立讨论。比如A公司把DevOps定义为运维开发，那么，DevOps这个职位上会变成只关注运维系统的开发，很明显这对DevOps工程是非常不利的。

DevOps工程和SRE工程的范围

DevOps工程偏向于整个研发流程的效能及健壮性的建设，而SRE工程偏向于线上环境的可用性的保证（注意：并不是说不变更，系统就可用。强调通过“不变更”来保证系统可用性，是天真）。我倾向于将它们看作一体来建设，而不是独立的两个领域。

DevOps工程的好坏会直接影响SRE工程的好坏。比如DevOps工程中的版本化实践没有做好，会导致SRE无法定位线上运行的服务的版本，进而阻碍线上问题的定位与处理；SRE工程没有做好，又会导致DevOps工程设计之初缺少对可观测性的考虑。

什么叫研发流程的健壮性？指的是研发流程的反脆弱能力及扩展能力。如GitLab不会因为用户增长而挂掉；更换一个Pipeline实现是很容易实现的。

DevOps/SRE作为职位

虽然我们把DevOps/SRE看作工程，但是这些工程始终要分配到不同的人/团队去做。这时，我们该如何做呢？

笔者认为这个问题超出了本文讨论的范围。

DevOps/SRE 成长计划

既然我们已经把DevOps/SRE看作工程，那么，何来成长计划一说？

这要说到写本文的初衷。写本文的初衷是团队最近加入了从业务开发转过来的新人。新人在看到我们用到技术和要解决的问题时，会不知从哪里学起。

说回成长计划，指的是DevOps/SRE这两个工程领域的成长计划，不论你当前的职位是什么。

<