Zenn
📖

Platform Engineering Maturity Modelの活用開始するべきフェーズは？

2024/01/15に公開
platformeng
tech

なぜこんなページを書いたの？

現在業務で感じている問題への対処として、Platform Engineering的な動きも必要になると感じたため、そもそもPlatform Engineeringとは何なのかと、Platform Engineering Maturity Modelという成熟度レベル定義を基に実際に自分たちがどういうところから動き始めればいいかについて考えてみたものです。

後述するように、私自身はPlatform Engineerではなく、業務上感じた課題への対処としてPlatform Engineering的な動きも必要と思って調べている段階ですので、色々わかっていない点や誤解して理解している点も多々あると思います。
そのため、もし読んだ方が気になったことがあったならコメントいただければ幸いです。

Platform Engineering?

platformengineering.orgによると、以下のような定義となります。
https://platformengineering.org/blog/what-is-platform-engineering

Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.

Platform Engineeringとは、ソフトウェアエンジニアリング組織において、自組織の効率化を達成するためにツールやワークフローを設計構築する活動。Platform Engineerとは、上記を開発から運用までのライフサイクル全体をカバーする統合されたプロダクトとして社内に提供するエンジニアということとなります。

自組織内の技術的活動を効率化するためのプロダクトを提供するエンジニア組織ということになりますね。

Platform Engineering Maturity Modelとは？

ただ、これだけではどういう形でPlatform Engineeringが進行していくのかはわかりにくいなと考えていたところ、CNCFからPlatform Engineering Maturity Modelという形で文書が出ていたため、読んでみました。

https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
© 2023 The CNCF Authors | Documentation Distributed under CC BY 4.0

Platform Engineering Maturity Modelとは、Platform Engineeringの隆盛の中で見えてきたいくつかのパターンをまとめたもの、とあります。Platform Engineering Maturity Modelは5個の観点（後述）とレベルで表現され、組織においてPlatform Engineeringがどれほどのインパクトを持つかの目安になるのではないかとされています。

ただ、あくまでこれ自体は今後改善していくための一助であり、また組織の置かれた環境次第で変動するもののため、厳密に適用するよりは、この先にどういうゴールが待っているかについて見通すために用いた方がいいともあります。

上記のようなものですが、今後どういう形で改善していけるかについての指針を得るには有用そうですので、実際にどう活用できそうか、を考えてみることにします。

Platform Engineering Maturity Model Table

Platform Engineering Maturity Modelにおいては、Model Tableという形で観点とレベルの概要がまとめられ、個々の観点とレベルごとに詳細が記述された構成となっています。
そのため、まずはModel Tableを見てみましょう。

Aspect
観点		 Level1
PROVISIONAL
暫定的		 Level2
OPERATIONAL
運用可能		 Level3
SCALABLE
スケール可能		 Level4
OPTIMIZING
最適化
Investment
投資		 どうスタッフやリソースがPlatformに割り振られるか？ 自発的または一時的 専任チーム プロダクトとしての開発 エコシステム化
Adoption
採用		 ユーザはどうPlatformを見つけることができるか？ 一定しない 外部からの推進 自発的な取得 参加型
Interfaces ユーザはどうPlatformを使用できるか？ 個別依存 標準ツール APIをホスト 統合されたサービス
Operations
運用		 Platformはどう計画され、開発され維持されるか？ リクエストベース トレースされる ユーザ側を補助 マネージドサービス
Measurement
測定		 Platformへのフィードバックや学習はどう行われるか？ アドホック 仕組化された 自動的に情報収集し計画 量的質的に達成度が明言

とりあえず詳細な方も見つつ書き下ろしてはみましたが、この言葉だけではわかりにくい点もありますので、詳細側も見てみましょう。

Model Detail

詳細をすべて書き下ろすと量も多いため、例示されていたシナリオを基に、要はどういうことか、を短文でまとめてみます。

Investment 投資

どうスタッフやリソースがPlatformに割り振られるか？

  • Level1 暫定的 > 自発的または一時的

ある分野において得意なエンジニアたちが有志となって整備する形となっていて、特に義務もない。

こういうベストプラクティスがあるよねという非公式なやり取りがあるくらい、という状態のようです。

  • Level2 運用可能 > 専任チーム

社内で多くのエンジニアが困っていることを、専任チームが改善を引き受けて、対応する。ただ、しばしば困っていることによる問題の度合いや、解決したことによる効果は測定されない。

困っていることを解決する専任チームがいるという状態のようです。

  • Level3 スケール可能 > プロダクトとしての開発

Platformの利用実績、メトリクスからインパクトの大きな問題を洗い出し、その上で対応する。

データを基にプロダクトとして開発運営がされるという状態のようです。

  • Level4 最適化 > エコシステム化

Platformのメトリクスから、どのくらいの貢献が会社になされているかが明確化される。

