地図が必要な理由
第1回でFDEがどんな職種かを整理しました。今回はその職種に必要なスキルの全体地図を描きます。ここで使う8ドメインは、このブログのFDEエンジニア育成RPGがレベルの軸として使う8つと同じです。Linux、ネットワーク、Kubernetes、データベース、認証・セキュリティ、オブザーバビリティ、クラウド・インフラ、顧客コミュニケーション。RPGではドメインのレベルが上がると同じログが違って読めるように設計されていますが、現実もまさにそのように動きます。
ドメインごとに三つを書きます。なぜ必要か、最低ラインはどこか、実務ラインはどこか。最低ラインは目標ではなく入場条件です。それ以下だと現場で会話が成立しません。実務ラインは、そのドメインの問題を一人で処理できる水準です。8つ全部が実務ラインの人はほぼおらず、その必要もありません。確認質問三つに詰まらず答えられれば、そのドメインはおおむね実務ラインです。
Linux
顧客サーバーの床はほぼ常にLinuxで、SSHで入った瞬間にGUIはありません。ここで詰まると、他のすべてのドメインへのアクセス自体ができません。
- 最低ライン — ファイル・プロセス・権限の基本概念。ディレクトリの移動と検索、プロセス一覧、ディスクとメモリ使用量の確認、ログがどこに溜まるかを探し当てること。
- 実務ライン — サービスマネージャでデーモンの状態と再起動履歴を追い、ディスク・メモリ・ファイルディスクリプタの枯渇を区別して診断し、他人の書いたシェルスクリプトを読んで直せる水準。
確認質問。ディスクが満杯だというアラートを受けたら、どの順序で確認するか。ログローテーションが止まっていることにどう気づくか。権限拒否エラーが出たとき、所有者・グループ・モードのどれから見るか。
ネットワーク
「つながらないんです」という報告の半分は、ネットワーク層で終わります。そして顧客環境のネットワークは、常にドキュメントより複雑です。
- 最低ライン — IP、ポート、DNS、ファイアウォールの概念。コマンドラインから接続可否を段階的に確認する能力。
- 実務ライン — TLS証明書の期限切れとチェーンの問題を診断し、プロキシやロードバランサの裏でリクエスト経路を追跡し、タイムアウト・接続拒否・リセットを症状だけで区別できる水準。
確認質問。同じURLがサーバーからは通るのにオフィスのPCからは通らないとき、まず何を疑うか。DNSのTTLは障害復旧をどう遅らせうるか。ファイアウォールに塞がれた場合とサービスが死んでいる場合は、クライアントからどう違って見えるか。
Kubernetes
いまのエンタープライズ顧客環境の標準的なデプロイ単位です。製品がコンテナで配布されるなら、障害診断の最初の画面はたいていここです。
- 最低ライン — Pod、Deployment、Serviceの関係。リソースの一覧・詳細・ログを引く基本コマンド。
- 実務ライン — CrashLoopBackOff、OOMKilled、Pendingがそれぞれ指す原因の系統を知り、リソース要求と上限を読み、Ingressから Podまでのトラフィック経路を追える水準。
確認質問。PodがPendingに留まる代表的な理由を三つ挙げられるか。コンテナがメモリ超過で殺されたことをどこで確認するか。Serviceはあるのに接続できないとき、セレクタとエンドポイントのどちらを先に見るか。
データベース
顧客のデータが住む場所であり、「遅いんです」という報告が最も頻繁に収束する場所です。そして失敗の代償が最も高い場所でもあります。
- 最低ライン — 結合を含むSQLクエリ、インデックスが何を変えるかの概念、作業前にバックアップの存在を確認する習慣。
- 実務ライン — 実行計画を読んで遅いクエリを診断し、ロック待ちとコネクションプール枯渇を区別し、マイグレーションのリスクを評価できる水準。
確認質問。昨日まで速かったクエリが今日遅いなら、どんな仮説を立てるか。ロックを掴んでいるセッションをどう探すか。インデックスの追加がかえって害になるのはどんな場合か。
認証・セキュリティ
FDEは他人の家の鍵を扱う人です。認証問題は障害報告の中で最も再現が難しい部類に入り、権限のミスは信頼を壊す最短経路です。
- 最低ライン — 認証と認可の区別、トークン・セッション・APIキーの寿命の概念、最小権限の原則。
- 実務ライン — OAuthやSSO連携のどの段階が壊れたかを特定し、401と403を手がかりに層を絞り、期限切れと時計のずれの問題を診断できる水準。
確認質問。401と403は、それぞれ何が失敗したという意味か。トークンが有効なのに認証が失敗するケースには何があるか。顧客が便宜のために管理者権限を丸ごと渡すと言ってきたら、何と答えるべきか。
オブザーバビリティ
未知の環境でオブザーバビリティは唯一の目です。自社サービスなら当然知っていることを、ここではログとメトリクスから掘り直さなければなりません。
- 最低ライン — ログ・メトリクス・トレースの区別、コマンドラインでログを時間とパターンで絞って読む能力。
- 実務ライン — ダッシュボードがなくてもメトリクスの出どころを探し当て、ログレベルと保持ポリシーを把握し、モニタリング自体が死んでいる状況でもシステム状態を再構成できる水準。
確認質問。モニタリングが先に死んだとき、何でシステム状態を把握するか。平均応答時間ではなくパーセンタイルを見るべき理由は何か。エラーログが毎秒数百行のとき、どこから絞って読むか。
クラウド・インフラ
顧客ごとにクラウドの地形が違い、FDEはその地形の上で働きます。マネージドサービスの障害とアプリケーションの障害を切り分けることが、診断の最初の分岐点です。
- 最低ライン — VPC・サブネット・セキュリティグループの概念、主要クラウド一つのIAM権限モデル。
- 実務ライン — マネージドデータベースやキューの状態をアプリの症状と切り離して確認し、コードで書かれたインフラ定義を読み、コスト構造の大枠を説明できる水準。
確認質問。セキュリティグループとネットワークACLは何が違うか。特定のアベイラビリティゾーンの障害が疑われるとき、何を確認するか。顧客のクラウドへのアクセス権を要求するとき、どの粒度で、どの期間で頼むか。
顧客コミュニケーション
8つの中で唯一技術ではありませんが、残りの7つを顧客に届ける通路です。RPGでもこのドメインのレベルが低いと、診断が正しくてもミッションが失敗する設計になっていますが、現実の採点方式も同じです。
- 最低ライン — 顧客の言葉を事実と解釈に分けて聞くこと、約束した周期で進捗を共有すること。
- 実務ライン — 期待値を明示的に管理し、悪い知らせを信頼を失わずに伝え、技術的な内容を非エンジニアの言葉に翻訳できる水準。
確認質問。「いつ直りますか」に、まだ分からないとき何と答えるか。顧客が間違った原因を確信しているとき、どう訂正するか。障害報告書の最初の段落には何が来るべきか。
手を動かして練習する
この地図で自分の位置を測ったら、空白は手で埋めるのが早道です。
- FDEエンジニア育成RPG — 上の8ドメインがそのままレベルの軸です。ミッションを回して、どのドメインで詰まるかを確かめてください。
- FDEカリキュラム ロードマップ — 10ドメイン65スキルをセルフチェック基準と共に追跡する学習チェックリストです。
FDE完全ガイドシリーズ