运维十年回忆：当前很多新技能的本质都是在解决运维问题

在我正式写文章之前，我仔细回顾了一下我个人经历的运维的过程，也去翻了很多其他公司公开能看到一些分享材料，也找很多业界的同事做了互换，让他们也一起回顾一下过往的经历，由于十年很长，还是有很多东西值得回味和磋商。

终极，我总结出 5 个结论，也是规律，分享给大家，期望带给各位读者和所在的企业一些思考和启示：

如果用一张图表示这 10 年运维发展的过程，下图再得当不过：

接下来，我们分过去、现在和未来三部分来分享一下我对运维发展过程及未来趋势的理解。

过去（2009-2013）：人工运维

第一个阶段，人事情坊阶段，也便是我们碰着的所有运维问题，基本靠人工操作完成。
这种情形下，系统规模不大，碰着的问题相对大略，大多集中在硬件、网络和系统层面，以是有一定操作系统或网络掩护履历的人就可以搞定。

这种场景下的运维，也便是我们常说的 SA，系统管理员，而且一样平常身兼多职，人数也不太多。

第二个阶段，脚本工具阶段，一样平常绝大多数企业都会很快从第一阶段过渡到第二阶段，由于上一阶段的大量重复繁琐的操作，完备可以转化为脚本来实现，而不是每次都去敲一堆类似的命令。

早期的 SA 紧张以各种 shell 为主，以是很多 SA 如果会 shell 编写一些批处理脚本，就会很有竞争力了。
再今后，我们大家所熟知的 Perl、Ruby、Python 等动态措辞也被广泛运用于脚本工具的实现，特殊是一些逻辑和场景相对繁芜的自动化实现。

第三个阶段，流程和工具阶段，当我们把一些繁芜的操作封装成一个个的脚本后，效率确实会提升很多，但是我们所面对的业务场景和体量也在变得更繁芜。
比如，对付运维同学，以前便是卖力安装和配置一下操作系统，如果是几十台或百台的规模，脚本批量实行完备可以搞定。

但是，再今后，运维还要卖力软件的频繁发布，每周要多次，乃至是每天都会有，这是由业务特点决定的，特殊是互联网类型的业务，与原来传统的每个月、乃至几个月发布一次的场景哀求完备不一样了。
而且随着用户体量的增加，做事器数量可能已经到了几百上千台，而且支配的业务也不尽相同，以是纯挚靠脚本实行，已经完备不能知足哀求。

这时候，就要面临更加繁芜化的场景实现，比如做一次业务支配，运维同学可能要安装做事器，做系统配置变更，安装软件包、启停进程，然后再负载均衡上配置做事等等。
这时，就须要有一个流程将一个个的脚本功能串联起来，同时还要有一些脚本实行结果校验及判断的过程。

以是，这就对流程和工具平台有了更大的诉求。
同时，在一些 IT 化比较早的行业，如电信运营商和金融行业，由于对变更过程的严格掌握，这就须要更加科学和规范的管理方法，以是会引入 ITIL 这样 IT 做事管理体系，对全体 IT 系统及其变更进行管控。

实在，第一到第三阶段，在 2009 年到 2013 年期间仍是绝大部分公司主流的运维模式。
如果能够做到工具化，或者有一些工具化平台，那该当算是比较前辈的运维模式了。

现在 （2014-2019）：自动化运维

但是，对付一些大厂，步伐会更快一些。
2013-2014 年，就已经有海内大厂进入到了第四个阶段，运维已经体系化，完备的自动化。

直到目前为止，从笔者互换和理解到的实际情形看，绝大多数企业基本都在第四阶段的培植过程中，以是我们把 2014-2019 这个阶段定义为现在。

到了这个阶段，就凸显出几个明显的特点，也是我们上面提到的个中几个规律，我们分别说一下。

第一，海内的运维行业的爆发，运维岗位真正地被重视，实在便是近 4、5 年旁边的事情，也便是 2014 开始到现在。

为什么这么讲？实在我只要关注下，运维行业有自己垂直的技能大会，类似 QCon 以及 ArchSummit 这样的顶级技能峰会，开始专门设置运维专题，基本便是在 14 年旁边开始的。
这个征象解释，运维的技能繁芜度已经上升到了一定程度，各大企业也开始意识到运维对付企业的效率、稳定和本钱有着决定性浸染，对运维的诉求和哀求也越来越高。

从这个角度讲，新兴的运维行业实在才算是刚刚起步，未来仍旧会有很大的潜力和空间。

