在 InfoQ 成立 15 周年之际，InfoQ 编辑部发起了“2007-2022：云、运维、架构、前端的 15 年演进史”特别策划，将和业内专家共同盘点云计算、运维、架构、前端四大技术领域的演进历史，试图从几个切面窥见 IT 技术的演进规律。本文是运维篇。

特此感谢岳上、刘毅二位老师对本文的贡献，他们的真知灼见，是本文能与大家见面的关键。

运维的工作主要是“运行”和“维护”，本质上是保证软件系统的稳定运行。

中国互联网从 20 世纪 90 年代开始形成，随后进入快速发展阶段。中国互联网的发展为我们创造出了一个科技神话，到了 2007 年，多个中国互联网企业的市值先后超过 100 亿美元，跻身全球最大互联网企业之列。随之用户和设备规模不断扩大，运维技术也不断地发生变化。从人工运维，到脚本和工具的使用，再到平台建设，运维技术体系不断完善，逐渐向自动化、智能化方向发展。

在这过程中产生的一个重要而且前后看上去相互矛盾的变化是，运维和开发人员从“分离”状态转变为“融合”状态。DevOps 于 2009 年出现，从一种实践方法论，逐渐涉及到开发和运营生命周期的各个阶段，进而演进成了一种“运维文化”。

在这 15 年里，运维人员的职责已经从操作性的维护工作，发展为需要多方面知识、具备 IT 综合能力的研发运维工作，难度相当于翻越了多个山头。

运维的进化：从人工脚本到自研平台

运维行业的发展，是与互联网的技术发展趋势相辅相成的。

互联网发展早期，线上系统规模和服务器数量不大，可以用脚本来进行部署维护工作。最初的业务运维，主要工作是做好服务器的部署和变更，及时地处理掉一些告警、排除隐患，保证整个系统的稳定运行。

2010 年左右，随着互联网行业快速发展，用户规模增大，需要维护的系统资源也有了大规模的增长，靠人工或脚本已经捉襟见肘了。早先运维的“资源”和运维的“人数”，是两条同步上升的直线，但到后来，资源可以大规模投入，运维人员却不能照样同步增加。人工运维也存在着一些风险，所以当运维的效率无法支撑业务规模化发展时，就进化到用平台去解决运维问题的主流方向上。运维平台的研发也让运维和开发从两者分离演变为互相结合，DevOps 的概念开始流行起来。

另一方面，互联网也促进了云计算的发展。到了这个阶段，管理成千上万规模的数据中心服务器，运维必须从全局的角度思考如何用平台化的手段解决问题，追求大规模场景下的效率，通过自研系统，用集中化的监控平台把云数据中心的告警等统一在一个地方管理。

安全和质量是运维最初始的职能，但云计算行业发展起来之后，运维关注的核心就变成了安全、效率、质量、成本，多个维度并重。而且云计算在成本上提出了更高的要求。云服务的成本是商业模式里面一个非常重要的因子，运维需要考虑如何用最优的成本去提供最优质的服务，并做到极致。

所有维度都要并重，还要追求极致的安全、效率和成本，那么就需要对系统有非常精细化的掌控，运维有了开发职能，对研发能力的要求也更高了。所以，在行业发展过程中，运维工作的内容不断地被丰富，职责范围越来越宽广，难度已经不是脚本时代能比拟的了。

“全能”的云数据中心运维人

这是运维最好的时代。

随着国家政策推进企业上云，云服务逐渐成为了社会的基础设施，主流云计算厂商加码建设数据中心，数据中心的运维是云服务正常运行的一大支柱。

以前的技术不能满足需求，必然倒逼着运维人不断摄取新技术并将其用到这个行业中。

首先是对自研能力的要求。“以前，在数据中心基础设施层面，我们采用属地化运营，比如一些监控、告警的操作都是由厂商提供的。随着规模扩大，效率要求提升，像腾讯的云数据中心就开始自研集中化、平台化的统一运维平台。从远端的集中监控中心到园区级，本地 ECC 监控中心，再到具体的某一个模组，独立的配电单元的监控中心，然后再到下面的采集器层面，实现软硬件上的全面自研。这在技术和模式上就有了非常大的变化，相应的在厂商层面上就很难做到。”岳上举例说道。

