SREとは？DevOps・プラットフォームエンジニアリングとの違いと始め方

SREとは、Site Reliability Engineering（サイト信頼性エンジニアリング）の略で、サービスの信頼性を「どこまで高めるか」を数値で決め、その目標を守るための運用をソフトウェアエンジニアリングの手法で進める考え方と、それを担う職種を指します。Googleが社内の運用のやり方として始め、書籍などで公開したことで広まりました。

名前が似たDevOpsやプラットフォームエンジニアリングとは、目的も成果物も違います。ここでは3つの違いを整理したうえで、SLO（サービスレベル目標）とエラーバジェットの計算を具体的な数字で確かめ、情シスや少人数のインフラチームが最初の1サービスで試す手順までをまとめます。

SREとは：信頼性を数字で決めて運用する考え方

「できるだけ落ちないようにする」という方針は、どこまでやれば十分かが決まらないため、改善と新しい変更のどちらを優先するかでいつも揉めます。SREはここに数字を持ち込みます。たとえば「社内ポータルは30日間でリクエストの99.9%が成功すればよい」と決めれば、残りの0.1%は失敗してもよい量、つまり使える予算になります。

もう1つの柱は、運用の手作業をエンジニアリングで減らすことです。障害対応や定型作業に使う時間に上限を設け、上限を超えそうなら自動化や設計の見直しに時間を回します。100%の信頼性は目指しません。利用者の回線や端末のほうが先に落ちるため、99.999%と99.99%の差は利用者にはほぼ伝わらない一方、そのための費用と変更の遅れは確実に増えるからです。

SRE・DevOps・プラットフォームエンジニアリングの違い

DevOpsとは、開発と運用の分断をなくし、変更を速く安全に届けるための文化や進め方の総称です。SREはそのDevOpsが目指すことを、数値の目標と役割分担で具体化した実践の1つとみなせます。プラットフォームエンジニアリングは、開発チームがそれぞれCI・監視・Kubernetesの設定まで抱え込む負担を減らすため、共通の基盤を社内向けの製品として作る取り組みです。

3つは競合するものではなく、重なりながら同時に進められます。たとえば、プラットフォームチームが用意したデプロイの仕組み（Argo CDによるGitOpsなど）の上で、各サービスのSLOをSREの考え方で管理する、という組み合わせです。少人数の情シスなら、3つを別のチームに分けるより、1つのチームが役割として持ち回るほうが現実的です。

SLI・SLO・SLAとエラーバジェット

SLI（サービスレベル指標）は「何を測るか」で、成功したリクエストの割合や、応答が300ミリ秒以内だったリクエストの割合のように、利用者の体験に近い数字を選びます。SLO（サービスレベル目標）は「SLIをどの期間でどこまで満たすか」、SLA（サービスレベル契約）は顧客との契約上の約束で、下回ると返金などが発生します。SLAを破る前に手を打てるよう、SLOはSLAより厳しめに置くのが普通です。

エラーバジェットは「1 − SLO」で求まる、失敗してよい量です。停止時間に換算すると目標の重さが実感できます。次の表は、30日（43,200分）と、月100万リクエストの場合の計算例です。

99.99%は月に4分強しか止められないので、手作業での再起動1回で予算を使い切ります。冗長化と自動復旧が前提の数字で、業務時間に使う社内システムならまず99.5%や99.9%から始めるのが妥当です。予算の使い方はあらかじめ決めておきます。残っている間は新しい機能や設定変更を進め、使い切ったら変更を止めて信頼性の改善を優先する、というルールにすると、「リリースしたい側」と「止めたくない側」の議論が意見ではなく残量の数字で決まるようになります。

アラートは、エラーの発生そのものではなく予算の減る速さ（燃焼率）で出します。燃焼率はエラー率を予算で割った値で、SLO 99.9%のサービスでエラー率が0.5%に上がれば燃焼率は5、そのままなら30日分の予算を6日で使い切ります。例として「1時間で月間予算の5%を使ったら通知」と決めるなら、30日＝720時間なので燃焼率36、SLO 99.9%ではエラー率3.6%が1時間続いたら鳴らす、という設定になります。

応答時間を平均値でSLIにすると、大半のリクエストが速ければ一部の利用者のひどい待ち時間が埋もれます。「1秒以内に返ったリクエストの割合」のように割合の形で測ると、エラーバジェットの計算にもそのまま使えます。また、SLOを100%に設定すると予算がゼロになり、どんな変更も許されなくなるので避けます。

SLIを実際に測る：アクセスログからの計算例

監視基盤がまだなくても、Webサーバーのアクセスログがあれば成功率は計算できます。nginxの標準のログ形式（combined）では、空白で区切った9番目の欄がステータスコードなので、500番台を失敗として数えます。

awk '{total++} $9 ~ /^5/ {err++} END {printf "requests=%d errors=%d success=%.3f%%\n", total, err, (total-err)*100/total}' /var/log/nginx/access.log

requests=2000 errors=7 success=99.650%

