@umacloud/knowledge 1.0.1

package/incident/04-antipatterns/incident-antipatterns.md

@@ -0,0 +1,490 @@
+---
+id: incident-antipatterns
+title: 事故管理反模式指南 (Incident Management Anti-Patterns)
+domain: incident
+category: 04-antipatterns
+difficulty: intermediate
+tags: [alert, antipatterns, fatigue, heroism, incident, postmortem, 反模式, 告警疲劳]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 事故管理反模式指南 (Incident Management Anti-Patterns)
+
+> 适用范围：SRE / DevOps / 运维团队 / 研发团队
+> 约束级别：SHALL（必须在事故管理流程建设中规避）
+> 目标：识别和消除事故管理中的常见反模式，建设高效、可靠的事故响应体系。
+
+---
+
+## 反模式 1: 英雄主义 (Heroism)
+
+### 描述
+
+团队依赖少数"英雄"工程师来解决所有重大事故，这些人总是半夜被叫醒、总是第一个响应、总是能救火。组织将个人的超负荷付出视为理所当然，而非系统性问题的信号。
+
+### 危害
+
+- 英雄疲惫导致判断力下降，引发更大的事故
+- 知识集中在少数人身上，形成单点故障
+- 其他团队成员缺少锻炼机会，能力无法成长
+- 英雄离职后团队事故响应能力断崖式下降
+- 表面上"问题总能解决"掩盖了系统性的架构和流程缺陷
+
+### 错误做法
+
+```
+# BAD: 英雄主义模式
+事故发生 → 所有人第一反应"找张三"
+→ 张三不在？等张三上线
+→ 张三每月值班 25 天，年假从不敢休
+→ 其他人旁观学习但从不独立处理
+→ 管理层: "张三真靠谱，给他加绩效"
+```
+
+### 正确做法
+
+```
+# GOOD: 系统化的事故响应
+事故发生 → On-Call 轮值工程师按 Runbook 响应
+→ 10 分钟无法解决 → 自动升级到二线
+→ 所有操作步骤记录在 Runbook 中，任何人可执行
+→ 事故后复盘更新 Runbook，补充缺失步骤
+→ 每月模拟演练，确保所有轮值人员都能独立响应
+```
+
+### 检测信号
+
+- 同一个人处理了 > 50% 的 P0/P1 事故
+- On-Call 轮值表上总是同一批人
+- 有人说"这个问题只有 XX 能解决"
+- Runbook 覆盖率 < 50% 或长期未更新
+
+---
+
+## 反模式 2: 告警疲劳 (Alert Fatigue)
+
+### 描述
+
+监控系统产生大量低价值或重复的告警，On-Call 工程师被淹没在告警洪流中，逐渐对告警麻木，开始忽略甚至静音告警，导致真正的严重问题被淹没。
+
+### 危害
+
+- 关键告警被忽略，事故发现时间（TTD）大幅延长
+- On-Call 工程师精神压力大，睡眠质量差，离职率高
+- 团队对监控系统失去信任，不再认真对待告警
+- 形成恶性循环：越忽略告警 → 越多告警无人处理 → 越多告警
+
+### 错误做法
+
+```yaml
+# BAD: 告警配置示例
+alerts:
+  - name: CPU_HIGH
+    condition: cpu > 50%        # 阈值过低，正常波动就触发
+    severity: critical           # 所有告警都是 critical
+    channels: [sms, call, email, slack]  # 所有渠道都通知
+
+  - name: MEMORY_HIGH
+    condition: memory > 60%     # 同上
+    severity: critical
+    channels: [sms, call, email, slack]
+
+  - name: DISK_USAGE
+    condition: disk > 70%       # 70% 根本不需要告警
+    severity: critical
+    channels: [sms, call, email, slack]
+
+# 结果: On-Call 每天收到 200+ 条告警，90% 无需处理
+```
+
+### 正确做法
+
+```yaml
+# GOOD: 分级分层的告警策略
+alerts:
+  - name: API_ERROR_RATE_CRITICAL
+    condition: error_rate_5m > 5%
+    severity: critical
+    channels: [pagerduty]      # 仅电话告警
+    runbook: https://wiki/runbook/api-error-rate
+    auto_resolve: true
+
+  - name: API_ERROR_RATE_WARNING
+    condition: error_rate_5m > 1%
+    severity: warning
+    channels: [slack]          # 仅消息通知
+    suppress_duration: 30m     # 30 分钟内不重复
+
+  - name: DISK_USAGE_HIGH
+    condition: disk > 90%
+    severity: warning
+    channels: [slack]
+    predict_full_in: 24h       # 预测 24 小时内满才告警
+
+# 原则:
+# - Critical: 需要立即人工介入，否则用户受影响
+# - Warning: 需要关注但不紧急，工作时间处理
+# - Info: 记录但不通知，用于排查和趋势分析
+```
+
+### 检测信号
+
+- On-Call 每天收到 > 50 条告警
+- 告警中 > 70% 无需人工处理（auto-resolve 或 false positive）
+- 团队有人把告警通知静音了
+- 存在"告警风暴"（一个问题触发 10+ 条告警）
+
+---
+
+## 反模式 3: 无复盘 (No Postmortem)
+
+### 描述
+
+事故恢复后就结束了，不进行系统化的复盘分析。团队忙于日常开发，认为复盘"太耗时间"或"已经知道原因了不需要开会"。结果同类事故反复发生。
+
+### 危害
+
+- 同类事故反复发生，MTTR 不降反升
+- 团队无法从失败中学习，不断踩同一个坑
+- 缺少改进驱动力，系统稳定性停滞不前
+- 新人无法从历史事故中学习经验
+
+### 错误做法
+
+```
+# BAD: 事故恢复后的典型场景
+15:05 事故恢复
+15:10 "好了，问题解决了，大家继续干活吧"
+15:15 回到各自的 Sprint 任务
+（三周后同样的问题再次发生）
+"这个问题上次不是修了吗？" "修了临时方案，根本原因没处理"
+```
+
+### 正确做法
+
+```
+# GOOD: 事故恢复后的标准流程
+15:05 事故恢复
+15:10 创建复盘 Issue，记录初步时间线
+15:15 指定复盘负责人，预约复盘会议（48h 内）
+Day+2 举行复盘会议（60min）
+Day+3 复盘报告发布，行动项创建为 JIRA
+Week+1 行动项进度 Review
+Week+4 验证行动项效果
+```
+
+### 检测信号
+
+- P1 以上事故无对应的复盘报告
+- 复盘报告无行动项，或行动项无人跟踪
+- 同类事故在 90 天内重复发生
+- 团队不知道过去一年有哪些事故
+
+---
+
+## 反模式 4: Blame 文化 (Blame Culture)
+
+### 描述
+
+事故发生后，第一反应是追问"谁干的"而非"为什么会发生"。犯错的人被公开批评、扣绩效或被要求写检讨，导致团队隐瞒问题而非暴露问题。
+
+### 危害
+
+- 工程师隐瞒操作失误，小问题滚成大事故
+- 没人敢做高风险的必要变更，系统停滞不前
+- 复盘变成追责会议，无法获得真实信息
+- "近失事件"（Near Miss）完全不被上报
+- 优秀工程师因文化问题离职
+
+### 错误做法
+
+```
+# BAD: Blame 文化的复盘会议
+经理: "这次事故谁上线的代码？"
+工程师 A: "...是我"
+经理: "上线前没测试吗？基本功都不扎实"
+工程师 A: "测了，但是..."
+经理: "以后你的代码必须两个人 Review 才能上线"
+（之后 A 变得谨慎到不敢发布任何变更，其他人学会了 Never volunteer）
+```
+
+### 正确做法
+
+```
+# GOOD: 无责文化的复盘会议
+主持人: "让我们了解一下当时发生了什么。A，你能描述一下上线的过程吗？"
+A: "我在 14:00 执行了部署，测试环境一切正常。上线后发现生产环境的
+   数据量比测试环境大 100 倍，查询性能完全不同。"
+主持人: "这说明我们的测试环境和生产环境数据量差异太大。
+   这是一个系统性的差距，我们来讨论怎么改进。"
+行动项: 建设与生产等比例的 Staging 环境
+```
+
+### 检测信号
+
+- 复盘报告中出现个人名字和批评性语言
+- 事故后有人被要求"写检讨"或"做承诺"
+- 工程师说"我不敢部署"或"让别人来上线"
+- 小事故被隐瞒，直到变成大事故才被发现
+
+---
+
+## 反模式 5: 手动恢复 (Manual Recovery)
+
+### 描述
+
+事故恢复完全依赖人工操作：手动 SSH 到服务器、手动执行 SQL、手动重启服务、手动切换流量。操作步骤在每个人脑子里，没有文档化和自动化。
+
+### 危害
+
+- 恢复时间长，人工操作需要回忆和查找步骤
+- 操作失误风险高，紧张情况下更容易犯错
+- 非专家无法执行恢复，依赖特定人员
+- 相同的恢复操作每次都要从头来
+
+### 错误做法
+
+```bash
+# BAD: 手动恢复流程（存在于某人的记忆中）
+# 1. SSH 到生产服务器（哪台来着？）
+ssh admin@prod-server-03
+
+# 2. 查看日志（日志路径是什么？）
+tail -f /var/log/app/error.log
+
+# 3. 重启服务（直接 kill 还是 graceful？）
+sudo systemctl restart app-service
+
+# 4. 检查是否恢复（看哪个指标？）
+curl http://localhost:8080/health
+
+# 5. 如果没恢复，回滚数据库（回滚到哪个版本？SQL 是什么？）
+psql -c "UPDATE config SET value='old_value' WHERE key='feature_flag'"
+```
+
+### 正确做法
+
+```yaml
+# GOOD: 自动化恢复 Runbook
+# runbook/api-service-recovery.yaml
+name: API 服务恢复
+trigger: API 错误率 > 5% 持续 5 分钟
+steps:
+  - name: 自动诊断
+    action: run_diagnostics
+    checks: [health, connectivity, resources, recent_deploys]
+
+  - name: 自动重启（如果健康检查失败）
+    action: rolling_restart
+    target: api-service
+    canary: true
+    rollback_on_failure: true
+
+  - name: 自动回滚（如果重启无效且有近期部署）
+    action: rollback_deployment
+    target: api-service
+    to: last_stable_version
+
+  - name: 自动扩容（如果是流量导致）
+    action: scale_up
+    target: api-service
+    max_replicas: 20
+
+  - name: 人工介入（以上均无效）
+    action: page_oncall
+    escalation: P1
+    context: "自动恢复失败，需人工排查"
+```
+
+### 检测信号
+
+- 事故恢复过程中有 SSH 到生产服务器的操作
+- 恢复步骤没有文档化，依赖口头传授
+- MTTR > 30 分钟的事故中，> 50% 时间花在"回忆步骤"
+- 恢复操作曾因人工失误导致二次事故
+
+---
+
+## 反模式 6: 无 Runbook (No Runbook)
+
+### 描述
+
+团队没有标准化的操作手册（Runbook），事故响应完全依赖工程师的个人经验和临场判断。新人面对事故束手无策，老人在凌晨 3 点边回忆边操作。
+
+### 危害
+
+- 新人 On-Call 时响应效率极低，MTTR 成倍增长
+- 同一类型的事故，不同人的处理方式和质量天差地别
+- 知识传承断层，人员变动后团队能力大幅下降
+- On-Call 轮值时心理压力大，不敢接收告警
+
+### 错误做法
+
+```
+# BAD: 没有 Runbook 的事故响应
+03:00 PagerDuty 告警: 数据库连接数飙升
+On-Call 新人: "我该怎么办？"
+→ 翻 Slack 历史消息找类似案例
+→ 搜索内部 Wiki 但什么都找不到
+→ 打电话把老同事叫醒
+→ 老同事凭记忆指导操作
+→ 40 分钟后恢复（其中 25 分钟在找人和找方法）
+```
+
+### 正确做法
+
+```markdown
+# GOOD: 标准化 Runbook 示例
+## Runbook: 数据库连接数异常
+
+### 触发条件
+- 数据库活跃连接数 > 80% 最大连接数
+- 应用层连接池等待队列 > 100
+
+### 快速诊断（2 分钟内完成）
+1. 查看当前连接数: `SELECT count(*) FROM pg_stat_activity;`
+2. 查看连接来源: `SELECT client_addr, count(*) FROM pg_stat_activity GROUP BY 1 ORDER BY 2 DESC;`
+3. 查看长事务: `SELECT pid, now()-xact_start, query FROM pg_stat_activity WHERE state='active' ORDER BY 2 DESC LIMIT 10;`
+
+### 恢复步骤
+**场景 A: 慢查询导致**
+1. Kill 超过 5 分钟的查询: `SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state='active' AND now()-xact_start > interval '5 minutes';`
+2. 验证连接数回落
+3. 记录被 Kill 的查询，创建优化 Issue
+
+**场景 B: 连接泄漏**
+1. 滚动重启应用实例（每次 1 个）
+2. 验证连接数回落
+3. 排查应用代码中的连接泄漏
+
+**场景 C: 流量暴增**
+1. 临时调大数据库最大连接数
+2. 启用应用层连接池排队
+3. 评估是否需要只读副本分流
+
+### 升级条件
+- 以上步骤 15 分钟内未恢复 → 升级到 P1
+- 数据库主节点不可用 → 立即升级到 P0
+```
+
+### 检测信号
+
+- 搜索内部文档找不到"Runbook"关键字
+- On-Call 交接时靠口头说明
+- 新人首次 On-Call 后说"完全不知道该怎么办"
+- 相同告警每次的处理步骤都不一样
+
+---
+
+## 反模式 7: 信息孤岛 (Information Silos)
+
+### 描述
+
+事故响应过程中，关键信息分散在不同的渠道和团队中，沟通不畅导致重复排查、遗漏关键线索、决策延迟。
+
+### 危害
+
+- 多个团队在排查同一个根因但互不知情
+- 关键信息延迟传递，影响决策效率
+- 事故后无法还原完整时间线
+- 跨团队协作效率低下
+
+### 错误做法
+
+```
+# BAD: 信息分散在多个渠道
+- 前端团队在 #frontend 频道讨论 "页面加载超时"
+- 后端团队在 #backend 频道讨论 "API 响应慢"
+- DBA 在私聊中讨论 "数据库负载高"
+- SRE 在 #ops 频道讨论 "网络延迟异常"
+- 没有人知道这些其实是同一个事故的不同表现
+- 经理在 30 分钟后才知道有事故发生
+```
+
+### 正确做法
+
+```
+# GOOD: 集中化的事故沟通
+1. 事故确认后立即创建专用频道 #incident-2024-0042
+2. 所有相关讨论集中在该频道
+3. Incident Commander 每 10 分钟发布状态更新：
+   - 当前状态（排查中/已定位/恢复中/已恢复）
+   - 影响范围
+   - 当前假设和排查方向
+   - 需要哪些团队协助
+4. 自动同步到状态页面，用户可自行查看
+5. 事故结束后频道归档，作为复盘材料
+```
+
+### 检测信号
+
+- 事故响应时需要在 3 个以上频道同时沟通
+- 有人说"我不知道已经在处理了"
+- 事后发现某个团队早就知道根因但没传递
+- 管理层通过非正式渠道才知道有事故
+
+---
+
+## 反模式 8: 过度升级 (Over-Escalation)
+
+### 描述
+
+团队对事故等级判断失准，将普通问题升级为 P0/P1 事故，或者每次告警都全员群发，导致高层和专家资源被频繁打扰，真正的重大事故反而无法得到足够关注。
+
+### 危害
+
+- 高级工程师和管理层被频繁打断，影响正常工作
+- "狼来了"效应：真正的 P0 事故时大家反应迟钝
+- 团队形成"什么事都升级"的依赖心态，不愿自主决策
+- 事故等级通胀，P0 数量远超合理范围
+
+### 错误做法
+
+```
+# BAD: 过度升级的告警配置
+告警 → 立即通知 CTO + 全部总监 + 全部 Tech Lead + 全部 SRE
+→ CTO 每天收到 10 条事故通知
+→ CTO 开始忽略通知
+→ 真正的 P0 事故来了，CTO 没看到通知
+
+# BAD: 模糊的升级标准
+"如果你不确定，就升级到 P0" → 一切都是 P0
+```
+
+### 正确做法
+
+```markdown
+# GOOD: 清晰的事故分级和升级标准
+
+## 事故分级定义
+| 等级 | 定义 | 示例 | 通知范围 |
+|------|------|------|----------|
+| P0 | 核心业务完全不可用 | 全站宕机/支付系统崩溃/数据泄露 | Incident Commander + SRE + VP |
+| P1 | 核心业务严重受损 | 部分用户无法下单/API 错误率>5% | Incident Commander + SRE |
+| P2 | 非核心功能异常 | 搜索推荐异常/报表延迟 | On-Call + 对应团队 |
+| P3 | 轻微异常或预警 | 单节点故障（已自动恢复）/容量预警 | Slack 通知 |
+
+## 升级规则
+- On-Call 工程师 15 分钟内无法恢复 P2 → 升级为 P1
+- P1 事故 30 分钟内无法恢复 → 升级为 P0
+- 影响范围扩大到其他业务 → 提升一个等级
+- 不确定等级时，先按 P2 处理，10 分钟内评估是否升级
+```
+
+### 检测信号
+
+- 月均 P0 事故 > 5 次（健康范围: 0-2 次/月）
+- 超过 50% 的 P0 事故降级后实际是 P2/P3
+- CTO/VP 每周被事故通知打扰 > 3 次
+- On-Call 工程师的第一反应总是"先升级再说"
+
+---
+
+## Agent Checklist
+
+- [ ] 对照本文档评估团队当前的事故管理成熟度
+- [ ] 识别出存在的反模式并按危害程度排定优先级
+- [ ] 每个反模式制定改进计划（90 天内可落地的措施）
+- [ ] 建立定期回顾机制（季度），检查反模式是否复发
+- [ ] 将本文档纳入 SRE/On-Call 新人培训必读材料
+- [ ] 告警噪声比（无需处理的告警 / 总告警）定期统计并优化

