Site Reliability Engineer 面接質問 — 30以上の質問と専門家の回答

Glassdoorの報告によると、SREの平均年収は169,680ドルで、75パーセンタイルは年間213,000ドルを超えています [1]。この役割は2003年にGoogleで誕生し、現在ではすべての主要テクノロジー企業に採用されており、ソフトウェアエンジニアリングとシステム運用の交差点に位置しています。面接プロセスはこの二面性を反映しています [2]。SREの面接では、信頼性制約を伴うシステム設計、自動化のためのコーディング、プレッシャー下でのインシデント管理、そしてSLOとエラーバジェットを通じて信頼性を定量化する特有のマインドセットがテストされます。このガイドでは、直面する行動面接、技術面接、状況判断面接の質問と、一流企業が期待する深さに合わせた回答を網羅しています。

重要なポイント

• SREの面接は通常4〜6ラウンドで構成されます：コーディング、システム設計、トラブルシューティング、インシデント管理、行動面接 — 1日または複数回のセッションにわたって実施されます [3]。
• SRE面接の核心的な差別化要因は信頼性重視のシステム設計です — 単にスケールするシステムではなく、グレースフルに劣化するシステムを設計する必要があります [2]。
• SLO、SLI、エラーバジェット、トイル削減はSRE固有の用語であり、面接官はこれらを流暢に使いこなすことを期待しています。
• SRE職のコーディング問題は、純粋なアルゴリズム問題ではなく、自動化、インフラストラクチャツーリング、運用スクリプティングを重視しています [3]。

行動面接の質問

1. 管理した中で最もインパクトのあったインシデントについて教えてください。あなたの役割は何で、ポストモーテムで何が明らかになりましたか？

専門家の回答： 「私はプライマリ認証サービスをダウンさせたカスケード障害のインシデントコマンダーでした。2300万のアクティブユーザーに47分間影響を及ぼしました。レートリミッターへのルーティン設定変更が、閾値を誤って10,000リクエスト/秒ではなく10リクエスト/秒に設定してしまいました。認証サービスがリミットに到達し、429エラーを返し、クライアントのリトライストームが負荷を50倍に増幅させました。P1を宣言し、インシデントチャネルを確立し、役割を割り当て（コミュニケーションリード、認証とインフラの技術リード）、対応を調整しました。修正は設定変更のロールバックでしたが、一時的にキャパシティを増やしてリトライバックログもドレインする必要がありました。ポストモーテムでは3つの根本原因を特定しました：レートリミッター設定値のバリデーション不在、設定変更のカナリアデプロイメント不在、クライアントリトライのサーキットブレーカー不在。3つの修正すべてを実装し、30秒ごとに認証フローをテストする合成カナリアを追加しました。このインシデントは四半期エラーバジェットの40%を消費し、信頼性改善が出荷されるまで新機能の開発凍結をトリガーしました。」

2. 重大なトイルの発生源を排除した経験について説明してください。

専門家の回答： 「オンコールエンジニアは、トラフィックスパイク時にデータベースリードレプリカを手動でスケーリングするために、週平均6時間を費やしていました — ダッシュボードを監視し、インスタンスにSSHし、スケーリングスクリプトを実行していました。これは典型的なトイルでした：手動、反復的、自動化可能、そしてサービスの成長に比例してスケールします。カスタムKubernetesオペレーターを使用したオートスケーリングコントローラーを構築しました。CPUとクエリレイテンシのメトリクスを監視し、過去のトラフィックパターンに基づく予測モデルを使用して必要なレプリカ数を計算し、レプリカを自動的にスケールアップ/ダウンしました。セーフガードも追加しました：最小・最大レプリカ数、フラッピング防止のクールダウン期間、オートスケーリングが最大キャパシティの80%に達した時のPagerDutyアラート（インフラ投資が必要なオーガニックグロースを示すシグナル）。デプロイ後、手動スケーリング介入は週6時間から0に減少し、オンコール負荷は30%減少しました。自動化されたスケーリングが人間より速く反応したため、P99クエリレイテンシも15%改善しました。」

3. 過度に攻撃的だと考えた信頼性要件に対して反論した例を挙げてください。

