接手事件
从通知中打开事件，或打开 告警 → 告警事件 的 等待确认 标签页。在确认超时之前点击 确认。确认会停止升级，并向打开事件的每个人显示负责人，避免其他人同时做重复的工作。 多个事件由同一个原因引起时，确认最能说明原因的那一个，并在处理期间静默其余事件。被语义分组收到一起的事件可以通过 API 一起确认。评估影响
在做任何改动之前，先阅读事件详情：
查看受影响服务的 SLO：燃烧率高意味着客户此刻就能感受到问题。
尽早通知客户
客户受到影响时，在原因查明之前就发布一个状态页事件：- 以草稿创建事件，选择受影响的组件及其影响程度。
- 以 调查中 状态发布第一条更新：客户看到了什么，以及下一次更新的时间。
- 每次状态变化都追加一条更新：已确认、监控中、已解决。已发布的更新永远不会被修改，只能被新的更新接续。
定位原因
保持事件的时间窗口，从症状一路追到原因：- 打开触发查询 重放触发事件的查询，相关日志 和 相关指标 打开它周边的上下文。日志、链路、指标和会话之间的跳转参见跨信号关联。
- 查找最近的变更：服务的发布时间线，以及应用性能发现附近的变更。
- 阅读 AI 根因，或点击 生成。把它当作需要验证的线索，并评价为 有帮助 或 没帮助。
- 在服务页上用 调查 向 Mole Agent 提问，它会把服务健康、上下游和发现附加到对话中。
先止血，再恢复
优先选择最快且安全的止血手段，例如回滚或关闭功能开关，而不是在压力下修复。止血之后：- 观察触发查询恢复正常。规则满足恢复条件时，打开的事件会自动解决；已确认的事件需要有人点击 解决。
- 只是在重复已知问题的相关事件，用静默单个事件屏蔽，而不是静默规则本身。
- 把状态页更新为 监控中，服务稳定一段时间后再更新为 已解决。
总结经验
几天之内在状态页事件上撰写复盘：发生了什么、影响、时间线、原因，以及后续的改进。评审期间保存为草稿，事件解决后再发布。Mole Agent 可以根据事件记录起草复盘。 然后用洞察改进检测：快速恢复事件 和 主要触发规则 指向噪声规则，通知来得太晚则说明缺少规则或规则太慢。参见让生产告警能够指导响应。验收标准
- 每个事件都在确认超时之内有了负责人。
- 面向客户的事件，客户在发问之前就从状态页得知了情况。
- 复盘写明了原因、影响、时间线，以及每项后续工作的负责人。
- 每项改进检测的后续工作都是一条具体的规则改动，并已在真实数据上测试。