SRE の考え方

SRE とは

SRE（Site Reliability Engineering） は、Google が提唱したソフトウェアエンジニアリングの手法で運用課題を解決するアプローチです。 「運用はソフトウェアの問題である」という前提に立ち、自動化・計測・エラーバジェットを核に据えます。 従来の運用チームが「変更を止めて安定を守る」方針だったのに対し、SRE は「リスクを定量化して許容範囲内で変更を加速する」立場を取ります。

SLI / SLO / エラーバジェット

SLI（Service Level Indicator） はサービス品質を数値化した指標です。 SLO（Service Level Objective） は SLI の目標値であり、たとえば「可用性 99.9%」のように設定します。 エラーバジェット（Error Budget） は SLO の余白部分（100% − 99.9% = 0.1%）で、この予算内で新機能リリースや実験が許可されます。

# エラーバジェット消費率の計算例
total_requests = 1_000_000
slo_target = 0.999  # 99.9%

allowed_errors = total_requests * (1 - slo_target)  # 1,000 件
actual_errors = 750

budget_consumed = actual_errors / allowed_errors  # 75%
print(f"エラーバジェット消費率: {budget_consumed:.0%}")
# => エラーバジェット消費率: 75%

エラーバジェットによる意思決定

エラーバジェットはエンジニアリングとビジネスを接続する共通言語です。 バジェットに余裕があればリリース速度を上げ、枯渇しそうなら信頼性改善に投資するという判断基準を全員で共有します。 この仕組みにより「開発 vs 運用」の対立構造が解消され、両者が同じ指標を見て協調できます。

トイル削減

トイル（Toil） は、手動で繰り返し行われ、自動化可能で、サービスの成長に比例して増加する運用作業です。 SRE チームはトイルを計測し、作業時間の 50% 以下に抑えることを目標にします。 残りの時間をエンジニアリングプロジェクト（自動化ツール開発、信頼性改善）に充てることでトイルを漸減させます。

リリースエンジニアリング

安全なリリースを繰り返すためには、カナリアデプロイ・Progressive Delivery・自動ロールバックの仕組みが必要です。 変更のバッチサイズを小さくし、問題発生時の影響範囲を限定することが基本戦略です。 CI/CD パイプラインにデプロイ後の SLI チェックを組み込み、エラーバジェット消費が急増したら自動でロールバックします。

# カナリアデプロイ後の SLI チェック例（概念的なスクリプト）
CANARY_ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_errors_total[5m])" | jq '.data.result[0].value[1]')
THRESHOLD=0.01

if (( $(echo "$CANARY_ERROR_RATE > $THRESHOLD" | bc -l) )); then
  echo "カナリアのエラーレートが閾値超過。ロールバックを実行します。"
  kubectl rollout undo deployment/api-server
else
  echo "カナリア正常。全体展開を続行します。"
  kubectl rollout resume deployment/api-server
fi

まとめ

📖 参考: 『インフラ大全』第 15 章 — DevOps と SRE