SRE不在の開発チームが障害対応と 向き合った100日間 / 100 days dealing with issues without SREs

katsukamaru

July 11, 2025

Tweet Share

Transcript

1. SRE不在の開発チームが障害対応と 向き合った100⽇間 SRE NEXT 2025 7/11~12(Fri~Sat)@TOC有明 2025年7⽉11⽇ 株式会社ログラス 1

2. 2 ⾃⼰紹介 株式会社ログラス 開発本部プロダクト開発部 Engineering Manager 株式会社ログラス所属。クラウド基盤チームマネージャー。 2020年にログラスに ジョイン。バックエンドエンジニア、クラウドエンジニアを経て、現在はEMとして チームのマネジメントを担当。社内に⾜りないロールに挑戦し、その領域をなんと

   かして、誰かに渡すことを繰り返しています。 勝丸 真 Shin Katsumaru

3. 3

4. 今⽇の発表内容 4

5. SREがいない組織だけどインシデント対応が出 来るようになりました！🤘 5

6. No 󰢃 6

7. 先⼈の知恵 すでにこの領域はかなり語られており、先⼈たちがどういう取り組みを⾏ってきたのかは すでに世に共有されている 7 • システム障害対応に必要となる知識について、プロセスだけでなく体制 作りや育成まで網羅的にカバーされており、まさに「教科書」 ◦ まずはチームで読み合わせることに利⽤すると良さそう ◦

   エンジニア以外の⼈にも読んでもらえると良い • 関⼼事が網羅されている⼀⽅で、各チームでどういうことが起こったの かという事例ではない 引⽤: ⽊村誠明 （2024） システム障害対応の教科書 技術評論社

8. 先⼈の知恵 すでにこの領域はかなり語られており、先⼈たちがどういう取り組みを⾏ってきたのかが 共有されている 8 • Topotal社 ⾼村さんによる昨年のSRE NEXT 2024での発表 ◦

   インシデントレスポンス環境を評価して、現在の対応がど のレベルなのかという成熟度モデルを提案 • 発表の中で３つの難点を指摘 ◦ 難点1: 企業ごとに解決策が異なるため不確実性が⾼い ◦ 難点2: ベストプラクティスの導⼊がうまくいかないケース ◦ 難点3: 「組織的な対応」の期待値が企業によって異なる 引⽤: https://speakerdeck.com/nari_ex/towards-an-organized-incident-response-maturity-assessment-and-im provement-steps

9. ベストプラクティスをそのまま実装したら 何が起こったのか？N=1を共有する 9

10. 当時のインシデント対応はどういう状況だったのか？ 週次で問い合わせ担当を決めて運⽤ 10 • オンコール担当チームが週次でアサインされる ◦ 等級や⼊社歴は特に考慮されていなかった • 疑わしい問題が起こったときに、まずは１次対応をお願いしていた ◦

    オンコール対応チームの責務は、最も詳しいチームにエスカレーションすること 今週は問い合 わせ担当です 通常の 開発します 通常の 開発します チーム① チーム② チーム③ もしかして 障害では？ ビジネス

11. 当時のインシデント対応はどういう状況だったのか？ インシデント対応はエンジニアの持ち回り 11 • インシデント発⽣した場合リードするエンジニア（挙⼿制）+ 数名のエンジニアで対応していた 今週は問い合 わせ担当です 通常の 開発します

    チーム① チーム② 障害対応 します もしかして 障害では？ ビジネス

12. 当時のインシデント対応はどういう状況だったのか？ ある時、カスタマーサクセス（CS）チームからフィードバック 12