在此基础上，数据中心的自研平台需满足一些极致的技术指标。过去对基础设施的监控告警，从设施出现问题到捕获到告警的时间大概是在分钟级，而自研平台的时效能提升到 10 秒以下，更及时地排除可能的故障。

（现代数据中心）

一个超大规模数据中心，可能包含了上百万台服务器，面对海量的运维对象以及这些对象产生的海量数据，运维行业将大数据引入到数据中心运维里面。对于云数据中心，甚至还可以实现对基础设施做物理模型的建模，用数字孪生技术实现对基础设施的配电和暖通的图形建模，形成一个图模一体的技术框架来可视化地表征整个数据中心实时运行状况。

面对海量数据，数据中心运维人员从监控着手，用数据治理提升数据的可信度，实现数据上的“准”、告警监控性能上的“快”、系统可用性上的“稳”。基于图模一体的技术框架又可实现告警风暴的收敛，包括告警的一些降噪处理，把影响到现场运营效率的无效告警在平台层面上处理掉。

并且云数据中心运维还需要有一些跨界，比如要关注电力系统、空调系统，了解新能源储能系统的设计，同时在软件层面用到一些互联网行业的优秀方法论和技术。

“举个例子，比如有些户外空调因为喷淋，会有一个集水盘，超过一定水位它就会告警。在过去行业里面，南方的一场大雨或者北方的一场大风，就会产生相当频繁的告警，但是这些告警往往不需要特别处理，因为根据设备特性，它会自动排出并恢复。这就需要我们了解设备工况并做出合理设计。”

在有海量数据积累的情况下，云数据中心的运维还可以进一步引入 AI 方面的技术，提升运维效率、降低运营成本、强化运营安全。例如，运维可以利用故障树、知识图谱等方式快速定位故障根因，从而节省故障排查时间；可以通过将机器学习算法和设备机理模型相结合，得到最优设备运营控制策略，从而节约运营能耗；还可以应用 AI 模型对设备进行精准预测，实现设备自动化巡检，从而保障运营安全等等。

无论是大数据还是 AI 技术的使用，都说明了在云的发展过程中，运维人员随着所运维的主体的重要性增强、复杂度增强，对其要求也会持续提升。

运维实践是一个传递的过程。运维工作可以将很多基础设施工作代码化，而业务运维的层面在多年前已经是自研平台来管理，再往下还可以逐渐卷入更多层面，如 SaaS、IaaS 层，这也是 IT 运营中“anything is code”的思路体现。岳上表示，“我觉得这是必然的趋势，这个过程中，整个运维的文化的传承和发展演进是一个蛮有意思的课题。”

DevOps 的兴起

运维人要具有开发思维，研发人也要具有运维思维。

我们看到运维行业在平台化、智能化的发展过程中，越来越要求运维人员具有开发能力。但其实自运维岗位诞生之后，在很长时间里，运维团队和开发团队（DO）相互独立，犹如中间存在着一堵墙。DevOps 的出现，将开发和运维融合到了一起，DO 分离反而成为了一种反模式。但它发展得这么火，变成一个全球性的“运动”，却是连 DevOps 之父 Patrick Debois 也意料不到的。

2007 年，Patrick 的项目遇到了难题，开发和运维团队之间总是存在争论，阻碍了项目的正常开展。毕竟研发团队在引入敏捷以后讲究的是快速变更、快速迭代。但是在运维层面，追求的还是稳定性、可靠性、安全性。所以这两个组织之间自然就会有隔阂，沟通协调要浪费大量时间和精力。

后来他遇到了另一位关注同样问题的 Andrew Shafer，两人讨论出了一个解决方案：聘请“思维过程与开发人员一样的运维人员”，以一步构建和部署项目。Patrick 在 Twitter 上宣传他的想法时创建了一个名为“DevOps”的标签，意外的是，这个标签很快就成了一种主流解决方案的代名词。

DevOps 想解决的问题到底有哪些

DevOps 本身是开发和运营两个英文单词拼在一起，顾名思义是想拆掉开发和运维之间的墙，让开发运维两种文化贯通融合，让这两个团队能充分地理解对方并协作，可以认为它是一种方法论，一种“文化”。支撑这个文化的背后，是一系列的自动化整合实践，最终的目的是让所有的团队回到最初的目的上来，更快更可靠地构建测试，更高效地交付软件。

到 2015 年左右，越来越多的公司开始将这个方法论升级成一种运动，更多强调工具化、自动化。

