プラットフォーム・エンジニアリングの課題──多様なチーム能力とSREの役割
齋藤氏が所属するASTのSREチームでは、ツールや基盤整備、それらの使い方をともに進めていくという伴走型の支援に取り組んでいる。これまでインフラ基盤のデプロイや改善、セルフサービスの提供、ツールや基盤の整備にも取り組んできたという。ASTが設立されたのは2020年、わずか4年のうちにグループで使われるプロダクト数が年々増加。すると、関係者のコミュニケーションパスが非常に複雑になってきたと齋藤氏。「チケット管理で進めると、依頼が集中して処理できなくなる状況が自然発生するような構造となっていました」と課題を語る。
[画像クリックで拡大]
SREチームでは、New RelicやPagerDutyなどを共通ツールとして整備しているが、これらを単なるモニタリングやオブザーバビリティ、インシデントマネジメントだけに使うのではなく、組織全体で効果を最大化することを目指している。これらのツールを「開発チームの能力向上」に役立てようとしているのだ。もちろん、ツールに慣れるまでには時間が必要だが、長期的にはこの取り組みがチーム全体の能力向上につながってきたという。
とはいえ、これらのツール以外にも技術スタックとして、さまざまなものを採用してきたために、「エンジニアの認知負荷が非常に高い状況です。私もKubernetesのアップグレードをしながら、Vaultの設定やTeraformでのコード記述、他人のレビューを同時にこなしています。Azureに関しても開発者向けに便利なサービスを提供しており、日々の負荷は非常に大きいです」と明かす。
DevSecOps Division SREチーム 齋藤光氏
特にイオングループに連なる企業数は多く、個社ごとに開発チームの能力やリソースの規模は大きく異なる。ASTの場合、チームごとの能力にバラつきがあり、アプリケーションコードだけを書けるチームがあれば、アーキテクチャまで考えられるチーム、インフラの知識を持ちTerraformのコードも扱えるチーム、さらにはSREまで自分たちで対応できるチームも存在する状況だ。
そうした中、プラットフォーム・エンジニアリングを考える際には「誰のためのプラットフォームか？」という課題が必ず浮かび上がる、と齋藤氏は指摘する。特に、アプリケーションコードだけを書いているチームにとっては、プラットフォーム・エンジニアリングへの関心が薄く、「自分たちが困らないよう、インフラを自動整備してくれればそれでいい」という意見が多いことも想像できるという。
こうした認知負荷の高さ、インフラに対する理解の有無は、プラットフォーム・エンジニアリングにおける大きな課題だ。齋藤氏は「このギャップを埋める役割を今担っているのが、SREチームです。プロジェクトを進める中、心が折れそうになる場面もありますが、事業として達成すべき目標がある以上、SREチームがエンベデッドやイネーブルといった形で支援しています」と話す。