13. 当時のインシデント対応はどういう状況だったのか？ エンジニアサイドは納得感があまり無かった。 いい感じに解決は出来ていると思っていた（認知のズレ） 13 • 対応するエンジニアの顧客対応へのズレがあったケース ◦ インシデント発⽣ → エンジニアA「障害対応やります」

    ▪ 修正コードカキカキ… ◦ インシデント発⽣ → エンジニアB「障害対応やります」 ▪ この障害の影響を受けているお客様はA社さんだけです ▪ 担当CSさんは回避策を早急にお伝え下さい ▪ ⾃分はロールバック作業やります！ • 本当にインシデントか？を確定させるまでに時間がかかっていたケース ◦ エンジニア的には疑わしい状態で騒ぎすぎると、カスタマーサクセスチームの時間を取ってしまうのではないか？

14. 当時のインシデント対応はどういう状況だったのか？ 障害対応フローは存在することは認知されていたが、障害時に対応するには平時の準備が ⼗分ではなかった 14 • 何回も対応しているメンバーはなんとなく動けていた が、フローが変更されたときに読み返すなどはしてな かった • ⼊ってきたばかりのエンジニアは、フロー存在は知って

    いたが、平時に読んで習熟度を⾼める動きが出来ていな かった（オンボーディング不⾜） • 持ち回りでやっていたせいで、継続的な改善に強いオー ナーシップを持つ⼈が現れず、改善が回しにくい状態 だった

15. 15 閑話休題

16. インシデント対応はビジネス的になぜ⼤事なのか？ • ビジネス視点 ◦ 影響対象のお客様に通知対応‧影響度の報告 ◦ 何か対応が必要になる場合は対応完了まで追い切る必要 ◦ リリース想定だった機能のリリースが遅れが発⽣ •

    プロダクト視点 ◦ 暫定対応に加えて、恒久対応が必要（⼤きいものでは数ヶ⽉単位で対応） ◦ 恒久対応のために、現在の計画を⾒直しロードマップの修正が必要 障害対応が与える影響は想像以上に⼤きい 16

17. 17 どのような座組みで対応してきたか

18. インシデント改善プロジェクトを⽴ち上げた 専任1名と3名の兼任体制 18 • プロジェクト改善推進メンバー 専任1名（CRE担当） ◦ プロジェクト改善推進メンバー、会議体の運営、タスクの実⾏ • インシデントコマンダー候補

    兼任3名（勝丸はここ） ◦ インシデントコマンドを学び、実際にコマンダー業を⾏う ◦ インシデントコマンダーチームに学びを持ち帰り、チームとして練度を上げる ◦ 指名して各事業から1名ずつ招集 事業A 事業B 事業C インシデント コマンダー

19. インシデント改善プロジェクトを⽴ち上げた ⽬標は3ヶ⽉で以下の３つを満たすこと 19 1⃣ インシデント対応の練度を向上させる 2⃣ 定量的なモニタリングをプロダクト開発組織に根付かせるための施策を検討、実施する 3⃣ 継続的な改善をするための体制を構築する

20. インシデント改善プロジェクトを⽴ち上げた 1⃣ インシデント対応の練度を向上させる 20 • 課題 ◦ ⼈によってインシデント対応にクオリティの差がある ◦ （補⾜）開発者全員がコマンダーは⽬指さない。まずは限られた⼈で対応に差がない状態を⽬指す

    ◦ インシデント対応が煩雑なためフローの明確化と刷新が必要 • 達成イメージ ◦ インシデントレベル定義、（障害ではない）不具合の管理⽅法についてドキュメント化され、CSと合 意できている

21. インシデント改善プロジェクトを⽴ち上げた 1⃣ インシデント対応の練度を向上させる 21 • やったこと ◦ インシデントコマンダー専任化 i. ⼀時的に数⼈のエンジニアをインシデントコマンダーというロールを与えて交通整理

    ◦ CSが感じている課題感を改めてヒアリングし、解決すべき課題を特定 ◦ インプット i. システム障害対応の教科書を読む ii. 複数⼈で外部の勉強会（Incident Response Meetup）参加 ◦ プロセスの整備 i. インシデントコマンダー体制をつくる（役割を⼀時的に集約させる） ii. 障害レベル定義アップデート / 障害対応フロー図を描く ◦ 社内向け発信系 i. Incident Response Meetup参加レポ共有 ii. 社内のプロダクト朝会で話す（N回） iii. Googleのブログ記事シェア ◦ インシデントコマンダーでインシデント対応整理‧ふりかえり