比如在流程工具选择上，以前很多是用像 assible 这样的自动化工具来解决单个环节的问题，慢慢的运维从面向脚本、面向单点工具开始走向一站式流程工具，如 DevOps 这样的 pipeline CI/CD。这些 pipeline 也能在线上直接对接到 plan 的部分，甚至对接到知识管理部分，以及下游的面向运维的像风控响应、故障响应的系统，让 DevOps 在一种标准化接口的层面顺畅地跑起来。也就是说 DevOps 工程师还必须了解源代码管理、持续集成和软件测试自动化等流程是如何工作的。这些都是现代软件开发链的核心组成部分。

发展到今天，DevOps 已经不仅仅是简单地对过程的描述、对方法的描述，更多的是文化、实践层面的事情，甚至慢慢影响了企业的“管理”。很多大公司对它的定义都不一样，亚马逊定义它是“哲学、实务和工具”，微软定义它是“人员、流程和产品”，还有定义为“组织和文化”、“软件交付方法”的。不得不说硅谷企业很善于形而上地把其抽象成一种理念和文化。

在国内，最早拥抱 DevOps 的是互联网企业，特别是头部的互联网企业将 DevOps 的思想和理念固化为对外的商业化 DevOps 产品和服务，能利用它有效屏蔽 DevOps 实施过程中底层的复杂度。而后逐渐影响到传统的包括金融、汽车制造这样的传统行业，因为它背后避免浪费、自动化、全流程的思想给企业带来了一定的收益，同时降低了信息化转型过程中的门槛。

所以总的来说，除了强调协作和沟通，DevOps 让开发运维两个团队互相介入，变成一个融合的团队了。运维团队在项目一开始就进入了基础架构和技术路线的选择流程里，甚至可以在代码框架上、在代码选型上给出合适的高可用性、高扩展性、高维护性的运维方案，涉及到了软件开发生命周期 SDLC 的每一个环节，是一个在文化、技能、流程、工具上的综合性文化体系。

“在我们看来，DevOps 是敏捷发展的自然结果，敏捷解决了需求和开发之间的协同沟通的问题，但是到了最后一步，DevOps 在运维层面上打破了这堵墙，在最后一公里上衔接起来了。”腾讯云 DevOps 负责人刘毅表示。“DevOps 的思想也一样的，在我们谈业务降本的时候，在分析每一个不良的中间环节时，都需要去思考怎么尽可能减少浪费。”

DevOps 的天时地利人和

2010 年后技术的发展，让 DevOps 有了顺势而上的机遇。

这一时期也正是微服务兴起之时，它是更轻量的 SOA，核心解决了软件复杂度里面最重要的高类聚低耦合还有伸缩性这样的问题。然而它有利有弊，微服务带来了更高的复杂度，提高了可观察、测试和运维的难度，容器的出现为微服务提供了一个量身订作的底座。

2013 年 Docker 开源，容器编排工具 Kubernetes 也逐步获得市场认可，存储、计算、网络都通过 Kubernetes 这层进行了统一抽象和封装，让已经被容器统一的微服务能够直接运行到 Kubernetes 平台，容器的一致性、自动化非常轻便地解决了底层支持的问题。

容器化提供了支持后，DevOps 自动化的能力、成本管理能力都得到了加强。DevOps 需要对全流程有更多的观察，也需要有更多的透明性，容器技术也提供了直接的帮助。资源的伸缩、成本的控制，这些都很好地支撑了 DevOps 技术的发展。

更重要的是，容器平台以及云原生的成熟度，提升了人员和 IT 系统之间的协作性。Dev 人员渗透到 Ops 层面的时候，协作更为流畅。“所以也可以说容器和微服务极大地推动了 DevOps 技术的发展。”刘毅总结道。

容器和微服务技术加速了 DevOps 的落地，像腾讯这样的企业在两三年前也在内部大规模实践，将研发流程和使用的工具都进行了统一和收敛，构建仓库、CI/CD 流水线等都用 DevOps 来实现。而且据信通院发布的 2021 年《中国 DevOps 现状调查报告》显示，落地实践成熟度处于全面级的企业多达 35.40%。

DevOps 的大规模应用，也改变了企业的组织结构。以前 DO 分离这种结构慢慢在很多场景下变成一种“反模式”。一些组织会建设跨职能的 DevOps 团队，这种组织结构贯穿了开发运维甚至包括工具团队、架构师，还有一些工程团队、业务团队，形成一个多角色组织在一起的跨职能团队，负责人一般直接向 CTO 或者 CIO 报告，从而推进整个组织里 DevOps 文化的落地。

