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

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

关于工具平台

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

但是工具平台谁来构建呢？这个值得捋一下。监控系统、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不同的告警。所有的告警都交给研发或者都交给运维，这种绝对的做法是不合理的。

关于变更发布

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

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

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

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

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

关于成本优化

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

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

小结

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

以上就是终结这个话题：运维岗位真的不能干了么？的详细内容，更多请关注AiHaoZ知识库其它相关文章！