🔧云计算：不需要运维工程师

本文基于我的两段工作经验撰写，不排除之后我对这件事的看法有所改变。

首先介绍我的两段工作经历，第一段是在某网络安全大厂任Python开发工程师，产品是toB的数据安全属性的数据分析软件，算上实习总共任职了三年半，期间从修BUG的实习生到小组长，负责Jupyter和对应的Papermill、Serving相关架构设计和二开，期间经历了三个运维工程师。第二段则是目前在创业公司做后端和基础设施架构师，团队里没有运维工程师，服务部署在AWS上，基础设施依赖包括但不限于AWS的各类云计算服务。

在我第一段经历中，运维工程师通常由如下职责：

• 提供公共的开发、测试、生产、演示环境，以支持开发、测试、产品演示等活动
• 对服务进行上下线，配置服务路由等
• 对服务器进行维护，缩扩容
• 对基础设施进行维护，比如存储、DB，为研发的各类需求提供基础件，如对象存储、块存储、Redis等等
• 对线上服务情况进行监测、告警

如此看来，似乎运维承担了团队中的重要职责，不容忽视，但实际上，运维在这些方面都有做的不好的地方。

1. 公共环境的支持：对于K8S架构下，主要是机器的腾挪和集群的部署，在自动化脚本的帮助下，这一类任务的工作时间不会太长。在第二段经历中，由云厂商host的K8S集群取代，由Github Action取代运维人工发布。
2. 运维进行服务上下线和路由定义，需要运维工程师和研发工程师进行沟通，运维工程师很难完全理解研发架构，而快速迭代的时候服务上下线和相关配置常常修改，我就有因为运维没时间而无法上线服务的情况。现在，我们由研发工程师进行服务上线工作，减少了不必要的沟通。
3. 服务维护缩扩容，之前已经通过K8S的autoscale实现了，目前也是通过AWS的自动缩扩实现的
4. 基础设施的维护，经典的运维已经无法支持了，比如之前的运维熟悉MySQL但不熟悉PGSQL，就无法对数据库进行调优配置，只能求助集团的工程师，但集团的工程师毕竟能力和经验都有限，在这上面我们付出了很多的精力，包括对Ceph的调优和维护，常常会因为存储性能和带宽瓶颈影响性能甚至业务功能。在第二段经历里，我发现AWS提供的存储、网络、DB、Redis等更加可靠，性能也更好。
5. 只需要集成Grafana等服务即可，不需要专门的运维人员。

综上，运维的核心功能已经不再刚需，如瑞典马工在《是时候让运维集体下岗了》所言，我们不需要运维，而需要更加内聚的开发团队，由每个Dev承担DevOps职责，再通过各个团队的组织，提供所需要的基础件。比如成立专门的Ceph团队，团队内通过DevOps方式进行二开，为所有人提供基础存储服务件。业务团队DevOps化，对服务进行直接部署和管理。

传统运维何去何从？其实在我的第一段经历中，运维还有一个职责：出差给客户部署环境。但这是吃力不讨好的，纯苦差事，也没有任何技术上的积累。这一职位同样可以被售前工程师替代。所以，或许每位运维的归途，要么是Dev化，成为真正的Nerd，要么是彻底Ops化，成为售前工程师。

那么，售前工程师又算是什么呢？