谷歌平臺工程五個誤區

盲人摸象的故事讓我們明白：為什麼人們會對一個新話題產生分歧，如果只從自己的角度看待問題，他們就會錯過整體。

平臺工程是一種相對較新的軟體交付方法，IT 組織和軟體工程團隊正在研究它：對於它是什麼、它能做什麼以及為什麼應該或不應該採用它存在很多分歧。

誤解 1：開發者門戶和內部開發者平臺是同一回事
開發者門戶是一個使用者介面，可供開發者訪問文件、API 和工具。

然而，內部開發者平臺不僅僅是一個門戶，它是一種工程化產品，旨在解決現實世界的問題，例如：

• DevOps 超載或認知負荷：由於現代軟體系統日益複雜，團隊成為瓶頸。
• 開發人員摩擦：團隊與基礎設施、工具、政策和流程互動的可量化減速。

• 開發人員主要與開發人員門戶介面進行互動，而開發人員平臺隱藏在其下方。
• 開發人員平臺透過使用黃金路徑實現開發者自助服務。該平臺透過編碼實踐、設定公司範圍的配置和應用安全控制等方法抽象了技術複雜性。

誤解二：我們不需要內部開發者平臺
平臺工程從建模您當前的流程（或其改進版本）開始，並構建軟體來為您完成此操作，而不是要求每個團隊都成為 DevOps 實踐專家。

這可以從簡單的 CI/CD 管道開始，並且可以透過一致的可觀察性或託管基礎設施服務進行改進。

透過將這些元件整合在一起，平臺就出現了。

向開發人員團隊展示抽象概念，以便更好地將這些元件整合在一起，形成一致、可用的開發人員體驗，這是平臺工程團隊的職責，而內部開發人員平臺是實現這一目標的手段。

平臺工程涉及的不僅僅是編寫程式碼。雖然編碼是一個重要方面，但真正的價值在於系統設計、整合、可擴充套件性和確保無縫的使用者體驗。它涵蓋了系統如何通訊、資料流、操作擴充套件以及跨團隊協作。

誤解三：平臺工程“只是高階 DevOps”
DevOps 是一種組織和文化運動，旨在提高軟體交付速度、提高服務可靠性並在軟體利益相關者之間建立共享所有權，其中DevOps 實踐包括

• 版本控制
• 持續整合
• 基於主幹的開發
• 持續測試
• 持續交付
• 建築學
• 雲基礎設施
• 測試管理

• 採取以開發人員為中心的方法
• 自動化和基礎設施即程式碼 (IaC)
• 安全性與合規性
• 可觀察性
• 連續的提高

誤解四：平臺工程“只是自動化”
平臺工程確實是自動化，但平臺是作為產品交付的，並且為完整的服務生命週期而設計的，而不僅僅是被動地附加。

自動化讓團隊在管理系統時減少了人工干預的需要。這可以簡單地完成，例如使用 shell 指令碼，也可以更復雜、更細緻、更可擴充套件。一般來說，當人們嘲笑某些東西“只是自動化”時，他們指的是大量經常中斷的瑣碎 shell 指令碼。

事實確實如此：自動化實際上可能會帶來新的、更難解決的問題。因此，避免不受控制的自動化是可以理解的，因為系統開始失敗不是由於自動化的質量，而是由於社會技術壓力，如對訊號的誤解、誤解的設計、錯誤的假設或不一致的激勵。

誤區五：平臺工程只是最新的時尚
軟體開發團隊的認知負擔顯著增加：當您要管理分佈在許多計算資源群中的數百或數千個微服務時，您根本無法同時深入瞭解基礎設施層和應用程式層。

如今，平臺工程解決了一些現實世界的問題，即：

1. DevOps 超負荷，又稱認知負荷——當團隊試圖管理現代軟體日益複雜的過程時，他們就會成為瓶頸
2. 開發人員摩擦 -團隊與基礎設施、工具、政策和流程互動時可量化的減速。

平臺工程是一個協作領域，需要與產品團隊、設計師、安全專家和其他利益相關者進行無縫溝通。最佳解決方案源自不同團隊彙集集體專業知識。

雖然技術敏銳度必不可少，但同理心、溝通能力、適應能力和理解更廣泛的業務目標等軟技能也同樣重要。解決方案是為有真正需求的真實使用者而構建的，而不是憑空而來。

平臺工程與 PaaS 有何不同？
平臺即服務 (PaaS) 早於平臺工程，但它並不總是適合某些團隊。您可能會問，平臺工程與 PaaS 有何不同？

雖然 PaaS 提供了高效構建應用程式和配置必要底層基礎設施的技術，但它需要周圍的人員和流程生態系統才能成功採用。
平臺工程為團隊提供了一種方法來構建產品的抽象或擴充套件，包括 PaaS，實施適合其組織的約束或自由。

換句話說，平臺工程是對 PaaS“以技術為中心”模型的回應，PaaS型不適用於可能需要進一步定製的組織。

總之，平臺工程是一種超越編碼的整體方法，透過工程平臺、協作以及技術和軟技能的結合來解決現實世界的軟體交付挑戰。