[完全ガイド] Site Reliability Engineer: SREの年収・将来性は？未経験からのロードマップを徹底解説

導入：Site Reliability Engineerの面接官は「ここ」を見ている

SRE（Site Reliability Engineer）の採用において、面接官が最も注視しているのは、単なる「インフラ知識の有無」ではありません。私たちが真に見極めようとしているのは、「ソフトウェアエンジニアリングの手法を用いて、運用の問題を解決しようとする執念」です。

多くの候補者が陥る最大の地雷は、「私はインフラの構築と保守が得意です」という、従来のインフラエンジニア（SysAdmin）の延長線上のアピールに終始してしまうことです。SREは「運用の自動化」を当然の前提とし、その先にある「信頼性の設計」に責任を持ちます。

私たちが警戒する「NGな候補者」は、以下のような特徴を持っています。 - 手作業（トイル）を厭わず、気合と根性で障害対応しようとする。 - 「なぜその数値（SLO）を設定したのか」というビジネス側への視点が欠如している。 - コードが書けず、シェルスクリプトのコピペで済ませようとする。

逆に、私たちが喉から手が出るほど欲しい「コアスキル」を持つ候補者は、「エラーバジェット（失敗の許容範囲）」を理解し、開発速度と信頼性のトレードオフを論理的に語れる人物です。このガイドでは、そんな「選ばれるSRE」になるための全戦術を公開します。

🗣️ Site Reliability Engineer特化型：よくある「一般質問」の罠と模範解答

1. 自己紹介

SREの面接における自己紹介は、単なる経歴紹介ではありません。「私は信頼性の守護神であり、かつ開発の加速装置である」という一貫したストーリーが必要です。

• ❌ NGな回答: 「これまでインフラエンジニアとして、サーバーの構築や監視を5年経験してきました。AWSのEC2やRDSを触れます。障害が発生した際は迅速に復旧作業を行ってきました。御社でもこれまでの経験を活かして安定稼働に貢献したいです。」 （※解説：これではただの「保守担当」です。SREとしての能動的な改善姿勢が見えません。）

• ⭕ 模範解答: 「私はこれまで5年間、大規模Webサービスの信頼性向上に注力してきました。直近の3年間はSREチームの立ち上げに関わり、手作業によるデプロイ作業をTerraformとGitHub Actionsで100%自動化し、トイル（運用負荷）を40%削減しました。単に『壊さない』ことだけでなく、SLO（サービスレベル目標）を定義し、エラーバジェットに基づいた開発チームとの意思決定プロセスを構築した経験があります。御社では、この『攻めの運用』の知見を活かし、サービスの急成長を支えるスケーラブルな基盤を構築したいと考えています。」

2. 退職理由（転職理由）

SREは「現状の不効率」を解決する職種であるため、退職理由も「より高度な技術的課題への挑戦」や「SRE文化の徹底」に紐付けるのが正解です。

• ❌ NGな回答: 「今の会社はオンコールが多く、夜間の呼び出しで疲弊してしまったため、ワークライフバランスを整えたいと思いました。また、開発チームがインフラのことを理解してくれず、無理なリリースを繰り返すことに限界を感じました。」 （※解説：他責思考に見える上、SREに付き物のオンコールから逃げている印象を与えます。）

• ⭕ 模範解答: 「現職ではインフラの自動化やモニタリングの整備に一定の成果を出せましたが、組織構造上、開発チームと運用チームが分断されており、SREの本質である『信頼性を共通言語とした開発・運用の協力体制』を築くことに限界を感じました。私は、エラーバジェットの概念を導入し、開発者が自ら信頼性に責任を持てるようなプラットフォームエンジニアリングの領域まで踏み込みたいと考えています。御社のエンジニアリングブログを拝見し、SREがプロダクトの意思決定に深く関与している点に強く惹かれ、志望いたしました。」

⚔️ 【経験年数別】容赦ない「技術・専門知識」質問リスト

🌱 ジュニア層（実務未経験〜3年）への質問

【深掘り解説】

Q1. Linuxサーバーで「負荷が高い（Load Averageが高い）」というアラートが飛びました。まず、どのようなコマンドを使って、どこをチェックしますか？

• 💡 面接官の意図: トラブルシューティングの基礎体力と、OSの基本リソース（CPU、メモリ、I/O）に対する理解度を確認します。単にコマンド名を知っているだけでなく、その数値が何を意味するかを理解しているかが重要です。

