インシデント管理

インシデント管理は、プラットフォームのインシデントを特定し、対処し、解決するための構造化されたプロセスです。目標は、事業運営と顧客体験への影響を最小限に抑えることです。

インシデントとは

インシデントとは、予期せぬ中断、サービスの低下、またはInfobipのプラットフォームとサービスの品質の低下です。インシデントは、製品の機能が意図したとおりに機能しないなどの軽微な問題から、プラットフォームの完全な停止まで多岐にわたります。

インシデント管理の段階

インシデント管理プロセスには、次の 3 つの主要な段階があります。

識別: 監視ツール、内部検出、または顧客からのフィードバックを使用してインシデントを検出します。
介入: 影響を受けるサービスの機能を復元します。
レビュー: インシデントを文書化して、学習と将来の改善をサポートします。

メンテナンス作業

メンテナンス作業は、Infobipプラットフォームの運用、効率、および安全性を維持するために不可欠です。これらのタスクには、ソフトウェアの更新、システムの最適化、セキュリティパッチ、インフラストラクチャのアップグレードが含まれ、予期しないダウンタイムを防ぎ、シームレスなサービス提供を確保するのに役立ちます。

メンテナンスの種類

メンテナンス作業は、次の 2 つのカテゴリに分類されます。

計画メンテナンス: 事前にスケジュールされ、アクティビティの少なくとも 10 営業日前にお客様に通知されます。計画メンテナンスは、通常、中断を最小限に抑えるためにオフピーク時に実行されます。
緊急メンテナンス: 10営業日以内にお知らせします。緊急メンテナンスは、プラットフォームの機能やセキュリティに影響を与える可能性のある緊急の問題に対処します。

主な違いは、計画メンテナンスは事前にスケジュールされ、事前に通知されるのに対し、緊急メンテナンスは事後対応型で、必要に応じて実行されることです。

メンテナンスとインシデントの通知

Infobip プラットフォーム内のインシデントとメンテナンスアクティビティは、ステータス (opens in a new tab) ページで通知されます。外的要因によるオペレーターのメンテナンスや配送低下は、外部接続状態 (opens in a new tab)ページでお知らせします。

両方のステータスページの更新をサブスクライブして、任意のチャネル (電子メール、Slack、Webhook、Atom/RSS フィード) を介して通知を受け取ることができます。

詳細については、次を参照してください。

インシデント管理プロセス

早期検出により、問題がエスカレートするのを防ぎ、応答時間を短縮できます。

インシデントの特定

インシデントの検出方法:

プラットフォームの監視: 自動化されたツールは、プラットフォームコンポーネントの正常性とパフォーマンスを継続的に評価します。これらのツールは、異常が検出されたときにアラートをトリガーします。
内部検出: チームメンバーは、予期しないサービス動作や手順エラーなど、自動化されたシステムでは検出されない問題を手動で特定できます。
顧客からの報告: 顧客は、発生した問題を報告できます。ユーザーからのフィードバックは、監視ツールが見逃す可能性のあるインシデントを特定するのに役立ちます。

初期対応

インシデントが検出されると、初期影響評価が実行されます。目標は、影響を受ける場所(データセンターやリージョンなど)、チャネル(SMS、RCS、WhatsAppなど)、および製品またはインターフェイス(Conversations、Answers、HTTP API、SMPPなど)に関する基本的な情報を収集することです。

インシデントは、事前に作成されたフォームを使用して、内部の「ブリッジ」イベントとして記録されます。これにより、部門間のコラボレーションのための一元的なコミュニケーションチャネルが作成されます。

インシデントのエスカレーションと通知

報告後、インシデントは適切な担当者にエスカレーションされます。運用チームのメンバーにアラートが通知され、トラブルシューティングが開始されます。構造化されたエスカレーション手順により、必要な専門家のタイムリーな関与が保証されます。

カスタマーサポートはインシデントを監視し、ステータス (opens in a new tab)ページ通知を準備します。最初の通知は通常 15 分以内に発行され、次のものが含まれます。

影響を受ける製品とチャネルの場所
影響を受けるチャネルと製品/インターフェース
既知の影響の簡単な説明

最初の通知に続いて、カスタマーサポートは新しい情報が利用可能になったときに更新を提供します。

インシデント介入

エスカレーションされると、エンジニアは問題の軽減に集中します。このプロセスには次のものが含まれます。

影響の検証と評価
原因についての理論の定式化
理論を支持または反駁するためのデータ収集

軽減策には、サービス機能を復元するためのクイックアクションの実装が含まれます。

これらのアクションは一時的なもので、次のような手順が含まれる場合があります。

ロードバランサーからの障害のあるインスタンスの削除
正常なデータベースクラスタを使用するためのサービスの再構成

緩和策は事前に発表され、その効果が監視されます。

緩和フェーズは、次の場合に終了します。

継続的な人間の関与が不要になる安定した状況が達成されます
インシデント解決のための適切な修正を実装するための十分な時間がある

一時的な解決策のみが適用される場合は、根本原因に対処するために長期的な修正が必要です。

例えば：

軽減手順	長期的な修正
障害のあるインスタンスをロードバランサーから削除する	インスタンスの復元と再統合
正常なデータベースクラスタを使用するようにサービスを再構成する	元のデータベースクラスタを修復する

インシデントのレビュー

解決後、インシデント後のレビューが実施されます。レビューには、詳細なデータの収集と 根本原因分析 (RCA) ドキュメントの作成が含まれます。このフェーズの重要な側面は、予防措置を特定し、それらを実行可能なタスクに変換することです。

Infobipでは、**インシデント記録ファイル(IRF)**を使用して、インシデントメトリックと、関係する担当者および信頼性チームからの書面によるレビューを記録します。

IRF テンプレート

IRFには以下が含まれます。

概要とタイムライン: タイムスタンプ付きの主要なアクションとイベントを含む短い概要。
検出: インシデントがいつ、どのように検出されたか。
軽減策: すべての緩和アクションと、将来の緩和策をより迅速に行うための要件の記録。
寄与原因: インシデントの期間または影響に影響を与えた根本原因およびその他の要因。
影響評価: 顧客への影響と影響を受ける製品またはサービスの説明。
予防措置: 再発を防止し、すべての原因に対処するために講じた、または計画した措置。

根本原因分析ドキュメント

RCAドキュメントは、IRFからの情報を使用して、Infobipプラットフォーム内で発生したインシデント用に準備されています。

Infobip の根本原因分析ドキュメントは、通常、次の構造に従います。