DevOpsエンジニアのスキル評価方法：方法論とルーブリック

DevOps評価の誤り

ほとんどのチームは、ソフトウェアエンジニアを評価する方法でDevOps候補者を評価します：コーディング演習。しかし、DevOpsは主にコーディングではなく、システム思考、トレードオフ判定、運用復元力です。

候補者は美しいTerraformを書くが、データベースが真夜中にポケットベルされたときに壊滅的に失敗するかもしれません。逆に、コードが点在っている候補者は、ゾーン全体の障害で0の手動介入で生存するシステムを構築するかもしれません。

異なるフレームワークが必要です。

DevOps スキルが実際に仕事の成果を予測するもの

1. システム思考と失敗モード推論

失敗モードに名前を付けることができますか？主導的にそれらを設計できますか？

評価内容： 簡単なアーキテクチャ（RDSと話しているウェブアプリ）を与えます。「ここで何が壊れますか？爆発範囲は何ですか？どのように軽減しますか？」Netflixを設計するよう求めないでください。基本的なセットアップをハードンするよう求めます。

良い答え：「RDSは単一障害点です。フェイルオーバーに読み取りレプリカを追加し、接続枯渇を防ぐ接続プールを追加します。アプリ自体はステートレスで負荷分散する必要があります。データベースのサーキットブレーカーを追加します。」

弱い答え：「Kubernetesを使用してください。」

2. 運用実用主義

最も単純なソリューションを選択しますか？それとも最新のツールに手を伸ばしますか？

評価内容： 「日単位のバックアップジョブを実行する必要があります。2つのオプション：Kubernetes CronJobまたはLambda。チームには既存のKubernetesがありません。トレードオフを話し合います。」

良い答え：「Kubernetesを既に実行していない場合、Lambdaはシンプルです。移動部分が少なく、デバッグが簡単で、CloudWatch統合がビルトイン。トレードオフは15分のタイムアウトと冷たい開始レイテンシー。バックアップには重要ではありません。Lambdaを使用します。」

弱い答え：「ポータビリティのためにKubernetesを常に使用してください。」

3. 可観測性とデバッグ

監視を設計できますか？アラートから根本原因まで問題をトレースできますか？

評価内容： ライブコーディングインタビューは適用されません。代わりに、本番アラートを与えます。「Postgres インスタンスでCPUが80%。ランダムに見えます。診断？」彼らを語らせるよう求めます。何のクエリツールを使用しますか、何を確認しますか、どの順序で？

良い答え：「最初に、pg_stat_statementsで最も遅いクエリを確認し、特定のアプリケーションエンドポイントと関連するかどうかを確認し、インデックス統計を見て、インデックスが欠落しているか膨らんでいるか確認します。」

4. オートメーション判定

何は自動化対マニュアルですか？

評価内容： 「1日20回デプロイしますが、データベースマイグレーションは1週間に1回だけです。デプロイと同じ方法で移行を自動化しますか？」

良い答え：「いいえ。オートメーションは操作が頻繁で低リスクの場合、認知負荷を削減します。移行は頻繁ではなく高リスク — 実行前に人が確認・承認し、ドライラン最初にしたい。」

弱い答え：「すべてを自動化します。」

5. クラウドアーキテクチャトレードオフ

AWS対Azure対GCPはフィーチャー機能ではなく、操作とコストについてです。

評価内容： シナリオを提示してコスト/メリット分析を尋ねます。「マイクロサービスプラットフォームを構築しています。管理Kubernetes（EKS/AKS/GKE）または自己管理を使用する必要がありますか？」

理想的には、彼らは言うでしょう：「管理はより良いです。制御プレーン、アップデート、ネットワークを処理します。トレードオフは制御が少なく、コストがやや高いです。自己管理は、専用チームと特定のネットワーク要件がある場合に優れています。」

評価構造

パート1：テイクホームシナリオ（2時間）

意図的なギャップまたはセキュリティの問題でアーキテクチャダイアグラムまたはTerraformコードベースを提供します。尋ねます：

• 問題を特定します
• トレードオフ分析で修正を提案します
• このシステムの監視戦略をスケッチします

これはasync対応で、大規模な知識をテストします。

パート2：ライブトラブルシューティング（45分）

シナリオ： 本番レイテンシースパイク。どのようにデバッグするかを説明してください。

候補者は話します。あなたは聞きます。テスト中：

• 体系的なアプローチ（推測ではなく）
• 可観測性ツール知識
• 優先順位付け（最初にどこを見ますか）
• コミュニケーション（考え方を説明できますか）

パート3：アーキテクチャ会話（30分）

制約または要件を提示します。「50TBのデータを新しいデータベースにゼロダウンタイムで移行する必要があります。アプローチは何ですか？」

これはテスト判定と実用主義。正解はありません — あなたは爆発半径、ロールバック計画、運用複雑さについての推論を聞いています。

ルーブリック：スコア枠組み

何を回避するか

しないでください：

• DevOps候補者にLeetCode問題を解くよう求めます。（スコアが良いですが、職務パフォーマンスを予測しません。）
• DevOpsを「ソフトウェアエンジニアリングライト」として扱う（異なるスキルセット）。
• ツールの幅に焦点を当てます。（Kubernetes知識は他に何かを操作できるかどうかを予測しません。）
• ライブインタビューを無視します。（問題を話し通すことで推論が明らかになります。）

してください：

• 現実的な制約を提示します。（予算制限、市場時間、チームサイズ）。
• 判定をテスト。事実ではありません。（TerraformをCloudFormationより選択した理由を説明できますか？）
• 説明を記録します。（非同期トラブルシューティング演習は推論を表示しません。ライブします。）

スケール時のDevOps採用

5人以上のDevOpsエンジニアを採用する場合、このルーブリックで構造化アセスメントプロセスを使用します。シナリオを1回テンプレートし、再利用し、候補者全体で結果を比較します。一貫性はシグナルを改善します。

より深いスキル固有の評価については、AWS対Azure対GCPテストフレームワークを確認して、クラウド固有のギャップを表示します。