Slide 1

Slide 1 text

PagerDuty を軸にした On-Call 構築と運用課題の解決 PagerDuty Japan Community Meetup Vol.4 2024/10/21 Soichiro Horimi (@horimislime)

Slide 2

Slide 2 text

本日お話しすること 弊社での PagerDuty 導入・利用事例について紹介 会社やプロダクトのスケールとともに、各フェーズでどのような施策を行ったか 機能として何をどう使ってきたか、周辺ツールとの連携も含めて解説

Slide 3

Slide 3 text

自己紹介 堀見 宗一郎 X: @horimislime https://horimisli.me 株式会社 10X でアプリ/バックエンド → 現在 SRE チーム ネットスーパー立ち上げ SaaS「Stailer」の開発

Slide 4

Slide 4 text

弊社と PagerDuty 遡ると 2021 年末ごろから incident 増加やサービス拡大を機に PagerDuty を検討開始 いくつかの選択肢のなかでの決め手 当時まだ SRE チームというものが存在しなかった 安定して稼働やノウハウ蓄積を重視 機能面の豊富さも重要ポイント

Slide 5

Slide 5 text

スモールスタートでの導入開始 まず問題を確実に検知し解消までステータス管理したい 当時監視に使っていた Google Cloud Monitoring からまずは PagerDuty 連携開始 アラートの精査や担当割り振りなどは整理しきれていない状態

Slide 6

Slide 6 text

PagerDuty 側の自動化機能で担当を割り振る Ruleset(現 Event Orchestration)を活用 全て PagerDuty に流して取りこぼしを無くしつつ、わかる範囲で担当分類 初期は担当分類しきれないものが多く、catch-all で新設 SRE チームが受け皿に

Slide 7

Slide 7 text

運用・スケールへの一歩 まずは取りこぼしを防ぐ状態ができたが、マンパワーで解決する状態 ローテの仕組みがなく皆 always on-call アラートを受けても対応方法が分かりづらい アラート数が多い、優先度が不明瞭、などなど → オペレーションから改善が必要

Slide 8

Slide 8 text

各自が頑張る運用から On-Call の体制へ SRE 内から On-Call 体制をロールプレイ PagerDuty Incident Response Guide をベー スに内部向けドキュメントを作り込み Corp 側とスムーズに待機体系も完成 On-Call Schedule で配信される webcal で Corp 側が手当を算出可能に

Slide 9

Slide 9 text

Runbook 運用 GitHub repository 上に docs 置き場を用意し markdown で記述 kubernetes で稼働しているものは deployment や job をファイル名に kubernetes manifest を変更した際の document 有無を GitHub Actions でチェック モニタリング側で エラー検知時に job 名から GitHub Markdown へリンクし通知

Slide 10

Slide 10 text

On-Call の民主化へ 一定運用が回るようになったが、依然として作業負荷が大きい 日々増えるシステムコンポーネントの監視設定を開発側でも行いたい 新入社員対応やチーム組み替え・移動に柔軟に対応したい 緊急度に応じてアラートを最適化して負荷を減らしたい → SRE 側の属人性排除・トイル削減が重要

Slide 11

Slide 11 text

Terraform module でチーム毎に必要な設定を自動化 Terraform での IaC を推進、PagerDuty Business プランアップグレード 各チームが簡単な記述で監視設定を自動生成できる Terraform Module を運用 チーム発足から On-Call 開始までの手続きを全てコード化 新入社員も Self Onboarding 可能に。SRE は PagerDuty のシート確保のみに

Slide 12

Slide 12 text

Severity ベースでアラートを最適化 CronJob などの処理が失敗した際の致命度を SEV1〜4 で社内定義 k8s manifest で SEV や担当を label で設定、metrics を監視できるように これらも Terraform で一括自動生成

Slide 13

Slide 13 text

営業時間に応じた対応 Business Hour ベース通知で実現 営業時間外は Dynamic Notification 低 Urgency アラートは Slack 通知・翌朝対応

Slide 14

Slide 14 text

PagerDuty をシンプルに保ちながらスケールする あえて Orchestration などアラートに対する自動化をやめている 自動化設定が SRE の暗黙知になりやすい、設定更新漏れが起こりがち 代わりにチーム・SEV 単位で監視ルールを用意する形に その代わり大量の監視を設定する必要がある IaC が成熟してきた今のフェーズだからできた → 今だとこっちの方がフィットしてる

Slide 15

Slide 15 text

約 3 年の運用を振り返る その時その時で、事業や組織で求められる体制を実現してきた PagerDuty の豊富な機能をフル活用、という感じではない フェーズごとに変わる最適な技術選択を、豊富な機能から行えるのが魅力 立ち上がり期は PagerDuty 側の自動化機能などを活用 成熟期では周辺ツールとうまく integrate し良いとこ取り

Slide 16

Slide 16 text

今後の展望 この先も PagerDuty を基盤とした活用方法は変わってくる On-Call 自体は安定してきているが、まだ考えられることは多い 例: より高度な自動化、例えばアラートを自動解消して負荷を減らすなど 事業が成長し人が増えていく限り課題は無限で、それが面白い部分 SRE 以外の力も不可欠。絶賛 SWE 採用やってます https://10x.co.jp/recruit