服务目录基础：定义、层级结构与CMDB关联
服务目录是ITSM体系的“前台货架”，它把IT部门提供的所有服务以标准化、可视化的方式呈现给客户和用户。在故障自愈场景中，服务目录决定了哪些服务可以触发自动恢复动作、恢复动作的优先级以及变更窗口的约束条件。本节从定义、层级结构和与CMDB的关联三个维度建立服务目录的基础认知。
2.1 服务目录的定义
服务目录（Service Catalog）是一份经过审核并维护的、IT部门向客户提供的所有服务清单。它包含每项服务的描述、服务等级、定价（若适用）、交付流程、依赖关系以及故障响应策略。在故障自愈配置中，服务目录是“自愈策略”的挂载点——每一项服务都可以绑定一组自愈剧本和变更窗口规则。
核心价值：服务目录将技术层面的运维能力转化为业务语言，使业务方能够理解“我能获得什么服务”，同时为运维自动化提供标准化的触发入口。
| 维度 | 说明 | 故障自愈关联 |
|---|---|---|
| 服务定义 | 服务名称、描述、服务等级目标（SLO） | 决定自愈动作的紧急程度与恢复时间目标 |
| 服务属性 | 服务类别、负责人、支持团队、成本中心 | 自愈通知的接收方与升级路径 |
| 服务依赖 | 依赖的基础设施、应用组件、外部服务 | 自愈时需检查依赖链，避免级联恢复 |
| 变更窗口 | 允许执行变更的时间段、冻结期、审批规则 | 自愈动作是否受变更窗口约束 |
2.2 服务目录的层级结构
服务目录通常采用三层或四层结构，从宏观到微观逐级细化。层级越深，服务的技术细节越明确，故障自愈策略的配置粒度也越精细。
- 服务组合层（Service Portfolio）：最高层级，包含所有已规划、在运营和已退役的服务。故障自愈通常只关注“在运营”部分。
- 服务目录层（Service Catalog）：面向客户可见的服务列表，如“邮件服务”“ERP系统”“网络接入”。每个目录项对应一个自愈策略组。
- 服务项层（Service Item）：目录下的具体服务实例，如“企业邮箱-生产环境”“ERP-财务模块”。自愈剧本直接绑定到服务项。
- 服务动作层（Service Action）（可选）：服务项下的原子操作，如“重启服务”“切换备机”“扩容节点”。故障自愈的执行单元。
实践建议：在配置故障自愈时，建议将自愈策略挂载在服务项层。这一层既保留了业务语义，又具备足够的技术粒度，避免策略过于宽泛或过于碎片化。
2.3 服务目录与CMDB的关联
CMDB（配置管理数据库）是IT运维的“后台仓库”，记录所有配置项（CI）及其关系。服务目录与CMDB的关联是故障自愈能够自动定位故障源和精准执行恢复动作的关键桥梁。
两者之间的核心映射关系如下：
| 关联维度 | 服务目录侧 | CMDB侧 | 故障自愈用途 |
|---|---|---|---|
| 服务→CI映射 | 服务项（如“ERP-财务模块”） | 应用系统CI、数据库CI、中间件CI | 故障告警到达时，快速定位受影响的服务 |
| 依赖关系 | 服务依赖列表 | CI间的“运行于”“连接至”“依赖”关系 | 自愈时按依赖顺序恢复，避免先恢复下游 |
| 变更窗口 | 服务项绑定的变更窗口策略 | CI的维护时段、冻结期属性 | 判断自愈动作是否在允许窗口内执行 |
| 负责人/团队 | 服务支持团队 | CI的运维责任人、备份责任人 | 自愈失败时自动升级通知到正确的人 |
常见误区：很多团队将服务目录与CMDB割裂维护，导致故障发生时“告警来了但不知道影响哪个服务”或“知道服务受影响但找不到对应的CI”。故障自愈要求两者保持实时同步，建议通过自动化工具（如服务映射引擎）定期校验映射关系。
2.4 服务目录在故障自愈中的关键作用
服务目录在故障自愈配置中承担策略挂载点和上下文传递者的双重角色。具体体现在以下三个环节：
- 告警过滤与路由：根据告警中携带的CI信息，通过服务目录→CMDB映射，确定受影响的服务项，进而决定是否触发自愈流程。
- 变更窗口校验：服务项绑定的变更窗口策略决定自愈动作能否立即执行。若当前时间不在窗口内，自愈流程进入“等待审批”或“跳过自动恢复”状态。
- 自愈剧本选择：不同服务项可绑定不同的自愈剧本。例如“数据库-主库”服务项绑定“主备切换”剧本，“邮件-生产环境”绑定“重启服务+健康检查”剧本。
最佳实践：在ITSM工具中配置服务目录时，建议为每个服务项预留“自愈策略ID”和“变更窗口ID”两个扩展字段。这样在故障自愈引擎中可以直接通过服务项ID获取策略配置，无需二次查询。