🦔

SREの知識地図まとめ

に公開
SRE
idea

SREの知識地図が良書であったのでまとめがてら解説記事を投稿します。

1. SREの核心：信頼性の「制御」と「最適化」

SREの最大の目標は、システムの信頼性を制御することにあります。この制御を通じて、開発チームは適切なリスクを取りながら迅速に開発を進めることが可能になります。

  • SREの目標: 信頼性を制御し、ユーザーや開発者の体験を最適化し、ビジネスの価値を最大化すること。信頼性は、サービスが顧客に約束された通りに機能するブランドの基盤です。
  • 信頼性の定義: ユーザーが期待通りにサイトを利用できる度合い。可用性（稼働時間）、レイテンシー（応答速度）、スループットといった具体的な定量指標（SLIの基盤）で測定されます。
  • SREのアプローチ: ソフトウェアエンジニアリングの原則、特に自動化と継続的な改善の手法を運用に応用します。
  • 過剰な信頼性の罠: 100%の可用性は、コスト高・開発速度の低下・実験の機会損失を招きます。過剰な信頼性を求めすぎると、チームの実験的な試みを躊躇させ、結果的にイノベーションを妨げ、システムを硬直化させることすらあります。
  • 文化: データに基づいた意思決定と、問題発生時に個人を責めず、システムやプロセスを改善の対象とする失敗から学ぶ非難なき文化の構築が、心理的安全性と学習を促進します。

2. 信頼性を測る指標：SLI・SLO・エラーバジェット

信頼性を「制御」するために、SREは**SLO（目標）とエラーバジェット（許容範囲）**という強力なツールを用います。

用語 意味 役割
SLI (Service Level Indicator) 信頼性を計測するための指標（例: 成功リクエスト/全リクエスト） 信頼性を計測する ファクト
SLO (Service Level Objective) 信頼性に関する目標値（例: 成功率99.9%） チームが目指す目標 約束
エラーバジェット SLOの許容範囲（例: 1000リクエスト中1回） リスクを許容し、開発の速度を確保する予算
  • エラーバジェットの重要性: SLOに違反していない限り、開発チームは積極的に新機能のリリースや実験を行うことができます。エラーバジェットを使い切ると、開発チームは新規リリースを停止し、**信頼性の改善（バグ修正、トイル削減など）**にリソースを振り向けます。これにより、開発速度と信頼性のバランスが保たれます。
  • SLO導入のステップ: まずユーザーの満足度に大きく影響するクリティカルジャーニー（例: ログイン、商品購入）を特定し、その経路に対するSLI/SLOを設定することが重要です。

3. システムを深く知る：モニタリングとオブザーバビリティ

システムの状態を知る能力は、信頼性確保と迅速な問題解決の土台です。

  • モニタリング: システムの状態をリアルタイムで収集し、既知の異常や障害を検知する仕組み。システムが「期待通りに動いているか」を把握します。
  • オブザーバビリティ（可観測性）: システムの状態を深く知るための能力。「なぜ期待通りに動かなくなったのか」といった未知の問題の原因を探るために、システムから情報を引き出す能力を指します。
  • CNCFが提唱する5つのシグナル: 高いオブザーバビリティを実現するためのデータソースです。
    • ログ (Logs): 発生したイベントの記録。
    • メトリクス (Metrics): 経時的に集計された数値データ（例: CPU使用率、リクエスト数）。
    • トレース (Traces): サービス間のリクエストの流れを追跡し、ボトルネックを特定。
    • プロファイル (Profiles): 実行時のリソース消費の詳細情報。
    • ダンプ (Dumps): クラッシュ時のメモリやプロセスの状態。
  • アラート: 障害の深刻度（重大度）や影響範囲によって通知の強度を分けることで、「ペイジャー・フィードバック・ループ」を適切に回し、オンコール担当者の疲弊（アラート疲労）を防ぎます。

4. 障害を成長につなげる：ポストモーテム

障害発生は避けられません。重要なのは、それを学びにつなげる学習文化を組織内に根付かせることです。

  • 目的: インシデントから得られる教訓を体系的に収集し、チームや組織全体で知識として共有すること。再発防止とシステムの耐障害性向上が最終目的です。
  • 実施: インシデント解決後、記憶が鮮明なうちに速やかに実施します。
  • 非難なき文化の徹底: ポストモーテムは「誰が悪いか」を問うものではなく、「なぜそのシステムは失敗したのか」「プロセスにどこに弱点があったか」に焦点を当てます。
  • アウトプット: 実施後は必ず**改善につながるアクションアイテム（フォローアップタスク）**を設定し、その完了をトラッキングします。

