クラウドエンジニア

The discipline

中核となる能力

• 01プロバイダーアーキテクチャ

  リクエスト量、バースト性、データの重さ、レイテンシ許容度といったワークロードの実際の形に対して、コンピュートのモデル、ストレージクラス、マネージドサービスを選びます。そして、プロバイダーの抽象がアプリケーションの必要と合わなくなる地点を把握します。

• 02ネットワーク設計

  アドレス設計、サブネットとルーティングの構造、他環境へのプライベート接続、制御されたエグレス、負荷分散です。ネットワークは、ワークロードが乗ったあとで最も引き直しにくいものの一つであり、ここでの判断は他の多くより長く残ります。

• 03アイデンティティとアクセス制御

  ロール、ポリシー、信頼関係を設計し、権限が事後のレビューではなく構造として最小権限になるようにします。企業ディレクトリとのフェデレーション、保存された鍵に代わるワークロードアイデンティティ、そして複数のポリシーが適用されるときにアクセス判定がどう決まるかの理解を含みます。

• 04マネージドサービスの判断

  プロバイダーのサービスを使う場面と、コンポーネントを自分で動かす場面を見極めます。マネージドサービスは運用負荷を下げ、結合度を上げるため、判断には何が保証されるか、想定する量ではいくらかかるか、そして将来そこを離れる場合に何が要るかを含める必要があります。

• 05データの保管とライフサイクル

  アクセスパターンに合う永続ストアを選び、保持とアーカイブの方針を意図的に定め、バックアップが取得できたことではなく復元できることを検証し、フェイルオーバー時に何が失われるかを知るためにレプリケーションの意味論を十分に理解します。

• 06可用性と復旧の設計

  停止とデータ損失の許容度を明示的な目標として表し、それを満たすゾーンとリージョンの構成を設計し、障害を予行演習します。一度も実施されたことのない復旧手順は文書であり、文書は負荷のかかったシステムとは違う振る舞いをします。

• 07プロバイダーのセキュリティモデル

  転送時と保管時の暗号化、鍵の管理とローテーション、シークレットの保管、ネットワークの分離、そして設定ミスの類型をまとめて防ぐ組織全体のガードレールです。あわせて、プロバイダーの責任がどこで終わり、利用者の責任がどこから始まるかを知ることでもあります。

• 08環境の可視性

  プロバイダーのメトリクス、フローログ、監査証跡、構成履歴を、事後の問いに答えられる形にまとめます。何が変わったか、誰が変えたか、そのリソースは以前どうだったかです。標準の監視は、あらかじめ定めた問いにはよく答え、予期しない問いには弱いため、監査履歴はダッシュボードと同じくらい重要になります。

• 09コストエンジニアリング

  支出を帰属させられるようにタグ付けと配賦を整え、想定ではなく観測された負荷に合わせてサイズを適正化し、コミットメント型の契約を意図的に選び、エグレスとゾーンをまたぐ通信を設計上の入力として扱います。最大の削減は調達ではなくアーキテクチャから生まれます。

• 10移行の遂行

  移行中もシステムが使える状態を保つよう順序を組みます。依存関係の把握、データの転送と突合、戻り道を定めた切り替え、そして誰も文書化していないものを地道に洗い出す作業です。移行が失敗するのは、技術的な部分より文書化されていない部分であることのほうがはるかに多いのです。

Buyer guidance

面接で尋ねる価値のある質問

プロバイダーの語彙ではなく、プロバイダーについての判断力を見分けるための質問です。御社が既に運用している選考プロセスの中で参考としてお使いください。要件を定めるのも、誰がそれを満たすと判断するのも御社です。

1. 01ご自身が設計した環境のアカウントとネットワークの構成を説明してください。もう一度作るなら、どこを違う構造にしますか。

   What a strong answer shows

   自分の判断とともに暮らしてきたかどうかです。優れた回答は、境界の背後にある理由——分離、影響範囲、課金、コンプライアンス——を説明し、具体的な後悔を一つ挙げます。それは説得力をもって作り話にするのが難しい部分です。

2. 02あるサービスが一つのストレージバケットを読む必要があります。その付与の手順と、他の何もがアクセスを得ていないことを証明する手順を説明してください。

   What a strong answer shows

   権限の評価についての正確さです。付与は簡単で、検証はそうではありません。鍵ではなくアイデンティティを使うこと、対象リソースまで絞られた範囲、そして結果を確認する方法を聞いてください。

3. 03トラフィックの伸びを伴わずに請求額が急増しました。どう調査しますか。

   What a strong answer shows

   コストを自分で診断するのか、上へ回すのかが分かります。配賦タグ、使用量の内訳、特定の課金種別についての仮説、そして転送量や遊休容量がコンピュートより多くを説明することが多いという認識を期待します。

4. 04直近に運用したシステムの復旧目標は何でしたか。それを満たせることを最後に確認したのはいつですか。

   What a strong answer shows

   文書化された計画と、試された計画の距離です。実際に復旧を予行演習した候補者は、日付と、その最中に何がうまくいかなかったかの話で答えます。そうでない候補者は構成図で答えます。

