連携サービスは700以上！ 普段のアラートから対応が必要なものを区別しよう！
山田氏はPagerDutyインシデント対応ソリューションの特長を、デモを交えつつ紹介した。
1つは、豊富な連携サービスだ。PagerDutyと外部サービス／ツール間のデータのやりとりを集約する基盤に、PagerDuty Digital Operations Platformがある。このプラットフォームを介して、検知フェーズではイベントデータを外部の連携ツールから取得、協力・解決フェーズではカスタマーサポートサービスやITOpsツールなどに分析結果を送信することができる。連携サービスは、700以上。APIやメール経由で外部サービスの検知結果をそのまま通知することも可能で、既存の設定や機能を活かす資産保護にも対応している。
トリアージフェーズでは、担当者が対応しなくても処理可能な“ノイズ”をAIやルール設定で排除する機能を提供する。たとえばAlert Grouping機能では、指定した時間内に受信したアラートを、中身や時間からAIが自動仕分けで1つのインシデント配下に集約し、不要な通知を削減する。またTransient Alerts機能では、短時間で自動復旧するような一過性のインシデントをAIが検出して通知を一時停止。復旧しない場合にのみ通知を飛ばす。
もちろん、条件を指定してマッチした場合にアクションを実行する設定も可能だ。条件は、アラートに含まれるフィールド情報やアラートを受け取ったタイミング、頻度など、複数を柔軟に組み合わせて設定できる。優先順位を設定すれば、緊急度の低いものはプッシュ通知せずにチケットだけ発行し、後日に順次対応するといったことも可能だ。また、すでに自動復旧機能を別製品で導入している場合は、Webフックなどを活用して、どの宛先にどの情報を通知するかといった設定もできる。「NTTドコモでは同機能により、約90％のノイズ削減を実現した」（山田氏）
担当者が捕まらなくても安心な「エスカレーションポリシー」
動員フェーズでは、トリアージフェーズで選別されたインシデントを対応に回す。これにはまず、インシデントの影響範囲と通知先の担当者をビジネスサービスとテクニカルサービスとして定義する必要がある。ビジネスサービスはエンドユーザーが利用するサービスで、テクニカルサービスはビジネスサービスが正常に稼働するための技術コンポーネントを意味する。たとえばECサイトの場合、ECのスマホアプリやWebサイトをビジネスサービスとして定義し、テクニカルサービスにはそれらの構成要素となる、決済を行うサービスや推奨商品情報を提示するサービスなどを定義する。このとき、モバイルアプリで問題が発生、またはコンテンツにアクセスする際に経由するAPIゲートウェイで問題があるといったとき、単一チームが責任持って対応できるよう、テクニカルサービスでエスカレーションポリシーを紐付けて担当者に通知する仕組みを作る。
エスカレーションポリシーでは、最初の通知先である担当者が指定した時間内に応答しない場合、次のレベルの担当者に通知を行う。通知の際は、On-Call Schedulesを参照して、その時間帯のシフトについている担当者を確認する。これが繰り返しながらエスカレーションし、最終的に誰も応答ない場合はチームのメンバー全員に一斉通知するといった設定も可能だ。Slackではさらに深い連携が実装されており、他の担当者の割り振りなど各種アクションをSlackから実行することができる。対応が必要なインシデントを絶対に見逃さない仕組みは、PagerDutyの特長のひとつだ。
