プラットフォームエンジニアリング成熟度モデル etc.：DevOps/SRE/Kube WeeklyUpdate (23/12/12-19)
以下の３つの記事から気になったもの & 個人的に気になったものを毎週紹介しています。
DevOps Weekly（ https://devopsweeklyarchive.com/ ）
SRE Weekly（ https://sreweekly.com/ ）
KubeWeekly（ https://www.cncf.io/kubeweekly/ ）
DevOps Weekly
DevOpsチームが2024年に向けて知るべきこと
DevOpsの現状と、来年に向けて考慮する必要があることに関する記事です。
DevOpsのルーツは変わらず、常に開発者と運用担当者が協力することにある。これを助けるアプローチとしてSPACEフレームワークがある。
また、Backstageプロジェクトのエンジニアリング責任者である Helen Gruel 氏は、2024年に必要になるものとしてはソフトウェア・テンプレートのコンセプトが挙げられると語っている。
ソフトウェア・テンプレートというのは、新しいプロジェクトを簡単に開始できるように、組織のベストプラクティスをテンプレートとして標準化し、数クリックだけで環境構築が可能にするものです。
最後にはCopilotをはじめとする生成AIが生産性を向上させる話についても触れられていました。
SRE Weekly
SLIについて
SLIについて詳細に書かれています。
特にSLIのアンチパターンについても詳細に書かれており、非常に良い勉強になりました。
Kubeweekly
プラットフォームエンジニアリング成熟度モデル
CNCFのプラットフォームWGから、プラットフォームエンジニアリング成熟度モデルがリリースされました。
記事から抜粋
注目すべきことに、成熟度が上がるごとに、資金と人の時間に対する要件が増大します。したがって、最高レベルに到達すること自体が目標であってはなりません。各レベルでは、その段階で現れるべき資質について説明します。読者は、必要な投資を考慮して、自分の組織と現在の状況がこれらの特質から恩恵を受けるかどうかを検討する必要があります。
ここの点について、最高レベルに到達することを目標とすると、組織規模にミスマッチしたりといった問題があったりすると思うので非常に共感しました。
モデルの見方
リンク先に記載のあるように、各セクションごとにレベル分けされています。
例えば、Investmentの項目では以下のようにレベル分けされています。
- レベル1：暫定 — 自主的または一時的
- レベル2：運用可能 — 専任チーム
- レベル3：スケーラブル — 製品として
- レベル4：最適化 — 有効なエコシステム
例えば、ある組織ではまだPlatformチームというものは存在せず、一部の人がPlatformの機能を提供している場合はレベル１となります。
こういったように、このモデルを用いてどれくらいプラットフォームエンジニアリングが成熟しているかをレベルで示すことができます。
ただ、最初にあったように個人的にも最高レベルを目指すのは組織の体制や規模などによって合わないケースもあるかと思います。例えば、大企業であればプラットフォームチームを新設することはできるが、比較的小さいベンチャー企業であれば、そもそもプラットフォームチームが必要なのかという話になると思います。
こういった点では、自分たちにとって何が最適なのか、どうあるべきが理想なのか、という点、改善すべき点を見つけるためのモデルであると認識できます。
最近盛り上がっている分野ではありますが、事例を見ているとやはり大きな企業で実践されているケースが多く、SREが流行り始めた頃に似ているのかなと個人的に感じました。
オライリーのSRE本を読んだものの、イマイチ自分たちの組織にフィードバックするにはミスマッチな部分が多いと感じる人が多かったのかなと勝手に想像しています。それと同じように、Platform Engineeringも大企業だからできること、というように今は捉えられてしまっている点もあるのかなと感じています。
今後もPlatform Engineeringについて、キャッチアップしていければと思います。
まとめ
来年開催予定のPlatform Engineering Conferenceの運営に申し込んでみました。(今はもう希望者がいっぱいになってしまったため、締め切ってしまったそうです)
今年ももうあと１週間ほどですね。来週は気が向いたら書こうと思います。（良いお年を）
Discussion