5. 05誰も全体を把握していないシステムの移行を任されました。最初の一か月にどう取り組みますか。

   What a strong answer shows

   情報が不完全な状況での進め方です。優れた回答は、目標アーキテクチャではなく観察と棚卸しから始めます。何が何と通信しているか、何が定期実行されているか、どこに文書化されていない依存があるかです。

6. 06マネージドデータベースを選ぶのはどんなときで、選ばないのはどんなときですか。

   What a strong answer shows

   運用負荷を、結合度とコストと秤にかけるかどうかです。バージョンや拡張機能の制約、スケール時の挙動、可用性の約束が実際に何を含むのか、そして将来そこを離れる際の費用に触れているべきです。

7. 07稼働中のリージョンでプロバイダーが性能劣化を報告しています。フェイルオーバーするかどうかをどう判断しますか。

   What a strong answer shows

   落ち着きと、フェイルオーバー自体もリスクを伴うという理解です。証拠を集める姿勢、レプリケーション遅延とデータ整合性への意識、そしてインシデント中に即興で決めるのではなく事前に合意した判断基準を見てください。

Common questions

Frequently asked questions

クラウドエンジニアとDevOpsエンジニアは何が違いますか

クラウドエンジニアはプロバイダー層を専門とします。アカウントとネットワークの構造、アイデンティティの付与と評価、システムが依拠するプロバイダーのサービス、ゾーンやリージョンの障害時の挙動、そしてそれらの費用です。DevOpsエンジニアは、どんな基盤であれ既にあるものへ変更を届けることを専門とします。パイプライン、デプロイ戦略、リリースの自動化、そしてリリース後のフィードバックです。一方はシステムが何から作られているかに関わり、他方は変更がどうそこへ届くかに関わります。小さな組織では一人が兼ね、環境が大きくなると、二種類の深さは一つの職務に収まらなくなります。

クラウドエンジニアとプラットフォームエンジニアは同じですか

同じではありません。どちらもアプリケーションの下に位置するため混同されがちですが、クラウドエンジニアリングが提供するのは要件を満たす基盤そのものです。構成、権限、可用性、支出です。プラットフォームエンジニアリングが提供するのは基盤への窓口であり、自分で組み立てることもできる社内エンジニアのために作られ、彼らが実際に使うことを選ぶかどうかで評価されます。プラットフォームは通常、クラウドエンジニアリングが整えたものの上に載ります。だからこそ、筋の通っていない環境の上にプラットフォームを築くと、背後に元の問題をすべて残したまま、きれいな外観だけができあがります。

複数のクラウドプロバイダーを使うべきですか

選択として採るのはまれで、事情によってそうなることは多くあります。意図的なマルチクラウドは、組織が理解すべき面をおおよそ倍にします。二つのアイデンティティモデル、二つのネットワークモデル、二通りの障害の振る舞いです。その対価は、交渉上の立場の強化と、多くの組織が結局行使しない可搬性の選択肢です。正当化されるのは、データ所在地の規則、顧客の要請、買収、あるいは実際の規制上の義務がある場合です。プロバイダー障害を理由に正当化されることはまれです。増えた複雑さが、防ぐ以上の停止を招きがちだからです。

クラウドの認定資格はどこまでを示しますか

プロバイダーのサービスカタログを学び、部品がどう組み合わさるはずかを思い出せることを示します。それは本物の基礎であり、キャリアの初期には価値があります。一方で、持ちこたえた権限モデルを設計したことがあるか、フェイルオーバーがドキュメントと違う振る舞いをするのを見たことがあるか、想定外の課金を原因まで追跡したことがあるかは示しません。資格は判断力ではなく準備の証拠として扱い、面接の時間は判断力に使ってください。

クラウド環境のセキュリティは誰の責任ですか

プロバイダーは基盤そのものを守り、利用者は設定、アイデンティティ、ネットワークの露出、データ保護、そしてその上に構築したすべてに責任を持ちます。公になったクラウドのデータ露出のほとんどは、この線の利用者側で起きています。意図より広い権限、インターネットから到達できるストレージ、リポジトリに入った認証情報、安全であるより便利であるための既定値です。自分が使うサービスについてこの境界がどこにあるかを言えないエンジニアは、自覚のない穴を抱えていることになります。

クラウドエンジニアがいれば支出を抑えられますか

部分的には可能ですが、採用の前にその限界を理解しておく価値があります。実際の削減には通常アーキテクチャの変更が要ります。ストレージクラスと保持期間、トラフィックの経路、遊休容量のリクエスト課金型コンピュートへの移行、誰も使っていないものの撤去です。そしてそれには、対象システムを所有するチームのエンジニアリング時間が必要です。この役割をコスト関連のチケットとアクセス申請の待ち行列として置けば、毎月レポートは出ますが、ほとんど何も変わりません。帰属を可視化し、設計変更を提案できるようにすれば、根本の傾向を動かせます。

クラウドエンジニアは既存の開発チームとどのように働きますか

開発チームの増強という形では、エンジニアは御社のチームの隣ではなく、その中に加わります。御社のアーキテクチャ原則、アカウントの慣習、セキュリティ方針、スプリントの優先順位が作業を規定し、何をどの順で作るかは御社の人々が決めます。雇用に関する部分はTalent.IDが担います。雇用関係、給与支払い、従業員福利厚生、タレント管理、そして継続的な従業員関係です。