数字化运维体系：管人、管事、管设备
当运维发展到中大型规模时，单纯的口头沟通已经无法胜任。必须设计一套能与当前运维规模相匹配的运维体系，并通过合适的软件平台落实下去。本节阐述数字化运维体系的核心方法论：目标、对象与落地路径。
一、为什么必须数字化运维
IT 建设容易，运维难。 相比以投资采购为主的建设阶段，运维阶段的各种"矛盾"更加突出：职责不清、故障反复、响应迟缓、数据缺失。如何搞好运维管理、达到可接受的 IT 服务水平，一直是 CIO 头疼的问题之一。
过去我们信奉西方鼓吹的一些标准，以为照着执行就可以解决问题，实践结果却证明这条路走不通——西方标准适合其自身信息化阶段，生搬硬套只会水土不服。
数字化运维体系的构建路径分四步：
- 将运维管理目标定为运维资源利用率最大化；
- 对运维资源及事务进行结构化统一，丰富其运维属性；
- 梳理运维资源，通过合理组织构建数字化运维体系；
- 构建 ITSM 软件并采集市场用户反馈，验证理论有效性并持续改进。
这套方法更加注重实战数据反馈，坚持以可落地作为高优先级的评判标准，适合中大型 IT 实战场景。
二、运维目标：资源利用率最大化
运维管理的终极目标是运维资源利用率最大化，通俗一点说就是"人尽其才、物尽其用"。它有三个侧面：
| 侧面 | 含义 | 路径 |
|---|---|---|
| 性价比合理（经济） | 投入产出可接受 | 开源（采购成本为零，但常需 追加开发投入）；商业（可测试对比、技术风险低，但需付费）；自研（自主可控、效果最佳，但成本高、风险高） |
| 兼顾 IT 用户体验 | 投资与体验对等 | 兼顾人性和经济规律，谨慎描述，勿过度吹嘘导致信誉损失 |
| 安全可靠（低风险） | 不出现重大损失或严重后果 | 数据安全、隐私保护、系统稳定性、访问控制、合规与应急响应 |
从成本结构看，运维总成本包含：人力（采购、开发、实施、运维、培训、安全、技术支持团队）、物力（硬件、软件许可、网络、办公设备、备份恢复设备）、时间（评估、采购、实施部署、定制开发与集成测试、培训、日常运维、升级维护）、管理（项目、人力资源、沟通协作、变更、政策流程、审计、风险）。
三、运维对象：管人、管事、管设备
西方 ITIL 的四维模型（组织机构和人员、信息和技术、合作伙伴和供应商、价值流和流程）可以通俗地转化为三个字：管人、管事、管设备。
3.1 管人：梳理角色与诉求
执行运维活动的主体是人，所以一般建议从运维人员资料入手开始梳理需求，通常包含 IT 用户、IT 工程师、IT 管理人员、供应商人员 等常见用户群体。不同角色用户有各自的需求和痛点，打造运维体系就是为了平衡这些诉求。
| 角色 | 核心诉求 | 反面场景 |
|---|---|---|
| IT 用户 | 服务体验好：无风险、零成本、方便快捷 | 找不到入口、提交麻烦、响应慢 |
| IT 工程师 | 专业化运维：职责边界清晰；有工具、有数据、有流程、有历史记录可参考；自动化工具处理重复机械工作 | 大锅饭、啥事都找我；每次重头摸排；重复累赘的工作 |
| 管理人员 | IT 预算范围内；运维/基础设施/业务系统/服务体验/安全风险均可接受 | 无法量化、无法管控、风险失控 |
| 供应商人员 | 服务需求尽快通知到 | 信息滞后、协作不畅 |
人员细分：IT 用户分内部用户（单位全体员工）与外部用户（使用我们服务的非内部人员，也是潜在服务发起者）；工程师分内部工程师（信息中心）与外部工程师（供应商、厂家、集成商、服务商的技术工程师）；管理人员分技术管理（信息中心中高层）、业务管理（业务部门中高层）、高级管理（单位高层）；其他人员如咨询顾问、行业专家酌情考量。
3.2 管设备：结构化梳理配置资源
首先，传统的 CMDB 管辖范围无法满足现代 IT 运维需求，不能照搬以往经验仅仅把 IT 资产设备纳入管理范围。精细化管理需要更详细的 IT 资源信息——除设备资源和应用软件外，还应该把业务系统和 其他逻辑资源信息纳入。
其次，应对 IT 资源关系进行梳理并适度可视化：不仅整理设备间的物理连接关系，也要梳理 IT 资源之间的逻辑关系，作为日常运营的重要数据支撑。
基础资源类型（15 类）：网络设备、物理服务器、安全设备、存储设备、个人电脑、其它 IT 设备、操作系统、数据库、中间件、Web 应用、其他软件、虚拟服务器、虚拟容器、动环设备、其他配置。
扩展资源类型：空间资源、业务系统、IP 地址、文档、知识、序列号、域名、SSL 证书等。
资源关系梳理：物理关系（物理连接上联/下联/无方向、整体包含局部、局部属于整体、无线链路、强实体关联、弱关联、被依赖/依赖于、安装部署于等）与逻辑关系（空间资源、业务系统、IP、文档、知识、序列号等）分开管理。
注意选择工作比较细心、耐心的同事作为主力梳理资源——资源台账的质量，决定后续所有分析的可信度。
3.3 管事：事务的结构化抽象
所谓管事，本质是对日常运维事务的结构化抽象：
| 事务类型 | 本质 | 常见类型 |
|---|---|---|
| 工单 | 相对完整的事务 | 服务请求、故障报修、变更、发布等 |
| 任务单 | 零碎的内部事务 | 工单协同任务、项目分解任务、巡检任务、盘点任务、管理指派任务、个人任务 |
| 项目 | 多个工单或任务的集合 | 硬件部署项目、软件开发项目、售后维保项目 |
四、中西运维体系对比
| 维度 | 中式数字化运维 | 西式流程运维 |
|---|---|---|
| 对象认知 | 结构化统一：运维资源抽象 + 运维事务抽象 | 流程化：流程无法落地或落地难；鼓吹价值，价值评估依赖少数人主观判断 |
| 过程方法 | 先数据、次过程：分析历史数据 → 找到问题根源 → 设计解决方案 → 执行改进方案 → 反馈验证持续优化 | PDCA：需求调研 → 规划 → 执行 → 检查 → 改进；实战验证不足 |
| 侧重要点 | 注重结果，结果优先、其次过程 | 注重流程、讲究过程合规；合规了，结果是否正向积极存疑 |
| 技术落地 | 量体裁衣 | 量衣裁体 |
| 成功概率 | 高 | 低 |
| 成本 | 阶段成本可控 | 无底洞且无法保证目标 |
五、落地实践：从认知到行动
落地案例（安踏集团）：一家集团型企业推进数字化战略转型后，信息中心面临的情况是——需要把现有资源（工程师 + 设备软硬件 + 业务系统）整合起来形成服务力量。过去的做法是照着 ITIL 教程搬、找一批程序员基于流程引擎打造 一套 OA/ERP 式的系统，效果不佳。新一代做法强调五个创新：
- 理论创新：基于但不局限于 ITIL v4，引入 VeriSM 等服务管理框架，更高的理论高度、更宽的行业视野；凡成功的 ITSM 都坚持以实战检验优先的设计；
- 技术创新：采用运行效率更高、更具工程化思维的技术，追求高并发性能响应；
- 设计创新：扁平化服务体系设计，简化服务设计、快速响应变化；
- 落地模式创新：找产品更是找长期服务商——业务顾问 + 团队实施 + 长期服务；"卖产品收钱拍屁股走人"的做法已被淘汰；
- 用户体验创新：ToB 权衡，优先保证信息正确、兼容良好、操作流畅，其次才是美观。
经验教训：少提口号，多干实事。 解决故障时，多聊事实、多分析数据、少扯淡。ITSM 的价值不在宣传，而在每一个被顺畅解决的工单里。
小结：数字化运维体系 = 目标（资源利用率最大化）× 对象（管人、管事、管设备）× 方法（结构化梳理 + 数据驱动 + 实战检验）。这套体系不是新造一个理论，而是把运维这件"复杂的事"拆成"可管理的对象"，再用软件固化下来。
完整实施版见《信息技术数字化服务体系实施指南》：本页为理论概要，该系列按建设目标、核心思想、管理内容、体系设计、实施要点、测量指标、后记八个部分展开。