• ❌ NGな回答: 「とりあえず top コマンドを叩いて、なんとなく数字が高いプロセスを探します。わからなければサーバーを再起動してみます。」

• ⭕ 模範解答: 「まず top や htop で全体の状況を俯瞰し、Load Averageの3つの数値（1分、5分、15分）を見て、負荷が上昇傾向にあるか、一時的なものかを確認します。次に、CPU負荷が高いのか、I/O待ち（iowait）が高いのかを切り分けます。CPUであれば vmstat や mpstat でユーザー空間かカーネル空間かを確認し、I/Oであれば iostat でディスク負荷を特定します。また、free -m でスワップが発生していないかも確認します。原因がプロセス特定できれば ps や lsof で詳細を調査します。」

Q2. Dockerコンテナと仮想マシン（VM）の根本的な違いを、リソースの観点から説明してください。

• 💡 面接官の意図: 現代のSREにとって必須のコンテナ技術の基礎を理解しているか。オーバーヘッドやカーネルの共有といった概念を正確に把握しているかを確認します。

• ❌ NGな回答: 「Dockerの方が軽くて起動が早いです。VMは重いです。Dockerはコンテナという単位で動くので便利です。」

• ⭕ 模範解答: 「最大の違いは、ゲストOSの有無とカーネルの共有です。VMはハイパーバイザ上で動作し、各インスタンスが独自のゲストOSを持つため、リソース消費が大きく起動も低速です。一方、DockerコンテナはホストOSのカーネルを共有し、プロセスを名前空間（Namespace）やcgroupsで隔離して実行するため、非常に軽量で起動が高速です。ただし、カーネルを共有する特性上、ホストOSと異なるカーネルバージョンが必要なアプリは動かせないといった制約や、セキュリティ面での考慮が必要です。」

【一問一答ドリル】

• Q. HTTPのステータスコード「502 Bad Gateway」と「504 Gateway Timeout」の違いは何ですか？

• A. 502はバックエンドサーバー（Upstream）からの不正なレスポンスを受け取った場合、504はバックエンドからの応答が制限時間内に返ってこなかった場合（タイムアウト）を指します。

• Q. DNSのAレコードとCNAMEレコードの違いを説明してください。

• A. Aレコードはドメイン名をIPアドレスに紐付け、CNAMEレコードはドメイン名を別のドメイン名（エイリアス）に紐付けます。

• Q. TCPとUDPの主な違いは何ですか？

• A. TCPはコネクション型で信頼性（確認応答や順序制御）を重視し、UDPはコネクションレス型で速度やリアルタイム性を重視します。

• Q. SSHで公開鍵認証を使用するメリットは何ですか？

• A. パスワードをネットワーク上に流さないため盗聴に強く、秘密鍵を持つ特定の端末からしかログインできないため、ブルートフォース攻撃に対して非常に安全です。

• Q. Gitで「merge」と「rebase」をどのように使い分けますか？

• A. mergeは履歴をそのまま残したい場合に使用し、rebaseはコミット履歴を一本にまとめて綺麗に保ちたい場合（主にローカルブランチの整理）に使用します。

🌲 ミドル層（実務3年〜7年）への質問

【深掘り解説】

Q1. SLO（Service Level Objective）を策定する際、どのようにして「適切な数値」を決定しますか？また、誰と合意形成を行いますか？

• 💡 面接官の意図: SREの核心である「信頼性の定義」ができるかを確認します。技術的な独りよがりではなく、ビジネスインパクトとユーザー体験に基づいた思考ができるかを見ます。

• ❌ NGな回答: 「システムが止まらないことが一番なので、稼働率99.99%を目標にします。エンジニアチームだけで決めて、それを守るように運用します。」

• ⭕ 模範解答: 「まず、ユーザー体験に直結する指標（SLI）を選定します。例えばリクエストの成功率やレイテンシです。数値の決定には、過去のパフォーマンスデータと、ビジネス上の許容範囲を考慮します。100%を目指すとコストと開発速度が犠牲になるため、『ユーザーが不満を感じない最低限のライン』を探ります。合意形成は、プロダクトマネージャー（PdM）やビジネスサイドのステークホルダーと行います。エラーバジェットを使い切った際に『新機能開発を止めて信頼性向上にリソースを割く』というポリシーまで含めて合意することが不可欠です。」

