クラウド・インフラエンジニアの浅野です。

普段、AWSを中心としたアーキテクチャ設計を行う中で、「信頼性」をどう定義し運用するかは常に課題です。
そこで、改めてSRE（Site Reliability Engineering）について深く理解したいと考え、書籍『SREの知識地図』を通して知識を整理しました。

■対象読者：

  • インフラ・アプリ開発に関わるエンジニア全般
  • 信頼性と開発速度のバランスに悩むPM・マネージャー
  • 「SRE」という言葉を最近よく聞くが、具体的に何かわからない方

■この記事で得られること

  • SREの重要キーワード（SLO/エラーバジェット/トイル）の実務的な要点
  • AWS環境にどう落とし込むか（CloudWatch / X-Ray / Synthetics など）
  • 「なんとなく」の運用から「数値」で判断する運用へ変えるための視点

そもそも、SREとは何か？

SRE（Site Reliability Engineering）は、その名の通り「信頼性」をエンジニアリングするアプローチです。2003年から2004年頃にGoogleで体系化されました。

SREの根底には、提唱者であるBen Treynor Sloss氏の考え方があります。その要旨は以下のようなものです。

「信頼性は、いかなる製品にとっても最も基本的な機能である」

どんなに素晴らしい機能を持つアプリでも、動かなければ価値はゼロです。ユーザーに使ってもらえません。
SREは、この「信頼性」を精神論や根性で守るのではなく、ソフトウェアエンジニアリングの力でコントロールするための実践手法です。

具体的には、以下の3つの視点で従来の運用と大きく異なります。

1. 信頼性を機能として定義する

従来の運用は「とにかく落ちないようにする」という曖昧な目標になりがちでした。

SREでは、「ユーザーにとって必要な信頼性はどの程度か？」を数値で定義します。
100%を盲目的に目指すのではなく、ビジネスへの影響とコストのバランスを踏まえて適切な目標値を設定し、戦略的な判断を行います。

2. 運用をソフトウェアの問題として解く

SREは、運用作業を「ソフトウェアの問題」として捉えます。

手動で行っていた作業をコード化・自動化し、システムが自律的に回復する仕組みを作ります。
「明日ラクをするために、今日コードを書く」のがSREの基本スタンスです。

3. 開発と運用の利害を調整する

開発は「変化（機能追加）」を求め、運用は「安定」を求めます。SREはこの対立を完全に消すのではなく、エラーバジェットという仕組みで利害を調整します。

「信頼性の予算内なら、いくらでも失敗（挑戦）していい」という共通ルールを設けることで、開発と運用が「ビジネス価値の最大化」という同じゴールに向かえるようにします。

エンジニアとして共感したSREの重要キーワード

SREには多くの概念がありますが、特に「これは実務で意識を変えるべきだ」と強く感じたポイントを厳選しました。

1. SLO / SLI と エラーバジェット

信頼性を「感覚」ではなく「数値」で管理するための重要な指標です。

  • SLI (Service Level Indicator)： 信頼性を測るための指標（何を測るか）。
  • SLO (Service Level Objective)： SLIに対して設定する目標値（どこまで守るか）。
  • エラーバジェット (Error Budget)： SLOに対する余裕（どれだけ失敗していいか）。

これらを実務に落とし込むと、以下のようになります。

【SLO設定のサンプル（具体例）】

  • 対象： 公開APIの可用性とレイテンシ
  • SLI（可用性）： ALBのリクエストのうち、5xx以外の割合（CloudWatchメトリクス HTTPCode_Target_2XX_Count / _5XX_Count から算出）
    • ※「5xx以外＝成功」と単純化しています。4xxはクライアント起因なら成功扱いが一般的ですが、認証フローなどUX影響が大きい場合は別指標で切り出します。
  • SLI（レイテンシ）： p99レスポンスタイム（TargetResponseTime p99）
    • 可用性だけでは「遅いが落ちない」状態を見逃すため、レイテンシSLOも併設するのが定石。
  • SLO (目標)： 直近30日間で 可用性 99.9% / p99 < 500ms
  • エラーバジェット (予算)： 可用性側で 0.1%
    • 30日換算で 約43分 の停止・エラー許容時間となります。

【AWSでの実装イメージ】

  • CloudWatchメトリクスフィルタ + Metric Math で「成功率」を算出
  • エラーバジェット消費率を CloudWatch Alarm で監視し、閾値超過で Slack 通知
  • 長期トレンドは CloudWatch Dashboard または Managed Grafana で可視化

【運用のイメージ】

「直近3日間で、すでに 30分 の予算を使ってしまった。残りは 13分 しかない」
「予算の消費スピードが早すぎるため、今週予定していたリスクの高い新機能リリースは凍結し、安定化タスクを優先しよう」

このように、エンジニアの感覚値ではなく、「改善するのか、追加開発するのか」を定量的な基準（残り時間と消費速度）で判断できるのが合理的だと感じました。

