SRE とは何か – SLI / SLO、エラーバジェット、トイルから理解する

SRE、Site Reliability Engineering とは、サービスの信頼性をソフトウェアエンジニアリングによって扱う考え方と実践体系です。Google は、SRE を「ソフトウェアエンジニアに運用チームを設計させたときに生まれるもの」と説明しています。

SRE は、Kubernetes、Prometheus、Terraform などのツールを使う人の呼び名ではありません。サービスの正常性を SLI で測り、SLO とエラーバジェットで信頼性と変更速度の基準を作り、トイルを減らすためにソフトウェアを実装することが中心です。

障害対応やオンコールも SRE の仕事に含まれます。しかし、人間が同じ運用作業を抱え続けることを前提にはしません。運用から得た知識を、設計、自動化、監視、復旧機構へ戻し、サービスと運用の両方を改善します。

運用はなぜ苦しくなるのか

従来の運用では、問題が起きるたびに人間の作業が増えていきます。障害が起きる。手順書を増やす。チェック項目を増やす。監視項目を増やす。会議を増やす。報告を増やす。承認を増やす。

一見すると、改善しているように見えます。しかし、実際にはシステムの信頼性が高まっているのではなく、人間の負荷が増えているだけの場合があります。

これは危険です。運用の安定性が「人間が頑張れること」を前提にしてしまうからです。担当者が覚えている。担当者が気づく。担当者が夜中に対応する。担当者が過去の経緯を知っている。担当者が空気を読んで止める。このような状態は、表面上は回っていても、構造としては脆いです。

SRE は、この状態に対する一つの答えだと思います。

SRE は運用をソフトウェアの問題として扱う

SRE を説明するときによく使われる考え方に、運用をソフトウェアの問題として扱う、というものがあります。これは非常に重要です。

運用上の問題を、単に人間の作業として処理するのではなく、ソフトウェアや仕組みによって解決できる問題として捉える。ここに SRE の感覚があります。

• 毎回同じ確認をしているなら、それは自動化できないのか。
• 毎回同じ復旧作業をしているなら、それは手順ではなくコードにできないのか。
• 毎回同じ種類の障害が起きるなら、そもそも設計で吸収できないのか。
• 毎回同じ判断で悩むなら、判断基準を定義できないのか。

SRE は、運用作業そのものを否定しているわけではありません。しかし、人間が反復作業を抱え続ける状態を、健全な運用とは見なしません。

信頼性は気合いではなく設計対象である

SRE の本質は、信頼性を設計可能なものとして扱う点にあると思います。

可用性、レイテンシ、エラー率、処理性能、キャパシティ、復旧時間、変更の安全性、監視可能性、障害時の切り分けやすさ。これらは、なんとなく頑張って守るものではありません。本来は、定義し、測定し、改善する対象です。

ここで重要になるのが、SLI や SLO という考え方です。SLI は、サービスの状態を表す指標です。たとえば、リクエスト成功率、応答時間、エラー率、名前解決成功率などです。SLO は、その指標に対する目標です。たとえば、月間のリクエスト成功率を 99.9% 以上にする、というような形です。

重要なのは、SRE が「絶対に落とさない」ことを目指す思想ではないという点です。どの程度の信頼性が必要なのか。どこまでの失敗を許容するのか。その範囲でどれだけ変更速度を維持するのか。ここを考える思想です。

100% の可用性を目指すと、変更できなくなります。変更できなければ、改善もできません。改善できなければ、長期的にはシステムの健全性が失われます。信頼性とは、高ければ高いほど良い、という単純なものではありません。

エラーバジェットで信頼性と変更速度をつなぐ

エラーバジェットは、SLO が許容している失敗量です。たとえば、月間成功率の SLO を 99.9% とした場合、残りの 0.1% が許容できる失敗の予算になります。

