下载掌阅APP，畅读海量书库
立即打开
在运维数字化转型的过程中，我们会面临来自组织与人员、管理与流程、技术与工具三个方面的压力与挑战。在构建数字化运维管理体系的过程中，也需要建立正确的数字化运维转型方法论与思路，具体如下。
运维数字化转型的目的是更好地契合数字化时代的业务要求，为客户和业务系统提供更加高效、快速、低成本、安全、稳定的运维保障和运营支撑。因此，运维数字化转型的目标可以定义为“构建以业务系统的保障和运营价值为导向的智能化敏捷运维管理体系”。
数字化运维最终指向的是运维工作的融合及统一管理。数字化是灵活的、流动的，这种流动性的要求势必会冲破运维中的各个孤岛，从而实现运维的一体化。反过来说，运维的一体化架构设计可以保障数据的自由流动和执行能力的跨系统调度。在运维一体化的架构中，连接和编排是两个核心要素。
由于运维本身的复杂性，通过某一个或某几个工具来覆盖整个运维工作实际上是不现实的，实现运维的一体化并不是换一个工具，而是换一种建设方式。就如同业务系统从单体到SOA（Service Oriented Architecture，面向服务的架构）再到微服务的发展，运维的一体化打破烟囱的方式是连接整合，而不是统一。而在运维领域，必定难以像业务系统一样投入大量的资源做完全的微服务改造，运维的一体化更倾向于SOA模式和微服务架构模式，通过ESB或API网关打通各个运维系统，非核心运维系统只需要提供API和数据，部分核心模块如CMDB则可进行微服务改造。
连接的方式能促进运维一体化建设。连接可以分为数据的连接和执行能力的连接两个方面。
1）数据的连接。要实现数据的连接，需要进行运维数据的治理。首先需要各个运维模块有统一的元数据，比如可以基于同一个CMDB进行数据转换，只有能够识别出同样的IT对象，数据与数据之间才可能产生连接。其次需要可以统一调用的数据资源池，将各系统的数据汇聚起来。这种数据的汇聚有两种方法：高阶的做法是统一的数据存储，这种做法技术难度大、成本高，但有利于后续运维大数据和AIOps的建设；变通的做法是查询接口的统一管理，基于API或者数据库读取的方式获取数据，一般用于报表编辑或者其他系统的集成开发，这种做法相对简易，但是不利于场景的扩展。
2）执行能力的连接。要实现执行能力的连接，就要对各运维模块的API做统一管控。通过ESB或API网关的方式对不同运维模块的核心执行能力进行统一管控，并供运维模块或其他模块消费。
运维能力治理的难点在于存量的运维系统对外暴露的能力一般不会非常完整，如果进行API开发，需要投入不少人力资源改造API。在进行运维能力治理时需要有所取舍，舍弃封闭性较强的运维系统，尽量替换成开放性高、具有良好生态的运维系统，并且在进行API开发时遵循二八原则，在资源有限的情况下只对需要经常调用的能力进行API开发，保障投入产出比。
当把各运维模块的数据和能力连接到一起之后，下一步就是基于这些丰富的素材通过编排的方式优化运维场景。编排的方式有4种：执行流程编排、报表编排、运维流程编排、运维场景编排。
1）执行流程编排。执行流程编排即针对自动化能力的编排，通过将针对操作系统的脚本、针对一体化运维平台工作的API作为执行原子，将企业内部多系统间的工作整合到一个流程模板中，实现一键自动化调度。
2）报表编排。报表编排即针对数据的可视化编排，作为运维领域的BI（Business Intelligence，商业智能），从各个运维模块或IT对象中消费数据，通过报表的方式做可视化呈现，实现运维的统计分析。
3）运维流程编排。运维流程编排即针对ITSM流程的编排，在流程引擎（可支持审批、会签、分支等基本流程需求）的基础上，还须结合执行流程编排、报表编排的功能，实现审批流、操作流、数据流的融合。
4）运维场景编排。运维场景编排是在数据治理、能力治理基础上的高阶应用，通过低代码的方式基于已整合的数据和API进行融合性运维工具的开发。执行流程编排、报表编排、运维流程编排会作为低代码开发的能力项使用。运维场景编排的低代码能力可以更快速地进行运维数字化的覆盖。虽然低代码开发降低了运维开发的门槛，但对于运维人员的技术能力也提出了新的挑战。
运维组织的建设目标为：以应用为中心的全生命周期综合支撑，构建跨职能的业务敏捷运维团队。建设的具体方式如下。
传统运维组织模式下，各个团队按照职能分为应用运维团队、系统运维团队、网络运维团队、数据库运维团队、ECC运维团队、调度运维团队等。在运维过程中，各个团队紧密合作，完成应用系统的发布、变更、故障排查等任务。由于应用系统的运维往往是一个全链条的过程，在这个过程中，各个团队的耦合度非常高，因此要完成例如一个业务系统故障的排查，需要穿透两堵墙：职能团队间的协作墙和职能团队的工具/数据墙。这就大大降低了运维管理、运维操作的效能和质量，增加了成本。因此，在新的模式下，我们需要通过各种方式尽可能降低团队间的耦合度，包括团队协作的耦合度和团队工具的耦合度，增强团队间、工具间的独立性，有利于整体运维效能提升。降低团队协作的耦合度，可以通过构建以应用为中心的跨职能团队方式实现；而降低团队工具的耦合度，可以通过构建端到端的、以应用为中心的全过程工具实现。
我们对传统职能式团队的弊病有一定了解，那么应对方式是什么呢？答案是以应用为中心构建跨职能的综合运维团队，我们称之为业务运维敏捷小组。例如将应用运维、系统运维、数据库运维、网络运维等相应团队的成员跨职能地组织成面向某些业务系统的敏捷运维小组，使用同一套运维管理工具，共同为业务系统的整体运维质量负责。这样能有效降低团队间的地盘墙、协作墙和工具墙，大大提升应用运维的协作度、工具整合度。
当职能团队构建起以应用为中心的跨职能综合运维团队后，所有基础资源的管理包括物理服务器、虚拟化、混合云、容器等，都可以由统一的资源团队管理，并为各个应用运维、业务运维团队提供服务。通过构建应用运维、业务运维和资源运维的三级运维管理体系，让应用运维更关注应用系统的运维、业务运维团队更关注业务的支撑、资源运维更关注资源的弹性供给与快速交付。通过租户化的管理，实现业务运维与资源运维间的团队协作解耦，尽可能让运维团队更多关注应用、业务系统和用户的支撑。
在传统的职能化模式下，工具是以职能团队为边界构建的，往往会造成工具间的集成与联动困难，并且不利于平台化运维模式的落地。在新的敏捷运维组织模式下，可以由资源团队承接运维平台的建设、运维以及资源的统一纳管，而业务敏捷运维小组则基于平台构建服务于业务和应用系统的端到端的运维监控管理工具，双方基于统一的平台实现资源的供给与调度。在平台模式下，对于企业已有工具或者独立的专项工具，都可以通过API网关等较为方便地集成到统一运维平台下，实现管理、数据、流程和工具等的有机融合。
运维服务管理的建设目标为：构建符合ITIL 4框架、融合式、高速IT运维服务管理体系。建设的具体方式如下。
在数字化转型趋势下，企业的所有部门都需要以用户和业务为中心，IT运维自然不能例外。传统IT管理模式下，以运维管理操作标准化和审批管控为主要目标，极少从业务系统和用户的视角来审视运维服务管理的质量和效能；在数字化模式下，单纯的管控往往无法满足快速响应业务和用户的效能目标，因此IT运维服务管理需要以为业务系统运营提供保障为价值导向，并在此指引下，实现效能与管控的并重。
传统IT运维服务管理以扁平的运维流程为主。运维流程只负责信息的录入、审批和记录，与ITOM的操作工具或系统脱节，既无法触发执行动作，又无法接收到执行反馈。不仅如此，在很多需要分析判断的运维场景中，都需要甲方运维管理员和驻场运维操作人员通过线下和线上的方式跨团队协作，比如申请调用各类监控数据、执行记录、日志等信息，有些场景会遇到运维数据无法汇聚融合的情况，典型的就是事件管理场景和变更场景。数字化时代的IT运维服务管理需要在各个管理实践（例如变更管理、事件管理、发布管理等）中，与ITOM工具的数据、记录、自动化操作等充分融合，以实现运维服务管理实践的高速流转和服务的敏捷交付。
在企业的工具自动化建设到一定阶段之后，就会发现运维服务管理是整体运维效能和质量提升的一大瓶颈。自动化工具的建设解决了工具的敏捷性与高速度的问题，但事实上，不仅工具需要敏捷性与高速度，服务管理也需要敏捷性与高速度。通过前述的基于平台的、与ITOM融合的方式构建起敏捷的ITSM体系，并最终实现高速度、高质量的服务管理交付，才能解决服务管理的敏捷性与高速度的问题。
数字化时代，无论企业内部还是外部，用户体验都是极为重要的一环。以往企业内部工具建设，特别是运维工具建设，并不太在意用户体验，这一点需要改变。用户体验差的工具，用户往往怨声载道，不愿使用，特别是当工具需要推广到运维以外的部门时，更是如此。如果用户压根不愿使用ITSM的服务台或者相关产品，敏捷服务管理是难以建立起来的。即便是IT部门内部，也需要关注用户体验，用户体验差的产品难以被持久使用，最终很可能面临被边缘化和废弃的境地。数字化时代，强调在工具中实现用户间的充分协同，强调面向用户的消费化体验，这两点是敏捷ITSM在用户中落地的重要因素。
运维工具的建设目标为：构建完备的端到端的一体化运维工具体系。建设的具体方式如下。
基于同一个平台，实现所有运维对象和资源的统一纳管，结合通用运维能力的沉淀和API网关的辅助，才能够实现ITOM工具的有机整合，进而实现所要达成的端到端的自动化运维目标。不仅如此，在同一个平台下，面向场景的SaaS工具迭代成为可能，使得运维工具能够始终匹配运维场景。
ITOM运维工具当前处于自动化阶段。自动化阶段的最终形态应该是关键运维场景的端到端自动化，也就说从运维需求的提出到运维过程的协作与审批，最后到运维操作的执行是一个完整的工具打通、流程打通、数据打通的过程。仅仅实现某个环节或步骤的自动化，无法从全局的维度实现运维管理效能的提升。
在时间的维度上，运维场景总是随着业务发展、系统变化、架构与资源的调整而发生变化，这就要求运维工具紧随运维需求的改变而改变。早期，企业往往过度依赖供应商的产品迭代和定制化开发，具有时效慢、成本高、需求匹配度差等问题。而通过一体化平台自带综合运维系统、前后端开发模块、低代码平台，结合时下流行的Python等低门槛开发语言，能够更加迅速、更低成本、更加精确地实现运维工具的迭代与扩展。
运维的未来在于智能化，这是业界的共识，但如何实现智能化运维，是存在分歧的。总体而言，智能化运维分为智能化平台、智能化场景及两者结合三种模式。
1）智能化平台：强调AI能力在平台层面的沉淀，通过对各类运维场景的定制化输出，实现场景的智能化运维。优点是一次构建，多处使用；缺点是面对不同的场景，需要调试对应的智能模型，工作量较大。
2）智能化场景：强调从场景入手，面向各个运维场景构建嵌入式的智能化能力。优点是开箱即用，调试成本低；缺点是许多与场景无关的智能化能力未沉淀到一体化平台中，存在重复造轮子的情况，并且未来扩展新的场景时，均要从零开始构建模型，不利于AI能力的复用。
3）智能化平台与智能化场景相结合：通过平台化方式沉淀通用的AI能力，并且针对常规运维场景提供开箱即用的智能化能力；针对个性化运维场景，通过平台的AI能力，运用场景数据作为输入进行调试后，实现场景的智能化运维。这种模式既为通用场景提供了开箱即用的AI能力，又实现了通用AI能力的沉淀和运用，兼顾效率与成本。
通过连接和编排构建起运维一体化的框架，在这个框架之上需要运维人员对运维数字化场景不断地进行深化和迭代，才能最终实现运维的数字化转型。针对运维数字化场景的演进，可以通过DTO模型（图2-11）进行分析：D即Data（数据）、T即Trigger（触发器）、O即Operation（操作）。这3个要素组合起来即是一个场景里的完整动作，每个要素从入门到深入可以分成3个层次。
1）个体数据：即只包含某个IT对象的数据，如某台主机的监控数据。
2）单领域数据：即包含某个领域（如监控）的数据，如IT基础架构监控数据、APM监控数据的合集。
图2-11 DTO模型
3）多领域数据：即包含多个领域的数据，如监控数据+CMDB数据，即可生成监控告警的拓扑关系，再加上知识库的数据，可得到对应的历史解决方案。
1）人工判断：即基于获得的数据，根据专家经验进行运维决策。
2）规则化：即将专家经验规则化，通过规则触发后续操作，如基于规则的转工单或自愈。
3）智能化：即基于AI算法触发后续操作，如基于AI预测的扩缩容决策。
1）人工执行：即纯手工操作，如命令行的黑屏操作。
2）部分自动化：即在执行过程的部分环节实现了自动化，如虚拟机的交付过程中调用了云平台的API做自动执行，但是交付后的软件安装为手动执行。
3）全自动化：即实现整个执行过程的全自动化。
每个场景都是由多个流程组成的，而流程由多个动作组成。当DTO这个动作在D的部分的输入不够完整时，就需要通过反复多个动作获得数据反馈，也就是整个操作流程是由多个DTO组成的。
针对运维数字化场景流程的演进，在横向上尽可能缩短DTO的流程链条，使得最初输入可以快速触达最终输出，保障场景的简洁和高效；在纵向上尽可能实现数据和技术的深化，做到将复杂的事情交给代码，减少执行过程的脑力和体力投入。
当然，在追求全量数据、智能化、全自动化的同时，也要考虑投入产出比。技术并不是越先进越好，而是价值越大越好。例如在T这个环节，像一些标准的故障处理场景，通过规则化就可以完全满足运维需求，如清理磁盘空间、应急操作时的主备切换等类似的场景就不需要使用AI技术。D和O两个要素同理，运维数字化也存在边际效益递减的情况，所以要做合适的运维数字化场景，而不要做最先进的运维数字化场景。