package/incident/05-cases/case-cascade-failure.md

@@ -0,0 +1,176 @@
+---
+id: case-cascade-failure
+title: 级联故障案例：一个服务超时引发全站雪崩
+domain: incident
+category: 05-cases
+difficulty: intermediate
+tags: [agent, cascade, case, checklist, failure, incident, whys, 关键教训]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 级联故障案例：一个服务超时引发全站雪崩
+
+## 概述
+
+2024 年 3 月某电商平台大促期间，商品推荐服务的一次慢查询导致级联故障，
+最终造成全站不可用 47 分钟，直接经济损失约 ¥380 万。本案例复盘完整故障
+链条、应急响应过程和事后改进措施。
+
+## 系统背景
+
+```
+用户请求 → Nginx → API Gateway → 商品服务 → [推荐服务, 库存服务, 价格服务]
+                                              ↓
+                                         推荐服务 → Redis 缓存 → 推荐引擎（ML 模型）
+```
+
+- 商品详情页同步调用推荐服务获取"猜你喜欢"
+- 推荐服务连接池大小: 200，超时设置: 5s
+- API Gateway 到商品服务超时: 10s
+- 日常 QPS: 商品服务 8,000，推荐服务 3,000
+
+## 故障时间线
+
+### T+0min - 触发点
+
+```
+14:00 大促开始，流量从 8,000 QPS 飙升至 25,000 QPS
+14:03 推荐引擎 ML 模型推理延迟从 50ms 上升至 800ms
+      根因：模型服务未扩容，GPU 利用率 100%
+```
+
+### T+5min - 第一级扩散
+
+```
+14:05 推荐服务响应时间从 100ms 上升至 4.5s
+      Redis 缓存命中率从 85% 降至 30%（大促新品未预热）
+14:06 推荐服务线程池耗尽（200 线程全部阻塞在 ML 调用）
+14:07 推荐服务开始返回超时错误，但商品服务仍在等待
+```
+
+### T+10min - 第二级扩散
+
+```
+14:10 商品服务线程池开始积压
+      每个请求等待推荐服务 5s 超时才能释放
+      有效并发从 500 降至 50
+14:12 商品服务响应时间从 200ms 飙升至 8s
+14:13 API Gateway 到商品服务开始超时（10s 限制）
+14:14 API Gateway 连接池耗尽
+```
+
+### T+15min - 全站雪崩
+
+```
+14:15 API Gateway 无法处理任何请求
+      影响范围从商品详情扩展到搜索、购物车、订单等所有服务
+      原因：所有服务共享同一个 API Gateway 实例
+14:17 Nginx 502 错误率达到 98%
+14:18 全站不可用
+```
+
+### T+20min - 告警与响应
+
+```
+14:20 P0 告警触发（全站可用性 < 10%）
+14:22 On-Call 工程师接入，开始排查
+14:25 初步判断为推荐服务问题，但不确定根因
+14:30 事故指挥官到位，拉起 War Room
+```
+
+### T+35min - 定位与恢复
+
+```
+14:35 确认根因：推荐服务超时拖垮整条链路
+14:37 决策：降级推荐服务（返回静态推荐列表）
+14:40 Feature Flag 关闭推荐服务实时调用
+14:42 商品服务线程池开始释放
+14:45 API Gateway 恢复，全站开始恢复
+14:47 全站可用性恢复至 99%
+```
+
+## 根因分析（5 Whys）
+
+```
+为什么全站挂了？
+  → API Gateway 连接池耗尽，所有服务不可达
+
+为什么 API Gateway 连接池耗尽？
+  → 商品服务响应极慢，连接无法释放
+
+为什么商品服务响应极慢？
+  → 同步等待推荐服务 5s 超时
+
+为什么推荐服务超时？
+  → ML 模型推理延迟 + 缓存未预热
+
+为什么没有熔断和降级？
+  → 推荐服务被视为"非核心"但以同步方式嵌入核心链路，
+    且未配置熔断器
+```
+
+## 故障链条图
+
+```
+[ML 模型未扩容]
+       ↓
+[推荐引擎延迟 800ms]
+       ↓
+[Redis 缓存未预热, 命中率 30%] → [推荐服务线程池耗尽]
+                                          ↓
+                              [商品服务等待超时, 线程积压]
+                                          ↓
+                              [API Gateway 连接池耗尽]
+                                          ↓
+                              [全站所有服务不可用]
+```
+
+## 改进措施
+
+### 立即修复（1 周内）
+
+| 措施 | 说明 |
+|------|------|
+| 推荐服务熔断器 | Hystrix/Sentinel，失败率 > 50% 自动熔断 |
+| 超时缩短 | 推荐服务超时从 5s 改为 500ms |
+| 异步降级 | 推荐调用改为异步，超时返回静态列表 |
+| 缓存预热 | 大促前 2 小时自动预热热门商品推荐缓存 |
+
+### 中期改进（1 个月内）
+
+| 措施 | 说明 |
+|------|------|
+| 服务隔离 | 核心服务（商品/订单/支付）与非核心服务独立 Gateway |
+| 舱壁模式 | 每个下游服务独立线程池，互不影响 |
+| 限流分级 | 核心接口保障带宽，非核心接口可降级 |
+| 压测常态化 | 每月全链路压测，验证容量和降级策略 |
+
+### 长期改进（3 个月内）
+
+| 措施 | 说明 |
+|------|------|
+| 服务网格 | Istio 统一管理超时/重试/熔断策略 |
+| 混沌工程 | 定期注入故障验证系统韧性 |
+| 容量规划 | 基于流量模型自动扩容，大促前自动预扩 |
+| SLO 体系 | 每个服务定义 SLO，用 Error Budget 驱动决策 |
+
+## 关键教训
+
+1. **非核心服务不要同步阻塞核心链路**: 推荐、广告等非核心功能必须异步或设极短超时
+2. **超时设置必须端到端校验**: 下游 5s + 上游 10s = 用户等 10s，这是不可接受的
+3. **共享基础设施是最大的单点**: 所有服务共用一个 Gateway，一个服务拖垮全部
+4. **熔断不是可选项**: 任何远程调用都必须有熔断保护
+5. **缓存预热是大促必选动作**: 冷缓存在流量高峰下是定时炸弹
+6. **告警到人太晚**: 从雪崩到告警花了 5 分钟，应在第一级扩散时就告警
+
+## Agent Checklist
+
+- [ ] 核心链路是否有非核心服务的同步依赖
+- [ ] 所有远程调用是否配置了合理超时（建议 < 1s）
+- [ ] 熔断器是否已对所有下游服务配置
+- [ ] 舱壁模式（独立线程池/连接池）是否已实施
+- [ ] API Gateway 是否做了核心/非核心服务隔离
+- [ ] 缓存预热机制是否就绪
+- [ ] 降级策略是否已定义且可通过 Feature Flag 快速启用
+- [ ] 全链路压测是否覆盖了级联故障场景
+- [ ] 告警阈值是否能在第一级扩散时触发