Ops Triage

上下游

• 前接：线上报错、告警、用户工单、客户反馈。
• 后接：本地能稳定复现的单个 bug 交 diagnosing-bugs；修复上线走 ship。
• 写入：服务器地址、日志位置、查询方式、管理接口 → 持久规则。

1. 取证

• 访问方式先在本机找：~/.ssh/config、持久规则里的服务器记录、部署脚本、项目的管理 API。
• 取一个时间窗口内的全部信号：错误日志、告警、工单、遥测。只看一条报错容易误判。
• 查询用只读语句。写操作按第 4 节。
• 用户给出的根因猜测和业务事实是第一假设，用证据坐实或排除。

2. 归类

按错误类型聚合，每类记录：条数、影响用户数、首次出现时间、对应哪次部署。再判断来源：

• 代码缺陷；
• 上游或第三方故障；
• 用户操作或配置；
• 噪音：不影响用户、可以降级或去重的告警。

客户反馈可能是误报，先确认问题真实存在。

3. 处理

• 止血优先：正在影响用户时，先回滚、关开关或修正数据，再修代码。
• 根因明确：修复根因，并搜索同类代码一起修。重试、静默兜底、屏蔽报错都只是掩盖。
• 根因不明：补带唯一前缀的诊断日志随下一版上线，记下待验证的假设。
• 噪音：降级日志级别或去重限频，写明理由。
• 有工单或告警系统的接口时，处理完标记状态。

4. 生产写操作

• 改数据：先 SELECT 出影响范围并备份这些行，在事务里执行，核对行数后再提交。
• 涉及资金或批量对外的操作：先试跑或小范围执行，确认后再放量。
• 从服务器测试上游 API：走服务器上配置的代理。
• 改服务器或网络配置：先备份原配置，网络类改动先准备好恢复脚本。

完成判据

归类表里每一类都有处置：已修复（附提交）、已补日志（附待验证假设）、已降噪（附理由）、需用户决策（附推荐）。汇报就用这张表。