SREの原則から辿る n1 の実践知と現在地

SREの原則から辿る n1 の実践知と現在地
READYFOR VPoE 熊谷 遼平

原則❶
リスクを受け入れる [Embracing Risk]
➡︎ 「信頼性100%は目指さない」と継続的に周知する
原則❷
サービスレベル目標 [Service Level Objectives]
➡︎ いきなりSLOを設定しにいかない
原則❸
トイルの排除 [Eliminating Toil]
➡︎ 「トイル」定義は明確にし、主目的化しない
原則❹
分散システムの監視 [Monitoring Distributed Systems]
➡︎ 車輪の発明はせず、巨人の肩に乗る
原則❺
自動化の推進 [The Evolution of Automation]
➡︎ 当時との差分を理解し、既存のプラクティスに追従する
原則❻
リリースエンジニアリング [Release Engineering]
➡︎ LeanとDevOpsを科学する
原則❼
シンプルさ [Simplicity]
➡︎ 原理原則に真摯に向き合うのが近道
おまけ
輪読会のススメ

Transcript

1. READYFOR VPoE 熊⾕ 遼平 SREの原則から辿る n1 の実践知と現在地 原則❶ リスクを受け⼊れる [Embracing Risk] ➡ 「信頼性100%は⽬指さない」と継続的に周知する 原則❷ サービスレベル⽬標 [Service Level Objectives] ➡ いきなりSLOを設定しにいかない 原則❸ トイルの排除 [Eliminating Toil] ➡ 「トイル」定義は明確にし、主⽬的化しない 原則❹ 分散システムの監視 [Monitoring Distributed Systems] ➡ ⾞輪の再発明はせず、巨⼈の肩に乗る 原則❺ ⾃動化の推進 [The Evolution of Automation] ➡ 当時との差分を理解し、既存のプラクティスに追従する 原則❻ リリースエンジニアリング [Release Engineering] ➡ LeanとDevOpsを科学する 原則❼ シンプルさ [Simplicity] ➡ 原理原則に真摯に向き合うのが近道 おまけ 輪読会のススメ
2. Confidential © READYFOR Inc. All Rights Reserved. 2 ⾃⼰紹介 はじめに 熊⾕ 遼平 READYFOR (レディーフォー) 株式会社 VPoE 兼 EM • X : https://x.com/KUMAN_R • Note : https://note.com/9ma3r • Qiita : https://qiita.com/KUMAN • Facebook : https://www.facebook.com/9ma3r • SpeakerDeck：https://speakerdeck.com/9ma3r
3. Confidential © READYFOR Inc. All Rights Reserved. 3 ⾃⼰紹介 2021年1月18日 
 COURSERA / Google Cloud 
 「Site Reliability Engineering 
 　Measuring and Managing Reliability 」修了 
 https://www.coursera.org/learn/site-reliability-engineering-slos 
 
 
 
 はじめに
4. Confidential © READYFOR Inc. All Rights Reserved. 4 About READYFOR はじめに 社名 READYFOR株式会社 設⽴年⽉ 2014年7⽉ 代表者 ⽶良はるか 事業 • ファンドレイジング事業 • プログラム事業 • フィランソロピー事業 パーパス（存在意義） みんなの想いを集め、 社会を良くするお⾦の流れをつくる
5. 5 Confidential © READYFOR Inc. All Rights Reserved. 前提
6. 6 Confidential © READYFOR Inc. All Rights Reserved. Embedded SRE 検証 SRE本の輪読会 前提＆モチベーション /「実践知」の共有 前提 2017年8⽉ (原.2016年4⽉) 2021年9⽉ (原.2018年8⽉) 2020年6⽉ (原.2018年7⽉) Googleトレンド「SRE」の直近10年間の推移 READYFORでは、2022年〜2024年にかけて SREのプラクティスを導⼊‧検証 世の中的にもSREの訴求が進み、プラクティスが確⽴されてきた中、この数年のREADYFORで得た知⾒を、 n+1の実践知として展開できればと思います。( 次の⽣成AI時代に向けて、改めて⽴ち返る ) ポストモーテム導⼊ ⾃動化やトイル削減を推進 SLI/SLO検証/運⽤ リリースエンジニアリング強化 などなど ※⽣成AIに関しては   あまり触れません ⽣成AIの台頭
7. 7 Confidential © READYFOR Inc. All Rights Reserved. 前提＆モチベーション /「現在地」のスナップショット 前提 https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20250805-cloudai-hc ガートナーのハイプ‧サイクルでは「サイト信頼性エンジニアリング」「プラットフォーム‧エンジニアリング」 ともに幻滅期に⼊り、関⼼が薄れていく時期になるとされている。また同時に⽣成AIが台頭する中、次のSREの 在り⽅を探るためにも、現在の取り組みをスナップショットとして残しておきたい。〜「啓発期」に向けて〜 ？
 【 リライアビリティは砕けない！？ 】 プロダクトやサービスが どのように進化‧発展を遂げようとも サイト信頼性が不要になることはない！？ ただきっと
