インデントを一元管理できるPagerDutyの3つの機能
セッション冒頭、PagerDuty, Inc ソリューションズ コンサルタント 大塚清尊氏は、PagerDutyに関して「日々発生する大量のアラートの中から、インシデントを定義づけし、誰が何を対応するかを素早く明確化することが可能になっています」と紹介した。
PagerDutyは、2007年米サンフランシスコで創業された企業で、従業員1100名以上、3カ国7拠点を持ち同名のツールをSaaSで提供している。ユーザーは、1万4000社、70万ユーザー、80カ国に存在し、Fortune 100の半数以上の企業が利用している。500以上の監視ツールや障害検知ツールなどと容易に統合でき、インシデントの管理を一元化することができる。
PagerDuty導入によって、インシデントによるダウンタイムの減少、インシデント対応の効率化、エスカレーションの自動化、ビジネスインパクトの見える化によるリスクの低減などの効果が期待できる。
PagerDutyの機能は大きく3つに区分できる。1つ目の「イベント・インテリジェンス」は、クラウドやコンテナ、ネットワーク、セキュリティといったさまざまな監視点から発信されるアラートを整理し、クリティカルなものかそうでないかを判断するなど、アラートの一元管理を可能にする。また、1つのインシデントから発生される複数のアラートを集約できるので、重複してノイズとなったアラートの低減も可能だ。これで、管理者が早急に対応すべきインシデントに効率的に向き合うことができる。
2つ目の「オンコール管理」は、整理されたインシデントをそのときの適格な担当者に連絡する機能。連絡は携帯電話、SMS、Eメール、プッシュ通知、チャット通知などを選ぶことができる。もし最初に一報を送信した担当者が不在の場合は、オンコール管理内の「エスカレーション自動化」が働き、インシデントは自動的に次の人にエスカレーションされる。その場に合わせた適格な管理者やエスカレーション先は、オンコール管理内の「スケジュール管理」が把握しているので、連絡先は自動で設定される。例えば、平日夜間と平日日中でオンコールのメンバーを変えている場合は、時間になるとPagerDutyが自動的にシフトを切り替えて連絡先を変える。
また、オンコール管理内の「アクティビティの管理」では、インシデント発生から対応する担当者が割り当てられるまでの経緯、その後の対応の経緯といった一連の流れを、時系列のアクティビティとしてインシデント情報に記録できるので、どう対応したかの見直しも容易に行える。
3つ目の「インシデント・レスポンスの自動化」は、対応作業のいろいろなケースを自動化するものだ。インシデントが発生した場合、一般的にはサーバー状態確認、情報収集、場合によっては再起動などの作業が発生するが、こうした作業をPagerDutyからワンクリックで簡単に実行できる。
加えてアラートの量、担当者割り当てまでの時間、解決に要した時間といったインシデント対応のパフォーマンスを保持できるので、月次や週次でオンコールされた担当者やチームのパフォーマンスなどを管理できる。大塚氏は「PagerDutyは、インシデントのトリガー発生時から解決までを効率化できる、エンドツーエンドのいろいろな場面で使えるツールです。また、それらのパフォーマンスをしっかりとメトリックとして保持できるので、さらなる効率化を図ることも可能です」と述べた。
デモンストレーションでPagerDutyをより詳しく紹介
PagerDutyの機能説明のあと大塚氏は、デモンストレーションによって利用イメージを紹介した。
インシデントに対応するチームを系統図で示す
PagerDutyは、インシデントの発生が想定される部分と、それに対応するチームを関連づけた系統図を用いてインシデントの管理を行う。これは、「サービスグラフ」と呼ばれる。下図を見ると、Web Servicesでインシデントが発生したら、最初の対応はDevOps Team Bが担当することがわかる。
大塚氏は、インシデントが発生し、オンコールですぐに連絡が必要となると、担当者の携帯電話に通知するというシーンも紹介した。通知手段は、電話のコール、SMS、Eメールなどを選択可能だ。下図の例では、右の黒い部分が携帯電話のメッセージ表示部分になっており「Login Error〜」というインシデント発生の通知が示されていることがわかる。
今回のデモンストレーションでは、「ログインできない」というインシデントを想定した。その際のサービスグラフでは「Login」が強調され、直下の対応チームに赤い三角マークが見える。このように図式化されることで、インシデントの発生と対応部署、その影響の及ぶ範囲などが容易に判断できる。
スケジュールや担当者の空き状況に応じた自動割り当ても可能
通知を受け取っても担当者がすぐに対応できない場合がある。滞りなく対応できるよう、他の担当者を割り当てるエスカレーションのルールについては「エスカレーションポリシー」で設定できる。ポリシーはいくつか階層に分かれていて、一番上の層が最初のエスカレーションポイントだ。またオンコール担当者のスケジュールと連携しているので、時間や日にちによって担当は自動的に選択される。ポリシーにはタイマーがあり「3分間で反応が無かったら」次の人にエスカレーションするという設定もできる。インシデントが発生しても、誰にも連絡がいかないということはない。
原因が同じ複数のアラートも、1つのインシデントに集約
Loginのエラーなど、サービス全体にかかわるインシデントが発生した場合、利用者の数だけ通知がきてしまう可能性がある。PagerDutyは、1つのインシデントに関連するアラートを集約することで、重複したアラートというノイズ情報を一箇所にまとめられる。これによって、アラートが発生する度に担当者が確認に走るという手間が省ける。図では、右側の携帯電話のメッセージ表示画面に集約されたアラートが見える。だぶったアラートについては、保管はするがインシデントは１つとして対応している。
アラートの集約については「Reduce Noise」機能から3つの手法を選べる。
「Time-Based」（タイムベース）は、アラートの内容に関わらず、時間をもとに集約を行う。30分と指定した場合は、最初のアラートが発生してから30分間は内容に限らず対応するインシデントの中に集約する。本設定は、メンテナンス作業などによって大量のアラートが一定時間発生する場合などに有効だ。
「Contents-Based」（コンテンツベース）は、アラートの内容を1個ずつ確認し、設定した条件に応じて集約を行う。設定は、集約したいアラートのデータの中で、このデータが同じだったら集約するという指定を行うことで設定ができる。アラート内のデータを表示し、集約に関連するデータ部をクリックすると、その場所に同じ情報があるものが集約される。
3つ目が「Intelligent」（インテイジェント）だ。PagerDutyの機械学習を用いて集約を行うことができる。機械学習を用いることで、アラートのタイトルや入ってくる時間帯が近ければ自動的に判断して集約を行う。ほかにも2つのアラートが同時に発生することが多いときは、この2つのアラートを選んで「merge」ボタンを押して学習させておくと、以後同じように処理できるようになる。
インシデントの自動分類を行うための設定も可能
PagerDutyは、アラートが入ってきた時に、そのアラートがクリティカルかどうかの見極めを行い、どの担当者宛にインシデントを分類するかといった仕分けを自動で行える。この自動仕分け機能は「イベントオーケストレーション」と呼ばれ、事前の各種設定によって仕分けの判断を行う。設定項目は、インシデントを発生したツールの種類や、アラートのデータを設定条件にすることができる。複数設定が可能で、アンド（＆）もしくはオア（or）することができる。下図は、その設定を編集できる「Edit Routing Rule」の画面だ。こうした仕分けによる分岐は、図式化された状態で確認できるので、設定にミスや問題があっても容易に理解でき修正もその場でできる。
大塚氏は「どこのメンバーに連絡すればよいかを考えながら行っていた手仕事の仕分け作業も、このイベント・オーケストレーション機能で自動的に実施することができます。前のアラート集約機能を合わせて90%以上のノイズを削減した実績もあります」と語った。
インシデント対応を自動化し、工数を削減
インシデントによっては、その対処法が決まっていることもある。例えばサーバーの現状確認、必要なら再起動、もしくは新しいWebサーバのデプロイなどは、よく行われる。これらは、スクリプトを動作させたり、コマンド入力したりすることによって実行できるが、PagerDutyには、このようなよく行う作業を自動実行できる機能がある。事前にスクリプトやコマンドを設定しておけば、プルダウンメニューから、例えば「Check Server Status」を選べば、すぐにサーバーの状況を確認可能だ。よく行うたくさんの作業をあらかじめ設定しておけば、相当の工数低減につながるだろう。
インシデントの対応は、システムの保安や保全に重要な作業だ。PagerDutyのようなツールを使って、効率的に処理し、時には自動操作で時間短縮することは、担当者の負荷低減の意味でも重要と言える。同社では、PagerDutyの無料トライアルを実施しているので、インデントの上手な管理に悩んでいるなら、すぐにトライアルでその効果を実感してほしい。
