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

Slide 1

Slide 1 text

共通言語としての SRE 久米拓馬 @takumakume / GMO PEPABO inc. 2025.4.15 GMO Launcher 2025 - SRE（GMOインターネット合同研修）

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

自己紹介 GMOペパボ株式会社ロリポップ・ムームードメイン事業部事業部CTO 久米拓馬 @takumakume ● 2016年中途入社 ● インフラ、バックエンド、SREを経験 ● 好きなソフトウェアはKubernetes ● 釣りをしたり、コーヒー豆を焙煎したり、ウイスキーを買い集めたりしている

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 1章なぜ「共通⾔語としてのSRE」の話をするか？

Slide 6

Slide 6 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ ● SREは特定の専⾨職だけのものではない ● SREのプラクティスをサービスの開発に関わるすべての⼈の “共通⾔語” とすることで信頼性の優先順位を制御したり、コミュニケーションをスムーズにしやすくするなぜ「共通⾔語としてのSRE」の話をするか？ 6

Slide 7

Slide 7 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ ● ⽴場や役割の違う⼈たちが、同じ⾔葉と意味で会話できる状態 ● 誤解なく、スムーズに、そして建設的に話が進むための“共通の⼟台” 共通⾔語とは 7

Slide 8

Slide 8 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ 󰳖 サービス責任者「この機能、できれば今週中にリリースしたいんだけど、どうかな？」 󰞵 エンジニア「最近サイトが不安定なので、リリースは延期したいです」 󰳖 サービス責任者「なるほど。でも、“どのくらい不安定” なのか、判断むずかしいよね…？」 🙅 共通⾔語がないと… 8

Slide 9

Slide 9 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ 󰞵 エンジニア「最近サイトが不安定で、サービスレベル⽬標をもう少しで下回ってしまいそうです」 󰳖 サービス責任者「それなら今回はリリースを⾒送ろう。スケジュールは調整するよ」 󰞵 開発「次のリリースに向けて改善を進めます！」 ✅ 共通⾔語があると… 9

Slide 10

Slide 10 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ 󰞵 エンジニア「最近サイトが不安定で、サービスレベル⽬標をもう少しで下回ってしまいそうです」 󰳖 サービス責任者「それなら今回はリリースを⾒送ろう。スケジュールは調整するよ」 󰞵 開発「次のリリースに向けて改善を進めます！」 ✅ 共通⾔語があると… 10 事前に取り決めた指標と優先順位を共通言語とすることで、コミュニケーションがスムーズ

Slide 11

Slide 11 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？「Site Reliability Engineering」という⼿法を組織全体の “共通⾔語 “ として活⽤するために知っておくべき基礎知識 ✅ 本⽇お話すること 11 「Site Reliability Engineer」という専⾨職としての振る舞いや個別の技術の話 🙅 本⽇話さないこと

Slide 12

Slide 12 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ ● SRE⽂化を実践しているチームと関わった際に、同じ⼟俵で会話ができるようになる。 ● サービス運⽤の課題に対し、SREを1つの解決⼿段として活⽤できるようになる。 🎯 研修の⽬的 12

Slide 13

Slide 13 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？本資料は新卒エンジニア向けに作成されていますが、受講者が⾃⾝のチーム内で内容を共有しやすいよう、⾮エンジニアの⽅にも理解できる表現や例えを意識して構成した。職種や専⾨性を問わず、「信頼性」について共通の⼟台を持てるようになることを⽬指している。 📝 研修資料について 13

Slide 14

Slide 14 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？サイトリライアビリティエンジニアリングとは 14 引⽤：『SREをはじめよう』O'Reilly - 1.1 SREとはなにか “組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるように⽀援することを⽬的とした⼯学分野”

Slide 15

Slide 15 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ ● 収益 ○ サービスが⽌まると価値は届かない＝収益がない ● 時間 ○ 障害対応などの作業に時間を取られる ● 評判 ○ 信頼性が⾼い競合他社に乗り換えられる ● 健康 ○ オンコールなどによって多くの時間を仕事に割く必要があり、健康に悪影響を及ぼす ● 採⽤ ○ 信頼性の低いシステムを抱え続ける会社で働きたいとは思わない信頼性が与える影響 15 参考：『SREをはじめよう』O'Reilly - 1.1.1 信頼性

Slide 16

Slide 16 text

16 運用に追われて機能開発が先送り

Slide 17