Q2. Terraformで管理しているインフラにおいて、手動で変更が加えられてしまい「ドリフト（差分）」が発生しました。どのように対処し、再発を防止しますか？

• 💡 面接官の意図: IaC（Infrastructure as Code）の運用経験と、構成管理の厳密さに対する姿勢を確認します。

• ❌ NGな回答: 「とりあえず terraform apply を叩いて上書きします。それでもダメなら state ファイルを手で修正します。再発防止としては、みんなに『手動で触らないで』とメールします。」

• ⭕ 模範解答: 「まず terraform plan で現在のstateと実環境の差分を正確に把握します。手動変更が正当な理由（緊急対応など）であれば、その内容をコードに反映し、stateと同期させます。不要な変更であれば、terraform apply でコードの状態に戻します。再発防止策としては、まずCI/CDパイプライン（GitHub Actions等）を通じたデプロイを強制し、個人の端末からの直接操作権限を剥奪（IAM制限）します。また、定期的に terraform plan を実行して差分を検知・通知する仕組み（Drift Detection）を導入します。」

【一問一答ドリル】

• Q. カナリアリリース（Canary Release）のメリットと、実現するために必要なコンポーネントは何ですか？

• A. 新機能を一部のユーザーにのみ先行公開してリスクを最小化できるのがメリットです。実現には、トラフィックを制御するロードバランサーやサービスメッシュ、異常を検知する高度なモニタリングが必要です。

• Q. Kubernetesの「Deployment」と「StatefulSet」の主な使い分けは何ですか？

• A. DeploymentはWebサーバーのようなステートレスなアプリに使用し、StatefulSetはDBのように固定のホスト名や永続ストレージが必要なステートフルなアプリに使用します。

• Q. プリメテウス（Prometheus）における「Pull型」監視のメリットは何ですか？

• A. 監視対象が自らデータを送る必要がないため対象側の負荷が低く、監視サーバー側で収集頻度を制御しやすい点や、対象の死活監視が容易である点です。

• Q. トイル（Toil）の定義と、それを削減すべき理由を説明してください。

• A. トイルは「手作業、反復的、自動化可能、戦術的、長期的な価値がない」作業です。これを削減しないと、エンジニアが本来行うべき「エンジニアリングによる改善」の時間が奪われ、モチベーション低下とシステムの硬直化を招くからです。

• Q. ブルーグリーンデプロイメントにおいて、切り戻し（ロールバック）を迅速に行うためのポイントは何ですか？

• A. 旧環境（ブルー）を即座に破棄せず、新環境（グリーン）に問題があった際にロードバランサーの向きを瞬時に戻せる状態を維持すること、およびDBのマイグレーションに後方互換性を持たせることです。

🌳 シニア・リード層（実務7年以上〜マネージャー）への質問

【深掘り解説】

Q1. マルチリージョンでのディザスタリカバリ（DR）戦略を設計する際、RTO（目標復旧時間）とRPO（目標復旧時点）をどのように定義し、コストとのバランスをどう取りますか？

• 💡 面接官の意図: 大規模システムのアーキテクチャ設計能力と、経営的視点（コスト対効果）を問います。

• ❌ NGな回答: 「常に全データを全リージョンにリアルタイム同期し、RTO/RPOをゼロにします。コストはかかりますが、止まらないことが正義です。」

• ⭕ 模範解答: 「ビジネスインパクト分析（BIA）を行い、サービス停止1時間あたりの損失額を算出します。その上で、アクティブ/パッシブ構成（パイロットライトやウォームスタンバイ）か、アクティブ/アクティブ構成かを選択します。例えば、DBのレプリケーション遅延を許容してコストを抑えつつRPOを数分に設定するか、あるいはAurora Global Database等を用いて低レイテンシ・低RPOを実現するかを、事業継続の重要度と予算を照らして提案します。また、定期的なDR訓練を実施し、定義したRTOが理論値ではなく実効値であることを証明するプロセスまで設計に含めます。」

Q2. 開発チームのリリース頻度が高く、エラーバジェットを頻繁に食いつぶしています。彼らは「機能開発が最優先だ」と主張しています。SREリードとしてどう動きますか？

• 💡 面接官の意図: 組織的な課題解決能力と、交渉力、そしてSRE文化の浸透スキルを確認します。

