管理内容：管人、管设备、管事
运维体系要管的对象，可以归纳为三件事：管人、管设备、管事。这里的"管设备"并非仅指硬件设备，而是指除人之外的全部 IT 资源；"管事"则是对日常运维事务的结构化抽象。
梳理从哪里入手？但凡事务，必然牵涉受众（用户）或执行人（工程师）；而设备同样涉及使用它的用户，以及维护、采购、保管它的人员。因此通常以运维人员作为梳理入口，先把"谁在用、谁在做、谁在管"弄清楚。技术人员日常打交道最多的是设备资源，因此把 IT 资源作为第二组梳理对象是合理的——但这一步需要打破传统 IT 设备的范畴，把 IP 地址、业务系统、文档、知识等逻辑资源一并纳入。资源梳理完成后，基于已掌握的资源信息设计合理的运维组织方式，运维事务的分类与流程也就水到渠成。
4.1 管人：运维角色梳理
执行运维活动的主体是人，因此一般建议从运维人员资料入手开始梳理需求。常见的用户群体包括 IT 用户、IT 工程师、IT 管理人员、供应商人员等，不同角色各有诉求与痛点。构建运维体系的目的，正是平衡这些不同角色的期望。
| 角色 | 核心诉求 | 要避免的反面场景 |
|---|---|---|
| IT 用户 | IT 服务体验好：享受方便快捷的专业 IT 服务，做到无风险、零成本 | — |
| IT 工程师 | 专业化运维，工作边界与职能清晰；规范的运维体系，有工具、有数据、有流程，并有历史处理记录可参考；有自动化工具支撑，处理重复机械的工作 | 大锅饭，啥事都能找到我；每次故障都要重头摸排一遍；每天被重复累赘的工作淹没 |
| 管理人员 | 在 IT 预算范围内，运维服务水平、基础设施运行、业务系统运行、IT 服务体验、信息安全风险均可接受 | — |
| 供应商人员 | 有服务需求时能尽快通知到位 | — |
角色细分
IT 用户可分为两类：
- 内部用户：单位内部全体员工；
- 外部用户：非本单位员工，但可能使用本单位提供的 IT 服务产品，同样是潜在的服务发起者。
工程师也可分为两类：
- 内部工程师：单位信息中心的 IT 工程师；
- 外部工程师：供应商（含厂家、集成商、服务商等）派出的技术工程师。
管理人员按视角不同分为三类：
- 技术管理人员：信息中心内部的中高级管理人员；
- 业务管理人员：业务部门的中高级管理人员；
- 高级管理人员：单位高级管理人员。
此外，还有一些可能与 IT 产生交集的人员，如咨询顾问、行业专家等，可根据自身实际情况酌情考量。
4.2 管设备：IT 资源梳理
传统 CMDB 的管辖范围已无法满足现代 IT 运维需求，因此不能照搬以往经验，仅仅把 IT 资产设备纳入管理。精细化管理需要更详细的资源信息：除去设备资源和应用软件外，还应将业务系统和其他逻辑资源一并纳入资源库。
其次，应对 IT 资源之间的关系进行梳理，并做适度的可视化——不仅整理设备间的物理连接关系，也要梳理资源间的逻辑关系，作为日常运营的重要数据支撑。
提醒：资源梳理是一项耗时且琐碎的工作，建议选择工作细心、耐心的同事作为主力。
通常按以下资源类型进行梳理。
基础资源
| 编号 | 名称 | 常见资源描述 |
|---|---|---|
| 1 | 网络设备 | 交换机、路由器等网络互联硬件 |
| 2 | 物理服务器 | 机架式、塔式等实体计算服务器 |
| 3 | 安全设备 | 防火墙、入侵检测、安全网关等防护硬件 |
| 4 | 存储设备 | 磁盘阵列、磁带库、SAN/NAS 等存储硬件 |
| 5 | 个人电脑 | 台式机、笔记本等办公终端 |
| 6 | 其它 IT 设备 | 打印机、扫描仪、投影仪等其他办公硬件 |
| 7 | 操作系统 | 部署在服务器或终端上的操作系统软件 |
| 8 | 数据库 | Oracle、MySQL、SQL Server 等数据库管理系统 |
| 9 | 中间件 | Tomcat、WebSphere、消息队列等中间件软件 |
| 10 | Web 应用 | 部署运行的 Web 应用系统 |
| 11 | 其他软件 | 上述类别未覆盖的各类应用软件 |
| 12 | 虚拟服务器 | 虚拟化平台上运行的虚拟机 |
| 13 | 虚拟容器 | Docker 等容器化实例 |
| 14 | 动环设备 | 机房 UPS、精密空调、温湿度传感等动力环境监控设备 |
| 15 | 其他配置 | 上述类别未覆盖的其他配置项 |
扩展资源
| 编号 | 名称 | 常见资源描述 |
|---|---|---|
| 1 | 空间资源 | 机房、机柜、办公区域等物理空间位置 |
| 2 | 业务系统 | 面向业务提供服务的应用系统 |
| 3 | IP 地址 | 网络中分配使用的 IP 地址资源 |
| 4 | 文档 | 设计文档、操作手册、实施方案等资料 |
| 5 | 知识 | 故障案例、处理经验、运维知识条目 |
| 6 | 序列号 | 设备与软件许可证的序列号、授权编号 |
| 7 | 域名 | 注册并使用的互联网域名 |
| 8 | SSL 证书 | HTTPS 等通信所使用的加密证书 |
4.3 管事：事务的结构化抽象
所谓管事，本质是对日常运维事务做结构化抽象。按事务的完整程度，可抽象为三类：
| 事务类型 | 本质 | 常见类型 |
|---|---|---|
| 工单 | 相对完整的事务 | 服务请求、故障报修、变更、发布等 |
| 任务单 | 零碎的内部事务 | 工单协同任务、项目分解任务、巡检任务、盘点任务、管理指派任务、个人任务 |
| 项目 | 多个工单或任务的集合 | 硬件部署项目、软件开发项目、售后维保项目 |
三者层次分明：工单是面向服务、相对完整的一次事务闭环；任务单是更零碎、偏内部协同的事务；项目则由多个工单或任务聚合而成，用于管理有目标、有周期的成组工作。
4.4 资源关系
资源梳理不只是登记一个个孤立的配置项，更要理清它们之间的关系。关系分为物理关系与逻辑关系两类，梳理后适度可视化，是故障定位、影响分析和日常运营的重要数据支撑。
物理关系
| 编号 | 关系名称 | 关系描述 |
|---|---|---|
| 1 | 物理连接（上联） | 本配置项向上游设备的物理连线，如服务器上联接入交换机 |
| 2 | 物理连接（下联） | 本配置项向下游设备的物理连线，如交换机下联服务器 |
| 3 | 物理连接（无方向） | 不区分上下游的对等物理连线 |
| 4 | 整体包含了局部 | 整体配置项包含某个局部配置项，如机 柜包含服务器 |
| 5 | 局部属于整体 | 局部配置项归属于某个整体配置项 |
| 6 | 无线链路 | 以无线方式建立的链路连接 |
| 7 | 强实体关联 | 两个实体之间紧密、刚性的关联 |
| 8 | 弱关联类型 | 两个实体之间松散、可选的关联 |
| 9 | 逻辑关联 | 不依赖物理连线、存在于逻辑层面的关联 |
| 10 | 被依赖 | 本配置项被其他配置项所依赖 |
| 11 | 依赖于 | 本配置项依赖其他配置项才能正常运行 |
| 12 | 安装部署了 | 某主机或设备上安装部署了某个软件或系统 |
| 13 | 安装部署于 | 某软件或系统安装部署在某台主机或设备上 |
| 14 | 其他配置关系 | 上述类别未覆盖的其他配置项关系 |
逻辑关系
| 编号 | 关系名称 | 关系描述 |
|---|---|---|
| 1 | 空间资源 | 配置项所处或占用的空间位置，如设备所在机房机柜、测试线路走向 |
| 2 | 业务系统 | 配置项所属或支撑的业务系统 |
| 3 | IP 地址 | 配置项绑定、使用的 IP 地址 |
| 4 | 文档 | 与配置项相关联的设计、运维文档 |
| 5 | 知识 | 与配置项相关联的知识条目、故障案例 |
| 6 | 序列号 | 配置项对应的序列号、授权编号 |
4.5 运维铁三角
本节原稿仅留存"运维铁三角"标题，正文缺失；以下依据本系列"管人、管设备、管事"三支柱的上下文补全，供读者参考。
管人、管设备、管事三者并非孤立，而是互为支撑的铁三角：
- 人是运维活动的执行主体与服务对象，决定了体系为谁服务、由谁落地；
- **资源（设备）**是运维活动的作用对象与数据基础，没有清晰的资源台账，人就无从着手、事就无从谈起；
- 事务是人围绕资源开展的具体活动，把人与资源以流程的方式组织起来。
三者缺一，体系即失衡：只管人管事而不清点资源，运维如同盲人摸象；只堆资源而不梳理人与事，资源库便沦为静态台账；只定流程而不落到具体的人和资源，流程只会空转。后续"体系设计"一章，正是围绕这三者的组织方式展开。