第二，运维的发展不是伶仃的，它与全体技能趋势发展是相辅相成的。

大厂之以是在这方面会走在前列，一方面是由于业务繁芜度和体量所决定，另一方面，是由于这样的场景倒逼着全体业务和技能架构发生了很大的变革。
比如我们现在早已耳熟能详的做事化和各种分布式技能，便是在这种场景下倒逼着技能体系演进出来的。

也正是在这样新的技能体系下，运维所面临的场景繁芜度也急剧上升，原有的运维技能如操作系统掩护、系统配置、脚本编写已经完备知足不了哀求。
同时，由于软件系统繁芜度的提升，也须要运维投入更多的精力去关注业务软件架构和运用做事上。

以是，这种场景下，我们所熟知的 DevOps，SRE、PE、运用运维、技能运营这些新的名字、岗位或理念，开始如雨后春笋般浮现出来。

实在这里很多观点早在 10 多年前就已经涌现了。
比如 SRE 最早是在 2003 由 Google 提出；DevOps 理念的影子在 2007 年旁边就开始浮现出来，2009 年的 DevOpsDays 大会上正式提出了这种叫法；而像 PE 这样的角色，最早是在 Yahoo! 设置的。

这些精良的运维或者稳定性的理念，在海内兴起前，实在已经在国外被广泛实践了很多年。
究其缘故原由，还是由于国外的技能发展是超前于海内的，比如 Google 在分布式领域的“三驾马车”，直接首创了一个新的技能时期，让业界有机会充分实践分布式的技能。

这里，我想表达的一个不雅观点是，这些理念在海内真正的落地，还是由于有实际的场景驱动。
业务体量和繁芜度到了那个程度，技能体系一定会找朝着分布式的方向发展。
而配套的，一定会有 SRE、DevOps 以及 PE 这样相辅相成的体系涌现。

海内大厂有机会提前走到这一步，从绝大部分公司发展的过程看，也一定会遵照这样的规律，只是早跟晚，快跟慢的问题。
这里的决定性成分实在是业务繁芜度和体量所决定的。

目前很多企业和公司之以是能走到运维的第四阶段，实在很大程度上也是由于广泛采取分布式技能，引入了做事化和各种分布式组件，在这种情形下，业务架构越来越清晰，对应的对运维的诉求和哀求也就逐步提升了上来。

范例的技能和发展特点

从技能角度，我们关注下这 4、5 年来技能的发展，说两个最范例的：

一个是容器技能，以及以容器为核心的编排系统，现在基本因此 K8S 为标准了。

首先，Docker 的创始人 Solomon 实在是运维出身，并不是做开拓的。
当时他的想法也很大略，便是希望能够屏蔽一些跟运用无关的底层细节，Run any application,anywhere，提升支配和发布的效率。

后来一经推出，大受关注，特殊是在 14 年旁边，可谓是大红大紫，且环绕着容器的一整套生态也在逐步发展起来。
到目前为止基于容器和 K8S 的根本平台，已经成为 PaaS 体系培植的标准，如果哪项技能不适配 K8S，那基本是没有发展空间的，也基本不会被认可。

从运维的角度看，容器办理的最大的问题便是运维的问题，特殊是运维的效率问题。
从目前业界的实践来看，容器确实发挥了极大的浸染。

现在更为极致的一种理念是无做事器技能，也便是我们熟知的 Serverless，也叫函数做事器。
这种理念极致的地方在于，往后纯粹便是 NoOps 的时期，开拓写完代码直接支配发布到云上，完备不用考虑做事器和资源的问题。
这种场景无疑是将全体迭代周期压缩到了极致，空想状态下，让全体技能团队无需考虑运维的事情。

但是，实际场景下，新技能发展仍须要一定周期和周边配套体系完善。
同时，新技能能够发展完善，也须要找到适宜自己发挥的业务场景，有时新技能涌现并不是要为了完备替代早期的技能。

大略总结一下，我们会创造，当前非常多的新技能和新趋势的产生，从实质上都是在办理运维问题，未来也一定是这样一个趋势。

从最佳韶光角度，到了这个阶段，从我个人认为，现在业界运维问题，更多的是企业层面的运维问题，而不是个体运维的问题。
这一点跟开拓者社区特殊强调个人能力极为不同，很多运维的问题办理不了，有时候很大程度上是受限于企业系统编制、组织架构、文化等方面的非技能层面的成分，而不纯挚是个人能力所能办理的。

以是，要办理企业的运维问题，有时是须要自上而下的推进，全体技能团队共同实行落地才可以。
从运维的角度单方面发起，是不会有效果的。

