我在談論平台時，我談論的是什麼

什麼是「平台」？

語言似乎很難。對於一種對大規模提升交付速度和效率來說極為重要的做法，「平台」可能是我們能使用的最模稜兩可的術語。因此，本文的標題是，這是最近我談論最多的內容。

軟體和硬體平台的定義比比皆是，通常描述應用程式可以執行的作業環境，並提供檔案系統和安全性等可重複使用的功能。

放大來看，在組織層級，「數位平台」具有類似的特性 - 一個作業環境，團隊可以建構在上面，以更快速地交付產品功能給客戶，並由可重複使用的功能提供支援。

數位平台是自服務 API、工具、服務、知識和支援的基礎，這些基礎以引人入勝的內部產品方式安排。自主傳遞團隊可以利用平台以更快的速度傳遞產品功能，並減少協調。

在 Thoughtworks，我們開發了一個模型，其中包含 平台能力的五個關鍵支柱。這些能力包括傳遞基礎架構、API 和架構修復、自服務資料、實驗性基礎架構和客戶接觸點技術。我們透過全球經驗了解到，這些是最重要的共享能力，可投資於其中以解鎖成為數位公司的能力。

本文重點介紹我們歸類為傳遞基礎架構的平台能力，包括雲端主機和 devops 工具，儘管相同的定義特徵適用於其他平台能力。

首先，非平台

幾年前，我受聘在一家大型澳洲金融服務組織擔任顧問。我們稱他們為 BigCo。我抵達現場的第一個目標是了解應用程式基礎架構、主機和運作領域正在發生什麼事。為了真正了解挑戰所在，我們決定遵循工作系統中的真實變更，並了解事情是如何完成的。

儘管在雲端和自動化方面進行了大量投資，但 BigCo 仍保留了基礎架構和運作領域中團隊的傳統安排。團隊按技術能力劃分。我們遵循了一些典型的變更，而每個變更都涉及這些團隊中的多個團隊。如果應用程式伺服器組態有任何變更，這由「中間軟體」團隊負責。然而，中間軟體團隊無法存取基礎作業系統組態，這是「中階」團隊的責任。資料庫變更必須由 DBA 團隊執行。網路變更必須透過網路團隊進行。負載平衡器變更必須由託管服務供應商執行，而防火牆變更則由不同的供應商執行。還有一個獨立的自動化團隊，他們擁有某些自動化能力，主要限於編排。當然，還有獨立的企業監控、安全性、變更和發布管理團隊。

圖 1：獨立的高度專業化基礎架構和運作團隊

這些 BigCo 團隊中的每一個團隊都在自己的管理結構下，有獨立的工作方式。每個團隊都在自己的技術領域中管理高效率，集中專業知識，外包非差異化能力，應用治理並降低成本。然而，BigCo 中沒有人衡量端對端向客戶傳遞功能的有效性。

涉及基礎架構的小變更需要數週到數個月不等的時間，這對對客戶的回應能力有很大的影響。這有很大的影響，但這還不是全部。我們注意到，當變更困難且緩慢時，變更過程中出現的任何故障都會導致進一步的延遲。這驅使工程師和經理將所做的變更數量減至最少，只對應用程式和基礎架構進行絕對必要的變更。

圖 2：應用程式傳遞團隊所需的變更需要數週或數個月

在 BigCo，這明顯導致應用程式和基礎架構的內部品質逐漸下降，而且各處環境和設定都有許多小差異。團隊已停止進行可維持或改善品質和一致性的微小改善和重構。在實務上，這是自我強化的：由於品質會影響可預測性，因此會增加變更風險，因此團隊變得更謹慎，也更難以進行改善。

因此，總而言之：在 BigCo 處理基礎架構和代管很緩慢且困難。

「積壓耦合」的影響

敏捷軟體交付的唾手可得成果始終在數位頻道中，由小型自主團隊與企業領導人緊密合作，找出客戶需求並建置滿足這些需求的功能。然而，數位產品團隊變得越快且越具回應性，對其施加的外部限制就會越大。

數位團隊通常在三個主要領域受到限制：緩慢移動的核心交易記錄系統、取得高品質資料和分析，以及共用基礎架構和營運。

我使用「待辦事項關聯」一詞，其中待辦事項是敏捷交付團隊經常使用的規劃工具。

圖 3：當變更在多個團隊的待辦事項 (工作佇列) 中具有相依性時，就會發生待辦事項關聯

這是一個簡單的概念 - 如果數位產品團隊待辦事項中的大量項目需要在另一個團隊中提出相應的待辦事項項目，那麼生產力和回應性就會大幅下降。待辦事項會在整個組織中串連，每個待辦事項都根據不同的系統進行優先順序排序。任務會在看板上取得大型紅色「已封鎖」貼紙，利害關係人會生氣，共用服務供應商會盡可能做出反應 - 通常會回應最大的聲音。

待辦事項關聯有多糟？在一家澳洲電信公司，我的同事對通過交付中心數百件工作或任務進行了一項研究。有些任務可以由單一團隊在沒有相依性的情況下完成，特別是在沒有由其他團隊成員排定工作的情況下。必須等待其他團隊的任務在經過時間上慢了 10-12 倍。因此，相依性具有真正的重大影響。

