| name | ship-workflow-canary |
| description | 发布后健康监控。当代码已部署需要持续验证生产健康，或提到"金丝雀""canary""监控""健康检查" |
docs/features/<name>/06-canary-report.md06-canary-report.md → reflect-team-retro/retro部署前（或部署后立即）采集健康基线：
# 对每个关键端点采集基线
for endpoint in /health /api/status /api/readyz; do
echo "--- $endpoint ---"
start=$(date +%s%N)
status=$(curl -s -o /dev/null -w '%{http_code}' "https://${HOST}${endpoint}")
end=$(date +%s%N)
elapsed=$(( (end - start) / 1000000 ))
body_hash=$(curl -s "https://${HOST}${endpoint}" | shasum -a 256 | cut -d' ' -f1)
echo "{\"endpoint\":\"$endpoint\",\"status\":$status,\"response_ms\":$elapsed,\"body_hash\":\"$body_hash\"}"
done
输出 baseline.json：
{
"collected_at": "2025-01-15T10:00:00Z",
"endpoints": [
{
"endpoint": "/health",
"status_code": 200,
"response_ms": 45,
"body_hash": "a1b2c3..."
}
]
}
基线规则：
每 60 秒轮询端点，比对基线：
# 单次检查脚本
check_endpoint() {
local endpoint=$1 baseline_status=$2 baseline_ms=$3
local start status elapsed
start=$(date +%s%N)
status=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "https://${HOST}${endpoint}")
end=$(date +%s%N)
elapsed=$(( (end - start) / 1000000 ))
# 分级判定
if [ "$status" = "000" ]; then
echo "CRITICAL|$endpoint|不可达"
elif [ "$status" != "$baseline_status" ] && [ "$status" -ge 500 ]; then
echo "CRITICAL|$endpoint|新5xx:$status"
elif [ "$status" != "$baseline_status" ] && [ "$status" -ge 400 ]; then
echo "HIGH|$endpoint|新错误码:$status(基线:$baseline_status)"
elif [ "$elapsed" -gt $((baseline_ms * 2)) ]; then
echo "MEDIUM|$endpoint|响应时间${elapsed}ms>2x基线${baseline_ms}ms"
elif [ "$status" != "$baseline_status" ] && [ "$status" -ge 300 ]; then
echo "LOW|$endpoint|新重定向:$status(基线:$baseline_status)"
else
echo "OK|$endpoint|status=$status time=${elapsed}ms"
fi
}
告警分级：
| 级别 | 条件 | 含义 |
|---|---|---|
| CRITICAL | 端点不可达（curl 超时/连接拒绝） | 服务挂了 |
| HIGH | 新的 4xx/5xx 错误码 | 功能损坏 |
| MEDIUM | 响应时间 > 2x 基线 | 性能退化 |
| LOW | 新的重定向 | 可能的配置变更 |
防抖规则： 连续 2+ 次检测到同一级别异常才触发告警。单次异常记录为 TRANSIENT，不告警。
监控持续时间：
监控结束后生成端点健康状态摘要：
| 状态 | 定义 |
|---|---|
| HEALTHY | 全部检查 OK，无 TRANSIENT |
| DEGRADED | 有 LOW/MEDIUM 级别异常，但无 HIGH/CRITICAL |
| BROKEN | 有 HIGH/CRITICAL 级别异常 |
输出 docs/features/<name>/06-canary-report.md：
# Canary Report — <name>
## Canary Summary
- Owner:
- Date:
- Monitoring window:
- Change size: small / standard / major
- Result: HEALTHY / DEGRADED / BROKEN
- Decision: continue / pause / rollback
- Ship source: `docs/features/<name>/05-ship.md`
## Canary Scope
- Environment / region / ring:
- Canary population / traffic percentage:
- Version / commit / artifact:
- Critical user journeys:
- Out of scope:
## Baseline
- Baseline source:
- Baseline collected at:
- Endpoint count:
- Samples per endpoint:
- Baseline owner:
## 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: HEALTHY / DEGRADED / BROKEN
- Decision: continue / pause / rollback
- Decision reason:
- Decision owner:
- Decision time:
## Baseline Update
- Updated: yes / no
- Reason:
- Previous baseline archived at:
## Follow-up
- Owner:
- Tracking:
- Next check:
- Next command: `/retro` / continue monitoring / rollback / investigate
当所有端点均为 HEALTHY 时，可选更新基线：
# 用最新数据覆盖 baseline.json
mv current-round.json baseline.json
规则：
baseline-$(date +%Y%m%d).json输出或记录必须包含：
| 说辞 | 现实 | 后果 |
|---|---|---|
| "部署完就没事了" | 部署只是上线的一半。上线后第一个小时的监控决定用户是否受影响。 | 不监控的上线：故障平均 15 分钟由用户投诉发现，影响 100+ 用户，信任损失修复需 1-2 周。 |
| "不需要基线，看日志就行" | 日志告诉你"发生了什么"，基线告诉你"这正不正常"。没有基线，所有数据都是噪声。 | 无基线监控：每次告警需 20-40 分钟人工判断是否正常，MTTR 从 5 分钟延长到 45+ 分钟。 |
| "60 秒检查太频繁了" | 60 秒能在 2 分钟内发现故障（防抖后）。用户发现故障平均需要 15 分钟。 | 5 分钟间隔检查：故障检测延迟从 2 分钟增加到 10+ 分钟，每分钟影响 50-200 活跃用户。 |
| "出问题再看" | 出问题时你已经损失了用户。主动监控把发现时间从"用户投诉"缩短到"分钟级"。 | 被动等待投诉：故障暴露延迟 30-60 分钟，客户流失率提升 3-5%，每次事故直接损失 ¥5K-¥50K。 |
| "只要 200 就行" | 200 但响应时间从 50ms 涨到 5000ms = 用户已经无法使用。Status code 不是健康的全部。 | 只看 status code：慢响应 5 秒的用户体验等同于服务中断，转化率下降 20-40%，10% 用户直接离开。 |
Canary 结果: 所有端点返回 200，部署成功。
问题：没有基线对比、没有响应时间数据、没有异常详情。200 可能伴随 10x 响应时间退化。
Canary Report — payment-v2
## 摘要
- 监控时长: 2 小时
- 检查次数: 120
- 结果: DEGRADED
## 端点状态
| 端点 | 状态 | 基线响应 | 平均响应 | 异常次数 |
|------|------|---------|---------|---------|
| /health | HEALTHY | 45ms | 48ms | 0 |
| /api/payments/process | DEGRADED | 320ms | 780ms | 8 (MEDIUM) |
## 异常详情
- 14:05 /api/payments/process 响应 780ms (2.4x 基线 320ms)
- 14:06 /api/payments/process 响应 810ms (2.5x 基线)
- 连续 8 次超过 2x 基线，防抖确认 MEDIUM
## 建议
- /health HEALTHY → 可更新基线
- /api/payments/process DEGRADED → 继续监控 30 分钟，排查支付服务慢查询
- 如 30 分钟后仍 DEGRADED → 建议回滚
优点：有基线对比、量化退化程度、防抖确认、明确下一步行动。
模板起点：templates/feature/06-canary-report.md
# <Feature Name> — Canary Report
## 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 决定是否继续或回滚 |
结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比，或提到"脑暴""想法""方案对比""怎么办"
恢复保存的工作上下文。当新 session 需要继续之前的工作，或提到"恢复""restore""继续上次"
保存工作上下文。当需要保存当前工作状态供后续 session 恢复，或提到"保存""save""checkpoint""挂起"
架构决策记录（ADR）。当面临技术选型、架构决策、方案取舍需要记录，或提到"ADR""决策记录""为什么这样做"
发布或导出检查 → Go/No-Go → 归档。当审查通过后需要上线或交付最终产物，或提到"发布""上线""ship""Go/No-Go"
合并 PR → 等待 CI → 验证生产。当 PR 已创建需要合并到主分支并验证部署，或提到"合并""merge""PR""land"