ミドルDevOps / SRE面接質問

ミドルDevOps / SRE面接の重点、よく出る質問、そして即時AIフィードバックでの練習方法。

無料のAI模擬面接を受ける

ミドルレベルで求められること

CI/CD、Kubernetes、可観測性、自立したオンコール運用が問われます。

ジュニアシニア

DevOps / SREの面接質問サンプル

技術面接あるサービスが遅いです。OSレベルから順にどうデバッグするか説明してください。
良い回答が押さえる点
- Load averageとCPU使用率の確認 (top, uptime)
- メモリ使用量とスワップの確認 (free, vmstat)
- ディスクI/Oの確認 (iostat, iotop)
- ネットワークの確認 (netstat, ss, sar)
- プロセスレベルでの分析 (strace, perf, コンテキストスイッチ)
サンプル回答を見る
サービスが遅い場合、OSレベルから段階的にデバッグします。まず、topやuptimeでロードアベレージを確認し、CPU使用率が高いか、I/O待ちが多いかを大まかに把握します。次に、freeやvmstatでメモリ使用量、スワップの発生を確認します。スワップが頻繁に発生している場合はメモリ不足の可能性があります。続いて、iostatでディスクI/Oの待ち時間やスループットを確認し、ストレージがボトルネックになっていないか調べます。ネットワークに関しては、netstatやssでコネクションの状態や再送率を確認し、必要に応じてtcpdumpでパケットキャプチャを行います。OS全体の傾向を把握した後、対象プロセスを特定し、straceでシステムコールのトレースや、perfでCPUプロファイリングを実施します。特に、コンテキストスイッチの多発やロック競合がないかを確認します。VMやコンテナ環境では、ハイパーバイザーやコンテナランタイムのメトリクスも確認します。最後に、アプリケーションログと組み合わせて原因を特定します。よくある失敗は、最初からアプリケーションレベルに飛び込むことです。OSのリソース使用傾向を先に把握することで、問題の切り分けが容易になります。
技術面接URLを入力してEnterを押すと、段階的に何が起こりますか？
良い回答が押さえる点
- DNS解決のキャッシュと再帰的解決
- TCP 3ウェイハンドシェイクとTLSハンドシェイク
- HTTPリクエスト送信とサーバー処理
- HTML解析とサブリソース取得（CSS, JS, 画像）
- レンダリングとイベント処理
サンプル回答を見る
URLを入力してEnterを押すと、段階的に処理が進みます。まず、ブラウザがURLを解析し、ホスト名のDNS解決を行います。ブラウザやOSのDNSキャッシュを確認し、なければ再帰的にDNSサーバーに問い合わせてIPアドレスを取得します。次に、ブラウザはTCPの3ウェイハンドシェイク（SYN, SYN-ACK, ACK）でサーバーとの接続を確立します。HTTPSの場合は、TLSハンドシェイクが追加され、証明書の検証と暗号鍵の交換が行われます。接続が確立すると、HTTPリクエスト（GET等）を送信します。HTTP/1.1の場合はコネクション再利用、HTTP/2の場合は多重化が行われます。サーバーはリクエストを処理し、HTTPレスポンス（ステータスコード、ヘッダー、ボディ）を返します。ブラウザはレスポンスのHTMLを解析（パース）し、レンダリングツリーを構築します。その過程で、CSS、JavaScript、画像などのサブリソースが必要になり、再度同様のプロセスで取得します。最終的に、ページが画面に表示され、ユーザーとのインタラクションが可能になります。よくある遅延の原因は、DNS解決の遅延やTLSネゴシエーションのオーバーヘッド、サブリソースの大量取得などです。
技術面接Kubernetesのlivenessプローブとreadinessプローブはどう違いますか？
良い回答が押さえる点
- livenessプローブ：コンテナの再起動をトリガー
- readinessプローブ：トラフィックルーティングの制御
- 失敗時の挙動の違い（再起動 vs サービス除外）
- 起動時やシャットダウン時の考慮事項
- プローブの実装方法（HTTP, TCP, コマンド）
サンプル回答を見る
Kubernetesのlivenessプローブとreadinessプローブは、どちらもコンテナのヘルスチェックに使われますが、目的と動作が異なります。livenessプローブは、コンテナが生きているか（正常に動作しているか）を確認し、失敗するとkubeletがコンテナを再起動します。アプリケーションがデッドロックや無限ループで応答不能になった場合に回復させるためです。一方、readinessプローブは、コンテナがトラフィックを受け付けられる状態かを確認し、失敗するとそのPodをServiceのエンドポイントから除外します。これにより、ロードバランサーからリクエストが送られなくなりますが、コンテナ自体は再起動されません。readinessプローブは、アプリケーションの起動中や、シャットダウン時のGraceful Shutdownに使われることが多いです。例えば、起動時に初期化が完了するまでreadinessを失敗させ、トラフィックを流さないようにします。また、シャットダウン時にreadinessを失敗させてから終了することで、トラフィックを停止してから安全に停止できます。よくある間違いは、両方のプローブを同じチェックにすることです。それぞれの役割を理解し、適切に設定する必要があります。

