10Xにおけるサービス信頼性を支えるPagerDuty導入事例

ツール導入前の課題

導入前は、アラートの検知時はSlackへの通知を行いエンジニアが対応に当たっていました。サービス規模の拡大とともにインシデントも増加傾向にあり、以下のような課題が顕在化していました。

• 対応担当のオーナーシップが曖昧
• アラートの対応ステータス管理が不足している
• 対応すべき問題の増加に対して担当者の分散や当番といった仕組みが不十分

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

問題の検知から解消までを漏れなく確実に行い、それを開発チーム内で持続的に行えるよう以下の状態を目指しました。

• アラート検知から担当者アサインおよび対応が迅速に開始されること
• 対応ステータスを管理しclose漏れ等の問題が起きないこと
• 担当者の分担やローテーションを仕組みで実現できること

• Grafana OnCall

不具合に気づくための要となるので、稼働の安定性や実績を重視しました。
また、サービスや関わる開発メンバーの増加が見えていたので、導入時点で見えていない様々な要件に対応できるだけの機能の豊富さもポイントとして見ていました。

信頼性向上の観点では、まず対応漏れなどのオペレーションミスによる問題を無くすことができました。また、レポートされるインシデントは以前だと問い合わせ経由での発覚などが多くを占めていましたが、システムアラートで早期に検知できる問題も増えてきました。これはPagerDutyだけでなく周辺のモニタリング体制も合わせて整備した効果が現れてきているかなと思います。

運用体制自体をゼロから構築するため、PagerDutyの活用に伴う周辺整備も含めた対応が特に大きかったと思います。具体的な例だとアラート対応担当者の洗い出しやアラート数自体の低減、対応手順のRunbook化や、PagerDuty通知時の緊急度の定義など多岐にわたります。こうした導入の際に取り組んだ事については以下でも紹介しているので、気になる方は参照ください。

• スタートアップの急成長に寄り添うOn-Call体制構築とその変遷 - Speaker Deck
• PagerDuty を軸にした On-Call 構築と運用課題の解決 - Speaker Deck

開発するサービスが大きくなってきて信頼性の要求レベルが上がると、PagerDutyは確実に必要になってくるツールの一つだと思います。 Pagerの導入は開発運用現場に一定のストレスをかける事でもあり、導入初期ではメリットだけでなく痛みも伴う場面があります。しかしその負担をどう減らせるか考え始めると、自然とオペレーション改善、社内制度づくりの必要性、はたまたサービスやモニタリングの品質向上など多岐にわたる課題に目が向くようになります。それらの多くは元々課題感としてあったものの、なかなか優先度が上げられず手をつけられていなかったものも多いと思います。

そうした問題への温度感を高め、優先度を上げて対応していくためのきっかけづくりとしても、PagerDuty導入やOn-Callの仕組みを導入していくのは良いきっかけになると考えています。

導入当初の課題で大きかったアラート検知以降のオペレーションは安定稼働してきていますが、そもそも検知するアラートの数自体を減らすなど、オペレーションコスト削減はまだやれることが多くある状態です。

例えば各チームでのアラート発生状況の詳細分析やさらなるモニタリング改善、問題検知後のリカバリオペレーション自動化など、アラートを人間が受ける頻度を限りなく下げる・より少人数のResponderでOn-Callを回せるようにするなどの改善ができると良いなと考えています。