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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup 代表理事 @一般社団法人クラウドネイティブイノベーターズ協会 Organizer @CloudNative Days

Slide 3

Slide 3 text

トラブルシューティング、してますか？

Slide 4

Slide 4 text

普段から運用、携わってますか？運用しているといろいろ起きますよね

Slide 5

Slide 5 text

トラシューアニマルになろう

Slide 6

Slide 6 text

トラシューはいいぞ • 知識が定着する • 新たな知識を得られる • システム全体の解像度が上がる • 開発者としての視野が広がる • 論理的思考能力が上がるトラブルシューティングからしか得られない栄養がある

Slide 7

Slide 7 text

だからこそ • 自分の開発したものは自分で運用しよう • 開発者もオンコールのローテーションに入ろうまだ組織が小さいスタートアップなら、そうしている(せざるを得ない)ところも多いです。ですが、組織が大きくなるにつれ、開発と運用を分ける動きが生まれ始めます。でも、その分け方は本当に正しいのでしょうか

Slide 8

Slide 8 text

You build it, you run it. Werner Vogels, VP & CTO of Amazon

Slide 9

Slide 9 text

フルサービスオーナーシップとは「コードを書いた者が、その責任を負う」 • 設計と実装の点から見て、テクノロジーに最も精通した人が製品開発ライフサイクル全体の責任を引き受ける運用モデル • 本番環境において自分が書いたコードの責任を負うよう、最もシンプルな形でエンジニアに権限を与える • 呼び方は色々ある • フルサイクル・デベロッパー (Netflix) https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249

Slide 10

Slide 10 text

製品開発ライフサイクル Build Test Ship Run Dev Ops

Slide 11

Slide 11 text

製品開発ライフサイクル Build Test Ship Run Dev Ops

Slide 12

Slide 12 text

障害のほとんどはデプロイによって引き起こされる “障害のほとんどはデプロイによって引き起こされる。したがって、デプロイが増えると障害も増え、結果としてインシデント管理、軽減策、ポストモーテムが必要となる ” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのかより引用

Slide 13

Slide 13 text

そのサービスを一番よく知っているのは誰かそれは作った本人一番よく知っている人が、トラシューするのが最も早い

Slide 14

Slide 14 text

フルサービスオーナーシップ Build Test Ship Run

Slide 15

Slide 15 text

“コードに責任を持つ ” メリット • サービス品質が上がる • 開発と運用を分けず一貫して担当することで、リリース後の振る舞いまで考慮してコードを書くようになる。だれも深夜に叩き起こされたくないので。 • 障害対応の迅速化 • 開発者がオンコールにいれば対応のスピードが格段に上がる。自分たちが開発したシステムを熟知しているため、原因特定や復旧が素早く行える。

Slide 16

Slide 16 text

“コードに責任を持つ ” メリット • フィードバックループの高速化 • 開発者が日常的に運用に関与すると、ユーザーからの生のフィードバックや本番環境での問題点が直接開発チームに届く • 「不具合→修正」のサイクルが短くなり、サービスの継続的な改善がスピーディーに行える • 運用負荷の軽減とチーム連携の強化 • 従来運用担当に集中しがちだった負荷が分散される。特定の運用チームだけに深夜対応などの負担がかかる状況を和らげ、組織全体で信頼性向上に取り組む姿勢が生まれる

Slide 17

Slide 17 text

トラシューアニマルになろう

Slide 18

Slide 18 text

運用軽視の「無責任」コード • 必要なログが出ていない / 不明瞭 • エスパー力が求められる問題 • 逆にログが多すぎて探せない • 目grep力が求められる問題 • ログの出力方法が不適切 • 散在していてすぐに見つけられない • 再起動したら消える • 監視用のフックが存在しない

Slide 19

Slide 19 text

運用軽視の「無責任」コード • 設定がハードコード • 接続先が変わるとコード修正が必要 • 実行環境に依存したコード • ブランチが分かれていて、それぞれの環境ごとに異なるコードベースを使わないといけない • 開発と本番環境の不整合 • 手元では動くが本番環境で問題がおきる

Slide 20

Slide 20 text

運用軽視の「無責任」コード • 依存ライブラリ解決が自動化されていない • ビルドのたびに特別な手順が必要 • デプロイ手順が複雑、手作業が多い • リリースの度にサービス中断が必要 • スケールアウトしづらい、ステートフルな設計

