SQL による顧客影響分析
内部エラー率は顧客への影響を確立するものではありません。インシデント対応には、チェックアウトの失敗、エクスポートの遅延、データの利用不可、または顧客が経験する可能性のあるその他の制御された影響など、製品の結果を文書化する必要があります。
1 つの影響行を定義する
インシデントおよび承認されたレポート単位ごとに 1 つの境界付き行を出力または導出します。有用なフィールドには次のものがあります。 incident_id、仮名 account_id、プランまたはサービス層、制御 impact_type, affected, impact_duration_ms、環境、および UTC 時間。
影響を受ける母集団と同様に、評価された母集団も保持します。結合で影響を受けるアカウントのみが見つかった場合、結果として得られるパーセンテージには信頼できる分母がありません。顧客名、電子メール、リクエスト本文、サポート メッセージ、および生のコンテンツを集計テーブルに含めないでください。アカウントレベルのドリルダウンを承認された回答者に制限します。
インシデントの範囲を調べる
の 顧客への影響 SQL レシピ 評価されたアカウントと影響を受けたアカウントを計画ごとにカウントし、影響を受けた割合を計算し、影響を受けた行のみの期間を平均します。このフィクスチャには、影響を受けた 3 つのエンタープライズ アカウントと、影響を受けた 2 つのスターター アカウントが表示されます。
サービスレベルの検出後にクエリを使用します。
- インシデントの開始と影響を受けた製品の結果を確認します。
- 同じ完全なウィンドウに対して評価されたアカウント母集団を構築します。
- 計画、地域、ルート、または別のレビュー済みの境界ディメンションごとに影響を比較します。
- 新たに影響を受けたアカウントと回復したアカウントを別のフローとして追跡します。
- クエリ、定義、結果をインシデント レコードに保存します。
承認された対応方針なしに、より高度な計画をより高い人的影響と同一視しないでください。計画は優先事項の 1 つであり、契約上の要件や安全要件に代わるものではありません。
回復の確認
回復とは、顧客に表示されるワークフローが再び成功し、遅延した再試行またはジョブが枯渇したことを意味します。ロールバックのタイムスタンプだけでは証拠になりません。引き続き完全なバケットを監視し、リクエスト量が消えていないことを確認してください。
の incident_impact_observed イベントスキーマ フィールドレベルの開始契約を提供します。の インシデント対応ガイド 検出、ルートおよびリリースの範囲設定、タイムライン、および回復について説明します。の API の信頼性の使用例 影響分析を提供できる広範な測定戦略を提供します。