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

第4章 フリート思考規模に応じたプラットフォームの管理

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

ほとんどのプラットフォームエンジニアリングは、一つのユースケースから始まる。開発者がデータベースを必要としたり、チームがアプリケーションをデプロイしたいと思ったりする。プラットフォームチームは、そのニーズをサポートするワークフローやテンプレートを構築する。最初はこれでうまくいく。テンプレートは1つ。パスは1つ。環境も1つだ。しかし、組織が大きくなったらどうなるだろうか？数百のサービス、数十のチーム、複数の環境、絶えず変化するコンプライアンス要件がある場合はどうなるだろうか？

そこで、フリート思考が不可欠になる。

自動車会社や航空宇宙会社が、バージョン、メンテナンス状態、演算子が異なる車両や航空機のフリートを管理するように、プラットフォームチームは、組織全体のサービス、環境、インフラのフリートを管理することを学ばなければならない。この考え方の転換は、持続可能でスケーラブルな社内プラットフォームには不可欠である。

フリート管理101

フリート管理とは、類似性はあるが同一ではないものの集合体を管理することであり、それぞれが独自のライフサイクル、依存関係、制約を持つ。

プラットフォームエンジニアリングでは、「フリート」には以下のものが含まれる：

• 複数の環境にまたがるアプリケーション

• プラットフォームがプロビジョニングするデータベース、キャッシュ、キュー

• チーム間で使用されているCI/CDパイプラインとワークフロー

• クラスタ、仮想プライベートクラウド（VPC）、クラウドアカウントなどのインフラ構成要素

• 時間とともに進化するプラットフォームの機能とプラグイン

これらの要素にはそれぞれライフサイクルがある。作成し、監視し、アップグレードし、時には引退させる必要がある。フリート管理のためのツールやプロセスがなければ、ドリフトがセットされる。チームは同じサービスの異なるバージョンを実行する。コンプライアンス・チェックにズレが生じる。サポートは反応的で予測不可能になる。

しかし、すべてが失われたわけではない。毎日の通勤で私たちの生活の多くに触れているこの業界から、教訓を学ぶことができる。

自動車プラットフォームからの教訓

最新の自動車は、バグを修正し、セキュリティ問題を修正し、新機能を展開するために、OTA（Over-The-Air）ソフトウェアアップデートを受ける。しかし、これらのアップデートはスピードだけを追求するものではない。安全性と座標を念頭に置いて設計されている。アップデートは段階的、一時停止、ロールバック、または選択的に適用することができる。クルマのシステムは、変更を適用する前に、実行中のバージョン、依存関係、健全かどうかを把握している。

このアプローチは、プラットフォーム・エンジニアリングにそのまま当てはまる。社内のプラットフォームは、次のようなことができなければならない：

• 機能をバージョンアップし、何がどこで実行されているかを追跡する。

• タイミングと範囲をコントロールしながら、アップデートを徐々に展開する。

• 問題にレスポンスして、変更を一時停止またはロールバックする。

• プロビジョニングされたすべての所有権とライフサイクルを追跡する。

• フリート全体のポリシー実施とドリフト検出をサポートする。

フリート思考は、プラットフォームを一度だけ構築して希望するシステムから、継続的に管理される環境に変える。 ...