下载掌阅APP，畅读海量书库
立即打开
企业大多数围绕ITIL v3的理念建设其运维服务能力，保障业务系统的稳定性，在ITIL v3服务管理体系中强调人员、流程、产品、合作伙伴4个关键要素。另外，在国内ITSS标准体系中定义了IT服务由人员、流程、技术和资源4个要素组成，并对这些IT服务的组成要素进行标准化。对企业IT服务而言，通常情况下是由具备匹配的知识、技能和经验的人员，合理运用资源和技术，并制订相关流程，向客户提供其价值。
运维管理体系架构如图2-1所示。在企业中，运维管理体系包含以下要素。
1）现场运维和技术专家：包括一线现场运维、二线技术专家和三线原厂服务人员。
2）运维管理团队：包括应用系统运维管理人员、数据运维管理人员等。
3）统一运管平台：包括统一运维运营门户、运营可视化大屏、运维大数据平台、自动化运维平台等。
4）运维服务流程：包括ITIL的常用流程服务，如请求管理、变更管理、故障管理、问题管理、资源交付、服务目录、SLA服务、知识库、工作服务台等。
图2-1 运维管理体系架构
运维是什么？不同的人对运维有不同的认识和见解。先来看看百度百科对运维的解释：企业IT部门采用相关的方法、手段、技术、制度、流程和文档等，对IT软硬件运行环境、IT业务系统和IT运维人员进行的综合管理。可以看出，运维是一个综合性非常强的岗位，不仅需要掌握大量的运维技术与知识，还需要管理、创新等能力。对于刚进企业从事运维工作不久的人来说，对运维的认识往往较为片面，仅限于一些简单操作性工作的理解，比如应用系统出现故障时快速恢复服务、应用上线前编写变更脚本、对数据库进行性能优化等。
运维从狭义上可以理解为“运维技术与资源”，主要包含“监、管、控”，是支撑运营的质量、效率、成本的核心。以下是运维的一些能力要求。
1）运维规范的制定与执行：以TOGAF、COBIT、ITIL、ITSS、SRE、ISO2000、DevOps、敏捷、运维一体化、研运一体化等方法论为基础，结合行业监管或标准，制定内部运维管理规范，约束运维人员的操作行为。
2）监管政策要求的落实：企业需要理解、快速响应、落地监管机构的管理要求。
3）运维基本保障：运维日常工作中会有类似环境配置、监控策略配置、应用发布作业编排、资源扩容、故障处理与问题排查等保障业务稳定运行的环节。
4）运维对象的使用：运维工作人员需要熟悉IT对象的基础运维，如网络、服务器、操作系统、数据库、中间件、JVM、容器、应用等的基本使用与调优。
5）运维服务能力：在ITIL的理念指导下，运维开始面向客户、业务侧等人员以服务的形式提供其价值，并且以服务级别协议（SLA）保障服务的质量，着重服务台、业务咨询、维护、知识库等支持能力的建设。
6）业务连续性管理：基于业务连续性目标，制订业务可用性计划、应急计划、基础架构及应用系统的高可用方案、容灾架构方案、备件冗余资源计划等。
7）安全运维能力：通过对运维所有操作进行审计留痕、系统及软件漏洞的修复、网络攻击识别的预防以及数据的防泄漏等方面的工作保障信息安全。
8）故障管理能力：建设完善的事件管理流程与问题管理流程，如对事件分类进行定义、问题的排查与定位等。
9）持续交付能力：为适应敏态业务发展需求，需要快速提供基础资源、一键应用发布工具等。
10）主动优化能力：运维不但需要提供被动保障的服务，还需要辅助业务开发团队设计应用运行架构以及进行性能优化，提升客户体验等。
11）应急演练：为保障业务连续性，需要针对重大系统故障提供应急恢复能力，并根据应用等级设计其高可用架构，通过应急演练不断提升突发事件响应速度、方案完备性以及人员熟练程度等。
12）业务支撑：根据业务团队实际需求及安全合规审计，为其提供数据维护、数据提取、参数维护等服务。
13）运行分析能力：通过运维数据分析帮助业务团队制订容量计划，提升应用整体性能以及可用性水平。
14）运营能力：运维需要有辅助业务运营的能力，基于运维视角发现业务痛点并共同制定解决方案，持续提升客户及业务体验等。
15）成本控制：运维成本的投入与控制，如针对人力、硬件、带宽、软件等资源成本的评估，以及资源优化和精细化管理。
16）运维开发：运维工具体系的规划与建设，运维开发能力的培养。
不同的企业需要运维的能力有不同的扩展，甚至同一企业在不同的发展阶段，由于企业战略与业务需求的变化，对运维的核心能力要求也会变化。
随着业务规模的不断发展，企业对运维人员的要求越来越高，运维组织与岗位的划分越来越细。在传统企业中，常见的运维团队设计如下。
1）机房运维团队：负责机房和总控中心场所公共环境设施的运维管理，负责各类生产设备硬件系统的建设和运维，负责基础环境设备及系统硬件设备的维修配件、耗品的需求管理。
❑规范制定：负责建立机房环境、硬件系统运维管理流程和工作机制，组织落实相关的风险防范管理措施和技术方案，保障机房环境及硬件系统可用性、可靠性和可维护性。
❑机房规划：负责机房环境规划建设，制定相关的管理原则、方案和实施流程；负责机房容量规划、选址扩容等。
❑环境管理：负责机房基础环境系统等各类硬件设备及系统的建立、运维和管理；负责协调、配合相关部门执行机房总控中心场所的水、冷、风、电等公共环境设施的安装、运维和管理，确保相关设施的安全稳定运行。
❑设备维护：负责实施机房各类计算机设备、基础环境设备及系统各类硬件设备的扩容升级、微码升级、老化更新、故障修复、维修配件及耗品需求管理，保障机房硬件设备和环境设备的性能与容量满足信息系统安全生产要求。
❑机房安全：负责机房环境日常管理，主要包括机房环境及机房设备的监控、巡检和日常维护，配合机房门禁管理部门对进入机房的人员进行授权审核和通行管理，确保机房环境安全。
❑综合布线：负责机房综合布线系统、加密机、加速器及除网络环境外负载均衡器硬件的安装调试和日常运维。
2）网络运维团队：负责网络通信建设总体规划，负责数据中心各类平台系统环境网络接入和技术支持，负责网络管理系统建设及性能优化，负责网络系统安全防护，保障网络运营安全。
❑规范制定：负责建立企业IT网络通信系统运维管理流程和工作机制，组织落实网络通信系统风险防范管理措施和技术方案，保证企业网络通信系统的可用性、可靠性和可维护性。
❑网络规划：按照网络建设的总体架构方案，组织实施企业骨干网、企业边界接入网络、企业局域网络、企业存储网络等网络通信系统建设。
❑网络配置：负责企业各类基础网络设备、网络安全设备、网络管理工具以及网络通信线路等的实施、运维和管理。
❑网络监控：负责定制网络监控系统一体化软件版本，组织企业网络升级和运维管理，负责企业工厂网络软硬件的部署、运维和管理。
❑运行维护：负责企业IT网络通信的需求受理、技术咨询和技术支持，负责网络设备扩容升级、老化更新以及网络通信线路开通、关闭等需求并组织实施。
3）服务台团队：负责24小时全球运维值班人员的管理，组织实施生产事件的应急处置；负责服务台管理，统一受理和处理客户服务请求和故障报修；负责总控中心场所及监控系统的配置、实时监控和日常运营管理。
❑值班排班：负责建立生产系统24小时现场运维管理机制和工作流程，统筹安排各专业条线、各岗位角色的24小时运维值班人员和排班计划。
❑集中监控：负责各类生产环境和系统的24小时集中实时监控，包括机房环境、网络通信、硬件设备、系统平台、中间件、数据库、应用软件等层面的运行状态。
❑服务受理：统一受理企业内部用户服务请求和生产事件报送，提供生产监控事件、服务台受理的服务请求及问题的一线技术支持，保证生产事件和服务请求的及时有效处理。
❑事件跟踪：负责事件管理，对监控事件、服务台报送事件实施闭环管理，保证各类事件得到及时、高效、有序处理。
❑应急响应：负责生产系统紧急事件的应急响应、组织排查和恢复，负责汇总和报告事件信息等工作。
4）系统运维团队：负责资产管理，服务器选型、交付和维修，操作系统运维、漏洞补丁、故障修复等。
❑资产管理：记录和管理运维相关的基础物理信息，包括数据中心、机房机柜、网络、服务器、IP地址等各种资源信息，制定有效的管理流程，确保信息的准确性，开放接口供运维管理工具使用。
❑服务器选型、交付和维修：负责服务器选型与测试，包含服务器安装部署、部件的基础性测试、业务兼容性测试，降低整机功率，提升机架部署密度等。
❑操作系统运维：负责操作系统的选型、定制和内核优化，以及补丁的更新和版本基线制定与发布；跟进日常各类操作系统相关故障；针对不同的业务类型，提供定向的优化支持。
5）数据库运维团队：负责数据存储方案设计、数据库表结构设计、索引设计和SQL优化，对数据库进行变更、监控、备份、架构设计等工作。
❑设计评审：在产品研发初始阶段，参与设计方案评审，从DBA的角度提出数据存储方案、库表设计方案、SQL开发标准、索引设计方案等，使服务满足数据库使用的高可用、高性能要求。
❑容量规划：掌握所负责服务的数据库的容量上限，清楚地了解当前瓶颈点，当服务还未到达容量上限时，及时进行优化、分拆或扩容。
❑数据备份与灾备：制定数据备份与灾备策略，定期完成数据恢复性测试，保证数据备份的可用性和完整性。
❑数据库监控：完善数据库存活和性能监控，及时了解数据库运行状态及故障。
❑数据库安全：建设数据库账号体系，严格控制账号权限与开放范围，降低误操作和数据泄露的风险；加强离线备份数据的管理，降低数据泄露的风险。
❑数据库高可用和性能优化：对数据库单点风险和故障设计相应的切换方案，降低故障对数据库服务的影响；不断对数据库整体性能进行优化，包括新存储方案引进、硬件优化、文件系统优化、数据库优化、SQL优化等，在保证成本不增加或者少量增加的情况下，数据库可以支撑更多的业务请求。
6）应用运维团队：负责线上服务的变更、服务状态监控、服务容灾和数据备份等工作，对服务进行例行排查、故障应急处理等。
❑设计评审：在产品研发阶段，参与产品设计评审，从运维的角度提出评审意见，使服务满足运维准入的高可用要求。
❑服务管理：负责制订线上业务升级变更及回滚方案，并进行变更实施。掌握所负责的服务及服务间关联关系、服务依赖的各种资源。能够发现服务上的缺陷，及时通报并推进解决。
❑资源管理：对各服务的服务器资产进行管理，梳理服务器资源状况、数据中心分布情况、网络专线及带宽情况，能够合理使用服务器资源，根据不同服务的需求分配不同配置的服务器，确保服务器资源的充分利用。
❑例行排查：制定服务例行排查点，并不断完善。根据制定的服务排查点，对服务进行定期检查。对排查过程中发现的问题，及时进行追查，排除可能存在的隐患。
❑预案管理：确定服务所需的各项监控、系统指标的阈值或临界点，以及出现该情况后的处理预案；建立和更新服务预案文档，并根据日常故障情况不断补充完善，提高预案完备性；制定和评审各类预案，周期性进行预案演练，确保预案的可执行性。
❑数据备份：制定数据备份策略，按规范进行数据备份工作；保证数据备份的可用性完整性，定期开展数据恢复性测试。
7）运维安全团队：负责网络、系统和业务等方面的安全加固工作，进行常规的安全扫描、渗透测试以及安全事件应急处理，进行安全工具和系统研发。
❑安全制度建立：根据公司内部的具体流程，制定切实可行且行之有效的安全制度。
❑安全培训：定期向员工提供具有针对性的安全培训和考核，在全公司内建立安全负责人制度。
❑风险评估：通过黑白盒测试和检查机制，定期生成对物理网络、服务器、业务应用、用户数据等方面的总体风险评估结果。
❑安全建设：根据风险评估结果，加固最薄弱的环节，包括设计安全防线、部署安全设备、及时更新补丁、防御病毒、源代码自动扫描和业务产品安全咨询等。为了降低可能泄露数据的价值，使用加密、匿名化、混淆数据，乃至定期删除等技术手段和流程。
❑安全合规：承担安全合规的对外接口工作。
❑应急响应：建立安全报警系统，通过安全中心收集第三方发现的安全问题，组织各部门对已经发现的安全问题进行修复、影响面评估、事后安全原因追查。
8）运维管理团队：负责信息系统生产变更的集中管理和排期，负责组织实施应用系统投产前可用性测试、新项目及新功能上线、版本升级和系统下线，负责运营管理体系的持续改进。
❑规范制定：负责建立信息系统生产变更管理规范、流程和工作机制，组织落实信息系统变更管理风险防范的管理措施，组织实施生产变更的集中管理，负责变更的评估、审批、公示和后评价，确保生产变更的安全性和有效性。
❑生产调度：负责统一组织和协调企业信息化相关的各项生产活动，包括应用项目投产、系统升级、系统下线、生产维护性活动、灾备切换演练及应急演练、特殊日安排等，进行生产环境（含生产、准生产、投产演练和灾备环境）、技术资源、时间窗口等各项生产资源的调度和排期，制订总体工作计划并控制执行，确保生产任务合规、有序执行。
❑投产控制：负责组织实施应用系统投产前的可用性测试，负责应用系统上线及版本升级和系统下线的投产管理，组织和协调投产版本准入控制、投产环境准备、投产前演练等投产准备工作，组织完成投产相关工作。
❑资源协调：负责生产活动的对外沟通协调和组织调度。
建立运维组织架构非常重要的一个原则就是“专业层级原则”，即根据运维能力的分类与分级，建立不同专业职能和层级的管理团队、技术团队和服务团队。例如，银行业的综合管理部门的生产调度团队、应用运维团队、服务台团队等。
运维组织的转型离不开运维组织架构和体系的变化，康威定律在某种程度上也可以用来指导运维组织架构设计。
❑第一定律：组织沟通方式会通过系统设计表达出来。
❑第二定律：时间再多，一件事情也不可能做得完美，但总有时间做完一件事情。
❑第三定律：线型系统和线型组织架构间有潜在的异质同态特性。
❑第四定律：大的系统组织总是比小系统更倾向于分解。
下面先来看看运维技术架构的变化。
1）基于传统建设方法。通过一个运维管理门户，将众多运维系统或工具封装到这个运维管理门户中，通过统一身份认证，工具间的URL跳转来实现一体化运维的表象，但底层的数据无法打通，相应共性组件也无法复用。这只能治标不能治本。
2）基于平台化建设方法。把通用的运维能力构建在平台内部，形成各个原子能力模块，再通过SOA的架构进行封装，将运维所需的场景功能和平台的原子能力模块进行隔离。这样做的好处在于避免了烟囱式的建设方法，让运维的数据和功能得到有效的治理。
这两种运维技术架构或许可以给我们一些启示。
1）组织沟通方式会通过系统设计表达出来。第一种运维技术架构建设是一种离散式的运维组织沟通方式，每个纵向领域技术组自己进行技术选型，这样的组织方式就是传统的方式，公司有不同的运维组，如网络、操作系统、数据库、办公应用、业务应用等，但是每个组相对独立，这种模式在当前的内外部运维环境下就会遇到问题。
2）企业的运维场景往往需要跨系统、跨流程、跨组织，天然具备个性化、全流程化的特点，这也是当前对运维组织的要求。
3）没有完美，只有更好。组织的转型无法一次解决，但是与运营技术架构匹配的组织将带来更大的效能。
转型的目标离不开运维的价值呈现，运维需要从运维支撑提升到增值服务，也就是除了稳定，还要考虑能否通过自动化和标准化释放运维人员。从PaaS化运营技术架构的变化趋势来看，如果把运维组织当成技术架构来看的话，应该有一个“运维发动机式的组织”，对外输出运维解决方案，这个组织在PaaS化的技术运营体系下称为技术运营组，如图2-2所示。
图2-2 技术运营协同架构
利用输出解决方案和工具的方式，提升现有人员日常的运维工作效率，例如把日常巡检、提数、配置管理等运维操作自动化、标准化，且标准化要体现在简便的Web交互界面功能上。这样运维人员就能得到一定程度的解放，他们就可以作为运维组的“甲方”，去仔细思考自己的运维如何更稳定、更高效、更可控。
定义好统一的工具开发或场景构建的标准，并构建起流程式的赋能机制，运维逐步转向运维开发。不断提升公司一体化运营平台的能力，从烟囱式系统建设转变为平台化建设，只有这样，才能实现更为高效的数据化运营和智能运营。
采用自生长式的运营模式，授人以鱼不如授人以渔，技术运营组的人员可以为一线运维人员开发工具，或让一线运维人员利用研运一体化平台为自己制造工具，从而不断提升运维人员的水平，同时实现简单工作的自动化和重复工作的标准化。
每个发展到一定规模的企业必然有规范化的流程作为重要的管控手段，在运维领域也一样，我们会经常接触到如服务台、事件、问题、变更、发布、请求、配置、服务级别、知识管理等运维管理流程。在运维流程的建设过程中，很多国内的中大型企业都设立了流程专员专门负责流程规范体系的建设，解决流程落地的各种问题，持续优化沉淀出适合企业自身的运维管理流程。本节会从流程的定义、作用出发，帮助梳理流程与制度规范的关系、流程与服务的关系。
流程是一系列有规律的行动的组合，这些行动以相对确定有序的方式执行，能产生特定的预期结果。运维流程包括实际运维工作过程中的各个环节、步骤和程序，通过运维各团队的相互协作快速解决用户的需求和运维故障问题，更有效地保障业务服务的连续性。
当然，随着时代的快速发展，也有些人会认为运维流程已不适合当前阶段运维的需要，运维更应该强调敏捷性与端到端的快速交付能力。这里列举一些大家对运维流程常见的看法以及笔者的相关观点。
1）运维流程的确定性严重阻碍了运维技术和管理的创新，增加了不必要的事务性工作投入。对于这种观点，笔者认为过于偏激。无规矩，不成方圆。如果没有流程，同一项任务的执行，不同的人会产生不一样的结果和输出，特别是对于运维经验不足的新手，如果没有规范化的流程进行管控，往往会造成很多人为的安全事故。事故一旦发生，就需要调用大量人力物力去解决问题，严重影响业务服务的连续性以及企业信息安全。虽然流程增加了部分人力资源的投入，但同时也极大地改善了系统的稳定性，减少了风险应急资源的投入。
2）流程增加了服务的实际交付时间，极大地影响了服务交付效率。以传统的瀑布式软件开发为例，从应用系统的需求提出到开发、测试、运维和运营的链路非常长，而且中间部门墙严重，协作起来非常困难，加上一系列的流程化管控问题，造成交付效率极其低下。随着DevOps的改革，这里的问题已经得到解决，基于CI/CD流水线的梳理与建设，整合研发运维各个工具系统，将跨团队的工作任务有效地编排起来，并且结合自动化的手段辅助任务的快速执行，使用轻量级的ITSM思想简化流程审批的各个环节，从而提高研运效能，使业务敏捷性增加。
3）流程的建设往往越来越臃肿，到最后流程形同虚设。流程是需要持续维护和优化的，因此企业需要设置类似流程经理和流程专员等角色，建设“管理流程”的“流程”，定期对企业流程现状进行体系化的复盘，找出流程卡点和问题，并针对性地对流程环节进行合理的优化和改进，周而复始，持续提升流程的效能。
4）运维流程即ITIL中提到的相关实践。很多人一提到流程就会想到ITIL，认为运维流程指的是请求管理、变更管理、发布管理、事件管理以及问题管理等，但这些其实并没有包含运维的所有工作内容，在运维的各个活动过程中同样也会涉及流程管控，如值班管理、应急演练、日常巡检、运维工作复盘等。
企业的运维流程建设是非常核心的内容，结合ITIL的核心实践，梳理企业运维流程当前缺失的环节，以全局的视角进行运维流程体系的规划，完善面向客户的服务目录与服务级别，建设事件管理、问题管理、变更管理、配置管理等规范化流程，提高运维工作的合规性及有序性。某企业运维流程体系示例如图2-3所示。
流程的作用可以从运维管理体系的维度进行分析，如组织、流程、平台、场景4个要素。把运维类比成复杂的人体生态系统，组织就相当于人体内部的各个器官，每个器官承担着不同的作用，不同先天条件的器官往往决定人的能力和体力；流程可以看作遍布人体全身的血管和神经系统，管理器官之间的有效运作，同时决定人的行为反馈模式，提升或约束人的机体效能；平台可以类比为人所使用的工具，工具扩展了人的各个器官的能力，节省了人体能量的消耗；场景可以看作人的行为切面，不同阶段或身份的人有着不同的行为，这些行为由人、工具、时间、协同、环境所组成。在整个运维管理体系中，流程是运维价值创造的核心，它连接运维组织的人、财、物的各个节点，并持续沉淀组织的最佳实践，指导组织高效开展运维工作。流程是一个运维管理体系沉淀下来的资产，体现着运维组织解决现实问题的智慧。
运维流程的作用总结如下。
1）提升运维价值质量。运维流程能将运维人员经验及隐性知识显性化，建设跨部门的有序规范的运维协作模式，减少人员能力的差异性，将个人能力转变为组织能力，提升运维质量的稳定性和一致性。
图2-3 某企业运维流程体系
2）提高运维工作效率。通过运维流程的建设，将运维工作中不明确的任务内容标准化，减少非增值的活动或环节，减少不必要的劳动投入，复制过去的成功经验，并利用运维流程工具的自动化能力将员工从琐碎的重复性任务中释放出来，提高企业运维组织效能。
3）加强运维组织管理。运维流程体系的建设过程是对组织内经验驱动及运维协作过程进行抽象总结提炼，沉淀为运维组织资产，基于流程线上合规化加强组织对团队与人员的管理，明确责任与义务，加强IT资源配置管理。
4）建立成长型组织。聚焦“业务链性保障、IT服务质量、交付效率、客户体验”，持续吸收运维最佳实践并维护工作流程，形成方法和套路。
随着企业IT信息化、数字化的进程不断推进，企业对IT系统的依赖程度与日俱增。面对越来越多的IT系统，IT运维对象倍增，各种异构的IT资源的管理成为企业运维的挑战，IT运维领域的技术发展也随之发生翻天覆地的变化，如何在日常IT运维管理工作中使用新一代的运维技术成为新的命题。本节将从IT运维技术的演进出发，讲述运维模式、工具、协作、管理等的变化。
技术架构是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厂商是闭源商用软硬件设备，无法响应企业自主可控的持续运营发展需求。在国家安全可控的一系列政策推动作用下，企业需要更为开放的技术环境或平台为其不同的业务需求生成各式各样的场景工具。
随着技术的快速发展，新一代的云化、分布式、开源等技术架构开始进入传统企业的视线。同时，在国家政策的强有力推动下，各行各业开始意识到新一代互联网架构的重要性，纷纷开始采用新的技术进行试点改造，其中互联网行业在技术的应用上也走在前沿。互联网的技术架构特点归纳如下。
1）采用x86服务器和开源软件。基本思路都是用大量的国产x86服务器代替昂贵的IBM小型机和EMC存储，用开源的软件代替闭源的商用软件，如用开源数据库MySQL代替Oracle，节省大量采购、取得许可证以及原厂维护所带来的成本。
2）分布式。应用部署架构采用分布式集群架构分担单机的计算压力，通过分布式任务合理利用多台机器性能，使其可以匹配上单台小型机的处理能力。
3）系统稳定性。由于x86服务器在系统稳定性上比小型机差，因此在应用部署架构上通常会增加必要的冗余设计，以集群的方式提供服务，在单个设备或组件不可用的情况下，业务服务仍保持可用，避免了单点故障。
4）高度可扩展。为适应业务的高速发展、用户量的数量级倍增，在架构设计上采用横向的扩展方式，可以随时增加资源以达成更大容量、更高支撑的用户并发量。
因此，在云计算、大数据、区块链、AI、物联网等新兴技术的冲击下，企业的IT技术架构也逐渐开始一系列的变革，从传统单一的IOE架构，逐步向x86、云化架构以及开源技术方案等领域转变（见图2-4）。技术架构的快速演进必然带来运维领域的创新发展，一体化运维平台随之提上议程。
图2-4 IT技术演进
我们先来看一下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活动，包括运维和研发活动。
DevOps是从实践中逐步总结提炼出的方法论理念，来源于敏捷开发的持续发展，是软件开发管理领域继敏捷开发之后的又一次升级。
敏捷开发方法的推广和实施，使软件交付过程中的开发和测试过程有效整合，进行快速有效的迭代交付，但在软件交付客户使用之前，或者使用过程中，还包括集成、部署、运维等环节，需要进一步优化交付效率。因此，DevOps的产生将敏捷的相关理念逐步扩展到运维侧，俗称解决软件交付“最后一公里”的问题。
DevOps的目的是通过进一步简化软件在构建、验证、部署和交付阶段的移动，扩展敏捷开发实践，同时授权跨职能团队拥有从设计到生产支持的软件应用程序的全部所有权，形成全流程一站式流水线管道。DevOps强调开发人员和运维人员（IT人员）合作，实现软件交付和基础设施变更的自动化，它旨在建立一种可以快速、频繁、可靠地构建、测试和发布软件的文化。DevOps核心词汇为合作、自动化、文化。
DevOps落地过程中需要进行相关领域的流程体系梳理，涉及的管理理念包括从DevOps核心理念中引入的敏捷管理、ITSM、精益思想等，还有基于客户现场的落地诉求，可能涉及产品管理、项目管理、需求管理、运维管理、运营管理等多维度管理体系的梳理与完善，同时还涉及客户的组织架构、人员职责等相关的调整。
因此，DevOps的导入对企业来说是一次重大的组织变革，不能从某一个部门或某一个团队开始实施，而要从企业的整体战略视角来审视DevOps转型的目标和路径，制定自顶向下的实施策略。同时，对于DevOps实施团队来说，要储备足够丰富的管理知识，也是一项不小的挑战。
运维部门作为企业科技部门的一部分，在信息化时代的今天，所承受的压力日益增加。传统的运维模式越来越难以适应业务和IT架构的扩张，运维团队需要寻求突破来跟上企业变化的步伐。通常来说，企业的运维管理体系分为规范化运维、自动化运维、敏捷化运维和智能化运维4个阶段，其中规范化运维到自动化运维的过渡阶段是大多数企业所在的阶段。
所谓规范化运维，指的是运维的基本要素都具备，比如操作、流程、数据等，但还比较杂乱，没有形成一定的规范。此时，可以通过引入运维PaaS平台、建设自动化场景和自动化运维流程，进入自动化运维阶段。如果企业处在规范化运维阶段，并在逐步建设自动化运维，建设周期是1～3年。
什么是自动化运维？随着近年各类运维市场活动的火热举办，自动化运维达到了前所未有的热度。自动化运维并不是炒作的概念，而是信息技术发展的必然趋势。“大数据”“容器”“DevOps”“微服务”等不断涌现的新技术大大增加了运维管理的操作单元数量，并对系统的可用性提出了更高的要求。从IBM、BMC、HP等传统厂商的各类工具产品纷纷面市，到Puppet、Ansible、SaltStack等开源解决方案风起云涌，自动化运维已经势不可挡。很多人尝试给自动化运维下定义，如“数据中心自动化”（DCA）、“开发运营一体化”（DevOps）等，始终无法形成被统一认可的概念。通过运维工具或平台，实现IT基础设施及业务应用日常任务处理和运维流程的自动化，从而提高效率和降低风险，促进运维组织的成熟和各种能力的升级。
1）日常任务处理：包括设备发现、脚本执行、操作系统安装、配置备份、配置检查、配置变更、补丁分析和分发、作业调度等。
2）运维流程：包括应用发布流程、应用部署流程、变更流程、故障处理流程、灾备切换流程、资源交付流程等。
3）能力升级：包括变化适应能力、风险应对能力、合规遵从能力、业务运营能力、事件应对能力等。
如何进入敏捷化运维阶段？当企业能够实现运维端到端的自动化、流程敏捷化、数据融合和全局度量，就可以认为该企业已经进入敏捷化运维阶段。其实，要建设敏捷化运维存在一定的难度，因为敏捷化运维不再是各个部门割裂，而是通过运维整体融合来发挥价值，所以一般来说在自动化运维的基础上要实现敏捷化运维需要3～5年。
最后，处在敏捷化运维阶段的企业各个方面条件都已经充分，只需等待AI模型和算法等各方面时机成熟后，方能进入智能化运维阶段。AIOps的前景十分广阔，但是在做到AIOps之前，我们需要做一些铺垫，包括构建端到端自动化的运维管理体系，将运营效能通过数字化的方式进行度量，最后才是运维数据体系的建设。运维数据体系的建设又包含运维数据的治理、运维平台工具的建设以及运维场景的建设。建设完成后的企业已经基本实现敏捷运维管理体系，踏入国内运维第一梯队，为向AIOps演进打下坚实的基础。
资源是指提供IT服务所依存和产生的有形及无形资产。以咨询为例，咨询服务供方为满足需方的需求，提供咨询服务能力相关的知识、经验和工具等。对一般企业而言，大部分只会关注运维工具体系的建设，认为工具是释放IT运维压力的关键，但这种理解过于片面，忽略了其他资源模块对IT运维的重要性。
这里重点提一下服务台与知识库两个核心资源的建设。服务台以服务的形式面向客户以及业务团队的关键角色，针对用户提出的事件或请求进行记录，确认其优先级，并进行一线调查与诊断，协调二三线资源快速解决问题，向用户通报进展情况，保障用户的需求得到响应与解决，提升用户的满意度。搭建服务台需要考虑服务人员的招募、选拔、培训以及人员能力的提升，服务台人员能力水平是决定服务质量的关键，一方面需要制定完善的人员管理流程与规范，另一方面需要为人员提供合适的工作环境和资料，比如服务台的标准话术、满意度回访指导手册等。需要依托知识管理体系，在服务台运行过程中不断积累知识文档，持续建设IT运维知识库，提升服务台一线问题解决率和处理效能。
在ITSS（Information Technology Service Standard，信息技术服务标准）中，针对资源要素的核心特征划分为4个等级。
1）基本级：基本具备可支撑运维业务需要的资源体系，包括服务台、必要的知识库和技术工具。
2）拓展级：除了满足基本级特征，重点审查资源管理过程的规范性和信息准确性。
❑与备件库、知识库、监控工具相关的记录和信息是完整和准确的。
❑建立与服务台、备件库、知识库等资源相关的规范的管理制度。
3）协同级：除了满足拓展级特征，重点审查各类资源对业务的完整覆盖和支撑作用。
❑各种资源可完整覆盖业务种类。
❑建立较为完善的备件库。
❑监控工具、服务台、备件库、知识库等资源可以有效提升服务级别，缩短故障排除时间和提高客户满意度。
4）量化级：除了满足协同级特征，重点审查资源使用情况的量化分析和持续优化。
❑对各类资源的使用情况和业务价值进行量化分析。
❑对各类资源的配备和利用进行持续优化。