SQL によるインシデント対応

対応者が同じ質問に同じ順序で答えると、インシデントへの対応が速くなります。変更がいつ始まったのか、どのユーザーとワークフローが影響を受けるのか、何が変更されたのか、システムは回復したか、などです。構造化イベントではこれらの次元が保持されるため、非構造化メッセージを検索することなく、広範な信号から防御可能なタイムラインに移動できます。

境界のある信号から開始する

次のような安定した完了イベントを選択します。 api_request_completed、次に完全な 5 分間のバケットを比較します。ルート テンプレート、リリース識別子、ステータス、エラー カテゴリ、安全なアカウント識別子を別のフィールドとして保持します。

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;

1 つの低容量バケットからインシデントを宣言しないでください。レートとリクエスト量およびそのサービスの運用目標を比較します。

影響を受けるルートとリリースの範囲

開始時間が明確になったら、変化を説明できる寸法を保存します。ルートとリリースごとにグループ化し、最小ボリュームのしきい値を維持し、失敗したリクエストとレートによってランク付けします。

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、依存関係、地域、またはプライバシーに配慮したアカウント識別子は、そのディメンションが応答を変更できる場合にのみ使用されます。生のリクエスト本文、認証ヘッダー、電子メール、および自由形式の例外テキストは避けてください。

タイムラインを構築して保存する

各仮説、クエリ、時間枠、結果、およびアクションをインシデント ログに記録します。最も有用なクエリをダッシュ​​ボードの横に保存して、2 番目の応答者がスコープを再現できるようにします。デプロイ、機能フラグの変更、依存関係の失敗、および回復アクションを正確な UTC タイムスタンプでマークします。

を使用します。 API エラー率レシピ 影響を受けるルートをランク付けするには、 リリース回帰レシピ ビルドを比較するには、 エラーバジェットバーンレシピ インシデントを可用性目標に結び付けるためです。対応者が顧客に影響を与える明示的な契約が必要な場合は、まず、 incident_impact_observed イベントスキーマ.

回復の確認

ロールバックまたは構成変更は、それ自体では回復されません。バケットが完了するまで待ち、エラー率とレイテンシーが予想範囲に戻ったことを確認し、トラフィック量が消えていないことを確認します。遅延した再試行とバックグラウンド作業をカバーするのに十分な長さのウィンドウを監視し続けます。

インシデントの後、検証された検出クエリをダッシュボードまたはアラートに変換し、その最小量と所有権を文書化し、影響を分離するために必要な安全なフィールドが対応者に欠けていた場合はイベント コントラクトを更新します。の アラートのトラブルシューティング ガイド では、ノイズを発生させずに結果の通知パスをテストする方法について説明します。