PagerDutyでアラート管理を改善した話

2020年1月31日公開 2021年6月24日更新

はじめに

こんにちは。インフラストラクチャー部のひらしーです。今回はPagerDutyを導入し、システムに異常が発生した際のアラート管理を改善した話を紹介します。

アラート管理改善前

解決すべき人へのエスカレーションが必要な問題発生時、以前は以下のような問題がありました。

通知手段がメールのみで、インフラチームのメンバーは全サービスのアラートを受け取って自分でフィルタリング・転送をする必要があり、問題のエスカレーション漏れや監視設定自体の見直しがされずに監視精度のばらつきが発生していた
過去のアラート情報が集約できておらず、問題の傾向把握や類似の障害の検索が困難だった

PagerDutyについて

上記の問題を解決するため、メール運用のまま手法のみ改善する運用や内製ツールの開発を検討しましたがトライアルでチーム内での評価が高かったためSaaSのアラート管理ツールであるPagerDutyを採用しました。

インシデント管理

PagerDutyでの運用では解決すべき問題の単位を「インシデント」で管理します。インシデントはITマネジメントの分野ではITIL (Information Technology Infrastructure Library)で以下のように定義されています。

Incident
An Incident is defined as an unplanned interruption or reduction in quality of an IT service (a Service Interruption). インシデントは、ITサービスの計画外の中断または品質の低下（サービス中断）として定義されます。ITIL Wiki#Incident Management より

このインシデント管理を以下のように運用しました。

各種監視システム・ツールからアラートを発報
PagerDutyにインシデントが作られ、サービス担当者が自分で指定した各種メディア(mail,PagerDutyスマートフォンアプリ)に通知、同時にWebhook機能にてエンジニアチームのChat Room(Chatworkを利用)に通知
サービス担当者がインシデントを確認、解決すべき人にエスカレーションし対応状況を追記していく、対応が完了したらインシデントをクローズ

インシデントレビュー

適切なアラート流量での運用を保てないとサービスの健全性を失うので、監視設定を実施するエンジニアは以下のような観点で定期的にPagerDutyで管理しているインシデントをレビューしています。

サーバ・監視に適切な監視項目セットと内容(閾値、監視間隔、リトライ)が設定されているか
インシデントの重要度が適切か。重要度の低いアラートが大量に通知されると「オオカミ少年効果」により障害対応の遅れや漏れが発生してしまうリスクがあります。(余談ですがPagerDutyは対応者への最終的な通知先は「high-urgency(今すぐ対応すべき)」か「low-urgency(今すぐ対応しなくても良い)」しか定義できないという対応者の混乱を防ぐシンプルな仕様になっています)
サービスのライフサイクルに影響するインシデントか(ピークタイム、メンテナンス前後に発生するものであれば、その対策を検討)

Chat運用

インシデントレビューにてアラート流量がコントロールし易くなったためサービス単位でチャットツール(Chatwork)でのインシデント運用を導入しています。以下は昨年末発生したアプリケーションログのローテーション期間が長く、ディスク圧迫が発生した時のやり取りですが、PagerDutyのwebhook機能を利用しアラート発報からチームへの通知、エスカレーションから具体的な対応報告とスムーズにコミュニケーションできるようになりました。