SRE とは何か – 従来のエンジニア職種との違いから考える

SRE という言葉を聞く機会は増えました。Site Reliability Engineering。日本語では、サイト信頼性エンジニアリングと訳されることが多い言葉です。

ただ、この言葉は少し扱いが難しいです。Kubernetes を触っているから SRE。Prometheus を入れているから SRE。Terraform を書いているから SRE。障害対応をしているから SRE。そういう説明も、まったく外れているわけではありません。

しかし、それだけでは SRE の中心には届いていないように思います。SRE は特定のツール名でも、単なる役職名でもありません。

私は SRE を、サービスの信頼性を、運用担当者の努力や勘ではなく、設計、計測、自動化、ソフトウェアによって扱う考え方だと捉えています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 は、各技術領域を否定するのではなく、それらをサービス信頼性という上位概念に接続する役割です。

Toil を減らすという感覚

SRE で重要な言葉に Toil があります。Toil とは、手作業で、反復的で、自動化可能で、長期的な価値を生みにくい作業です。

毎回手でログインして確認する。毎回同じコマンドを打つ。毎回同じ手順で再起動する。毎回同じ形式のレポートを作る。毎回同じチケットを処理する。こういう作業は、放置すると運用を圧迫します。

厄介なのは、Toil は一見すると「仕事をしている感」があることです。忙しい。対応している。手を動かしている。何かを処理している。しかし、それが構造的な改善につながっていないなら、システムは良くなっていません。

SRE は、こうした作業をできるだけ減らそうとします。手作業を自動化する。属人化を減らす。人間の判断が必要な箇所を明確にする。機械でできることは機械に寄せる。仕組みで防げるものは仕組みで防ぐ。

SRE はツール名ではない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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