2007-2022：云、运维、架构、前端的15年演进史

菏泽炫佑科技

2007-2022：云、运维、架构、前端的15年演进史

在InfoQ成立15周年之际，InfoQ编辑部推出特别计划《2007-2022：云、运维、架构、前端15年演进史》，将共同与行业专家盘点云计算、运维、架构、前端四大技术领域的演进史，试图从几个方面一睹IT技术的演进历程。 本文是一篇运维文章。

谨向岳尚老师和刘毅老师对本文的贡献表示感谢。 他们的见解是本文能够与大家见面的关键。

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

中国互联网于20世纪90年代初具规模，随后进入快速发展阶段。 中国互联网的发展为我们创造了一个科技神话。 到2007年，中国多家互联网企业市值突破100亿美元，跻身全球*大互联网企业行列。 随着用户和设备规模不断扩大，运维技术不断变革。 从人工运维，到脚本和工具的使用，再到平台建设，运维技术体系不断完善，逐步向自动化、智能化方向发展。

这个过程中一个重要且看似矛盾的变化是运营和开发人员从“分离”状态转向“融合”状态。 2009年出现后，它已经从一种实用的方法论发展到开发和运营生命周期的各个阶段，进而演变为一种“运维文化”。

15年来，运维人员的职责从运维工作演变为需要多方面知识和综合IT能力的研发运维工作。 难度相当于爬很多座山。

运维演进：从手动脚本到自研平台

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

在互联网发展初期，线上系统规模和服务器数量都较小，可以使用脚本进行部署和维护。 在初期的业务运维中，主要工作是部署和更换服务器，及时处理一些告警，消除隐患，保证整个系统的稳定运行。

2010年前后，随着互联网行业的快速发展，用户数量增加，需要维护的系统资源也大规模增加。 手动或脚本支持不再足够。 早期，运维“资源”和运维“人数”是两条同步增长的直线。 但后来，当资源可以大规模投入时，运维人员的数量却无法同步增加。 人工运维也存在一定的风险，所以当运维效率无法支撑业务大规模发展时，就演变成使用平台解决运维问题的主流方向。 运维平台的发展也让运维和开发从分离演变到融合，概念开始深入人心。

另一方面，互联网也推动了云计算的发展。 现阶段，在管理数千台数据中心服务器时，运维必须从全局的角度思考如何使用平台化的方法来解决问题，在大规模场景下追求效率，并通过自研系统进行集中监控。 该平台在一处管理云数据中心警报。

安全和质量是运维*初的功能，但云计算行业发展后，运维的核心变成了安全、效率、质量、成本，多个维度并重。 而云计算在成本方面提出了更高的要求。 云服务的成本是商业模式中非常重要的因素。 运维需要考虑如何以*优的成本提供*优质的服务，做到*好。

各个维度都要同等重视，要追求极致的安全性、效率和成本，这就需要对系统进行非常精细的控制。 随着运维方面的开发职能，对研发能力的要求也更高。 因此，在行业发展过程中，运维工作的内容不断丰富，职责范围也越来越广，难度也不再与脚本时代相比。

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

这是运维*好的时代。

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

以往的技术无法满足需求，这必然迫使运维人员不断吸收新技术并将其应用到这个行业中。

首先是自研能力的要求。 “过去，在数据中心基础设施层面，我们采取的是本地化运营，比如一些监控、报警等业务都是由厂商提供。随着规模的扩大和效率要求的提高，腾讯云数据中心开始进行自研和运营。”统一、平台化的运维平台，从远程集中监控中心，到园区级、本地ECC监控中心，再到具体模块、独立配电单元的监控中心，再到接下来在设备层面，我们将实现软硬件的全面自研，这会带来技术和模式上非常大的变化，相应地在厂商层面将很难实现。” 岳尚举了一个例子。

在此基础上，数据中心自研平台需要满足一些极限的技术指标。 过去，对于基础设施监控和报警，从设施出现问题到捕获警报的时间约为几分钟。 而自研平台的时效性可以提升到10秒以内，可以更及时地排除可能出现的故障。

（现代数据中心）

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

面对海量数据，数据中心运维人员从监控入手，利用数据治理提高数据可信度，实现数据“准”、报警监控性能“快”、系统可用性“稳”。 基于图形与模型一体化的技术框架还可以实现报警风暴的汇聚，包括对报警的一些降噪处理，以及在平台层面处理影响现场运行效率的无效报警。

此外，云数据中心运维还需要一些跨界操作，比如关注电力系统和空调系统，了解新能源存储系统的设计，利用互联网行业的一些优秀方法论和技术等。软件级别。