コーディングログを解析し、上位のエラー率を報告するスクリプトを書いてください。

良い回答が押さえる点

JSONログのパース方法
エラーログのフィルタリングと集計
時間範囲やエラーレベルの考慮
トップNのエラー率計算
出力形式の標準化（例：CSV、テーブル）

サンプル回答を見る

ログファイルを解析し、エラーレートが高い上位のエラーメッセージを報告するPythonスクリプトを作成します。以下のコードでは、JSON形式のログを読み込み、エラーレベルがERROR以上のものを抽出し、エラーメッセージごとにカウントして、全体のログ数に対する割合を計算します。出力はエラーレートの降順で表示します。

参考コードpython

#!/usr/bin/env python3
"""
ログファイルを解析し、エラー率の高い上位メッセージを報告する。
ログ形式: 1行1JSON、{"timestamp": "...", "level": "...", "message": "..."}
使用法: python log_parser.py <ログファイル>
"""

import sys
import json
from collections import defaultdict

def parse_logs(filepath):
    error_counts = defaultdict(int)
    total_lines = 0
    with open(filepath, 'r') as f:
        for line in f:
            line = line.strip()
            if not line:
                continue
            total_lines += 1
            try:
                record = json.loads(line)
            except json.JSONDecodeError:
                # JSONパースエラーは無視（または警告）
                continue
            # エラーレベルがERROR以上（WARNINGは含まない）
            level = record.get('level', '').upper()
            if level in ('ERROR', 'CRITICAL', 'FATAL'):
                msg = record.get('message', 'unknown')
                error_counts[msg] += 1
    if total_lines == 0:
        print("ログが空です")
        return
    # エラーメッセージごとにエラー率を計算
    error_rate_list = []
    for msg, count in error_counts.items():
        rate = count / total_lines * 100
        error_rate_list.append((rate, count, msg))
    # エラー率降順でソート
    error_rate_list.sort(reverse=True)
    # 上位10件を表示
    print(f"総ログ行数: {total_lines}")
    print(f"エラーメッセージの種類数: {len(error_rate_list)}")
    print("\n上位エラー率（エラー率, 発生回数, メッセージ）:")
    for rate, count, msg in error_rate_list[:10]:
        print(f"{rate:.2f}% ({count}回) - {msg[:80]}")

if __name__ == '__main__':
    if len(sys.argv) != 2:
        print("使用法: python log_parser.py <ログファイル>")
        sys.exit(1)
    parse_logs(sys.argv[1])

# 時間計算量: O(N * M) ここでNはログ行数、Mはエラーメッセージの種類（辞書操作は平均O(1)）
# 空間計算量: O(M) エラーメッセージの種類数分の辞書とリスト

