2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ma_dash

SREとは？（定義/背景/業務/SLI・SLO解説/単価/なり方）

2
Posted at

この記事は、**Google流SRE（Site Reliability Engineering）**を軸に、
「SREって結局なに？」「DevOpsとどう違う？」「何をやる仕事？」「どうやって目指す？」までを一気通貫でまとめます。

目次

1. SREとは（定義）

SRE（Site Reliability Engineering）は、ざっくり言うと：

「本番運用を、気合いと人手ではなく “エンジニアリング（ソフトウェア/システム工学）” でスケールさせる」ための職務・マインドセット・手法のセット

Googleの文脈では、SREはよく次のように説明されます。

  • ソフトウェアとシステム工学を組み合わせ
  • 大規模・分散・耐障害なシステムを構築・運用
  • 信頼性・可用性・改善速度を両立させる

そして有名な言い回しとして：

「SREとは、“運用チームをソフトウェアエンジニアに設計させたら” 何が起きるか」

…という思想が、全体の核になっています。

2. SREが生まれた背景

インターネットサービスが急成長すると、従来型の“人手運用”はこうなります。

  • サービス規模 ↑ → 運用負荷 ↑（比例で増える）
  • 障害対応・手作業が増え、改善が追いつかない
  • いつのまにか「運用するために運用している」状態に…

そこでSREは、運用にありがちな反復作業を**Toil（トイル）**として扱い、

  • 自動化（スクリプト化 / IaC / パイプライン）
  • 設計改善（冗長化、ボトルネック解消、フェイルセーフ化）
  • 仕組み化（監視設計、障害対応の標準化、ポストモーテム）

のような「恒久的にラクになる投資」へ時間を寄せます。

3. いつ・どこで・誰が始めたのか

一般的に、

  • 2003年ごろ
  • Google
  • **Ben Treynor Sloss（Benjamin Treynor Sloss）**が “SRE” という呼称を作った

…という説明がよく引用されます。

また、Google Cloud側の資料でもSREはGoogle由来の運用モデルとして紹介され続けており、
「Google発の手法が、業界へ広がっていった」流れで理解するとスッキリします。

4. SREの業務内容（代表例）

SREの仕事は会社によって差がありますが、Google流の「型」で見ると、だいたい以下が柱になります。

4.1 信頼性目標（SLO）を決め、計測できるようにする

  • 何を「良い状態」とするかを数値化（例：成功率、レイテンシ、可用性）
  • “雰囲気”ではなく “合意できる数字” を作る

4.2 監視・アラート設計（ユーザー体験に効く指標中心）

  • ログ/メトリクス/トレースの整備（Observability）
  • アラートは「鳴りすぎ」も「鳴らなさすぎ」も事故るので設計が超重要

4.3 障害対応（オンコール）と再発防止

  • まず復旧（MTTR短縮）
  • その後、ブレームレス・ポストモーテムで再発防止へ

4.4 Toil削減（自動化・仕組み化）

  • Runbook整備、手順の自動化、運用のコード化
  • “毎週の儀式”を消していく

4.5 変更管理・キャパシティ・パフォーマンス

  • 安全に速く変える（リリースのガードレール作り）
  • 負荷/性能/容量の見通し（キャパシティプランニング）

5. SREの代表的な考え方（SLI/SLOなど）

ここがSREの「共通言語」になりやすい部分です。

5.1 SLI / SLO / SLA

  • SLI（Service Level Indicator）：サービス品質の「指標」
    例：成功率、レイテンシ、可用性、エラー率 など

  • SLO（Service Level Objective）：SLIに対する「目標値」
    例：過去30日で成功率 99.9%

  • SLA（Service Level Agreement）：顧客との「契約」
    違反時の返金など、ビジネスの責務に直結しやすい

実務のコツ：**SLAは“外向き（顧客）”、SLOは“内向き（運用）”**で握ることが多いです。

5.2 エラーバジェット（Error Budget）

  • ざっくり 「1 − SLO」
  • 例：SLO 99.9%なら、0.1%は「失敗してよい枠」

これが強いのは、開発と運用の対立を、

  • 「安全第一で止めるべき」
  • 「新機能を出して攻めるべき」

という感情論ではなく、“残りの失敗枠”という共通言語で意思決定しやすくする点です。

5.3 Toil（トイル）

Toilは、典型的にこういう性質を持つ作業です。

  • 手作業
  • 反復的
  • 自動化可能
  • 戦術的（場当たりになりやすい）
  • 永続的価値が薄い

SREはToilを減らし、空いた時間で改善を進めるのが基本戦略です。

5.4 ブレームレス・ポストモーテム

