SRE とは？ 意味と仕事内容、SLO・エラーバジェットを解説
要約
SRE は、本番システムの運用を手作業ではなくソフトウェアエンジニアリングで行う取り組みです。数値の信頼性目標（SLO）を立て、その範囲内で改善と開発のバランスを取ります。繰り返しの作業（トイル）は自動化し、運用の負荷を下げます。
SRE とは、本番環境のシステムを手作業ではなく、ソフトウェアエンジニアリングで運用する取り組みです。チームは信頼性の数値目標を決め、その数字を測定し、サービスを維持するための繰り返し作業を自動化します。毎月同じディスクのアラートで午前3時に呼び出されているなら、SRE はまさにその問題を取り除くために存在します。
Google がこの言葉を使い始めたのは2003年ごろとされています。現在は Google の外でも広く使われており、20人規模のスタートアップから銀行まで採用されています。違いは規模であり、中心となる仕組みはほぼ同じです。
SRE エンジニアは実際に何をするのか
Google で SRE チームを立ち上げた Ben Treynor Sloss は、Google SRE 本の冒頭の章で端的に述べています。SRE とは、ソフトウェアエンジニアに運用チームを設計させたら何が起きるか、という問いへの答えだ、と。運用の仕事を、コードを使って行うということです。
通常の1週間は、大きく4つの仕事に分かれます。サービスにとって「正常に動いている」とは何かを定義します。そうでない状態を検知する監視を作ります。障害が起きたら対応し、次の人が同じ件で呼び出されないように修正を書きます。
2つの例で具体的に考えてみます。毎週木曜に手作業でデプロイしているチームなら、自動ロールバック付きのパイプラインを作ります。毎晩リークしているサービスを再起動しているチームなら、リークの原因を見つけて直します。どちらも繰り返しの作業を一度きりのプロジェクトに変えています。それが SRE の本質です。
4つ目の仕事は、多くのチームが見落とします。障害対応しかしない SRE は、肩書きを変えただけの運用エンジニアです。ソフトウェアとして仕組みを改善する部分こそが、この役割を別物にしています。
SRE と DevOps の違い
DevOps は文化です。開発者と運用担当者が、リリースするものとその稼働に共同で責任を持つという考え方です。チーム間の壁が問題だと示してくれますが、どこまでのダウンタイムを許容するか、いつリリースを止めるべきかは教えてくれません。
SRE はその答えになる数字を提供します。SLO、エラーバジェット、手作業の上限です。Google 自身の整理では、SRE は DevOps の考え方を具体的に実装する一つの方法です。
どちらが「優れているか」の議論は、ほどほどにしてください。8人のチームなら、両方から借りることになります。役に立つ問いは、そのサービスがどれくらい信頼できる必要があるのかを、チームが一文で答えられるかどうかです。
SLI、SLO、SLA とは何か、なぜ重要なのか
SRE では3つの略語がほとんどの重みを担っており、人はよく混同します。
SLI（サービスレベル指標）: 測定値です。例えば、300ミリ秒以内に 5xx 以外の応答が返った HTTP リクエストの割合などです。
SLO（サービスレベル目標）: その測定値の目標です。例えば、直近28日間で99.9%のリクエストが成功する、といったものです。
SLA（サービスレベル合意）: 未達の場合は返金などの罰則を伴う契約です。SLA は SLO より緩く設定します。
これを決める理由は、「サービスは速くて信頼できるべきだ」という文章はテストできないからです。「チェックアウトリクエストの99.9%が500ミリ秒以内に成功する」という目標ならテストでき、議論に決着をつけられます。
最初はサービスごとに2〜3個の SLI から始めてください。それ以上になると、誰も覚えられなくなります。ユーザーが実際に体感できる SLI を選びましょう。CPU 使用率は原因であって症状ではありません。失敗したチェックアウト、遅いページ読み込み、古いデータこそ、顧客が気づくものです。
エラーバジェットはどう機能するのか
エラーバジェットとは、SLO が許容している不安定さのことです。単純に1から SLO を引いた値です。可用性の目標が99.9%なら残りは0.1%で、30日の月ならおよそ43分のダウンタイムに相当します。
計算の仕組みそのものが本質なので、小さなコード例を示します。
slo = 0.999
window_minutes = 30 * 24 * 60 # 43,200
budget = (1 - slo) * window_minutes # 43.2 分
spent = 31 # これまでの不良サービス時間（分）
print(f"残り {budget - spent:.1f} 分") # 残り 12.2 分バジェットが残っている間は、チームは速くリリースします。使い切ったら機能リリースを止め、作業を信頼性の改善に移します。SRE Workbook のエラーバジェットポリシーの例が、チームがそのルールをどう文書化するかを示しています。
目的は罰することではありません。開発者はリリースしたい、運用担当者は安定させたい、という古くからの対立を、両者が読める共通の数字に置き換えることです。ただし、リーダーシップが事前に一時停止を守ると合意していなければ機能しません。四半期ごとに覆される予算ポリシーは、飾りにすぎません。
なぜ「トイルは50%以下」というルールがあるのか
トイルとは、サービスの規模に比例して増え、何も残さない手作業の繰り返しです。詰まったワーカーを手で再起動するのはトイルです。それを自動で再起動するヘルスチェックを書くのはエンジニアリングです。
Google の SRE 組織は、各エンジニアの時間のうちトイルを50%未満に抑えることを目指しています。詳細はトイルの排除に関する章にあります。残りの時間は、将来のトイルを減らすプロジェクトや機能開発に使われます。理由は単純で、誰かが止めなければトイルは全員の時間の100%まで膨らむからです。
50%は目標ではなく上限として扱ってください。成熟したサービスを運用するチームは、それよりずっと低いところにいます。四半期にわたってこれを超えているなら、それは SRE ではなく、運用キューを回しているだけです。
始め方はシンプルです。2週間、すべてのチケットとページを「トイル」か「プロジェクト」にタグ付けします。そのうえでトイルを作業時間順に並べます。上位3つが自動化のバックログになります。
ブレームレス・ポストモーテムは何を変えるのか
障害が起きたとき、ポストモーテムが問うのは「誰がやったか」ではなく、「システムのどこが、その人にそのミスをさせてしまったか」です。非難は人に情報を隠すことを教えます。ブレームレスなレビューは、人に情報を書き出すことを教えます。
役立つポストモーテムは短く、4つの要素で構成されます。時系列、寄与した要因、うまくいったこと、担当者と期限を持つアクションアイテムです。担当者のいないアクションアイテムは、ただの願望です。
価値の大半はフォローアップから生まれます。未完了のアクションアイテムは毎月見直しましょう。同じ原因が6か月以内に2回出てきたら、文書の内容に関係なく、最初のポストモーテムは失敗していたことになります。
SRE チームに最初に必要なツール
多くは要りません。まずはシグナルから始め、その後にオンコールと自動化を加えてください。
メトリクスとダッシュボード: SLI を計算できる程度で十分です。Grafana と Prometheus はよく使われるオープンソースの組み合わせで、Datadog と New Relic はホスト型の選択肢です。
SLO に紐づくアラート: 1台のホストがスパイクしたときではなく、バジェットが急速に減っているときに通知します。ページは少なく、質の良いものにします。
機能フラグと段階的ロールアウト: 大まかに言えば、多くの障害は変更の後に起きるので、変更を元に戻せるようにすることが最も安上がりな信頼性向上です。LaunchDarkly や Statsig がこれを支えます。
ページごとの手順書（ランブック）: アラートに手順書がないなら、手順書を書くか、アラートを削除してください。
購入と構築は、この順序で検討してください。SLO のないままツールを買ったチームは、何のための数字かわからない、美しいダッシュボードを手に入れるだけです。
慣れないコードを読む作業は SRE のどこに入るのか
これは求人票に書かれないことです。障害対応中の SRE は、自分が書いていないサービスを、数か月開いていないリポジトリで理解しなければならないことがよくあります。問いはたいてい抽象的ではありません。「このリトライループはどこにあり、タイムアウト時に何をするのか」という具体的なものです。
これまでにも同じことをしたはずです。grep し、blame し、最後にそのファイルを触った人にメッセージを送る。80K 行のリポジトリなら、それで何とかなります。しかし、6チームが所有する12のサービスでは、障害対応の最初の20分が消え、その分がバジェットを削ります。
ここで、自分のリポジトリについて質問に答えてくれるコード検索ツールが役立ちます。例えば、あるサービスがタイムアウトをどこで設定していて、どの呼び出し元がそれに依存しているかを尋ねられます。障害そのものを直してくれるわけではありません。行動に移る前にコードを読むのに使う時間を短くしてくれます。そして、その時間は測定できます。
SRE は自分のチームには過剰か、どう始めるか
サービスが1つで、エンジニアが数人、ユーザーが時々の不具合を許容してくれるなら、専任の SRE チームは不要です。必要なのは、SLO、適切なアラート、そしてページの責任者です。
次のどれかが当てはまったら検討してください。障害で実際の売上が失われている、オンコールでメンバーが燃え尽きている、場当たり的な運用依頼で開発が遅れている。多くの企業は、1〜2人のエンジニアを非常勤の SRE にすることから始め、どうなるかを見ています。
よくある失敗は、運用チームの名前を「SRE」に変えただけで、働き方を変えないことです。チームが相変わらずチケットを抱え、手動デプロイを続け、エラーバジェットもないなら、変わったのは肩書きだけです。
来週からどう始めるか
組織変更は必要ありません。最も痛みの大きいユーザー向けサービスを1つ選び、次の5つをしてください。
そのサービスの SLI と SLO を1つずつ書きます。シンプルに保ちましょう。
エラーバジェットを計算し、チーム全員が見られるダッシュボードに置きます。
2週間トイルを記録し、自動化する最上位の項目を選びます。
次の障害でブレームレス・ポストモーテムを行い、担当者付きのアクションアイテムを作ります。
バジェットがゼロになったときにどうするかを、文書で合意します。
1か月後、チームがリリースするかどうかで議論する時間が減り、数字が何を示しているかを話す時間が増えていれば、うまくいっています。SLO が緩すぎてバジェットがまったく動かないなら、目標を厳しくしてください。