PagerDuty Advent Calendar 2日目の記事です。
この記事では、診断や復旧作業等を自動化する方法を説明します。
PagerDuty自体が、インシデント対応を始めとするデジタルオペレーションを自動化するプラットフォームであり、アラートのグルーピングや処理の自動化、通知の自動化、ポストモーテム草稿の自動生成等を行うことができます。
本記事でカバーする自動化は、主にサーバーやDB等の外部のリソースに対する操作で、下図の赤枠の部分になります。どのような仕組みで実現できるのか、ユースケースと併せてご説明します。
Event-Driven Automation と Human-in-the-Loop Automation
Event-DrivenとHuman-in-the-Loopとは、自動化された作業をトリガーする方法です。
Event-Drivenでは、特定の条件を事前に設定しておき、その条件が満たされれば(人が介在することなく)自動実行します。
一方、Human-in-the-Loopでは、人が自動化作業をトリガーします。実行前に人による精査や判断が必要な作業はこの方法を取ります。
下図はPagerDutyでEvent-Driven AutomationとHuman-in-the-Loop Automationを行う場合の例です。
Event-Drivenの例としては、Event Orchestrationで監視ツールから受信するEventの条件を設定しておき、特定の条件Eventを受信した場合に診断やログ収集などを自動実行することができます。
Human-in-the-Loopの例としては、インシデント起票後に担当者が状況を判断し、必要に応じて修復作業等のJobをPageDutyやSlackから選択・実行することができます。
Runbook Automationは、Jobを管理する自動化のためのプラットフォームで、外部のリソースに対する操作をPagerDutyと連携して行うことができます。以降はRunbook Automationについて解説します。
なお、Incident WorkflowsはPagerDutyに組み込まれた、ローコードでワークフローを自動化できる機能です。PagerDutyや連携先のツールを操作して、インシデント対応で必要となるタスクを自動化できます。(例: 重大インシデント発生時に緊急対策本部を設置し、インシデント・コマンダーをアサインする)
Incident Workflowsについては別途「解決編」で説明予定です。
PagerDuty Runbook Automation
PagerDuty Runbook Automationは汎用の自動化プラットフォームで、インシデント対応以外にも様々な用途で利用できます。
一般にはRundeckと呼ばれるOSS/Community版の方が有名かもしれません。
Rundeckは2020年にPagerDutyが買収し、その商用版がPagerDuty Runbook Automationという名称で提供されています。
自動化における課題とPagerDuty Runbook Automation
作業の自動化を検討する際、一般に以下のような課題に直面します。
-
用途ごとに存在する様々な自動化ツール
様々な分野や用途に特化したツールが存在します。特定のツールだけで全てを自動化することは難しく、一方で組み合わせて利用しようとすると管理が困難になります。 -
担当者のスキルのばらつき
作業を自動化する担当者のスキルもハードルになります。一部ツールに知見があるエンジニアでも、全てのツールに精通することは期待できません。 -
セキュリティ
セキュリティについても考慮する必要があります。認証情報をセキュアに管理し、オンプレ環境でもセキュリティレベルを落とさずに実行できる仕組みが必要になります。
PagerDuty Runbook Automation(RBA)は、前述の課題を乗り越えることができるよう設計されています。
RBAは、既存の自動化ツール置き換えるものではなく、これらのツールを組み合わせるオーケストレーターとして利用できます。RBAによって簡単にEnd-to-Endのワークフローを構築・管理することができるようになります。
120を超えるインテグレーションが用意されているため、これらを利用してGUIから簡単にJobを作成することができます。PagerDuty Advanceは生成AIによるJob作成支援機能で、作成したいJobの内容を自然言語で入力すると、適切なインテグレーションやAPIを使ってJobのドラフトを作成してくれます。
3rd PartyのIdProviderやKey Storageと組み合わせて利用することもでき、オンプレ環境に対してもインターネット側からセキュアにアクセスする方法を用意しています。
ユースケース
RBAは汎用の自動化プラットフォームであるため、インシデント対応以外にも様々な用途で利用できます。
一番ベーシックな利用方法は、定期実行Jobのスケジューラーとして利用することです。cronを使って各サーバーで実行しているJobをRBAで一元管理すると、実行スケジュールやログの管理、Jobが失敗した際の再実行、管理者への通知などを簡単に行うことができるようになります。
ここでは利用のイメージを持っていただくために、インシデント対応とPlatform Engineeringの例をいくつかご紹介します:
Runner: オンプレ環境でもJobを安全に実行する仕組み
オンプレ環境でも、Runnerを利用することでFirewallにInboundの穴を空けずにJobを実行することができます。
RunnerはJava11で動作するプログラムで、HTTPS/TCP443を利用してRBAとコネクションを確立します。以降は5秒ごとに実行すべきJobがないか確認し、JobがあればDC内のノードを操作して実行、その結果をRBAに返します。
日本語チュートリアル
Runbook Automationの設定方法やトラブルシューティングについては、日本語のチュートリアルを用意しました。
Runnerを含む環境構築の手順、基本的な操作から少し高度なワークフローの制御まで、Jobのサンプルと併せて確認できるようになっていますので、ご興味がある方はぜひお試しください。
自動化に適した作業とは？
最後はどんな作業を自動化すべきかについて考えてみたいと思います。
自動化はあくまで手段であり、目的ではありません。どのような効果を期待するのか、そして高い効果が期待できる作業を見極めることが重要です。
一般的に以下のような作業は、工数削減・ミスの回避・処理の迅速化などで高い効果が期待できます:
- 繰り返し発生する定型作業
- ミスが許されないクリティカルな作業
- 証跡を残す必要がある作業
「繰り返し発生する定型作業」の例:
- インシデント対応
- 一次診断(ログ収集、関連メトリクスの確認、Webページの正常性確認)
- 自動復旧(サーバーの再起動)
- 不正アクセス対策(攻撃者の送信元IPをブロックリストに追加)
- 外部ツールへの情報連携(Slack/Status Page/JIRA)
- メンテナンスに伴う監視・通知設定の変更
- Platform Engineering
- 開発環境の構築(リソースのプロビジョニング、アクセス権の付与・変更)
- QAテスト
- バッチ処理
- DR対策(定期的なバックアップ、リストア試験)
- ビジネスオペレーション
- 監査用ログ収集・レポート作成
- 社員の入社等に伴う諸手続き(ユーザーアカウントの追加・削除・権限設定の変更)
インシデント対応に関しては、解決までに時間のかかっているサービスや作業をPagerDutyのInsightレポートやポストモーテムの機能を活用して分析することができます。
自社にとって自動化の効果の高い作業を見極めるために、活用いただければ幸いです。
PagerDuty設定ガイド 目次
検知編 | トリアージ編 | 動員編 | 解決編 | 学習編
- 一次対応を自動化する
- Alert Groupingでアラートノイズを削減する
- Auto Pauseで一過性アラートの通知を削減する
- Event Orchestrationでアラートへの対処を自動化する
- [診断や復旧作業他を自動化する] << イマココ