PagerDutyを活用したオンコール運用の軌跡
こんにちは！
株式会社ココナラのHead of Informationに任命された ゆーた（@yuta_k0911）です。
PagerDuty Advent Calendar 2023の18日目の記事です！
ココナラでは2016年からPagerDutyを使っています。（私が入社する4年も前から・・・）
PagerDuty導入以前のオンコール運用や導入後から現在に至るまでどのような利用・工夫をしていて、今後どう利活用しようとしているか？をアドベントカレンダーの記事にしてみます！
私の推し機能も紹介します。
ぜひ、PagerDutyを利用検討中の方もご覧ください！
実は会社名義でアドベントカレンダーに参加するのはこれが初めてです💦
初歩的な内容が多いと思いますが、お付き合いください🙇♂
ココナラでのPagerDutyの使い方
PagerDutyを使い始めたのは私が着任する前ですので、想像で書いている箇所もあります。
PagerDutyを使い始める前のオンコール運用
2016年当時はAWSのメトリクス監視ツールからメールによる通知を利用した管理体制で運用していました。
エンジニアの人数も10名未満でした。
オンコールの当番制を導入していましたが、PagerDutyのようなツールを用いておらず、直接の電話通知機能がありませんでした。
そのため、以下の課題が発生していたと思われます。
- 当日のオンコール担当者が誰かがわかりにくい
- アラートの通知がメールのみなので、オンコール担当者がアラートに気づけなかった or 気づいたが動けない場合のエスカレーションが滞り、アラート対応が遅れる
- ↑の結果として、MTTA（平均確認時間）は約10分程度と長くなってしまっている
24時間・365日の安定稼働を実現するには自社内の人手で対応するのは非現実的です。
オンコール体制ごとアウトソースするには莫大なコストが掛かるので、SaaSを利用することで費用対効果の高いオンコール運用を目指したと思われます。
私の前職でも、費用対効果を鑑みて、PagerDutyを同じような理由で採用していました。
もともとココナラの監視はAWSサービス以外のDatadogなどのサードパーティ監視ツールを活用していたため、それとの親和性も考慮した結果とも言えます。
現在のオンコール運用
繰り返しではありますが、現在のココナラではPagerDutyを利活用し、オンコール運用を実現しています。
エンジニアの人数も大幅に増えました。オンコール体制に入っているエンジニアは40名弱です。
ざっくりですが、ココナラのオンコールシステムと運用を図にしてみます。
ココナラのプロダクトはAWS上で稼働しています。
そこを複数の監視サービスでメトリクスをモニタリングしており、異常を検知したら、PagerDutyを介してオンコール担当者へ電話もしくはSlackで通知する仕組みを採用しています。
オンコール運用の各論として、以下を日々の運用の中で行っています。
- オンボーディング資料の拡充（PagerDutyの使い方含む）
- アラートの対処方法のナレッジ化（対応要否やバッチ処理のリランのやり方含む）
- 有識者と新任者のペアリングによるオンコール運用のスキルトランスファー
また、オンコール運用を効率的・効果的にするために一部自作しています。
これは私が着任したときから活用されているものなので、当時は類似機能がなかったのでは？と想像しています。現在はPagerDutyに類似機能が存在しているものもあります。
1. 当日のオンコール担当者をSlackに通知
毎日10時にオンコールシフトを切り替えており、そのタイミングで当日の担当者を通知しています。
自身のカレンダーに自分のオンコールシフトを連携している方が大多数ですが、これによって認識漏れを防ぐことにも繋がります。
2. アラート発生時に当日のオンコール担当者へメンション
アラートが発生した際に、その日のオンコール担当者へSlackにメンションを行うことで、より気づきやすい仕組みを実現しています。
反応が一定期間ないとリマインドをしてくれるので、オンコール担当者以外もアラートの未反応・未対応に気づきやすくなっています。
3. アラートのキーワードを元にRunbookを通知
既出のアラートであらかじめRunbookを用意しているものに限定した話です。
通知された内容のキーワードを元にRunbookをSlackに通知しています。これによって、Slackだけでインシデント対応を進めることが可能です。
いろいろ書き連ねましたが、これらの対応にて MTTAを1分程度 まで短縮することができています！🎉
PagerDutyがオンコール運用の要と言っても過言ではありません！
PagerDutyの推し機能
こちらでご紹介する機能は個人的な推しですので、ココナラ全体での利活用はこれからです！
Incidents
アラートに1対1対応をしているNotesを見ながら、根本対応が終わっているかどうか、対応が詰まっているチケットがないかなど、未クローズのインシデント状況の確認することで、抜け漏れを防ぎます。
Insights
MTTR（平均対応時間）やインシデント発生傾向などのデータを日別にモニタリングすることで、どの施策で作り込まれた不具合であるかを分析し、例えばPjM / PdMにフィードバックするための材料にしています。
また、人単位で集計を行うことでオンコール対応者の負荷の偏りを確認し、その結果をもとに分散を行ったり、コンディションの把握にも活用しています。
今後、取り組んでみたいこと
「推し機能」の一例をご紹介しましたが、他にも有益な機能を兼ね備えているので、適宜PoCしていきたいです！
PagerDuty社の「Operations Cloud」を利活用していくことで、インフラ・ワークフローの最適化にも挑戦したいと考えます。
また、ココナラで実装した機能のいくつかは「車輪の再発明」になっているので、どこかでPagerDuty側の機能へ寄せることも検討します。
最後に以下の点はPagerDuty社だけでなく、ユーザー企業と一緒になって進めていきたいと思っています！
-
日本語ドキュメントの拡充
- 日本法人が新しく設立されたばかりということもあり、日本語のドキュメントがまだ少ない（主要な情報は英語のドキュメントで提供されている）
-
CSのサポートによるオンボーディングや伴走
- （ココナラで使い切れていない部分も多数あるが）新機能の紹介や、現時点で未利用の機能に対して、他社がどのように活用しているかなどのベストプラクティスをシェアしてくれる機会などがあると良い
-
アラートの自動トリアージ機能
- 機械学習的なアプローチなどを用いて、「これは対処しなくてもいいです」と表示したり、自動でRunbookに追加されるなどの機能があると嬉しい
- また、新しいアラートや問題が発生した際に、それが以前に経験したことがないかどうかを識別して「これまでに出たことがないアラートです」のような表記ができるとより良い
PagerDuty Summit 2023でも近しい話をしていますので、以下の記事もご覧ください！
これから導入を考えている会社に伝えたいこと
24時間・365日で動いているサービスの前提として、「必要なタイミングに必要な人が動ける体制を構築する」ことが必要不可欠です。
「検知して対応する」という流れの中の「検知」の部分で、様々あるサードパーティの情報を全部まとめるというプロセスが第一歩目になると考えます。
現時点でPagerDutyを代替するツールやサービスはないと考えています。総じて費用対効果が高く、良いツールだと思っているので、これからオンコール対応を検討している企業で1回試さないのは損だと思っています。
ただし、前述の通り、課題もいくつかあります。まずは利用企業の事例を参考にPoCなどに取り組むと良いです。
ココナラのPagerDuty利用事例は記事にもなっていますので、ぜひご覧ください！
Discussion