システム設計安全で段階的な本番ロールアウトを備えたCI/CDパイプラインを設計してください。
良い回答が押さえる点
- パイプラインのステージ構成（ビルド、テスト、デプロイ）
- 安全なロールアウト戦略（カナリア、ブルーグリーン）
- 自動化されたヘルスチェックとロールバック条件
- 環境分離（開発、ステージング、本番）
- 承認ゲートと監査ログ
サンプル回答を見る
安全で段階的な本番ロールアウトを備えたCI/CDパイプラインを設計します。パイプラインは以下のステージで構成されます。まず、コードの変更がプッシュされると、自動的にビルドと単体テストが実行されます。次に、静的解析とセキュリティスキャンを実施します。これらが成功すると、ステージング環境にデプロイされ、統合テストとパフォーマンステストが実行されます。本番ロールアウトは段階的に行います。例えば、カナリーデプロイ戦略を採用し、最初はトラフィックの5%を新しいバージョンにルーティングします。ヘルスチェック（エラーレート、レイテンシ）を監視し、閾値を超えた場合は自動的にロールバックします。段階を徐々に増やし（25%、50%、100%）、各段階で自動承認または手動承認を挟みます。100%ロールアウト後も、しばらく監視を継続し、問題があればロールバックします。ロールバックは、前のバージョンへの切り替えを自動化しておきます。また、全てのデプロイはイミュータブルなアーティファクト（コンテナイメージ等）を使用し、デプロイ履歴と承認記録を監査可能にします。よくある欠点は、ロールバック条件が不十分で、障害に気づくのが遅れることです。メトリクスとアラートを適切に設定し、自動ロールバックを実装することが重要です。
システム設計マルチリージョンサービスの監視とアラートを設計してください。
良い回答が押さえる点
- 指標の種類（レイテンシ、エラーレート、トラフィック、リソース使用率）
- 分散トレーシングとログ集約の統一
- リージョン間のレイテンシと可用性の監視
- アラートの設定（閾値、異常検知、オンボーディング）
- エスカレーションポリシーとオンコール体制
サンプル回答を見る
マルチリージョンサービスの監視とアラートを設計します。まず、各リージョンごとに主要なメトリクス（レイテンシ、エラーレート、リクエスト数、リソース使用率）を収集します。これらのメトリクスを統合ダッシュボードで可視化し、リージョン間の比較を容易にします。分散トレーシングシステム（例：Jaeger）を導入し、リージョンを跨ぐリクエストのパフォーマンスを追跡します。ログは集中管理し（例：Elasticsearch）、障害時の原因特定を迅速に行えるようにします。アラートは、各リージョンのメトリクスに対して個別に閾値を設定し、異常検知アルゴリズム（例：標準偏差からの乖離）も併用します。特に、リージョン間のレイテンシ差が大きくなった場合や、特定リージョンのエラーレートが急上昇した場合にアラートを発報します。また、リージョン全体のダウンを検知するために、死活監（ヘルスチェック）を他のリージョンから定期的に実行します。アラートは、重要度に応じて通知先を変え（PagerDuty, Slack）、エスカレーションポリシーを定義します。よくある失敗は、リージョンごとに独立した監視を行い、全体の状態が見えにくくなることです。統一されたビューと、リージョン間の依存関係を理解することが重要です。
行動面接主導したインシデントとポストモーテムでの対応について教えてください。
良い回答が押さえる点
- インシデント発見と初期トリアージ
- エスカレーションとコミュニケーションチャネルの確立
- 復旧作業の優先順位付けと実行
- ポストモーテムの作成と5 Whys分析
- 改善アクションの追跡と予防策の導入
サンプル回答を見る
私が主導したインシデントの例として、データベースのクエリパフォーマンス低下によるサービス障害があります。状況：アラートによりレイテンシが急上昇したことを検知し、即座にオンコール対応を開始しました。トリアージでは、問題が特定のDBインスタンスに集中していることを特定し、スロークエリログを分析した結果、インデックス不足のクエリが原因と判明しました。初期対応として、クエリを一時的にキャッシュする回避策を導入し、サービスを復旧させました。その後、恒久対策としてインデックスを追加し、ステージングで検証後本番適用しました。ポストモーテムでは、5 Whys分析を用いて根本原因を調査し、インデックス設計のレビュープロセスが欠けていたことが判明しました。改善アクションとして、コードレビューにパフォーマンスチェックリストを追加し、自動SQL解析ツールを導入しました。この経験から、インシデント対応では迅速なトリアージとコミュニケーションが重要であり、ポストモーテムを真摯に行うことで組織の信頼性が向上することを学びました。
行動面接信頼性の作業と機能リクエストをどうバランスしますか？
良い回答が押さえる点
- エラーバジェットの概念と活用
- 機能リクエストの優先順位付け（価値 vs 信頼性への影響）
- 信頼性作業のROIの定量化
- ステークホルダーとの合意形成
- 週次のバランス見直しとチームの自律性
サンプル回答を見る
信頼性の作業と機能リクエストのバランスは、エラーバジェットを用いて管理します。まず、サービスのSLO（目標稼働時間）を定義し、その残りをエラーバジェットとして可視化します。バジェットが十分な間は機能開発を優先し、残りが少なくなったら信頼性作業にリソースをシフトします。機能リクエストは、その価値だけでなく、信頼性への影響（リスク）も評価して優先順位を決めます。具体的には、各機能がシステムの複雑性を増すか、障害のリスクを高めるかをチームで議論し、必要に応じて信頼性作業を事前に組み込みます。また、信頼性作業のROIを定量化し、ダウンタイムのコストと比較してステークホルダーに説明します。週次のミーティングでバランスを見直し、チームの負荷と優先順位を調整します。よくある問題は、機能開発に偏りすぎてエラーバジェットを使い果たすことです。その場合は、機能凍結期間を設けて信頼性改善に集中します。最終的には、チームが自律的にバランスを判断できる文化を育てることが重要です。