プロダクトとして運営されるだけでなく、内部向けであるがゆえに、外部向けであれば売り上げなどで測ることができる会社への貢献も含めてわかるようになった状態のようです。

Adoption 採用

ユーザはどうPlatformを見つけることができるか？

  • Level1 暫定的 > 自発的または一時的

他のチームがやっていることを聞いたり、どう実現したかの成果物をコピーして使うという状態。

特に何か整備されたわけではなく、別チームに相談して解決する、というレベルの情報提供の度合いのようです。

  • Level2 運用可能 > 外部からの推進

エンジニア組織として、標準的なツールを使うことを決め、各チームに対して自前のものでなくそれを使うための導入が行われる。ただし、チームによっては要件を満たすのが難しいケースもある。

標準ツールを使うという全体とした流れとなり、その通り実践されている状況のようです。

  • Level3 スケール可能 > 自発的な取得

Platformの上で足りない機能を各々で用意して使うことが許容される。そのため、各チームはまずPlatformの機能でほしいものがあるかを確認し、またない場合でも別の機能で達成できるケースはそれが提供される形となる。

第一の選択肢としてPlatformを使うという流れになっており、それにない場合に自分たちで拡張して使うというバランスが確立した状態のようです。

  • Level4 最適化 > 参加型

チームが標準では提供されていない機能を提供したい場合に、Platformに対して自分たちが検証した結果を基にPlatformのコア機能として使える道が開かれている。

Platformを各チームが拡張し、Platformに対して貢献してPlatformが成長していくという流れになっている状態のようです。

Interfaces

ユーザはどうPlatformを使用できるか？

  • Level1 暫定的 > 個別依存

必要になった際に、それをできる人にリクエストして作ってもらう。時折前の環境はないので、更に基板よりなチームに依頼が必要となるケースもある。

人的な依頼によって利用可能となっている状態のようです。

  • Level2 運用可能 > 標準ツール

担当チームがTerraform module、Kubernetes controller、CRD等とドキュメントを提供し、それを基に各チームが実行。

機構とドキュメントは用意されており、それを基に各チームが使用するという状態のようです。

  • Level3 スケール可能 > APIをホスト

APIが用意されており、それを介して各チームは例えばPlatform中のRDBを作成、メンテといったオペレーションや、各種情報の取得ができるようになっている。

APIという形で明確になったインタフェースを基にPlatformが利用可能になっているという状態のようです。

  • Level4 最適化 > 統合されたサービス

Proxyのような中間レイヤ、サーバレスランタイムといった拡張機能をPlatormにチームごとに追加可能となっており、またAPIだけでなくUIからカタログを選んでデプロイが可能となっている。

Platform自体に多くの拡張ポイントも解放されており、APIだけでなくUIから実行可能ともなっているように、各チームのレベルに合わせたサポートが提供された状態のようです。

Operations 運用

Platformはどう計画され、開発され維持されるか？

  • Level1 暫定的 > リクエストベース

共通的に使われているミドルウェアでの深刻な脆弱性が検出された際に、各チームが管理しているサーバ上のミドルウェアをアップデートするよう依頼し、その完了報告を基にOKとするという形で対処する。確実性は必然的に低くなる。

各チームが個別で基盤部は管理しているので、共通的な何かはない、という状態のようです。

  • Level2 運用可能 > トレースされる

共通的に使われているミドルウェアでの深刻な脆弱性が検出された際に、各チームが管理しているサーバ上のミドルウェアをアップデートするよう依頼し、各チーム側でのバックログ上で管理されていることをトレースしている。

各チームでタスク管理という観点では正規化されており、それを中央でトレースするということが行えるという状態のようです。

  • Level3 スケール可能 > ユーザ側を補助

共通的に使われているミドルウェアをアップグレードする際に、それを検証するための環境をPlatformチーム側で提供し、各チームで検証してもらう流れとなっている。

Platform上で使用している機能をアップデートしていくために利用者側を補助していくような体制を確立している状態のようです。

  • Level4 最適化 > マネージドサービス

共通的に使われているミドルウェアをアップグレードする際に、各チーム側は自前で環境をアップグレードする必要はない。アップグレード後のテストシナリオを定義しておけば、Platform側が自動的にミドルウェアをアップグレードした上でテストを実施し、問題なければ順次環境のアップグレードが行われる。

Platform上で使用している機能それ自体を利用者側がオペレーションする必要はなく、要求項目を設定しておけば、それに従って自動的にアップグレードするようなPlatformに至った状態のようです。

Measurement 測定

Platformへのフィードバックや学習はどう行われるか？

  • Level1 暫定的 > アドホック

サーベイをPlatformチーム側が行い、それのフィードバックを基に次Quarterの計画を立てる。ただ、しばしばリクエストが多すぎたり、先進的過ぎたりして常にできるわけではない。また、足りない機能は各チームが個別に対応することもある。