這在許多方面傷害了我們：它傷害了對客戶需求的純粹產出和回應性，並驅使我們進行更多長期規劃以更有效率地管理相依性。它也損害了團隊對成果的自負責任，而我觀察到，對於許多團隊來說，這是一個殺手級動機。團隊可能會發現很容易推卸責任，並停止尋求自己的持續改善。

身處於服務許多吵鬧的內部客戶的超負荷團隊中也不是什麼樂事。

最近「擴大敏捷」的傳統試圖以一種方式解決這個問題 - 透過引進規劃儀式，試圖調整多個團隊的優先順序。這明確地以整體減少的自主性、回應性和回應變更的能力來換取增加調整。這不可能是唯一的方法。

因此，一個好的平台必須具有一個特徵，就是減少累積耦合的數量。平台必須提供不需要提出申請和分配工作的服務。自助服務是良好平台的一個關鍵定義特徵。

平台應為團隊提供自助服務存取權。具體來說，它應允許自助服務配置、自助服務設定以及平台功能和資產的自助服務管理和操作。

半吊子的表面化私有雲

BigCo 認識到自助服務的需求，但很難想像如何透過一個根深蒂固於傳統基礎設施和思維的大型基礎設施和營運組織來達成此目標。由於已經投資於集中式自動化工具，因此第一個努力是為應用程式傳遞團隊建立一個自助服務功能，以自備基礎設施。

建立了一個自助服務工具，讓傳遞團隊能夠根據一個非常固定的範本申請運算執行個體。配置的虛擬機器執行個體是固定的，並安全鎖定以確保中央中階團隊能夠控制機隊。為了對執行個體執行有用的操作（例如安裝套件、將其連接到網路、附加儲存空間、配置負載平衡器、設定監控工具或其他任何操作），傳遞團隊需要提出申請。

圖 4：BigCo 建立了一個基本的自助服務 API，而沒有改變應用程式和基礎設施的執行方式的基本原理。結果並沒有顯著改變傳遞速度。

你可以辯稱這只是第一次反覆運算，而且這是真的，但意圖很明顯。當時 BigCo 的基礎設施和營運部門尚未準備好打破其組織孤島，並將重要的責任（因此也是存取權）轉移給傳遞團隊。即使意圖良好，逐步建立該 API 以達到所需豐富度的龐大工作量也是不可行的。

我們稱這種方法為「表面私有雲」- 重新標記現有的虛擬化平台，讓交付團隊以非常受限的方式使用，而沒有真正意圖減少集中控制的數量。

同時，在 BigCo 中，一個交付團隊在平行努力中解鎖了直接使用 Amazon Web Services (AWS) 以進行生產系統的能力。一旦先例就緒，交付團隊便加入了使用 AWS 的搶購行列。

AWS 是交付團隊直接使用的引人注目的平台：它完全是自助服務，並且具有明確的責任界限。「您建立它，您執行它」成為了口頭禪，其中 Amazon 建立並執行平台直到 API，並確保其具有高度可用性，而您的應用程式交付團隊建立、配置和執行位於頂部的應用程式。

這就是故事的結局嗎？

自主性加速上市時間，增加創新

我所遇到的多數組織都有一個預設設定為「建立以供重複使用」：由風險規避和成本降低結合驅動的能力集中化。

圖 5：多數組織預設為集中強制技術選擇以獲得成本效益

在過去幾年中，我很幸運能成為一家大型澳洲（和全球）科技公司技術領導團隊的一員，該公司在線上擁有龐大影響力，我們稱之為 WebBiz。擁有數百名工程師，他們規模夠大，可以面對與 BigCo 相同類型的許多挑戰，在基礎設施、應用程式和資料方面擁有不小的遺留問題 - 但 WebBiz 規模夠小，可以看到快速的改變和改善。

在我任職 WebBiz 期間，我們開始從將多數應用程式部署在租用資料中心的虛擬化平台，轉移到新的預設部署目標 AWS。我們還將應用程式和（多數）基礎設施的建立和執行責任轉移到產品團隊，這是從傳統的中央作業到 DevOps 最完整的轉變，我見證了這一點。我相信從「您建立它，您執行它」的心態開始一個小型組織實際上並不困難，但進行轉變需要勇氣和願景的連續性。WebBiz 在這方面做得非常好。

作為遷移的一部分，WebBiz 的產品團隊獲得了對如何配置和執行堆疊的每個部分的完全自主權。這種方法被稱為「團隊管理基礎設施」- 儘管早期建立了一些預設，但每個團隊都會在堆疊的每個部分做出自己的決策，幾乎沒有中央授權。

WebBiz 成功地扭轉了組織的典型預設偏見：偏好技術多元化和發明。這提高了員工參與度，工程師在技術堆疊中獲得更深入的經驗，推動發明，快速建立對所部署內容的責任感，並消除了團隊依賴性的主體。它還吸引了對承擔所執行內容的責任、對自主性反應良好以及對解決困難的業務和技術問題感興趣的工程師在 WebBiz 工作。