“比如，有的空调室外机会因喷淋而带有集水盘，当水位超过一定水位时就会报警。以往行业，南方下大雨，北方刮大风，就会报警。”引起相当频繁的报警，但这些报警往往不需要特殊处理，因为它们会根据设备的特性自动解除和恢复。这需要我们了解设备的工况并进行合理的设计。”

随着海量数据的积累，云数据中心的运维可以进一步引入AI技术，提高运维效率、降低运营成本、加强运营安全。 例如，运维可以利用故障树、知识图谱等方法快速定位故障根源，从而节省故障排除时间； 通过机器学习算法与设备机理模型相结合，可以得到*优的设备运行控制策略，从而节省运行能源。 消耗; 人工智能模型还可用于准确预测设备、实现自动化设备巡检、确保运行安全等。

无论是大数据还是人工智能技术的运用，都表明在云的发展过程中，随着其运维主体的重要性和复杂性的增加，对运维人员的要求也会不断提高。

运维实践是一个传递的过程。 运维工作可以编码很多基础设施的工作，而且业务运维层面很多年前就已经通过自研的平台进行管理，再往下可以逐渐涉及到更多的层，比如SaaS、IaaS层，这也是IT运行中“就是代码”的思想的体现。 尚悦表示，“我觉得这是一个必然的趋势，在这个过程中，整个运维文化的传承和发展是一个非常有趣的话题。”

的上升

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

我们看到，在运维行业平台化、智能化发展的过程中，越来越要求运维人员具备开发能力。 但事实上，自从运维岗位诞生以来，很长一段时间，运维团队和开发团队（DO）一直是相互独立的，仿佛中间有一堵墙。 开发运维一体化的出现，DO分离已经成为一种反模式。 但它发展到如此之大，变成了一场全球性的“运动”，这是连我父亲都始料未及的。

2007年，该项目遇到了困难。 开发和运维团队之间一直存在纠纷，阻碍了项目的正常发展。 毕竟，引入敏捷之后，研发团队专注于快速变化、快速迭代。 但在运维层面，追求的是稳定性、可靠性、安全性。 因此，两个组织之间自然会存在隔阂，沟通协调会浪费大量的时间和精力。

后来他遇到了正在研究同样问题的其他人，两人讨论了一种解决方案：雇用“与开发人员具有相同思维过程的运维人员”来一步构建和部署项目。 在互联网上推广他的想法时，他创建了一个名为 的标签，令人惊讶的是，该标签很快就成为主流解决方案的代名词。

您想解决哪些问题？

它是开发和运营两个英文单词的组合。 顾名思义，它想要推倒开发和运维之间的墙，让开发和运维两种文化融为一体、融为一体，让两个团队能够充分相互理解、协作。 它可以被认为是一种方法论、一种“文化”。 这种文化的背后是一系列自动化集成实践。 *终目标是让所有团队回归*初的目标，更快更可靠地构建测试，更高效地交付软件。

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

比如在流程工具选择方面，很多这样的自动化工具都是用来解决单一环节的问题。 慢慢地，运维从面向脚本、面向单点工具转向了CI/CD等一站式流程工具。 。 这些也可以直接在线连接到计划部分，甚至知识管理部分，以及下游的风控响应、故障响应等面向运维的系统，使其能够在平台层面上流畅运行。标准化接口。 这意味着工程师还必须了解源代码管理、持续集成和软件测试自动化等流程是如何工作的。 这些是现代软件开发链的核心组成部分。

如今，它已不仅仅是简单的流程和方法描述，更是文化和实践的问题，甚至逐渐影响到企业的“管理”。 许多大公司对它的定义不同。 亚马逊将其定义为“哲学、实践和工具”，微软将其定义为“人、流程和产品”，也将其定义为“组织和文化”以及“软件交付方法”。 不得不说，硅谷公司非常善于将其形而上地抽象为一种概念和文化。

在中国，互联网企业*先拥抱它，尤其是领先的互联网企业，将自己的想法和理念固化为外部的商业产品和服务，并能够有效屏蔽实施过程中底层的复杂性。 随后逐渐影响到金融、汽车制造等传统行业，因为其背后避免浪费、自动化、完成流程的理念给企业带来了一定的好处，同时也降低了信息化转型过程中的门槛。

所以总的来说，除了强调协作和沟通之外，让开发和运维两个团队互相介入，成为一个一体化的团队。 运维团队在项目之初就进入基础设施和技术路线的选型过程，甚至可以在代码框架和代码选型上提供合适的高可用、高扩展、高维护的运维解决方案。 SDLC涉及软件开发生命周期的各个方面，是文化、技能、流程、工具等方面的综合文化体系。

“我们认为，这是敏捷开发的自然结果。 敏捷解决的是需求和开发的协同沟通问题，但*后一步是在运维层面打破这堵墙，在*后一公里打通。 ”腾讯云负责人刘毅表示。 “思路是一样的，当我们谈到降低企业成本时，在分析每一个不好的中间环节时，我们需要思考如何尽可能地减少浪费。”

