运维岗位的未来发展趋势：行业需求分析

上周五，马驰和赖伟在网上进行了讨论。话题是：运维岗位真的没有了吗？作为主持人，我既是点燃者，也是引导者：）听两位老兵分享各自的一些观点，我受益匪浅。今天一定要记录下来，以免忘记。也算是对直播的一次回顾。

关于工具平台

工具平台将取代部分劳动力。这实际上是显而易见的，不需要进一步解释。

但谁来构建工具平台呢？这值得一看。监控系统、CI/CD平台、混沌工程平台、中间件服务等都是基于PE构建的，简称PE。 PE显然分为很多组，每个PE组负责有限数量的平台。这些分散的PE团队可以组织成一个大的团队，比如基础设施团队，也可以拆分成多个团队。比如工程性能相关的PE团队可以放在一个部门（比如性能工程部）、数据库、大数据。相关的PE团队放在一个部门（比如数据部门），稳定性保障相关的PE团队放在一个部门（比如运维部门）。

这个组织的划分在不同的公司可能会有所不同，但是关系并不是很重要。关键是PE团队应该如何开展工作？ PE团队的核心应该做到以下几点：

但并非所有事情都是一朝一夕就能实现的。如果你还没有这些东西怎么办？公司应该先招募一名COE，让COE在能力建设的同时充当业务顾问。如果业务发展快而自研太慢，公司还可以向外部供应商寻求解决方案。甚至COE本身也可以根据情况寻求外部解决方案。

关于外部供应商

直观上大家会感觉欧美企业更愿意购买SaaS服务，而国内企业更愿意在开源的基础上打造自己的服务。是因为国内公司理念不好吗？并不真地。核心问题是国内很多领域缺乏可靠的ToB公司和产品。想象一下，如果一家ToB公司可以为甲方提供：

只要CXO不差，他一定会选择引入这样的外部供应商。但有这样的ToB公司吗？这是一个很大的问号。我们通过向客户提供可观测性产品来创建并努力成为这样的提供商。希望ToB业界同仁共同努力！

延伸到职业选择的问题，虽然现在某个细分领域可能没有好的供应商，但三年后呢？ 5年后呢？国外已经率先行动了吗？中国有没有潜力的供应商？如果你已经有了，兄弟，你还敢继续投身于这个小众领域吗？我们是否应该提前制定一些计划？

当然，当谈到对未来的预测时，我们通常要么过于乐观，要么过于悲观。当谈到时间估计时，我们通常会做出过于超前或过于滞后的预测。是啊，兄弟，就看你怎么判断了。

关于紧急故障排除

故障响应是否应该由研发部门处理？还是运维？这个问题很有趣。马驰认为，线上80%的故障都与变化有关。改变是R&D做出的，R&D显然对它们更加熟悉。让研发响应故障，意味着研发可以更快地响应80%的问题。

对于商业研究和开发来说也是如此。数据库变更、基本网络变更、接入层变更都是一样的。做出改变的人响应自己服务的故障报警似乎更合理。

其实这取决于两个前提：

监控和可观察性足够好，通过这个平台可以及时发现变化带来的问题。大家加油，希望每个公司都有一套完整的可观测体系。变更带来的问题会立即反映出来。引入一些更改 如果问题直到一周后才出现，那么进行更改的人将很难怀疑自己。

其实我们可以分两种情况来对待。变更后的服务稳定性监控由变更者负责。日常生活又是另外一个场景，应该分开对待。那么谁应该每天这样做呢？应该是那些能够直接参与故障定位和止损的人。原因很明显。如果有人接到报警后还需要联系其他人，那么故障止损的及时性就太差了。

所以首先要对报警进行分类处理，不同的人会收到不同的报警。把所有的报警都交给研发或者运维是不合理的。这种绝对的做法是不合理的。

关于变更发布

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

如果你不在乎的话，改变系统底层只是在一批机器上批量运行一个脚本而已。但增加了上述要求后，就变得困难多了，成为一个系统工程。

在业务研发方面，需要做好可观察点，需要有监控系统及时发现问题，甚至报警后自动阻塞发布流程。需要有一些蓝绿发布、金丝雀发布的手段，需要一些自动代码扫描和安全扫描的能力。工具系统不完整。一味地要求研发来确保变更可以回滚、变更是安全的，这是不合适的。 CI/CD能力的高低基本可以看出企业的技术实力。

如果你的公司仍然为研发提供运维提单，并且运维是在线操作，你应该考虑这是否合理。当然，上述方式更多的是互联网方式，可能并不适合所有企业。这次直播只是提供一个想法，还得你自己考虑。

当然，如何实现这种理想的情况呢？在达到这个理想的情况之前，我们应该如何一步一步地去实现呢？直播中并没有讨论时间问题。如果公司的业务适合在互联网上运行，那么搭建这样的系统是比较容易的，可以尽快采取行动。如果公司的业务必须运行在物理机或虚拟机环境中，那么首先创建统一的变更发布平台，然后填补空白并逐步完善。

关于成本优化

两位客人话不多，但大家对这件事却十分谨慎。提醒大家：

人比硬件更贵。千万不要做花费5000万人力，节省4000万硬件成本的事情。为业务留下足够的冗余算力。如果资源使用过于紧张，该批次的预算将不会被批准。如果因为容量出现故障，客户体验就会受损，舆论会负面，得不偿失。一个可笑的例子是，为了节省300万的硬件成本，体量却无法维持，实在是浪费。概括

现阶段，平台体系尚未完善。采用自助+COE+BP()的架构来构建运维系统，看起来是可靠可行的。等以后情况足够好了，我们可以减少BP的人力（BP已经逐渐具备了做COE的能力），随着它的不断完善，我们可以继续减少COE。以后呢，那么运维、研发可能就不需要了。

鱼云专注于提供高性能云服务器和物理服务器租赁服务。我们致力于为企业提供安全、稳定、高效的解决方案，确保数据无忧、业务顺畅。