トラシューアニマルになろう ～開発者だからこそできる、安定したサービス作りの秘訣～

Developers Summit 2025で登壇した資料です

障害対応のイマが分かる年に一度の祭典 PagerDuty on Tour Tokyo 2025、参加申し込み受付中です！
https://www.pagerduty.co.jp/pagerdutyontourtokyo/?cpcode=mktg-jacopen

Transcript

1. トラシュー アニマルに なろう 開発者だからこそ できる、 安 定 した サービス作りの秘訣
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup 代表理事 @一般社団法人クラウドネイティブイノベーターズ協会 Organizer @CloudNative Days
3. トラブルシューティング、してますか？
4. 普段から運用、携わってますか？ 運用しているといろいろ起きますよね
5. トラシュー アニマルに なろう
6. トラシューはいいぞ • 知識が定着する • 新たな知識を得られる • システム全体の解像度が上がる • 開発者としての視野が広がる • 論理的思考能力が上がる トラブルシューティングからしか得られない栄養がある
7. だからこそ • 自分の開発したものは自分で運用しよう • 開発者もオンコールのローテーションに入ろう まだ組織が小さいスタートアップなら、そうしている(せざるを得ない)ところも多いで す。 ですが、組織が大きくなるにつれ、開発と運用を分ける動きが生まれ始めます。で も、その分け方は本当に正しいのでしょうか
8. You build it, you run it. Werner Vogels, VP & CTO of Amazon
9. フルサービスオーナーシップとは 「コードを書いた者が、その責任を負う」 • 設計と実装の点から見て、テクノロジーに最も精通した人 が 製品開発ライフサイクル全体の責任を引き受ける 運用モデル • 本番環境において自分が書いたコードの責任を負うよう、 最もシンプルな形でエンジニアに権限を与える • 呼び方は色々ある • フルサイクル・デベロッパー (Netflix) https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
10. 製品開発ライフサイクル Build Test Ship Run Dev Ops
11. 製品開発ライフサイクル Build Test Ship Run Dev Ops
12. 障害のほとんどはデプロイによって引き起こされる “障害のほとんどはデプロイによって引き起こされる。した がって、デプロイが増えると障害も増え、結果としてインシデ ント管理、軽減策、ポストモーテムが必要となる ” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか より引用
13. そのサービスを一番よく知っているのは誰か それは作った本人 一番よく知っている人が、トラシューするのが最も早い
14. フルサービスオーナーシップ Build Test Ship Run
15. “コードに責任を持つ ” メリット • サービス品質が上がる • 開発と運用を分けず一貫して担当することで、リリース後の振る舞いまで 考慮してコードを書くようになる。だれも深夜に叩き起こされたくないの で。 • 障害対応の迅速化 • 開発者がオンコールにいれば対応のスピードが格段に上がる。 自分たちが開発したシステムを熟知しているため、原因特定や復旧が素 早く行える。
16. “コードに責任を持つ ” メリット • フィードバックループの高速化 • 開発者が日常的に運用に関与すると、ユーザーからの生のフィードバッ クや本番環境での問題点が直接開発チームに届く • 「不具合→修正」のサイクルが短くなり、サービスの継続的な改善がス ピーディーに行える • 運用負荷の軽減とチーム連携の強化 • 従来運用担当に集中しがちだった負荷が分散される 。特定の運用チー ムだけに深夜対応などの負担がかかる状況を和らげ、組織全体で信頼 性向上に取り組む姿勢が生まれる
17. トラシュー アニマルに なろう
18. 運用軽視の「無責任」コード • 必要なログが出ていない / 不明瞭 • エスパー力が求められる問題 • 逆にログが多すぎて探せない • 目grep力が求められる問題 • ログの出力方法が不適切 • 散在していてすぐに見つけられない • 再起動したら消える • 監視用のフックが存在しない
19. 運用軽視の「無責任」コード • 設定がハードコード • 接続先が変わるとコード修正が必要 • 実行環境に依存したコード • ブランチが分かれていて、それぞれの環境ごとに異なるコードベースを 使わないといけない • 開発と本番環境の不整合 • 手元では動くが本番環境で問題がおきる
20. 運用軽視の「無責任」コード • 依存ライブラリ解決が自動化されていない • ビルドのたびに特別な手順が必要 • デプロイ手順が複雑、手作業が多い • リリースの度にサービス中断が必要 • スケールアウトしづらい、ステートフルな設計
21. 運用軽視の「無責任」コード • 安全に停止できない • 起動に時間がかかりすぎる • サービス間の結合が強く、起動順序に制約がある • 運用手順の属人化・ブラックスボックス化
22. このような明らかなアンチパターンだけでなく 運用していくことで判明する 「ああやればもっと良くなる」 というポイントはたくさんある
23. 自分で運用をして辛さを味わえば、 「早く直そう」というモチベーションが湧く
24. 開発する ⇩ 障害がおきる ⇩ 🐅トラシューする 🐕 ⇩ 改善する
25. トラシュー アニマルに なろう
26. オンコール
27. オンコール 呼び出し
28. オンコール • 運用で緊急を要する事態が発生した際、 すぐに対応ができるように待機する勤務形態 • PagerDutyを導入している場合、PagerDutyによって呼び出される • フルサービスオーナーシップの場合、 開発者もオンコールのローテーションに入る
29. 疑問: 開発者がオンコールに入ると ベロシティが悪化するのでは
30. 疑問: 開発者がオンコールに入ると ベロシティが悪化するのでは • するよ • 一時的にベロシティの悪化は起きるので、トラシュー後はそうならないような仕組 み作りをしていくべき • ベロシティはあくまでも目安として考える • そもそもベロシティを目標にしてはいけない • サービスの安定性より優先されるベロシティに意味はない
31. 疑問: 開発者がオンコールに入ると ベロシティが悪化するのでは • 特定の人に負荷が集中してしまうのが良くない • 組織のサイズによって変わってくるが、月に3〜4日程度が理想 • 適切にスケジュールを組んで担当をバラしていく
32. オンコール 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 一次対応者 (応答がなければ) 二次対応者 オンコールの ローテーション
33. エスカレーションポリシー • 3-tierのエスカレーションポリシーが標準的 • 1st level サービスに責任を持つチームの誰か • 2nd level 1st levelで受け取れなかった通知をキャッチ • 3rd level チームリーダー、EM、プロダクトオーナーなど
34. 疑問: オンコールは SREがやるべきでは？ • 明確にNO • SREは信頼性を高めるエンジニアリングを行う専門家であって、オンコール専任 の仕事ではない • SREも開発者もオンコールローテーションに入る • プロダクトに関するインシデントはプロダクトチームが、プロダクトを跨ぐインシデン トはSREが担当するという棲み分けをしている例もあり
35. 「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run これを回すこと自体に責任を持たせる
36. 「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run オンコール
37. 「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run スケールアウトがしやすい実装 (コンテナオーケストレーターの自 律復旧に委ねる) ビルドやパッケージングの自 動化 素早いビルドの工夫 実行パラメータの外部注 入(環境依存の排除) トラブルシュートしやす いログの工夫 インフラのコード化
38. 「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run スケールアウトがしやすい実装 (コンテナオーケストレーターの自 律復旧に委ねる) ビルドやパッケージングの自 動化 素早いビルドの工夫 実行パラメータの外部注 入(環境依存の排除) トラブルシュートしやす いログの工夫 インフラのコード化 フィードバックループで改善を続け、呼び出しの頻度を減らす
39. 疑問: オンコールに入ると心理的負担が大きいのでは • これは重要なポイント • エンジニアの「燃え尽き症候群」への対処
40. 疑問: オンコールに入ると心理的負担が大きいのでは • 無理のないローテーション • 深夜対応を行った翌日は勤務開始を遅らせる・休みにする • 思いやり・安心できる雰囲気作り • 監視画面を眺める必要は無い • 不要なノイズをなるべく削減 • シャドーイング、ペアワーク
41. + Past Incidents 過去の類似インシデント一覧と、 発生時期・回数のヒートマップを表示。 Related Incidents 他サービスで現在発生している、 関連性の高いインシデントを表示。
42. GUI/CodeによるJob定義と管理 42 42 柔軟なJob起動⼿段 認証 120を超える インテグレーション PagerDuty GenAI によるJob作成⽀援 オンプレ環境にも セキュアにアクセス Enterprise Runner - Event-Driven - Human-in-the-Loop - スケジューリング Web GUI API CLI Webhook PagerDuty Runbook Automation
43. アラートに応じた自動化 アラートを受信 インシデントを起票 切り分けのための タスクを実行 自動修復 軽減策のタスクを 実行
44. 参考資料 燃え尽きエンジニアを救う「オンコール最適 化、5つの教訓」 https://www.pagerduty.co.jp/blog/the-hum an-side-of-being-on-call-5-lessons-for-man aging-stress-anxiety-and-life-while-being-o n-call/
45. 疑問: 家庭の事情もあって深夜・休日の オンコールに入るのは厳しい • そういうケースはあり得るので、ある程度は柔軟に対応すべき • 日中帯シフトのみを担当 • セカンダリ対応 • 士気・連帯感を保つため、「誰かだけが常に免除」という形にはしないほうがいい • お互い助け合う風土が重要。「何かあったらカバーして貰えないか頼みやす い」雰囲気作り
46. ポストインシデントレビューのファシリテーター • インシデントそのものに対応するのではなく、ポストインシデントレビュー(ポスト モーテム)をドライブするファシリテーターを担う • インシデント対応しなかった人がレビューを担うことで、当事者バイアスを避けな がらインシデントの全貌を明らかにすることが可能 • イベントの収集、タイムラインの整理、関係者へのヒアリング、レポートの作成など • 改善のフィードバックループを回していく上で重要な存在
47. 参考資料 間違いだらけのポストモーテム - ホントに役 立つレビューはこうだ！ https://speakerdeck.com/jacopen/jian-wei-i tarakenohosutomotemu-hontoniyi-li-turehiy uhakouta
48. + だと Postmortems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデント ノート、Slackの会話などからタイムラインを作成
49. フルサービスオーナーシップに関する資料 PagerDuty自身の経験を元にしたガイド、「 Ops Guides」の一環として、フルサービスオーナー シップのドキュメントも公開中 現在は英語のみですが将来的な日本語の計 画もあり https://ownership.pagerduty.com/
50. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防 ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化 インシデントを特定 ⾃動処理 運⽤改善のための 知⾒を提供 最適な担当者に通知 迅速な解決を⽀援 あらゆるツールから イベントを受信 架電、 SMS、メール Appプッシュ通知、チャット ⾃動エスカレーション スケジュール管理 診断‧修復作業の⾃動化 チーム内外と円滑に連携 クラウド コンテナ マイクロサービス ネットワーク アプリ‧サービス セキュリティ データベース サーバー ソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ 担当者が最適な 通知⽅法を選択 対応履歴 MTTA/MTTR 分析 担当者の負荷状況 ポストモーテム 解決のヒントを提⽰ • 過去の類似インシデント • 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations
51. まとめ • インシデントを減らし、価値を生み続けるソフトウェアの開発には、ライフサイ クルすべてに責任をもつフルサービスオーナーシップが重要 • Team Topologiesの実践により、フルサービスオーナーシップを実現するチー ムが見えてくる • 敬遠されがちなオンコールも担うことで、開発から運用まで含めたライフサイ クルの改善に繋げることができる • この一連のサイクルを実現するために、PagerDutyも貢献します
52. PagerDuty on Tour Tokyo 2025特別サイト 昨年、1000名以上の⽅にご参加いただき、会場が満席となったPagerDuty on Tourが、今年も4⽉10⽇に開催されます！ 本イベントは、システム障害対応やIT運⽤の未来を議論する年に1度の特別なカンファレンスです。 富⼠通 執⾏役員副社⻑ ⾼橋 美波⽒とPagerDuty CEO ジェニファー‧テハダの豪華特別対談、元プロ野球選⼿ ⾥崎 智也⽒の特別講演が決定！ さらに⽇本を代表するITリーダーたちが登壇、最新事例や成功の秘訣を共有します。 PagerDuty Chief Executive Officer ジェニファー‧テハダ PagerDuty Chief Product Development Officer ジェフリー‧ハウスマン PagerDuty Japan Country Manager ⼭根 伸⾏ 登壇者‧セッション情報は随時アップデート！お申込み（無料）はこちらから！ 富⼠通株式会社 執⾏役員副社⻑ ⾼橋 美波⽒ 野球解説者 元プロ野球選⼿ ⾥崎 智也⽒
53. トラシュー アニマルに なろう
55. 参考リンク • PagerDuty on Tour Tokyo 2025 https://www.pagerduty.co.jp/pagerdutyontourtokyo/ • 間違いだらけのポストモーテム - ホントに役立つレビューはこうだ！ https://speakerdeck.com/jacopen/jian-wei-itarakenohosutomotemu-hontoniyi-li-ture hiyuhakouta • 燃え尽きエンジニアを救う「オンコール最適化、5つの教訓」 https://www.pagerduty.co.jp/blog/the-human-side-of-being-on-call-5-less ons-for-managing-stress-anxiety-and-life-while-being-on-call/ • セールスアニマルになろう v2 🦄 - スタートアップの営業活動 (1) 🎰 (本セッションの展開のインスパイア元 ) https://speakerdeck.com/tumada/serusuanimaruninarou-v2-sutatoatupufal seying-ye-huo-dong-1