用途：面向生产环境延迟升高、错误率上升等事件的分诊 runbook，供 SRE 团队按固定顺序排查问题。
主要能力：规定了操作顺序与判断依据，帮助排查者先确认是否为发布引入，再定位其他原因，并统一总结写法。
使用方式：
- 先拉取最近 6 小时的发布记录，不要先打开日志。
- 将发布时间戳与受影响服务的 p99_latency_ms / error_rate 对齐，明确时间差（例如“deploy 14:31，p99 在 14:33 变化”）。
- 若有发布吻合：拉取 diff 并阅读，检查后续列出的常见问题，再用 grep 日志确认，不要盲目 grep。
- 若无发布吻合：检查 checkout/cart/auth/inventory 的 db_pool_utilization，然后检查上游依赖。
- 总结时在底部写一行：“Root cause: <sha> — 一句机制说明”。若不是发布导致，则用组件或上游依赖名代替 sha（如 db-primary、stripe-api），仍为一句。该行以上为证据，保持简短，长版本写入事后复盘文档。
常见致因（按出现频率大致排序）：原本批量的查询被改为逐行查询；缓存装饰器被“临时”移除；新增查询未加索引；在异步处理器中存在阻塞调用；无退避的重试循环。
限制：资料未提供适用平台、命令安装方式、收费信息或版本要求；若需调整上述顺序，须在 #sre 说明理由。