技術多元化增加阻力

然而，對於所有好處，轉移到完全自主化是有明確成本的。透過採用 AWS 作為平台，WebBiz 已移除與集中式基礎架構團隊的積壓耦合。然而，WebBiz 中的每個團隊現在都被迫針對建置和操作其基礎架構的每個面向做出多項決策。

圖 6：雲端原生景觀（來源： www.cncf.io)

上面是 雲端原生景觀 的最新版本：嘗試擷取一些常見的開放原始碼和產品提供，依據建置雲端原生架構的關注領域分組。這是一個擁擠的地圖，而且僅是最完善的提供。對於這些領域中的每一個領域，團隊必須評估選項並選擇一個符合其需求的提供，然後學習如何整合和操作該提供。

除了重複基礎架構的維護拖累之外，每個團隊持續研究和評估其基礎架構選擇還有一個持續的開銷。另外還有一個摩擦，會對在執行明顯不同的堆疊的團隊之間的技能甚至員工轉移造成阻礙。

WebBiz 現在開始建立一個定義更清楚的傳遞基礎架構平台 - 一組引人注目的預設值，產品團隊可以使用這些預設值來減少拖累並提高其生產力。

但是他們是否冒著失去自主化帶來的優點的風險？

平台作為內部產品

在自主多元化和強制整合之間找到正確的平衡是一場真正的奮鬥，而且這更難以事先預測。找到此平衡的成功關鍵要素是平台必須引人注目，它們不能僅靠強制令來維持。您現有的共用基礎架構功能具有壟斷性，傳遞團隊沒有可行的替代方案。一點競爭是推動產品思考的必要要素，確保每個平台功能都增加價值，而不是造成限制和耦合。

什麼讓一個平台具有吸引力？以下是幾個想法

• 對於絕大多數的使用案例，該平台都是自助服務的。
• 該平台具有可組合性，包含可獨立使用的離散服務。
• 該平台不會強迫交付團隊採用僵化的工作方式。
• 該平台的入門使用快速且便宜，並具有簡易的入門管道（例如快速入門指南、文件、程式碼範例）
• 該平台擁有豐富的內部使用者社群，可供分享
• 該平台預設安全且合規
• 該平台是最新的

最終，當使用平台功能比建立和維護自己的東西更容易時，交付基礎架構平台就是具有吸引力的。Netflix 將其集中式工具描述為「鋪好的道路」- 團隊不必使用這些工具，但有責任維護其自身替代方案的所有成本。

一個平台也應該不只是軟體和 API - 它是文件、諮詢、支援和傳福音，以及範本和指南。

等等…這不是「DevOps 團隊」嗎？

做得不好嗎？是的，它可能是。

我們完全輸掉了整個「DevOps」不是角色/團隊/工具的戰鬥，不是嗎？我們一直輸掉這些戰鬥。也許下次採用新的策略？

-- Phil Calçado

（我還沒有準備好承認在 DevOps 上的失敗：所以如果你不確定，如果你有一個名為「DevOps」的團隊，那麼這個詞並不表示你認為它的意思。）

你可以選擇建立一個團隊來建立和操作交付基礎架構平台 - 我認為在大多數情況下，這將是開始的最佳方式。如果是這樣，你應該非常清楚平台團隊與其客戶的責任範圍 - 為清楚起見，我將其稱為應用程式團隊。

應用程式團隊建立、部署、監控，並隨時待命處理他們在平台上提供和部署的應用程式元件和應用程式基礎架構。平台團隊建立、部署、監控，並隨時待命處理平台元件和基礎平台基礎架構。

理想情況下，平台團隊甚至不知道在平台上執行哪些應用程式，他們只負責平台服務本身的可用性。

透過這種方式，應用程式團隊和平台團隊都有責任建立和執行自己的產品。「你建立它，你執行它」仍然適用。

我從何開始？

在建立交付平台方面，有一些成功的前提條件。首先，你可能已經在你的旅程中 遠離「專案」 作為資助和配置技術交付的主要機制。平台是一個產品，需要一個長壽且穩定的產品團隊負責建立和執行。

其次，您必須願意將應用程式的部分或全部執行責任轉移給應用程式團隊，並遠離集中式運作和支援。平台提供工具和服務，讓應用程式團隊可以對其建置的內容負責，在支援集中化的同時，這是不會發生的。

第三，您必須願意放棄實作的嚴格一致性，以換取您授予自主應用程式團隊的自由和責任。

現在，有一些陷阱。

• 您的平台不僅是基礎架構、工具和您可以安裝的 API。為了有效，您必須回答您的傳遞團隊將如何快速採用新功能、他們將獨立做出什麼選擇與使用明智的預設值，以及您將如何持續維護這些功能。這將需要一些內部諮詢技能、培訓和傳播。
• 您不知道需要什麼平台功能，因此請根據真正的已驗證需求從小處著手。從應用程式團隊收集已經驗證的解決方案，並嘗試與將使用這些功能的團隊合作，建立並測試功能。
• 請務必小心，不要只將平台標籤套用在您已經擁有的有限虛擬化主機和鎖定的集中管理工具上。