SODAにおける PagerDuty を利用したインシデント管理

ツール導入前の課題

以前は緊急のアラートをSlackのグループメンションを利用していました。タスクに集中している時や深夜においては、Slackやメールの通知が埋もれてしまうことが多く、重要なアラートが見過ごされる可能性があり、特定の担当者に負荷が偏ってしまう問題もありました。

どのような状態を目指していたか

オンコールスケジュールの管理ができ、オンコールの負荷が分散すること、全てのアラートが確実に担当者に届き迅速に対応をできることを目指していました。

1. 簡単な連携

主に使用しているDatadogとのインテグレーションがあり、簡単に連携できたことが非常に大きなポイントでした。

2. オンコールスケジュールの管理の容易さ

オンコールスケジュールの作成や変更、確認が簡単であり、公式サイトのドキュメントやブログが充実していたため、導入後の運用もスムーズに進められました。

3. イニシャルコストがないこと

テスト利用が無料でできたため、導入前に試用できたことも安心して選定できた理由の一つです。

オンコールスケジュールの管理、電話での通知を自動化することで緊急時の対応が分散され、対応漏れを防ぐことができています。

導入時にはいくつかの課題がありました。特にSODA社内で運用をしている、RunbookやPlaybookの整備には時間がかかりました。担当者のノウハウをドキュメント化し、全員が対応できるようにするために、最初の数回は経験豊富な担当者が伴走し、フォローを行う必要がありました。

サービスは常時稼働していることが前提であるため、オンコール担当を適切に設定することで、運営の負荷を分散し、致命的なインシデントを見逃すことなく対応する体制を整えることができます。 信頼性の高いサービス運営を目指す企業にとって、PagerDutyは有力な選択肢の一つとして検討する価値があると思います。

アラート前に社内やユーザーの問い合わせでインシデントが発覚することがあるため、アラートがそれなりに充実していないと拾えるアラートが少ないため今後もっと拡充をしていきたいと考えています。 便利な機能はたくさんあるけど活用がまだできていない物が多く、今後 Postmortems を利用してポストモーテムのタイムライン管理、分析の改善につなげていきたいと考えています。