専門家の回答： 「プロダクトチームが新しい通知サービスに対して99.999%の可用性（ファイブナイン）を要求しました。ファイブナインが実際に何を意味するかを計算しました：年間5.26分のダウンタイムであり、マルチリージョンのアクティブ-アクティブデプロイメント、30秒以内の自動フェイルオーバー、そしてカナリアデプロイメントなしの設定変更に対する実質的なゼロトレランスが必要になります。エンジニアリングコストは6ヶ月と追加インフラ40万ドルと見積もられました。そこでプロダクトチームに尋ねました：「通知が5分遅れた場合、ユーザーにどのような影響がありますか？」答えは「何もない — 通知はタイムクリティカルではない」でした。既存のインフラで小規模な改善により達成可能な99.9%の可用性（年間8.76時間のダウンタイム）を提案しました。プロダクトチームはコスト-信頼性トレードオフの曲線を見た後、同意しました。これがSREの規律です：信頼性は機能であり、すべての機能と同様に、ユーザーへの影響によって正当化されるべきコストがあります [2]。」

4. 重要なサービスのモニタリングまたはオブザーバビリティを改善した経験について教えてください。

専門家の回答： 「決済サービスのモニタリングは基本的なヘルスチェック — HTTP 200レスポンスとCPU利用率 — のみを追跡していました。サービスが200を返しながら3時間にわたって古いキャッシュデータを提供していたサイレント障害の後、オブザーバビリティスタックを再設計しました。ユーザー体験に連動したSLIを定義しました：決済完了率（目標99.95%）、P99での決済処理レイテンシ（目標2秒）、データ鮮度（キャッシュ陳腐化60秒以内）。これらをPrometheusメトリクスとして実装し、SLOバーンレートアラート付きのGrafanaダッシュボードを作成し（マルチウィンドウ：高速バーン用5分、低速バーン用1時間）、7つのマイクロサービスにまたがる決済フローを追跡するためにJaegerで分散トレーシングを追加しました。マルチウィンドウアラートアプローチにより、偽陽性のページが60%減少しながら、プロジェクトの発端となったサイレント障害のタイプを検出できるようになりました。「サービスは稼働しているか？」から「サービスはユーザーに価値を提供しているか？」へ移行しました。」

5. 機能開発のベロシティと信頼性作業のバランスをどのように取ったか説明してください。

専門家の回答： 「信頼性作業と機能開発が同じメトリクスによって管理されるエラーバジェットポリシーを実装しました。月間エラーバジェットが50%以上であれば、開発チームは機能にフルスピードで取り組みました。50%を下回ると、機能と信頼性改善を50/50で分割しました。25%を下回ると、バジェットが回復するまですべてのエンジニアリング努力を信頼性に移しました。これは厳格なルールではなく、SREとプロダクトチーム間で交渉された合意で、チームチャーターに文書化されました。重要な洞察は、エラーバジェットが信頼性を具体的にすることです：信頼性が「重要かどうか」を議論する代わりに、エラーバジェットの80%を消費したことを示すデータを指し示し、安定性への投資が必要だと示すことができました。1年間で、このアプローチによりP1インシデント率は45%減少し、一方でプロダクトチームは前年比12%多くの機能を出荷しました — インシデント対応やホットフィックスに費やす時間が減ったためです。」

6. オンコールローテーションにどのようにアプローチし、チームのオンコール体験をどのように改善しましたか？

専門家の回答： 「オンコールを人員配置の問題ではなく、エンジニアリングの問題として捉えています。チームに参加した時、オンコールエンジニアは週平均14回アラートを受けており、40%のページが対応不要または重複でした。3つの変更を実施しました。第一に、アラートチューニング：30日間のすべてのアラートをレビューし、発火しなかったアラートや一貫して対応不要だったアラートを削除し、PagerDutyのアラートグルーピングを使用して重複アラートを統合しました。第二に、ランブック自動化：最も頻繁な対応可能アラートのトップ5について、自動修復スクリプト（PagerDuty Webhooksでトリガー）を書き、初期対応アクションを処理し、自動修復が失敗した場合にのみ人間にアラートしました。第三に、オンコール引き継ぎの改善：構造化された引き継ぎドキュメント（オープンインシデント、最近の変更、既知のリスク）と、退任・着任オンコール間の15分の同期引き継ぎミーティングを導入しました。ページは週14回から4回に減少し、オンコール満足度調査スコアは2.1/5から4.3/5に改善しました。」

技術的な質問

1. SLO、SLI、エラーバジェットについて説明してください。それらの関係性は？

