3. 模板化设计原则：DRY原则、单一职责、可复用性、可扩展性、版本控制

Runbook 模板化不是简单的复制粘贴，而是一套遵循软件工程最佳实践的设计体系。本节将深入解析支撑 Runbook 模板化设计的五大核心原则，帮助你在构建自愈模板时做出正确的架构决策。

3.1 五大原则概览

下表总结了五大原则的核心关注点及其在 Runbook 模板中的具体体现：

3.2 DRY 原则：消除重复，集中维护

DRY（Don't Repeat Yourself）是模板化的基石。在 Runbook 中，重复意味着多处维护、容易遗漏、变更风险高。

正确做法： 将“进程健康检查”抽象为一个参数化模块，所有 Runbook 通过引用该模块来调用：

# 共享模块：health_check.yaml
steps:
  - name: "检查进程存活"
    command: "curl -f http://${HOST}:${PORT}/health"
    retry: 3
    interval: 5s

# 引用模块：disk_cleanup_runbook.yaml
import:
  - module: "health_check.yaml"
    params:
      HOST: "localhost"
      PORT: "${APP_PORT}"

3.3 单一职责原则：一个模板，一个场景

每个 Runbook 模板应该只负责一种自愈场景。混合多个职责会导致模板臃肿、难以测试、复用性下降。

• 正确： disk_cleanup_template.yaml 只处理磁盘空间清理，包含检查阈值、清理临时文件、归档日志。
• 错误： 同一个模板既处理磁盘清理，又处理内存泄漏重启，还包含数据库连接池调整。

3.4 可复用性：参数化驱动环境无关

可复用性要求模板不硬编码任何环境特定值。通过参数化变量，同一个模板可以适配开发、测试、生产环境。

3.5 可扩展性：插件式架构支持新场景

可扩展性确保当出现新的自愈场景时，你只需添加新模板，而无需修改现有模板或框架代码。

下图展示了基于插件式架构的 Runbook 模板扩展模型：

3.6 版本控制：可追溯的模板生命周期

将 Runbook 模板视为代码进行版本管理，是保障生产环境稳定性的关键。推荐使用 Git 仓库 + 语义化版本号（SemVer）的组合策略。

版本控制最佳实践：

• 仓库结构： 每个模板独立目录，包含 template.yaml、README.md、tests/ 子目录。
• 版本号规则： MAJOR.MINOR.PATCH（例如 v2.1.3），MAJOR 变更表示不兼容的模板结构改动。
• 变更记录： 每个版本在 CHANGELOG.md 中记录新增、修复、废弃内容。
• 发布标签： Git tag 与版本号一一对应，支持快速回滚到任意历史版本。

# 模板仓库目录结构示例
runbook-templates/
├── disk_cleanup/
│   ├── v1.0.0/
│   │   ├── template.yaml
│   │   └── README.md
│   ├── v1.1.0/
│   │   ├── template.yaml
│   │   ├── README.md
│   │   └── CHANGELOG.md
│   └── v2.0.0/
│       ├── template.yaml
│       ├── README.md
│       └── CHANGELOG.md
├── process_restart/
│   └── ...
└── network_self_heal/
    └── ...

3.7 原则协同：构建高质量模板

五大原则并非孤立存在，它们相互协同，共同构建高质量的 Runbook 模板体系。下图展示了原则之间的依赖与增强关系：