8. 8 Confidential © READYFOR Inc. All Rights Reserved. SREの原則から辿る n1 の実践知
9. Confidential © READYFOR Inc. All Rights Reserved. 9 原則❶ リスクを受け⼊れる [Embracing Risk] ➡ 「信頼性100%は⽬指さない」と継続的に周知する 原則❷ サービスレベル⽬標 [Service Level Objectives] ➡ いきなりSLOを設定しにいかない 原則❸ トイルの排除 [Eliminating Toil] ➡ 「トイル」定義は明確にし、主⽬的化しない 原則❹ 分散システムの監視 [Monitoring Distributed Systems] ➡ ⾞輪の再発明はせず、巨⼈の肩に乗る 原則❺ ⾃動化の推進 [The Evolution of Automation] ➡ 当時との差分を理解し、既存のプラクティスに追従する 原則❻ リリースエンジニアリング [Release Engineering] ➡ LeanとDevOpsを科学する 原則❼ シンプルさ [Simplicity] ➡ 原理原則に真摯に向き合うのが近道 おまけ 輪読会のススメ ⽬次：SREの原則から辿る n1 の実践知 SREの原則から辿る n1 の実践知
10. 「信頼性100%は⽬指さない」と継続的に周知する 原則❶ リスクを受け⼊れる
11. 11 Confidential © READYFOR Inc. All Rights Reserved. 「信頼性100%は⽬指さない」と継続的に周知する 01 リスクを受け⼊れる ‧SREプラクティスの導⼊初期や、過剰な信頼性を追求するケースが散⾒される場合、まずは⽬線合わせから。 ‧⾃サイトの信頼性の状況を、定性ではなく、定量で明確に⾔い切れるようにすることが最初の⼀歩。 可⽤性 レベル 許可される利⽤不可期間 1年当たり 四半期ごと ⽉あたり 週あたり 1⽇あたり 1時間 当たり 100.00% 0秒 0秒 0秒 0秒 0秒 0秒 99.999% 5.26分 1.30分 25.9秒 6.05秒 0.87秒 0.04秒 99.99% 52.6分 12.96分 4.32分 60.5秒 8.64秒 0.36秒 99.95% 4.38時間 1.08時間 21.6分 5.04分 43.2秒 1.8秒 99.90% 8.76時間 2.16時間 43.2分 10.1分 1.44分 3.6秒 99.50% 1.83⽇ 10.8時間 3.6時間 50.4分 7.20分 18秒 99% 3.65⽇ 21.6時間 7.2時間 1.68時間 14.4分 36秒 95% 18.25⽇ 4.5⽇ 1.5⽇ 8.4時間 1.2時間 3分 90% 36.5⽇ 9⽇間 3⽇ 16.8時間 2.4時間 6分 コスト 信 頼 性 100% 100%の信頼性は 費⽤対効果が合わない。 (もちろんセンシティブなサービスは除く)
12. いきなりSLOを設定しにいかない 原則❷ サービスレベル⽬標
13. 13 Confidential © READYFOR Inc. All Rights Reserved. いきなりSLOを設定しにいかない 02 サービスレベル⽬標 SLO導⼊に向けて試⾏錯誤を繰り返したが、どうにも定着しなかった...... SLOの導⼊を⾊々と試みたが、中々上⼿くいかなかった。 1) 単独のSREチームがSLOを掲げても浸透しない 🤔 2) Embedded SREとしてチームにSLOありきで設定を促しても形骸化する 🤔 3) チームに定量的な肌感がないままSLOを設定しても、全く定着しない 🤔 SLO運⽤は諦めて、チーム主導でのSLI運⽤だけを回したところ、 徐々にSLOが浮かび上がってきた！？
14. 14 Confidential © READYFOR Inc. All Rights Reserved. SLI/SLOの導⼊当初は、SLO設定は急がず、まずは各チーム主導でSLIと向き合う事から始めてみる。 いきなりSLOを設定しにいかない ➡ まずはSLIの運⽤から始めてみる 02 サービスレベル⽬標 I. 各チームにコア領域を割り当て、SLIを1〜3つ設定してもらう。ユーザージャーニーも明確にする。 II. SLIを選定する際、全エンドポイントと各数値を⼀覧列挙し、簡単に取捨選択できるようにする。➡ SLI探索シート HOW 01 各チーム主導で各領域のSLIを１〜３つ設定する I. 各チームが設定したSLIは、部全体の主要指標として明確に掲げて、全体で共有する。➡ SLI⾃動集計‧レポート II. SLIの状況は最低でも期間１年間以上で追う。(時間帯、⽉末⽉初、シーズナル等の外れ値で右往左往しないように！) HOW 02 部全体でSLIを掲げて、定期的な状況確認‧共有の場を設ける I. 全体共有とは別に⽉２回程度、チームリード同⼠が集まり、SLIの状況確認や対応の有無についての場を設ける。 II. SLIの変化に対して、調査‧対応するかは各チームリード(=開発タスクの管理責任者)が適宜判断する。 HOW 03 SLIの変化に対する調査‧対応は各チームリードに委ねる
15. 15 Confidential © READYFOR Inc. All Rights Reserved. SLI探索シート 02 サービスレベル⽬標 ① SLI選定は、全エンドポイントにおける基本的な数値を列挙し、各担当が全体感を把握しながら精査する。 ② エンドポイントを決めで指定すると考慮漏れが発⽣したり、再現性のある⾒直しや改善に繋がりづらい。 全ての エンドポイント⼀覧 各エンドポイントの数値 ‧リクエスト数 ‧レイテンシ ‧可⽤性 ステータスコード別の数値 SLI選定 チェックボックス ( チェックすると   ⾃動集計される) イメージ画像 1 2 3 4
16. 16 Confidential © READYFOR Inc. All Rights Reserved. SLI⾃動集計＆レポート 02 サービスレベル⽬標 ③「探索シート」でチェックしたエンドポイントが⾃動で反映されるようするとスムーズ。 ④ 主要な指標は⼀通り、より詳細に集計‧可視化されるようにするとともに、極⼒⾃動化する。 イメージ画像 各SLIの状況は ⼀⽬で追える ようにする
17. 17 Confidential © READYFOR Inc. All Rights Reserved. SLI⾃動集計＆レポート 02 サービスレベル⽬標 ⑤ 設定したSLIによってボラティリティが⼤きく異なる。まずは傾向を癖をしっかり掴んでいく。 ⑥ 定点観測とリアルタイムでの調査‧対応検討を重ねることで、各SLIの必要性や対応すべき閾値が⾒えてくる                                      ➡ ブラッシュアップしていく イメージ画像 イメージ画像 SLIの呼吸を知る
18. 18 Confidential © READYFOR Inc. All Rights Reserved. 各指標の傾向や癖の把握や、リアルタイムでの調査‧対応の積み重ねが、SLO運⽤への近道であった。 いきなりSLOを設定しにいかない ➡ SLI運⽤を重ねがなら納得感のあるSLOへ 02 サービスレベル⽬標 I. 各数値はどのような理由で、どのように変動するのか、そもそもの定量的な肌感がないと⽬標も形骸化しがち。 II. SLIの状況は最低でも期間１年間以上で追う。(時間帯、⽉末⽉初、シーズナル等の外れ値で右往左往しないように！) POINT 01 SLIの定量的な傾向や癖を掴めてくる I. 定量的な傾向や癖の確認を重ねる中で、各SLIで「対応しなくて良い」or「しなきゃまずい」のラインが⾒えてくる。 II. 同時にボラティリティが⾼かったり、再現性がなかったりと、活⽤しづらいSLIの特徴なども⾒えてくる。 POINT 02 SLIの変化に対して、対応するか否かの傾向が⾒えてくる I. リアルタイムでの数値変動とともに、調査‧対応を重ねることで、SLI/SLOがブラッシュアップされていく。 II. 何か急ぎでSLOの設定が必要な訳ではなく、定量的な肌感覚も⾼くない場合、SLIと馴染むことが結果的に近道。 POINT 03 POINT１〜２を重ねながら、確度の⾼いSLOへと育てていく
19. 19 Confidential © READYFOR Inc. All Rights Reserved. 当初、エラーバジェットの運⽤も検討したが、⾒送ることとした。 エラーバジェットの運⽤はしない 02 サービスレベル⽬標 I. 信頼性指標は、利⽤者の増減や機能開発を続ける限り、変動し続けるため、そこを基準とした強い意思決定は難しい。    (⼤規模な事業‧組織‧サービスで、強い統制が必要であれば別かもしれないが、少なくともREADYFORでは ) 理由 01 信頼性指標だけでは、機能開発を停⽌する動機としては乏しい I. 機能開発を全て⽌めて、リソースを信頼性改善に全振りしなければならないケースはあまり想定できない。    (アジャイルやDevOpsの発展により柔軟迅速なリリースが可能になったことも⼤きい？ブルックスの法則にも陥る。 理由 02 機能開発 or 信頼性改善の⼆者択⼀にならない。 I. 「信頼性をアクティブに統制」し「将来のインシデントを軽減」することが重要。(*1 ) II. そのためには信頼性の定量化と適切な把握、柔軟な運⽤は⼤切だが、エラーバジェットはオプショナルで良い。 理由 03 信頼性の統制を⽬的とするならば必ずしも必要ない。 *1.信頼性成熟度: https://cloud.google.com/blog/ja/products/devops-sre/evaluating-where-your-team-lies-on-the-sre-spectrum
20. 「トイル」定義は明確にし、主⽬的化しない 原則❸ トイルの排除
21. 21 Confidential © READYFOR Inc. All Rights Reserved. 「トイルの定義」の認識を全体で合わせる 「本番環境のサービス運⽤に付随する作業」において ① マニュアルでの作業：  ‧⼿動スクリプトの実⾏など。 ② 反復する作業：  ‧何度も繰り返す作業 ③ ⾃動化可能な作業：  ‧機械で代替可能な作業 ④ 永続的な価値のない作業：  ‧完了後もサービスの状態が変わらない作業 ⑤ O(n)に⽐例する作業：  ‧サービス規模、トラフィック量、   ユーザー数に⽐例して増加する作業 「トイル」定義は明確にし、主⽬的化しない 03 トイルの排除 ①トイル削減は⼤切だが、特定チームにだけで主⽬的化されて、ビルドトラップに陥らないように気をつける。 ② 開発チーム全体で、このプラクティスが浸透し、⾃然に取り組めている状態が望ましい。 定義 (ex) ソフトウェア エンジニアリング •コードの作成または修正 •関連する設計およびドキュ メント作成作業 •自動化スクリプトの作成 •ツールやフレームワークの作成 •スケーラビリティと信頼性のための サービス機能の追加 •インフラストラクチャコードの堅牢性向 上のための修正 システム エンジニアリング •本番システムの構成 •構成の変更 •システムのドキュメント化 •セットアップとアップデートの監視 •負荷分散の構成 •サーバー構成、 OSパラメータの調 整、ロードバランサーの設定 •アーキテクチャ、設計、本番環境に関 するコンサルティング トイル 反復的、手動など、サービス の実行に直接関連する作業 オーバーヘッド サービスの運営に直接関連し ない管理業務 •採用、人事関連の書類作成 •チーム/社内会議 •バグキューの衛生管理 •レビュー、自己評価 トイルの定義 ▼ ⼀般的なSREの４つのアクティブティ 図. 書籍「SRE サイトエンジニアリングリライアビリティ」を元に作成 ⼤事なのは「エンジニアリング」業務 “すべてのSREは、数四半期または1年間の平均で、少なくとも 50%の時間をエンジニアリング作業に費やす必要があります。“
22. ⾞輪の再発明はせず、巨⼈の肩に乗る 原則❹ 分散システムの監視
23. 23 Confidential © READYFOR Inc. All Rights Reserved. ⾞輪の再発明はせず、巨⼈の肩に乗る 04 分散システムの監視 S3 WAF Cloud Front Aurora Storage Transfer Cloud Storage BigQuery Data stream dbt Datadog SendGrid Cloud Functions Pub/Sub etc Replication Log Archives Get Object PUT Put log files Post Webhook Publish Spread Sheet Looker Stuido Redash ❹ アプリケーション及びクラ ウドプラットフォームの ログ収集‧可視化‧監視は Datadogに集約させる ❺ ログ永続化やデータ統合、 データ加⼯‧変換処理、デー タマスキング等々は BigQueryに集約させる。 ❶ As Simple as Possible, No Simpler ❷ 右三⾓なDAG(有向⾮巡回グラフ)を⽬指す。 ❸ フルマネジメントなサービスを極⼒⽤いる。   (内製化によるコストメリットが余程ない限り) SRE本の発売当初と⽐較すると、各種クラウドサービスやSaaSはかなり確⽴されているため、素直に使う。 [構成紹介]
24. 24 Confidential © READYFOR Inc. All Rights Reserved. SLI/SLOに関するデータ収集‧可視化フロー 04 分散システムの監視 Datadog Logs を Archive経由で BigQueryに保持し、そこからSLIデータの集計‧可視化を⾏う。 Datadog S3 Storage Transfer BigQuery dbt Cloud Storage Spread Sheet Slide Datadog Log Archive を⽤いてログデータをS3 にバックアップ S3の Log Archiveを CloudStorageへ転送 BigQueryの外部テーブル でCloudStorage参照 SLI/SLOで利⽤しやすい ように view を作成 スプレッドシートで ⼀覧列挙‧集計‧可視化 レポーティング資料 と同期 コードは書かずに、フルマネジメントなツールを極⼒利⽤する
25. 25 Confidential © READYFOR Inc. All Rights Reserved. Datadog SLOs は検討したが......。 04 分散システムの監視 SLI/SLO運⽤のDatadog完結を試みたが、以下の理由から⾒送る。(今後の機能拡充や使い勝⼿を踏まえ再検討) ❶ クエリ表現が弱い。 SQLクエリと⽐較すると扱いづらく、 設定したいSLI定義が表現できない。 ❷ 対象期間が限定される。 期間は枝葉ではなく広くみた⽅が 望ましいが、ログの保存期間に依存 する。 ❸ 閲覧‧共有が絞られる。 SREチームのみであれば良いが、 部全体での利⽤‧展開を踏まえると どうしても扱いづらい。( 仮にSRE チームに閉じていて問題ないという場合、逆に SLI/SLOの適切な運⽤ができているか怪しい？)
26. 26 Confidential © READYFOR Inc. All Rights Reserved. (特に⽬新しくないが)、⽇々の監視運⽤やMTTD/MTTRの最速化のため、秘伝のタレ的なダッシュボード運⽤。 分散システムの各種メトリクスはDatadog集約 04 分散システムの監視
27. 当時との差分を理解し、既存のプラクティスに追従する 原則❺ ⾃動化の推進
28. 28 Confidential © READYFOR Inc. All Rights Reserved. 当時との差分を理解する 05 ⾃動化の推進 ‧当時と⽐較すると、クラウドサービスやIaCなどツールは格段に確⽴され、洗練されている。 ‧当時の課題は何で、今現在はどうなっているのか？を把握しながら、既存のベストプラクティスを導⼊する。 2017年8⽉ (原.2016年4⽉) Googleトレンド「SRE」の直近10年間の推移 SRE本で紹介されている自動化のユースケース例 1) ユーザーアカウントの作成 2) サービスのクラスターのターンアップとターンダウン 3) ソフトウェアまたはハードウェアのインストール準備と廃止 4) 新しいソフトウェアバージョンの展開 5) ランタイム構成の変更 6) ランタイム構成の変更の特別なケース :依存関係の変更 *このリストは本質的に無限に続く可能性があります。 サービスやツールは⾶躍的に拡充 SRE本の発売当時、下記の技術は まだまだ発展途上かつ未成熟で、 内製化の余地はたくさんあった。 (オンプレ利⽤もまだ多く残存) ‧クラウドサービス (SaaS/Paas) ‧コンテナ技術 ‧Infrastructure as Code ‧DevSecOps ‧CI/CDパイプライン ‧Observability ‧etc
29. 29 Confidential © READYFOR Inc. All Rights Reserved. 既存のプラクティスを活⽤しよう 05 ⾃動化の推進 リリース 要件 定義 設計 開発 テスト 分析‧企画 仮想開発環境の⾃動化 ☑開発環境構築：Docker Compose / Dev Containers ☑クラウド開発環境プロビジョニング：Terraform テスト環境構築の⾃動化 ☑テスト環境の⾃動⽴ち上げ：SlackApp & AppRunner ☑指定バージョンの⾃動デプロイメント：GitHub Actions ビルド＆継続的インテグレーションの⾃動化 ☑静的解析とリンティング：ESlint(JS)、RuboCop(Ruby) ☑ユニットテスト＆結合テスト：Vitest(JS)、Rspec(Ruby) ☑CIパイプライン全体：GitHub Actions テストの⾃動化 ☑E2Eテスト：Playwright、Autify ☑パフォーマンス‧負荷テスト：k6、JMeter ☑Visual Regression テスト：Chromatic セキュリティチェックの⾃動化 ☑セキュリティ脆弱性診断：Brakeman(Ruby)、Trivy ☑ソフトウェア構成分析：Dependabot、Renovate ☑動的アプリケーションセキュリティテスト：ZAP デプロイ＆運⽤の⾃動化 ☑構成管理＆デプロイ：Terraform、GitHub Actions、ECS ☑モニタリング＆アラート：Datadog、CloudWatch ☑バッチ処理&定期実⾏：EventBridge、maintenance_tasks ⽣成AIの台頭で ⾃動化の可能性 は拡⼤ 内製化で⼯夫する余地はほとんどなくなり、ツールとサービスの組み合わせでモダンなプラクティスを追従する。
30. 30 Confidential © READYFOR Inc. All Rights Reserved. xxxx ※ ⽣成AIによる⾃動化の可能性 05 ⾃動化の推進 ⽣成AIで「⾃然⾔語」を扱えるようになったことで、ラストワンマイルな反復作業やマニュアル作業等の⾃動化 の幅は広がった。(遊び半分で作成した) カジュアルなSlackアプリ例の紹介。(けっこう多⽤されてはいる...) ① ワークフローで インシデント報告 ⾃動登録 報告書⽣成 ポストモーテム伝道侍 (直近の１週間のインシ デントがあれば、要約 して共有会を実施 ) 通知 (テンショ ン⾼く...) ① Slack Appに 起票指⽰ メンション ②スレッド 情報取得 ③ Issueの 件名/本⽂ を⽣成 ② 参照 ③ 投稿 ④ GitHub Issue 作成 ⑤ Slack 投稿 構成概略 構成概略 ❶ ポストモーテム伝道侍 ❷ GitHub起票君 Slack上 の議論や アラート
31. LeanとDevOpsを科学する 原則❻ リリースエンジニアリング
32. 32 Confidential © READYFOR Inc. All Rights Reserved. LeanとDevOpsを科学する 06 リリースエンジニアリング ‧リリースエンジニアリングは、より体系的に整理されている「LeanとDevOpsの科学」も参照。 ‧「⾃動化の推進」同様、現代では⼀定確⽴されていることを前提に、迅速にプラクティスの検討‧導⼊する。 2017年8⽉ (原.2016年4⽉) Googleトレンド「SRE」の直近10年間の推移 ”リースエンジニアリングは、... 簡潔に言えばソフトウェアの構築とデ リバリーです” “コード変更が本番環境にデプロイされるまでの時間（つまりリリース 速度）や、ビルド設定ファイルで使用されている機能に関する統計情 報など、様々な指標を報告するツールを備えています。これらのツー ルのほとんどは、リリースエンジニアによって構想・開発されました。 ” 2018年11⽉ (原.2018年3⽉) 確⽴されてきている
33. 33 Confidential © READYFOR Inc. All Rights Reserved. Ref. FourKeysの取り組み 06 リリースエンジニアリング リリースエンジニアリングに関連する内容、特に FourKeys に関する実践例は、今年のEMConfでも発表して いるため、もしご興味あれば参照ください。( 今回は SRE イベントのため 詳細は割愛 ) 【 EM Conf 2025 】 1行のコードから社会課題の解決へ EMの探究、事業・技術・組織を紡ぐ実践知 https://speakerdeck.com/9ma3r/emconf2025
34. 原理原則に真摯に向き合うのが近道 原則❼ シンプルさ
35. 35 Confidential © READYFOR Inc. All Rights Reserved. 今後、⽣成AIの台頭もあり、SREの発展や応⽤が進んでいく中、原則から忠実に⽴ち返ることは⼤切。 ということで、原則「シンプルさ」(*1) を引⽤しながら、これまでの総括。 ( *1. SRE本 第9章「Simplicity」) 原理原則に真摯に向き合うのが近道 原則❼ シンプルさ ‧「複雑な仕組みで解決しようとする誘惑」を断ち切ろう。 ‧認知負荷は下げる施策の前に、そもそも⾼い仕組みは⼊れない。 ‧”完璧とは、取り除くものがなくなった時に達成される” POINT 01 “信頼性の代償は、    最⼤限のシンプルさの追求” ‧「退屈」➡「予測可能性」を⾼めて、サプライズを減らそう。  ( 「予期せぬ出来事」ではなく「織り込み済みの出来事」にする) ‧偶発的複雑性を減らすための建設的な議論の場を設計しよう。 POINT 02 “退屈の美徳” / ⽬指すのは、 何も起こらない「退屈」なシステム ‧⼩さく⾼速なリリースの効果は絶⼤。 ‧最⾼のコードは、書かれなかったコードである。  ( リリースさえ不要な解決策がないか常に検討する ) POINT 03 “リリースのシンプルさ” / ⼩さなリリースは⼤きな安定を⽣む いずれも当たり前の事かも仕⼊れないが、凡事徹底は難しい...
36. 36 Confidential © READYFOR Inc. All Rights Reserved. おまけ
37. 37 Confidential © READYFOR Inc. All Rights Reserved. まずは基本からということで「SRE探求会」と称して、SREチーム内でSRE本＆ワークブック本の輪読会を実施。 各書の実践編はそれぞれ興味度合いを事前ヒアリングし、全体感やそれぞれの傾向を共有しながら進⾏。 輪読会のススメ おまけ ▼無料公開ページ https://sre.googl e/sre-book/table- of-contents/ ▼無料公開ページ https://sre.googl e/workbook/tabl e-of-contents/
38. Enjoy SRE ！！ ご清聴ありがとうございました！