• ❌ NGな回答: 「ルールなので強制的にリリースを止めます。文句を言われたら上長に報告します。」

• ⭕ 模範解答: 「対立構造を作るのではなく、『信頼性は機能の一部である』という共通認識を醸成します。まず、エラーバジェットの消費内訳を可視化し、なぜ失敗しているのか（コードの品質か、インフラの不安定さか）をデータで示します。もしリリース頻度が高すぎて失敗しているなら、自動テストの拡充やカナリアリリースの導入をSRE側から提案・サポートし、『安全に速く出すための仕組み』を一緒に作ります。それでも改善しない場合は、事前に合意したエラーバジェットポリシーに基づき、スプリントの一定割合を信頼性向上タスクに充てるよう、PdMを含めた会議で意思決定を促します。」

【一問一答ドリル】

• Q. カオスエンジニアリング（Chaos Engineering）を導入する際の最初のステップは何ですか？

• A. システムの「定常状態」を定義し、メトリクスで観測可能にすることです。その上で、本番環境に影響の少ない小さな実験から開始します。

• Q. FinOpsの観点で、クラウドコストを最適化するための具体的な手法を3つ挙げてください。

• A. 1. 未使用リソース（ゾンビインスタンス）の特定と削除、2. リザーブドインスタンスやセービングスプランの適用、3. スポットインスタンスの活用とオートスケーリングの最適化。

• Q. サービスメッシュ（Istio等）を導入する最大の動機と、引き換えになるデメリットは何ですか？

• A. 動機はマイクロサービス間の可観測性、トラフィック制御、セキュリティ（mTLS）の共通化です。デメリットは、ネットワークのホップ数増加によるレイテンシと、運用の複雑性の増大です。

• Q. インシデント発生時、コマンダー（指揮官）が果たすべき最も重要な役割は何ですか？

• A. 意思決定に集中し、作業（実操作）を自分で行わないことです。情報の集約、役割（広報、記録、実作業）の割り当て、そして「何をやらないか」の判断を下すことに専念します。

• Q. 「オブザーバビリティ（可観測性）」の3つの柱を挙げ、それぞれの役割を述べてください。

• A. メトリクス（統計的な傾向把握）、ログ（個別の事象の記録）、トレース（リクエスト単位の分散システム間の遷移把握）の3つです。

🧠 思考力と修羅場経験を探る「行動・ソフトスキル質問」

【深掘り解説】

Q1. 過去に経験した「最も深刻なシステム障害」について教えてください。その際、あなたはどのように行動し、最終的にどのような恒久対策を講じましたか？

• 💡 面接官の意図: プレッシャー下での判断力と、反省を次に活かす「ポストモーテム（事後分析）」の姿勢を見ます。

• ❌ NGな回答: 「DBがクラッシュして半日止まりました。必死に復旧作業をして、なんとか直しました。その後は気をつけるようにしました。」

• ⭕ 模範解答: 「数年前、特定クエリによる接続数飽和で全サービスがダウンする障害がありました。私はインシデントコマンダーとして、まず影響範囲を特定し、暫定対応としてリードレプリカへのトラフィック分散と、特定機能のサーキットブレイカー発動を指示しました。復旧後、ブレイムレス（非難なし）なポストモーテムを実施。根本原因がアプリケーション側のコネクションプール管理の不備にあることを突き止めました。恒久対策として、クエリのタイムアウト設定の厳格化と、異常検知時に自動でスロットリングを行う仕組みを導入し、同様の事象での全断を防止しました。」

Q2. 開発チームが「監視アラートがうるさすぎて無視している」という状況にあります。あなたならどう改善しますか？

• 💡 面接官の意図: アラート疲弊（Alert Fatigue）に対する理解と、実効性のある運用設計ができるかを確認します。

• ❌ NGな回答: 「アラートの通知先を自分だけにして、開発者には見せないようにします。あるいは、アラートの閾値を極端に下げて鳴らないようにします。」

• ⭕ 模範解答: 「アラートの『信憑性』と『アクション可能性』を見直します。対応不要な通知（ノイズ）は即座に削除するか、チケット化して日中に確認する程度の優先度に下げます。オンコールで叩き起こすアラートは『即座に人間が介入しないと致命的なもの』だけに厳選します。また、アラート通知にランブック（手順書）へのリンクを添付し、誰でも迷わず対応できるようにします。これらを開発チームと共同で行うことで、アラートを『邪魔なもの』から『自分たちを守るための信頼できる信号』へと再定義します。」

