PagerDuty Operations Cloudの導入効果をレビューでご紹介(ゆーた-株式会社ココナラ)
参考になった
11
株式会社ココナラ / Yuta Kawasaki（ゆーた）
開発部長 / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 |
|---|---|---|
Bussiness | 11名〜50名 | 2016年 |
| 利用プラン | Bussiness |
|---|---|
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2016年 |
アーキテクチャ
アーキテクチャの意図・工夫
元々は各監視ツールから各々Slackに通知しており、架電できていないものも一定存在していた。そこをPagerDutyへ全て連携することで、アラートの一元管理と漏れのない架電対応を実現している。
導入の背景・解決したかった問題
導入背景
※株式会社ココナラでは2016年からPagerDutyを導入しており、2020年の入社以前の記載については、一部想像が含まれております。
2016年当時、AWSのメトリクス監視ツールから通知メールを使用して管理体制を運用していた。当番制を導入していたが、PagerDutyのように直接の電話通知がないため、メール通知に気づかなかったり、ミーティング中や深夜の時間帯などにメールを見逃してしまい、対応が遅れることがあった。PagerDutyを導入する前のMTTA（平均確認時間）は約10分だったが、現在は電話通知も行われており、確認時間は1分以内に短縮されている。
比較検討したサービス
- 外注
- Amazon Connect
- 内製(社内メンバーによる24時間,365日の監視体制）
選定理由
2016年当時はエンジニアの人数は1桁人数〜10名程度でした。 24時間・365日の安定稼働を実現するには多くの人数が必要で、アウトソースするにもコストが掛かるので、SaaS(PagerDuty)なら費用対効果が高いと判断したのではないでしょうか。 前職で、PagerDutyを費用対効果を鑑みて、同じような理由で採用していたのでそう推測できます。また、監視はAWS内だけではなくDatadogなどのサードパーティも活用していたため、それらとの親和性を考慮するという判断もあったかと思います。
導入時の苦労・悩み
PagerDuty導入・浸透のために以下のようなオンボーディングを実施する必要があった。
- 導入初期
- PagerDutyの使い方や、そもそものオンコール対応のルール等に関するドキュメントの作り込み
- 人員増加の過渡期
- バッヂ処理が原因でアラートが発生する問題が発生したが、その問題に対処するためのナレッジ整備
- バッヂ処理が問題で落ちたものや、どれくらいのデータ量を取り込むかなど判断基準に悩むものをランブックにまとめる
- 放置していいものや自分たちで応答しなければならないものをランブックにまとめる
結果として、新たに入ったオンコール担当者が困ることはさほど多くなく、効果が出ていると考えている。
導入に向けた社内への説明
上長・チームへの説明
「費用対効果」と「使いこなせるか」という2点で説明した。 前者は外注した場合の費用よりも明らかに安価だったので、そこはクリアできていたと考えられる。 後者は当時は英語のマニュアルのみだったが、今は日本法人もできたので改善されつつある。
あまり細かい試算や算出はしていないが、オンコールの対応の仕組みがなかったら何が起きるのか、それがサービスへどのような影響をもたらすのか、それに対応するために外注・内製・PagerDutyの利活用をした際にそれぞれがどれくらいのコストになり、それぞれを採用する場合のメリット・デメリットを説明した。
活用方法
よく使う機能
定常的に（週に1度くらい）インシデントの発生状況と、対応漏れのアラートがないかを確認している。また、オンコール担当者ごとにどれくらいインシデント対応が発生しているかなども併せて見るようにしている。その他、経営上のインパクトがあるインシデントは抽出して経営層へのレポートに使用している。
- Incidents
- アラートに1対1対応をしているNotesを見ながら、根本対応が終わっているかどうか、対応が詰まっているチケットがないかなど、未クローズのインシデント状況の確認をしている。
- Insights
- 平均対応時間やインシデント発生傾向などのデータを日別にモニタリングすることで、どの施策で作り込まれた不具合であるかをPdMにフィードバックするための材料にしている。また、人単位で集計を行うことでオンコール対応者の負荷の偏りを確認し、その結果をもとに分散を行ったり、コンディションの把握に活用している。
ツールの良い点
- 柔軟なアラート設定が可能
- Datadog、Amazon CloudWatch、Sentryなどのサードパーティの監視ツールと連携して、重要度を見極めた上で各種アラートの発報を適切な形（架電やSlackでの通知）で行うことができる
- 緊急性・重要度に応じてアラートを識別し、その重さによって通知の方法を変えることができる
- 特定期間における通知の抑止が柔軟にできるなど、24時間365日の監視体制に欠かせないサービスが安価で利用できる
- シフト管理が容易
- シフトの作成や変更が容易である。また、オンコールの対応状況と報酬を連動させる上で、ファクトとして実際に稼働しているかどうかをPagerDutyで可視化できるので管理もしやすい。
- サービスの品質が高い
- 誤動作や、アラートがうまく発行されないケースなどは相当少ない。
ツールの課題点
- 日本語ドキュメントが少ない
- 日本法人が新しく設立されたばかりで、日本語のドキュメントがまだ少ない。主要な情報は英語のドキュメントで提供されているので、導入を検討している方はその点を考慮して、覚悟を持って取り組んで欲しい。
- CSのサポートはもう少し伴走してほしい
- ただ自分たちが使えていないだけかもしれないが、新機能の紹介や、使えていない機能に対して、他社がどのように活用しているかなどのベストプラクティスをシェアしてくれるなど、もう少し伴走してくれると嬉しいです。
- アラートのトリアージ機能が欲しい
- 機械学習的なアプローチなどを用いて、Lamdaで検知したアラートに対して「これは対処しなくてもいいです」と表示したり、自動でランブックに加えたりする機能があると嬉しい。また、新しいアラートや問題が発生した際に、それが以前に経験したことがないかどうかを識別して「これまでに出たことがないアラートです」のような表記も欲しい。
その他
PagerDutyやオンコール対応に関する事例がなかなか出回らず、プロダクト規模によって体制も異なるので、独自に色々頑張っている方も多いと思います。これはPagerDutyのコミュニティに期待していることですが、もっとユーザーがナレッジを横展開したり、みんなが困っている苦しみを集合知で解決できるような場があったら嬉しいです。
ツールを検討されている方へ
24時間・365日 で動いているサービスの前提として、みんなが動ける体制を構築することが必要だと思います。「検知して対応する」という流れの中の「検知」の部分で、様々あるサードパーティの情報を全部まとめるというプロセスが第一歩目になると思います。現時点でPagerDutyを代替するツールやサービスはないと考えています。総じて費用対効果高くいいツールだと思っているので、これからオンコール対応を検討している企業で1回試さないのは損だと思っています。
株式会社ココナラ / Yuta Kawasaki（ゆーた）
開発部長 / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
2020年にココナラへジョイン、Head of Informationとして、プロダクトインフラ・SREと社内情報システム / セキュリティを管掌している。 2024年からココナラテックの執行役員 情報基盤統括本部長を兼任。 2025年からココナラのDev Enabling室 室長を兼任し、技術広報を中心とした開発の進化を進めている。
よく見られているレビュー
株式会社ココナラ / Yuta Kawasaki（ゆーた）
開発部長 / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
2020年にココナラへジョイン、Head...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法