> [!abstract] 概要 > [[Ben Treynor Sloss]]（Google VP of Engineering、SRE 創設者）による SRE の定義と核心原則の章。従来のシステム管理者モデルの限界を示し、Google が採用した SRE モデルの人員構成・運用上限・中核テネットを体系的に提示する。 ## 書誌情報 - 書名: Site Reliability Engineering: How Google Runs Production Systems - 章: Chapter 1 — Introduction - 著者: [[Ben Treynor Sloss]] - 出版: O'Reilly Media, 2016 年 4 月 ## 従来モデルの限界 従来のシステム管理者（sysadmin）モデルには 2 つの構造的欠陥がある。 1. **線形スケーリング**: サービスの成長に比例して運用チームの人員が増加する。手作業による管理は規模に対してスケールしない。 2. **開発と運用の対立**: 開発チームは機能追加と速度を求め、運用チームは安定性と変更抑制を求める。両者の目標が構造的に矛盾する。 ## Google の SRE モデル ### 人員構成 Google の SRE チームは以下の混成で構成される。 - **50〜60%**: ソフトウェアエンジニア（通常の SE 採用基準を満たす） - **40〜50%**: ソフトウェアスキルの 85〜99% を備え、加えて UNIX システム内部やネットワーキング（L1〜L3）の専門性を持つ人材 ### 50% ルール 運用作業（[[トイル]]）の上限を **50%** に設定する。残りの時間はエンジニアリング——自動化、ツール開発、アーキテクチャ改善——に充てる。これにより、サービスの規模が増大してもチームの人員が線形に増加しない構造を実現する。 ## 中核テネット ### エラーバジェット 100% の信頼性は目標として不適切である。プロダクトチームと SRE が共同で四半期ごとの[[エラーバジェット]]を設定し、信頼性とイノベーション速度の均衡を取る。バジェットが残っている間はリリースを加速でき、消費されたらリリースを制限する。これにより開発と運用の対立を共通のインセンティブで解消する。 ### モニタリング モニタリングにおいて、人間がアラートを解釈する設計は誤りである。システムがデータを解釈し、人間に求められるアクションを 3 種に分類する。 - **アラート（Alert）**: 即時の人間の介入が必要 - **チケット（Ticket）**: 人間の対応が必要だが即時でなくてよい - **ログ（Log）**: 診断や事後分析のために記録するが、人間は能動的に見ない ### 緊急対応 [[プレイブック]]を用いた対応は、記憶に頼る対応と比較して MTTR を約 **3 倍**短縮する。直感的な「ヒロイズム」よりも、文書化された手順に従う規律的な対応のほうが信頼性を高める。 ### 変更管理 障害の **70%** はライブシステムへの変更に起因する。変更管理のベストプラクティスは以下の 3 点である。 1. **漸進的ロールアウト（progressive rollout）** 2. **迅速かつ正確な問題検知** 3. **問題発生時の安全なロールバック** ### キャパシティプランニング サービスの需要予測と、需要に対応するためのプロビジョニングを含む。有機的成長（自然なユーザー増加）と非有機的成長（機能追加・マーケティングキャンペーン等）の両方を考慮する。 ## SRE と DevOps の関係 Treynor Sloss は、SRE は DevOps の**具体的実装**（specific implementation）であり、逆に DevOps は SRE の**一般化**（generalization）であるという対称的な関係を提示する。両者は共通の原則——サイロの解消、事故からの学習、自動化の重視——を共有するが、SRE はより規範的（prescriptive）な実践体系を持つ。