プラットフォームエンジニア

この領域について

中核となる能力

• 01プラットフォームをプロダクトとして扱う

  利用者が誰で、それ以前は何をしていて、そのどの問題を実際に解いているのかを把握します。この役割はプロダクトとしての通常の義務を伴います。利用者調査、ドキュメント、サポート、練られたロードマップ、そして成果物の量ではなく採用状況を誠実に測ることです。

• 02ゴールデンパスとサービステンプレート

  何もない状態から、動いていて観測でき、適切に守られたサービスまでの、支えられた経路を用意します。雛形、パイプライン、ランタイム設定、テレメトリ、アラートの経路が一緒に届き、チームが手を加えたあとも保守可能であり続けることです。

• 03セルフサービスのプロビジョニング

  データベース、キュー、環境、DNSレコード、権限を、宣言された要求として出せば、プラットフォームが強制する制限の範囲内で自動的に満たされるようにします。成功とは、依頼が速くなったことではなく、誰にも頼まなくてよくなったことです。

• 04抽象の設計

  何を隠し、何を見せ、どこに逃げ道を置くかを決めます。隠しすぎれば、要件が少し変わった途端にチームは行き場を失います。隠さなすぎれば、手数の増えたドキュメントができあがります。この境界の見極めが、この職種の知的な中核です。

• 05マルチテナンシーと分離

  共有インフラ上で多くのチームのワークロードを動かしつつ、一つが他を劣化させないようにします。リソース制限、名前空間とネットワークの境界、クォータの方針、そして行儀の悪いテナントに対してプラットフォームが何を保証するのかについての明確な立場です。

• 06既定で備わる可観測性

  舗装された道に計装を同梱し、各チームが自前で作らなくてもトレース、構造化ログ、有用なメトリクスが存在するようにします。監視がプロジェクトになる組織と、どのサービスも不調になった瞬間に調べられる組織の差はここにあります。

• 07コードとしてのポリシーとガードレール

  要件を自動化された制御——アドミッションポリシー、イメージの来歴の規則、ネットワーク制限、実行時の検知——として表現し、準拠した構成が既定になり、そこから外れれば見えるようにします。何かを拒むガードレールは、代わりに何をすべきかを示さなければなりません。さもなければチームは迂回します。

• 08ワークロードのアイデンティティとシークレット

  すべてのワークロードに検証可能なアイデンティティを与え、それに基づいて短命な認証情報を発行し、アプリケーションが長期の鍵を持ち歩かないようにします。配布、ローテーション、失効はプラットフォームの性質になり、各チームが別々に実装するものではなくなります。

• 09プラットフォーム自体の信頼性

  プラットフォームはその上に築かれたすべての依存先であるため、自身の可用性目標とエラーバジェットは、個々のサービスのそれより重要になります。障害の起き方には特に注意が要ります。障害時に閉じる方向へ倒れるプラットフォームは、インシデントの最中に組織のデプロイを止めてしまいます。それはまさにデプロイが必要な瞬間です。

• 10インターフェースの進化と廃止

  チームが依存するものにバージョンを与え、古いインターフェースは移行経路、十分な予告、そして可能であれば自動変換を伴って引退させます。まずい廃止は、プラットフォームが依って立つ信頼を失う最短の道であり、信頼は仕組みより立て直しが難しいのです。

よくあるご質問

よくあるご質問

プラットフォームエンジニアリングとDevOpsは何が違いますか

誰のための仕事かと、何を生み出すかが違います。DevOpsは変更が本番へ移動することと、その後に返るシグナルに関わり、通常はデリバリーチームの内側で、そのチームのために実践されます。プラットフォームエンジニアリングは、多くのチームが利用するものを生み出します。セルフサービスの窓口と、その上を通る支えられた経路を備えた社内プロダクトで、下層の仕組みを知らずに使えます。前者はソフトウェアがどれだけ安全に、どれだけ頻繁に利用者へ届くかで測られ、後者はチームが手助けなしに必要なものを得られるかで測られます。混同は無理もありません。プラットフォームのグループはしばしばデリバリー用の道具を作り、プラットフォームエンジニアの多くはデリバリーの仕事から来ているからです。それでも、誰にも使われないプラットフォームは、生み出したパイプラインがどれほど優れていても失敗しています。