22. インシデント改善プロジェクトを⽴ち上げた • 変わったこと ◦ 取り扱う「インシデント」とは何か？から再定義 ◦ インシデントレベル定義し直し、レベルによって巻き込む⼈を再定義。特にCriticalなものは経営陣も追加 ◦ 変更したフローで問題なく対応が出来たのか、細かく改善するループがインシデントコマンダー内で⽣まれた 22

23. インシデント改善プロジェクトを⽴ち上げた 2⃣ 定量的なモニタリングをプロダクト開発組織に根付かせるための施策を検討、実施する 23 • 課題 ◦ インシデント対応を改善していくために定量的な情報を取得できていない • 達成イメージ

    ◦ MTTR（平均修復時間）など必要な定量メトリクスが取得でき、インシデント対応のクオリティが可視化 できている ◦ インシデント対応⾃体の改善が可能になっている状態になっている

24. インシデント改善プロジェクトを⽴ち上げた 2⃣ 定量的なモニタリングをプロダクト開発組織に根付かせるための施策を検討、実施する 24 • やったこと ◦ ツール（Waroom）の導⼊を⾏い、インシデントコマンダー業務の型化と⾃動化（後述） i. 1⃣

    で改善したフローを元に、対応を⾃動化を実施 • 変わったこと ◦ インシデントコマンダーが迷わずに対応出来るようになった ◦ Slackのチャンネルのデータを元に⾃動でインシデントが記録され負荷軽減 ◦ インシデント対応を定量的に捉えられるようになった

25. インシデント改善プロジェクトを⽴ち上げた 2⃣ 定量的なモニタリングをプロダクト開発組織に根付かせるための施策を検討、実施する 25

26. インシデント改善プロジェクトを⽴ち上げた 2⃣ 定量的なモニタリングをプロダクト開発組織に根付かせるための施策を検討、実施する 26 こちらの数字はサンプルです。実際のものではありません

27. インシデント改善プロジェクトを⽴ち上げた 3⃣ 継続的な改善をするための体制を構築する 27 • 課題 ◦ インシデント対応の改善が継続的にできる組織⽂化の状態ではなく、インシデント対応を組織にインストールする ために、どのような組織で回していくのか誰も仮説を持っていない •

    達成イメージ ◦ 1⃣ 2⃣ を通して継続的な改善をするための体制案を考え、Mgr陣に提⾔する ◦ インシデント対応のクオリティを上げていくための体制案（正式な部だったり、有志のPJだったり）をMgr陣に提 案し、2025年4⽉中に5⽉以降の体制が構築できている状態 実際の作業⼯数やどれぐらいの⼈員が必要になったのかをEMに共有

28. ここで終われば... SREがいない組織だけどインシデント対応が出 来るようになりました！🤘 28

29. 教科書的な対応してうまくいきました ではないこともたくさん 29

30. 実際に回してみるとうまくいかないことも多かった 出会った世界は教科書的な世界とは全く異なっていた 30 ツールを導⼊する前に、今の改善フロー の問題点を明らかにするべきではない か？ 今までの対応である程度上⼿く⾏ってる と思っていたんだけどな インシデントレベルを⾒直すということは、 今までは対応されていたものが対応されなく

    なる？ 顧客影響が⼩さいというのは、誰から⾒て⼩さ いとなりますか？例えば特定のお客様だけが 困っているケースなどは？

31. 31

32. 32 対話

33. 対話を重ねて課題を愚直に解決していった ビジネスチーム 33 • 愚直で丁寧なコミュニケーションの積み重ねで信頼を勝ち取る ◦ 考えていること、やろうとしていることをこまめに発信する ◦ 最初はステークホルダーへのネガティブな影響が最⼩限になるように丁寧にコミュニケーションをし、徐々に我々 としてやるべきことを主体的に推し進めていく

    ◦ 正直、真正⾯からコミュニケーションとれず遠回りしたこともある。けど、周囲が何を期待しているのかをヒアリ ングしながら期待に応えるようにし、徐々に⾃分たちのやりたいことを思いとして乗せていった ◦

