IncidentRelay v2.3.1 の例は動作しており、にチェックされました。以下の名前、識別子、タイミングは一例です。本番認証情報を使用する前に、テスト展開で認証情報を検証してください。
ビジネス例 · セットアップ · 実際の例 · 受け入れチェック · 制限と障害モード
ビジネス例: 3 つのクライアント システム、1 つの騒々しいサポート チャット
顧客事例ではなく、例示的なシナリオ。以下の指標はパイロットのための提案であり、節約を測定したり、IR にすべてのレポート ダッシュボードが含まれるという主張ではありません。
状況とリスク。 サービス プロバイダは 3 つのクライアントをサポートしており、それぞれにアプリケーションとインフラストラクチャのアラートが付いています。すべてが 1 つのチャットで完了します。エンジニアはメッセージを他のチームに転送する一方で、繰り返されるアラートによって元のレポートが埋もれてしまいます。ビジネス リスクは、監視によって障害がすぐに検出された場合でも、所有権の遅延と回避可能なサポート作業です。
IR を使用したワークフロー。 各クライアント サービスを担当チームにマッピングし、送信者ごとに意図されたルート トークンを使用します。環境ラベルとサービスラベルを照合し、オンコールターゲットを選択し、意図された所有権の境界内でのみ繰り返しをグループ化します。パターンを拡張する前に、以下のマッチャーを使用して 1 つのクライアントの実動課金サービスを試験的に試行します。
検証すべき運用上の利点。 日常的なメッセージ転送を明示的なルーティングに置き換えます。複数のホストが同じ問題を報告した場合は、個別の子アラートを維持しながら、行動できるチームで最初の対応を続けます。
測定対象: 最初のルーティング決定後に再割り当てされたアラート、所有者のないグループ、および各クライアントの根本的な障害ごとの通知の数をカウントします。拒否されたテスト イベントや一致しないテスト イベントも確認します。クライアントの停止が目に見えなくなると、ページ数を減らしても成功しません。
境界。 ラベル マッチングは顧客データの分離ではありません。アクセス許可、認証情報、展開境界を個別に確認してください。ラベルに一貫性がなかったり、グループ分けが広すぎたりすると、作業が間違ったチームに送信されたり、無関係な症状が結合されたりする可能性があります。別のクライアントをオンボードする前に、これらのケースを検証してください。
取り込み、所有権、配送を分離する
本番課金サービスとステージング コピーが同じユーザーを誤って起こしてはなりません。最初のパイロットでは、運用請求チームの Webhook ルートを作成し、そのデフォルトのサービスとローテーションまたはポリシーを選択し、チャネルをアタッチします。そのインテーク トークンによってルートが選択されます。ラベルの一致だけでは、送信者を認証したり、任意のルートを選択したりすることはありません。
ナロールートマッチャーと明示的なグループ化キー
これをルートのマッチャー エディターに貼り付けます。これはマッチャー オブジェクトであり、受信 Webhook 本体ではありません。すべての条件では AND セマンティクスが使用されます。プロダクション ラベルとサービス ラベルを要求すると、ステージング イベントやラベルのないイベントがこのルートから除外されます。
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}この例では、ルートの group_by フィールドを次のように設定します。
["alertname", "severity", "labels.cluster"]同じクラスター内で同じアラートを報告する 2 つのホストは、別個の子 ID を保持しながら、AlertGroup を共有できます。汎用 Webhook の場合は、billing:node-1:health や billing:node-2:health などの安定したフィンガープリントを使用します。失敗と回復に関して予期されるラベルを含め、すべての再試行の ID として新しいタイムスタンプを決して使用しないでください。
重複排除とグループ化は異なります。同じフィンガープリントによって子が更新されます。同じグループキーを持つ異なるフィンガープリントは、1 つのグループ内に別々の子を作成します。ルート、チーム、ソース、サービスのスコープのグループ化も可能です。各ホストを別個のグループにする必要がある場合にのみ、グループ化フィールドに instance を追加します。
1 人の送信者が実際に複数のチームにサービスを提供する場合
イベント コンテンツから所有権を選択する必要がある場合は、グローバル オーケストレーションを使用します。ビルダーで、条件 labels.environment equals production と labels.service equals billing-api から始めて、同じグループから有効なチーム、ルート、サービス オブジェクトを選択します。インストール間で数値オブジェクト ID をコピーしないでください。
一致と不一致の両方を検証およびシミュレートし、公開してから、hybrid との互換性のある shadow を使用します。 active に切り替える前に、実際の実行を確認してください。 Shadow は、本番環境の動作を変更することなく決定を記録します。シミュレーターはエンドツーエンドの配信を証明するものではありません。
小規模なルーティング テスト マトリックスを使用する
| 入力 | この例で期待される結果 |
|---|---|
| 本番課金イベント | マッチャーはパスします。選択したサービス、譲受人、チャネルが計画された所有権と一致します。 |
| サービスラベルのステージングまたは欠落 | マッチャーが通らない。送信者の意図した代替パスを確認します。この例では、キャッチオール ルートは作成されません。 |
| 指紋が重複しています | 同じ子が更新されます。グループ化ラベルが一致する場合、別のホスト フィンガープリントによって同じグループ内に 2 番目の子が作成されます。 |
| 回復したのは2人の子供のうち1人だけ | あの子は決意する。グループは、発砲したすべての子供たちが回復するまで発砲を続けます。孤立したリカバリでは新しいグループは作成されません。 |
証拠を黙って消去するようなルールは避けてください
空のマッチャーはすべてに一致します。 severity という名前のラベルは、自動的には正規化されたイベント重大度と同じフィールドにはなりません。文書化されたフィールド パスを使用して、実際の正規化されたイベントを検査します。回復を受け入れる必要がある取り込みパスには status=firing を必要としません。
active + legacy はオーケストレーションの決定を適用しません。 hybrid では、無効なエンティティの組み合わせは従来のパスにフォールバックする可能性があります。権限のある orchestration モードは、代わりに、評価またはエンティティ検証の失敗時の処理をブロックします。意図的に失敗行動を選択します。
広範な drop または suppress ルールを使用せずに開始します。抑制とグループ化は通知を減らすことができますが、どちらも悪い監視信号を役に立たせるものではありません。テスト済みの以前のバージョンを保持し、ロールアウトを拡張する前に予期しない不一致を確認してください。