専門家の回答： 「SLI（Service Level Indicator）は、サービス品質の特定の側面を測定する定量的メトリクスです — 例えば、200ms以内に正常に返されたHTTPリクエストの割合。SLO（Service Level Objective）はSLIの目標値です — 例えば、ローリング30日ウィンドウで99.9%のリクエストが200ms以内に成功すべき。エラーバジェットはSLOの逆数です：SLOが99.9%であれば、エラーバジェットは0.1% — 測定ウィンドウで0.1%の障害を許容できます。1日100万リクエストを処理するサービスでは、99.9%のSLOは1日1,000件の障害を許容できることを意味します。エラーバジェットはSREとプロダクトチーム間の共通言語を作ります：バジェット内であれば積極的に機能をリリースし、バジェットが消費されたら信頼性に投資します。これにより、信頼性に関する主観的な議論が、客観的なデータ駆動の意思決定に置き換えられます [2]。」

2. 50のサービスを持つマイクロサービスアーキテクチャ向けのモニタリングとアラートシステムを設計してください。

専門家の回答： 「3つのレイヤーでシステムを構築します。データ収集：各サービスにPrometheusクライアントライブラリを導入し、REDメトリクス（Rate, Errors, Duration）とカスタムビジネスメトリクスをエクスポート。Prometheusフェデレーション階層を使用 — クラスターごとのPrometheusインスタンスが長期保存とクロスクラスタークエリのための中央のThanosまたはMimirにフィード。LokiまたはElasticsearchによる構造化ログのログ集約。JaegerまたはTempoによる全50サービスにわたるコンテキスト伝搬を伴う分散トレーシング。アラート：個々のエンドポイントではなく、各サービスの重要なユーザージャーニーに対してSLOを定義。マルチウィンドウバーンレートアラートを実装：1時間閾値上の5分ウィンドウが高速バーンを検出、6時間閾値上の30分ウィンドウが低速バーンを検出。チームベースのルーティングとエスカレーションポリシーでPagerDutyを通じてアラートをルーティング。ダッシュボード：サービスごとのゴールデンシグナルダッシュボード（レイテンシ、トラフィック、エラー、飽和）、全50サービスのバジェット消費を表示するトップレベルSLOダッシュボード、トレーシングデータから生成されるサービス依存関係マップを構築。重要な設計原則：原因（CPU高）ではなく症状（ユーザー影響）でアラートし、すべてのアラートメタデータにランブックをリンクさせること。」

3. サービスの応答が遅いです。トラブルシューティングのアプローチを説明してください。

専門家の回答： 「ユーザーへの影響から始めます：P50/P99レイテンシは通常と比べてどうか、影響を受けているユーザーの割合は？次にUSEメソッド（Utilization, Saturation, Errors）とREDメソッド（Rate, Errors, Duration）を体系的に辿ります。まず、サービス自体を確認：CPU、メモリ、GCポーズ（JVMサービスの場合）、スレッドプール飽和、コネクションプール枯渇。次に、下流の依存関係を確認：データベースクエリレイテンシ（スロークエリ？ロック競合？欠落インデックス？）、キャッシュヒット率（キャッシュがコールドスタートしたか、ホットキーを追い出したか？）、外部APIレイテンシ（サードパーティサービスが劣化しているか？）。さらに、ネットワークを確認：パケットロス、DNS解決遅延、TLSハンドシェイクオーバーヘッドがあるか？分散トレーシングを使用して、リクエストパスのどのスパンが最もレイテンシに寄与しているかを特定します — これにより分散システム全体のボトルネックが特定されます。段階的な劣化であれば、リソースリーク（メモリ、接続、ファイルディスクリプタ）やキャパシティを超えるトラフィック増加を確認します。突然の場合は、最近のデプロイメント、設定変更、上流トラフィックパターンの変化を確認します。」

4. 複数のリージョンにまたがって99.99%の可用性を達成するシステムをどのように設計しますか？