用語	役割	例
SLI	実際のサービス状態を測る指標	有効なリクエストの成功率、応答時間
SLO	SLI に対して達成したい目標	30 日間の成功率を 99.9% 以上にする
エラーバジェット	SLO の範囲内で許容できる失敗量	30 日間で 0.1% の失敗を許容する
SLA	顧客との契約や補償を含む対外的な合意	月間稼働率を下回った場合の返金条件

エラーバジェットに余裕があるなら、段階的なリリースや実験に一定のリスクを取れます。消費が速い、または使い切った場合は、機能追加より信頼性改善へ比重を移す判断ができます。

重要なのは、障害を罰するための数字にしないことです。開発と運用が同じ SLO とエラーバジェットを使い、「変更をどこまで進めるか」「どの改善を優先するか」を判断する共通基準にします。

また、SLO は監視できるものを適当に目標にするのではありません。ユーザーがサービスを利用できたかを表す SLI を選び、事業上必要な水準から SLO を決めます。CPU 使用率が低いことと、ユーザーのリクエストが成功することは同じではありません。

SRE と従来のエンジニア職種の違い

SRE を理解しにくい理由の一つは、既存のエンジニア職種と重なって見えることです。サーバーエンジニア、ネットワークエンジニア、インフラエンジニア、運用エンジニア、クラウドエンジニア、DevOps エンジニア、Platform Engineer。SRE は、これらと完全に別の存在ではありません。むしろ、かなり重なります。

ただし、見ている対象が少し違います。従来のエンジニアは、多くの場合、担当する技術領域を軸にしています。一方で、SRE の中心にあるのは、サービスの信頼性をどう定義し、どう測定し、どう維持し、どう改善するかです。

種別	中心にあるもの	主な問い
サーバーエンジニア	OS、ミドルウェア、サーバー構成	このサーバーは正しく動いているか
ネットワークエンジニア	通信、経路、接続性	通信は正しく流れているか
インフラエンジニア	基盤全体	システムを動かす土台は整っているか
運用エンジニア	監視、障害対応、定常作業	安定して運用できているか
クラウドエンジニア	クラウドサービス	クラウド上で適切に構成できているか
DevOps エンジニア	開発と運用の接続	変更を継続的に届けられるか
Platform Engineer	共通基盤、開発者体験	開発者が安全かつ効率的に使える基盤か
SRE	サービス信頼性	サービスは信頼できる状態か、それをどう測り改善するか

SRE は「何の技術を担当しているか」よりも、サービスが信頼できる状態であり続けるために、技術をどう使うかを見ています。

サーバーエンジニアとの違い

サーバーエンジニアは、OS、ミドルウェア、仮想化基盤、サーバー設定などを扱います。これは SRE にとっても重要です。

しかし、SRE はサーバーそのものを正常に動かすことだけを目的にしません。サーバーが生きていることと、サービスが正常であることは同じではないからです。

CPU が正常で、メモリも余裕があり、プロセスも起動していて、ディスクも空いている。それでも、ユーザーから見てサービスが使えないなら、それは信頼性の問題です。SRE は、サーバー単体の正常性ではなく、サービスとしての正常性を見ます。

ネットワークエンジニアとの違い

ネットワークエンジニアは、ルーティング、スイッチング、Firewall、Load Balancer、BGP、OSPF、VRF、冗長化などを扱います。ネットワークは、信頼性の根幹です。

ただし、SRE の観点では、ネットワーク構成そのものよりも、そのネットワーク障害がサービスにどう影響するか、どの経路断を許容できるか、どこで検知できるか、どの程度で復旧できるか、利用者影響をどう小さくするかが重要になります。

ネットワークエンジニアは通信基盤そのものを深く見る。SRE は、その通信基盤を含めてサービス信頼性への影響を見る。ここが違います。

運用エンジニアとの違い

SRE が最も誤解されやすいのは、運用エンジニアとの関係です。SRE は運用をします。障害対応もします。監視も見ます。オンコールも担当することがあります。なので、外から見ると運用エンジニアに見えます。

しかし、決定的に違うのは、SRE が運用作業を減らすこと自体を仕事にする点です。手順書通りに対応する、アラートに反応する、定常作業を処理する、障害報告を書く。それだけで終わらせない。

