1. SREの価値観：失敗から学ぶ文化
SRE（Site Reliability Engineering）では、障害や失敗を単なる問題ではなく、組織とシステムを改善するチャンスと捉えます。
障害発生後には「ポストモーテム（事後検証レポート）」を作成し、
- 誰かを責めるのではなく
- 原因を明らかにし
- 改善策を組織全体で共有する
という文化を育てていきます。
2. SLA・SLO・エラーバジェット
SLA（Service Level Agreement）
サービス提供者と利用者の間で合意された「サービス品質に関する契約」。
SLO（Service Level Objective）
SLAを達成するための「具体的な数値目標」。
例：「99.9% の稼働率を維持する」「リクエストの95%を200ms以内で応答する」
エラーバジェット（Error Budget）
SLOをもとに、どの程度のエラーが許容されるかを数値化したもの。
これを活用すると、次のような運用が可能になります：
- バジェットが十分なら新機能のリリースを積極的に行う
- 消費が多い場合は信頼性改善に注力する
しきい値の例：
- ⚠️ 70%超：注意
- 🟠 85%超：要対策
- 🔥 95%超：リリース停止・改善優先
3. モニタリングとオブザーバビリティの違い
モニタリング
あらかじめ決めた指標・しきい値で異常を検知することが目的。
例：「CPU使用率が90%を超えたらアラート」
オブザーバビリティ（観測可能性）
システム内部で何が起きているのかを事前の定義なしに理解できる能力。
問題が起きたときの原因追跡や根本分析が容易になります。
4. モニタリングの基本指標
4つのゴールデンシグナル
- Latency（レイテンシ）：応答時間
- Traffic（トラフィック）：リクエスト量
- Errors（エラー）：エラー率
- Saturation（飽和度）：システムリソースの使用率
USEメソッド（インフラ向け）
- Utilization（利用率）
- Saturation（飽和度）
- Errors（エラー）
REDメソッド（サービス向け）
- Rate（リクエスト発生率）
- Errors（エラー率）
- Duration（処理時間）
5. CNCFが提唱する5つのプライマリシグナル
- ログ（Logs）：イベントやエラーの記録
- メトリクス（Metrics）：数値化された性能・状態指標
- トレース（Traces）：リクエストの流れと遅延の可視化
- プロファイル（Profiles）：リソース使用の詳細分析
- ダンプ（Dumps）：システムのスナップショット解析
6. オブザーバビリティがもたらす価値
オブザーバビリティを高めることで得られるメリット：
- 🚀 障害の根本原因を迅速に特定できる
- 📈 ユーザー体験を改善し、満足度が向上する
- 👩💻 開発・運用チームの負担が軽減される
- 🔄 継続的な改善サイクルが回しやすくなる
7. トイル（Toil）とは何か？
トイルとは、SREにおいてサービス運用に関連する手作業で、反復的で自動化可能な作業を指します。
トイルの特徴
- 手作業である
- 反復的である
- 自動化可能である
- 価値を生まないが必要な作業である
例
- 障害対応のたびに毎回同じスクリプトを手動で実行
- 定期的な手動デプロイ
- 同じ問い合わせへの手作業対応
解決策: 自動化・スクリプト化・標準化により、トイルを削減し、エンジニアの創造的な時間を確保します。
8. PRR（Production Readiness Review）
PRRは、本番環境へのリリース前に「運用可能な状態かどうか」を確認するプロセスです。
チェック項目には次のようなものがあります：
- モニタリング・アラートは適切に設定されているか
- ログ・メトリクスは取得できているか
- ロールバックやリカバリー手順は準備されているか
- SLOが定義されているか
9. 組織構造とコンウェイの法則
コンウェイの法則：「組織は自らのコミュニケーション構造を反映したシステムを設計する」
→ 組織構造はシステムのアーキテクチャにも大きな影響を与えます。
SREチームは、信頼性を中心としたチーム設計を行い、開発チームとの協働を通じてサービス全体の品質向上を目指します。
10. チームトポロジーとインタラクション
SREと開発チームの協働には、チームトポロジーの考え方が役立ちます。
4つのチームタイプ
- ストリームアラインドチーム：ユーザー価値に直結した機能開発
- プラットフォームチーム：共通基盤・ツールの提供
- イネーブリングチーム：専門知識で他チームを支援
- コンプリケイテッドサブシステムチーム：高度な専門領域を担当
3つのインタラクションモード
- コラボレーション：共に課題を解決する
- X-as-a-Service：機能をサービスとして提供
- ファシリテーション：他チームの支援・教育
まとめ
SREは単なる運用チームではなく、信頼性と開発速度のバランスを取る文化と仕組みです。
- 障害から学び改善する
- SLOとエラーバジェットで信頼性を数値化
- トイル削減と自動化で価値を最大化
- チーム構造と協働モデルでシステム全体を最適化
これらを組み合わせることで、安定性と開発スピードの両立が可能になります。