専門家の回答： 「99.99%の可用性は年間52.6分のダウンタイムを許容します。つまり、すべてのコンポーネントが冗長であるか、独立して障害を起こす必要があります。アーキテクチャ：少なくとも3リージョンにまたがるアクティブ-アクティブデプロイメント（キャパシティを無駄にしフェイルオーバーリスクを導入するアクティブ-パッシブではなく）。ヘルスチェック駆動のトラフィックシフティングによるグローバルロードバランシング（Cloudflare, AWS Global Accelerator） — リージョンがヘルスチェックに失敗した場合、30秒以内にトラフィックが自動的に正常なリージョンにルーティングされます。データレイヤー：リージョン内の同期レプリケーション（一貫性のため）、リージョン間の非同期レプリケーション（データモデルに応じたCRDTsまたはlast-writer-winsによる競合解決）。クロスリージョン書き込みにはレイテンシオーバーヘッドがあることを受け入れます。デプロイメント：リージョンごとのカナリアデプロイメント — 1リージョンにデプロイし、30分観察し、残りのリージョンに展開。これにより、不良デプロイが同時にすべてのリージョンをダウンさせることを防ぎます。設計すべき障害モード：単一リージョン障害、データベースプライマリフェイルオーバー、DNS伝播遅延、証明書有効期限切れ、依存関係の障害。テスト：定期的なカオスエンジニアリング — GremlinやLitmusなどのツールを使用して毎月障害を注入し、フェイルオーバーが文書化された通りではなく設計された通りに機能することを検証します。」

5. 水平スケーリングと垂直スケーリングの違いは何ですか？それぞれをいつ好みますか？

専門家の回答： 「垂直スケーリングは単一インスタンスのリソースを増加させます（CPU、RAM、高速ディスク）。水平スケーリングはロードバランサーの背後にインスタンスを追加します。ステートレスサービス（Webサーバー、APIサーバー、ワーカー）には水平スケーリングを好みます。線形的なキャパシティ成長、フォールトトレランス（1インスタンスの喪失は軽微）、クラウドインフラパターンとの整合性が得られるためです。水平スケーリングが複雑さを導入するステートフルコンポーネントには垂直スケーリングを使用します — ワーキングセットにより多くのメモリが必要なデータベースプライマリや、CPUバウンドのシングルスレッド処理パイプラインなど。実際の判断は3つの要因に依存します：状態管理（ステートフルサービスは水平スケーリングが困難）、コスト効率（垂直スケーリングは収穫逓減とハードウェア上限に達する）、障害の影響範囲（大きなインスタンス1つの障害は壊滅的；小さなインスタンス20個中1個の障害は管理可能）。本番では通常両方を組み合わせます：データベースを最大の実用的インスタンスに垂直スケールし、次にリード集中ワークロードにはリードレプリカで水平スケールします。」

6. Infrastructure as Code (IaC) について説明し、信頼性向上にどのように活用したか教えてください。

専門家の回答： 「Infrastructure as Codeは、インフラ設定をソフトウェアとして扱います：バージョン管理、レビュー、テスト、再現可能。クラウドリソースプロビジョニング（VPC、データベース、ロードバランサー、IAMポリシー）にはTerraformを使用し、インスタンス内の構成管理にはAnsibleまたはPuppetを使用しています。信頼性の利点：再現性（コードから数分で任意の環境を再構築でき、スノーフレークサーバーを排除）、監査可能性（git logで誰が何をいつなぜ変更したかがわかる）、テスト可能性（CIでterraform planを実行して適用前に破壊的変更を検出し、Terratestでインフラモジュールのインテグレーションテストを実施）。具体例：ステージング環境がプロダクションから乖離し、ステージングでテストした変更がプロダクション障害を引き起こした際、同じTerraformモジュールから環境固有の変数で両環境を再構築しました。コードが唯一の真実の源となるため、ドリフトは不可能になりました。Terraform CloudにSentinelポリシーも実装し、セキュリティガードレールを強制しました — パブリックS3バケット禁止、0.0.0.0/0イングレスのセキュリティグループ禁止。」

7. 急成長するサービスのキャパシティプランニングにどのようにアプローチしますか？

専門家の回答： 「4段階のフレームワークを使用します。第一に、負荷モデルの確立：主要なリソースドライバー（リクエスト/秒、同時接続数、データ量）を特定し、インフラメトリクス（CPU、メモリ、ディスクI/O、ネットワーク帯域幅）と相関させます。これにより「作業単位」のコストが得られます — 例えば「各APIリクエストは2msのCPUと0.5MBのメモリを消費する」。第二に、成長のモデリング：過去のデータを使用してトラフィック成長を予測（線形、指数的、季節的）。急成長サービスでは少なくとも6ヶ月先まで予測し、2倍の安全係数を適用します。第三に、ボトルネックリソースの特定：最初にキャパシティに達するリソースがスケーリングトリガーを決定します — コンピュートノードのCPU、データベースのIOPS、またはネットワークの帯域幅かもしれません。第四に、応答の自動化：弾力的なリソース（コンピュート、キャッシュ）にオートスケーリングを実装し、非弾力的なリソース（データベースインスタンスのアップグレード、リザーブドキャパシティ）にはリードタイムを考慮した調達を確立します。キャパシティプランを毎月レビューし、予測と実績を比較し、実際の成長が予測から20%以上乖離した場合にモデルを調整します。」