对的时间、地点和人物

2010年后技术的发展提供了跟风的机会。

这一时期也是微服务兴起的时期。 它是一个更轻量级的SOA，其核心解决了软件复杂性中*重要的问题：高集群、低耦合、可扩展性。 然而，它有优点也有缺点。 微服务带来了更高的复杂性，增加了可观测、测试和运维的难度。 容器的出现为微服务提供了量身定制的基础。

容器编排工具于2013年开源，逐渐获得市场认可。 存储、计算、网络都通过这一层进行统一抽象和封装，让容器统一的微服务可以直接运行在平台上。 容器的一致性和自动化程度非常高。 轻松解决底层支撑问题。

容器化提供支撑后，自动化能力和成本管理能力都得到了加强。 整个过程需要更多的观察和更多的透明度。 容器技术也提供了直接的帮助。 资源扩张和成本控制都支持技术的发展。

更重要的是，容器平台和云原生的成熟改善了人与IT系统之间的协作。 当Dev人员渗透到Ops层面时，协作变得更加顺畅。 “所以可以说容器和微服务极大地推动了技术的发展。” 刘毅总结道。

容器和微服务技术的实施加速。 像腾讯这样的公司也在两三年前进行了大规模的内部实践，统一和融合所使用的研发流程和工具，构建用于实施的仓库、CI/CD管道等。 而根据信息通信研究院发布的2021年《中国现状调查报告》，多达35.40%的企业处于实施成熟度综合水平。

大规模应用也改变了企业的组织结构。 之前的DO分离结构在很多场景下已经慢慢成为“反模式”。 一些组织将建立跨职能团队。 这种组织结构贯穿开发和运营，甚至还包括工具团队、架构师以及部分工程团队和业务团队，形成一个多角色组织的跨职能团队。 负责人一般直接向CTO或CIO汇报，推动文化在整个组织的落地。

这些进一步为团队带来改进。 因为开发和运维有共同的目标，所以开发团队也在转型，会注重质量左右移，尽早发现问题，防止问题向下游蔓延。 同时，我们会更加关注运维层面的问题，根据发生的问题进行回顾和根本原因分析，从而缩短问题解决时间（MTTR，MTTD），缩短所谓的交货时间，并实现更快的迭代和更高的交付频率。

运维团队也会参与需求分析等业务设计，关注前期的架构设计。 这就要求运维角色具有架构能力，能够提供架构抽象，特别是应用层和API层架构抽象，并提供更加标准化的架构设计建议。 因为标准化的架构设计意味着更好、更简单的运维能力，而抽象层的构建也能更好地实现运维层面的自动化。 当DO分离时，这些都很难实现。 现在运维角色的人参与早期的架构和编码过程，并且可以在项目的早期阶段消除可能出现的问题。

AIOps 不容忽视

AIOps是一个对运营和未来影响深远的技术方向。

近年来，随着云计算、微服务等技术的普及，以及业务的快速发展，运维人员需要支付的运维数据（日志、监控信息、应用信息等）关注度也呈指数级增长。

从整个流程来看，横向解决了一些组织协作问题，但Ops的工作本身有其专业性。 过去专业专注于人和工具，所以从深度来说，数据问题，结合人工智能，就有AIOps。

AIOps，或基于算法的 IT 运营 (IT)，是由 定义的一个新类别。 恰巧海量信息中有很多信号需要挖掘和观察。 这就是AI擅长的范围。 那么AIOps就适时出现了。 通过挖掘可观察领域中暴露的数据，它消除了噪音并提供自动警报。 聚合*终带来更深入、更准确、更快速的运维。 AWS数据显示，在AIOps工具上线后，许多中小企业的MTDR实践缩短了80%以上。 AIOps带来的价值是非常明显的。

因为这种IT系统本身过于复杂，新员工刚接触Ops时可能会感到困惑：他们发现生产环境每天都在发生各种各样的事情，有的看到的是结果，但只是表面现象。 事实上，各种信号到来后，有的只是小故障信号，或者是小隐患的来源。 这些大量的报警信息分散了运维人员的注意力。 那么如何将这些信号、事件和根本原因关联起来，如何快速获取因果关系，进而快速选择*正确的应对路径来改变呢？ 这就是AI可以帮助解决的问题。 可以将运维人员从纷繁复杂的问题中分离出来。 摆脱警报和噪音。 AIOps运维人员可以利用它来提高故障预警和根因分析能力，进而建立早期防御机制。

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