この例の99.65%は、SLOが99.9%なら不足、99.5%なら達成です。4xxを失敗に入れないのは、存在しないURLへのアクセスのように利用者側の誤りが大半だからですが、ログイン画面の401が急に増えたような場合は別のSLIとして見ます。応答時間を測るにはlog_formatに$request_timeを足す必要があり、継続的に測ってグラフにするなら、PrometheusとGrafanaでの監視のような仕組みに移すのが次の段階です。

トイルを減らし、ポストモーテムを書く

トイルとは、人が手で繰り返している運用作業のうち、仕組みにすれば人手が要らなくなり、利用者やサーバーが増えるほど比例して増えていくものを指します。「来月も同じ手順を同じように繰り返すなら、それはトイル」と考えると見分けやすく、情シスなら「月末に退職者のアカウントをCSVと突き合わせて手で止める」「ディスクが埋まるたびにログを手で消す」が典型です。まず2週間、作業記録にトイルの印を付けて時間を集計し、「回数×1回あたりの時間」が大きいものから自動化します。

障害のあとは、個人の責任を問わない形式（ブレームレス）でポストモーテムを書きます。「誰が間違えたか」を書くと次から事実が報告されなくなるので、「なぜその操作が可能だったか」「なぜ気づくのが遅れたか」という仕組みの側を問います。次のひな形は、書く項目を固定して毎回の負担を減らすためのものです。

## 概要（1〜2文）
## 影響：期間 / 影響を受けた利用者 / 消費したエラーバジェット（例：月間の35%）
## タイムライン：検知・判断・復旧の時刻と、そのとき見ていた情報
## 原因：直接の原因と、それを許した仕組み上の要因
## うまくいったこと・運がよかったこと
## 再発防止策：内容 / 担当 / 期限（チケット番号）

SLOの達成率やポストモーテムの件数を、個人やチームの評価に使わないでください。評価に結びついた数字は、目標を緩めたり障害を小さく報告したりする方向に歪みます。数字はサービスの状態を知るためのもので、人を比べるためのものではない、と最初に合意しておきます。

SREを最初の1サービスで始める手順

専任のSREチームを作る必要はありません。既存の運用担当が、SLOとポストモーテムの2つだけを先に取り入れるのが、少人数のチームには一番負担の少ない始め方です。

1. 利用者が多く、止まると困る人がはっきりしているサービスを1つ選ぶ（例：社内ポータル、VPN、勤怠システム）
2. 利用者にとっての「うまくいった」をSLIにする（例：ログインの成功率、1秒以内に表示されたページの割合）
3. 過去4週間のログで現状の値を測り、SLOは現状よりわずかに低い値から始める
4. 燃焼率のアラートを1つだけ作り、それ以外の通知は見直す
5. 月に1回、達成状況とトイルの時間を振り返り、エラーバジェットの残りを改善と変更のどちらに使うか決める
6. 障害のたびにポストモーテムを書き、再発防止策を期限つきで追う

最初のSLOを現状より高く置くと、初月から予算を使い切って「変更禁止」が続き、仕組みそのものが嫌われます。逆に、利用者が数人で、止まっても翌日の対応で困らないサービスにSLOを作る必要はありません。死活監視で十分なものと、SLOで管理する価値があるものを分けて、手間をかける対象を絞ります。

よくある質問

SREとDevOpsの違いは何ですか？

DevOpsは、開発と運用が協力して変更を速く安全に届けるための文化や進め方の総称です。SREはその実践の1つで、信頼性の目標をSLOとして数値で決め、エラーバジェットで変更の速さとのバランスを取る、という具体的なやり方と役割を持ちます。DevOpsが方向性、SREが手段という関係です。

SREとインフラエンジニアの違いは何ですか？

インフラエンジニアはサーバーやネットワークの構築と運用が中心で、SREはそれに加えて、SLOで信頼性の目標を決め、運用の手作業をコードで自動化することに責任を持ちます。実務では重なる部分が多く、インフラエンジニアがSLOやポストモーテムを取り入れることで、SREの役割を担うようになる例もあります。

SREエンジニアに向いている人は？

同じ作業を2回やると自動化したくなる人、障害の原因を個人ではなく仕組みに求められる人、数字で優先順位を説明するのが苦にならない人に向いています。障害対応の当番（オンコール）を担う職場もあるため、夜間や休日の対応を含めた働き方を事前に確かめておくことも欠かせません。

まとめ

SREの出発点は、信頼性の目標を「30日間で99.9%」のような数字にし、1 − SLOを使ってよい予算として扱うことです。DevOpsは方向性、プラットフォームエンジニアリングは共通基盤づくりで、3つは同時に進められます。まずは1つのサービスでアクセスログから成功率を測り、SLOとポストモーテムだけを運用に足すところから始めてください。

次に読む

• ITILとは？情シスに必要なプラクティスだけを取り入れる方法：インシデント管理や問題管理とSREの関係
• Gitブランチ戦略の選び方：変更を速く安全に届けるための開発側の運用ルール