• その作業はなぜ人間がやっているのか。
• 自動化できないのか。
• そもそもその障害が起きない設計にできないのか。
• アラートは本当に人間を起こす価値があるのか。
• 同じ対応を繰り返していないか。

SRE は運用を担当するだけではなく、運用そのものを改善対象として見るのです。

DevOps や Platform Engineering との違い

DevOps と SRE はかなり近いです。DevOps は、開発と運用の分断をなくし、継続的に価値を届けるための文化や考え方です。SRE は、その中でも特に信頼性に焦点を当てた実践体系だと考えると分かりやすいです。

乱暴に言えば、DevOps は文化、組織、流れの話です。SRE は、信頼性を扱うための具体的な工学実践です。DevOps が「開発と運用を分断しない」と言うなら、SRE は「では、信頼性をどう測るのか。どこまで失敗を許容するのか。変更を止める基準は何か」と問います。

Platform Engineering とも重なります。Platform Engineering は、開発者が安全かつ効率的にサービスを作れるように、共通基盤や内部プラットフォームを整備する役割です。SRE は、サービスが信頼できる状態を維持することに重心があります。

良いプラットフォームは信頼性を高めます。良い SRE は、開発者が安全に変更できる仕組みを作ります。そのため現実にはかなり重なりますが、Platform Engineering は開発者体験に寄りやすく、SRE はサービス信頼性に寄りやすい。この違いで捉えると整理しやすいです。

SRE は責任範囲ではなく抽象度で見る

SRE を理解するうえで重要なのは、責任範囲だけで見ないことです。SRE がネットワークを触ることもあります。サーバーを見ることもあります。Kubernetes を見ることもあります。アプリケーションログを見ることもあります。

すると、既存職種との違いが分かりにくくなります。違いは、触る対象ではなく、見ている抽象度にあります。

ネットワークエンジニアは、経路や冗長性を深く見ます。SRE は、その経路障害がサービスの SLO にどう影響するかを見ます。サーバーエンジニアは、OS やミドルウェアの状態を深く見ます。SRE は、その状態がユーザー体験や可用性にどう影響するかを見ます。

つまり SRE は、各技術領域を否定するのではなく、それらをサービス信頼性という上位概念に接続する役割です。

トイルを減らし、エンジニアリングへ時間を戻す

SRE でいうトイルは、単に面倒な仕事ではありません。Google SRE は、手作業で、反復的で、自動化可能で、戦術的で、長期的な価値を生みにくく、サービスの成長に比例して増える運用作業として説明しています。

• 毎回同じ手順でアカウントを作成する
• 同じアラートに対して同じ確認と再起動を行う
• 複数画面から数値を転記して定例レポートを作る
• リリースのたびに同じチェックを人手で繰り返す
• 負荷の増加に合わせて同じ作業件数だけが増える

すべての手作業がトイルとは限りません。初めての障害を調査して構造を理解すること、設計判断を行うこと、未知の問題に対する仕組みを作ることは、反復的な作業とは異なります。

Google は、SRE チームの運用作業に 50% の上限を設け、残りを開発と改善へ使う考え方を示しています。この数字をすべての組織へそのまま適用する必要はありませんが、運用負荷を測らず、改善時間を保護しなければ、SRE という名前でも従来運用へ戻ることを示しています。

トイル削減の目的は人を減らすことではありません。反復作業から時間を戻し、障害を起こしにくい設計、復旧の自動化、観測可能性、キャパシティ、変更の安全性へ投資することです。

SRE はツール名ではない

SRE を語るとき、ツールの話に寄りすぎることがあります。Kubernetes、Prometheus、Grafana、Terraform、Ansible、Argo CD、Datadog、PagerDuty。これらは確かに SRE と相性の良いツールです。

しかし、ツールを導入しただけでは SRE にはなりません。Prometheus を入れていても、何を見るべきか決まっていなければ、ただメトリクスが溜まっているだけです。Grafana のダッシュボードがあっても、判断基準がなければ、きれいな画面があるだけです。

