北京
在去年的KubeCon+CloudNativeCon歐洲大會上，兩位工程師Eugenia Bergman和Hagen Tonnies分享了他們如何從一個為游戲流媒體服務的單一平臺起步，最終將整個基礎設施運營方式從項目管理徹底轉向產品思維的歷程。這一轉變的核心矛盾在于：當平臺只需支撐一個內部客戶時，年度項目規劃、預算鎖定和里程碑交付能運轉得很好；但當多個團隊接入、需求開始分化，那種“一次交付、用完即止”的邏輯就開始反噬團隊自己的節奏。
Bergman回憶，早期他們的平臺開發周期完全圍繞年度項目計劃展開：年初劃定范圍、分配預算、定義交付節點，每一項改進都被包裝成一個有起點和終點的項目，成功與否只看是否按時、按量、按里程碑完成。這套流程在支撐單一的游戲流媒體產品時，讓一切顯得可控。問題出現在平臺慢慢演化為要服務多個內部團隊后——不同團隊對基礎設施的訴求互相沖突，而項目制帶來的卻是一堆離散的能力堆積，缺乏整體向前演進的動力。
他們察覺到的第一個痛點是“一次性交付”造成的累積債。每一次平臺增強都被當作獨立項目交付，完成后即宣告結束，下一個項目的優先級總是重新排序，導致很多剛建立的能力轉頭就被擱置。平臺沒有清晰的產品定義，雖然一直在持續交付，但整體可用性和內聚性反而停滯不前。Tonnies補充說，當時的反饋循環基本是內向的，團隊只關心迭代速度、完成度和質量，卻很少有真正來自平臺用戶的驗證，整個系統優化的只是“做完”而非“長期使用價值”。
轉機的觸發來自內外部思想的混合撞擊。Tonnies提到，早期業內已有同行開始引入系統思維和產品思維，比如Prometheus和Grafana的生態文化；內部則開始集體閱讀《Project to Product》和《鳳凰項目》這類著作，很多人發現自己的痛點幾乎被全盤復述。此后，一群架構師和高級工程師組成的小型實踐社區開始密集辯論這些理念，一點點摸索出替代現有模型的方法。
他們的開發者平臺也隨之發生實質性的形態變化。以往它從來不是一個統一平臺，而是圍繞Kubernetes和GitOps實踐有機生長出來的一組能力。早期主要以Helm部署、命名空間范圍內的資源和GitLab驅動的流水線為核心，團隊通過內部開發門戶接入，大多運行在共享集群里。這套模型在標準化應用交付上很高效，但它本質上為單一服務團隊優化，沒有真正解決更復雜的多租戶和多樣化基礎設施需求。隨著公有云服務（如AWS）的引入，這種局限被進一步放大，也直接推動了向自助式、API驅動、多租戶架構的躍遷，讓平臺所有權更清晰、抽象更合理。
整個轉變可被看作一個分水嶺：一旦平臺從“內部工具”變成“內部產品”，團隊就必須從完成交付的工程節奏中抽出身來，去構建可疊加的價值路徑和真實閉環的反饋機制。對于任何正在規模化內部平臺的工程師團隊來說，Bergman和Tonnies的經歷都是一個鮮活的注腳——扔掉舊的項目地圖，不一定迷失方向，反而可能第一次看清用戶到底需要什么。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