面接官が評価するポイント

Linuxとネットワーク

プロセス、ファイルシステム、DNS、TCP/IP、デバッグツール。

CI/CDとIaC

パイプライン、Terraform、再現可能で自動化されたデプロイ。

コンテナとオーケストレーション

Docker、Kubernetesのスケジューリング、ネットワーク、スケーリング。

可観測性

メトリクス、ログ、トレース、SLO、意味のあるアラート。

信頼性

インシデント対応、非難なきポストモーテム、キャパシティプランニング。

準備の進め方

第一原理からデバッグしましょう — 面接官は体系的で階層的なアプローチを求めます。
回答をSLO、エラーバジェット、非難なきポストモーテムを軸に組み立てましょう。
回答の中であらゆることを自動化しましょう。手動の手順は危険信号と読み取られます。

よくある質問

DevOps/SRE面接にはどんなコーディングが含まれますか？

通常はスクリプティング（ログ解析、自動化）で、時にデータ構造の問題も。加えて多くのトラブルシューティングとシステム設計があります。

SRE面接でKubernetesはどれくらい重要ですか？

ミドルおよびシニアレベルで非常に一般的です — スケジューリング、ネットワーク、プローブ、スケーリングに関する質問が出ます。

SRE面接にどう備えますか？

階層的なトラブルシューティングを練習し、SLOやインシデント対応などの信頼性概念を復習し、模擬面接でシナリオをリハーサルしましょう。

DevOps / SREの質問をAIの即時フィードバックで練習

Offerslyはあなたの履歴書と希望職種に合わせた模擬面接を実施し、すべての回答を関連性・深さ・明確さ・正確さで採点します。

無料で始める DevOps / SRE面接質問の一覧

DevOps / SREの面接質問サンプル

技術面接あるサービスが遅いです。OSレベルから順にどうデバッグするか説明してください。

良い回答が押さえる点

Load averageとCPU使用率の確認 (top, uptime)
メモリ使用量とスワップの確認 (free, vmstat)
ディスクI/Oの確認 (iostat, iotop)
ネットワークの確認 (netstat, ss, sar)
プロセスレベルでの分析 (strace, perf, コンテキストスイッチ)

サンプル回答を見る

サービスが遅い場合、OSレベルから段階的にデバッグします。まず、topやuptimeでロードアベレージを確認し、CPU使用率が高いか、I/O待ちが多いかを大まかに把握します。次に、freeやvmstatでメモリ使用量、スワップの発生を確認します。スワップが頻繁に発生している場合はメモリ不足の可能性があります。続いて、iostatでディスクI/Oの待ち時間やスループットを確認し、ストレージがボトルネックになっていないか調べます。ネットワークに関しては、netstatやssでコネクションの状態や再送率を確認し、必要に応じてtcpdumpでパケットキャプチャを行います。OS全体の傾向を把握した後、対象プロセスを特定し、straceでシステムコールのトレースや、perfでCPUプロファイリングを実施します。特に、コンテキストスイッチの多発やロック競合がないかを確認します。VMやコンテナ環境では、ハイパーバイザーやコンテナランタイムのメトリクスも確認します。最後に、アプリケーションログと組み合わせて原因を特定します。よくある失敗は、最初からアプリケーションレベルに飛び込むことです。OSのリソース使用傾向を先に把握することで、問題の切り分けが容易になります。