障害後に「誰のせい」をやると、現場は保身に寄ります。
SREでは、個人を責めず、学習して再発防止へつなげる文化が重要視されます。

6. 他職種との違い（SRE vs DevOps 等）

6.1 まず結論：SREとDevOpsは“対立概念”ではない

  • DevOps：文化・哲学・組織改善（協業、サイロ解消、継続的デリバリーなど）を含む広い概念になりがち
  • SRE：その理想を、SLO/計測/エラーバジェット/ポストモーテム/Toil削減などで「運用モデルとして実装」しやすい

6.2 雑に比較するとこんな感じ

観点 DevOps SRE
性格 文化・協業・プラクティス全般 信頼性に焦点を当てた運用モデル
指標 DORAメトリクス等も多い SLI/SLO/エラーバジェットが中心になりやすい
仕事の見え方 開発～運用の境界を溶かす “信頼性”をエンジニアリングで担保する

7. 必要なスキル

SREは「運用ができればOK」ではなく、ソフトウェアエンジニアリング寄りの力が効きやすいです。

  • プログラミング（自動化、ツール開発、テスト、性能改善）
  • Linux/OS基礎（プロセス、メモリ、ファイル、権限、パフォーマンス）
  • ネットワーク基礎（TCP/IP、DNS、LB、TLS、疎通/遅延/輻輳）
  • 分散システムの勘所（障害は起きる前提、部分故障、リトライ地獄など）
  • Observability（ログ/メトリクス/トレース）
  • 障害対応（切り分け→復旧→再発防止）
  • IaC / CI/CD / クラウド（Terraform等が案件要件で出やすい）

8. なる方法（現実的ルート）

入口はだいたい2つです。

8.1 SWE（開発）→ SRE

  • 運用課題をコードで潰せるのが強い
  • 変更・リリースに強い

8.2 インフラ/運用 → SRE

  • 本番の勘所を持っているのが強い
  • そこにソフトウェア工学（自動化/設計/テスト）を載せていく

8.3 最短で“それっぽく”なる実務ステップ（例）

  1. 対象サービスを決める（自社でも個人でもOK）
  2. SLIを定義（成功率/レイテンシ等）
  3. SLOを設定（例：30日 99.9%）
  4. アラートをSLO基準で設計
  5. Toilを棚卸し → 自動化（Runbook→スクリプト→IaC）
  6. 障害対応の練習 → ポストモーテム雛形で再発防止

9. フリーランス単価（日本の目安）

※単価は「掲載案件」「集計方法」「景気」で変動します。
※ここでの「月額」はざっくり 週5（140〜180h程度）換算を想定。

9.1 職種全体の平均として見えるライン

  • 月90〜110万円台が見えることがある（平均の出し方や時期で差が出る）

9.2 経験年数（1年/3年/5年以上）で刻む単価イメージ

「SREの実務経験年数」で刻むと、相場感はだいたいこんなイメージになります（※サイト差・案件差あり）。

経験年数の目安 よく任される領域（例） 月額単価の目安
1年 監視/アラート整備、運用改善、IaC補助、Toil削減の一部 40〜70万円
3年 SREとして自走、SLO/監視設計、Terraform/K8s、改善ループ主導 70〜100万円
5年以上 リード/テックリード、横断改善、オンコール体制設計、信頼性の設計責任 90〜130万円+

単価は、SREの経験年数だけでなく「クラウド（特にKubernetes/マネージド運用）」「IaC」「可観測性（ログ/メトリクス/トレース）」「障害対応経験」「リード経験」で上振れしやすいです。

10. SREのキャリアアップ（その後の選択肢）

SREは「運用担当の延長」ではなく、信頼性を軸に横断できる職種なので、経験を積むほど選択肢が増えます。

10.1 技術を深める（IC：Individual Contributor）ルート

  • Senior SRE → Staff/Principal のように、技術で影響範囲を広げる道
  • 例：信頼性アーキテクチャの設計、複数チームのSLO設計支援、全社的な障害対応プロセス改善 など

10.2 Platform Engineering（プラットフォーム）へスライド

  • SREの先でよくあるのが Platform Engineering（開発者体験/共通基盤/IDPなど）
  • 「信頼性の改善」を超えて、開発組織全体の生産性まで責任範囲を広げる動き

10.3 マネジメント（EM / SRE Manager）ルート

  • オンコール体制・採用・育成・ロードマップなど、組織づくり側へ
  • テックリード→マネージャー→部門長…の流れも現実的

10.4 コンサル/アーキテクト寄り（信頼性×事業）

  • SLO導入支援、Observability刷新、クラウド移行の信頼性設計、インシデント改善支援
  • 「現場で回した経験」が強い武器になりやすい領域

