SRE

SREとは

SRE(Site Reliability Engineering:サイト信頼性エンジニアリング)は、運用の課題をソフトウェアエンジニアリングの手法で解決する方法論です。Google が生み出し、書籍として公開されたことで世界に広まりました。

[[DevOps]] が「開発と運用の壁をなくす」という理念だとすれば、SRE はそれを具体的な仕組みと数値で実装したものと言えます。「class SRE implements DevOps」(SRE は DevOps の実装である)という有名な表現があります。

SREの中心概念

概念	意味
SLI(Service Level Indicator)	信頼性の測定指標(例: リクエスト成功率、応答時間)
SLO(Service Level Objective)	SLI の目標値(例: 成功率 99.9% 以上)
エラーバジェット	SLO までの「許容できる失敗の残高」(99.9% なら 0.1% 分)
トイル(Toil)	手作業で繰り返される価値の低い運用作業。自動化の対象

エラーバジェット — 100%を目指さない

SRE の最も重要な発想は「信頼性 100% を目指さない」ことです。100% に近づけるコストは指数的に増える一方、ユーザーは 99.9% と 99.99% の違いをほぼ体感できません。

そこで SLO を定め、目標との差分をエラーバジェット(失敗の予算)として扱います。

バジェットが残っている間 → 新機能のリリースなど、変更に積極的になれる
バジェットを使い切ったら → 新機能を止め、信頼性の改善に集中する

「もっとリリースしたい」対「安定させたい」という対立を、数値に基づくルールで解決するのがエラーバジェットの発明です。

初学者向けポイント

SRE エンジニアの仕事は障害対応だけではありません。トイルの自動化に業務時間の上限(例: 手作業は50%まで)を設け、残りをエンジニアリングに使うのが原則です
SLO は「ユーザーが困るかどうか」を基準に決めます。サーバーの CPU 使用率ではなく、ユーザーから見た成功率や速度を測るのがポイントです
障害対応の実務は [[インシデント対応]]、その検知は [[監視とアラート]] と [[オブザーバビリティ]] が支えます
障害後は個人を責めないふりかえり(ポストモーテム)で、再発防止を仕組みに落とし込みます

関連技術とのつながり

[[DevOps]] — SRE はその理念を具体化した実装と位置づけられる
[[オブザーバビリティ]] — SLI を測るための観測基盤
[[監視とアラート]] — SLO 違反の予兆を検知する仕組み
[[インシデント対応]] — 障害発生時の実務プロセス
[[デプロイ戦略]] — カナリアリリースで観察する指標や「いまリリースしてよいか」の判断を、SLI/SLO とエラーバジェットが数値で支える

Q: エラーバジェットとは何?
- [x] SLO までの「許容できる失敗の残高」
- [ ] 障害対応にかけられる金銭的な予算
- [ ] サーバー購入費用の上限
解説: SLO が 99.9% なら残り 0.1% が失敗の予算です。残高があるうちは変更に積極的になれ、使い切ったら信頼性改善に集中します。

Q: SRE が「信頼性 100%」を目指さない理由はどれ?
- [ ] 障害が多い方がチームの経験になるから
- [x] 100% に近づけるコストは指数的に増え、ユーザーはその差をほぼ体感できないから
- [ ] 法律で 100% が禁止されているから
解説: 99.9% と 99.99% の差をユーザーはほぼ感じられない一方、コストは大きく増えるため、適切な目標(SLO)を数値で定めます。

Q: 「トイル」と呼ばれるものはどれ?
- [ ] 新機能の設計作業
- [ ] ユーザーからの感謝のメッセージ
- [x] 手作業で繰り返される価値の低い運用作業
解説: トイルは自動化すべき反復的な手作業のことです。SRE はトイルを減らし、エンジニアリングに時間を使うことを重視します。