状況判断の質問

1. サービスのエラーバジェットが四半期の残り2週間で使い果たされました。プロダクトチームは主要な機能をリリースしたいと考えています。どうしますか？

専門家の回答： 「エラーバジェットポリシーに従い、バジェットの枯渇は信頼性フリーズをトリガーします — バジェットが回復するか四半期がリセットされるまで機能デプロイメントはなし。プロダクトチームにデータを提示します：「SLOは99.9%で、残り14日でエラーバジェットの100%を消費しました。主要機能のデプロイはデプロイリスクを導入し、さらにSLO違反を深刻化させる可能性があります。」代替案を提供します：フィーチャーフラグの背後に段階的ロールアウト（1% -> 10% -> 100%）で機能をデプロイして影響範囲を最小化できますか？バジェットをより早く回復させる特定の信頼性改善を優先できますか？まず一部のリージョンにのみデプロイする方法はありますか？エラーバジェットポリシーはまさにこの状況のために存在します — これがなければ、ケースバイケースで交渉することになり、SLOフレームワーク全体を損ないます。しかし柔軟性も持ちます：機能が収益にクリティカルでSLO違反が軽微であれば、リーダーシップがトレードオフの完全な可視性の下でリスクを受け入れる可能性があります [2]。」

2. ジュニアエンジニアの変更がプロダクション障害を引き起こしました。ポストモーテムをどのように扱いますか？

専門家の回答： 「基本原則はブレームレス（非難なし）です — ポストモーテムは何が起きたか、なぜシステムがそれを許したかを調べます。誰が悪いかは決して問いません [2]。タイムラインの事実を確立してポストモーテムをリードします：どのような変更が行われ、いつ、即座の影響は何で、いつ検出され、どのように解決されたか？次にシステム的な原因に焦点を当てます：なぜ変更管理プロセスが安全でない変更を許可したのか？不十分なコードレビュー、欠落した自動テスト、不適切なカナリアデプロイメント、またはロールバック能力の欠如はなかったか？アクションアイテムはシステムを改善すべきであり、エンジニアを罰するべきではありません：エラーを検出できたはずの自動バリデーションの追加、問題がプロダクション前に浮上するようにステージング環境のパリティ改善、障害モードをより早く検出するモニタリングの追加。ポストモーテムドキュメントに明示的に記載します：「エンジニアは文書化されたプロセスに従いました。プロセスが不十分であり、これらの改善が再発を防止します。」非難の文化はエンジニアにミスを隠させ、ブレームレスの文化はエンジニアにミスを報告し修正させます。」

3. モニタリング、ドキュメント、テストがないレガシーシステムを引き継ぎました。どこから始めますか？

専門家の回答： 「影響範囲の優先順位付けで始めます。第1週：基本的なヘルスモニタリングの追加 — サービスは応答しているか？エラー率は？リソース利用率は？システムメトリクスのPrometheusエクスポーターをデプロイし、エントリポイントをリクエストレベルメトリクスで計装します。何かに触れる前に可視性を確保します。第2〜4週：コードを読み、リクエストフローを追跡し、依存関係をマッピングしてシステムアーキテクチャをドキュメント化。システムが何と通信し、何がシステムと通信しているかを示す依存関係グラフを作成します。第2月：クリティカルパスのインテグレーションテストを追加 — 壊れた場合にページを生成する唯一のユーザージャーニー。将来の変更のためのセーフティネットを提供します。第3月：変更が手動のSSH-and-deployではなく自動テストと段階的デプロイメントを通過するようにCI/CDを実装。全体を通じてトイルを追跡：このシステムはどのような手動操作を必要とするか？これが自動化作業の優先順位付けに情報を提供します。重要な原則は：書き直さずに安定化すること。何年も稼働しているレガシーシステムは無数のエッジケースを生き延びています — 置き換えは新しいリスクを導入します。」

4. モニタリングがプロダクションでの遅いメモリリークを示しています。サービスは72時間ごとにクラッシュして再起動します。どのようにアプローチしますか？

