DevOps/SRE 新人成长计划

cat-gce3f1f3f0_640.jpg

基于工程讨论，而非职位

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

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

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

DevOps工程和SRE工程的范围

DevOps工程偏向于整个研发流程的效能及健壮性的建设，而SRE工程偏向于线上环境的可用性的保证（注意：并不是说不变更，系统就可用）。

DevOps工程的好坏会直接影响SRE工程的好坏。比如DevOps工程中的版本化实践没有做好，会导致SRE无法定位线上运行的服务的版本，进而阻碍线上问题的定位与处理。

什么叫研发流程的健壮性？指的是研发流程的反脆弱能力。

DevOps/SRE作为职位

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

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

DevOps/SRE 成长计划

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

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

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

千万不要以职位来局限自己。

笔者希望这篇文章能帮到新人。让他们有一个大的学习方向。

DevOps/SRE 领域知识/能力清单

在说到成长计划时，我一开始想以下清单：

• 持续集成：各种技术栈构建的方法（比如前端的npm，后端的Maven，android的Gradle等），各种自动化测试的方法（如单元测试、接口测试等）、分布式构建的方法、精准测试的方法；
• 持续部署：传统的部署方式，云原生的部署方式，各种发布模式（如金丝雀、蓝绿）；
• 研发流程指标收集：首先你得知道有什么指标可以收集，然后知道如何收集成本低，准确度高；
• 制品管理：不同的技术栈，制品的管理方式不同；
• 配置管理：各种集中式的配置管理平台（比如Nacos，Etcd等），各种模板语言（比如go template、Jinjia2），支持编程的配置语言（如Jsonnet），各种技术栈本身的配置方式（比如SpringBoot的application.yaml配置、JVM的配置）；
• 容量规划能力：笔者目前没有太多的经验；
• 可观测性：日志、指标、调用链三种可观测性的建设，建立SLO的能力，还有与之对应的告警技术；
• 事故的处理能力：事中处理、事后总结；
• 流水线领域：指的是流水线的领域知识，比如串并行、执行步骤、触发条件等语义，了解这些后，任何流水线的实现方式的使用都应该能得心应手；
• 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。

该如何学

不要被上文所列的知识清单所惊讶。如果你认同前文提到的DevOps/SRE工程的范围，你就会坦然。

但是该如何学呢？

排除掉个人喜好因素，本文写的是工程级别的成长计划，所以，不讨论细分领域。比如行业里有专门搭建、调优Ceph的人，我们可以认为他们是Ceph方向的SRE。

站在工程的角度来看，笔者认为新人可以按以下阶段练习并思考，在每一个阶段分别去熟悉使用到的技术栈：

1. 熟悉持续编译打包：选择一个平台，如Jenkins，实现当代码提交后，你的应用能自动化编译打包。这个过程，就是流水线的原型了。可以分成以下几个等级：

   级别1：通过GUI创建流水线，对源代码进行编译打包，并将包上传到指定的地方集中管理；

   级别2：通过Pipeline as Code创建流水线，对源代码进行编译打包，并将包上传到指定的地方集中管理；

   通过实践分析这两种方式的优缺点。设想当你要支持99个工程的编译打包时，你会怎么做？

2. 熟悉将上一步的包部署到指定的IP的机器上。这个阶段可以分成以下几个等级：

   级别1：通过在GUI上设置，一步步设置部署一台机器上；

   级别2：通过Pipeline as Code部署到一台机器上；

   级别3：实现幂等的部署，即执行一次和执行多次部署操作后，结果都应该是一样的；

   级别4：实现编译打包后，直接部署到目标机器上。

   思考：如何将包部署到100台机器上？

   接下来所有的阶段，都只能通过as Code的方式实现。

3. 熟悉制品的版本的管理。

   级别1：手工管理制品及制品与版本之间的关系；

   级别2：将制品放到像Nexus这样的平台上；

   级别3：将制品的上传与使用集成到前面的步骤中。

   思考：什么样的版本号能让你后期更方便地找到制品所对应的源代码？

4. 在持续编译打包过程中加入单元测试。

   级别1：执行编译打包后，执行单元测试，如果失败，流水线失败，不上传制品；

   级别2：测试结果与制品关联起来，只有通过测试的制品，才能够被使用。

   思考：如何实现当a文件变动，只执行a文件相关的单元测试？更深入的思考，当团队成员不会写单元测试，你该如何做？甚至领导都不支持写单元测试呢？

5. 在部署环节加入冒烟测试。

6. 熟悉多环境的部署。

   级别1：每个环境的制品是分别编译打包的；

   级别2：每个环境使用的是同一制品。

   本质上，多环境的管理属于配置管理的范畴。本阶段重点是思考配置的管理。

7. 熟悉针对K8s环境的部署。

   级别1：只通过kubectl apply -f的方式部署一个应用；

   级别2：通过Helm或Kustomiz的方式部署一个应用；

   级别3：部署100个应用到一个K8s集群；

   级别4：部署100个应用到5个K8s集群。

   思考：两种部署方式的区别。

8. 加入指标监控/告警。包括所有的层次的监控。

   级别1：针对VM级别的监控；

   级别2：针对K8s环境的监控；

   级别3：将告警发送到指定IM上。

   思考：VM与K8s的监控之间的区别；声明式与GUI配置告警规则之间的区别。

9. 引入调用链技术。

10. 各种发布模式的实践。

    级别1：滚动更新；

    级别2：手工金丝雀发布、手工蓝绿部署；

    级别3： 自动化金丝雀发布、自动化蓝绿部署；

以上成长计划只是大的轮廓。我总结一下：

对于新人，你大脑里可以将研发流程看成：开发→编译打包 →部署→监控。从开发人员提交代码到git后，后面的阶段，你都要进行自动化。至于如何做到全自动化，就看你的练习和思考了。

成长计划其实就是一个个实现自动化的练习题，促使你去思考，如何做才是更好的。

后记

熟悉我的朋友一看上文的知识清单，就猜到是我的技术栈。所以，上面的清单是有局限性，我也是人，超出我认知的，我可能无法想得到了。但是那份清单并不是重要。重点是练习题背后的思考。

当然，以上的练习题需要配合一些这个领域的专业书，你才会思考得更深入。请关注“持续交付实践指南”公众号，下篇文章写这个领域都有哪些专业的书。