為何平臺工程將吞噬軟體開發？

我曾是平臺工程的懷疑論者。

2018年，我們創造了"內部開發者平臺"（Internal Developer Platform）這一術語並構建其基礎框架，助力企業實現規模化平臺建設。

此後，採用平臺工程的團隊數量每年翻倍。儘管取得顯著成功——PlatformCon等行業活動及專業社群蓬勃發展——我仍質疑這究竟是實質性變革，還是即將消退的市場營銷噱頭。

這種質疑在去年發生轉變。我開始觀察到：過去2-3年間，已有組織將80%的運維工作遷移至高度最佳化的平臺，其成效令人震驚。與高層管理者的對話揭示出兩個持續主題：產品上市時間縮短50%，平臺工程正在吞噬其他職能。更少平臺工程師支撐更多開發者，而運維、資料庫管理、安全、可觀測性及SRE等角色正被平臺吸收。包括CIO與CEO在內的決策者深度理解其平臺戰略，視其為業務增長的核心驅動力。

上市時間加速雖引人注目，但"平臺工程吞噬一切"的表述更值得關注。某大型硬體製造商CEO將其描述為"軟體開發的工業化"——從"手工小作坊"轉向"流水線生產"。儘管此模式未必適合小團隊，但對大型組織而言，這完美契合2025年及AI時代對速度、規模與安全性的要求。2010年代的"自由式"開發模式已顯不足。

我們正處於軟體開發的工業革命程序中。我們正在構建結構化數字工廠，以前所未有的速度與高標準生產軟體。平臺工程師正是這些生產線的建造者，從基礎設施到安全防護、從開發者體驗到產品所有權，各類職能現均融入平臺正規化。若您的專業技能無法適配此生產線，則將面臨淘汰風險。

參考1906年亨利·福特將手工藝汽車製造轉變為流水線生產的變革：此前家庭作坊需大量專業工種協同作業。

以租車公司SIXT為例，800名開發者僅由40名平臺工程師支撐——開發者與平臺工程師比例達20:1。相較之下，傳統架構中每5名開發者即需配備運維/安全/基礎設施人員各1名。效率與速度的提升具有里程碑意義。實現此目標需高度標準化與流程最佳化：Postgres資料庫若存在100種配置方式，系統將不可維護。

近期我收到批評意見，指出"平臺工程師"職稱較常規定義更寬泛，需具備架構、軟體開發、安全與運維等多領域技能——此觀點成立。

當下亟需明確平臺工程內部的專業細分領域。我們應加強相關討論，針對不同角色開發培訓體系、支援機制與文件框架。

平臺工程總監（HOPE）：領導崗位，統籌全域性平臺工程職能，負責制定戰略方向、確保與業務目標對齊並協調各平臺工程團隊。需具備跨架構、軟體開發、安全與運維的多領域技能。
平臺產品經理（PPM）：規劃與結構化領域專家工作，擔任平臺工程團隊與組織需求間的橋樑。透過功能優先順序排序實現價值最大化，需同時理解平臺技術細節與使用者需求。
基礎設施平臺工程師（IPE）：定義資源預設配置，維護平臺執行所依存的底層基礎設施（含伺服器、網路及資料庫），確保平臺具備可擴充套件性、可靠性及高效性。
開發者體驗平臺工程師（DPE）：聚焦平臺易用性與最佳化，透過工具鏈精簡、摩擦點消除及體驗增強，為開發者建立工具模版與文件體系。
安全平臺工程師（SPE）：維護與治理策略檢查及籤核流程，將安全措施直接嵌入開發流水線，制定並實施安全策略，確保平臺具備魯棒安全控制。
可靠性平臺工程師（RPE）：由傳統站點可靠性工程師（SRE）演化而來。職責包括設定可靠性標準、按應用需求調整資源配置。在平臺工程技術棧中，主要負責監控與可觀測性平面，並對生產環境資源平面進行精細化調優。
運維平臺工程師（OPE）：透過日常運維管理、效能監控、故障排查及更新部署，確保系統平穩執行，保障平臺持續可用性。