闭环缺一环就退化
闭环指从告警触发到处置执行、再到结果验证与状态回写的完整链路。缺任何一环都会退化：没有验证等于假设处置成功，没有回写则告警与工单长期与实际状态不一致，没有终止条件则系统会在同一问题上反复执行，形成振荡。
基本信息
| 闭环环节 | 触发、执行、验证、回写 |
|---|---|
| 验证方式 | 复用健康检查重新判定一次 |
| 终止条件 | 成功、失败、达到尝试上限 |
| 回写内容 | 动作类型、耗时、结果、执行者 |
| 防振荡 | 冷却时间与连续恢复判定 |
典型使用场景
- 进程异常：告警触发重启，重启后重新执行健康检查确认恢复
- 实例不可用：自动摘除并通知，结果回写避免重复通知
- 处置失败：连续失败达上限后升级人工，并附上失败现场
- 反复振荡：同一告警短时间内多次触发时拉长冷却时间，避免动作叠加
- 复盘改进：统计自动处置成功率，把无效动作从剧本中移除
闭环环节与缺位后果
| 环节 | 作用 | 缺位后果 |
|---|---|---|
| 触发 | 由告警或巡检结果发起 | 依赖人工发现，响应延迟 |
| 执行 | 按剧本调用处置动作 | 动作不一致，结果无法复现 |
| 验证 | 重新检查确认已恢复 | 假设成功，故障仍然存在 |
| 回写 | 更新告警与工单状态 | 状态滞后，重复告警与重复动作 |
闭环骨架与留痕
闭环骨架与留痕
# 触发 -> 执行 -> 验证 -> 回写，四步都要留痕
if ! /opt/check/health.sh; then # 触发条件
systemctl restart app.service >> action.log # 执行处置动作
sleep 5 # 给服务留出启动时间
if /opt/check/health.sh; then # 验证处置是否生效
echo resolved >> action.log # 回写成功状态
else
echo still-broken-escalate >> action.log # 升级人工并附现场
fi
fi验证环节应复用同一套健康检查，而不是另写一个判断。两套逻辑并存时容易出现处置侧判定成功、检查侧仍报失败的分歧，闭环状态随之失去可信度。
自动处置必须有冷却时间。告警抖动与处置动作叠加会形成振荡：动作触发新告警、新告警再触发动作，最终把局部问题扩散成持续不可用。