DevOps Engineer Test: Example Questions & Assessment Template

ジェネリックなインフラ質問が失敗する理由

ほとんどのDevOps評価は教科書的な質問をします：「コンテナとは何ですか？」または「CICDを定義してください。」これらの質問は、圧力下で耐性のあるシステムを設計できるか、午前2時に本番インシデントをデバッグできるかではなく、雑学知識の想起を測定します。

本当のDevOpsテストは判断を測定すべきであり、事実ではありません。自動化と運用性の間のトレードオフを理解する人、水平スケーリングと垂直スケーリングのいつを知っている人、失敗モードについて推論できる人をテストすべきです。

シグナルを持つDevOps評価がどのように見えるかはここにあります。

カテゴリ1：制約下でのインフラストラクチャ設計

シナリオベースの質問：

「1つのEC2インスタンスで実行されているアプリケーションがあります。1000 RPSを処理し、CPU の70%を使用し、4GBのRAMを60%の使用率で持っています。SLAは99.9%の稼働時間です。アプリケーションはステートレスです。どのような変更を加え、どの順序で行いますか？どのようなトレードオフを行っていますか？」

これはテストします：

• スケーラビリティと冗長性の理解（99.9%には両方が必要）
• コスト意識（高価なソリューションにジャンプするかどうか）
• シーケンス知識（最適化前のフェイルオーバー）
• トレードオフの表現（EBS gp3対ローカルNVMe、例えば）

「ロードバランサーを追加し、別のAZで2つ以上のインスタンスをスピンアップします」と言う候補者は明確に考えています。「Kubernetesに切り替える」と言う候補者は、制約（高可用性、マルチテナンシーではない）を理解せずにパターンマッチングしているかもしれません。

カテゴリ2：インシデント対応とトラブルシューティング

シナリオベースの質問：

「CI/CDパイプラインがランダムなビルドで失敗しています。エラーは『Docker レジストリへの接続タイムアウト』です。問題は約20ビルドごとに1回発生します。最初に何をチェックしますか、どのようなインストルメンテーションを追加しますか？」

これはテストします：

• システマティックなデバッグ方法論
• ネットワーク分離と認証の理解
• 可観測性の考え方（次回これを防ぐ必要がある場合、何をインストルメント化しますか？）
• 優先順位付け（完全な根本原因分析は必要ありません。ビルドシステムを今安定させることが必要です）

「Dockerレジストリステータスページをチェック」で始まる候補者は、「最初：それは再試行可能ですか、レート制限を追加しましたか？2番目：レジストリトークンがビルド中に期限切れになっているか、ネットワーク設定が変更されたか確認してください。」と言う候補者ほど思慮深くありません。

カテゴリ3：コードと設定レビュー

ライブ演習：

意図的な問題を含む30行のTerraformスニペットまたはDocker Composeカンフィグを提供します。候補者に問題を特定し、修正を説明するよう依頼します。

Terraformのサンプル問題：

• 0.0.0.0/0をデータベースポートに許可するセキュリティグループ
• RDSの欠落したバックアップ保持ポリシー
• 変数に含まれているハードコードされたデータベースパスワード
• コスト配分用のタグなし

Composeの例の問題：

• 正当化なしで特権コンテナ
• ヘルスチェックの欠落
• 制限なしのstdoutへのロギング（ディスク充填リスク）
• リソース制約なし（CPU/メモリ）

これは、本番システムを出荷し、何が壊れるかを学んだかどうかをテストします。教科書エンジニアはこれらをキャッチしません。経験豊富なオペレーターはキャッチします。

カテゴリ4：アーキテクチャとツール選択

会話：

「50のマイクロサービス全体でジョブを調整する必要があります。各ジョブは2～30分かかります。強力な順序付けの保証が必要です。何を使用しますか？トレードオフについて説明してください。」

有効な回答：

• Temporal（ワークフローオーケストレーション、強力な順序付け、複雑な操作）
• ステップファンクション（マネージド、AWSに限定、柔軟性が低い）
• Pub/Sub +コンシューマーアプリ（低結合、弱い順序付け、運用的にシンプル）
• Kubernetes ジョブ+カスタムコントローラー（柔軟、より多くの運用オーバーヘッド）

面接官が「ステップファンクションはシンプルに見える」とバックプッシュすべきです。候補者は「既に部分的に成功したジョブを再試行する必要がある場合、または10分のSLAで実行される2分のジョブがある場合、ワークフロー状態マシンが必要になるまで。しかし、それが真のコストです。複雑さのトレードオフ。」と弁護すべきです。

これは知識ではなく、判断と経験をテストします。

カテゴリ5：可観測性とモニタリング

短いシナリオ：

「変更を展開し、エラー率が0.1%から0.5%に上昇しました。レイテンシーp99は同じです。変更はロギングとトレーシング（リクエスト処理ではなく）に関係しています。どこを見ますか？」

弱い回答：「ログをチェックしてください。」 強い回答：「まず、トレーシング計測またはロギングレベルが変更されたかどうかを確認します。これは実際のエラーを増やさずにエラーの可視性を増加させる可能性があります。その後、ログカーディナリティを確認します。その後、以前にキャッチされていなかった新しいエラーケースをログしているかどうかを確認します。」

これは、Kubernetesドキュメントのみを読んだことのあるエンジニアからオペレーターを分けています。

評価を構造化する方法

1. 30分のテイクホーム： インフラストラクチャ設計シナリオ+設定レビュー。決定を説明するよう依頼します。
2. 30分の同期面接： ライブトラブルシューティング会話+アーキテクチャディスカッション。推論を記録します。
3. キーストロークインテグリティシグナルで評価をペアリングします。 DevOpsの候補者がChatGPTまたはStackOverflowから完全なソリューションをコピーする場合、通常の編集パターンが表示されます。ClarityHireはデフォルトでこれをキャプチャします。

正直な反対論

すべてのロールにこの深さが必要なわけではありません。ジュニアDevOpsまたはSREロールは、より単純なフィルタリングから利益を得ます。彼らはTerraformを読むことができますか、アプリを展開できますか、ネットワーク図を理解できますか？シニア+採用の場合、このルーブリックが適用されます。中レベルの場合、複雑さを減らしますが、シナリオベースの構造を保ちます。

次のステップ

本当のテストでDevOps候補者を評価する準備ができていますか？DevOpsおよびクラウドエンジニアリング評価ハブにチェックしてくださいテンプレートとDevOpsエンジニアのスキルを評価する方法に関するガイダンスについて。