IncidentRelay v2.3.1 の例は動作しており、にチェックされました。以下の名前、識別子、タイミングは一例です。本番認証情報を使用する前に、テスト展開で認証情報を検証してください。
ビジネス例 · セットアップ · 実際の例 · 受け入れチェック · 制限と障害モード
ビジネス例: 毎晩のバックアップが終わらない
顧客事例ではなく、例示的なシナリオ。以下の指標はパイロットのための提案であり、節約を測定したり、IR にすべてのレポート ダッシュボードが含まれるという主張ではありません。
状況とリスク: ある企業は、営業日が始まる前に注文データベースを 2 台のサーバーにバックアップします。 1 つのジョブは静かに停止します。もう一方は成功します。単一の成功シグナルが共有されれば、ギャップは隠蔽されます。ビジネス リスクは、復元が必要な場合にのみ、古い復旧ポイントや失われた復旧ポイントが見つかることです。
IR を使用したワークフロー。 完了期限を定義し、予想される各サーバーを個別に追跡します。ホストは、ジョブと成功チェックが終了した後にのみハートビートを送信します。完了がない場合は、バックアップ エスカレーション パスを使用してプラットフォーム レスポンダーにルーティングされる期限切れアラートが作成されます。エンジニアはジョブを調査または再実行し、結果を記録します。
検証すべき運用上の利点。 次のビジネス シフトの前に、サイレントでスケジュールされたジョブの失敗を所有タスクに変えます。完了信号が本当に成功を表している場合、同じパターンでスケジュールされたエクスポート ジョブやバッチ ジョブをカバーできます。
測定対象: サーバーごとの期限切れ、期限から承認までの時間、最新の検証済みバックアップの経過時間を追跡します。バックアップの検証と復元の結果をバックアップ システムまたは運用レポートに記録します。緑色の心拍からそれらを推測しないでください。
境界。 ハートビートは信号が到着したことを証明するものであり、データが復元できることを証明するものではありません。回復ポイントや回復時間を保証するものではありません。復元を個別にテストし、同じ障害ドメインの外側から IR 自体を監視します。
ページング システムを自分が運営するサービスとして扱う
実稼働クラスターと夜間のデータベース バックアップを所有するプラットフォーム チームを考えてみましょう。監視スタックの近くに IR を設置したいと考えていますが、そのためにチームは IR を起動するシステムの責任も負うことになります。 Web サービス、スケジューラ、データベース、シークレット、および回復手順の所有者に名前を付けます。
リリース Docker セットアップでは、ウェブ サービスとスケジューラ サービスを個別に実行します。テスト環境でその展開ガイドに従った後、リリース チェックアウトからそれらを検査します。
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerWeb プロセスは受信アラートを受け入れます。 スケジューラはリマインダー、エスカレーション、定期的なジョブを処理します。すべての Web ワーカー内でスケジューラを起動しないでください。ログイン ページが機能していても、時間指定のエスカレーションが実行されていることは証明されません。
1 つのホスト上で欠落しているバックアップを検出する
毎日 UTC の 03:00 に期限設定されるスケジュール済み完了ハートビートを作成し、ソースが heartbeat であるルートに接続します。インスタンスの追跡を有効にします。固定フリートの場合は、db-1 や db-2 などの静的な予期されるインスタンスを使用します。プラットフォームのローテーションまたはポリシーをアタッチし、チャネルをテストします。
ホストのバックアップと成功チェックが完了したら、この本文を JSON コンテンツ タイプで POST /api/heartbeats/ping/HEARTBEAT_TOKEN に送信します。ルート トークンや管理用の API トークンではなく、ハートビートのシークレット URL を使用してください。
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}各ホストから個別のインスタンス値を送信します。インスタンスを追跡しないと、あるサーバーからの ping が成功すると、別のサーバーの欠落したバックアップが隠蔽される可能性があります。ジョブが失敗した後、シェル クリーンアップ ハンドラーから無条件に成功 ping を送信しないでください。プロキシおよびジョブログからのシークレット ping URL を編集します。
起動だけでなくテストも失敗
- 予想される両方のインスタンスに ping を実行し、短いテスト スケジュールで 1 つを意図的に省略します。正常なインスタンスが正常なままである間、そのインスタンスに対して期限切れのアラートが発生することが予想されます。
- 不足しているインスタンスを再開します。自動解決が有効になっている場合は、別のインスタンスの障害を解決せずに、期限切れアラートが解決されることを確認します。
- テスト展開でのみスケジューラを停止します。時間制限された作業への影響を観察し、独立した監視者がそれに気づいていることを証明します。次に、それを復元し、処理を確認します。
- データベース、構成、および必要なシークレットを、送信通知がブロックされた隔離された環境に復元します。配信を許可する前に古い実行グループを確認してください。これにより、復元ドリルでは実動レスポンダーをページングできなくなります。
成功した ping は復元テストではありません
ハートビートは欠落した信号を検出します。これらはアクティブな HTTP/TCP プローブではないため、バックアップが使用可能であることを証明できません。また、IR 自体の完全な停止を確実に通知することもできません。外部の可用性チェックと、同じ障害ドメインの外側にある別の連絡先パスを維持します。
セルフホスティングでは、チャット、電子メール、音声、またはネットワークの依存関係は削除されません。どのデータベースと展開モデルがワークロードに適合するかを決定し、テストされたリリースを固定し、アップグレードとロールバックをリハーサルします。これらの例は、高可用性やスループットの保証を確立するものではありません。
保持期間を意図的に設定します。解決されたアラート履歴はデフォルトで無期限に保持されます。クリーンアップでは、リンクされたコメントや配信レコードも削除できますが、必ずしもデータベース ファイルが圧縮されるわけではありません。 Retention is not a substitute for backups.