IncidentRelay v2.3.1 の例は動作しており、にチェックされました。以下の名前、識別子、タイミングは一例です。本番認証情報を使用する前に、テスト展開で認証情報を検証してください。
ビジネス例 · セットアップ · 実際の例 · 受け入れチェック · 制限と障害モード
ビジネス例: SaaS 顧客はタイムゾーンを越えて業務を行っています
顧客事例ではなく、例示的なシナリオ。以下の指標はパイロットのための提案であり、節約を測定したり、IR にすべてのレポート ダッシュボードが含まれるという主張ではありません。
状況とリスク: B2B SaaS チームはヨーロッパと北米の顧客にサービスを提供しています。顧客の午後の勤務時間が別のエンジニアの夜と重なっており、通常の対応者は休暇中です。合意されたスケジュールがない場合、チームはチャットに最初に気づいた人に依存します。リスクは、所有者のいない停止と、非番のスタッフの度重なる中断です。
IR を使用したワークフロー。 スタッフの対応範囲に同意し、それを基本ローテーションと営業日レイヤーで表します。休日の代替をオーバーライドとして記録し、別のバックアップ エスカレーション ターゲットを構成します。引き継ぎと将来のギャップを確認します。計画的な課金展開の場合は、無関係なサービスが通知を継続している間、サービスを対象としたメンテナンス期間を使用します。
検証すべき運用上の利点。 休暇や引き継ぎを含む、サポートとエンジニアリングに対する責任を予測可能にします。計画された作業では、会社全体のアラート ストリームをミュートする必要はありません。
何を測定するか。 今後 14 日間など、将来の定義された期間内で未カバーの分を確認し、チームの対応目標内の直前の手動引き継ぎと確認を確認します。エンジニアごとの夜間通知を実際の人員配置スケジュールと比較します。バランスのとれたカレンダーだけでは作業負荷はわかりません。
境界。 カレンダーが埋まっていても、追加のスタッフが作成されることも、誰かが対応できることを証明することもありません。 IR は、契約上の応答時間を保証したり、ACK から顧客の対応状況を計算したりすることはありません。より広範な業務プロセスにおいて、人員配置の決定、SLO の監視、顧客とのコミュニケーションを継続します。
勤務日を最適化する前に夜をカバーする
SRE チームが、日勤勤務と夜間勤務の勤務時間にわたる請求の信頼性を所有しているとします。 1 回のローテーションで、優先度 10 と無制限の 24/7 カバレッジを持つベース レイヤを作成します。優先度 20 のレイヤーを追加し、Europe/Berlin の月曜日から金曜日の 09:00 ～ 18:00 に制限します。実際のアクティブなメンバーを使用して、生成されたカレンダーを確認します。
最も優先度の高いアクティブ層が割り当て先に供給されます。オーバーライドはレイヤーよりも優先されます。これらは 2 人の同時応答者ではありません。バックアップ対象範囲に対して別のエスカレーション ターゲットまたはローテーションを構成します。アクティブなレイヤーがなく、オーバーライドが適用されない場合、担当者は存在しません。 回転とレイヤーのルールをご覧ください。
計画的な展開中に請求通知を一時停止する
インターフェースを介してサービス スコープのウィンドウを作成するか、スコープを変更する権限を持つ認証された管理-API セッションを使用してこの構成を POST /api/maintenance-windows に送信します。取り込みルート トークンは管理資格情報ではありません。 42 を実際の課金サービス ID に置き換えて、今後のテスト期間を選択します。
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}これらのタイムスタンプは、選択したタイムゾーンの実時間であり、Z が省略された UTC 値ではありません。この期間中、受信した請求アラートは表示されたままですが、通知、リマインダー、およびエスカレーションは一時停止されます。他のサービスは影響を受けないはずです。この動作は、新しい AlertGroup を禁止する suppress_incident や、通知を有効のままにする pause_escalation_only ではありません。
シフトの途中だけでなく境界線をテストする
- 週末と夏時間への移行期間中の、09:00 と 18:00 の直前と直後に割り当てを検査します。一時的なオーバーライドを追加し、それが有効であることを確認してから削除します。
- 完全なオンコール ヘルス チェックを開きます。チェックされた将来のウィンドウ、ギャップ、非アクティブなメンバー、および使用可能な配信方法を確認します。緑色の概要は、永久的な保証や電話への配信を証明するものではありません。
- メンテナンス中に請求イベントと無関係なサービス テスト イベントを送信します。請求が表示されるが静かで、無関係なサービスが引き続き通知することを確認します。すでに未解決のアラートを含めるには、ウィンドウを既存のアラートに適用するオプションを明示的に有効にします。デフォルトではオフになっています。
- ウィンドウが終了したときに請求を実行したままにします。再アクティブ化を有効にすると、見逃したリマインダーをすべて再生することなく、通常の通知が再開されることを確認します。実際の応答者がそれを受信し、確認できることを確認します。
静かなサービスは回復されたサービスではありません
メンテナンスはサービスを修復したり、配信されたメッセージを取り消したり、解決を示唆したりするものではありません。終了時の再アクティブ化はデフォルトで有効になっています。これを無効にすると、ウィンドウが終了した後もメンテナンス効果が保持されます。ウィンドウが重なっていると、最後に適用可能なアクティブまたは保持されている効果が解放されるまで、アラートを静かに保つことができます。 メンテナンス ガイドでこれらのコントロールを確認してください。
SLO 計算とバーンレート検出を監視スタックに保持します。 IR は、結果として得られる信号をルーティングし、調整します。 AlertGroup は、技術的な確認、解決、通知、およびエスカレーションを所有します。 インシデントは別の運用ワークフローです。複数の AlertGroup を 1 つのインシデントにリンクしても、それらの技術履歴はマージされません。 v2.3.1 では、レスポンダーと関係者は引き続き AlertGroups に属します。インシデント ステータスの変更を AlertGroup ACK として扱うのではなく、両方のライフサイクルをテストします。