Slide 21

Slide 21 text

運用軽視の「無責任」コード • 安全に停止できない • 起動に時間がかかりすぎる • サービス間の結合が強く、起動順序に制約がある • 運用手順の属人化・ブラックスボックス化

Slide 22

Slide 22 text

このような明らかなアンチパターンだけでなく運用していくことで判明する「ああやればもっと良くなる」というポイントはたくさんある

Slide 23

Slide 23 text

自分で運用をして辛さを味わえば、「早く直そう」というモチベーションが湧く

Slide 24

Slide 24 text

開発する ⇩ 障害がおきる ⇩ 🐅トラシューする 🐕 ⇩ 改善する

Slide 25

Slide 25 text

トラシューアニマルになろう

Slide 26

Slide 26 text

オンコール

Slide 27

Slide 27 text

オンコール呼び出し

Slide 28

Slide 28 text

オンコール • 運用で緊急を要する事態が発生した際、すぐに対応ができるように待機する勤務形態 • PagerDutyを導入している場合、PagerDutyによって呼び出される • フルサービスオーナーシップの場合、開発者もオンコールのローテーションに入る

Slide 29

Slide 29 text

疑問: 開発者がオンコールに入るとベロシティが悪化するのでは

Slide 30

Slide 30 text

疑問: 開発者がオンコールに入るとベロシティが悪化するのでは • するよ • 一時的にベロシティの悪化は起きるので、トラシュー後はそうならないような仕組み作りをしていくべき • ベロシティはあくまでも目安として考える • そもそもベロシティを目標にしてはいけない • サービスの安定性より優先されるベロシティに意味はない

Slide 31

Slide 31 text

疑問: 開発者がオンコールに入るとベロシティが悪化するのでは • 特定の人に負荷が集中してしまうのが良くない • 組織のサイズによって変わってくるが、月に3〜4日程度が理想 • 適切にスケジュールを組んで担当をバラしていく

Slide 32

Slide 32 text

オンコール必要なアラートだけに絞り込み電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知一次対応者 (応答がなければ) 二次対応者オンコールのローテーション

Slide 33

Slide 33 text

エスカレーションポリシー • 3-tierのエスカレーションポリシーが標準的 • 1st level サービスに責任を持つチームの誰か • 2nd level 1st levelで受け取れなかった通知をキャッチ • 3rd level チームリーダー、EM、プロダクトオーナーなど

Slide 34

Slide 34 text

疑問: オンコールは SREがやるべきでは？ • 明確にNO • SREは信頼性を高めるエンジニアリングを行う専門家であって、オンコール専任の仕事ではない • SREも開発者もオンコールローテーションに入る • プロダクトに関するインシデントはプロダクトチームが、プロダクトを跨ぐインシデントはSREが担当するという棲み分けをしている例もあり

Slide 35

Slide 35 text

「開発者に運用もやらせる」ではなく「ライフサイクルに責任を持たせる」 Build Test Ship Run これを回すこと自体に責任を持たせる

Slide 36

Slide 36 text

「開発者に運用もやらせる」ではなく「ライフサイクルに責任を持たせる」 Build Test Ship Run オンコール

Slide 37

Slide 37 text

「開発者に運用もやらせる」ではなく「ライフサイクルに責任を持たせる」 Build Test Ship Run スケールアウトがしやすい実装 (コンテナオーケストレーターの自律復旧に委ねる) ビルドやパッケージングの自動化素早いビルドの工夫実行パラメータの外部注入(環境依存の排除) トラブルシュートしやすいログの工夫インフラのコード化

Slide 38

Slide 38 text

Slide 39

Slide 39 text

疑問: オンコールに入ると心理的負担が大きいのでは • これは重要なポイント • エンジニアの「燃え尽き症候群」への対処

Slide 40

Slide 40 text

疑問: オンコールに入ると心理的負担が大きいのでは • 無理のないローテーション • 深夜対応を行った翌日は勤務開始を遅らせる・休みにする • 思いやり・安心できる雰囲気作り • 監視画面を眺める必要は無い • 不要なノイズをなるべく削減 • シャドーイング、ペアワーク

Slide 41

Slide 41 text

+ Past Incidents 過去の類似インシデント一覧と、発生時期・回数のヒートマップを表示。 Related Incidents 他サービスで現在発生している、関連性の高いインシデントを表示。

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

