序言

“数字化转型”这个话题可谓是老生常谈了，2021 年我国颁布了《“十四五”规划纲要》，将“数字化转型”定为国家产业发展的重要方向。

在这样的背景下，数字化转型自然引起了公众的关注，似乎大家经常可以听到一些人把它挂在嘴边，但如果此时你问他们到底什么是数字化转型的，得到的答案大概率会是大数据、云计算、区块链、物联网和人工智能之类的。其实，这些答案本身并没有问题，但它们仅仅是数字化转型的技术代表。从严格意义上说，数字化转型并没有一个清晰明确的内容大纲。

笔者认为，数字化转型的核心，并非是单纯的堆砌新技术，而是将业务和技术深度融合。为了能够实现这一目标，我们就离不开各种技术的支撑，这个时候，数字化 IT 就应运而生。讲到这里，回答其实已经有了，数字化 IT 和传统 IT 最大的区别就是前者是以“业务”为导向，归根结底，是以“人”为导向。

双态 IT

随着信息技术的深入应用，企业业务模式从以线下为主转变为以线上为主，业务产品创新频率提升、创新周期缩短、同业竞争加剧，而不少企业的 IT 组织效能却尚未能提升到满足业务敏捷交付的水平，具体表现为：

• 工具割裂与缺失；

• 规范执行不到位；

• 管理成本居高不下；

• 问题信息反馈滞后等。

2014 年，Gartner 提出了“双模 IT”的概念，实现传统研运模式和敏捷研运模式的融合，在此基础上，国内企业通过结合自身市场情况，提出了“双态 IT”这一相近的理念，即稳态+敏态，稳态以业务稳定性为核心，敏态以快速响应市场变化为核心，这一理念率先得到了互联网、金融等领域的认可，并逐步变成大众概念。

研发域

天才第一步：敏捷开发转型

为了实现应用的快速开发、交付和迭代，敏捷开发（Agile）就此诞生，其中，Scrum 方法论最为大家所熟知，而以敏捷开发为基础的 DevOps（Development 和 Operations），则是进一步整合了研发团队和运维团队，通过组织、流程和工具，以及自动化“软件交付”和“架构变更”的流程，使得编译构建、测试、发布软件能够更加地敏捷、频繁和可靠。

一站式 DevOps 建设方法可以用“四纵四横”来概括，横向主要涵盖端到端工具集成、信息资产流转共享、流程融入工程平台、能效显示与精益改进几个方面的建设；纵向主要指从需求、开发、测试到运维各端工艺的平台支持与规则设定，以及资源间复杂的拓扑关系构建。

DevOps 的建设可以按照五个阶段去开展：

第一阶段：

前后延展，打通研发工具链，将生产力的全面贯通，实现工程能力的自动化，提高工程人员整体效率；

第二阶段：

融合对接管理流程与工程流程，使得信息尽可能以线上化的形式自动流转，同时保持信息一致性和合规性，便于可信追溯和安全审计；

第三阶段：

各端标准化，从需求、开发、测试、运维等环节，形成资产工艺标准化支撑；

第四阶段：

标准化后，各端要形成资产关联，智能分析与推送，并可通过聚合服务下变更影响分析，形成可复用的资产库；

第五阶段：

面向下一代数字化构想，价值驱动业务，构建 IT 内部数字化全流程贯通。

更上一层楼：从 DevOps 到 BizDevOps

DevOps 为 IT 组织带来了效能提升，实现了其内部从开发测试到运维的流程、组织和工具的重构，并实现 IT 从“稳态”到“敏态”的转型，提升了 IT 组织应对市场和业务变化的能力。但正如我们之前所说，企业的商业价值需要更多由业务数据来驱动，前端的业务决策、业务调整和执行，都需要和 IT 实现以及 IT 运营数据形成更紧密的闭环。

为了更好的达成这一目标，需要 IT 组织和业务部门更加深度的融合，从 DevOps 向业务端进行扩展，引入业务部门的角色，甚至是产品的最终用户，允许这些角色在最初期进行参与，更有效地统一业务需求和 IT 实现，在敏捷的基础上更好实现方向的正确性；另一方面，在敏捷化的环境下，业务需求、IT 应用的变更往往是细粒度而频繁发生的，通过业务部门在全流程的参与可以更有效的从业务整体视角进行全局管控及决策。

运维域

传统运维之痛：运维是块砖，哪用往哪搬

IT 运维管理即 ITOM（IT Operation Management），是指采用专业的信息技术和方法，对软硬件环境、网络、应用系统及运维服务流程等进行综合管理。在传统模式下，作为业务支撑的运维团队，首先需要做的就是保障系统的稳定、安全和可靠。因此，相关人员更关注可用性指标（MTTR、MTTF、MTB 等）、可靠性指标（RTO、RPO）和安全合规性，强调建设，避免变化，并往往采用“被动维持”的工作模式。

通常而言，运维的能力建设主要涵盖组织、流程和工具三个方面。在传统的 ITOM 建设中，能够真正实现数字化的工作内容并不多，除了分散建设的监控告警系统和不充分利用的 CMDB，就是主要用来维稳管控的 ITSM，然而随着技术的发展和业务模式的变化，传统模式已经有些力不从心，开始显现诸多问题：

