プラットフォームエンジニアリング勉強会に参加して

はじめに

ume(梅)です。早いもので気付いたら入社して3ヶ月が経ってました。
今回は社内でプラットフォームエンジニアリングの勉強会に参加しましたのでそのまとめ記事をお届けします。

やったこと

CNCFのホワイトペーパーを各自輪読の上、数回にわたって章毎のディスカッションを行いました。
以降の節がホワイトペーパーの当社的な解釈です。

サマリー

以下を読み進める上で2つの単語を理解しておくと良いです。

• 認知的負荷: 簡単に言うと「勉強・調査しないとわからないようなこと」のこと、特にプラットフォームエンジニアリングは以下の低減を目的にしている
  • 課題内在性負荷・・・学習内容の難しさによる負荷
  • 課題外在性負荷・・・「気が散る」ことや、メールなどで入ってくる無関係な情報などによる負荷
• プラットフォームチーム: チームトポロジーで定義されたチーム定義のうちのひとつ、インフラやツール、CI/CDなどの共通サービスなどをプラットフォーム化したものを提供するチーム

なぜプラットフォームなのか？

プラットフォームを開発し以下を目的となります。

• 製品チームの認知負荷低減　---　ここが肝要
  • 製品チーム = 当社でいうプロジェクトチーム
• 信頼性の向上
• 開発効率の向上
• 障害の低減、品質の向上
• クラウドコストの低減

プラットフォームとは

プラットフォームの成熟度は以下5つの段階が想定されています。

1. コンピュート、ストレージ、データベース、アイデンティティなどの機能を単体でプロビジョニング
2. パイプラインやタスクラン、アーティファクト、構成管理、テレメトリ収集も同時にプロビジョニング
3. サードパーティソフトの導入時に依存関係の自動的な解決
   • 外部アプリとミドルウェアの自動構成
4. 開発するソフトウェアのユースケースに特化した形でアプリケーションひな形のミドルウェア、パイプラインを準備
5. 計測、標準のダッシュボードを通じてパフォーマンスやコストの可視化
   • 運用系も自動構成

プラットフォームの属性

プラットフォームとして必要なことは以下の通りです。

1. 製品のような扱いでプラットフォームを整備する
2. プラットフォームのUX向上を意識する
3. ドキュメント整備とオンボーディング
   • ドキュメント、テンプレート、ツールを用意して、オンボーディングをスムーズに行う
4. セルフサービス（開発チームが自分だけでプロビジョニングできる）
   • プラットフォームチームの作業を必要とせず、ユーザーが自らオンデマンドで利用できるようにする
5. ユーザーの認知不可の軽減
   • プラットフォームの実装の詳細をカプセル化する
6. オプションで構成可能（カスタマイズ可能）
   • プラットフォームが対応していない場合でも、自分たちで持ち込むことは可能な状態にする
   • プラットフォームが制約になってしまわないようにする
7. デフォルトで安全（セキュア）
   • なにも設定しなくても、デフォルトで払い出された状態で安全である状態

プラットフォームチームの属性

プラットフォームを提供するチームとして必要なことは以下の通りです。

1. プラットフォームのユーザー要件を調査し、機能ロードマップを計画する
   • ユーザーインタビュー、インタラクティブなハッカソン、問題追跡ツールとアンケート、可観測性ツールによる使用状況直接観察
2. プラットフォームが提案する価値観を売り込み、宣伝し、擁護する
   • インバウンドフィードバックと思慮深いデザイン
   • アウトバウンドマーケティングと擁護
3. ポータル、API、ドキュメントとテンプレート、CLIツールなどの機能とサービスを使用および観察するためのインタフェースを管理および開発する
   • 自分たちではなるべく作らない、うまく既存のあるツール・サービスを利用する
   • ボタンを押したらIaCツールが実行されるようなイメージ

プラットフォームに関する課題

プラットフォーム構築に対する課題と対策は以下の通りです。

• プラットフォームを製品のように扱い、ユーザーといっしょに開発する必要がある
  • フィードバック無しで機能やエクスペリエンスをリリースするのはNG
• 優先順位と最初のパートナーアプリケーションチームを慎重に選択する必要がある
  • プロダクト固有の機能は優先度を低くする
  • 熱心なアプリケーションチームに使ってもらい、良いフィードバックを出してもらう
• 企業リーダーのサポートを求め、バリューストリームへの影響を示す必要がある
  • インフラを単なるコストとして認識されてしまわれないように、企業リーダーの理解を得ることが必要
  • バリューストリームチームに対する直接的な影響と関係を実証する

プラットフォームチームを運営していくにあたっての課題は以下の通りです。

• プラットフォームチームの認知負荷が多くなる
• 特定のビジネスに固有の経験と能力に集中させることが重要
• あるものはなるべく活用する、自分たちでなるべく開発しない
• ドメインと顧客数に応じて人員配置を行う

プラットフォームの成功を測る方法

プラットフォームのKPIには以下が挙げられます。

• ユーザーの満足度と生産性
  • アクティブユーザーと維持率
  • ネットプロモータースコア、ユーザーの満足度
  • SPACEフレームワーク
• 組織の効率性: 自動的に測るツールがあると良いかも
  • サービスが使えるようになるまでの時間
  • 本番環境にデプロイできるまでの時間
  • 新しい開発メンバーが最初にコードをコミットするまでの時間
• 製品と機能の提供
  • Four Keysの本番環境に対する指標を測ると良い

プラットフォームの機能

以下の機能が定義されている。
当社で採用する具体的なサービスは検討が必要そう。

• 製品と機能を観察およびプロビジョニングするためのWeb ポータル
• 製品と機能を自動的にプロビジョニングするためのAPI (および CLI)
• 製品の機能を最適に使用できる「ゴールデン パス」テンプレートとドキュメント
• サービスと製品の構築とテストの自動化
• サービスと製品の提供と検証の自動化
• ホスト型IDEやリモート接続ツールなどの開発環境
• インスツルメンテーションとダッシュボードを使用したサービスと製品の可観測性(機能、パフォーマンス、コストの監視を含む)
• コンピューティング ランタイム、プログラム可能なネットワーク、ブロック ストレージおよびボリューム ストレージなどのインフラストラクチャサービス
• データベース、キャッシュ、オブジェクト ストアなどのデータサービス
• ブローカー、キュー、イベント ファブリックを含むメッセージングおよびイベント サービス
• サービスとユーザーの ID と認可、証明書とキーの発行、静的シークレット ストレージなどのID およびシークレット管理サービス
• コードとアーティファクトの静的分析、ランタイム分析、ポリシーの適用などのセキュリティサービス
• コンテナイメージと言語固有のパッケージ、カスタムバイナリとライブラリ、ソースコードのストレージを含むアーティファクトストレージ

最後に

エンジニアのキャリアを積んできてプラットフォームの大切さは理解してきたつもりでしたが、改めてドキュメントにまとめられたものを読み大変勉強になりました。
ホワイトペーパー内で具体的なツールにも触れていたので社内でも活用していきたいと考えてます。

ume