除了AIOps之外，其实还有更多值得关注的东西，比如等等。目前国外很多大公司都在谈论这方面的理论和文化，小公司也开始做这方面的工具。 “国内公司比较务实，他们更注重工具和一些应用的实现，要收敛一致性，注重技术架构。他们很少向外界谈论想法。但在未来的探索中，我们需要积极拥抱新技术并迎头赶上。不要只是成为别人的工具和想法。” 刘毅评价道。

数字化转型下的运维

当各行各业都建立在数字技术之上时，运维的重要性达到了前所未有的巅峰。

IT运维一直是企业数字化的有力支撑，但很多传统企业的IT运维还处于依靠人的阶段。 对于一些企业来说，数字化转型意味着引入新技术、流程和文化来实现共同目标。 那么对于运维来说，不再需要手动去系统中查找数据，然后根据自己头脑中的经验做出判断。 企业IT运维肯定也会引入自动化平台运维。

拆开来看，它是一件具体的作品。 建设包括资产生命周期管理、实时了解资源使用情况、系统健康状态、数据可视化、自动化部署、自动化处置、自动化故障接管等，为运营带来巨大效益。 维度带来了许多挑战：

数字化是现实生活场景的数字化表示。 首先要做的是了解运营需求，运营需求越来越精细，数字化必须在实时掌握数据的基础上体现，所以需要数据。 采集监控全方位、立体化。

以基础设施为例，这需要报警、维护、变更等之间进行通信。包括现在的一些3D大屏和数据看板，它们呈现了整体运行情况的一些数据自动化软件开发，也体现了数据工程师的深入理解的业务。 现在行业内这样的运维产品很多，有自主开发的空间。 这也是所谓挑战带来的新商机。

同时，数字化转型也要求运维工程师提高对数字化精细化的敏感度。 如果数据收集和计算存在一些不准确的地方，就可能导致虚假报告。 考核的可能包括物联网的一些新的数据采集技术、数据验证、运维对数据服务的理解等。

例如，高密度IT机架在运行大数据和人工智能服务时会消耗大量电力。 为保证关键业务的可靠运行，必须保证机架峰值功率在额定容量内运行。 如果机架采集的电量数据出现异常，如电表精度不够、硬件故障、配置错误、通讯异常等，则可能会出现机架“超功率”的风险。 这时候就要对多维度的数据源进行综合分析，比如对比服务器配件等。 电源，可以判断机架采集的电力是否值得信赖，从而保证IT业务有足够的供电能力。 如果没有可靠的数据，您可能会倾向于保守操作并保留过多的冗余容量。 如果数据可信，就可以在保证可靠性的同时充分提高电力容量利用率，不仅降低了电力成本，而且满足了各类企业的需求。 碳中和的战略目标。 诸如此类的数据治理问题需要运维工程师在数字化转型过程中特别关注。

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

此外，进行数字化转型意味着团队需要应对经常发生冲突的挑战，例如快速变化、研发快速迭代与稳定、安全运营之间的冲突。 这也正是设计的初衷。 利用可以将人、流程和技术结合起来，也为企业提供了梳理整个企业发展流程、提高组织协作的机会。

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

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

2、除了打破壁垒，还要加强透明度2007-2022：云、运维、架构、前端的15年演进史，包括研发活动的透明度、运维活动本身的透明度、生产环境的透明度、系统的透明度。 因为我们正在实践一个新的工具领域，如果不了解它的变化，我们就不知道未来的进步是好是坏。

3、中小企业可以引入屏蔽复杂性的一站式研发、运维全平台，然后专注于自身业务与平台的兼容性，降低从头开始搭建的成本技术层面、工具层面、流程层面。

写在*后

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

运维是一个“超载”的概念。 *初，在业务运维方面，可能只需要及时分配资源、处理告警即可保证整个系统的稳定运行。 早期，运维岗位的技术含量不是很高。 如果给人们两个职位可供选择，开发或运维，大多数人可能会选择开发职位。

在云原生阶段，运维开始追求大规模效率，思考如何用平台化的方法从全局的角度解决问题。 对运维的要求也不断提高，运维被赋予了更多的研发和管理层面。 文化影响...

"I am very about the of the of and ," said Yue Shang. "The so- '' means that at times, and are to needs. From this point of view, and can The space is and , there are more and more that can be done, and there will be more for in the .”

嘉宾简介：

Yue Shang, of Cloud Data and Head of . of the ODCC and Group. Cloud Data the only in the 2021 of and data .

Liu Yi, head of Cloud. was the only level in the 2020 of and .

IE is "dead", the end of an era

Why is the Scrum agile not among big ?

How we in 2022?

Baidu born after 1995 were with their and were for the 's ; the non- in the ; the team and a wave of ｜Q News

Today, as the for live , how the such as and lags to a good user ?

Why is live not now?

What are the in the live in the ?

Scan the QR code on the to the 's first "Ultra-Low Live White Paper" and grasp the next trend!

Click to see less bugs

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等