【新卒研修】共通言語としてのSRE/SRE as a common language

GMOインターネットグループの合同研修である「GMO Launcher 2025」SREパートの資料を公開します。

---

SREは特定の専門職だけのものではない。
SREのプラクティスをサービスの開発に関わるすべての人の “共通言語” とすることで信頼性の優先順位を制御したり、コミュニケーションをスムーズにしやすくする。

SRE文化を実践しているチームと関わった際に、同じ土俵で会話ができるようになる。
サービス運用の課題に対し、SREを1つの解決手段として活用できるようになる。

1章：なぜ「共通言語としてのSRE」の話をするか？
2章：SREの基礎
　2.1. サービスレベル目標
　2.2. トイルの削減
　2.3. ポストモーテムの文化：失敗からの学び
3章：SREのアンチパターン

Transcript

1. 共通言語としての SRE 久米拓馬 @takumakume / GMO PEPABO inc. 2025.4.15 GMO Launcher 2025 - SRE（GMOインターネット合同研修）
3. 自己紹介 私のイズム GMOペパボ株式会社 ロリポップ・ムームードメイン事業部 事業部CTO 久米 拓馬 @takumakume • 2016年中途入社 • インフラ、バックエンド、SREを経験 • 好きなソフトウェアはKubernetes • 釣りをしたり、コーヒー豆を焙煎したり、ウイスキー を買い集めたりしている 私の仕事は ホスティング領域の事業部CTOとして、技術力でユーザの表現のハードルを下げ、1つ でも多くの人類のアウトプットを増やすことです。
4. 共通⾔語としてのSRE • 1章：なぜ「共通⾔語としてのSRE」の話をするか？ • 2章：SREの基礎 ◦ 2.1. サービスレベル⽬標 ◦ 2.2. トイルの削減 ◦ 2.3. ポストモーテムの⽂化：失敗からの学び • 3章：SREのアンチパターン ⽬次 7
5. 8 1章 なぜ「共通⾔語としてのSRE」 の話をするか？
6. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ • SREは特定の専⾨職だけのものではない • SREのプラクティスをサービスの開発に関わるすべての⼈の “共通⾔語” とすること で信頼性の優先順位を制御したり、コミュニケーションをスムーズにしやすくする なぜ「共通⾔語としてのSRE」の話をするか？ 9
7. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ • ⽴場や役割の違う⼈たちが、同じ⾔葉と意味で会話できる状態 • 誤解なく、スムーズに、そして建設的に話が進むための“共通の⼟台” 共通⾔語とは 10
8. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 󰳖 サービス責任者 「この機能、できれば今週中にリリースしたいんだけど、どうかな？」 󰞵 エンジニア 「最近サイトが不安定なので、リリースは延期したいです」 󰳖 サービス責任者 「なるほど。でも、“どのくらい不安定” なのか、判断むずかしいよね…？」 🙅 共通⾔語がないと… 11
9. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 󰞵 エンジニア 「最近サイトが不安定で、サービスレベル⽬標をもう少しで下回ってしまいそうです」 󰳖 サービス責任者 「それなら今回はリリースを⾒送ろう。スケジュールは調整するよ」 󰞵 開発 「次のリリースに向けて改善を進めます！」 ✅ 共通⾔語があると… 12
10. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 󰞵 エンジニア 「最近サイトが不安定で、サービスレベル⽬標をもう少しで下回ってしまいそうです」 󰳖 サービス責任者 「それなら今回はリリースを⾒送ろう。スケジュールは調整するよ」 󰞵 開発 「次のリリースに向けて改善を進めます！」 ✅ 共通⾔語があると… 13 事前に取り決めた指標と優先順位を共通言語とすることで、コ ミュニケーションがスムーズ
11. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 「Site Reliability Engineering」という⼿法を組織全体の “共通⾔語 “ として活⽤するた めに知っておくべき基礎知識 ✅ 本⽇お話すること 14 「Site Reliability Engineer」という専⾨職としての振る舞いや個別の技術の話 🙅 本⽇話さないこと
12. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ • SRE⽂化を実践しているチームと関わった際に、同じ⼟俵で会話ができるようにな る。 • サービス運⽤の課題に対し、SREを1つの解決⼿段として活⽤できるようになる。 🎯 研修の⽬的 15
13. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 本資料は新卒エンジニア向けに作成されていますが、受講者が⾃⾝のチーム内で内容を 共有しやすいよう、⾮エンジニアの⽅にも理解できる表現や例えを意識して構成した。 職種や専⾨性を問わず、「信頼性」について共通の⼟台を持てるようになることを⽬指 している。 📝 研修資料について 16
14. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ サイトリライアビリティエンジニアリング とは 17 引⽤： 『SREをはじめよう』O'Reilly - 1.1 SREとはなにか “組織がシステム、サービス、製品において適切なレベルの信頼性を 持続的に達成できるように⽀援することを⽬的とした⼯学分野”
15. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ • 収益 ◦ サービスが⽌まると価値は届かない＝収益がない • 時間 ◦ 障害対応などの作業に時間を取られる • 評判 ◦ 信頼性が⾼い競合他社に乗り換えられる • 健康 ◦ オンコールなどによって多くの時間を仕事に割く必要があり、健康に悪影響を及ぼす • 採⽤ ◦ 信頼性の低いシステムを抱え続ける会社で働きたいとは思わない 信頼性が与える影響 18 参考：『SREをはじめよう』O'Reilly - 1.1.1 信頼性
16. 19 運用に追われて 機能開発が先送り
17. 20 機能開発に追われて 障害の再発防止が先送り
18. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 適切なレベルの信頼性 21 サービス ユーザー SRE 適切なレベルの信頼性を 維持できるように コントロールする 信頼性 ⾼すぎず 低すぎない
19. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 適切なレベルの信頼性 22 サービス ユーザー SRE 適切なレベルの信頼性を 維持できるように コントロールする 信頼性 ⾼すぎず 低すぎない 結果として、 より多くの価値をユーザに提供し ビジネスを成功に導く
20. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 23 適切なレベルの信頼性を維持するには チームや職種を横断して合意形成が必要
21. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 24 共通言語としての SRE
22. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ より多くの価値を素早くユーザに提供する • 開発者（Dev）‧運⽤者（Ops）といった組織や⽂化のサイロを打破 • ソフトウェアデリバリーの効率性や速度を向上 DevOps 25
23. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ DevOpsとSREの関係 26 引⽤：『SREの探求』O'Reilly - 12章 DevOpsとSRE：コミュニティからの声 SREはプロダクションの運⽤が起点
24. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ DevOpsとSREを両⽴させて、ユーザに価値を届ける 27 信頼性 サービス ユーザー SRE 機能 DevOps コントロール
25. 1章：なぜ「共通⾔語としてのSRE」の話をするか？ 1章のまとめ • 本研修でのSREは「Site Reliability Engineering」を指す • なぜ「共通⾔語としてのSRE」の話をするか ◦ SREを持続的に機能させるには、組織全体でSREを共通⾔語にする必要がある • SREとは、信頼性を上げたり下げたりすることで、機能開発とのバランスを取る • DevOpsとSREを両⽴し、ユーザに価値を提供し続ける 28
26. 29 2章 SREの基礎
27. 2章：SREの基礎 30 2.1 サービスレベル⽬標
28. • 100％の信頼性を⽬指さない ◦ 信頼性におけるリスクと、イノベーションの速度とのバランスを取る • 信頼性を測定‧⽬標設定‧定量的に評価することで制御する ◦ サービスの品質は、エンジニア個⼈の勘や責任感だけでは管理できない 2.1 サービスレベル⽬標 前提となる考え⽅ 31
29. 2.1 サービスレベル⽬標 信頼性スタック 32 • SLI（サービスレベル指標） ◦ システムの信頼性に関する定量的な測定値 ◦ 例：稼働率、レイテンシ、エラーレート • SLO（サービスレベル⽬標） ◦ SLIに対しての⽬標値 ◦ 例：稼働率 ⽉間 99.9％ • エラーバジェット ◦ SLO違反を許容する範囲 ◦ 例：稼働率 ⽉間 99.99％ の場合、0.01％ (4分23秒) 引⽤：Alex Hidalgo, ⼭⼝能迪, 成⽥昇司 『サービスレベル⽬標』O'Reilly - 1.2 信頼性スタック
30. • 信頼性スタックにおいてベースとなる最も重要な要素 • ユーザー体験を直接確認する ◦ 🙅 CPU使⽤率 ◦ ✅ 商品検索にかかる時間 • SLIをどうやって決めるか 2.1 サービスレベル⽬標 SLI（サービスレベル指標） 33
31. 2.1 サービスレベル⽬標 CUJ (Critical User Journey) 34 • ユーザがサービスを利⽤する上で重要な体験 • 例 ◦ ECサイト：商品検索→カートに⼊れる→決済 • どのメトリクスを計測すればCUJを担保できるかをベースにSLIを設定する
32. 2.1 サービスレベル⽬標 35 “良いSLIは、すべての利害関係者が理解できる平易な⽂章” 引⽤： 『サービスレベル⽬標』O'Reilly - 1.2.1 サービスレベル指標 サービスに関わるチームや責任者がSLIを理解し、 SLOを下回る場合の優先順位を⾼く合わせる
33. • SLIを決めたらしばらく計測し、現状を把握する • 現状の値、ユーザの期待、技術的制約を考慮し達成可能な⽬標を設定する ◦ 現実とかけ離れた⾼い⽬標を設定すると機能しない • 稼働率と許容停⽌時間 ◦ 99.9% （⽉間 43.83分） ◦ 99.99% （⽉間 4.38分） ◦ 99.999%（⽉間 26.30秒） ◦ あなたのサービスが本当に必要とする信頼性は？ • ⽬標は定期的に⾒直す ◦ サービスにとって重要なことは時間の経過とともに変化する 2.1 サービスレベル⽬標 SLO（サービスレベル⽬標） 36
34. 2.1 サービスレベル⽬標 37 “サービスレベル⽬標 は、ユーザーやエンジニア、製品チーム、 さらにビジネスに、より⼤きな⾄福をもたらすためのものです。” 引⽤： 『サービスレベル⽬標』O'Reilly - 1.4.5 すべて⼈に関わる “SLO の⽬標値の末尾に、 9 を増やすことだけが⽬標ではないはずです”
35. • エラーバジェットが余っている → より多くの機能をリリース • エラーバジェットが超過した → 信頼性の回復に集中 2.1 サービスレベル⽬標 エラーバジェット 38
36. ある日、エラーバジェットを超過 39
37. 「新機能のリリースが急ぎなので 一旦リリース優先で」 40
38. • 信頼性が売上や利益に直結してないように⾒えるケースが多いので、優先順位が上 がりずらい • SLOは適切な「レベルの信頼性」か？ ◦ 経済的に合理的な設定か？ ◦ SLOが多すぎではないか？ 2.1 サービスレベル⽬標 エラーバジェットの運⽤は難しい 41
39. • エラーバジェットが超過する前に⼿を打つことが重要 • ほとんどの開発リソースを信頼性回復に投⼊しなければならない状況になると、意 思決定が振れやすい 2.1 サービスレベル⽬標 エラーバジェットを消費し尽くしてからでは遅い 42
40. • エラーバジェットが消費されていくレート • 将来のある時点までにシステムが消費することになるエラーバジェットの数量を予 測する 2.1 サービスレベル⽬標 バーンレートをアラートしてエラーバジェットの枯渇前に⼿を打つ 43
41. 2章：SREの基礎 44 2.2 トイルの削減
42. サービスを稼働させるのに手一杯 45
43. • ⼿作業である • 頻繁に繰り返される • ⾃動化できる • 割り込み的‧反応的に発⽣する（例：アラート対応） • ⻑期的な価値を持たない 2.2 トイルの削減 トイル：価値を⽣まない反復的作業 46
44. • トイルは⽇に⽇に増え続け、業務の⼤半がトイルになる • 機能開発や信頼性の回復などの価値を届ける仕事に時間が割けなくなる • サービス成⻑に⽐例して作業量が増えることで、サービスがスケールしなくなる 2.2 トイルの削減 トイルを放置すると 47
45. 2.2 トイルの削減 トイルの削減は開発とその後のメンテナンスも含めてコストメリットを出す 48 ✅ 引⽤： 『サイトリライアビリティワークブック』O'Reilly - 6.2 トイルの計測 🙅
46. 2.2 トイルの削減 🙅トイルを削減するために時間がかかりすぎるからやらない 49
47. • シニアエンジニアなら時間に⾒合った成果が得られるが、ジュニアエンジニアだと難し いので⾃動化を諦めるケース • ⼀⾒コスパが悪いと思っても、積極的にチャレンジしていく姿勢は重要 2.2 トイルの削減 🙅トイルを削減するために時間がかかりすぎるからやらない 50
48. 誰でも最初から爆速で解決できない だからといって諦めると上達しない 51
49. • 最初から完璧なシステムを作らない • ⼩さな改善を積み重ねることで、次の改善の時間が少しずつ⽣まれる • ドキュメントを書くというのも改善である ◦ プロセスが明確化されることで属⼈化から脱却し、チームで解決できる 2.2 トイルの削減 ⼩さく始める 52
50. • 割り込みによるコンテキストスイッチの減少 • コードによるプロセスの明確化と標準化 • ヒューマンエラーの防⽌ • スキルアップ‧キャリアの成⻑ • チームの⼠気の向上 2.2 トイルの削減 ⾃動化による間接的なメリット 53
51. 2章：SREの基礎 54 2.3 ポストモーテムの⽂化: 失敗からの学び
52. • サービスに変更を加え続ける中でインシデントは避けられない • インシデントを再発させない仕組みが必要 • インシデントの影響‧対応内容‧再発防⽌策をドキュメント化したものがポストモーテム 2.3 ポストモーテムの⽂化: 失敗からの学び 失敗からの学び 55
53. • 避難をしない、建設的である • たとえヒューマンエラーだとしても、特定の⼈を対象に⾮難をしてはならない • ⼈を罰すると、萎縮し、⾏動しなくなる • 頻繁にインシデントが発⽣していても、責めてはいけない • 問題は⼈ではなくインシデントが発⽣するシステムにある 2.3 ポストモーテムの⽂化: 失敗からの学び ポストモーテムの⽂化 56
54. 2.3 ポストモーテムの⽂化: 失敗からの学び 57 ポストモーテムの例 ポストモーテムはドキュメントであり、知識の共有も1つの⽬的である。 チーム外のメンバー以外でも分かりやすく簡潔な⽂章を書く。 引⽤： 『サイトリライアビリティエンジニアリング』O'Reilly - 付録D ポストモーテムの例
55. 2.3 ポストモーテムの⽂化: 失敗からの学び 58 アクションアイテムはシステムの改善を設定する。 ⼈間が「気をつける」だと再発する。 根本対処を後回しにしすぎない→偶発的障害はすぐにでも再発する
56. 2.3 ポストモーテムの⽂化: 失敗からの学び 59
57. 2.3 ポストモーテムの⽂化: 失敗からの学び 60
58. ポストモーテムを書く暇がないです！ 61
59. 2.3 ポストモーテムの⽂化: 失敗からの学び 62 ポストモーテムを書くべき閾値を定義する すべてのインシデントにポストモーテムを書こうとすると信頼性に掛ける時間のバランスが取れなくなる • ユーザへの影響が⼀定の閾値を超えたとき • データ損失や漏洩が発⽣したとき • システムの影響範囲が多岐に渡ったとき • 復旧までの時間が⼀定の閾値を超えたとき • インシデントの検知が⼈間だったとき
60. 2.3 ポストモーテムの⽂化: 失敗からの学び 63 ポストモーテムの作成をワークフロー化する https://speakerdeck.com/hiboma/yapc-kyoto-2023?slide=46
61. 2章：SREの基礎 64 • サービスレベル⽬標 ◦ SREはSLI/SLO/エラーバジェットを⽤いてデータドリブンな意思決定を⾏う ◦ ⼀⽅で、エラーバジェットを正しく運⽤する難易度は⾼い ◦ 最終的には、関係者との合意形成が重要 • トイルの削減 ◦ サービス成⻑に⽐例して作業量が増えないようにトイルを削減する ◦ ⼀朝⼀⼣でトイルを削減できるエンジニアリング⼒は⼿に⼊らないので諦めない ◦ 最初から完璧なしくみを作らない、⼩さく始めて⼤きな成果につなげる • 失敗から学ぶ ◦ インシデントの原因は⼈ではなくシステムである、⼈を⾮難しない ◦ ポストモーテムでドキュメント化する ◦ 再発防⽌アクションは⼈ではなくシステムを改善する 2章のまとめ
62. 65 3章 SREのアンチパターン
63. 3章：SREのアンチパターン • システムの塩漬け • 何もしなくても壊れた • 「秘伝のタレ」によって属⼈化されたオペレーション • ノイズの多いアラート 66 アンチパターンを共通認識とすることで、問題提起をしやすくする
64. 3章：SREのアンチパターン 67 “およそ 70% のサービス障害は、 動作中のシステムの変更によって⽣じていることを発⾒” 引⽤：『サイトリライアビリティエンジニアリング』O'Reilly - 1.3.5 変更管理
65. 3章：SREのアンチパターン • 過度な信頼性の追求や⼿が回らないなどの理由によって、システムに変更を加えない⾏為 • システムに変更を加えると壊れるリスクがある。システムの変更と信頼性のバランスを取るのがSREで あるという話をした • 「システムを変更しなければ壊れない」「システムは動いているので放置する。ソフトウェアアップ デートやリアーキテクチャは⾏わない」といったシステムの変更をやめてしまうのはアンチパターン 68 システムの塩漬け
66. 何もしなくても壊れた 69
67. 何もしない から壊れる 70
68. 3章：SREのアンチパターン • システムは常に周囲の状況が変化している ◦ ユーザのアクセスパターンの変化 ◦ 連携する別のシステムの変更 ◦ 使っているソフトウェアのバージョン更新 ◦ 新たな脆弱性の発⾒ ◦ ハードウェアスペックの進化 ◦ ⼈間の⼊れ替わり • システムに変更を加えなくても、周囲の変化によってシステムがダウンしたり、システム間通信プロト コルの互換性を失ったり、変更を加えることができなくなったりする。 • 変更されないシステムは⻑期的に⾒るとボトルネックとなり事業成⻑を阻害する。 71 「何もしないから壊れる」とは
69. 3章：SREのアンチパターン • 俺の作った最強のスクリプトを個々⼈で所持 ◦ 短期的には成果が出る • サイトリライアビリティエンジニアリング＝運⽤（オペレーション）ではない • スケールしない ◦ サービスやチームが拡⼤すると、対応が追いつかなくなる • ⾃動化が進まない ◦ ⼿作業の“成功体験”が⾃動化の阻害要因になる • 再現性が低い ◦ 個⼈の存在‧集中⼒‧記憶⼒‧体調に左右される • 情報の⾮対称性が⽣まれる 72 「秘伝のタレ」によって属⼈化されたオペレーション 情報をアウトプットし、チームで解決できるようにしましょう
70. • システムに不具合があった場合に担当者に知らせるためにアラートを設定し、オンコール対応を⾏い サービスの復旧を⾏う。 • ⼀⽅で、以下のようなアラートを出すのはアンチパターンである。 ◦ アクションが不要なアラート ▪ 数秒後に復旧し、対応不要なもの（アラートで起こされたけど、すぐに復旧していた） ▪ アラート単体では無視できるもの（CPU使⽤率が90％だったけど、サービスはまだ動いて いるので対応不要） ◦ アクションが不明なアラート ▪ アラートが来たけど、何が問題か分からない、どこから調べたらいいか分からない 3章：SREのアンチパターン 73 ノイズの多いアラート
71. • 担当者は疲弊 • 割り込み対応のコンテキストスイッチが多くなり⽣産性が低下 • オオカミ少年化→本当に重要なアラートが埋もれる 3章：SREのアンチパターン 74 ノイズの多いアラートが多いとどうなるか
72. 3章：SREのアンチパターン 75 • システムは継続的にメンテナンスをしましょう ◦ システムを変更しなくても、環境が変化する。結果としてシステムは壊れる • オペレーションは標準化‧⾃動化しましょう ◦ 属⼈化は情報の⾮対称性を⽣み、事業のスケールを阻害する • アクションが必要なアラートだけを発⾏しましょう ◦ 意図のないアラートは疲弊の原因 ◦ 重要なアラートを⾒逃さないようにする 3章のまとめ
73. 76 さいごに
74. さいごに 77 • SREは⼀部の専⾨職の話ではなく、信頼性を語るための共通⾔語 • サービスの健全性を数値で⽰し、チームで同じ⽬線で判断できる⼟台になる • 適切なレベルの信頼性を⽬指し、機能開発とバランスを取る 本⽇のまとめ 研修を受講した皆さんが配属先で 「信頼性について同じ言葉で語れるチーム」をつくったりその一員になるための、 最初の一歩となることを願っています。
75. さいごに 78 参考書籍
76. 79 Thank You! Thank You!