Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PagerDuty を軸にした On-Call 構築と運用課題の解決 / PagerDuty ...
Search
horimislime
October 21, 2024
Programming
1
320
PagerDuty を軸にした On-Call 構築と運用課題の解決 / PagerDuty Japan Community Meetup 4
horimislime
October 21, 2024
Tweet
Share
More Decks by horimislime
See All by horimislime
スタートアップの急成長に寄り添うOn-Call体制構築とその変遷
horimislime
3
1.9k
How we build our app with minimum 3rd party dependencies
horimislime
0
100
サポート効率を上げるためのロギング環境構築
horimislime
7
3.9k
migrating-from-promise-to-reactive
horimislime
0
400
社内Swiftもくもく会成果発表
horimislime
0
140
Swift Optional Extension Tips
horimislime
1
1.6k
ios-internationalization
horimislime
2
8.9k
UI testing in XCode7
horimislime
3
820
UIテストをカジュアルに自動化 / UI Automation using Remote
horimislime
2
2.4k
Other Decks in Programming
See All in Programming
Local Peer-to-Peer APIはどのように使われていくのか?
hal_spidernight
2
440
GitHub Actions × AWS OIDC連携の仕組みと経緯を理解する
ota1022
0
230
Current States of Java Web Frameworks at JCConf 2025
kishida
0
580
CSC509 Lecture 03
javiergs
PRO
0
320
プロダクト開発をAI 1stに変革する〜SaaS is dead時代で生き残るために〜 / AI 1st Product Development
kobakei
0
440
Advance Your Career with Open Source
ivargrimstad
0
260
プログラミングどうやる? ~テスト駆動開発から学ぶ達人の型~
a_okui
0
190
uniqueパッケージの内部実装を支えるweak pointerの話
magavel
0
880
猫と暮らすネットワークカメラ生活🐈 ~Vision frameworkでペットを愛でよう~ / iOSDC Japan 2025
yutailang0119
0
210
CSC305 Lecture 02
javiergs
PRO
1
260
Pythonスレッドとは結局何なのか? CPython実装から見るNoGIL時代の変化
curekoshimizu
4
1.2k
WebエンジニアがSwiftをブラウザで動かすプレイグラウンドを作ってみた
ohmori_yusuke
0
170
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
Designing for humans not robots
tammielis
254
25k
KATA
mclloyd
32
14k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
How to train your dragon (web standard)
notwaldorf
96
6.3k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Unsuck your backbone
ammeep
671
58k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Docker and Python
trallard
46
3.6k
Transcript
PagerDuty を軸にした On-Call 構築と運用課題の解決 PagerDuty Japan Community Meetup Vol.4 2024/10/21
Soichiro Horimi (@horimislime)
本日お話しすること 弊社での PagerDuty 導入・利用事例について紹介 会社やプロダクトのスケールとともに、各フェーズでどのような施策を行ったか 機能として何をどう使ってきたか、周辺ツールとの連携も含めて解説
自己紹介 堀見 宗一郎 X: @horimislime https://horimisli.me 株式会社 10X でアプリ/バックエンド →
現在 SRE チーム ネットスーパー立ち上げ SaaS「Stailer」の開発
弊社と PagerDuty 遡ると 2021 年末ごろから incident 増加やサービス拡大を機に PagerDuty を検討開始 いくつかの選択肢のなかでの決め手
当時まだ SRE チームというものが存在しなかった 安定して稼働やノウハウ蓄積を重視 機能面の豊富さも重要ポイント
スモールスタートでの導入開始 まず問題を確実に検知し解消までステータス管理したい 当時監視に使っていた Google Cloud Monitoring からまずは PagerDuty 連携開始 アラートの精査や担当割り振りなどは整理しきれていない状態
PagerDuty 側の自動化機能で担当を割り振る Ruleset(現 Event Orchestration)を活用 全て PagerDuty に流して取りこぼしを無くしつつ、わかる範囲で担当分類 初期は担当分類しきれないものが多く、catch-all で新設
SRE チームが受け皿に
運用・スケールへの一歩 まずは取りこぼしを防ぐ状態ができたが、マンパワーで解決する状態 ローテの仕組みがなく皆 always on-call アラートを受けても対応方法が分かりづらい アラート数が多い、優先度が不明瞭、などなど → オペレーションから改善が必要
各自が頑張る運用から On-Call の体制へ SRE 内から On-Call 体制をロールプレイ PagerDuty Incident Response
Guide をベー スに内部向けドキュメントを作り込み Corp 側とスムーズに待機体系も完成 On-Call Schedule で配信される webcal で Corp 側が手当を算出可能に
Runbook 運用 GitHub repository 上に docs 置き場を用意し markdown で記述 kubernetes
で稼働しているものは deployment や job をファイル名に kubernetes manifest を変更した際の document 有無を GitHub Actions でチェック モニタリング側で エラー検知時に job 名から GitHub Markdown へリンクし通知
On-Call の民主化へ 一定運用が回るようになったが、依然として作業負荷が大きい 日々増えるシステムコンポーネントの監視設定を開発側でも行いたい 新入社員対応やチーム組み替え・移動に柔軟に対応したい 緊急度に応じてアラートを最適化して負荷を減らしたい → SRE 側の属人性排除・トイル削減が重要
Terraform module でチーム毎に必要な設定を自動化 Terraform での IaC を推進、PagerDuty Business プランアップグレード 各チームが簡単な記述で監視設定を自動生成できる
Terraform Module を運用 チーム発足から On-Call 開始までの手続きを全てコード化 新入社員も Self Onboarding 可能に。SRE は PagerDuty のシート確保のみに
Severity ベースでアラートを最適化 CronJob などの処理が失敗した際の致命度を SEV1〜4 で社内定義 k8s manifest で SEV
や担当を label で設定、metrics を監視できるように これらも Terraform で一括自動生成
営業時間に応じた対応 Business Hour ベース通知で実現 営業時間外は Dynamic Notification 低 Urgency アラートは
Slack 通知・翌朝対応
PagerDuty をシンプルに保ちながらスケールする あえて Orchestration などアラートに対する自動化をやめている 自動化設定が SRE の暗黙知になりやすい、設定更新漏れが起こりがち 代わりにチーム・SEV 単位で監視ルールを用意する形に
その代わり大量の監視を設定する必要がある IaC が成熟してきた今のフェーズだからできた → 今だとこっちの方がフィットしてる
約 3 年の運用を振り返る その時その時で、事業や組織で求められる体制を実現してきた PagerDuty の豊富な機能をフル活用、という感じではない フェーズごとに変わる最適な技術選択を、豊富な機能から行えるのが魅力 立ち上がり期は PagerDuty 側の自動化機能などを活用
成熟期では周辺ツールとうまく integrate し良いとこ取り
今後の展望 この先も PagerDuty を基盤とした活用方法は変わってくる On-Call 自体は安定してきているが、まだ考えられることは多い 例: より高度な自動化、例えばアラートを自動解消して負荷を減らすなど 事業が成長し人が増えていく限り課題は無限で、それが面白い部分 SRE
以外の力も不可欠。絶賛 SWE 採用やってます https://10x.co.jp/recruit