重要なのは、ツールではなく問いです。何を正常とするのか。何を異常とするのか。どこまで自動化するのか。どこから人間が判断するのか。どの障害を許容し、どの障害を許容しないのか。変更速度と安定性をどう両立するのか。

全部を守る、は設計ではない

SRE 的に考えると、すべてのシステムを同じ重要度で守る必要はありません。むしろ、全部を同じように守ろうとすることは、設計として雑です。

公開している Web サイト、DNS、認証基盤、GitLab、検証用アプリケーションでは重要度が違います。公開サイトはある程度安定していてほしい。DNS は名前解決に関わるので重要度が高い。認証基盤が落ちると複数のサービスに影響する。一方で、検証用アプリケーションは壊れてもよい場合があります。

これは企業システムでも同じです。すべてを最重要扱いにすると、何も判断できなくなります。すべてを高可用にしようとすると、コストも複雑性も増えます。すべてに厳密な運用手順を求めると、変更速度が落ちます。

だからこそ、何を守るのかを決める必要があります。そして、何を守らないのかも決める必要があります。この「守らないものを決める」感覚は、かなり重要です。

SRE チームとして成立する条件

SRE という職種名があっても、チームが次の条件を持たなければ、従来の運用チームから変わりにくくなります。

条件	確認すること
サービス所有者との合意	何を SLI とし、どの SLO を守るかを共同で決めているか
エラーバジェットの意思決定	消費状況がリリース速度や改善優先度へ接続されているか
変更する権限	監視するだけでなく、アプリケーションや基盤を改善できるか
運用負荷の上限	オンコール、チケット、手作業が改善時間を食い潰していないか
開発能力	反復作業を置き換えるソフトウェアと仕組みを実装できるか
障害からの学習	責任追及ではなく、再発防止と検知・復旧改善へつながるか
担当範囲の選択	すべてを同じ重要度で守らず、信頼性投資の境界を決めているか

特に重要なのは、SRE がサービスを改善する権限を持つことです。アラートを受け、手順書を実行し、報告書を書くことしか許されないなら、問題の原因をソフトウェアや設計へ戻せません。

日本で SRE が曖昧になりやすい理由

日本の現場では、SRE という言葉が少し曖昧に使われがちです。インフラエンジニアの新しい呼び名として使われることもあります。クラウド運用担当のような意味で使われることもあります。監視や障害対応をする人のように扱われることもあります。

もちろん、それらは SRE と無関係ではありません。しかし、それだけでは SRE の本質ではありません。SRE を単なる役職名や採用キーワードとして扱うと、結局は従来の運用に新しい名前をつけただけになります。

本来問うべきなのは、その組織は信頼性を定義しているのか、その信頼性を測定しているのか、手作業を減らす仕組みがあるのか、障害から学習する仕組みがあるのか、変更速度と安定性のバランスを設計しているのか、という点です。

SRE とは信頼性に輪郭を与えること

最終的に、SRE とは何か。私は、SRE とは信頼性に輪郭を与えることだと思います。

信頼性という言葉は、放っておくと曖昧です。安定している。落ちない。速い。安全。ちゃんとしている。問題がない。こうした言葉は便利ですが、そのままでは設計できません。

SRE は、それを具体化します。何が正常か。何が異常か。どの程度なら許容できるか。何を測るか。どこを自動化するか。どこで人間が判断するか。どの失敗から学ぶか。どの複雑性を受け入れ、どの複雑性を捨てるか。

そうやって、曖昧な「安定運用」に輪郭を与える。その輪郭があるから、設計できる。測定できる。改善できる。自動化できる。判断できる。

SRE とは、運用を気合いから工学へ移すための考え方です。重要なのは、SRE という肩書きではありません。信頼性を、曖昧な願望ではなく、設計可能な対象として扱っているか。そこに SRE の本質があるのだと思います。

参考情報