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这两个工程领域的成长计划，不论你当前的职位是什么。
千万不要以职位来局限自己。
笔者希望这篇文章能帮到新人。让他们有一个大的学习方向。
DevOps/SRE 领域知识/能力清单
DevOps/SRE 涉及的领域非常的广。通过以下清单，我们了解到适合DevOps/SRE领域的人，通常是通才。而不是专才。在我们这个行业，通才往往不受待见。以下是清单内容：
- 持续集成：各种技术栈构建的方法（比如前端的npm，后端的Maven，android的Gradle等），各种自动化测试的方法（如单元测试、接口测试等）、分布式构建的方法、精准测试的方法；
- 持续部署：传统的部署方式，云原生的部署方式，各种发布模式（如金丝雀、蓝绿）；
- 研发流程指标收集：首先你得知道有什么指标可以收集，然后知道如何收集成本低，准确度高；
- 制品管理：不同的技术栈，制品的管理方式不同，比如Nexus；
- 配置管理：各种集中式的配置管理平台（比如Nacos，Etcd等），各种模板语言（比如go template、Jinjia2），支持编程的配置语言（如Jsonnet），各种技术栈本身的配置方式（比如SpringBoot的application.yaml配置、JVM的配置）；
- 容量规划能力：笔者目前没有太多的经验；
- 可观测性：日志、指标、调用链三种可观测性的建设，建立SLI可视化的能力，还有与之对应的告警技术；
- 事故的处理能力：事中处理、事后总结；
- 流水线领域：指的是流水线的领域知识，比如串并行、执行步骤、触发条件等语义，了解这些后，任何流水线的实现方式的使用都应该能得心应手；
- Everything as Code：这个领域估计很少人在意，如Terraform、Packer、Pipeline as Code、Config as Code等；
- 代码管理：GitLab、GitHub等平台的使用、SonarQube等代码静态扫描的使用、分支的管理模式、代码仓库的结构设计；
- Code Review：了解Code Review的各种实现方式；
- 安全扫描：代码、制品、依赖等安全扫描；
- 后端服务架构方面：微服务的架构模式、高可用的知识、分布式一致性知识等；
- ServiceMesh：Istio、等了解越多越好；
- 虚拟化技术：容器化、Vagrant、Kubernetes、OpenStack，了解越多越好；
- 负载均衡：LB领域知识、具体LB技术知识（如F5、Nginx、Kong等）；
- MQ中间件：如Pulsar、Kafka；
- CDN技术：CDN领域知识、CDN厂商知识；
- 数据库知识：各种数据库的搭建、配置、高可用等；
- 操作系统领域：操作系统的安装、调优等；
- 网络：TCP/IP、DNS、HTTP等；
- 云厂商：了解越多越好。
以上并不能包括所有，因为还有很多细分的领域，比如AI领域和游戏领域。
最后，还要学习将以上所有的领域的知识进行有机集成，并自助化的能力。如果没有这个能力，以上的知识无法做1+1=3。
该如何学
首先你要有心理准备。不要被上文所列的知识清单所惊讶。并没有人要求你一次性学会所有的领域知识。
但是该如何学呢？
排除掉个人喜好因素，本文写的是工程级别的成长计划，所以，不讨论细分领域。比如行业里有专门搭建、调优Ceph的人，我们可以认为他们是Ceph方向的SRE。
站在工程的角度来看，笔者认为新人可以按以下阶段练习并思考，在每一个阶段分别去熟悉使用到的技术栈：
熟悉持续编译打包
选择一个平台，如Jenkins和GitLab CI。实现当代码提交后，你的应用能自动化编译打包。这个过程，就是流水线的原型了。可以分成以下几个等级：
级别1：通过GUI创建流水线，对源代码进行编译打包，并将包上传到指定的地方集中管理；
级别2：通过Pipeline as Code创建流水线，对源代码进行编译打包，并将包上传到指定的地方集中管理；
思考：
- 通过实践分析以上两级别的区别；
- 设想当你要支持99个工程的编译打包时，你会怎么做？
- 多代码仓库集成打包的流水线该如何实现？
熟悉将制品部署到指定的IP的机器上
- 级别1：通过在GUI上设置，一步步设置部署一台机器上；
- 级别2：通过Pipeline as Code部署到一台机器上；
- 级别3：实现幂等的部署，即执行一次和执行多次部署操作后，结果都应该是一样的；
- 级别4：实现编译打包后，直接部署到目标机器上。
思考：如何将包部署到100台机器上？
接下来所有的阶段，都只能通过as Code的方式实现。
熟悉制品的版本的管理
- 级别1：手工管理制品及制品与版本之间的关系；
- 级别2：将制品放到像Nexus这样的平台上；
- 级别3：将制品的上传与使用集成到前面的步骤中。
思考：什么样的版本号能让你后期更方便地找到制品所对应的源代码？
在持续编译打包过程中加入单元测试
- 级别1：执行编译打包后，执行单元测试，如果失败，流水线失败，不上传制品；
- 级别2：测试结果与制品关联起来，只有通过测试的制品，才能够被使用。
思考：
- 如何实现当a文件变动，只执行a文件相关的单元测试？
- 当团队成员不会写单元测试，你该如何做？甚至领导都不支持写单元测试呢？
在流水线中加入集成测试
调查团队里多个系统之间是如何集成的，并考虑如何设计自动化集成测试。
熟悉多环境的部署。
- 级别1：每个环境的制品是分别编译打包的；
- 级别2：每个环境使用的是同一制品。
本质上，多环境的管理属于配置管理的范畴。本阶段重点是思考配置的管理。
熟悉针对K8s环境的部署
- 级别1：只通过kubectl apply -f的方式部署一个应用；
- 级别2：通过Helm或Kustomiz的方式部署一个应用；
- 级别3：部署100个应用到1个K8s集群；
- 级别4：部署100个应用到5个K8s集群。
思考：两种部署方式的区别。
熟悉on-call流程
只有你了解一个告警通知如何处理、处理过程需要哪些信息，你才知道如何设计SRE体系及DevOps过程。没有救过火，你是不会对SRE这份工作有体会的。
加入指标监控/告警
包括所有的层次的监控。
- 级别1：针对VM级别的监控；
- 级别2：针对K8s环境的监控；
- 级别3：将告警发送到指定IM上；
- 级别4：将告警根据不同的规则通知到当时的on-call。
思考：
- VM与K8s的监控之间的区别；声明式与GUI配置告警规则之间的区别；
- 日志监控、指标监控、调用链监控之间的关系；
- 日志监控前提是日志结构化，该如何结构化？
各种发布模式的实践
- 级别1：滚动更新；
- 级别2：手工金丝雀发布、手工蓝绿部署；
- 级别3： 自动化金丝雀发布、自动化蓝绿部署；
小结
以上成长计划只是大的轮廓。我总结一下：
对于新人，你大脑里可以将研发流程看成：开发→编译打包 →部署→监控。从开发人员提交代码到git后，后面的阶段，你都要进行自动化。至于如何做到全自动化，就看你的练习和思考了。
成长计划其实就是一个个实现自动化的练习题，促使你去思考，如何做才是更好的。
后记
熟悉我的朋友一看上文的知识清单，就猜到是我的技术栈。所以，上面的清单是有局限性，我也是人，超出我认知的，我可能无法想得到了。但是那份清单本身并不是最重点的。最重点的是练习题背后的思考。
最后，如果你希望加入“持续交付实践指南”微信交流群，可以添加微信号：zhaizhijun0 ，他会拉你入群。
