2.1.3 技术

随着企业IT信息化、数字化的进程不断推进，企业对IT系统的依赖程度与日俱增。面对越来越多的IT系统，IT运维对象倍增，各种异构的IT资源的管理成为企业运维的挑战，IT运维领域的技术发展也随之发生翻天覆地的变化，如何在日常IT运维管理工作中使用新一代的运维技术成为新的命题。本节将从IT运维技术的演进出发，讲述运维模式、工具、协作、管理等的变化。

1.IT技术架构的演进

（1）IOE架构

技术架构是IT架构的地基。随着技术架构的演进，业务使用的IT资源对象也随之变化。在十年前，企业大多数仍采用IOE的传统架构，以IBM为代表的商用小型机、Oracle为代表的商用数据库、EMC为代表的高端存储设计是各个企业IT体系的标配，机房里清一色的IBM小型机，业务应用系统数据库千篇一律都是Oracle企业级数据库。回过头细想一番，为什么当时的企业都倾向于采用这种IOE架构呢？其实就当时而言，企业采用IOE是迫不得已，即使“去IOE”较早的阿里巴巴，最初的技术架构也是采用IOE。当时连分布式技术都未诞生，IOE这种国外商用产品确实比同期其他厂商的产品成熟得多，其单机稳定性和性能非常高。通常情况下，一台IBM小型机可以正常运行多年，即使不停机，也不会出现任务故障，其稳定性是保障业务服务非常核心的价值。

此外，从技术因素考虑，在当时IT系统运维模式基本还属于人肉运维的年代，系统技术栈构成的单一也便于运维团队的组建和培养。在当时，几乎每个中大型企业的运维团队都会有专门运维Oracle的技术专家，负责企业数据库的日常运维问题的处理。

随着企业的高速发展，IOE这种传统集中式系统架构达到性能瓶颈时往往只能垂直扩展，基本已无法适应业务的需求。近年来，互联网企业在技术架构上不断深入研究，为IT行业带来了全新的技术模式变革。互联网企业掀起这场轰轰烈烈的技术革命，无非出于以下几个因素的考虑。

1）成本。成本是企业不得不考虑的重要因素，一台小型机的价格相当于多台x86服务器，这对于企业的成本投入来说是非常高的。

2）灵活性。行业竞争对敏态业务的需求，要求技术架构能快速响应业务需求变更的落地，传统IOE集中式架构已难以实现。

3）扩展性。因只能垂直扩展，传统的IOE架构已无法满足激增的业务资源容量的需求。敏态业务需要更为弹性、更易于扩展的水平式扩展的云化技术架构。

4）自主可控。传统IOE厂商是闭源商用软硬件设备，无法响应企业自主可控的持续运营发展需求。在国家安全可控的一系列政策推动作用下，企业需要更为开放的技术环境或平台为其不同的业务需求生成各式各样的场景工具。

（2）互联网架构

随着技术的快速发展，新一代的云化、分布式、开源等技术架构开始进入传统企业的视线。同时，在国家政策的强有力推动下，各行各业开始意识到新一代互联网架构的重要性，纷纷开始采用新的技术进行试点改造，其中互联网行业在技术的应用上也走在前沿。互联网的技术架构特点归纳如下。

1）采用x86服务器和开源软件。基本思路都是用大量的国产x86服务器代替昂贵的IBM小型机和EMC存储，用开源的软件代替闭源的商用软件，如用开源数据库MySQL代替Oracle，节省大量采购、取得许可证以及原厂维护所带来的成本。

2）分布式。应用部署架构采用分布式集群架构分担单机的计算压力，通过分布式任务合理利用多台机器性能，使其可以匹配上单台小型机的处理能力。

3）系统稳定性。由于x86服务器在系统稳定性上比小型机差，因此在应用部署架构上通常会增加必要的冗余设计，以集群的方式提供服务，在单个设备或组件不可用的情况下，业务服务仍保持可用，避免了单点故障。

4）高度可扩展。为适应业务的高速发展、用户量的数量级倍增，在架构设计上采用横向的扩展方式，可以随时增加资源以达成更大容量、更高支撑的用户并发量。

因此，在云计算、大数据、区块链、AI、物联网等新兴技术的冲击下，企业的IT技术架构也逐渐开始一系列的变革，从传统单一的IOE架构，逐步向x86、云化架构以及开源技术方案等领域转变（见图2-4）。技术架构的快速演进必然带来运维领域的创新发展，一体化运维平台随之提上议程。

2.运维理论体系的演进

（1）ITIL

我们先来看一下ITIL的演进过程。ITIL最早是在1980提出的，但当时并没有引起人们的关注，也没有被太多人认可。2000年，ITIL发布了第二版，重点讲流程建设。2007年ITIL第三版问世，经过4年的修正和完善，于2011年推出ITIL v3 2011版本。2019年，ITIL发布第四版，并在2020—2021年间将第四版的内容逐步补充完毕，形成较为完整的ITIL框架体系。ITIL的思想随着技术的发展也经历了多个版本的变化，每个版本关注的重点也有区别。

❑ITIL v1：对IT任务进行职能化的拆解，每个部门和每个岗位有专业的分工，存在基本的工作流程，部门之间的联系较弱。

❑ITIL v2：在原有专业化分工的基础上，把流程规范化。

❑ITIL v3 2007：强调IT整体作为一个服务存在，围绕服务目录和SLA以及服务的整个生命周期开展相关工作。

❑ITIL v3 2011：与2007版本相差不多，只是把服务内容从IT服务扩展到了企业内服务，如人力资源服务、财务服务等。

❑ITIL 4：建设重心开始转向价值驱动，以价值链和价值流为中心，面向IT数字化转型。

