云计算和 AI 时代下的运维转型

本文作者 赵成

花名“谦益”，是公众号“Forrest 随想录”的作者，多届 ArchSummit 运维专题明星讲师和优秀出品人，TGO 杭州分会会员。目前专注于云计算和人工智能时代的运维转型和提升。加入蘑菇街之前，赵成在华为工作了七年，经历过开发、测试、运维以及一线客户服务等诸多岗位。他在不断的历练中迅速成长，培养了全面思考的意识和能力，积累了丰富的电信级和互联网业务研发及运维经验。

首先来看业界的三个典型案例，一个来自国外，一个来自国内，最后一个是我自己团队的案例，都非常具有代表性。

• 国外Netflix的模式

Netflix从一开始就强调开发人员要进行自助化运维，其内部的运维工作全部由开发人员完成，平台也由开发人员自己完成，只保留极少的Core SRE角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是其电商业务，还是AWS公有云服务，全部都由开发人员完成。因为具有技术前瞻性，微服务以及分布式这样的技术架构早已在这样的团队落地，再加上其超强的技术能力，所以可以从一开始就这样来做。

• 国内阿里巴巴的模式

阿里巴巴技术团队在2016年左右也开始进行“去PE（即生产工程师，相当于应用运维的角色）”的组织架构调整，原来需要PE完成的运维工作，全部由开发人员承担。原来的PE要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应调整的PE就只能离开了。之前在业务稳定性保障过程中起到核心作用的PE，随着各类工具平台的逐步完善，在高度自动化之后，最终也只能面临职业和技能上的转型。

与Netflix正好相反，这种模式是从一开始技术能力无法满足要求，能靠人就先靠人的阶段逐渐过渡形成的，在过程中不断完善各类自动化平台。

• 我自己的团队在发展过程中的模式

我大致回顾了一下，发现从2016年年初到目前，我自己的团队一直没有招聘新的应用运维人员。总结了一下，并不是没有合适的人，而是主要有以下两个原因。

1. 第一个原因：随着自动化逐步完善，效率不断提升，单个PE能够支持的业务变得越来越多；同时，很多事情都可以由开发人员自助完成。
2. 第二个原因：我会有意识地招聘具备开发能力的人员，他们入职后，一方面参与各类平台的开发，另一方面还要定期轮岗做一些运维工作。后来我发现，只要进行有效的引导，同时具备运维和开发能力是不成问题的。

结果就是，应用运维的岗位需求已经没有那么强烈了。这一趋势，跟阿里巴巴的发展过程非常相似。不过，我从来没有刻意地设计过这个过程，基本算是顺其自然。

从上面的这三个案例来看，无论哪种情况，就运维来说，随着日常重复的人工操作被逐步自动化之后，如果还是固守原有的工作模式和思路，能做的事情、能够提供的价值，就一定会越来越少。终究有一天，我们会面临和阿里巴巴PE同样的转型问题，而且这个转型是在可预见的短期内就会到来的。

既然预见到了趋势，那么下面就来谈谈应该如何面对。

• 应用运维的转型

如果只允许给一条建议的话，我给出的建议就是——

学会写代码

早期的运维岗位，基本上不会对代码能力有很强的要求。所以对这个岗位上的人员来说，这一点就成了当前技能上最大的短板，也成了后续职业发展的瓶颈限制。

但是，运维行业发展到现在，无论是从趋势上看，还是从我们现在所经历的实际现状来看，单纯靠人力维护的投入越来越无效。

所以，我们无论是做运维转型，还是做其他技术转型，具备代码开发能力，已经成为了一项必备技能。

这里多说一点，大多数运维人员不具备代码开发能力，并不是自身的能力问题。很多情况下都是因为不够自信，对写代码心存畏惧，担心自己写不好，所以一开始就把自己给限制住了。如果是这样，我给的建议再多也没用，关键还是要靠自己先迈出第一步。

现在在我自己的团队中，有很多同事做了多年运维工作后，因为乐于尝试和挑战，很快就可以独立编程了，再加上自身有很多一线运维的经历和经验，可以说既懂业务又懂开发，反而比单纯做平台和工具的运维开发更有竞争力。

下面是一些具体的建议。

1. 代码开发上，我建议从Python、PHP或Go这些上手比较简单的语言开始。不是只写写脚本，而是一定要能够实现完整的业务功能或流程。一开始尝试去做一些简单的工具，实现一些简单的功能，再往后可以通过一些复杂的业务场景深入下去。一旦场景的复杂度高了，就会涉及更高的开发技能，比如并发、缓存、消息甚至是服务化框架等。关键是敢于迈出第一步，然后逐步转变。相信我，真的没有那么困难，我身边有太多优秀的转型案例，当事人都是这么过来的。
2. 提升产品意识。不是要求运维同事都成为优秀的产品经理，或者具备很强的产品设计能力，而是一定要有产品意识，只要有这么一点点小的转变就会带来大的不同。有很多运维同事，甚至是资深级别的，往往还是习惯于处在最末端，前面有什么事情找到他，他就处理什么事情，属于被动响应的类型。但是，如果你有产品意识，能够将你所做的事情整理汇总起来，然后做一下流程上的串联，再把流程中每个环节步骤的功能进行详细描述，同时在梳理的过程中，对一些不合理、不规范的地方进行标准化约定，也就是落实我们前面说的标准化，最后输出的内容就是平台开发所需要的需求分析和产品需求文档的雏形。如果能将所做的事情从单纯的运维操作转化到这个维度，那我们呈现的价值就完全不一样了。
3. 提升技术运营意识。这一点跟上面类似。简单来说，就是如何根据需求，把承载了标准化和规范体系的工具平台真正落地应用起来。同时，在落地的过程中，先进行问题收集和一定的数据分析，再回到产品设计和需求实现的流程中进行改进，形成一个良性的闭环。

