LESSON 30分

ストーリー

田
田中VPoE
SREの全体像を掴んだところで、SREを支える基本原則を学ぼう。これが組織設計の土台になる
あなた
Googleの「SRE本」に書かれている原則ですか？
あ
田
田中VPoE
そうだ。ただし、Googleの原則をそのまま適用するのではなく、うちの組織に合わせてカスタマイズする必要がある。原則の本質を理解した上で、実情に合わせるんだ

SREの7つの基本原則

原則1: 信頼性はビジネス指標

信頼性はそれ自体が目的ではなく、ビジネス目標を達成するための手段です。

誤った考え方SREの考え方
「稼働率100%を目指す」「ビジネスに必要な信頼性を定量化し、その水準を維持する」
「障害はゼロにすべき」「障害のコストとイノベーション速度のバランスを取る」

100%の信頼性は間違った目標だ。ユーザーは99.99%と100%の違いを感じない。だが、その差を実現するコストは桁違いに大きい。

原則2: SLOによる意思決定

SLO（Service Level Objective）をすべての意思決定の基準にします。

SLOに基づく意思決定フロー:

エラーバジェット残り → 十分 → 新機能リリースを加速
                    → 少ない → リリース速度を落とし、信頼性改善に集中
                    → 枯渇 → 新機能開発を停止し、信頼性回復に全力

原則3: トイル（Toil）の削減

手動で繰り返し行う運用作業（トイル）を50%以下に維持します。

トイルの特徴例
手動作業手動でサーバーを再起動
繰り返し毎週同じレポートを手動作成
自動化可能スクリプト化できるのに手作業
戦術的長期的な改善につながらない
サービスの成長に比例ユーザーが増えるほど作業が増える
SREチームの時間配分（理想）:

トイル（運用作業）: ≤ 50%
エンジニアリング（自動化・改善）: ≥ 50%

トイルが50%を超えたら → 組織として対策が必要

原則4: 自動化の推進

繰り返し作業はすべて自動化の候補です。

自動化の段階説明
手動作業人間がすべて実行
ドキュメント化手順書（ランブック）を整備
半自動化スクリプトを人間が実行
完全自動化トリガーに基づいて自動実行
自律的対応システムが自己修復

原則5: 漸進的なリリース

変更は小さく頻繁にリリースし、問題の影響範囲を最小化します。

プラクティス目的
カナリアリリース少数のユーザーで問題を検出
フィーチャーフラグ機能の段階的公開
自動ロールバック問題検知時の即時復旧

原則6: 共有オーナーシップ

開発チームとSREチームがサービスの信頼性を共同で所有します。

従来: 開発チーム → 投げる → 運用チーム

SRE:  開発チーム ←→ SREチーム
      共同で信頼性に責任を持つ
      - 開発: コードの品質、テスト
      - SRE: 可観測性、インシデント対応プロセス
      - 共同: SLO設計、容量計画、ポストモーテム

原則7: 学習する組織

障害から学び、同じ問題を繰り返さない文化を構築します。

プラクティス目的
ブレームレスポストモーテム個人を責めず、システムの改善に集中
インシデントレビュー定期的な振り返りと改善
カオスエンジニアリング計画的に障害を起こし、弱点を発見

まとめ

ポイント内容
7つの原則信頼性はビジネス指標、SLO意思決定、トイル削減、自動化、漸進リリース、共有オーナーシップ、学習する組織
トイルの目標SREチームの時間の50%以下
核心信頼性100%は間違い。ビジネスに必要な信頼性を効率的に実現する

チェックリスト

  • SREの7つの基本原則を理解した
  • トイルの定義と50%ルールを理解した
  • 共有オーナーシップの考え方を理解した

次のステップへ

次は「SREと従来運用の違い」を学びます。具体的にどのようにプラクティスが異なるのかを深掘りしましょう。

推定読了時間: 30分