当前很多新技术本质上都在解决运维问题丨运维十年回顾

很高兴能在 QCon 10 年之际接到邀请，写一写运维行业发展的这十年，非常感谢 InfoQ 社区的邀请和信任。

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

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

• 第一，运维行业的发展，是有规律可循的，是一个逐步演进的过程。这也说明，其实我们有很多经验可以向先行者们学习。

• 第二，运维行业的发展，不是孤立的，它与业界的整个技术趋势发展是相辅相成的。这就要求，关注运维的同时，我们也要关注整个技术趋势和背景。

• 第三，运维行业真正高速地发展，真正地被重视，其实就在最近 5、6 年。运维这个行业还很年轻，仍有非常大的发展空间。

• 第四，运维行业当前的痛点，本质上更多的是企业层面的痛点，而不是运维个体的痛点。所以，要尝试自上而下的解决问题，而不是自下而上。

• 第五，未来，一定是云计算的时代，未来已来，只是分布不均。所以，云计算时代下的运维转型升级，将是一个非常明确的方向。

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

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

第一个阶段，人工作坊阶段，也就是我们遇到的所有运维问题，基本靠人工操作完成。这种情况下，系统规模不大，遇到的问题相对简单，大多集中在硬件、网络和系统层面，所以有一定操作系统或网络维护经验的人就可以搞定。

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

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

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

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

但是，再往后，运维还要负责软件的频繁发布，每周要多次，甚至是每天都会有，这是由业务特点决定的，特别是互联网类型的业务，与原来传统的每个月、甚至几个月发布一次的场景要求完全不一样了。而且随着用户体量的增加，服务器数量可能已经到了几百上千台，而且部署的业务也不尽相同，所以单纯靠脚本执行，已经完全不能满足要求。

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

所以，这就对流程和工具平台有了更大的诉求。同时，在一些 IT 化比较早的行业，如电信运营商和金融行业，由于对变更过程的严格控制，这就需要更加科学和规范的管理措施，所以会引入 ITIL 这样 IT 服务管理体系，对整个 IT 系统及其变更进行管控。

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

但是，对于一些大厂，步伐会更快一些。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 的时代，开发写完代码直接部署发布到云上，完全不用考虑服务器和资源的问题。这种场景无疑是将整个迭代周期压缩到了极致，理想状态下，让整个技术团队无需考虑运维的事情。

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

简单总结一下，我们会发现，当前非常多的新技术和新趋势的产生，从本质上都是在解决运维问题，未来也一定是这样一个趋势。

从最佳时间角度，到了这个阶段，从我个人认为，现在业界运维问题，更多的是企业层面的运维问题，而不是个体运维的问题。这一点跟开发者社区特别强调个人能力极为不同，很多运维的问题解决不了，有时候很大程度上是受限于企业体制、组织架构、文化等方面的非技术层面的因素，而不单纯是个人能力所能解决的。

所以，要解决企业的运维问题，有时是需要自上而下的推进，整个技术团队共同执行落地才可以。从运维的角度单方面发起，是不会有效果的。

智能运维或 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 这样的岗位也都是不错的选择。

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

这些年经历下来，特别是近几年，最大的感受就是变化之快，让人目不暇接。新事物、新技术、新产品、新平台层出不穷，有时不知从何下手。

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

赵成，资深 DevOps 和运维专家，现任蘑菇街平台技术总监，腾讯云 TVP，极客时间运维专栏作家，多届 ArchSummit 运维专题明星讲师和优秀出品人，SRECon19 Asia/Pacific Speaker，个人专注于云计算、SRE 和 AIOps 领域。

点个在看少个 bug