这些进一步给开发运维团队带来了改善。因为开发和运维有了共同目标，开发的团队也在转型，会去关注质量的左移和右移，尽早发现问题，避免问题往下游走。同时也会更多地去关注运维层面的问题，根据发生的问题去做复盘和根源分析，从而缩短问题解决时间（MTTR、MTTD），缩短所谓的 lead time，实现更快地迭代，更高频地交付。

运维团队也会参与需求分析等业务设计中，关注前期的架构设计层面的事情。这要求运维角色具有架构能力，能提供对架构进行抽象，特别应用层、API 层的架构抽象，提供更标准化的架构设计建议。因为标准化的架构设计就意味着能具有更好的更轻松的运维能力，而抽象层的建设也能更好地实现运维层面的自动化工作。这些在 DO 分离的时候很难实现，现在运维角色的人参与到早期的架构和代码过程中，能在项目早期消灭掉可能的问题。

不可忽视的 AIOps

AIOps 是一个对运维以及未来影响深远的技术方向。

这些年来，随着云计算、微服务等技术的流行，以及业务的迅速发展，运维人员要关注的运维数据（日志、监控信息、应用信息等）也呈现了指数级增长。

DevOps 在全流程的角度横向解决了一些组织协作的问题，但 Ops 这件工作本身是有其专业性的，以前的专业性讲究在人、在工具上，那么在深度上，在数据问题上，结合人工智能，就有了 AIOps。

AIOps，也就是基于算法的 IT 运维（Algorithmic IT Operations），是由 Gartner 定义的新类别。正好海量信息中有大量的需要去挖掘和观察的信号，这正是 AI 擅长的范围，那么 AIOps 就很及时地出现，通过挖掘在可观测领域曝出来的这些数据，消灭噪音，做自动化告警的聚合，最终带来更深入、更准确、更快的运维。AWS 的数据显示，他们的 AIOps 工具上线以后，很多中小企业都缩短了 80% 以上的 MTDR 实践，AIOps 带来的价值是非常明显的。

因为这种 IT 系统本身过于复杂，新员工刚接触到 Ops 的时候可能也是一头懵的：他发现原来生产环境每天有各种事情发生，有些看到的是结果，只是表面上的现象。其实各种信号到来以后，其中有一些只是小的故障信号或者一些小的隐患源头。这些大量的报警信息分散着运维人员的注意力。那么怎么把这些信号、事件和根因进行关联，怎么快速地得到因果关系，然后快速地选择最正确的响应变更路径，这就是 AI 可以帮助解决的问题，它能将运维人员从纷繁复杂的告警和噪音中解脱出来。AIOps 运维人员，可以借助它提升自己的故障预警、根因分析的能力，进而建立起提前防御的机制。

AIOps 也给运维工程师提出了更高的要求。自动化运维平台和 DevOps 的实施，需要运维人左移到架构、代码方向，现在他们更是需要提升一些更垂直的能力，比如掌握大数据、机器学习这些知识，将以前的运维经验结合运维数据，用机器学习的方法对这些数据进行归纳总结、模型评估、模型选择、参数调整进行运维决策，成为一种多领域结合的专家。

除了 DevOps、AIOps 外，其实也还有更多值得关注的，比如 DevSecOps、GitOps 还有 FinOps 等，目前国外有很多大的公司在谈这方面的理论、文化，小的公司开始做这方面的工具。“国内企业比较务实，更多的还是关注工具、一些应用的落地，去收敛一致性、重视技术架构，很少对外谈理念。但在未来的探索上，我们需要积极拥抱新技术，迎头赶上去，不要只是 follow 别人的工具和理念。”刘毅评论道。

数字化转型下的运维

当各行各业都建构在数字化技术之上，运维的重要性攀上了前所未有的高峰。

IT 运维一直是企业数字化的有力支撑，但很多传统企业的 IT 运维甚至还处在依赖人的阶段。对一些企业而言，数字化转型意味着引入新技术、流程和文化以实现共同目标。那么对于运维来说，也不再是靠人工在系统中翻找数据、然后根据自己脑子里的经验去做判别，企业 IT 运维必定也会引入自动化的平台运维。