アラートに応じた自動化アラートを受信インシデントを起票切り分けのためのタスクを実行自動修復軽減策のタスクを実行

Slide 44

Slide 44 text

参考資料燃え尽きエンジニアを救う「オンコール最適化、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/

Slide 45

Slide 45 text

疑問: 家庭の事情もあって深夜・休日のオンコールに入るのは厳しい • そういうケースはあり得るので、ある程度は柔軟に対応すべき • 日中帯シフトのみを担当 • セカンダリ対応 • 士気・連帯感を保つため、「誰かだけが常に免除」という形にはしないほうがいい • お互い助け合う風土が重要。「何かあったらカバーして貰えないか頼みやすい」雰囲気作り

Slide 46

Slide 46 text

ポストインシデントレビューのファシリテーター • インシデントそのものに対応するのではなく、ポストインシデントレビュー(ポストモーテム)をドライブするファシリテーターを担う • インシデント対応しなかった人がレビューを担うことで、当事者バイアスを避けながらインシデントの全貌を明らかにすることが可能 • イベントの収集、タイムラインの整理、関係者へのヒアリング、レポートの作成など • 改善のフィードバックループを回していく上で重要な存在

Slide 47

Slide 47 text

参考資料間違いだらけのポストモーテム - ホントに役立つレビューはこうだ！ https://speakerdeck.com/jacopen/jian-wei-i tarakenohosutomotemu-hontoniyi-li-turehiy uhakouta

Slide 48

Slide 48 text

+ だと Postmortems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデントノート、Slackの会話などからタイムラインを作成

Slide 49

Slide 49 text

フルサービスオーナーシップに関する資料 PagerDuty自身の経験を元にしたガイド、「 Ops Guides」の一環として、フルサービスオーナーシップのドキュメントも公開中現在は英語のみですが将来的な日本語の計画もあり https://ownership.pagerduty.com/

Slide 50

Slide 50 text

1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化インシデントを特定⾃動処理運⽤改善のための知⾒を提供最適な担当者に通知迅速な解決を⽀援あらゆるツールからイベントを受信架電、 SMS、メール Appプッシュ通知、チャット⾃動エスカレーションスケジュール管理診断‧修復作業の⾃動化チーム内外と円滑に連携クラウドコンテナマイクロサービスネットワークアプリ‧サービスセキュリティデータベースサーバーソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ担当者が最適な通知⽅法を選択対応履歴 MTTA/MTTR 分析担当者の負荷状況ポストモーテム解決のヒントを提⽰ ● 過去の類似インシデント ● 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations

Slide 51

Slide 51 text

まとめ • インシデントを減らし、価値を生み続けるソフトウェアの開発には、ライフサイクルすべてに責任をもつフルサービスオーナーシップが重要 • Team Topologiesの実践により、フルサービスオーナーシップを実現するチームが見えてくる • 敬遠されがちなオンコールも担うことで、開発から運用まで含めたライフサイクルの改善に繋げることができる • この一連のサイクルを実現するために、PagerDutyも貢献します

Slide 52

Slide 52 text

PagerDuty on Tour Tokyo 2025特別サイト昨年、1000名以上の⽅にご参加いただき、会場が満席となったPagerDuty on Tourが、今年も4⽉10⽇に開催されます！本イベントは、システム障害対応やIT運⽤の未来を議論する年に1度の特別なカンファレンスです。富⼠通執⾏役員副社⻑⾼橋美波⽒とPagerDuty CEO ジェニファー‧テハダの豪華特別対談、元プロ野球選⼿⾥崎智也⽒の特別講演が決定！さらに⽇本を代表するITリーダーたちが登壇、最新事例や成功の秘訣を共有します。 PagerDuty Chief Executive Oﬃcer ジェニファー‧テハダ PagerDuty Chief Product Development Oﬃcer ジェフリー‧ハウスマン PagerDuty Japan Country Manager ⼭根伸⾏登壇者‧セッション情報は随時アップデート！お申込み（無料）はこちらから！富⼠通株式会社執⾏役員副社⻑⾼橋美波⽒野球解説者元プロ野球選⼿⾥崎智也⽒

Slide 53

Slide 53 text

トラシューアニマルになろう

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

参考リンク • 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