应用运维的发展趋势和发展建议

上两篇SRE文章写完后，是计划写一篇应用运维发展趋势和发展建议的文章，前两天阿里的毕玄大神分享了一篇《阿里应用运维体系的变迁》的文章，讲述了阿里整个应用运维发展的过程，所以正好借着毕玄大神的文章再写一下个人的理解好了。

几个共鸣点

其实，大言不惭的说一句，我的理解和判断跟大神的思路基本一致（英雄所见略同^_^）。有几个点：

• 阿里前面所经历的那段过程，我想正是今天我们很多公司还正在经历的，事务发展的规律就是如此，就如同小孩子长大成人，必然要经历从爬到走，再到跑的过程，中间还要摔无数的跟头才能发展到下一步。而发展到后面，我们能够预见到的运维模式，就是Google定义的SRE，也是DevOps的非常成功的实践模式。
• 运维的发展基本都是从人工—脚本—工具—DevOps—智能化这样一个阶段，现在做的超前一点的公司基本都能够在DevOps这样一个阶段。而智能化需要DevOps的高度发展（自动化的保障）、运维所积累的数据足够多（分析的基础），标准规则足够规范（判断规则清晰）、技术过硬（机器学习等前沿技术引入），这个阶段可能确实还需要一定的发展过程。
• 当前应用运维的同学势必面临着转型，从传统型运维转向Google SRE型的运维，这个实际是业务和技术高速发展的今天，随着基础环境（云计算、IAAS、PAAS）和运维DevOps方法论越来完善，带来的对技术能力的必然的更高要求。

所以，阿里（腾讯、百度）是我们很好的学习典范，没有必要再去搞什么创新的东西出来，虚心借鉴经验，少走弯路、少栽跟头，踏踏实实解决我们自己的问题就是最大的创新。

发展趋势的判断

这里想特别提到的一点是阿里应用运维PE的组织架构和运作模式的变化，组织架构上PE已经全部打散，划归到了各个业务软件开发团队，真正的跟开发同学坐到了一起，且随着阿里整个运维自动化体系的高度发达，现在很多的线上操作，开发同学实际都可以可以自助完成的，所以现在很多的运维工作都已经是以开发同学为主，高效自主地完成，而不再是依赖PE这个角色。而PE已经开始转型向自动化运维开发和产品解决方案的角色发展，要求学习开发、要求对业务和业务架构有更深入的理解，更多地从所负责的业务的角度，去做一些个性化地效率提升和稳定性提升的事情，可以看到实际就是朝着Google定义的SRE的方向在发展，国外FB、Linkedin等基本都是这个模式。这其实还是技术团队对PE有了更高的要求和期望，PE不得不转型，不得不提升。

技能储备和转型上的一些个人建议

从阿里应用运维的发展趋势上看，Google的SRE模式一定是未来运维发展和转型的方向，大势所趋。所以，现在我们既然看到了趋势，就得提前做出预判和做一些技能方面的准备了，我个人对于应用运维在技能上一个建议就是学习代码开发，一定要去突破自己，可以从Python、Go、Ruby、PHP上手比较简单的语言开始，尝试去做一个简单的CMDB、应用配置管理、持续集成与发布等等。要想提升的话，可以尝试去写点更复杂的东西，比如具备并发处理能力的Agent、RPC框架、服务发现功能等等，这就要求对多线程、高并发等等有一定的要求，可以通过Go或者Java来做等等，再往前提升，可以去了解一下机器学习相关的知识，比如TensorFlow等。重要的一点，从运维的实际业务场景入手学习。这篇只是提建议，所以不讲具体技术细节了。

当然我在《我所理解的SRE、PE和应用运维（下）》的文章中提到的标准规范制定和执行等等能力，也很重要，这些是软实力，但是代码能力就是硬实力，要想有更广阔的发展就得软硬结合，刚柔并济。

这里还想表达的一个观点是，做运维别总是抱怨自己多么苦逼、多么不容易，还总是背锅啥的，记住，最重要的是把自己的能力提升上来，能力不够就别再浪费时间在那里抱怨这个抱怨那个了，没有意义。

对于SA和网络工程师，我觉得也是一样的思路，单看当前技术趋势，SDN、安全、内核相关的人才需求是非常紧缺的，而且这块跟业务的结合越来越紧密。比如SDN，其实简单来说就是因为业务上对网络层面的策略控制越来越多样性，为了能更加灵活的设定和管理网络策略，引入了这种可编程的新型网络架构。SDN核心的能力就是可编程。我之前跟一个SDN的厂商在沟通SDN落地的一些解决方案，厂商给我的非常中肯的意见是，“SDN要落地，我们可以提供设备，提供方案，但是最终运作起来是需要你有SDN的专业开发人员才可以的，否则后续更为零落的应用是玩不起来的。”所以，你看代码能力确实是必须具备硬实力。

我想代码能力一定是未来运维转型和发展的一个分水岭，具不具备代码开发能力，将决定着个人发展的空间和市场议价能力，各位做运维的同学不要再纠结和犹豫了，动手做起来吧。