技術面接URLを入力してEnterを押すと、段階的に何が起こりますか？

良い回答が押さえる点

DNS解決のキャッシュと再帰的解決
TCP 3ウェイハンドシェイクとTLSハンドシェイク
HTTPリクエスト送信とサーバー処理
HTML解析とサブリソース取得（CSS, JS, 画像）
レンダリングとイベント処理

サンプル回答を見る

URLを入力してEnterを押すと、段階的に処理が進みます。まず、ブラウザがURLを解析し、ホスト名のDNS解決を行います。ブラウザやOSのDNSキャッシュを確認し、なければ再帰的にDNSサーバーに問い合わせてIPアドレスを取得します。次に、ブラウザはTCPの3ウェイハンドシェイク（SYN, SYN-ACK, ACK）でサーバーとの接続を確立します。HTTPSの場合は、TLSハンドシェイクが追加され、証明書の検証と暗号鍵の交換が行われます。接続が確立すると、HTTPリクエスト（GET等）を送信します。HTTP/1.1の場合はコネクション再利用、HTTP/2の場合は多重化が行われます。サーバーはリクエストを処理し、HTTPレスポンス（ステータスコード、ヘッダー、ボディ）を返します。ブラウザはレスポンスのHTMLを解析（パース）し、レンダリングツリーを構築します。その過程で、CSS、JavaScript、画像などのサブリソースが必要になり、再度同様のプロセスで取得します。最終的に、ページが画面に表示され、ユーザーとのインタラクションが可能になります。よくある遅延の原因は、DNS解決の遅延やTLSネゴシエーションのオーバーヘッド、サブリソースの大量取得などです。

技術面接Kubernetesのlivenessプローブとreadinessプローブはどう違いますか？

良い回答が押さえる点

livenessプローブ：コンテナの再起動をトリガー
readinessプローブ：トラフィックルーティングの制御
失敗時の挙動の違い（再起動 vs サービス除外）
起動時やシャットダウン時の考慮事項
プローブの実装方法（HTTP, TCP, コマンド）

サンプル回答を見る

Kubernetesのlivenessプローブとreadinessプローブは、どちらもコンテナのヘルスチェックに使われますが、目的と動作が異なります。livenessプローブは、コンテナが生きているか（正常に動作しているか）を確認し、失敗するとkubeletがコンテナを再起動します。アプリケーションがデッドロックや無限ループで応答不能になった場合に回復させるためです。一方、readinessプローブは、コンテナがトラフィックを受け付けられる状態かを確認し、失敗するとそのPodをServiceのエンドポイントから除外します。これにより、ロードバランサーからリクエストが送られなくなりますが、コンテナ自体は再起動されません。readinessプローブは、アプリケーションの起動中や、シャットダウン時のGraceful Shutdownに使われることが多いです。例えば、起動時に初期化が完了するまでreadinessを失敗させ、トラフィックを流さないようにします。また、シャットダウン時にreadinessを失敗させてから終了することで、トラフィックを停止してから安全に停止できます。よくある間違いは、両方のプローブを同じチェックにすることです。それぞれの役割を理解し、適切に設定する必要があります。

コーディングログを解析し、上位のエラー率を報告するスクリプトを書いてください。

良い回答が押さえる点

JSONログのパース方法
エラーログのフィルタリングと集計
時間範囲やエラーレベルの考慮
トップNのエラー率計算
出力形式の標準化（例：CSV、テーブル）

サンプル回答を見る

参考コードpython

#!/usr/bin/env python3
"""
ログファイルを解析し、エラー率の高い上位メッセージを報告する。
ログ形式: 1行1JSON、{"timestamp": "...", "level": "...", "message": "..."}
使用法: python log_parser.py <ログファイル>
"""

import sys
import json
from collections import defaultdict

