インシデント管理の定番サービスといえば PagerDuty ですが、この記事では「インシデント対応の自動化」に関する機能のまとめと、実際に触ってみた所感を記載します。
また弊社では内製のインシデント自動処理システムが存在し5年ほど運用しています。このシステムの機能を PagerDuty の自動化系機能で実現できそうか比較、検討してみます。
※ この記事では PagerDuty の導入を検討している方や初めて触る方を対象に「どのような自動化のサービスがあるか」についておおまかに概観します。各機能の詳細や操作方法については公式ページをご確認ください。
PagerDutyの自動化系機能・サービス比較
| 機能・サービス名 | 概要 | 対象 | 利用例 |
|---|---|---|---|
| Event Orchestration | PagerDutyが受信するイベントに対して、フィルタリングやルーティング、変換などの処理を自動的に行います。ノイズの削減や適切な担当者への迅速な通知が可能になります。 | PagerDuty イベント | ● 特定のキーワードを含むイベントのみを重要度の高いインシデントとして設定し、オンコール担当者に通知する |
| Incident Workflows | 発生したインシデントに対して流すワークフローを定義できる。 ワークフローはインシデントのライフサイクルや指定条件をトリガーに自動起動することも、任意に手動起動することも可能。 |
PagerDuty インシデント |
● インシデントの優先度に応じて、自動的に特定のチームに通知を送信し、関連するSlackチャンネルに投稿する ● 特定のサービスでインシデントが発生した際に、関連するドキュメントへのリンクを含む通知を送信する ● Runbook Automation で定義されたランブックをキックする |
| PagerDuty Runbook Automation (RBA) | 定型的な手動による運用手順（ランブック）を自動化し、セルフサービスでの実行やイベントトリガーによる自動実行を可能にします。 | イベントやインシデントが上がってきたシステム |
● サーバーの再起動やログの収集など、インシデント対応時に必要な手順を自動化し、担当者がワンクリックで実行できるようにする ● 定期的なシステムチェックやメンテナンス作業をスケジュール設定して自動実行する |
各サービスを理解する上で私がポイントと感じたのは以下です。
- Event Orchestration
PagerDuty インシデントが作成される前の「PagerDuty イベント」に対し様々な操作を行い、インシデントの作成に繋げたり、逆に作成させなかったりする。
※ PagerDuty の「イベント」については下記の記事で詳しく解説されています。
イベントとアラートとインシデントの違いとは？ - Incident Workflows
作成された「PagerDuty インシデント」に対し様々な操作を行う。あるいは外部サービスと連携する。 - Runbook Automation (RBA)
Incident Workflows や Event Orchestration を含む PagerDuty の各機能から RBA のジョブが実行され、対象(運用中)のシステムや任意の外部リソース(AWS等)に対し様々な処理を行う。
どのサービスも様々なことができて、かつできることに似た部分があるため、初めて触った時は「やりたいことを実現するにはどのサービスを利用べきか」に迷ったこともありました。
そういう時は「このサービスが対象とするものは何か(== インシデントやイベント)」を思い出すとブレにくくなると思います。
触ってみた所感
Event Orchestration
オペレーターに限らず、構築あるいはセキュリティ担当者にとっても重要なサービスだと思います。
Event Orchestration が主に扱うのは「PagerDuty イベント」ですが、これは監視ツールといった外部サービスから PagerDuty が受け取るデータのことです。PagerDuty にとっては運用中のシステムとの接点ともなるデータのため、オペレーターだけでなくシステム構築に関わるメンバーも Event Orchestration を利用するとより効率よく設定できると思います。
色々なことができるため詳細は公式その他の情報に譲りますが、くだけた言い方をすると「送られてきたデータを色々いじって自分好みの PagerDuty インシデントに仕上げる」という感じかなと。
Incident Workflows
システムの運用者(オペレーター)にとって便利な機能（アクション）が揃っています。
例えば、
- このインシデントの担当者を追加する
- 対象システムを修復するための AWS Lambda 関数を呼び出す
- Webhook による関数呼び出しも可能で、以前投稿した記事もあるのでよければご覧ください
【PagerDuty】Incident WorkflowsからWebhookで外部プログラムを実行する
- Webhook による関数呼び出しも可能で、以前投稿した記事もあるのでよければご覧ください
- Slack チャンネルにメッセージを投稿する
- Google Meet の新規会議を作成する
といったことをウェブアプリから簡単に設定できます。
用意されているアクションは下記ページで確認できます。
Incident Workflow Actions Overview
PagerDuty インシデントは「イベント → アラート → インシデント」という PagerDuty 内のデータフローの最終形態ともいえるので、システム運用の最前線に立つオペレーター向けのアクションが揃っているなと感じました。
Runbook Automation (RBA)
上の2つとは位置付けも役割も異なるサービスです。できることが多岐に渡るため、Event Orchestration と同じくシステムに関わる人なら誰でも便利に利用できます。
Incident Workflows や Event Orchestration が「PagerDuty のインシデントやイベントに対して何かをする」のが基本なのに対し、Runbook Automation は「インシデントの対象となるシステムに対し何かをする」のが基本となります。
※ あくまでも基本で、PagerDuty インシデントや任意の外部リソースに対しても様々な処理を行えます。
「PagerDuty インシデント作成 → RBA が対象システムを修復 → 修復の結果(成功or失敗)に応じてインシデントのステータスを変更」といった、一番人間に近い作業を自動化してくれるのがこのサービスです。
歴史的経緯から PagerDuty とはウェブアプリが別で(ドメインも別)、なんでもできる汎用性の高さから導入・運用コストも上2つよりはかかるため、 システムの規模が大きくなるほど真価を発揮するサービスだと思います。
内製の自動化システム「AMS」
弊社では「AMS」という内製の自動化システムを構築・運用しています。
運用自動化ツールで効率的な運用を実現
MSP業務の効率化を実現〜PagerDutyを活用した次世代監視システムを開発〜
監視業務の一次対応スピードを高速化！次世代監視システム AMS 開発の裏側
AMS は事前定義した「一次対応シナリオ（AMS シナリオ）」にもとづいて以下の処理を行います。
- アクションの実行
- 例：ウェブサイトの死活監視、AWS リソースの操作（EC2/RDS インスタンスの再起動等）、CloudWatch Logs の検索 etc…
- アクションの実行結果に応じたエスカレーション
- 「Backlog 課題の起票」「自動架電」の2種類から組み合わせ可能
これまで紹介してきた PagerDuty のサービスとは「自動化」というキーワードで共通するため、AMS でやっていることを PagerDuty ならどのように実現できるのか考えてみました。
AMS で行っている自動化処理を PagerDuty で実現する
ケース例
以下のようなケースを考えてみます。
- 【障害発生】EC2 インスタンス内で動作していた Apache が停止
- 【検知】監視ツールが PagerDuty にイベントを送信
- 【トリアージ】★ プライオリティの設定
- 【動員】★ 担当者をアサイン、関係者に通知
- 【解決】★ Apache を再起動、プロセスが起動していることを確認
★印のある3以降が AMS のスコープになります。
AMSの場合
【トリアージ】プライオリティの設定
AMS ではおおまかに以下のようなプライオリティ判定を自動的に行います。
- AMS による復旧作業が成功した場合は、PagerDuty インシデントのプライオリティを「低(P4)」にセットする
- AMS では復旧作業を行わず、有人対応にエスカレーションした場合は「中(P3)」にセット
- AMS による復旧作業が失敗した場合は「高(P2)」にセット
このように AMS による作業(アクション)の結果にもとづいてプライオリティを決めるため、監視ツールでいうところのプライオリティとはやや趣旨が異なります。AMS は弊社 MSP チームとの連携が重要で「AMS から有人対応に引き継ぐか否か」がプライオリティの判断基準となっているためです。
ただ PagerDuty も AMS も最終的には PagerDuty インシデントのパラメータである「インシデントプライオリティ」を設定することは同じです。
【動員】担当者をアサイン、関係者に通知
AMS シナリオで事前に設定しておくことで Backlog と自動架電を組み合わせた通知を関係者に送ることができます。
Backlog 課題には任意の AMS ユーザーを課題担当者や通知先として設定できます。
Backlog 課題の内容としては PagerDuty インシデントのデータの一部または全部、あるいはアクションの結果（このケースだと再起動後のプロセスの状況等）を掲載するなど、柔軟な内容に編集できます。
【解決】Apache を再起動、プロセスが起動していることを確認
AMS シナリオに「Apache を再起動するアクション」を設定しておくことで復旧作業が行われます。
同時に「Apache のプロセスを確認するアクション」も設定しておくと復旧後の確認も実施します。
PagerDutyの場合
【トリアージ】プライオリティの設定
Event Orchestration でルールを事前に作成しておきます。
ルールにマッチするイベントを受信すると、その後作成される PagerDuty インシデントの「インシデントプライオリティ」がルールにもとづいた値にセットされます。
【動員】担当者をアサイン、関係者に通知
Incident Workflows のワークフローを事前に作成し、エスカレーション先を設定しておきます。
このワークフローに紐付けられた PagerDuty インシデントが作成されると、ワークフローで設定した PagerDuty ユーザーがインシデントの担当者として自動的にアサインされます。※ Escalation Policy という単位でアサインさせることも可能
Backlog のようなプロジェクト管理ツールを使ってエスカレーションしたい場合は、ツールの API にリクエストするためのプログラムを用意し、それを Webhook や JavaScript アクションとして設定することが可能です。
【解決】Apache を再起動、プロセスが起動していることを確認
Runbook Automation のジョブを作成します。ジョブのステップを追加し「Apache の再起動コマンド」をセットします。ps コマンド等を次のステップとして追加することで「プロセスの起動確認」ができます。
最後に作成したジョブを Incident WorkFlows から呼び出せるように設定します。
まとめ
今回紹介した3つのサービスが「トリアージ、動員、解決」として綺麗に当てはまりました。もっとも実際には「Event Orchestration から RBA ジョブを呼び出し、事前処理を行う」といったことも可能なため、このような固定した分担にこだわる必要はありません。
また細かく比べると AMS の仕様と PagerDuty の仕様が1対1で対応するわけではありませんが、AMS の運用で得たノウハウを PagerDuty による自動化にもある程度落とし込めそうなことがわかりました。
最後になりましたが PagerDuty 様のブログでも AMS が紹介されているのでぜひご覧ください！
PagerDutyと一次対応の自動化 〜24/365監視運用の実現と効果〜
公式ブログリンク
今回紹介した PagerDuty の各サービスについて公式ブログで詳しく説明されているのでご参考ください。
Event Orchestration
Incident Workflows
Runbook Automation