Slide 17 text

17 機能開発に追われて障害の再発防止が先送り

Slide 18

Slide 18 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？適切なレベルの信頼性 18 サービスユーザー SRE 適切なレベルの信頼性を維持できるようにコントロールする信頼性⾼すぎず低すぎない

Slide 19

Slide 19 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？適切なレベルの信頼性 19 サービスユーザー SRE 適切なレベルの信頼性を維持できるようにコントロールする信頼性⾼すぎず低すぎない結果として、より多くの価値をユーザに提供しビジネスを成功に導く

Slide 20

Slide 20 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ 20 適切なレベルの信頼性を維持するにはチームや職種を横断して合意形成が必要

Slide 21

Slide 21 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ 21 共通言語としての SRE

Slide 22

Slide 22 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？より多くの価値を素早くユーザに提供する ● 開発者（Dev）‧運⽤者（Ops）といった組織や⽂化のサイロを打破 ● ソフトウェアデリバリーの効率性や速度を向上 DevOps 22

Slide 23

Slide 23 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ DevOpsとSREの関係 23 引⽤：『SREの探求』O'Reilly - 12章 DevOpsとSRE：コミュニティからの声 SREはプロダクションの運⽤が起点

Slide 24

Slide 24 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ DevOpsとSREを両⽴させて、ユーザに価値を届ける 24 信頼性サービスユーザー SRE 機能 DevOps コントロール

Slide 25

Slide 25 text

1章：なぜ「共通⾔語としてのSRE」の話をするか？ 1章のまとめ ● 本研修でのSREは「Site Reliability Engineering」を指す ● なぜ「共通⾔語としてのSRE」の話をするか ○ SREを持続的に機能させるには、組織全体でSREを共通⾔語にする必要がある ● SREとは、信頼性を上げたり下げたりすることで、機能開発とのバランスを取る ● DevOpsとSREを両⽴し、ユーザに価値を提供し続ける 25

Slide 26

Slide 26 text

26 2章 SREの基礎

Slide 27

Slide 27 text

2章：SREの基礎 27 2.1 サービスレベル⽬標

Slide 28

Slide 28 text

● 100％の信頼性を⽬指さない ○ 信頼性におけるリスクと、イノベーションの速度とのバランスを取る ● 信頼性を測定‧⽬標設定‧定量的に評価することで制御する ○ サービスの品質は、エンジニア個⼈の勘や責任感だけでは管理できない 2.1 サービスレベル⽬標前提となる考え⽅ 28

Slide 29

Slide 29 text

2.1 サービスレベル⽬標信頼性スタック 29 ● SLI（サービスレベル指標） ○ システムの信頼性に関する定量的な測定値 ○ 例：稼働率、レイテンシ、エラーレート ● SLO（サービスレベル⽬標） ○ SLIに対しての⽬標値 ○ 例：稼働率⽉間 99.9％ ● エラーバジェット ○ SLO違反を許容する範囲 ○ 例：稼働率⽉間 99.99％の場合、0.01％ (4分23秒) 引⽤：Alex Hidalgo, ⼭⼝能迪, 成⽥昇司『サービスレベル⽬標』O'Reilly - 1.2 信頼性スタック

Slide 30

Slide 30 text

● 信頼性スタックにおいてベースとなる最も重要な要素 ● ユーザー体験を直接確認する ○ 🙅 CPU使⽤率 ○ ✅ 商品検索にかかる時間 ● SLIをどうやって決めるか 2.1 サービスレベル⽬標 SLI（サービスレベル指標） 30

Slide 31

Slide 31 text

2.1 サービスレベル⽬標 CUJ (Critical User Journey) 31 ● ユーザがサービスを利⽤する上で重要な体験 ● 例 ○ ECサイト：商品検索→カートに⼊れる→決済 ● どのメトリクスを計測すればCUJを担保できるかをベースにSLIを設定する

Slide 32

Slide 32 text

2.1 サービスレベル⽬標 32 “良いSLIは、すべての利害関係者が理解できる平易な⽂章” 引⽤：『サービスレベル⽬標』O'Reilly - 1.2.1 サービスレベル指標サービスに関わるチームや責任者がSLIを理解し、 SLOを下回る場合の優先順位を⾼く合わせる

Slide 33

Slide 33 text