プラットフォームエンジニアは、インフラやクラウドのエンジニアの呼び名を変えただけですか

働き方を変えずにチーム名だけを付け替えた組織では、実質的にそうなっていることがあります。本来は違います。クラウドやインフラのエンジニアリングが生み出すのは基盤そのものです。アカウント構成、アイデンティティモデル、可用性の姿勢、コスト構造です。プラットフォームエンジニアリングが生み出すのは同僚が使うものであり、他所へ行けるかもしれない利用者を持つことから来る義務を伴います。ドキュメント、サポート、バージョニング、移行経路を伴う廃止、そして前提ではなく測定される採用状況です。プラットフォームはその基盤の上に載り、基盤が健全であることに依存します。だからこそ順序が重要になります。

これが正当化されるには、組織はどのくらいの規模である必要がありますか

普遍的な境目はありませんが、信頼できる検査はあります。同じインフラの判断が独立に何回下されているか、そしてその答えがどれだけ違うかを数えることです。チームが二つか三つなら、正直な答えはたいてい、よく手入れされたテンプレート、共有モジュールのライブラリ、そして明確なドキュメントです。チーム数が増え、一貫性の欠如がプラットフォームより高くつくようになるにつれて、根拠は強くなります。利用者が一つしかない段階で作れば、一つのユースケースに仕える抽象ができ、しかもそのユースケースを複雑にします。

社内プラットフォームの利用は必須にすべきですか

義務にするより、当然の選択肢にするほうがはるかにうまくいきます。強制は採用を遵守に変え、プラットフォームが必要とするフィードバックを覆い隠します。チームは使いにくさを報告しなくなり、黙って迂回するようになります。本当に交渉の余地がないものもいくつかあり、たいていはセキュリティと規制上の統制です。それらは舗装された道の内外を問わず適用される自動ガードレールに置くべきです。それ以外については、チームが別の手段を選ぶことは、チームについての情報ではなくプラットフォームについての情報です。

プラットフォームチームがチケットの待ち行列になると何が起きますか

プラットフォームチームであることをやめ、名前の違う共通サービス窓口になります。仕事は依頼を閉じることを軸に組み替えられ、グループはスループットで測られ、依頼そのものを不要にするセルフサービスの機能を作る余地は誰にもありません。そして待ち行列は、どれほど効率よくさばいても伸びます。需要を生んでいるのは、その待ち行列のせいで誰も作れないもの、まさにそれの不在だからです。立て直すには、依頼が続く中でもプラットフォームの作業のための余力を意図的に守る必要があり、それは経営層にしか下せない居心地の悪い判断です。

プラットフォームのオンコールは誰が担いますか

プラットフォームについては、プラットフォームチームです。これはこの職種を置く分かりやすい論拠の一つでもあります。共有のコンポーネントが壊れたとき、それを理解している一つのグループが対応するのであって、複数のプロダクトチームが同じ不具合を別々に診断するのではありません。境界は明示されている必要があります。プラットフォームが何に責任を持ち、何がサービスを所有するチームに残り、判然としない場合に呼び出しをどう振り分けるかです。曖昧さは最悪の結果を生みます。インシデントが「これは誰の問題か」の交渉から始まる状態です。

プラットフォームエンジニアは既存の開発チームとどのように働きますか

開発チームの増強という形で御社のチームに参画し、そのチームの既存のやり方に従います。レビューの慣習、リリースプロセス、アーキテクチャの方向性、そして御社の計画サイクルで決まる優先順位です。作業の方向づけは、プロダクト、ロードマップ、エンジニアリング標準とあわせて御社に属します。Talent.IDは、雇用が続くかぎり雇用関係を保持し、タレント管理、給与支払い、従業員福利厚生、そして継続的な従業員関係を担います。