未来（2019-Future）：智能运维和云打算

关于智能运维

智能运维或 AIOps，我之以是把它定位在未来阶段，紧张是我认为目前能在这个领域有成果的，还是集中在大厂。
对付绝大多数企业来说，特殊是中小企业，机遇仍旧未到。

从 AI 的角度，AIOps 有三个方面的充要条件：机器学习算法、打算能力如 GPU、海量数据。

从上面三个条件看，也就不难明得，为什么 AIOps 做的比较超前的都是国内外的大厂，由于有技能实力、有足够的资源和数据，最关键的是有足够繁芜和变态的业务场景以及运维场景，在倒逼着 Ops 往这个方向上走。

但是，对付一家企业来说，履行 AIOps 最主要的条件条件是数据，海量数据。
目前来说，能够具备这个条件的只有大厂，由于只有大厂有这个业务和资源体量，能够产生海量数据。

同时，对付 AIOps 来说， 还有很主要的一个条件条件，那便是高度完善的运维自动化，也便是 Ops 的部分。
自动化都没做好前，AIOps 是没有任何意义的，千万不要本末倒置。

我的理解，AI 和 Ops 要办理的还是两个层面的问题。
可以类比到人，AI 相称于人的大脑，我们手脚和躯干是实行系统，大脑卖力决策判断，手脚躯干卖力完成大脑下发的动作指令。
对应到运维上面，AI 要办理的是怎么快速创造问题和判断根因，而问题一旦找到，就须要靠我们高度完善的自动化体系去实行对应的运维操作，比如容量不足就扩容、流量过大就该当触发限流和降级等等。

末了，AIOps 的发展一定是一个长期演进的过程。
AI 是 Ops 的有力补充，进一步降落运维的事情强度和压力，但是 AIOps 一定培植在高度自动化和完善的运维体系之上的，是一个演进的过程，不会是一个跳跃性的过程，也不会产生一个完备颠覆性的 AIOps 模式，将现有的 Ops 体系替代掉。

云打算：未来已来，势不可挡

实在仔细关注下技能趋势的发展，我们会创造，现在很火的一些观点，比如 Serverless、FaaS、边缘打算、弹性打算、云原生、IoT 等，乃至是我们耳熟能详的 Docker 容器、K8S、机器学习、AI 等等，基本都跟云打算干系。
很多都是在云打算这个趋势下衍生出来的新技能，而且又由于云打算供应的根本举动步伐，相互之间又有紧密的联系。

说地严格一点，这些技能只有在云上，乃至是公有云上才会发挥浸染和代价。
分开了云打算，这些技能没有任何意义。
由于，云打算带来的最大的好处便是“按需索取”，也便是我们说的弹性，进而带来本钱上的最优化。
如果我们自己机房里还掩护着上千台设备，都是我们自己的本钱，说实话，再弹性也没多大意义，由于不办理实际的本钱问题。

再便是，到了机器学习领域，特点是周期性地须要大量 CPU 和 GPU 资源，并不是持续须要，以是如果还是延续老的思路自己采购，这个本钱就大了去了，对付一样平常企业根本不现实。
况且有时候还要考虑资源在不同区域分布的问题，比如边缘打算，一个普通企业搞一个机房还可以，但是要管理和掩护很多机房，就不太现实了。

以是不难明得，未来的技能趋势，一定是跟云打算干系的。
这个是大势，不可逆。

因此从个人发展的角度，我以为，如果想要更好的发展、更大的空间，就朝着云打算这个行业走，做跟这个行业干系的岗位。
一些岗位参考，比如，公有云平台的运维，至少在规模和体量上足够大，寻衅也足够大，还能打仗到很多新技能。
其他由云打算衍生出来的办理方案架构师、技能运营、CRE 这样的岗位也都是不错的选择。

对付企业来说，尽快拥抱云打算，将更多的精力放到自己的核心业务能力上，通过云的能力，为自身的业务带来更多可能性，或许是一个更好的选择。

写在末了

这些年经历下来，特殊是近几年，最大的感想熏染便是变革之快，让人目不暇接。
新事物、新技能、新产品、新平台层出不穷，有时不知从何下手。

面对这样充满了不愿定性的场景，运维职员，包括其他技能职员，唯一能做的便是坚持学习，拥抱变革，脚踏实地的办理问题。
对付个人要不断提升能力，对付企业要审时度势，选择好未来的技能方向，我想未来一定会更有寻衅，更有乐趣，也必将更加精彩。

更多运维精彩内容，请点击“理解更多”