【一問一答ドリル】

• Q. 優先順位の異なる複数のタスクを抱えている時、どのように整理しますか？

• A. 「ユーザーへの影響度（信頼性）」と「ビジネスの緊急度」を軸にマトリクスを作成し、エラーバジェットの残り状況を見て判断します。

• Q. 自分の技術的なミスで障害を起こしてしまった時、最初に何をしますか？

• A. 隠さず即座にチームに報告し、被害の最小化（ロールバック等）に全力を挙げます。その後、なぜそのミスが「仕組み」で防げなかったのかを分析します。

• Q. 非技術者のステークホルダーに「技術負債の解消」の必要性を説明するにはどうしますか？

• A. 「このまま放置すると将来的に新機能の開発スピードが○%低下し、障害による損失リスクが○円発生する」と、ビジネス指標に換算して説明します。

• Q. チーム内で意見が対立した際、どのように合意形成を図りますか？

• A. 感情論を排除し、SLOやコスト、保守性といった共通の評価軸（データ）に基づいて議論を進め、プロトタイプによる検証結果を重視します。

• Q. SREとして、自分のモチベーションをどこに置いていますか？

• A. 「複雑なシステムが安定して動き続けること」そのものと、自分の自動化によって「仲間が楽になり、プロダクトが加速すること」に最大の喜びを感じます。

📈 面接官を唸らせるSite Reliability Engineerの「逆質問」戦略

1. 「現在、貴社のSREチームにおいて、トイル（運用負荷）とエンジニアリング（改善活動）の比率はどの程度でしょうか？また、理想の比率に近づけるための最大の障壁は何だとお考えですか？」

2. 💡 理由: Googleが提唱する「トイル50%以下」というSREの原則を理解していることを示しつつ、現場のリアルな課題を聞き出すことで、自分が貢献できるイメージを具体化できます。

3. 「エラーバジェットを使い切った際の『リリース停止』などのポリシーは、ビジネスサイドとどの程度厳格に合意されていますか？実際にリリースを止めた事例があれば教えてください。」

4. 💡 理由: 組織としてのSRE文化の成熟度を測る鋭い質問です。これが機能している会社は、SREの権限が適切に認められている優良な職場である可能性が高いです。

5. 「オンコール体制において、一次対応の自動化（セルフヒーリング）はどの程度進んでいますか？また、オンコール担当者の心理的安全性や負担軽減のために取り組んでいることはありますか？」

6. 💡 理由: 運用の自動化への意欲と、チームの持続可能性を重視する姿勢をアピールできます。

7. 「開発チームがインフラや信頼性に責任を持つ『You build it, you run it』という文化を、SREとしてどのように支援、あるいは推進されていますか？」

8. 💡 理由: SREを「何でも屋」ではなく「プラットフォーム提供者」として捉えていることを示し、モダンなSRE像を持っていることを証明できます。

9. 「今後1〜2年で、システムのアーキテクチャや組織構造において、SREが主導して解決すべき最大の技術的チャレンジは何だと考えていますか？」

10. 💡 理由: 会社の将来展望に興味を持ち、長期的に貢献する意欲があることを示せます。また、入社後に自分が取り組むべき「大きな仕事」を把握できます。

結び：Site Reliability Engineer面接を突破する極意

SREの面接は、知識の量を競うテストではありません。それは、あなたが「不確実なシステムという怪物」とどう向き合い、いかにして「エンジニアリングという武器」でそれを手懐けるかという、あなたの思想と哲学を問う場です。

面接官は、あなたが完璧であることを求めてはいません。むしろ、失敗から何を学び、それを二度と起こさないための「仕組み」をどう作るか、そのプロセスを熱く語る姿に惹かれます。

SREは、プロダクトの成功を影で支えるだけでなく、その基盤をデザインする主役です。あなたがこれまで経験してきた苦労や、深夜の障害対応、自動化に成功した時の喜び。そのすべてが、あなたの強力な武器になります。

自信を持ってください。あなたが「信頼性」を誰よりも大切に思う気持ちがあれば、必ず面接官に伝わります。このガイドを羅針盤として、理想のキャリアを切り拓いてください。応援しています！