IncidentRelay v2.3.1 の例は動作しており、にチェックされました。以下の名前、識別子、タイミングは一例です。本番認証情報を使用する前に、テスト展開で認証情報を検証してください。
ビジネス例 · セットアップ · 実際の例 · 受け入れチェック · 制限と障害モード
ビジネス例: オフィスが閉まった後にチェックアウトが失敗する
顧客事例ではなく、例示的なシナリオ。以下の指標はパイロットのための提案であり、節約を測定したり、IR にすべてのレポート ダッシュボードが含まれるという主張ではありません。
状況とリスク: オンライン ストアには 4 人のエンジニアがいます。 22:40 に、顧客がまだチェックアウトしている間に、監視によって支払いリクエストの失敗が検出されました。一般チャットのメッセージでは、誰が問題を処理しているのかがサポートに示されません。未完了の購入と増大するサポート待ち行列はビジネスリスクです。アラート自体は信号にすぎません。
IR を使用したワークフロー。 現在のプライマリ レスポンダに請求アラートを送信します。誰もそれを承認しない場合、ポリシーは指定されたバックアップに移動します。割り当てられたエンジニアはグループを認識し、調査します。サポートは、合意されたインシデント プロセスを使用して、その所有者を見つけて更新を取得できます。以下の障害と回復のペアを使用して、このチェーンをテストします。
検証すべき運用上のメリット。 対応可能なエンジニアを手動で検索する代わりに、事前定義された所有権チェーンを使用します。配信されたチャット メッセージが誰かがそれに取り組んでいることを意味すると考えるのではなく、引き継ぎを通じて責任を可視化してください。
測定対象: 最初のアクション可能なアラートから ACK までの時間、内部目標内で認められたシェア、および手動による再割り当ての数を記録します。失敗したチェックアウトと、コマース監視で正常な支払いが再開されるまでの時間を個別に追跡します。
境界。 IR はチェックアウトや決済プロバイダーを修復しません。 ACK は顧客が再度支払うことができることを証明するものではなく、どちらのエンジニアとも連絡が取れない場合はエスカレーション ポリシーは役に立ちません。フォールバック連絡先パスと実際の支払い回収小切手を保持します。
4 人のエンジニア、1 つの請求サービス、1 つの所有権チェーン
4 人のエンジニアが請求 API のサポートを共有するとします。 1 つのチームと週 1 回のプライマリ ローテーションから始めます。ルートにデフォルトのサービスと 1 つのテスト済み配信チャネルを与えます。バックアップ担当者を明示的に追加します。共有チャット ルームはエスカレーション ポリシーではありません。
| 物体 | UIでの設定例 |
|---|---|
| オーナーシップ | チーム payments;サービス billing-api;ローテーション payments-primary には 4 人のアクティブなメンバーと 24/7 のカバレッジが含まれます。 |
| 摂取量 | ソース webhook、デフォルト サービス billing-api、ポリシー エスカレーション モード、および接続された通知チャネル。 |
| エスカレーション | ルール 1: プライマリ ローテーション、300 秒の遅延。ルール 2: 指定されたバックアップ ユーザー、600 秒の遅延。このパイロットに repeat_count=0 を設定します。 |
アラートを送信する前に、チャネルと応答者の連絡先を設定します。 オンコール ヘルス診断全体を開きます。緑色の表の概要だけでは、将来の補償範囲をスキャンしたり、メッセージが電話に届いたことを証明したりすることはできません。
1 つの障害を送信してから、その障害を回復する
これらの JSON 本文を、Content-Type: application/json と Authorization: Bearer ROUTE_TOKEN とともに個別に POST /api/integrations/webhook に送信します。プレースホルダーを UI のテスト ルート トークンに置き換えます。ソース管理や共有ログから除外してください。これは一般的な Webhook 形式であり、正規化されたシミュレータ イベントではありません。
{
"status": "firing",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}{
"status": "resolved",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}リカバリのために同じルート、フィンガープリント、およびグループ化ラベルを保持します。フィンガープリントは子アラートを識別します。リクエストごとに新しいランダム値に変更すると、重複排除が無効になります。孤立したリカバリでは新しいグループは作成されません。
実際の夜勤の前にチェーンを証明する
- 発砲体を2回送ります。 1 つの子アラート、目的のサービス、および現在の主担当者が期待されます。 HTTP の成功だけでなく、実際の配信を確認します。
- 別のテスト アラートは未承認のままにしておきます。最初のポリシー遅延後にバックアップがターゲットになることを確認します。スケジューラーの頻度、キューイング、およびプロバイダーの配信により、これは正確な 5 分間の配信 SLA ではありません。
- 別のテスト グループを認識し、保留中の起動のみの通知が停止することを確認します。リカバリを送信し、起動した子が残っていないときにグループが解決されることを確認します。
- 一時的な回転オーバーライドを作成し、テストを繰り返します。オーバーライドが有効な割り当て先であることを確認してから、テスト構成を削除します。
チェーンがいつ停止するかを知る
ポリシー モードでは、チーム リマインダー ベースのエスカレーションは無視されます。すべてのルールと許可された繰り返しがなくなると、ポリシー リマインダーは停止します。アラートはまだ発生している可能性があります。仕事上の連絡先の詳細を持たないバックアップ担当者は、データベース内の名前にすぎません。
ACK は所有権であり、課金サービスの回収ではありません。 IR はアプリケーションを修復したり、不足しているエンジニアを補充したりすることはできません。 IR またはその通知プロバイダーが利用できない場合にチームに連絡する外部の方法を確保し、オンボーディング中にそのフォールバックについて同意します。