4. 服务目录的层级结构
备份恢复变更窗口服务目录采用四级分层结构，从宏观服务大类到微观操作步骤逐级细化。每一级都承载明确的分类职责，确保运维人员、审批者和执行者能够快速定位所需服务，并理解其上下文。
设计原则：一级按业务域划分，二级按技术类型划分，三级按可交付单元划分，四级按原子操作划分。层级之间保持“1:N”的树形关系，避免交叉归属。
4.1 四级层级定义与职责
| 层级 | 名称 | 职责 | 示例 |
|---|---|---|---|
| 一级 | 服务大类 | 按业务领域或系统平台划分，面向服务目录的顶层导航 | 数据保护服务 |
| 二级 | 服务类型 | 按技术实现方式或恢复粒度划分，面向技术选型 | 文件级备份恢复 |
| 三级 | 服务项 | 按可独立申请和交付的运维动作划分，面向变更请求 | Linux 文件系统增量备份 |
| 四级 | 操作步骤 | 按执行脚本或操作手册的原子步骤划分，面向自动化执行 | 执行 rsync 增量同步 |
设计提示：四级结构并非强制要求所有服务项都展开到四级。对于简单操作（如“查看备份状态”），三级即可满足需求；对于复杂变更（如“数据库全量恢复”），必须展开到四级以降低执行风险。
4.2 层级结构全景图
以下 SVG 展示了备份恢复变更窗口服务目录的四级层级关系，以及各层级之间的归属与流转路径。
4.3 一级目录：服务大类
一级目录是服务目录的最高分类层级，通常按业务域或系统平台进行划分。在备份恢复场景中，建议将“数据保护服务”作为独立的一级大类，与“计算服务”“网络服务”“存储服务”等并列。
- 命名规范：使用名词性短语，简洁且具有业务辨识度，例如“数据保护服务”“容灾恢复服务”。
- 数量控制：整个服务目录的一级大类建议控制在 5～8 个，避免过多导致导航困难。
- 归属边界：每个一级大类应具备清晰的业务边界，不与其他大类产生交叉。例如“数据保护服务”不包含“网络安全服务”中的日志备份。
4.4 二级目录：服务类型
二级目录在一级大类内部按技术实现方式或恢复粒度进行细分。对于“数据保护服务”，常见的二级分类包括：
| 二级服务类型 | 技术特征 | 典型场景 |
|---|---|---|
| 文件级备份恢复 | 基于文件系统接口，按文件或目录粒度操作 | Linux 服务器配置文件备份、Windows 共享文件夹恢复 |
| 数据库级备份恢复 | 基于数据库原生工具或 API，支持事务一致性 | MySQL 全量备份、Oracle RMAN 恢复 |
| 虚拟机级备份恢复 | 基于虚拟化平台快照或 API，整机粒度操作 | VMware vSphere 整机备份、Hyper-V 即时恢复 |
| 对象存储备份恢复 | 基于 S3/OSS 协议，按对象或桶粒度操作 | MinIO 桶备份、阿里云 OSS 跨区域复制 |
注意：二级目录的设计应充分考虑未来扩展性。例如，当引入容器备份（如 Velero 备份 Kubernetes 集群）时，应能自然新增“容器级备份恢复”类型，而不需要重构已有分类。
4.5 三级目录：服务项
三级目录是服务目录中可独立申请和交付的最小服务单元。每个服务项对应一个具体的变更窗口请求，包含明确的输入、输出、SLA 和审批流程。
服务项的命名应遵循“平台 + 动作 + 粒度”的格式：
- 平台：Linux、Windows、MySQL、Oracle、VMware 等。
- 动作：全量备份、增量备份、全量恢复、时间点恢复、校验等。
- 粒度：文件级、数据库级、整机级等。
示例服务项清单：
| 服务项名称 | 所属二级类型 | 预计执行时长 | 变更窗口要求 |
|---|---|---|---|
| Linux 文件系统增量备份 | 文件级备份恢复 | 30 分钟 | 无窗口限制 |
| MySQL 全量备份 | 数据库级备份恢复 | 60 分钟 | 低峰期窗口 |
| VMware 整机恢复 | 虚拟机级备份恢复 | 120 分钟 | 紧急变更窗口 |
| MinIO 桶增量同步 | 对象存储备份恢复 | 45 分钟 | 无窗口限制 |
4.6 四级目录：操作步骤
四级目录是服务目录的最细粒度，对应执行脚本或操作手册中的原子步骤。四级目录的设计直接影响自动化编排的可行性和变更执行的标准化程度。
每个四级操作步骤应包含以下属性：
- 步骤编号：如 STEP-01、STEP-02，用于编排顺序。
- 步骤名称：动词开头的简短描述，如“执行 rsync 增量同步”。
- 执行方式：手动 / 半自动 / 全自动。
- 前置条件：执行前必须满足的条件，如“目标目录已挂载”。
- 后置验证：执行后必须检查的指标，如“文件数量一致”。
- 回滚步骤：失败时的回退操作，如“删除目标目录新增文件”。
最佳实践：四级操作步骤建议与 CMDB 中的脚本库或 Ansible Playbook 的 task 名称保持一一对应。这样，当服务目录触发变更时，可以直接映射到自动化执行单元，减少人工翻译成本。
4.7 层级结构设计检查清单
在完成服务目录层级设计后，建议使用以下清单进行自检：
| 检查项 | 通过标准 | 自检结果 |
|---|---|---|
| 一级大类边界清晰 | 每个服务项只属于一个一级大类 | □ 通过 □ 需调整 |
| 二级类型覆盖完整 | 当前所有备份恢复场景均有对应二级类型 | □ 通过 □ 需调整 |
| 三级服务项可独立交付 | 每个服务项有明确的输入、输出和 SLA | □ 通过 □ 需调整 |
| 四级步骤可执行 | 每个步骤有明确的执行命令或脚本 | □ 通过 □ 需调整 |
| 层级深度一致 | 同类服务展开到相同层级深度 | □ 通过 □ 需调整 |
4.8 层级结构设计示例：MySQL 全量备份
以下示例展示一个完整的四级路径，从一级大类到四级操作步骤：
一级：数据保护服务
└── 二级：数据库级备份恢复
└── 三级：MySQL 全量备份
├── 四级 STEP-01：检查 MySQL 实例运行状态
├── 四级 STEP-02：锁定备份表（FLUSH TABLES WITH READ LOCK）
├── 四级 STEP-03：执行 mysqldump 全量导出
├── 四级 STEP-04：解锁表（UNLOCK TABLES）
├── 四级 STEP-05：压缩备份文件
├── 四级 STEP-06：传输备份文件到备份存储
└── 四级 STEP-07：校验备份文件完整性（md5sum）
扩展思考：如果未来需要支持 MySQL 增量备份，只需在三级目录下新增“MySQL 增量备份”服务项，并定义其四级步骤（如基于 binlog 解析），而不需要修改已有的一级和二级结构。这正是四级层级结构带来的扩展性优势。