def parse_logs(filepath):
    error_counts = defaultdict(int)
    total_lines = 0
    with open(filepath, 'r') as f:
        for line in f:
            line = line.strip()
            if not line:
                continue
            total_lines += 1
            try:
                record = json.loads(line)
            except json.JSONDecodeError:
                # JSONパースエラーは無視（または警告）
                continue
            # エラーレベルがERROR以上（WARNINGは含まない）
            level = record.get('level', '').upper()
            if level in ('ERROR', 'CRITICAL', 'FATAL'):
                msg = record.get('message', 'unknown')
                error_counts[msg] += 1
    if total_lines == 0:
        print("ログが空です")
        return
    # エラーメッセージごとにエラー率を計算
    error_rate_list = []
    for msg, count in error_counts.items():
        rate = count / total_lines * 100
        error_rate_list.append((rate, count, msg))
    # エラー率降順でソート
    error_rate_list.sort(reverse=True)
    # 上位10件を表示
    print(f"総ログ行数: {total_lines}")
    print(f"エラーメッセージの種類数: {len(error_rate_list)}")
    print("\n上位エラー率（エラー率, 発生回数, メッセージ）:")
    for rate, count, msg in error_rate_list[:10]:
        print(f"{rate:.2f}% ({count}回) - {msg[:80]}")

if __name__ == '__main__':
    if len(sys.argv) != 2:
        print("使用法: python log_parser.py <ログファイル>")
        sys.exit(1)
    parse_logs(sys.argv[1])

# 時間計算量: O(N * M) ここでNはログ行数、Mはエラーメッセージの種類（辞書操作は平均O(1)）
# 空間計算量: O(M) エラーメッセージの種類数分の辞書とリスト

システム設計安全で段階的な本番ロールアウトを備えたCI/CDパイプラインを設計してください。

良い回答が押さえる点

パイプラインのステージ構成（ビルド、テスト、デプロイ）
安全なロールアウト戦略（カナリア、ブルーグリーン）
自動化されたヘルスチェックとロールバック条件
環境分離（開発、ステージング、本番）
承認ゲートと監査ログ

サンプル回答を見る

安全で段階的な本番ロールアウトを備えたCI/CDパイプラインを設計します。パイプラインは以下のステージで構成されます。まず、コードの変更がプッシュされると、自動的にビルドと単体テストが実行されます。次に、静的解析とセキュリティスキャンを実施します。これらが成功すると、ステージング環境にデプロイされ、統合テストとパフォーマンステストが実行されます。本番ロールアウトは段階的に行います。例えば、カナリーデプロイ戦略を採用し、最初はトラフィックの5%を新しいバージョンにルーティングします。ヘルスチェック（エラーレート、レイテンシ）を監視し、閾値を超えた場合は自動的にロールバックします。段階を徐々に増やし（25%、50%、100%）、各段階で自動承認または手動承認を挟みます。100%ロールアウト後も、しばらく監視を継続し、問題があればロールバックします。ロールバックは、前のバージョンへの切り替えを自動化しておきます。また、全てのデプロイはイミュータブルなアーティファクト（コンテナイメージ等）を使用し、デプロイ履歴と承認記録を監査可能にします。よくある欠点は、ロールバック条件が不十分で、障害に気づくのが遅れることです。メトリクスとアラートを適切に設定し、自動ロールバックを実装することが重要です。

システム設計マルチリージョンサービスの監視とアラートを設計してください。

良い回答が押さえる点

指標の種類（レイテンシ、エラーレート、トラフィック、リソース使用率）
分散トレーシングとログ集約の統一
リージョン間のレイテンシと可用性の監視
アラートの設定（閾値、異常検知、オンボーディング）
エスカレーションポリシーとオンコール体制

サンプル回答を見る

マルチリージョンサービスの監視とアラートを設計します。まず、各リージョンごとに主要なメトリクス（レイテンシ、エラーレート、リクエスト数、リソース使用率）を収集します。これらのメトリクスを統合ダッシュボードで可視化し、リージョン間の比較を容易にします。分散トレーシングシステム（例：Jaeger）を導入し、リージョンを跨ぐリクエストのパフォーマンスを追跡します。ログは集中管理し（例：Elasticsearch）、障害時の原因特定を迅速に行えるようにします。アラートは、各リージョンのメトリクスに対して個別に閾値を設定し、異常検知アルゴリズム（例：標準偏差からの乖離）も併用します。特に、リージョン間のレイテンシ差が大きくなった場合や、特定リージョンのエラーレートが急上昇した場合にアラートを発報します。また、リージョン全体のダウンを検知するために、死活監（ヘルスチェック）を他のリージョンから定期的に実行します。アラートは、重要度に応じて通知先を変え（PagerDuty, Slack）、エスカレーションポリシーを定義します。よくある失敗は、リージョンごとに独立した監視を行い、全体の状態が見えにくくなることです。統一されたビューと、リージョン間の依存関係を理解することが重要です。