• 运维工具烟囱式建设

运维工具多为解决某一单一运维管理场景需求，工具间相互独立，导致存在大量的数据孤岛，同时造成部分功能的重复建设，即使部分运维工具能够通过定制开发的形式和彼此实现互通，但后续的维护和扩展仍然面临挑战。

• 自动化运维能力不足

一些运维团队至今仍严重依赖手工完成发布上线、系统巡检等重复性工作，占用大量的人力资源成本。

• 流程化程度低

一些运维团队的运维工作主要集中在人工的方式，导致运维数据离散严重。由于缺少统一的流程管理系统，难以将各团队的运维工作进行有效串联，致使信息失真、沟通成本高的现象普遍存在。

• 数据化运营程度低

日常的运维工作往往沉淀了大量的运维数据，但很少被充分挖掘利用。很多运维工作依然以人工触发为主，缺乏数据化触发手段；同时，传统大数据平台使用门槛过高，无法适合运维数据场景需求。

好马配好鞍，敏捷运维转型

和研发管理一样，IT 运维同样需要敏捷转型，其核心同样也同样是以“业务驱动”为导向。敏捷转型的第一步是理念的转型，需要领导层的重视和自上而下的推进，毕竟没有人喜欢主动改变熟悉的环境。

万事开头难，有了思想的转变，接下来就是着手具体的建设任务，其内容同样包含了组织、流程和工具三方面的建设，也就是我们常说的 PPT 或 PPTR 模型。

• 人员组织：

组织建设的原则是为企业目标负责，在规划设计时，需要以企业的战略为顶层依据，综合考虑对各利益相关方的影响，根据服务列表（如对内业务、对外业务）等规则划分组织架构、岗位和职责，并以此为基础设计考核体系，最后通过和工具、流程的不断磨合，持续做出优化调整。

• 管理流程：

流程设计要为效率负责，其建立的过程需要经过调研分析、概要设计、详细设计、线上化试验和线上化运行等多个环节，同组织的建立一样，管理流程也是一个需要持续优化的过程。

• 技术工具：

工具作为运维工作的支撑，其建设原则是将日常的运维工作尽可能流程化、自动化和线上化。在规划设计时，我们通常可以考虑 RASO（Role、Scene、Activity、Object）模型，即什么角色，在什么场景下，完成什么活动，涉及什么对象。

需要注意的是，不同阶段的建设并不是按部就班的，每个阶段都可能涉及到不同管理实践建设，我们需要结合自身情况选择不同侧重点。

敏态运维的建设可以按照四个阶段去开展：

第一阶段（“流程标准”阶段）

以事件为驱动，围绕 MTTR 改善运维工作，仍以被动响应式的工作方式为主，是传统 IT 运维的典型表现。该阶段的建设重点是打好基础，全力保障系统的稳定运行，因此我们通常考虑建设统一的监控告警体系和基础的 IT 服务管理体系，如事件、问题和服务请求流程。

第二阶段（“主动管理”阶段）

“主动管理”阶段是向敏态运维转型的重要节点，其侧重点从“如何快速处理故障”向“如何减少故障”转变，同时，运维团队也需要和开发团队/ISV 服务商开展更紧密的合作。在该阶段的建设中，我们可以考虑建立应急团队和规划团队，设计变更管理、配置管理和容量管理等流程，并着手于建立一定的故障处置自动化能力，提升故障的处置效率。

第三阶段（“持续改进”阶段）

在保障业务连续性的基础上，为满足业务敏捷迭代的需求，IT 组织需要全面协作，通过精益、敏捷、DevOps 等理念，打破部门墙，为业务的全面敏捷负责。为了能够实现真正意义上的敏捷，我们可以引入“应用运维团队”的概念，围绕应用构建运维工具及管理实践，保障应用可观测性和可靠性。

第四阶段（“价值导向”阶段）

在 IT 运维管理实践足够成熟，且通过工程化建设有效较少 IT 团队的日常琐事的前提下，运维团队可进一步进行价值运营，通过运维中台和企业服务平台的建设，进行企业内部的“数字化工作空间”打造任务，比如，基于流程梳理和能力集中，实现非 IT 领域（HR、财务、管理）等的服务构建和运营。

总结

说了这么多，总结起来，数字化 IT 的关键无非是两点。

第一点是坚持以“业务驱动”为导向。IT 人员作为技术出身，重视技术，这无可厚非，但 IT 技术的本质是实现业务价值的手段，而并非目的。我们需要做的，不仅仅是满足业务部门的响应，而是能够帮助业务实现转型和进步，甚至是为业务决策带来指导性意见。

第二点是“具体问题，具体对待”。尽管敏态 IT 模式为企业业务价值的实现带来了帮助，但这并不意味着它可以适用一切，我们还需要结合实际情况进行落地，这也是我们为什么需要“双态 IT”的原因之一。同样，在 IT 建设的过程中，不同阶段的建设要做什么，怎么做，并没有一个统一的标准方案。