アラートの嵐で疲弊していた、AWSエンジニアのあるアイディア
2009年創業の米PagerDuty。サイバー攻撃や故障・障害からインフラを守り、安定稼働を実現することがますます重要となる中で、創業者の元AWSエンジニアたちはサイバー攻撃やインフラ障害などのインシデントが発生するたびにPager（ポケベル）で呼び出され、対応に追われる日々を送っていた。しかし、通知のすべてが対応を必要とするものではなく、大半はやり過ごしても問題のないものだった。アラートの嵐で無駄に疲弊するエンジニアたちを救い、本当に対応が必要なインシデントに注力できるようにするには、どうすればよいのだろうか。自らの経験を通じて生まれたアイディアは今、PagerDutyインシデント対応ソリューションとして、グローバルで2万社以上が導入するまでとなった。日本法人は2022年5月に設立したばかりだが、すでに330社以上が同社ソリューションを活用しているという。
インシデントについて、PagerDutyの山田索氏は「ITシステムの障害を引き起こしている原因や、近いうちに障害となりうる問題など、何らかの対応が必要な課題」と定義。インシデント以外は自動化で対処し、専門家の目が必要なものだけ分析に振り分けることができれば、迅速かつ効率的なインシデント対応が実現可能で、将来問題になりそうな芽も摘むことができるとし、それをサポートするのがPagerDutyインシデント対応ソリューションだと述べた。
インシデント対応は、主に「検知」「トリアージ」「動員」「協力／解決」「学習／予防」の5つのフェーズに分けることができる。PagerDutyでは、New RelicやDatadog、Splunkなどのオブザーバビリティツールや統合ログ管理ツールと連携してイベントを受信。インシデント担当者による対応が不要なものは自動で処理し、必要なものは適切な担当者に通知。過去の類似インシデントや直近のコード変更など解決のヒントを提示し、対応後は再発防止に向けた事後分析やチーム内外との知見の共有などをサポートする。
連携サービスは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の特長のひとつだ。
変更の自動リストアップや対応履歴の参照機能など、迅速な問題解決を支援！
協力／解決フェーズは、通知を受けた担当者がいかに迅速に問題を解決できるかを支援する。
原因を特定するには、手がかりが必要だ。これは、現在インシデントが発生しているサービスで最近行われた変更を自動でリストアップするRecent Changes機能、過去のアラート情報や対応履歴を参照して現在のインシデントと関連性が高いものを自動で提示するPast Incidents機能、他サービスで発生中のインシデントで関連性の高いものを提示するRelated Incidents機能などがサポートする。インシデントにつながる変更はあったのか、過去の類似インシデントではどのような対応が行われたのか、他サービスの影響によるものかどうかなど、解決に必要な情報が自力で調査することなく提示されることで、次のアクションへスムーズにつなげることができる。
特に最近のシステムは複数サービスの依存関係で成り立っており、担当チームと素早く連絡を取り合って対応に当たることができるのは重要だ。PagerDutyではこうした機能が豊富に用意されている。たとえば、他サービスの担当者に通知して協力を仰ぐAdd Responders機能、チーム外の関係者とインシデント対応状況を共有して対応作業を円滑化するStatus Update機能などが挙げられる。また、PagerDuty上で実行する一連のアクションをワークフローとして定義し、自動実行するIncident Workflow機能も有用だ。たとえば他チームへの協力依頼を出してからステークホルダーを追加、Zoom会議を設定するなど、インシデント対応の典型的な流れがあれば、それをワークフローに定義して自動実行するといった具合だ。こうした事務的な手続きから解放されることで、より業務に集中できるようになる。
このほか、自動診断スクリプトや修復ジョブを事前に定義して自動実行することもできる。もちろん、手動で実行したり、アラートに含まれる情報を条件にイベントドリブンで診断をキックしたりすることも可能だ。たとえば、インシデント対応をする担当者に一部のシステムへのアクセス権がない場合でも、一次切り分けの診断をジョブとして用意し、誰でも実行できるようにしておけば、速やかな対応が実現する。
「PagerDutyは、運用の負荷を下げてエンジニアが新機能の開発やサービスの安定化といった、より重要なサービスに注力できるよう支援する。講演で説明した以外にも、さまざまな便利な機能があるので、ぜひチェックしてほしい」（山田氏）
月に1万件あったアラート数を10分の1に削減。NTTドコモが実践したインシデント対応改善
NTTドコモ様はAWS と PagerDuty を使用し、最高クラスのインシデント対応プロセスを実装することでシステムノイズとアラート疲れを大幅に軽減し、インシデント解決時間を大幅に短縮しました。
インシデント対応を行なっている DevOps や IT 運用チーム向けのセッションとなっておりますが、アラートの精査やクリティカルなインシデント発生後の通知・連絡に課題を感じている方は、是非こちらの動画をご視聴下さい。