● SLIを決めたらしばらく計測し、現状を把握する ● 現状の値、ユーザの期待、技術的制約を考慮し達成可能な⽬標を設定する ○ 現実とかけ離れた⾼い⽬標を設定すると機能しない ● 稼働率と許容停⽌時間 ○ 99.9% （⽉間 43.83分） ○ 99.99% （⽉間 4.38分） ○ 99.999%（⽉間 26.30秒） ○ あなたのサービスが本当に必要とする信頼性は？ ● ⽬標は定期的に⾒直す ○ サービスにとって重要なことは時間の経過とともに変化する 2.1 サービスレベル⽬標 SLO（サービスレベル⽬標） 33

Slide 34

Slide 34 text

2.1 サービスレベル⽬標 34 “サービスレベル⽬標は、ユーザーやエンジニア、製品チーム、さらにビジネスに、より⼤きな⾄福をもたらすためのものです。” 引⽤：『サービスレベル⽬標』O'Reilly - 1.4.5 すべて⼈に関わる “SLO の⽬標値の末尾に、 9 を増やすことだけが⽬標ではないはずです”

Slide 35

Slide 35 text

● エラーバジェットが余っている → より多くの機能をリリース ● エラーバジェットが超過した → 信頼性の回復に集中 2.1 サービスレベル⽬標エラーバジェット 35

Slide 36

Slide 36 text

ある日、エラーバジェットを超過 36

Slide 37

Slide 37 text

「新機能のリリースが急ぎなので一旦リリース優先で」 37

Slide 38

Slide 38 text

● 信頼性が売上や利益に直結してないように⾒えるケースが多いので、優先順位が上がりずらい ● SLOは適切な「レベルの信頼性」か？ ○ 経済的に合理的な設定か？ ○ SLOが多すぎではないか？ 2.1 サービスレベル⽬標エラーバジェットの運⽤は難しい 38

Slide 39

Slide 39 text

● エラーバジェットが超過する前に⼿を打つことが重要 ● ほとんどの開発リソースを信頼性回復に投⼊しなければならない状況になると、意思決定が振れやすい 2.1 サービスレベル⽬標エラーバジェットを消費し尽くしてからでは遅い 39

Slide 40

Slide 40 text

● エラーバジェットが消費されていくレート ● 将来のある時点までにシステムが消費することになるエラーバジェットの数量を予測する 2.1 サービスレベル⽬標バーンレートをアラートしてエラーバジェットの枯渇前に⼿を打つ 40

Slide 41

Slide 41 text

2章：SREの基礎 41 2.2 トイルの削減

Slide 42

Slide 42 text

サービスを稼働させるのに手一杯 42

Slide 43

Slide 43 text

● ⼿作業である ● 頻繁に繰り返される ● ⾃動化できる ● 割り込み的‧反応的に発⽣する（例：アラート対応） ● ⻑期的な価値を持たない 2.2 トイルの削減トイル：価値を⽣まない反復的作業 43

Slide 44

Slide 44 text

● トイルは⽇に⽇に増え続け、業務の⼤半がトイルになる ● 機能開発や信頼性の回復などの価値を届ける仕事に時間が割けなくなる ● サービス成⻑に⽐例して作業量が増えることで、サービスがスケールしなくなる 2.2 トイルの削減トイルを放置すると 44

Slide 45

Slide 45 text

2.2 トイルの削減トイルの削減は開発とその後のメンテナンスも含めてコストメリットを出す 45 ✅ 引⽤：『サイトリライアビリティワークブック』O'Reilly - 6.2 トイルの計測 🙅

Slide 46

Slide 46 text

2.2 トイルの削減 🙅トイルを削減するために時間がかかりすぎるからやらない 46

Slide 47

Slide 47 text

● シニアエンジニアなら時間に⾒合った成果が得られるが、ジュニアエンジニアだと難しいので⾃動化を諦めるケース ● ⼀⾒コスパが悪いと思っても、積極的にチャレンジしていく姿勢は重要 2.2 トイルの削減 🙅トイルを削減するために時間がかかりすぎるからやらない 47

Slide 48

Slide 48 text

誰でも最初から爆速で解決できないだからといって諦めると上達しない 48

Slide 49

Slide 49 text

● 最初から完璧なシステムを作らない ● ⼩さな改善を積み重ねることで、次の改善の時間が少しずつ⽣まれる ● ドキュメントを書くというのも改善である ○ プロセスが明確化されることで属⼈化から脱却し、チームで解決できる 2.2 トイルの削減⼩さく始める 49

