ガイド

SRE（サイトリライアビリティエンジニアリング）とは

SREはGoogleが提唱した「信頼性をソフトウェアエンジニアリングで解決する」アプローチです。SLI/SLO・エラーバジェット・トイル削減という独自の概念で、開発速度と信頼性のトレードオフを管理します。

SREとDevOpsの違い

DevOpsは「開発と運用の文化的統合」という考え方であり、SREはその具体的な実装方法の一つです。

SLI（Service Level Indicator）

サービスの信頼性を測る指標。「何を計測するか」。

例: 直近30日のリクエスト成功率 = 成功リクエスト数 / 全リクエスト数

SLO（Service Level Objective）

SLIの目標値。「どこまで達成するか」。社内的な約束。SLAより厳しく設定する。

例: 可用性SLO = 99.9%/月（月間ダウンタイム許容 = 43.8分）

SLA（Service Level Agreement）

ユーザー・顧客との契約上の約束。SLO未達時のペナルティ（返金等）を含む。SLOより低く設定するのが原則。

例: SLA = 99.5%/月。SLO = 99.9%（バッファ0.4%を社内で吸収）

エラーバジェット（Error Budget）

SLOが99.9%なら、残り0.1%がエラーバジェット（許容できるエラー量）。バジェットが残っている間はリスクのある新機能をリリース可能。バジェットを使い果たしたらリリースを凍結して信頼性改善に集中する。「開発速度 vs 信頼性」のトレードオフをデータで判断する仕組み。

SREはエンジニアリング作業時間の50%以上をトイル（手作業・反復的な運用業務）に費やすべきではないという原則を持ちます。

トイルの特徴（すべて満たすものがトイル）

·手作業（自動化できるのに手でやっている）

·反復的（同じ作業を繰り返す）

·自動化可能（エンジニアリングで解決できる）

·継続的な価値がない（やっても価値が増えない）

·スケールしない（システム成長に比例して増える）

·対応が急を要する（緊急で中断が多い）

トイル削減の優先順位

1位

オンコールアラートの削減: アラートが頻発→根本原因修正。「見るだけ」アラートは即削除。

2位

デプロイの自動化: 手動デプロイ手順をCI/CDに完全移行。承認フローもPRレビューで代替。

3位

キャパシティ管理の自動化: Auto Scalingで手動スケールアップ作業をゼロに。予測スケーリングも活用。

4位

設定変更の自動化: IaCによりコンソール操作・SSHでの設定変更を排除。

SREが重視するオブザーバビリティは「外部の出力からシステムの内部状態を理解できること」。3つの柱で構成されます。

Metrics（メトリクス）

時系列の数値データ。CPU使用率・レスポンスタイム・エラー率。「何が起きているか」を把握する。

Prometheus + Grafana / CloudWatch / Datadog

Logs（ログ）

イベントの記録。「何が・いつ・どこで起きたか」を調査する。構造化ログ（JSON）で検索性を高める。

Loki / CloudWatch Logs / Datadog Logs

Traces（トレース）

分散システムでのリクエスト追跡。「どこでボトルネックが発生したか」を特定する。マイクロサービスで必須。

Jaeger / AWS X-Ray / Datadog APM