今天我们来聊一聊，在云计算和AI时代，运维应该如何做好转型？今天的内容可以说是我们前面运维组织架构和协作模式转型的姊妹篇。针对运维转型这个话题，谈谈我的思考和建议。
我们先来看业界的三个典型案例，一个来自国外，一个来自国内，最后一个是我自己团队的案例，都非常具有代表性。
先看国外Netflix的模式。
Netflix从一开始就强调开发人员进行自助化运维。我们第一篇文章中就介绍到，Netflix内部的运维工作全部都由开发人员完成，平台也由开发自己完成，只保留极少的Core SRE角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是其电商业务，还是AWS公有云服务，全部都由开发搞定。
这样的团队因为其技术前瞻性，微服务以及分布式这样的技术架构早已落地，再加上其超强的技术能力，所以可以从一开始就这样来做。
再看国内阿里的模式。
阿里技术团队在2016年左右，也开始进行“去PE”的组织架构调整，原来需要PE完成的运维工作，全部由开发承担。原来的PE要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应调整的PE就只能离开了。之前在业务稳定性保障过程中起到核心作用的PE，随着各类工具平台的逐步完善，在高度自动化之后，最终也只能面临职业和技能上的转型。
这种模式，与Netflix正好相反，也就是一开始技术能力无法满足要求的时候，能靠人就先靠人，然后过程中不断完善各类自动化平台。
最后，再说说我自己的团队，发展过程中的模式。
我大致回顾了一下，发现从去年年初到目前，将近两年的时间里，我自己的团队也没有招聘新的应用运维人员了。并不是没有合适的人，我总结了一下主要有两个原因。
第一个原因，随着自动化逐步完善，效率不断提升，单个PE能够支持的业务变得越来越多；同时，很多事情开发都可以自助完成。
第二个原因，我有意识地招聘具备开发能力的人员，他们入职后一方面参与各类平台的开发，另一方面还要定期轮岗做一些运维工作。后来我发现，只要有效进行引导，同时具备运维和开发能力是不成问题的。
所以，结果就是，应用运维的岗位需求已经没有这么强烈了。从趋势上看，跟阿里的发展过程非常相似。不过这个过程，我从来没有刻意地设计过，基本算是顺其自然。
从上面的这几个案例来看，无论哪种情况，就运维来说，随着日常重复的人工操作被逐步自动化之后，如果还是固守原有的工作模式和思路，能做的事情、能够提供的价值，一定会越来越少。终究有一天，我们会面临和阿里PE同样的转型问题，而且这个转型是在可预见的短期内就会到来。
既然预见到了趋势，那下面我们就来谈谈应该如何面对。
如果只允许给一条建议的话，我给出的建议就是：学会写代码。
我们早期的运维岗位，基本上都不会对代码能力有很强的要求。所以对这个岗位上的同学来说，这一点就成了技能上最大的短板，也成了后续职业发展的瓶颈限制。
但是，运维行业发展到现在，无论是从趋势上看，还是从我们现在所经历的实际现状来看，单纯靠人力维护的投入越来越无效。
所以，无论是我们做运维转型也好，还是做其它技术转型也好，具备代码开发能力，已经成为一项必备技能。
这里多说一点，我们大多数做运维的同学不具备代码开发能力，并不是自身的能力问题。很多情况下都是因为不够自信，对写代码心存畏惧，担心自己写不好，所以一开始就把自己给限制住了。如果是这样，我给的建议再多也没用，关键还是要靠自己先迈出第一步。
现在我自己的团队中，有很多同事做了多年运维工作后，因为乐于尝试和挑战，很快就可以独立编程，而且因为自身有很多一线运维经历和经验，可以说即懂业务又懂开发，反而比单纯做平台和工具的运维开发更有竞争力。
下面是一些具体的建议。
在阿里的PE转型过程中，有一部分转型去做效能工具研发，有一部分经验丰富的资深运维就转型去做了技术产品和技术运营这样的运维专家角色。对于开发人员已经可以自助完成的部分一线运维工作，运维专家还会在这个过程中对开发做一些赋能。
所以，对于当前运维岗位上的同事来说，有这样一个先天优势来承担这样的职责，可以参考阿里PE转型的经验，根据自己的优势特点提前做好方向规划。
机遇与挑战并存，上面我们更多地讲了机遇，但是与此同时我们也要看到挑战，甚至是危机。
而最大的挑战和危机往往都不是来自内部，当我们还在纠结如何不被开发替代的时候，外面的技术环境已经发生了很大的变化，而这种变化带来的将是颠覆性的改变。
有两个最大的外部因素，一个是云计算，一个是火热的 AI，我们分别来看。
首先，云计算发展到今天，已经不是我们想象中的只能提供IaaS服务的云平台了，目前各大公有云上的PaaS产品体系也已经非常完善。我们前面讲的各类分布式中间件产品都有覆盖，而且这些产品，还都是各大公有云平台公司在自有业务上锤炼出来的非常优秀的产品。
简单一句话，现在我们去做一个业务，基于这些基础服务，完全无需自研纯技术产品，只要专注业务逻辑开发即可。我了解到国内某新兴的O2O，每日超过千万笔的订单量，除业务代码外，其它基础层面的服务就完全依赖于某大型公有云的IaaS、PaaS以及周边的各类服务体系。
这种情况下，非但不再需要大量的如SA、网络工程师、DBA以及应用运维这些岗位，就连技术门槛较高的分布式中间件研发岗位也会大量缩减，所以这个挑战和危机就会非常大了。
这种情况下，我们应该如何面对？其实，我在前面的文章中已经给出答案，大家可以先回顾一下，然后再往下看。
这里的答案就是，从价值呈现的角度来思考我们可以做什么。至于做什么我前面也提到过，比如持续交付以及稳定性保障体系。当然根据业务的不同特点，远不止这些内容。这些都是跟业务自身层面相结合的，与平台无关。与业务结合，就会有个性和独立的地方。如何根据自己的业务特点，找到跟业务相切合的价值呈现点，是我们每一个人应该去思考和探讨的。只有找到这些点，我们做的事情才会有价值和意义，我们所在的岗位才会有价值和意义。
然后，再谈谈AI。这里说明一下，我们现在谈到的AI，其实大部分情况是在谈论AI的一种实现方式，就是机器学习算法。关于这一点我在InfoQ分享过一篇文章，我把链接附在文末，如果你感兴趣可以读一读。
AI和Ops的结合，更多还是场景驱动的。就是我们要处理的数据量越来越多，面对的场景越来越复杂，而且会大大超出我们人力的认知范畴。比如BAT这样的公司，几十万台服务器的规模，出现一个问题，我怎么能够快速发现，快速定位，并最终快速恢复？如果是几百甚至几千台服务器，靠人还是可以搞定的，但是几十万台，靠人就不可能了。
所以，这个时候，就需要借助技术的能力，而机器学习算法又正好可以满足我们的诉求。
这里想特别提一点，机器学习算法的应用，是离不开场景和业务特点的，也就是说怎么用还是离不开人，离不开对业务和场景熟悉的人。从我现在了解到的情况来看，很多公司和团队，针对每一个场景都需要投入很大的精力去对某个特定曲线和算法进行调参优化，以确保它们的准确性，也还没有神乎其神地达到完全不靠人的无监督学习。这里面并不是说算法本身不具备这个能力，而是现实场景太复杂，我们不能用简单固化的算法来应对。
说到这里，我想我们应该可以抓住这里面的关键点了，就是懂线上运维实际情况的人做这个事情，会更加适合。当然，这是极其理想的状态，因为机器学习算法的应用还是存在比较高的门槛，不仅仅是技术层面，还要一定的数学基础，需要对大数据产品有所了解等等，是个相对复杂的过程。
所以，这里我的建议就是要多去了解，因为未来随着技术、数据和计算能力的提升，AI是一个必然的趋势。如果一点都不了解，极有可能就会被卡在门槛外面，这就不是转型的问题了。
上面我结合一些运维发展到目前的现状以及呈现出的趋势，做了一些分析和建议。最后我们总结一下。
新时代下，机遇和挑战并存，我们确实面临着岗位和技能的转型。我给出的建议是：学会写代码，培养产品意识，提升技术运营意识。
当然，转型这个过程也不会完全是绝对和极端的，以后就一定是一个运维都不要，一个SA也不要，一个网络工程师也不要。但是，我们应该看到，这些岗位会更加收敛。一个是岗位设置上会收敛到各大云平台厂商这里，做专职的基础和后端的服务维护；同时随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。最重要的，这些岗位上的价值空间以及成长空间，将会变得极为有限，不管我们愿不愿意承认，这都是我们不得不接受的现实。
同时，在云计算和AI时代我们面临的这些挑战和危机是可以预见到的，而未来还会存在大量的不确定和我们预见不到的东西，这种情况我下我们又应该如何应对呢？
或许，唯一的办法就是不断地学习和提升自己的技能，保持对技术发展趋势的敏锐性，及时做出调整和应对，才是根本的解决之道。
关于今天我们分享的主题和内容你有怎样的感想呢？你是否正在面临转型的困惑？是否已经成功转型，有什么经验？欢迎你留言与我分享讨论。
如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
拓展阅读
评论