Slide 50

Slide 50 text

● 割り込みによるコンテキストスイッチの減少 ● コードによるプロセスの明確化と標準化 ● ヒューマンエラーの防⽌ ● スキルアップ‧キャリアの成⻑ ● チームの⼠気の向上 2.2 トイルの削減⾃動化による間接的なメリット 50

Slide 51

Slide 51 text

2章：SREの基礎 51 2.3 ポストモーテムの⽂化: 失敗からの学び

Slide 52

Slide 52 text

● サービスに変更を加え続ける中でインシデントは避けられない ● インシデントを再発させない仕組みが必要 ● インシデントの影響‧対応内容‧再発防⽌策をドキュメント化したものがポストモーテム 2.3 ポストモーテムの⽂化: 失敗からの学び失敗からの学び 52

Slide 53

Slide 53 text

● 避難をしない、建設的である ● たとえヒューマンエラーだとしても、特定の⼈を対象に⾮難をしてはならない ● ⼈を罰すると、萎縮し、⾏動しなくなる ● 頻繁にインシデントが発⽣していても、責めてはいけない ● 問題は⼈ではなくインシデントが発⽣するシステムにある 2.3 ポストモーテムの⽂化: 失敗からの学びポストモーテムの⽂化 53

Slide 54

Slide 54 text

2.3 ポストモーテムの⽂化: 失敗からの学び 54 ポストモーテムの例ポストモーテムはドキュメントであり、知識の共有も1つの⽬的である。チーム外のメンバー以外でも分かりやすく簡潔な⽂章を書く。引⽤：『サイトリライアビリティエンジニアリング』O'Reilly - 付録D ポストモーテムの例

Slide 55

Slide 55 text

2.3 ポストモーテムの⽂化: 失敗からの学び 55 アクションアイテムはシステムの改善を設定する。⼈間が「気をつける」だと再発する。根本対処を後回しにしすぎない→偶発的障害はすぐにでも再発する

Slide 56

Slide 56 text

2.3 ポストモーテムの⽂化: 失敗からの学び 56

Slide 57

Slide 57 text

2.3 ポストモーテムの⽂化: 失敗からの学び 57

Slide 58

Slide 58 text

ポストモーテムを書く暇がないです！ 58

Slide 59

Slide 59 text

2.3 ポストモーテムの⽂化: 失敗からの学び 59 ポストモーテムを書くべき閾値を定義するすべてのインシデントにポストモーテムを書こうとすると信頼性に掛ける時間のバランスが取れなくなる ● ユーザへの影響が⼀定の閾値を超えたとき ● データ損失や漏洩が発⽣したとき ● システムの影響範囲が多岐に渡ったとき ● 復旧までの時間が⼀定の閾値を超えたとき ● インシデントの検知が⼈間だったとき

Slide 60

Slide 60 text

2.3 ポストモーテムの⽂化: 失敗からの学び 60 ポストモーテムの作成をワークフロー化する https://speakerdeck.com/hiboma/yapc-kyoto-2023?slide=46

Slide 61

Slide 61 text

2章：SREの基礎 61 ● サービスレベル⽬標 ○ SREはSLI/SLO/エラーバジェットを⽤いてデータドリブンな意思決定を⾏う ○ ⼀⽅で、エラーバジェットを正しく運⽤する難易度は⾼い ○ 最終的には、関係者との合意形成が重要 ● トイルの削減 ○ サービス成⻑に⽐例して作業量が増えないようにトイルを削減する ○ ⼀朝⼀⼣でトイルを削減できるエンジニアリング⼒は⼿に⼊らないので諦めない ○ 最初から完璧なしくみを作らない、⼩さく始めて⼤きな成果につなげる ● 失敗から学ぶ ○ インシデントの原因は⼈ではなくシステムである、⼈を⾮難しない ○ ポストモーテムでドキュメント化する ○ 再発防⽌アクションは⼈ではなくシステムを改善する 2章のまとめ

Slide 62

Slide 62 text

62 3章 SREのアンチパターン

Slide 63

Slide 63 text

3章：SREのアンチパターン ● システムの塩漬け ● 何もしなくても壊れた ● 「秘伝のタレ」によって属⼈化されたオペレーション ● ノイズの多いアラート 63 アンチパターンを共通認識とすることで、問題提起をしやすくする

Slide 64

Slide 64 text