34. 対話を重ねて課題を愚直に解決していった 34

35. 対話を重ねて課題を愚直に解決していった プロダクトチーム 35 • プロセス整備だけではうまくいかないことを共有し、エンジニアリングが出来る範疇であることを共有 ◦ インシデントコマンダーはスキルであることも共有 i. 最終的には⼈間的な判断は残るので、そこを⾒極めるにはある程度繰り返すしかない ◦

    障害対応は⽂化作り。⽂化浸透のために何度も繰り返し重要性を説く i. 障害対応を"楽しむ"。この領域がいかに⾯⽩いかを語る ◦

36. 対話を重ねて課題を愚直に解決していった 導⼊したツールに対して 36 • プロダクト 改善して欲しい部分も率直に伝えつつ、必要になった背景もきちんと伝える ◦ 仮に⾃分たちは使っているということをアピールしつつ、仮に改善に時間がかかってもいいというスタンス ◦ ⼀緒に改善していくぞという気持ちで利⽤している

37. インシデントコマンダーのこれから まだまだ対応すべきことはたくさんある 37 • 知⾒を共有しインシデントコマンダーを増やしていく ◦ まだまだ⼀部の⼈がインシデントコマンダーとなっただけで、全員インシデントコマンダーには程遠い ◦ そのために、新しPJに⼊る⼈にペアインシデントコマンドなどを⾏っている ◦

    インシデントコマンダーとしてのオンボーディング資料を拡充 • それぞれのチームに戻った際に、知識や経験を形式知化し、他のメンバーへ展開する仕組みは構築できて いない ◦ 組織全体で信頼性に取り組む⽂化を醸成するフェーズへと移⾏はもう少し時間がかかりそう • ポストモーテムの改善 ◦ 今回の登壇では対象にしなかった ◦ 効果的なポストモーテムにするための改善や、恒久対応が実施しきれていないなど改善出来るポイントはある

38. プロジェクトを通しての学び 気づき‧学び（エンジニア視点） 38 • 過去に整えていたフローが段々と機能不全に陥っていた、平時準備が⼤事 ◦ プロダクトの複雑化やステークホルダーの増加により、実は伝える先が増えていたなど ◦ エンジニアの増加により、フローを精緻に全員が実⾏できるようになることの難しさがあった ◦

    平時での準備不⾜ • プロセス整備だけではうまくいかない ◦ プロセスがワークするために⼀時的に「属⼈化」を許容した ◦ ⼀⽅で責任も⽣まれる。なぜこのフローなのか？も語る i. 責任を果たすためにに、その領域を学習しベストプラクティスを学ぶ • 対話する相⼿に理解してもらうために「なぜ？」も共有する。同時に相⼿のなぜも考える。 ◦ エンジニアのなぜ？とビジネスサイドのなぜ？は違う ◦ エンジニアのなぜこう思うのか？は積極的に伝える

39. プロジェクトを通しての学び 気づき‧学び（マネージャー視点） 39 • 各社イネーブルメントに困っている印象があるが、まず何⼈か選んでスキル向上を狙うのはいいのでは ◦ 今回はある程度うまく⾏ったのは、毎⽇時間を取ったことが重要だった（と思う） ◦ 領域を変えれば応⽤できそう i.

    セキュリティ ii. パフォーマンスメトリクス iii. コスト監視 ◦ 継続的な投資としての「時間確保」が重要 • 「対話のデザイン」と「期待値のマネジメント」はもう少し探索できそう ◦ 「認知のズレ」をもっと早く検知するには？は、組織デザインで⼀定解消出来るのではないか？という問い ◦ 週次のふりかえりに定期的に、ビジネスサイドに⼊ってもらうなどはありそう

40. 40

41. 41