4. 联动场景设计原则：定义与三大设计原则
在容量压测与巡检脚本编排中，联动场景是指多个自动化 Runbook 按照业务逻辑或故障响应流程，自动触发、串联执行并共享上下文的状态机集合。设计不当的联动场景会导致执行混乱、状态丢失、无法回退。本节从定义出发，深入讲解设计联动 Runbook 的三大核心原则：幂等性、可观测性、可回滚性。
4.1 联动场景的定义
联动场景（Orchestration Scenario）是多个原子 Runbook 通过事件、条件、数据依赖组合而成的自动化执行单元。在容量压测场景中，典型的联动场景包括：
- 压测触发 → 巡检前置检查 → 资源扩容 → 压测执行 → 巡检后置验证
- 异常检测 → 告警抑制 → 自动回滚 → 通知通报
- 定时巡检 → 数据采集 → 容量预测 → 报告生成
| 维度 | 单 Runbook | 联动场景 |
|---|---|---|
| 执行范围 | 单一任务（如检查 CPU） | 多任务编排（检查→扩容→压测） |
| 状态传递 | 无或局部变量 | 全局上下文共享 |
| 失败处理 | 单点重试或退出 | 联动回滚或补偿 |
| 触发方式 | 手动或定时 | 事件驱动 + 条件判断 |
关键认知：联动场景不是 Runbook 的简单串联，而是有状态、有依赖、有补偿机制的编排单元。设计时需将每个 Runbook 视为可独立验证的“乐高积木”。
4.2 设计原则一：幂等性（Idempotency）
幂等性是指对同一联动场景执行多次，其结果与执行一次完全一致。在容量压测中，幂等性防止因重试、超时、并发触发导致的资源重复分配或状态错乱。
4.2.1 幂等性要求
- 资源操作幂等：创建资源时使用唯一标识（如 request_id），重复请求不创建新资源。
- 状态变更幂等：设置状态而非增量修改（如 set_state(RUNNING) 而非 toggle_state()）。
- 数据写入幂等：使用 upsert 语义，避免重复插入巡检结果。
4.2.2 幂等实现示例
# 非幂等写法（危险）
def scale_up():
count = get_current_instances()
set_target_instances(count + 5) # 每次执行都增加5台
# 幂等写法（安全）
def scale_up_to(target=20):
current = get_current_instances()
if current < target:
set_target_instances(target) # 设置目标值
return {"current": current, "target": target}
实践建议：在联动场景入口处生成全局唯一 correlation_id，所有子 Runbook 携带此 ID。重复请求时，根据 ID 直接返回上次执行结果，避免重复操作。
4.3 设计原则二：可观测性（Observability）
可观测性要求联动场景在执行过程中暴露足够的状态、指标和日志，使运维人员无需登录机器即可判断执行进度、定位故障点。
| 观测维度 | 具体指标 | 实现方式 |
|---|---|---|
| 执行状态 | 等待中 / 运行中 / 成功 / 失败 / 回滚中 | 状态机 + 持久化存储 |
| 进度信息 | 当前步骤 / 总步骤数 / 预计剩余时间 | 步骤计数器 + 时间戳 |
| 上下文快照 | 变量值、中间结果、错误堆栈 | 结构化日志 + 链路追踪 |
| 健康检查 | 心跳 / 存活探针 / 就绪探针 | 定时上报 + 看门狗 |
常见陷阱：只记录最终成功/失败，不记录中间步骤。当联动场景在步骤 3/7 失败时，无法定位是步骤 3 本身失败，还是步骤 2 的数据传递异常。必须为每个步骤输出独立的状态和耗时。
4.4 设计原则三：可回滚性（Rollbackability）
可回滚性是指当联动场景执行失败或产生非预期结果时，能够将系统状态恢复到执行前的安全状态。在容量压测场景中，回滚操作必须谨慎设计，避免二次破坏。
4.4.1 回滚策略对比
| 策略 | 原理 | 适用场景 | 风险 |
|---|---|---|---|
| 逆向操作 | 执行与正向操作相反的指令 | 扩容/缩容、启停服务 | 逆向操作本身可能失败 |
| 快照恢复 | 执行前保存状态快照，回滚时恢复 | 配置变更、数据修改 | 快照存储开销大 |
| 补偿事务 | 执行补偿操作抵消已生效的变更 | 多步骤联动场景 | 补偿逻辑复杂 |
| 版本切换 | 保留旧版本，回滚时切换流量 | 服务发布、流量调度 | 需要额外资源保留旧版本 |
4.4.2 回滚设计检查清单
- 每个步骤必须有对应的回滚步骤：正向操作和回滚操作成对出现。
- 回滚操作本身必须幂等：多次执行回滚不产生副作用。
- 回滚范围可控：支持单步骤回滚、部分回滚、全量回滚。
- 回滚超时处理：回滚操作超时时，标记为“回滚失败”并人工介入。
- 回滚日志独立存储：回滚操作日志与正向操作日志分开，便于审计。
设计口诀：“正向可逆，逆向幂等，失败有路，回滚有痕。” 每个联动场景必须包含回滚计划，并在非生产环境定期演练回滚流程。
4.5 三大原则的联动关系
幂等性、可观测性、可回滚性并非孤立原则，而是相互支撑的三角关系：
- 幂等性 是回滚的基础——只有幂等的回滚操作才能安全执行多次。
- 可观测性 为回滚提供决策依据——通过状态和日志判断是否需要回滚以及回滚到哪一步。
- 可回滚性 是幂等性的兜底保障——即使幂等设计有遗漏，回滚机制仍能恢复系统。
落地建议：在联动场景设计阶段，使用“三原则检查表”逐项评审。将检查表集成到 CI/CD 门禁中，不符合三原则的联动场景不允许上线。