プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン

8章プラットフォームのリアーキテクチャ

初期の技術的な判断を後悔しないなら、それはつまり、おそらく作り込みすぎたということです。

—Randy Shoup

5章では、新しいプラットフォームを提供するプロセスについて説明しました。小さく始めて、厳選した少数の顧客とパートナーシップを組み、段階的な提供を通じて顧客ベースに幅広い有用性を持つものを構築していることを確認するというものです。7章では、プロダクトロードマップを超えたロードマップ計画の取り組みについて概説し、KTLO作業と新機能への投資と、運用効率、スケーラビリティ、セキュリティなどを向上させるシステム改善とのバランスを取る方法を伝えました。これらはすべて素晴らしく聞こえます。小さく始めて、勢いを得て、機能だけでなくシステムメンテナンスへの定期的な投資によって物事を順調に進め続けるというわけです。何か問題になる可能性があるでしょうか。

このプロセスを完璧に実行したとしても、壁にぶつかることがあります。システムの負荷が増加すると、段階的なシステム投資を行っているにもかかわらず、より多くの運用上の問題が発生し始めます。KTLO作業は負荷の増加と共に増大し、その結果、チームがシステム改善や新機能を提供する能力が低下します。最終的に、最高のソフトウェア開発者たちは去っていきます。これは燃え尽き症候群が原因ではなく、進歩が起きないことに対するフラストレーションが原因です。重要なインフラは時が止まったように凍結され、ビジネスにとって重要なままでありつつも、新しい機能をサポートできなくなってしまいます。

なぜ段階的なシステム改善では、この状況を防げないのでしょうか。問題は、これらの改善はシステムをスケールさせるための短期的利益は大きい一方で、焦点が狭いがゆえに、システムのアーキテクチャにおけるより深い欠点への対処としてはうまくいかないことです。 ...