（※SLOの数値（例：99.9%）は業種や機能ごとに最適解が変わります。ビジネス影響とコストのトレードオフで決めることが重要です）

2. オブザーバビリティ

単なる死活監視ではなく、「システムがなぜその状態にあるのか」を外部出力（ログ、メトリクス、トレースなど）から推測できる能力のことです。

AWSでいえば、次の3点セットが起点になります。

  • メトリクス： CloudWatch Metrics / Container Insights
  • ログ： CloudWatch Logs（Logs Insights でクエリ）
  • トレース： AWS X-Ray（分散トレース）

さらに、合成監視で「ユーザー視点の可用性」を測るなら CloudWatch Synthetics、異常検知を自動化するなら DevOps Guru を組み合わせると実務的です。

3. ポストモーテム

障害発生後の事後検証です。
重要なのは、Blameless（非難なし） という文化を前提に、個人の責任追及ではなく、プロセスやシステムの欠陥に焦点を当てることです。

フォーマットの要点：

  • タイムライン： 検知〜収束までを分単位で整理
  • 影響範囲： 影響ユーザー数・エラーバジェット消費量
  • 根本原因： 5 Whys などで「人」ではなく「仕組み」まで掘り下げる
  • アクションアイテム： 各項目に 担当者・期限・チケットID をセット。やりっぱなし防止が命

「同じ障害を二度と起こさない」ための仕組み化が目的です。

4. トイル

私が最も共感し、同時に危機感を覚えたのがこの「トイル」という概念です。
これは「手作業で行われ、繰り返され、自動化が可能で、戦術的（長期的価値がない）であり、サービスが成長するにつれて作業量も比例して増える作業」のことです。

これらを可能な限り削減し、エンジニアリングの時間を作ることは、どの現場でも急務だと感じます。

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

SREを学ぶ過程で整理できたのが、これら3つの用語の違いです。混同されやすいので、比較表にまとめます。

観点 DevOps SRE プラットフォームエンジニアリング
本質 文化・哲学 方法論・職能 製品（内部プラットフォーム）
主眼 開発と運用の協働 信頼性のエンジニアリング 開発者体験（DX）の向上
成果物 組織文化・CI/CDパイプライン SLO / エラーバジェット / ポストモーテム IDP（Internal Developer Platform）
合言葉 "You build it, you run it" "Hope is not a strategy" "Self-service for developers"

ざっくり言えば、DevOps は方向性、SRE は信頼性の実装、プラットフォームエンジニアリングは開発者のための基盤提供。競合する概念ではなく、組織の成熟度に応じて重ね合わせるものだと理解しました。

これらを混同せず、今の組織に何が必要かを見極める視点が重要だと学びました。

私自身の経験と、これからのSREについて

過去の「SRE診断」と、当時の誤解

実は以前、ある企業様の案件で「SRE診断」を受けたことがあります。
正直に告白すると、その当時の私はSREの本質を全く理解できていませんでした。

むしろ、こう思っていたのです。
「内製で作った小さい社内システムに、そこまでの信頼性が本当に必要なのか？」
「すべてにおいてSREエンジニアやSREチームが必要というわけではないだろう」と。

ユーザーとしての実体験と、ビジネス視点

しかし、いちユーザーとしての体験を思い出すと、考えが変わります。
あるWebサービスが一時的に使えなかったとき、シンプルに「気分がよくない」と感じましたし、「これが繰り返し起きたら、もう使わず離れるだろうな」と直感しました。

つまり、信頼性の欠如は顧客離れに直結するのです。
インフラやアーキテクチャを考える立場になった今、改めて「信頼性はビジネスそのもの」だと痛感しています。

（2025年に発生した大規模障害の経験も、この考えをより強固にしました。詳しくは AWS大規模障害についての見解 に書いています。）

「抽象」から「数値」への転換

今回確信したのは、「抽象的に動くのはやめて、きちんと数字を明確に決めて判断すること」の重要性です。

「なんとなく重い気がする」「なるべく頑張る」といった精神論では、現場は疲弊し、正しい判断もできません。
SLOやエラーバジェットという「数字」を共通言語にし、役割を持って実施し、定期的に振り返る。
このサイクルこそが、SREの本質です。

最後に

果たして、これらすべてをきちんと導入して回せているチームが、日本にどれだけあるでしょうか。おそらく、SREを教科書通りにフル導入できている現場は、まだ少数派だと思います。

だからこそ、「ぜひやってみたい」と強く思いました。

まずはできるところから。そして、より深い理解を得るために、次はSREのバイブルとも言われる『Site Reliability Engineering（GoogleのSRE本）』を読もうと思います。

クラウド・インフラエンジニアとして、お客様のシステムに「信頼性」という価値を実装できるよう、学びを続けていきます。

書籍情報

今回の記事で紹介した書籍はこちらです。これからSREを学びたい方、実務で迷いがある方におすすめの一冊です。

『SREの知識地図——基礎知識から現場での実践まで』（Amazon）