拆开来看，就是一项项的具体工作，构建包括资产全生命周期管理、实时掌握资源使用情况、系统健康状态、实现数据可视化、实现自动化部署、自动化处置、自动化故障接管等，这给运维带来的不少挑战：

数字化是对现实场景的数字化表征，首先要做到的是对运营需求的理解，它是越来越精细化的，并且数字化一定是体现在在对数据的实时掌握的基础上，所以要求数据的采集、监控是全方位的，并且是立体的。

以基础设施为例，这就要求在告警、维修以及变更等等之间进行打通。包括现在的一些 3D 大屏、数据看板，是对整体运行情况的一些数据的呈现，也反映了数据工程师们对业务的深入理解。现在行业上也有很多的此类运维产品，也有了独立发展的空间，这也是所谓的挑战带来的新的商业上的机遇。

同时，数字化转型也要求运维工程师提高对数字精细化的敏感度。如果数据采集、计算存在一些不太准确的情况，可能会带来呈现上虚报，这其中考察的可能包括一些数据物联网的采集新技术、数据的校验、以及运维对数据业务的理解。

比方说高密度 IT 机架运行大数据和 AI 业务时会消耗大量电力，要确保关键业务的可靠运行，就必须保证机架峰值功率运行在额定容量内。如果机架采集功率数据发生异常，譬如电表精度不足、硬件故障、配置错误、通信异常等，就可能发生机架“超电”风险，此时对多维数据源进行综合分析，例如比较服务器拟合功率，就可以判断机架采集功率是否可信，从而确保 IT 业务有足够供电容量。没有可信数据，就可能倾向于保守运营，预留太多的冗余容量，如果数据可信，就可以在保证可靠的情况下充分提升电力容量利用率，不仅降低电力成本，也符合各企业碳中和的战略目标。像这种数据治理的问题，都是在数字化转型过程中需要运维工程师们特别注意的地方。

在数字化演变过程中，相应的自动化包括可靠控制要求也会更高。作为一个生产系统，它的高可用方面也会提出更高的要求，包括整个系统要做到 4 个 9、5 个 9 的高可用等等。

另外，进行数字化转型就意味着团队需要应对经常发生冲突的挑战，例如快速变更、快速迭代的研发和稳定、安全的运维之间的冲突。这恰恰也是 DevOps 的设计初衷。利用 DevOps 可以将人员、流程和技术结合在一起，同样也给企业带来了梳理企业开发全流程和改善组织协作的机遇。

DevOps 的落地，对于数字化转型中中小企业来说具有一定的复杂度，这意味着企业需要采取一些策略，例如：

一、建立学习型组织，需要团队中的每个角色都有全流程能力。

二、除了打破壁垒，还要在透明性上做强，包括对研发行为、运维行为本身的透明性，对生产环境、对系统的透明性。因为是在新的工具领域实践，如果不了解它的变化，就不知道未来的进展是好还是坏。

三、中小企业可以引入屏蔽了复杂度的研发运维一站式全平台，然后关注自己业务和平台之间的切合性，降低在技术层面、工具层面、流程层面从零开始建设的成本。

写在最后

从过去这 15 年历史来看，运维在未来有着非常好的发展前景。

运维是一个“超载”的概念。最初作为业务运维来讲，可能只需做好资源的分配，及时地处理掉告警保证整个系统的稳定运行就好了。早前运维岗位技术含量不是很高，如果提供开发或者运维两个岗位供人选择，可能大部分人会选开发岗位。

到了云原生阶段，运维开始追求大规模的效率，从全局的角度思考如何用平台化的手段解决问题，对运维的要求也在持续提升，运维又被赋予了更多研发层面、管理文化层面的含义…

“我非常看好运维发展的可能性，”岳上表示，“所谓‘超载’，就是在不同的时期，根据业务需要被赋予不同的职责和责任，那么由此来看，运维人员可以想像的空间越来越大，可以做的事情也越来越多，未来也肯定有更多可以发展的方向。”

嘉宾简介：

岳上，腾讯云数据中心总监，自动化负责人。ODCC 智能监控与管理组组长。腾讯怀来云数据中心在 2021 年信通院数据中心智能化管理评估中获评唯一 Level4 最高等级。

刘毅，腾讯云 Devops 的负责人。腾讯在 2020 年信通院 DevOps 标准评估中获评唯一卓越级。