Canary — 发布后健康监控
用途
该技能用于代码部署之后的持续生产健康验证，通过采集基线、循环监控端点、生成健康报告并视情况更新基线，判断发布结果并给出继续、暂停或回滚的决策记录。
入口与出口
- 入口：通过 review 且已部署的代码。
- 出口：docs/features/<name>/06-canary-report.md。
- 输出路径：06-canary-report.md → reflect-team-retro。
- 指向：监控稳定后建议 /retro。
- 前置加载：CANOR.md（原文写作 CANOR.md）。
何时不使用
- 代码尚未部署，仍在 review/ship/deploy 前。
- 没有生产或可观测环境可验证。
- 只是本地 smoke test 或一次性手动检查。
流程
Phase 1：基线采集
部署前（或部署后立即）采集健康基线。文中给出对每个关键端点采集基线的 shell 示例（/health、/api/status、/api/readyz），记录 status code、response_ms 与 body_hash，并汇总为 baseline.json，字段包括 collected_at 和 endpoints 数组（endpoint、status_code、response_ms、body_hash）。
基线规则：
- 每个端点至少采集 3 次，取中位数。
- 记录 status code + response time + body hash。
- 基线采集失败 = 阻塞。不能在不知道"正常是什么样"的情况下开始监控。
Phase 2：循环监控
每 60 秒轮询端点，比对基线。文中提供 check_endpoint 的 shell 示例，分级判定逻辑包括：curl 状态为 000 视为不可达；与基线不同且 >=500 为新 5xx；与基线不同且 >=400 为新错误码；响应时间超过基线 2 倍；与基线不同且 >=300 为新重定向；否则为 OK。
告警分级：
- CRITICAL：端点不可达（curl 超时/连接拒绝），含义为服务挂了。
- HIGH：新的 4xx/5xx 错误码，含义为功能损坏。
- MEDIUM：响应时间 > 2x 基线，含义为性能退化。
- LOW：新的重定向，含义为可能的配置变更。
防抖规则：连续 2+ 次检测到同一级别异常才触发告警。单次异常记录为 TRANSIENT，不告警。
监控持续时间：
- 小型变更：30 分钟。
- 标准变更：2 小时。
- 重大变更（核心路径/数据库 migration）：24 小时。
Phase 3：健康报告
监控结束后生成端点健康状态摘要：
- HEALTHY：全部检查 OK，无 TRANSIENT。
- DEGRADED：有 LOW/MEDIUM 级别异常，但无 HIGH/CRITICAL。
- BROKEN：有 HIGH/CRITICAL 级别异常。
输出 docs/features/<name>/06-canary-report.md，报告包含以下小节：Canary Summary（Owner、Date、Monitoring window、Change size、Result、Decision、Ship source 等）、Canary Scope（环境/区域/ring、金丝雀人群/流量百分比、版本/commit/产物、关键用户旅程、范围外内容）、Baseline（基线来源、采集时间、端点数、每端点样本数、基线负责人）、Health Signals 表格（Signal、Source、Baseline、Current、Threshold、Status）、Endpoint Status 表格（Endpoint、Status、Baseline Response、Current / Average Response、Error Count、Notes）、Analysis Policy（Interval、Count / duration、Failure threshold、Debounce rule、Promotion rule、Rollback rule）、Anomalies 表格（Time、Signal / Endpoint、Severity、Evidence、Action）、Decision（Final status、Decision、Decision reason、Decision owner、Decision time）、Baseline Update（Updated、Reason、Previous baseline archived at）、Follow-up（Owner、Tracking、Next check、Next command：/retro / continue monitoring / rollback / investigate）。
Phase 4：基线更新
当所有端点均为 HEALTHY 时，可选更新基线（示例为用最新数据覆盖 baseline.json）。规则：
- 只有全部端点 HEALTHY 才更新。
- DEGRADED 或 BROKEN 时不更新——基线代表"已知良好状态"。
- 更新前保存旧基线为 baseline-$(date +%Y%m%d).json。
验证证据
输出或记录必须包含：输入/来源、执行动作、验证结果、阻塞/回退。
常见说辞与对应现实
文中列举了若干常见说辞，如"部署完就没事了""不需要基线，看日志就行""60 秒检查太频繁了""出问题再看""只要 200 就行"，并给出相应现实与后果说明。这些内容属于该技能文档中的论述素材。
红旗
- 没有基线就开始监控。
- 只检查 status code 不检查响应时间。
- 单次异常就告警（没有防抖）。
- 监控 5 分钟就宣布"稳定"。
- 基线采集失败但仍然继续部署。
- BROKEN 状态但没有触发回滚。
- 监控期间无人值守（重大变更的 24 小时监控需要 oncall）。
- 关键业务端点不在监控列表中。
好/坏示例
坏示例：只看 status code，结论为所有端点返回 200、部署成功，但缺少基线对比、响应时间数据与异常详情。 好示例：证据驱动的 canary 报告（payment-v2），包含监控时长、检查次数、结果 DEGRADED、端点状态表、异常详情（连续 8 次超过 2x 基线，防抖确认 MEDIUM）与建议（HEALTHY 可更新基线、DEGRADED 继续监控 30 分钟排查、仍 DEGRADED 建议回滚）。
输出模板
模板起点：templates/feature/06-canary-report.md，小节包括 Canary Summary、Canary Scope、Baseline、Health Signals、Endpoint Status、Analysis Policy、Anomalies、Decision、Baseline Update、Follow-up。
验证失败处理
- 基线采集失败（端点不可达）：阻塞部署，修复端点或排除后重新采集，不得在没有基线的情况下开始监控。
- 连续 2+ 次 CRITICAL 告警：立即触发回滚，按回滚计划执行，通知 human partner。
- 响应时间 >2x 基线持续 10 分钟：降级为 DEGRADED，继续监控 30 分钟；若持续退化则建议回滚。
- 监控 30 分钟内出现 TRANSIENT >5 次：延长监控至 2 小时，排查抖动根因，不宣布 HEALTHY。
- 监控结束时仍有 DEGRADED 端点：不更新基线，输出报告中标注退化端点，建议 human partner 决定是否继续或回滚。
验证清单
包括：baseline.json 已采集（至少 3 次取中位数）；Canary Scope 已写清环境、ring、流量比例、版本和关键用户路径；Health Signals 已覆盖可用性、延迟、错误率和必要业务信号；Analysis Policy 已写清 interval、count/duration、failure threshold、防抖、promotion 和 rollback 规则；所有关键端点在监控列表中；防抖机制生效（连续 2+ 次才告警）；监控持续时间与变更规模匹配；06-canary-report.md 已生成；Decision 已记录 continue / pause / rollback 及 owner；Follow-up 已记录下一步和 tracking；所有端点状态为 HEALTHY（或 DEGRADED/BROKEN 有对应行动）；HEALTHY 端点基线已更新。