専門家の回答： 「まず影響を定量化します：再起動はユーザーに見えるエラーを引き起こしていますか？再起動がグレースフル（接続のドレイン、ロードバランサーがクラッシュ前にインスタンスをアンヘルシーとマーク）であれば、即座のユーザー影響は最小限かもしれません。アングレースフル（OOMキル、ドロップされた接続）であれば、迅速な対応が必要なP2です。調査には：トラフィックを削減したプロダクションインスタンスでヒーププロファイリングを有効化（Go用pprof、Java用JVisualVM、Python用memory_profiler）。定期的な間隔（毎時）でヒープスナップショットを取得し、オブジェクト数とサイズを比較して成長しているオブジェクトタイプを特定します。一般的な原因：エビクションなしのキャッシング、ゴルーチン/スレッドリーク、適切なクリーンアップなしのコネクションプール枯渇、イベントリスナーの蓄積。短期的な緩和策として、トラフィックが少ない時間帯に48時間ごとにサービスをグレースフルに再起動するCronJobまたはライブネスプローブを設定 — 根本原因の調査中に時間を稼ぎます。長期的な修正として、リークしているオブジェクトタイプが特定されたら、根本原因を修正し、メモリ使用量SLIをモニタリングに追加し、メモリ成長率が過去の標準を超えた場合のアラートを作成します。」

5. リーダーシップがインフラコストを30%削減しながら現在の信頼性レベルを維持するよう求めています。どのようにアプローチしますか？

専門家の回答： 「4つのカテゴリでコスト削減の機会を特定します。ライトサイジング：実際の利用率に対してインスタンスタイプを監査 — 経験上、クラウドインスタンスの40〜60%がオーバープロビジョニングされています。クラウドプロバイダーの推奨事項（AWS Compute Optimizer, GCP Recommender）を使用し、実際のCPU/メモリ利用率データで検証します。リザーブドキャパシティ：予測可能なベースラインワークロードをオンデマンドからリザーブドインスタンスまたはセービングプランに変換（通常30〜50%の節約）。スポット/プリエンプティブルインスタンス：中断を許容できるフォールトトレラントなワークロード（バッチ処理、CI/CDランナー、ステートレスワーカー）を特定し、スポット価格に移行（60〜90%の節約）。アーキテクチャの最適化：無駄を特定して排除 — 未使用リソース、過剰レプリケートされたデータ、誰も読まない高価なログ、夜間や週末にシャットダウンできる24時間稼働の開発環境。各施策を予測される節約額、実装工数、信頼性リスクとともに提示します。制約は明確です：信頼性は交渉の余地がありません。コスト削減は冗長性の除去やサービス品質の劣化ではなく、効率化から生まれます。」

面接官への質問

1. このチームが管理するサービスのSLOは何ですか？エラーバジェットはどのように管理されていますか？ チームがSREの原則を実践しているか、単にタイトルを使っているかが分かります。

2. オンコールローテーションはどのようになっていますか — エンジニアの人数、ページの量、エスカレーションポリシーは？ QoLに直接影響し、チームの運用健全性を示します。

3. チームはプロジェクト作業（信頼性改善）と運用作業（インシデント対応、トイル）のバランスをどのように取っていますか？ チームがエンジニアリング作業のキャパシティを持っているか、消火活動モードに陥っているかが分かります。

4. チームと開発チームの関係はどうですか — SREは埋め込み型ですか、集中型ですか？ 日々のコラボレーションモデルと影響力が決まります。

5. チームのポストモーテムへのアプローチは — ブレームレスですか？アクションアイテムの何パーセントが完了されていますか？ チームのインシデント学習文化が分かります — ポストモーテムを書いてもアクションアイテムを完了しないチームには文化的な問題があります。

6. チームはどのようなインフラとツーリングを管理していますか — クラウドプロバイダー、コンテナオーケストレーション、オブザーバビリティスタック？ 技術環境についての実践的な質問です。

7. チームが現在直面している最大の信頼性課題は何ですか？ 解決すべき問題とそれが興味深いかどうかの洞察が得られます。

面接の形式と何を期待すべきか