3章：SREのアンチパターン 64 “およそ 70% のサービス障害は、動作中のシステムの変更によって⽣じていることを発⾒” 引⽤：『サイトリライアビリティエンジニアリング』O'Reilly - 1.3.5 変更管理

Slide 65

Slide 65 text

3章：SREのアンチパターン ● 過度な信頼性の追求や⼿が回らないなどの理由によって、システムに変更を加えない⾏為 ● システムに変更を加えると壊れるリスクがある。システムの変更と信頼性のバランスを取るのがSREであるという話をした ● 「システムを変更しなければ壊れない」「システムは動いているので放置する。ソフトウェアアップデートやリアーキテクチャは⾏わない」といったシステムの変更をやめてしまうのはアンチパターン 65 システムの塩漬け

Slide 66

Slide 66 text

何もしなくても壊れた 66

Slide 67

Slide 67 text

何もしないから壊れる 67

Slide 68

Slide 68 text

3章：SREのアンチパターン ● システムは常に周囲の状況が変化している ○ ユーザのアクセスパターンの変化 ○ 連携する別のシステムの変更 ○ 使っているソフトウェアのバージョン更新 ○ 新たな脆弱性の発⾒ ○ ハードウェアスペックの進化 ○ ⼈間の⼊れ替わり ● システムに変更を加えなくても、周囲の変化によってシステムがダウンしたり、システム間通信プロトコルの互換性を失ったり、変更を加えることができなくなったりする。 ● 変更されないシステムは⻑期的に⾒るとボトルネックとなり事業成⻑を阻害する。 68 「何もしないから壊れる」とは

Slide 69

Slide 69 text

3章：SREのアンチパターン ● 俺の作った最強のスクリプトを個々⼈で所持 ○ 短期的には成果が出る ● サイトリライアビリティエンジニアリング＝運⽤（オペレーション）ではない ● スケールしない ○ サービスやチームが拡⼤すると、対応が追いつかなくなる ● ⾃動化が進まない ○ ⼿作業の“成功体験”が⾃動化の阻害要因になる ● 再現性が低い ○ 個⼈の存在‧集中⼒‧記憶⼒‧体調に左右される ● 情報の⾮対称性が⽣まれる 69 「秘伝のタレ」によって属⼈化されたオペレーション情報をアウトプットし、チームで解決できるようにしましょう

Slide 70

Slide 70 text

● システムに不具合があった場合に担当者に知らせるためにアラートを設定し、オンコール対応を⾏いサービスの復旧を⾏う。 ● ⼀⽅で、以下のようなアラートを出すのはアンチパターンである。 ○ アクションが不要なアラート ■ 数秒後に復旧し、対応不要なもの（アラートで起こされたけど、すぐに復旧していた） ■ アラート単体では無視できるもの（CPU使⽤率が90％だったけど、サービスはまだ動いているので対応不要） ○ アクションが不明なアラート ■ アラートが来たけど、何が問題か分からない、どこから調べたらいいか分からない 3章：SREのアンチパターン 70 ノイズの多いアラート

Slide 71

Slide 71 text

● 担当者は疲弊 ● 割り込み対応のコンテキストスイッチが多くなり⽣産性が低下 ● オオカミ少年化→本当に重要なアラートが埋もれる 3章：SREのアンチパターン 71 ノイズの多いアラートが多いとどうなるか

Slide 72

Slide 72 text

3章：SREのアンチパターン 72 ● システムは継続的にメンテナンスをしましょう ○ システムを変更しなくても、環境が変化する。結果としてシステムは壊れる ● オペレーションは標準化‧⾃動化しましょう ○ 属⼈化は情報の⾮対称性を⽣み、事業のスケールを阻害する ● アクションが必要なアラートだけを発⾏しましょう ○ 意図のないアラートは疲弊の原因 ○ 重要なアラートを⾒逃さないようにする 3章のまとめ

Slide 73

Slide 73 text

73 さいごに

Slide 74

Slide 74 text

さいごに 74 ● SREは⼀部の専⾨職の話ではなく、信頼性を語るための共通⾔語 ● サービスの健全性を数値で⽰し、チームで同じ⽬線で判断できる⼟台になる ● 適切なレベルの信頼性を⽬指し、機能開発とバランスを取る本⽇のまとめ研修を受講した皆さんが配属先で「信頼性について同じ言葉で語れるチーム」をつくったりその一員になるための、最初の一歩となることを願っています。