10.5 次のステップで評価されやすい実績の例

  • SLO導入で意思決定が変わった（リリース判断がデータで回るようになった）
  • アラート削減（ノイズ低減）・MTTR短縮
  • Toil削減（手作業を削って自動化に置き換えた）
  • ポストモーテム運用の定着（再発防止が回るようになった）

11. 向いている人・向いていない人

向いている人（傾向）

  • 仕組み化が好き（自動化、標準化、再発防止）
  • 数字で議論できる（SLO/エラーバジェット）
  • 障害対応でも冷静に切り分けできる（プレッシャー耐性）
  • “速度と安全”のトレードオフ設計ができる

向いていない人（傾向）

  • 手作業中心で満足しがち（Toilに飲まれやすい）
  • 100%を求めすぎて、現実的な合意が苦手
  • 障害/オンコールが強いストレスになる（組織次第で負荷が大きい）

12. メリット・デメリット

メリット

  • 信頼性を**言葉ではなく数値（SLI/SLO）**で扱える → 合意しやすい
  • エラーバジェットで、開発と運用の衝突を“共通言語”で調停しやすい
  • Toil削減で、運用がスケールしやすい

デメリット（落とし穴）

  • SLI/SLO設計が弱いと形骸化しやすい（測ってるけど意思決定に使えてない）
  • 体制が弱いとオンコール/障害対応で燃えやすい
  • “SREを置けば解決”ではなく、開発側との協業モデル設計が必要

用語まとめ

記事中に出てきた用語を、最後にサクッと振り返れるようにまとめます。

  • SRE（Site Reliability Engineering / 直訳：サイト信頼性エンジニアリング）
    本番運用をエンジニアリングでスケールさせ、信頼性を高める考え方・職種。

  • DevOps（Development + Operations / 直訳：開発と運用）
    開発と運用の壁をなくし、協業・継続的デリバリーを進める文化/考え方。

  • SLI（Service Level Indicator / 直訳：サービス水準指標）
    サービス品質を測る“指標”（例：成功率、レイテンシ、可用性、エラー率）。

  • SLO（Service Level Objective / 直訳：サービス水準目標）
    SLIに対する“目標値”（例：過去30日で成功率99.9%）。

  • SLA（Service Level Agreement / 直訳：サービス水準合意）
    顧客との“契約”（違反時の補償が発生することが多い）。

  • Error Budget（直訳：エラーバジェット / 許容失敗枠）
    「1 − SLO」で表せる“失敗してよい枠”。速度と信頼性の意思決定に使う。

  • Toil（直訳：骨の折れる単純作業、徒労）
    手作業・反復・自動化可能・永続価値が薄い作業。SREはこれを減らす。

  • Observability（直訳：可観測性）
    システム内部の状態を、ログ/メトリクス/トレース等で“観測して理解できる状態”にする考え方。

  • On-call（直訳：待機当番）
    障害時に呼び出され、復旧対応を行う当番体制。

  • MTTR（Mean Time To Recovery / 直訳：平均復旧時間）
    障害から復旧までにかかる平均時間。短いほど復旧が速い。

  • Blameless Postmortem（直訳：非難しない事後分析）
    個人を責めず、事実と学びに基づいて再発防止につなげる振り返り。

  • Runbook（直訳：運用手順書）
    障害対応や定型作業の手順をまとめたもの。自動化のベースにもなる。

  • IaC（Infrastructure as Code / 直訳：コードとしてのインフラ）
    インフラ構成をコードで管理し、再現性・変更容易性を高める手法。

  • CI/CD（Continuous Integration / Continuous Delivery(Deployment)
    直訳：継続的インテグレーション / 継続的デリバリー（デプロイ））
    ビルド・テスト・リリースを継続的に回し、変更を安全に速く届ける仕組み。

  • Kubernetes / K8s（略称：K8s）
    コンテナ運用のためのオーケストレーション基盤。SRE案件で要件になりやすい。

  • Terraform
    IaCツールの代表例。クラウドの構成管理でよく使われる。

  • Platform Engineering（直訳：プラットフォームエンジニアリング）
    共通基盤や開発者体験（DX）を整え、開発組織全体の生産性を上げる領域（SREからの発展先になりやすい）。

参考リンク

Google / Google Cloud（日本語）

Google SRE（日本語あり）

SREの起源・背景（読み物）

おわりに

SREは「運用担当」ではなく、信頼性をエンジニアリングで担保する役割です。
まずは SLI→SLO→アラート の最小セットを自分の環境で回してみると、一気に理解が進みます。

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?