主要テクノロジー企業でのSRE面接は通常、フルループで4〜6時間にわたります [3]。コーディングラウンドでは、自動化、データ処理、システムツーリングに焦点を当てた問題でPython/Go/Javaの習熟度がテストされます — 純粋なLeetCodeではなく「エラーパターンを特定するログパーサーを書く」といった問題が期待されます。システム設計ラウンドでは、明示的な信頼性制約を持つ分散システムの設計を求められます — 「99.99%のリクエストを100ms以内に提供するURLショートナーを設計してください。」トラブルシューティングラウンドでは、プロダクションシナリオ（サービス劣化、カスケード障害、不可解なアラート）が提示され、診断方法論が評価されます。行動ラウンドでは、オンコール経験、インシデント管理、チーム間コラボレーション、トイル削減が評価されます。一部の企業はLinux/ネットワーク基礎ラウンドを追加し、プロセス管理、ファイルシステム操作、TCP/IP、DNS解決などのトピックをカバーします。リクルータースクリーニングからオファーまでのプロセス全体は通常3〜6週間かかります。

準備方法

• Google SREブックを学習してください。 SLO、エラーバジェット、トイル、インシデント管理に関する章は基礎的であり、面接で頻繁に参照されます [2]。
• 信頼性制約を伴うシステム設計を練習してください。 明示的な可用性目標、障害モード、グレースフルデグラデーション戦略を持つシステムを設計します。
• インシデントストーリーを準備してください。 あなたの役割、タイムライン、根本原因、解決策、システム改善を含む3〜5の詳細なインシデントナラティブを用意してください。
• Linuxの基礎を復習してください。 プロセス管理、ファイルシステム操作、ネットワークコマンド（ss, tcpdump, dig, traceroute）、システムパフォーマンスツール（top, vmstat, iostat, sar）。
• 自動化のためのコーディングを練習してください。 ログを解析し、APIと対話し、インフラ状態を管理し、障害ケースをグレースフルに処理するスクリプトを書いてください。
• オブザーバビリティスタックを把握してください。 Prometheus、Grafana、Jaeger/Tempo、ELK/Loki、PagerDutyについて、プロダクションでの使用経験を含めて議論できる準備をしてください。

よくある面接ミス

1. 障害を想定せずにスケールのための設計をすること。 SRE面接はシステムが障害をどのように処理するかを特にテストします — 「すべてが動作する前提」のシステムを説明することはレッドフラグです [2]。
2. 信頼性を定量化しないこと。 「システムは高可用性であるべき」と言う代わりに「システムはリクエスト成功率で測定された99.95%可用性SLOを満たすべき」と言えないことは、SREの原則を内面化していないことを示します。
3. インシデントを純粋に技術的な問題として扱うこと。 インシデントストーリーでコミュニケーション、調整、ポストモーテムプロセスを議論しないことは、インシデント管理経験の欠如を示唆します。
4. トイルを無視すること。 SRE面接ではトイル削減についてよく質問されます。自動化した手動運用作業の例がないことはギャップです。
5. ソリューションをオーバーエンジニアリングすること。 非クリティカルなサービスにファイブナインアーキテクチャを提案することは、判断力の欠如を示します。SREは最大の信頼性ではなく、適切な信頼性に関するものです [2]。
6. エラーバジェットモデルを理解していないこと。 エラーバジェットがSREとプロダクトチーム間のアライメントをどのように生み出すか説明できなければ、SREフレームワークを学んでいません。
7. コーディング能力を示せないこと。 SREはオペレーターではなくエンジニアです。コーディング問題に苦戦することは、役割を定義する自動化とツーリングを構築できない可能性を示します [3]。

重要なポイント

• SRE面接は特定のエンジニアリングマインドセットをテストします：信頼性の定量化、データ駆動のトレードオフ、運用をソフトウェアエンジニアリングの問題として扱うこと。
• SLO、SLI、エラーバジェット、トイルはSREの語彙です — それぞれについて流暢に使用し、実践的な経験を示してください。
• 診断方法論、コミュニケーションスキル、システム的改善思考を示す詳細なインシデントストーリーを準備してください。
• システム設計の回答には、明示的な障害モード、グレースフルデグラデーション戦略、可用性目標を含める必要があります。

履歴書が面接まであなたを導くことを確認したいですか？ResumeGeniの無料ATSスコアチェッカーをお試しいただき、応募前にSite Reliability Engineerの履歴書を最適化してください。

FAQ

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

SREは、処方的なプラクティスを伴うDevOps原則の具体的な実装です：SLO、エラーバジェット、トイルバジェット、および開発チームとの定義されたエンゲージメントモデル。DevOpsは、開発と運用間のコラボレーションを強調する、より広い文化的運動です。SREは、DevOps原則を実行可能にする具体的なフレームワーク — SLO、エラーバジェット、50%エンジニアリング時間ルール — を提供します。多くの企業がこれらの用語を互換的に使用していますが、SREを正式に実践している企業（Google、LinkedIn、Dropbox）の面接では、その区別が重要です [2]。