在阿里巴巴的PE转型过程中，有一部分运维转型去做效能工具研发，有一部分经验丰富的资深运维就转型成为技术产品和技术运营这样的运维专家角色。对于开发人员已经可以自助完成的部分一线运维工作，运维专家还会在这个过程中对开发做一些赋能。

所以，对于当前运维岗位上的同事来说，有这样一个先天优势来承担这样的职责。可以参考阿里巴巴PE转型的经验，根据自己的优势特点提前做好方向规划。

• 云计算和AI带给我们的挑战

机遇与挑战并存，上面我们更多地讲了机遇，但是与此同时也要看到挑战，甚至是危机。

而最大的挑战和危机往往都不是来自内部的，当我们还在纠结如何不被开发替代的时候，外面的技术环境已经发生了很大的变化，而这种变化带来的将是颠覆性的改变。

有两个最大的外部因素：

一个是云计算，一个是火热的AI

下面我们分别来探讨。

首先，云计算发展到今天，已经不是我们想象中的只能提供IaaS服务的云平台。目前，各大公有云上的PaaS产品体系也已经非常完善，前面讲到的各类分布式中间件产品都有所覆盖，而且这些产品，还都是各大公有云平台公司在自有业务上锤炼出来的非常优秀的产品。

简单来说，现在我们去做一个业务，可以基于这些基础服务，完全无须自研纯技术产品，只要专注业务逻辑开发即可。我了解到国内某新兴的O2O产品，每日有超过千万笔的订单量，除业务代码外，其他基础层面的服务完全依赖于某大型公有云的IaaS、PaaS以及周边的各类服务体系。

在这种情况下，非但不再需要大量的如SA、网络工程师、DBA以及应用运维这些岗位，就连技术门槛较高的分布式中间件研发岗位也会大量缩减，所以这个挑战和危机就会非常显著。

那么，我们应该如何面对这种情况呢？

从价值呈现的角度来思考我们可以做什么。至于做什么，比如持续交付以及稳定性保障体系。当然，根据业务的不同特点，可做的远不止这些。而且只需考虑跟业务自身相结合，无须考虑平台。与业务结合，就总会有比较个性和独立的地方。如何根据自己的业务特点找到跟业务相切合的价值呈现点，是我们每一个人应该去思考和探讨的。只有找到这些点，我们所做的事情和所在的岗位才会有价值和意义。

然后，再谈谈AI。这里说明一下，我们现在谈论AI，其实大部分情况下是在谈论AI的一种实现方式——机器学习算法。关于这一点，我在InfoQ做过分享（“AIOps为什么是运维发展的必然趋势？”“AI时代，我们离AIOps还有多远？”），如果感兴趣可以读一读。

AI和Ops的结合，更多还是场景驱动的。当要处理的数据量越来越多，面对的场景越来越复杂，而且会大大超出人力的认知范畴时，我们便会去寻求AI的帮助。比如BAT这样的公司，拥有几十万台服务器的规模，如果出现一个问题，怎么能够快速发现、快速定位，并最终使系统快速恢复呢？如果是几百甚至几千台服务器，靠人还是可以搞定的，但是几十万台，靠人就不可能搞定了。

所以，这个时候，就需要借助技术的能力，而机器学习算法又正好可以满足我们的诉求。

这里想特别提一点，机器学习算法的应用，是离不开场景和业务特点的，也就是说怎么用还是离不开人，离不开对业务和场景熟悉的人。从我现在了解到的情况来看，很多公司和团队针对每个场景都需要投入很大的精力去对某个特定曲线和算法进行调参优化，以确保它们的准确性，也还没有神乎其神地达到完全不靠人的无监督学习。这里并不是说算法本身不具备这个能力，而是现实场景太复杂，我们不可能用简单固化的算法来应对所有的场景。

说到这里，我想我们应该可以抓住这里面的关键点了，就是懂线上运维实际情况的人做这件事情，会更加合适。当然，这是极其理想的状态，因为机器学习算法的应用实际上是个相对复杂的过程，还是存在比较高的门槛的，不仅仅是要求一定的技术能力，还要一定的数学基础，需要对大数据产品有所了解，等等。

所以，我的建议就是要去多了解，因为未来随着技术、数据和计算能力的提升，AI是一个必然的趋势。如果一点都不了解，那么极有可能会被卡在门槛外面，这就不是转型的问题了。

• 总结

我们结合运维发展到目前的现状以及呈现出的趋势做了一些分析和建议，下面来总结一下。

新时代下，机遇和挑战并存，我们确实面临着岗位和技能的转型。我给出的建议是：

学会写代码，培养产品意识，提升技术运营意识

当然，转型这个过程也不会完全是绝对和极端的，不可能一个运维都不要，一个SA（System Administrator，系统管理员，或者叫系统运维工程师）也不要，一个网络工程师也不要。但是，我们应该看到，这些岗位会更加收敛。一方面是在岗位设置上会收敛到各大云平台厂商那里，做专职的基础和后端的服务维护；同时，随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。最重要的，这些岗位上的价值空间以及成长空间将会变得极为有限，不管我们愿不愿意承认，这都是我们不得不接受的现实。

同时，在云计算和AI时代我们面临的这些挑战和危机是可以预见的，而未来还会存在大量的不确定和预见不到的东西，这种情况下我们又应该如何应对呢？

或许，不断地学习和提升自己的技能，保持对技术发展趋势的敏锐性，及时做出调整和应对，才是唯一的办法和根本解决之道。

————

本文摘自赵成新作《进化：运维技术变革与实践探索》。