5. オンコールを支える仕組み

障害対応の負担を軽減し、迅速かつストレスの少ない対応を可能にするための「設計」が必要です。

  • Runbook: 障害発生時の対応手順、トラブルシューティング方法などをまとめたドキュメント。オンコール担当者が迅速かつ適切に対応するための重要な自動化の代替となるリソースです。
  • Runbookの記載内容: 目的（いつ使うか）、想定シナリオ、使用ツール、ステップバイステップの対応手順、ロールバック手順など、曖昧さを排除した具体的な情報。
  • 負担軽減: 交代制やバックアップ担当者の配置による負担の平準化と、適切なシフト設計（休息期間の確保）により、エンジニアの疲弊を防ぎます。アラートのトリアージ（優先順位付け）とノイズ削減も、負担軽減に直結します。

6. トイルの削減：自動化への投資

トイルを削減し、エンジニアが付加価値の高い仕事に集中できる環境を創出することは、SREの最も重要なミッションの一つです。

  • トイルとは: 反復的で、手作業で、自動化可能で、戦術的（戦略的ではない）なタスクを指します。例としては、手動でのサーバー再起動や定型的なログ確認などがあります。
  • 目的: トイルを最小限に抑え、エンジニアリングの作業（新機能開発、自動化ツール開発）に集中することで、信頼性の高いサービスの提供とイノベーションの促進を目指す。SREチームは、時間の最低**50%**をエンジニアリング（自動化、設計改善）に費やすべきとされます。
  • 実践: トイルを分類・計測し、削減の計画及び目標設定（例: 来期末までにトイルの時間を20%削減）、そして削減の実施のサイクルを回します。

7. リリースの安全性を高める：PRR

変更は障害の主要な原因の一つです。リリースプロセスに品質保証のプロセスを組み込むことで、リスクを最小化します。

  • PRR (プロダクションレディネスレビュー): 重要な変更を本番環境にリリースする前に、その変更が本番運用の条件（スケーラビリティ、モニタリング、インシデント対応計画、リソース要件など）を満たしていることを、SREチームなどが中心となって確認するプロセス。
  • 効果: リリース時の障害リスクを大幅に低減し、夜間のオンコールを減らすことに貢献します。

8. SREの組織構造

SREチームの組織構造は、会社・チームの規模、事業フェーズ、信頼性に関する目標を踏まえた戦略的な判断が必要です。

  • プロダクト専任パターン（Embedded SRE）: 特定のプロダクトチームにSREが所属し、専門知識を深く共有します。
  • プロダクト横断パターン（Platform SRE / Tooling SRE）: 複数のプロダクトを少数のSREチームが担当し、共通のプラットフォームやツールを提供します。
  • 会社横断パターン（Consulting SRE / Central SRE）: SREチームが全社の基盤やツールの開発・コンサルティングを担当し、組織全体のSRE文化を推進します。

9. SREの実践の始め方

SREのプラクティスは、現場の課題に寄り添う形で段階的に導入することが成功の秘訣です。

  • 課題への寄り添い: SREプラクティスを一方的に推進するのではなく、まずは開発チームが直面している具体的な課題（例: 頻発する障害、デプロイの負担）に共感し、その解決をサポートすることから始めます。
  • 最初のステップ: 課題が不明確な場合や、システムのブラックボックス化が進んでいる場合は、まずはオブザーバビリティ（可観測性）の向上（ログ、メトリクス、トレースの整備）を目指すことが、次のアクション（SLO設定、トイル特定）を見つける土台となります。
  • DevOpsとの関係: SREは、DevOpsの原則（文化、自動化、計測、共有）を、Google流の「ソフトウェアエンジニアが運用を担当する」という形で具体的な実践方法として体現するアプローチの一つです。

10. この本を読んで

自分もSREエンジニアとして日々業務していますが、この知識地図と書籍を通して、改めて以下の重要な点を強く感じました。

信頼性はチームスポーツである: 信頼性やトイルに関すること（SLOの設定、Runbookの整備、トイルの削減）は、SREエンジニア「だけ」が取り組むべき業務ではないということです。

組織全体へのプラクティスの普及: SREエンジニアは、これらのプラクティスをプロダクト開発チームや組織全体に広め、浸透させる役割を担うべきです。開発者が自身のサービスの信頼性を計測し（SLI/SLO）、トイルを自ら特定・削減する文化こそが、真のサービスの安定と開発速度の向上につながると確信しました。

この知識地図と書籍の学びを活かし、チームや組織全体としてSREプラクティスを浸透させていけるよう、実践を続けていきたいと思います。

Discussion