基本的にはアドホックな個別対応となっており、状況に応じてフィードバックや学習が行われるという状況のようです。

  • Level2 運用可能 > 仕組化された

Platformチームが一定の時間をサーベイやインタビューで収集した際にリクエストを受けたユーザ定義機能に費やす。サーベイの結果は管理され、新機能も決まった方式で社内共有される。

社内で明確化されたプロセスを基に活動している状態のようです。

  • Level3 スケール可能 > 自動的に情報収集し計画

組織がPlatformを使用している際のリードタイムやビルドタイムといったメトリクスを自動的に収集するようになっており、それをベースにPlatformチームはサービスのモニタリング、可用性安定性といった要素を実装する。

自動的にメトリクスが収集され、それを基に対応が行われるようになった状態のようです。

  • Level4 最適化 > 量的質的に達成度が明言

Platform利用時のメトリクス（ビルドタイム等）とその変化を基に対応チームが組織され、SLOの定義と対応が行われる。その対応により、各チームの利用体験を悪化させることなく問題が解消される。

対応が必要な点の絞り込みもプロセス化され、改善する際の達成度もSLOを基におこなわれる状態のようです。

上記ざっと読んでみましたが、レベル毎の差はおおむね以下のようになっているように感じました。

  • Level1 暫定的
    • 必要があった際に何か対応が行われる状態。
  • Level2 運用可能
    • 組織の中で標準化、プロセス化が行われた状態。
  • Level3 スケール可能
    • 自動化やデータを基にした判断が行われている状態。
  • Level4 最適化
    • 機能のカタログ化、SLO定義、拡張ポイントに貢献の可視化といった自己最適化が常時進むようになっている状態。

スタートアップにいるとLevel4などまで上げていくのはちょっと想像がつきませんが、社内の開発組織が巨大であれば、Levelを上げていくことで効率化される要素も増え、Levelを上げるよう「投資」した方が有利になってきそうです。
その判断も常時できるようになっているのが、Level4まで到達できた組織なのでしょう。

今の私の立場

こういうことを調べていた前提の説明になります。
私はdotDataという会社でSREという名前のついているチームに所属しているエンジニアです。
https://jp.dotdata.com/

SREと名前はついていますが、実際にやっていることは以下のようにSREっぽいこと（？）を手広くやっているチームとなっています。

  • 自社プロダクトを提供するSaaSの運用およびそのために必要となる設計実装
  • Customer Facingなチームへのデモ環境、PoC環境の構築提供および運用
  • 社内のDeploymentやサービス公開に関する技術相談・支援
  • 自社プロダクト開発チームに入ってのデモ＞PoC＞本番環境へ向けた設計実装デプロイ支援
  • クラウドコスト最適化

上記のような活動をしている中で、他チーム（＝自社プロダクト開発チーム）に入って設計実装デプロイ支援をし、それを現状運用状態に入っているSaaSをデプロイするための機構に統合し、ということをやっている際に非効率さを感じたからというのがPlatform Engineeringに興味を持った発端です。

他チームは各々自前でIaaCでリソースを定義し、一部手動も含めて開発に必要なクラウドコンポーネントをデプロイするということを行っています。そういう中に途中から入って設計実装デプロイ支援をしていると、当然やることは他チームのIaaCを基にし、アプリケーションに手を入れていく形になります。

ただ、それを最終的に現状運用状態に入っているSaaS基盤に統合しようとすると、インフラ構成や他のリソースのライフサイクルの違いなど、そういったギャップを解消しながら統合する必要が出てきます。また、実はこういう前提があった、ということもあとから出てきて時間がかかるということになりがちです。

そんな中で、そもそもインフラ構成の構築コードと、ガイドラインを予め提供してその上で進めてもらえば、以下のような利点があるのではないかと考えていたところ、これってPlatform Engineeringと通じるものがあるのではないか、こういった活動で以下のようないい点があるのではないかと考えた次第です。

  • 他チーム：既に一定の検証がされたIaaCとガイドラインを基に進められるため、初期構築が早いし、質も安定する。
  • SRE：SaaS基盤に統合するのが楽、また、明言されない前提も元のIaaCを知っているため、検出しやすい。

で、どう活用できるのか？

実際読んでみたのですが、Platform Engineering Maturity Model、特別なことは書いておらず、各Levelや観点についても、書いているパターンは正統派なんですよね。
また、Level2くらいまではプロセス化して要件をきちんと管理すれば普通に到達できるLevelなので、Level2を一通り満たす位にならないと、この先どうしていけばいいかに困ることもそうない。

一定以上に発展させるためのヒントは得られど、現時点でどこから着手すれば有効かという観点では、結局自組織依存になってしまうために現時点ではあまり活用できるかというのはなさそうという結論になりそうです。

ただ、将来的にどういう形でPlatformを他チームに使ってもらうか、というゴールをイメージするという観点では参考になりました。
まずはできるところから進めていくほかなさそうですね。

Discussion