SRE

一言でいうと

サービスの信頼性を、人手の運用ではなくソフトウェアエンジニアリングで担保する職種です。

この職種の出自と登場時期

SRE は Google で生まれました。2003年に Google へ入社した Benjamin Treynor Sloss が、7人のエンジニアからなる Production Team の責任者を務めたところが起点です。本人は SRE を「ソフトウェアエンジニアに運用チームを設計させたら何が起きるか」と表現しています（Google SRE 本 Chapter 1）。

同じ本には、SRE の働き方を決める2つのルールが書かれています。ひとつは、チケット対応・オンコール・手作業といった運用業務の合計を全体の50%までに抑えること。もうひとつは、残りの50%を開発に充てることです。あわせて「あらゆるシステムにとって可用性100%は誤った目標である」という前提から、目標可用性の裏返しをエラーバジェットとして扱い、その予算の範囲でリリース速度を上げる考え方が示されています。

国内では2015年11月に、メルカリがインフラチームを SRE チームへ改称したことを技術ブログで公表しています。当時5名の体制で、API サーバーとミドルウェアの可用性、パフォーマンス改善、ログ基盤、プロビジョニングまでを担当範囲としていました。日本語の書籍としては、2017年8月にオライリー・ジャパンから『SRE サイトリライアビリティエンジニアリング』の邦訳が刊行されています。海外での誕生から国内の職種名としての定着まで、10年以上の時差がある職種です。

ミッション

SRE が責任を持つのは、サービスが「落ちないこと」ではなく「合意した水準で動き続けること」です。何%の可用性を目指すのかを事業側と決め、その水準を満たしているかを計測し、外れたときに原因を潰します。

裏返せば、目標を上回っている間はリリースを止めない判断も SRE の仕事です。信頼性を上げる活動と、開発速度を上げる活動は本来トレードオフの関係にあり、その配分をエラーバジェットという共通の判断基準で運用するのが SRE のミッションだと考えるとわかりやすくなります。

主な業務範囲

• SLI・SLO の設計と計測。何を信頼性の指標にするかを決め、ダッシュボードに載せる
• 監視とアラートの設計。人を起こす価値のあるアラートだけを残し、それ以外を消す
• インシデント対応とポストモーテム。障害の再発防止策をコードや仕組みに落とし込む
• トイル（繰り返しの手作業）の削減。デプロイ・プロビジョニング・復旧手順を自動化する
• キャパシティプランニングと負荷試験。トラフィックの伸びに対して余力を先回りで確保する
• 開発チームへの信頼性レビュー。新機能の設計段階で単一障害点や退行の経路を指摘する

求められる能力

技術面では、コードを書けることが前提になります。Go や Python などでツールを実装し、Terraform や Kubernetes のようなインフラのコード化基盤を扱い、分散システムの障害モードを理解している人が中心です。監視基盤（Prometheus / Datadog 等）の設計経験、Linux とネットワークの基礎、データベースの運用知識も広く求められます。

非技術面では、事業側と信頼性の目標を交渉できることが決め手になります。SLO は技術だけでは決まらず、「どこまでの停止なら事業として許容できるか」を言語化する作業だからです。障害時に情報を整理して周囲に伝える力、ポストモーテムを犯人探しにしない運営力も、実務では技術力と同じ比重で見られます。

この職種に就く人のキャリア経路

多いのはインフラエンジニア・サーバーサイドエンジニアからの移行です。前者はコードを書く比率を上げる方向で、後者は本番環境の運用責任を持つ方向で、それぞれ SRE に寄っていきます。ネットワークエンジニアや情報システム部門からの転向もありますが、その場合はアプリケーションコードを読める状態になっているかが分かれ目になります。

その後の進路は、プラットフォームエンジニアや共通基盤の責任者として横断組織を作る道と、EM やアーキテクトとして組織全体の技術的意思決定に回る道に分かれます。クラウドベンダーやオブザーバビリティ製品のソリューションアーキテクトへ移る人も一定数います。

隣接職種との違い

採用担当の見極めポイント

• 求人票に SRE と書かれていても、実態が「従来のインフラ運用の呼び替え」である場合があります。SLO を運用しているか、直近1年で何を自動化したかを聞くと、実態がはっきりします
• 職務経歴書の「SRE 経験」は、基盤の新規構築・既存基盤の運用改善・オンコール対応のどれを指すかで中身が別物になります。担当していたサービスの規模と、何人体制のオンコールだったかまで確認してください
• 自社に SRE の考え方を共有できる人がいない状態で1人目を採ると、目標設定も自動化の優先順位も本人の判断だけで決まります。誰と信頼性の目標を合意するのか、入社時点で決めておく必要があります

求人・市場の傾向

国内の母集団は、SRE を名乗って募集を出している企業の数に対して薄い状態が続いています。実務経験者の多くは既に事業会社の中核にいて、転職市場に出てくる頻度が低いためです。とくにマネージドサービスの利用にとどまらず、SLO 運用まで回した経験を持つ人は限られます。

そのため、募集要件を「SRE 経験者」に固定すると母集団がほとんど作れないことがあります。サーバーサイドエンジニアで本番運用の改善を主導した人、インフラエンジニアでコードを書いてきた人まで対象を広げ、入社後に SRE の枠組みを渡す設計のほうが現実的です。

関連キーワード

SLI / SLO / エラーバジェット / トイル / オブザーバビリティ / ポストモーテム / オンコール / Kubernetes / Terraform / プラットフォームエンジニアリング