使用 SQL 响应故障
当响应者以相同的顺序回答相同的问题时，事件响应会更快：更改何时开始、哪些用户和工作流程受到影响、发生了什么变化以及系统是否已恢复？结构化事件保留了这些维度，因此您可以从广泛的信号转移到可防御的时间线，而无需搜索非结构化消息。
从广泛开始，然后保留路线并发布可以解释变化的维度。
从有界信号开始
选择一个稳定的完成事件，例如 api_request_completed，然后比较完整的五分钟桶。将路由模板、发布标识符、状态、错误类别和安全帐户标识符保留为单独的字段。
SELECT
date_bin(INTERVAL '5 minutes', timestamp_utc, TIMESTAMP '1970-01-01') AS bucket,
COUNT(*) AS requests,
100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_request_events
WHERE timestamp_utc >= now() - INTERVAL '2 hours'
GROUP BY bucket
ORDER BY bucket;
不要从一个小容量的存储桶中声明事件。将费率与请求量以及该服务的运营目标进行比较。
范围受影响的路线和发布
一旦开始时间明确，保留可以解释变化的维度。按路由和发布进行分组，保留最小数量阈值，并按失败请求和比率进行排名。
SELECT
route_template,
release,
COUNT(*) AS requests,
SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failed_requests,
100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_request_events
WHERE timestamp_utc >= now() - INTERVAL '30 minutes'
GROUP BY route_template, release
HAVING COUNT(*) >= 20
ORDER BY failed_requests DESC, error_rate_pct DESC;
仅当该维度可以更改响应时，才使用 error_type、依赖项、区域或隐私安全帐户标识符重复查询。避免使用原始请求正文、授权标头、电子邮件和自由格式的异常文本。
建立并保存时间线
在事件日志中记录每个假设、查询、时间窗口、结果和操作。将最有用的查询保存在仪表板旁边，以便第二个响应者可以重现范围。使用准确的 UTC 时间戳标记部署、功能标记更改、依赖项故障和恢复操作。
使用 API 错误率配方 对受影响的路由进行排名，使用 发布回归配方 比较构建，并使用 错误预算燃烧配方 将事件与可用性目标联系起来。当响应者需要明确的客户影响合同时，请从 incident_impact_observed 事件模式 开始。
验证恢复情况
回滚或配置更改本身并不是恢复。等待完整的存储桶，验证错误率和延迟是否返回到预期范围，并检查流量是否没有消失。继续观察足够长的窗口以涵盖延迟的重试和后台工作。
事件发生后，将经过验证的检测查询转换为仪表板或告警，记录其最小数量和所有权，并在响应者缺乏隔离影响所需的安全字段时更新事件合同。 告警故障排除指南 解释了如何在不产生噪音的情况下测试生成的通知路径。