ITIL 4的核心框架与概念包含四大维度：组织和人员、信息和技术、价值流和流程、合作伙伴与供应商。这是在原有ITIL v3的PPT（价值与流程、信息与技术、组织与人员）基础上进行了完善和升华，所有的运维活动都应兼顾这四大维度，保证运维管理在各个维度都是均衡和合理的。

基于以上四大维度，ITIL 4提出了服务价值系统（SVS），从用户的机会/需求出发，去梳理能够实现机会/需求的完整的端到端价值链，并基于价值链交付价值。价值链外部包含IT治理和实践，最外侧是指导原则和持续改进。这样解释起来可能有点抽象，简单来说就是要围绕某一个价值展开具体的IT活动，包括运维和研发活动。

（2）DevOps

DevOps是从实践中逐步总结提炼出的方法论理念，来源于敏捷开发的持续发展，是软件开发管理领域继敏捷开发之后的又一次升级。

敏捷开发方法的推广和实施，使软件交付过程中的开发和测试过程有效整合，进行快速有效的迭代交付，但在软件交付客户使用之前，或者使用过程中，还包括集成、部署、运维等环节，需要进一步优化交付效率。因此，DevOps的产生将敏捷的相关理念逐步扩展到运维侧，俗称解决软件交付“最后一公里”的问题。

DevOps的目的是通过进一步简化软件在构建、验证、部署和交付阶段的移动，扩展敏捷开发实践，同时授权跨职能团队拥有从设计到生产支持的软件应用程序的全部所有权，形成全流程一站式流水线管道。DevOps强调开发人员和运维人员（IT人员）合作，实现软件交付和基础设施变更的自动化，它旨在建立一种可以快速、频繁、可靠地构建、测试和发布软件的文化。DevOps核心词汇为合作、自动化、文化。

DevOps落地过程中需要进行相关领域的流程体系梳理，涉及的管理理念包括从DevOps核心理念中引入的敏捷管理、ITSM、精益思想等，还有基于客户现场的落地诉求，可能涉及产品管理、项目管理、需求管理、运维管理、运营管理等多维度管理体系的梳理与完善，同时还涉及客户的组织架构、人员职责等相关的调整。

因此，DevOps的导入对企业来说是一次重大的组织变革，不能从某一个部门或某一个团队开始实施，而要从企业的整体战略视角来审视DevOps转型的目标和路径，制定自顶向下的实施策略。同时，对于DevOps实施团队来说，要储备足够丰富的管理知识，也是一项不小的挑战。

3.运维模式的演进

运维部门作为企业科技部门的一部分，在信息化时代的今天，所承受的压力日益增加。传统的运维模式越来越难以适应业务和IT架构的扩张，运维团队需要寻求突破来跟上企业变化的步伐。通常来说，企业的运维管理体系分为规范化运维、自动化运维、敏捷化运维和智能化运维4个阶段，其中规范化运维到自动化运维的过渡阶段是大多数企业所在的阶段。

所谓规范化运维，指的是运维的基本要素都具备，比如操作、流程、数据等，但还比较杂乱，没有形成一定的规范。此时，可以通过引入运维PaaS平台、建设自动化场景和自动化运维流程，进入自动化运维阶段。如果企业处在规范化运维阶段，并在逐步建设自动化运维，建设周期是1～3年。

什么是自动化运维？随着近年各类运维市场活动的火热举办，自动化运维达到了前所未有的热度。自动化运维并不是炒作的概念，而是信息技术发展的必然趋势。“大数据”“容器”“DevOps”“微服务”等不断涌现的新技术大大增加了运维管理的操作单元数量，并对系统的可用性提出了更高的要求。从IBM、BMC、HP等传统厂商的各类工具产品纷纷面市，到Puppet、Ansible、SaltStack等开源解决方案风起云涌，自动化运维已经势不可挡。很多人尝试给自动化运维下定义，如“数据中心自动化”（DCA）、“开发运营一体化”（DevOps）等，始终无法形成被统一认可的概念。通过运维工具或平台，实现IT基础设施及业务应用日常任务处理和运维流程的自动化，从而提高效率和降低风险，促进运维组织的成熟和各种能力的升级。

1）日常任务处理：包括设备发现、脚本执行、操作系统安装、配置备份、配置检查、配置变更、补丁分析和分发、作业调度等。

2）运维流程：包括应用发布流程、应用部署流程、变更流程、故障处理流程、灾备切换流程、资源交付流程等。

3）能力升级：包括变化适应能力、风险应对能力、合规遵从能力、业务运营能力、事件应对能力等。

如何进入敏捷化运维阶段？当企业能够实现运维端到端的自动化、流程敏捷化、数据融合和全局度量，就可以认为该企业已经进入敏捷化运维阶段。其实，要建设敏捷化运维存在一定的难度，因为敏捷化运维不再是各个部门割裂，而是通过运维整体融合来发挥价值，所以一般来说在自动化运维的基础上要实现敏捷化运维需要3～5年。

最后，处在敏捷化运维阶段的企业各个方面条件都已经充分，只需等待AI模型和算法等各方面时机成熟后，方能进入智能化运维阶段。AIOps的前景十分广阔，但是在做到AIOps之前，我们需要做一些铺垫，包括构建端到端自动化的运维管理体系，将运营效能通过数字化的方式进行度量，最后才是运维数据体系的建设。运维数据体系的建设又包含运维数据的治理、运维平台工具的建设以及运维场景的建设。建设完成后的企业已经基本实现敏捷运维管理体系，踏入国内运维第一梯队，为向AIOps演进打下坚实的基础。