终结这个话题：运维岗位真的不能干了么？

昨晚马驰和来炜在线交流，话题是运维岗位真的不能干了么？我作为主持人，既是点火的又是拉架的 :) 听两位老兵分享了一些他们各自的观点，受益匪浅。今天抓紧记录一下，以免忘记，算是对昨天直播的一个复盘。

核心观点

运维岗位不会因为工具平台出现而简单消失，但会从“人工操作”转向平台工程、领域专家和业务协作。
Platform Engineer 的价值在于把监控、CI/CD、混沌工程、中间件等能力做成自助平台，并用平台落地规范。
研发是否 OnCall 不能一刀切，关键看告警类型、变更归属、可观测能力和谁能直接参与止损。
变更发布和成本优化不是单点工具问题，而是平台能力、工程规范和业务风险之间的系统性平衡。

关于工具平台

工具平台会取代一部分人工，这个其实是显而易见的，无需多言。

但是工具平台谁来构建呢？这个值得捋一下。监控系统、CI/CD 平台、混沌工程平台、中间件服务等，都是 Platform，由 Platform Engineer 来构建，简称 PE。PE 显然会拆成很多小组，每个 PE 小组负责有限的几个平台。这些零散的 PE 小组整体可以组成一个大的团队，比如叫基础架构团队，也可以拆到多个团队，比如跟工程效能相关的 PE 小组放到一个部门（比如效能工程部门），数据库、大数据相关的 PE 小组放到一个部门（比如数据部门），稳定性保障相关的 PE 小组放到一个部门（比如运维部）。

这个组织的划分，不同公司可能不同，关系倒不是很大，关键是 PE 团队应该怎么开展工作？PE 团队核心要做好以下事项：

构建好用的平台，让业务研发团队来自助服务。
平台要沉淀最佳实践。平台需要满足业务，但也要有业界最佳实践。如果业务需求和业界最佳实践相冲突，尽量应以业界最佳实践为准；如果短期实在无法做到，也应该制定分步落地计划，争取未来做到。否则个性的东西、反模式的东西越来越多，Platform 侧就会越来越难受，最后不堪重负，推倒重来，一地鸡毛。
要想方设法使用平台来落地规范，而不是用规章制度来落地规范。马驰举了一个例子挺好，他们有个规范，是要求业务程序不能利用本地磁盘存储状态数据。他们没有把这个作为红线法令颁布，而是明确告诉业务方会定期重启容器，让容器漂移。其实用过 AWS 的人应该知道，AWS 的虚机有的时候也会莫名重启。面向不可靠的基础设施提供高可用的应用程序，本就是应用研发人员的职责。
需要 COE（领域专家）来指导 Platform 的演进，因为擅长数据库的架构师未必擅长 Hadoop，擅长 Hadoop 的架构师未必擅长可观测性系统，擅长可观测性系统的架构师未必擅长混沌工程。

但所有的 Platform 都不是一蹴而就的。如果还没有这些 Platform，怎么办？公司应该先去招聘 COE，让 COE 一边做业务顾问，一边建设 Platform 能力。业务发展很快，Platform 自研太慢，也可以寻求外部供应商的解决方案。甚至 COE 本身，都是可以寻求外部解决方案的，视情况而定。

关于外部供应商

大家直观上会觉得：欧美的公司更乐于采购 SaaS 服务，国内的公司更乐于基于开源自建。是不是因为国内的公司理念不行？不尽然。国内很多领域缺少靠谱的 ToB 企业和产品才是最核心的问题。试想，如果某个 ToB 公司可以为甲方提供：

优秀的、先进的方法论。
稳定的、易用的产品。
优秀的、稳定的客户成功团队，帮助客户更好地落地最佳实践。
价格上，比甲方自己招聘人员自研更便宜。

只要 CXO 脑子没坏，肯定会选择引入这样的外部供应商。但是这样的 ToB 公司有么？这是个大大的问号。我们创建快猫星云公司，为客户提供可观测性产品，力争成为这样的供应商。希望业界 ToB 同仁一起努力！

延展一下择业问题，虽然某个细分领域可能现在还没有很好的供应商，但是 3 年以后呢？5 年以后呢？国外是不是已经率先有了？国内是不是有潜力不错的供应商了？如果已经有了，兄弟，你还敢继续投身在这个细分领域么？是否应该早做一些打算？

当然了，对于未来的预估，我们通常过于乐观，也过于悲观；对时间的预估，通常预估得超前，也预估得滞后。道理如此，兄弟，就看你怎么判断了。

