LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログ

PagerDutyを導入して障害対応の体制と運用ルールを確立しました

Webエンジニアの古賀です。LCLでは、障害対応の強化の一つとして多機能な通知機能を持つPagerDutyを導入しました。 組織的な対応シフト・フローが組めるようになり、精神的にとても安心できるようになったので紹介させていただきます。

pagerduty.digitalstacks.net

導入前の課題

LCLでは、Mackerelを利用して各サーバの監視しており、障害が発生するとチャットでエンジニアへTO(メンション)で通知をしていました。 この運用方法では、以下のような問題がありました。 

  • 全エンジニアへの通知のため、早めに気づくエンジニアが固定の担当になりがち
  • TO(メンション)の重要度が高く、通常のやりとりで使いづらい
  • 通知は一度しかこないため、他のチャットで埋もれてしまい見逃す可能性がある

f:id:lcl-engineer:20181129210414p:plain

チャットでの障害通知では限界が見えてきて、何かいいサービスはないか検討していたところPagerDutyを見つけました。

PagerDutyとは

Mackerel、Datadogなど監視サービスからのアラート通知を受け取り、決められたシフト・フローに従って通知を行ってくれるサービスです。様々な機能がありますが、LCLの課題解決につながったものは以下になります。 thinkit.co.jp

多様な通知方法とスヌーズ

  • 電話・SNS・アプリなど通知方法が豊富
  • 初回はPUSH通知、応答がなければ5分後に電話などスヌーズで見逃し防止
  • 通知音も変更可能なので、他のアプリと差別化しやすい

対応担当のスケジューリング

  • サービスごとにスケジュール設定が時間単位で可能
  • 複数レイヤー管理なので週ローテに対して、特定日だけ交代などが簡単にできる
  • Googleカレンダーにも連携可能

f:id:lcl-engineer:20181129105658p:plain

エスカレーション機能

  • 設定された時間内に応答、障害解決されなければ上位の担当者へ自動通知される
  • アプリ上での手動エスカレーションもできる
  • 見逃しや解決に時間がかかっている場合の共有が自動化できる
  • LCLで初動は当日のシフト担当、2次は関連エンジニア全員とした

f:id:lcl-engineer:20181129105723p:plain

導入後の対応体制

障害通知

チャットでの障害通知をやめ、PagerDutyでエンジニアの各端末に直接通知を流すようにしました。

  • 発生時にアプリのPUSH通知(障害と分かる通知音に設定)
  • 5分間応答がなければ再アラートとして電話連絡
  • 10分間応答がなければ自動でエスカレーション

アプリで確実な通知が受け取れるようになったので「見逃してないか??」の疑心暗鬼がまず解消しました。 万が一見逃しても自動的にチームにエスカレーションされるフローとなっています。

対応フロー

週ごとに割振りを決め障害担当のシフトを組むようにしました。初動は担当者がコントロール。 導入前は担当者の責任が重くなりすぎる?という不安がありましたが、実際は対応フローが明確になりチームとして非常に動きやくなりました。

  • 通知を受けた担当が障害の状況を確認
  • 突発的なアクセス増などの一時的なアラートなら様子見
  • 重障害や判断迷ったらエスカレーションしてチームで対応にあたる
  • 10分で解決の動きがなければPagerDutyが自動的にエスカレーション

エスカレーション機能で関連エンジニアに共有できるのが非常に嬉しく、「困ったら遠慮せず!」をキーワードにしています。 対応が順番で回ってくるので個々のエンジニアにも責任感が生まれ、障害対応のいいナレッジが溜まっていきそうです。

※ シフト制で担当になった場合は、待機・対応手当が当然支払われます

まとめ

PagerDutyの導入によって組織的な障害対応ができる環境が整ってきました。まだまだ導入したてなので改善を加えていき障害に強いチームを育てていきたいですね。 ナレッジが溜まってきましたらまた記事を追加していきたいと思います。