SRE
Site Reliability Engineering の略で、ソフトウェアエンジニアリングの手法でシステムの信頼性を向上させる実践
SRE運用
SRE とは
SRE (Site Reliability Engineering) は、Google が提唱した実践で、ソフトウェアエンジニアリングの手法でシステムの信頼性を向上させる。「運用は自動化すべきソフトウェアの問題」という考え方。
SRE の核となる概念
SRE は SLI (サービスレベル指標: レイテンシ、エラー率)、SLO (サービスレベル目標: 99.9% の可用性)、エラーバジェット (SLO で許容される障害の量)、トイル (手動で繰り返す運用作業)、ポストモーテム (障害後の非難なしの振り返り) を核とする。
SLI / SLO / SLA
| 概念 | 定義 | 例 |
|---|---|---|
| SLI | 測定可能な指標 | P99 レイテンシ、エラー率 |
| SLO | 内部目標 | P99 < 500ms、可用性 99.9% |
| SLA | 顧客との契約 | 可用性 99.9%、違反時に返金 |
エラーバジェットの運用
SLO: 99.9% → エラーバジェット: 月 43 分
バジェット残り > 50%: 新機能を積極的にリリース
バジェット残り < 25%: 信頼性改善を優先
バジェット = 0%: 機能リリースを凍結
トイルの削減
手動デプロイは CI/CD パイプラインに、手動スケーリングは Auto Scaling に、手動アラート対応はランブックの自動化 (SSM) に、手動証明書更新は ACM の自動更新に置き換える。
SRE チームの作業時間の 50% 以上をトイルに費やしている場合、自動化が不足している。
サーバーレスと SRE
サーバーレスではサーバーの監視やパッチ適用が不要 (AWS が管理)、スケーリングも自動化されるため、SRE はアプリケーションレベルの障害対応と信頼性に集中できる。
サーバーレスでは、インフラの運用負荷が大幅に削減され、SRE はアプリケーションの信頼性に集中できる。
ポストモーテム
1. タイムライン: 何が起きたか
2. 影響: ユーザーへの影響
3. 根本原因: なぜ起きたか
4. アクションアイテム: 再発防止策
→ 非難なし (Blameless) が原則
SRE については関連書籍でも詳しく扱われている。