关于应急故障处理

应该由研发来 OnCall 故障响应？还是运维？这个问题很有意思。马驰认为，线上 80% 的故障跟变更相关，变更是研发做的，研发显然更熟悉，让研发来 OnCall 故障响应，就意味着，80% 的问题研发可以更快地响应。

业务研发如此，数据库变更、基础网络变更、接入层的变更，都是同样的道理。做变更的那个人来响应自己的服务的故障告警，看起来是比较合理的。

实际上，这取决于两个前提：

监控、可观测性做得足够好，变更导致的问题能够通过这套平台及时发现。大家加油，希望每个公司都有一套完备的可观测性体系。
变更引入的问题是即时体现的。有些变更引入的问题如果一周之后才出现，做变更的人也很难怀疑到自己头上。

其实我们可以分两种情况对待。变更之后的服务稳定性监测，本就是做变更的人的分内之事；日常 OnCall 是另一个场景，应该单独对待。那日常 OnCall 应该由谁来做呢？应该是那些可以直接参与故障定位、止损的人。道理很明显，如果 OnCall 的人收到告警还需要去联系别人，那这个故障止损的时效性就太差了。

所以首先，应该对告警分门别类处理，不同的人 OnCall 不同的告警。所有告警都交给研发，或者所有告警都交给运维，这种绝对的做法是不合理的。

告警类型	更适合谁优先响应	判断理由
变更后即时异常	变更负责人或服务研发	最熟悉变更内容和回滚路径
基础设施异常	基础设施或运维团队	更熟悉网络、宿主机、集群和资源层
数据库或中间件异常	对应领域专家或平台团队	需要组件经验和平台权限
业务链路异常	服务 owner、SRE、业务值班协同	需要同时判断业务影响和技术止损

关于变更发布

最终目标是有共识的，就是让业务研发可以自由发布版本，但是我们又希望受控，希望安全地发布，希望在发布的同时保障业务连续性。这就对 CI/CD 系统提出了极高的要求。

如果不管不顾，变更系统的底层就是去一批机器上批量跑个脚本的事情。但是附加了上述这些要求之后，就困难了很多，变成了一个系统性工程。

业务研发侧，需要做好埋点可观测，需要监控类系统能够及时发现问题，甚至告警之后自动阻断发布流程。需要有一些蓝绿发布、金丝雀发布的手段落地，需要有一些自动代码扫描、安全扫描的能力。工具体系不完备，一味要求研发确保变更可回滚、确保变更安全，也是不合适的。CI/CD 的能力水平如何，基本可以看出这个公司的技术实力。

如果你所在的公司，还是研发给运维提单，运维去线上操作，要掂量一下这么做是否合理了哈。当然，上面的做法更多偏互联网，未必适合所有公司，这个直播也只是提供一个思路，你要自行斟酌。

这个理想情况怎么达到？在理想情况达成之前应该怎么一步一步走过去？时间问题，直播里并未探讨。如果公司的业务适合跑在 Kubernetes 上，用 Kubernetes 来构建这么一套体系相对容易，可以尽快行动起来。如果公司的业务必须跑在物理机、虚拟机环境，那就先搞一个统一的变更发布平台，然后哪里缺失补哪里，逐渐完善。

关于成本优化

两位嘉宾谈得不多，不过大家对这个事情都非常慎重。提醒大家：

人比硬件贵，千万不要做花费了 5000 万的人力，节省了 4000 万硬件成本的事情。
要给业务留出足够的冗余算力。如果资源用得太紧张，该批的预算不批，因为容量导致故障的话，客户体验受损、舆论不利，得不偿失。
可笑的例子是，用 3000 万买量，为了节省 300 万的硬件成本，没抗住量，真的就呵呵了。

小结

现在这个阶段，平台体系还没有那么完备，使用自助 Platform + COE + BP（Business Partner）的架构来搭建运维体系，看起来是靠谱可落地的。未来 Platform 足够好的时候，可以缩减 BP 人力（BP 也慢慢具备 COE 的能力）；Platform 继续完备，可以继续缩减 COE；再之后，嗯，运维和研发可能就都不需要了吧。

更现实的判断是：岗位名称会变，工作重心会变，但稳定性、效率、成本和风险这些问题不会消失。能把经验沉淀到平台、能理解业务场景、能在故障和变更中做系统性判断的人，仍然会有价值。