SRE面接にはどのプログラミング言語を知っておくべきですか？

PythonとGoがSREで最も一般的に使用されている言語です。Pythonはスクリプティング、自動化、運用ツーリングに。Goはパフォーマンスクリティカルなシステムツーリングに（Kubernetesエコシステムの多くのツール、Prometheus、内部インフラツールはGoで書かれています）。一部の企業はJavaやRubyを使用します。少なくとも1つのコンパイル言語と1つのスクリプト言語に習熟している必要があります [3]。

Site Reliability Engineerとしてどのくらいの年収を期待すべきですか？

年収は128,842ドル（PayScale平均）から169,680ドル（Glassdoor平均）の範囲で、75パーセンタイルは213,272ドルです [1]。FAANG企業のシニアSREは株式報酬を含めて300,000〜500,000ドル以上を得ることができます。報酬は企業のティア、勤務地、専門分野によって異なります。SREは通常、同じ企業の一般的なソフトウェアエンジニアリング職に対して10〜20%のプレミアムを獲得します。

Google SREブックは面接準備にどれほど重要ですか？

非常に重要です。Google SREブック（「Site Reliability Engineering: How Google Runs Production Systems」）は、ほとんどのSRE面接でテストされる概念を定義しています：SLO、エラーバジェット、トイル、インシデント管理、SREエンゲージメントモデル [2]。Googleの正確なプラクティスに従わない企業で面接を受ける場合でも、この本は面接官が使用する語彙とフレームワークを提供します。

SRE職を得るためにオンコール経験は必要ですか？

オンコール経験は強く好まれますが、エントリーレベルのSRE職では必ずしも必須ではありません。正式なオンコール経験がない場合は、同等のスキルを示してください：構築したモニタリングシステム、対応したインシデント（ステージングや開発環境でも）、手動操作を削減するために作成した自動化。プロダクションシステムの運用の現実を理解していることを示してください。

SRE面接に役立つ資格は何ですか？

Google Cloud Professional Cloud DevOps Engineer、AWS DevOps Engineer Professional、Certified Kubernetes Administrator (CKA) が最も関連性の高い資格です。ただし、トップ企業でのSRE面接は、資格よりも実践的な経験と問題解決能力をはるかに重視します。資格は履歴書スクリーニングを通過するのに役立ちますが、技術面接を乗り切ることはできません。

SRE面接はソフトウェアエンジニアリング面接とどう違いますか？

SRE面接には、明示的な信頼性制約を伴うシステム設計（SLO、障害モード、グレースフルデグラデーション）、トラブルシューティングラウンド（プロダクションシナリオの診断）、インシデント管理とオンコール経験に関する行動質問が含まれます。ソフトウェアエンジニアリング面接は、アルゴリズムコーディング、アプリケーションレベルのシステム設計、プロダクト思考により焦点を当てています。SREのコーディング問題は、純粋なアルゴリズム問題よりも実践的で自動化指向の傾向があります [3]。

出典： [1] Glassdoor, "Site Reliability Engineer: Average Salary & Pay Trends 2026," https://www.glassdoor.com/Salaries/site-reliability-engineer-salary-SRCH_KO0,25.htm [2] Google, "Site Reliability Engineering: How Google Runs Production Systems," https://sre.google/sre-book/table-of-contents/ [3] InterviewBit, "SRE (Site Reliability Engineer) Interview Questions (2025)," https://www.interviewbit.com/sre-interview-questions/ [4] Exponent, "Site Reliability Engineer Interview Questions Explained (Updated 2026)," https://www.tryexponent.com/questions?role=sre [5] Wiz, "Site Reliability Engineer Interview Questions Explained," https://www.wiz.io/academy/cloud-careers/site-reliability-engineer-interview-questions [6] NovelVista, "50 Site Reliability Engineer (SRE) Interview Questions 2026," https://www.novelvista.com/blogs/devops/top-sre-interview-question-answer [7] MindMajix, "Top 50 Site Reliability Engineer (SRE) Interview Questions 2025," https://mindmajix.com/sre-interview-questions [8] Coursera, "Site Reliability Engineer Salary Guide 2026," https://www.coursera.org/articles/site-reliability-engineer-salary