行動面接主導したインシデントとポストモーテムでの対応について教えてください。

良い回答が押さえる点

インシデント発見と初期トリアージ
エスカレーションとコミュニケーションチャネルの確立
復旧作業の優先順位付けと実行
ポストモーテムの作成と5 Whys分析
改善アクションの追跡と予防策の導入

サンプル回答を見る

私が主導したインシデントの例として、データベースのクエリパフォーマンス低下によるサービス障害があります。状況：アラートによりレイテンシが急上昇したことを検知し、即座にオンコール対応を開始しました。トリアージでは、問題が特定のDBインスタンスに集中していることを特定し、スロークエリログを分析した結果、インデックス不足のクエリが原因と判明しました。初期対応として、クエリを一時的にキャッシュする回避策を導入し、サービスを復旧させました。その後、恒久対策としてインデックスを追加し、ステージングで検証後本番適用しました。ポストモーテムでは、5 Whys分析を用いて根本原因を調査し、インデックス設計のレビュープロセスが欠けていたことが判明しました。改善アクションとして、コードレビューにパフォーマンスチェックリストを追加し、自動SQL解析ツールを導入しました。この経験から、インシデント対応では迅速なトリアージとコミュニケーションが重要であり、ポストモーテムを真摯に行うことで組織の信頼性が向上することを学びました。

行動面接信頼性の作業と機能リクエストをどうバランスしますか？

良い回答が押さえる点

エラーバジェットの概念と活用
機能リクエストの優先順位付け（価値 vs 信頼性への影響）
信頼性作業のROIの定量化
ステークホルダーとの合意形成
週次のバランス見直しとチームの自律性

サンプル回答を見る

信頼性の作業と機能リクエストのバランスは、エラーバジェットを用いて管理します。まず、サービスのSLO（目標稼働時間）を定義し、その残りをエラーバジェットとして可視化します。バジェットが十分な間は機能開発を優先し、残りが少なくなったら信頼性作業にリソースをシフトします。機能リクエストは、その価値だけでなく、信頼性への影響（リスク）も評価して優先順位を決めます。具体的には、各機能がシステムの複雑性を増すか、障害のリスクを高めるかをチームで議論し、必要に応じて信頼性作業を事前に組み込みます。また、信頼性作業のROIを定量化し、ダウンタイムのコストと比較してステークホルダーに説明します。週次のミーティングでバランスを見直し、チームの負荷と優先順位を調整します。よくある問題は、機能開発に偏りすぎてエラーバジェットを使い果たすことです。その場合は、機能凍結期間を設けて信頼性改善に集中します。最終的には、チームが自律的にバランスを判断できる文化を育てることが重要です。

面接官が評価するポイント

Linuxとネットワーク

プロセス、ファイルシステム、DNS、TCP/IP、デバッグツール。

CI/CDとIaC

パイプライン、Terraform、再現可能で自動化されたデプロイ。

コンテナとオーケストレーション

Docker、Kubernetesのスケジューリング、ネットワーク、スケーリング。

可観測性

メトリクス、ログ、トレース、SLO、意味のあるアラート。

信頼性

インシデント対応、非難なきポストモーテム、キャパシティプランニング。

準備の進め方

第一原理からデバッグしましょう — 面接官は体系的で階層的なアプローチを求めます。

回答をSLO、エラーバジェット、非難なきポストモーテムを軸に組み立てましょう。

回答の中であらゆることを自動化しましょう。手動の手順は危険信号と読み取られます。

よくある質問

DevOps/SRE面接にはどんなコーディングが含まれますか？

通常はスクリプティング（ログ解析、自動化）で、時にデータ構造の問題も。加えて多くのトラブルシューティングとシステム設計があります。

SRE面接でKubernetesはどれくらい重要ですか？

ミドルおよびシニアレベルで非常に一般的です — スケジューリング、ネットワーク、プローブ、スケーリングに関する質問が出ます。

SRE面接にどう備えますか？

階層的なトラブルシューティングを練習し、SLOやインシデント対応などの信頼性概念を復習し、模擬面接でシナリオをリハーサルしましょう。