基礎技術基礎架構定義為“ 用於建立，發展和運營我們的業務的軟體和系統。”包括雲服務，構建工具，編譯器，編輯器，原始碼控制系統，資料基礎架構（Kafka，Hadoop，Airflow…），路由和訊息傳遞系統（Envoy，gRPC，Thrift…），Chef，Consul，Puppet，Terraform等。

達到一定規模的公司通常會建立一個或多個團隊來負責這些工具的不同子集。他們被命名為“基礎設施”，“平臺”，“基礎”……在本文中，我將使用“平臺團隊”。如果您是其中一員，您將知道平臺團隊的生活很艱難。

很多工作都是要在標準化和自治之間找到適當的平衡。為了產生有意義的影響，平臺團隊依賴於企業或公司組織內的標準。試圖為每種可能的語言生態系統，框架，資料庫，訊息傳遞系統等提供支援，這會使平臺團隊變得過於專注而無法發揮作用。

另一方面，尊重其他團隊的自主權來制定自己的技術決策也是明智的。平臺化的平臺團隊可能會冒著光顧的象牙塔式住宅的麻煩，給其他工程團隊帶來反覆無常的選擇。標準化和自治是複雜的因素。

如果您將此問題乘以20怎麼辦？如果您有20家公司提供支援，每家公司都擁有自己的技術，文化，慈善和恐懼症，決策家譜以及自己的平臺團隊，那麼該怎麼辦！

那是我團隊在Adevinta的工作。Adevinta建立了線上市場。他們每個人都需要以自己的方式與眾不同。同時，它們都共享許多其他不需要相同的點點滴滴。實際上，如果它們一次構建並由所有人共享，則更具成本效益。其中大部分屬於技術基礎架構類別。我的團隊致力於這種型別的管道。

作為平臺團隊創造價值

平臺部門屬於企業的成本中心，這並不意味著它們對公司沒有任何價值。相反：Kubernetes叢集對於業務至關重要。很難用一幅圖解釋為什麼工程團隊應該花費從EC2遷移到Kubernetes，而不是僅僅交付更多可賺錢的功能。從某種意義上說，成本中心為利潤中心提供動力。這就是平臺團隊應該意識到自己受到持續審查（無論是否可見）的原因。企業總是會懷疑，我們為什麼要支付這支昂貴的工程師團隊？亞馬遜，谷歌，微軟，數字海洋，Heroku或其他任何人不能提供這些人的服務嗎？我們不能利用 由許多商業公司資助的許多開源專案，而在其他地方使用人員嗎？

當平臺團隊（有意或無意）構建具有第三方替代方案的系統時，他們將在不平衡的競爭環境中競爭。 平臺團隊應真正避免與AWS，Google或任何商業公司競爭，比如他們自己的CI系統是否優於商業的整合系統，市場將以比預期更快的速度趕上來，並使平臺團隊變得多餘。每個平臺團隊都應該問自己：我們的與眾不同之處是什麼？我們提供什麼比使我們的公司值得投資於我們的團隊，而不是讓那些工程師投入產品更有價值？

到目前為止，回顧一下：由於平臺團隊是成本中心，因此他們必須真正專注於制定與業務相關的清晰，現實的價值主張。他們還必須確保其影響對企業而言是可理解的並且是可見的。最後，他們必須確保自己仍屬於快速發展的行業。

我們的PaaS

我的團隊專注於PaaS，可幫助Adevinta的工程師在雲中構建，部署和操作軟體。我們主要關注無狀態工作負載（例如微服務）。

我們對產品工程師的建議很簡單：“ 看，我們知道您在競爭激烈的市場中奮鬥。我們的任務是幫助您贏得比賽。您更喜歡自己做管道？我們尊重您。但是，如果您希望將注意力集中在產品上，我們將有一個領域專家團隊為您服務。我們會盡力為您提供所需的技術基礎架構，以便您專注於贏得比賽 ”。

我們定義了一條黃金之路：減少了一系列精幹的，行之有效的工具選擇，這些工具可以有效地構建，部署和操作微服務（我們支援的核心繫統在下面的左側幻燈片中）。每個工具在它們的類別中是最好的嗎？可能不會。但是我們知道他們可以完成工作，在行業中得到良好的支援，維護和標準化。它不是關於區域性最優，而是關於全域性最大值。

這也不是要選擇一堆隨機的零件，而是給產品團隊一個類似於宜家的平臺，他們必須逐個組裝。

我們將GitHub，Travis，Artifactory，Spinnaker，FIAAS，Kubernetes，Prometheus，Datadog，Sumologic，ELK捆綁在一起。

我們提供的主要價值在於類似人體關節或膠水。我們是如何將所有這些系統整合在一起的。我

們的PaaS支援由多個模組化元件組成，試圖成為一種 可穿透的抽象。主要好處是：

• 避免輸掉與商業公司的戰鬥。我們每個組成部分背後至少都有一個完整的公司。期望我們能聘請5-7名工程師（佔團隊的1/4！）來針對擁有20名員工的企業構建內部配置，以替代CI系統，CD系統，指標平臺等幾乎是不現實的。或50倍的容量。相反，我們注重的是具體針對我們的 公司，裁剪過的，現成的解決方案，我們的需求。商業競爭者更可能將注意力集中在該行業的大部分通用產品上。
• 對於那些不能或不會使用整個捆綁包的團隊來說，定義明確的清晰度很重要。這是能夠像我們一樣支援高度異類的公司和團隊的要求。我們經常看到採用其中一種工具的團隊如何逐漸逐漸採用其他全部工具，因為他們獲得了信任，並意識到我們可以免除他們進行大量無差別的繁重工作的麻煩。
• 相同的靈活性使我們能夠在合理的時候更換單個零件，從而對使用者的影響最小。我們當前的一項舉措是確保升級或切換這些元件對使用者完全透明。

衝擊小，重複多次

我們使用的策略之一是發現可以引入對整個表面產生較小影響的工具的位置。這在減少開發過程中的工作量方面非常有效。

在將新變更合併到主樹中涉及的大多數任務中，可能只有真正需要涉及人腦的兩項工作：編寫程式碼和進行審查。我們著手使開發過程中的其他許多瑣事自動化：分配審閱者，分析覆蓋率和靜態分析報告，傳播依賴關係更新，使分支機構保持最新，合併已批准的PR ...這些動作中的每一個都可能具有影響很小。但是，乘以數百名工程師的人口，一個月又一個月就能得到規模經濟。

等等，您之前說過，我們應該避免與商業公司競爭。 GitHub在今年早些時候釋出了Actions，您剛才提到的一些自動化似乎與公共GitHub上的自動化非常相似。這是否意味著您的團隊已經過時了？

記住建立差異化因素的要點。使得PaaS的核心功能遲早會變得商品化。但是膠水是另一回事。我們的區別很簡單：GitHub動作只能對GitHub事件做出反應。我們的自動化可以對整個Adevinta開發生態系統中的所有事件做出反應。

因為我們沒有花太多時間來構建核心工具，所以我們可以專注於膠水。我們的Devhose元件可以從開發生態系統中的每個工具（GitHub，Travis，Spinnaker，Artifactory，JIRA，Slack，Kubernetes甚至是Golden Path之外的幾個工具）收集事件，並將其儲存在日誌中，並在“工程事件匯流排”中進行廣播。我們還圍繞它構建了一些工具，使我們能夠輕鬆實現與生態系統互動的新功能。例如，我們最近原型化的一個機器人在Kubernetes中偵聽事件，檢測到被殺死的Pod，收集故障排除資訊並將其傳送到Slack通道，以便向擁有該服務的團隊發出警報。

多虧了在膠水上的投資，當GitHub Actions達到企業版時，它將帶來我們可以利用的價值，而不是存在的威脅。

良性反饋迴圈

在事件匯流排中註冊和廣播我們開發人員生態系統中發生的所有事情，對於多種用途而言非常有價值。其中之一是對開發過程本身建立見解。

我們構建了一個名為Ledger的系統來幫助解決此問題。這是一個事件使用者，它從Devhose的事件匯流排中讀取資料並處理所有型別的生產率指標。我們的參考文獻之一是 Accelerate 及其年度“發展狀況”報告（2018年， 2019年）。他們的主要主張是軟體交付團隊的績效可以而且確實為公司提供了競爭優勢。這得到了廣泛的行業研究的支援，該研究將特定的實踐與開發和交付技術的最有效方法結合在一起。這正是我們團隊的使命。

作者確定了捕獲開發和交付過程有效性的四個關鍵指標：變更準備時間，變更失敗率，部署頻率和恢復時間。這些可用作高階績效指標，可可靠地衡量組織實現其目標的能力。

因為我們為大多數工程過程提供管道，所以我們在正確的位置進行測量。這是我們有關連續交付的儀表板之一，包括“部署頻率”（加速指標之一）。

使用我們PaaS的團隊可以立即使用這些技術，包括更多指標：構建持續時間，程式碼覆蓋率，靜態分析問題，安全性問題，更改的前置時間，有關程式碼審查過程的統計資訊等。

比如“拉取請求”大小與在其團隊中合併的時間之間的相關性：

• 顯而易見，小型PR的合併速度更快。實際上，只有幾十行的差異使合併時間從幾小時到幾天增加了一倍。
• 即使合併時間隨PR大小而增長，但看起來非常大的PR（最後一個儲存桶）合併所需的時間要少得多。您可以猜測為什麼。

這個例子很好地說明了Ledger如何幫助我們影響最佳實踐，而不會引起對抗，執行或疏遠工程師。我們沒有提出任何意見。我們顯示了超過2年的價值資料，這些資料可用於整個團隊，整個公司，但絕不會公開個人身份資訊。我們關心的是團隊的績效，而不是負責多少程式碼覆蓋範圍。這不是管理人員用來衡量績效的工具，而是使團隊瞭解並做出有關其流程的明智決定的工具。

同樣，這與SonarQube之類的工具是否有些重疊 ？絕對是 但是我們有差異化因素。我們可以分析開發過程中的所有內容，而不僅僅是程式碼質量。我們可以為團隊量身定製最適合的部署和釋出工作流程。我們可以使用特定於Adevinta組織結構圖的組織資訊來豐富資料。我們可以將質量與流程中的其他階段相關聯（例如，我們要進入的下一階段是回答諸如“高程式碼覆蓋率是否與較少的事件相關？”之類的問題）。我們可以按需重新處理2年以上的原始資料，並在開發它們時生成新的統計資訊（或修正錯誤:)。

加速報告指出，可以兩種方式使用這些指標。團隊可以告知其軟體交付效能的改進。組織可以學習如何通過非技術利益相關者可以理解的指標來支援工程生產力。換句話說，通過提供這些指標，我們促進了技術與業務之間，成本與利潤中心之間的對話。正是因為我們衡量團隊的生產力，所以我們也可以衡量我們的工作在多大程度上實現了我們的使命：支援團隊以最佳狀態交付。

投資元件

有時我們會投資於平臺的元件。

在演講中，我沒有時間討論 Spinnaker，在那裡我們與Netflix，Google，Target和許多其他公司一起（並且一直是）活躍的撰稿人已有4年了。成為社群的一員使我們更容易地獲得對我們有意義的上游功能，例如雲形成支援或 與Travis的整合，以及數十個錯誤修復和其他改進。

但是，內部投資的最佳示例是我們在EC2上構建和運營的Kubernetes叢集。不可避免的問題是：為什麼不使用EKS，GKE或其他託管解決方案？

“膠水”策略應該已經浮現在腦海。

以下是Kubernetes原始安裝提供的內容以及叢集提供的內容的簡化比較。一個簡單的Kubernetes叢集可以工作，您可以排程容器，但是僅此而已。GKE，EKS等提供的功能比左圖略多：它們可以自動縮放節點並處理其他基本操作負擔。但是，它們仍然遠遠不能滿足希望安全執行生產工作負載而幾乎沒有運營負擔的產品團隊的典型需求。

一些差異例子：

我們的叢集是多租戶的，允許多個市場安全地共享基礎架構，同時通過更高的密度來優化成本。我們處理多租戶的所有弊端。我們為每個租戶處理網路隔離。我們提供合理的預設值，pod安全策略等。我們向上游貢獻的NGINX入口控制器新增了一個驗證Webhook ，以減小破壞NGINX配置的入口 爆炸半徑。

我們在多個地理區域維護叢集。這對於Adevinta的一些中央團隊至關重要，這些團隊建立了諸如訊息傳遞，信譽系統等集中功能，這些功能將在多個市場中使用，這些市場服務於遙遠的地理位置（從歐洲到拉丁美洲）的使用者。我們的叢集提供了一個統一的，託管的執行時環境，靠近所有可以部署中央功能的市場。

在每個群集中，我們都提供開箱即用的整合。您會利用cert-manager和Let's Encrypt獲得自動證書 。使用者可以使用通過我們公司的SSO生成的身份驗證令牌。他們通過簡單的配置選項選擇自動獲取的指標並將其傳送到Datadog或我們的內部Prometheus。日誌提供了相同的功能。

使用者可以避免學習完整的Kubernetes，而可以使用 FIAAS（基於Kubernetes的商品抽象）。它是在大約7年前在我們的一個市場中內部建立的，並於2019年初進行OSS開發。

在每個群集中，我們定期執行自動金絲雀測試，以部署規範的應用程式並測試連線性和大多數整合，我們嘗試比使用者更早地發現問題。我們的團隊提供專職的24/7/365通話服務。

我們會進行全棧升級。因為Google或AWS可能會升級您的Kubernetes版本，但不會在乎您在那裡執行的所有內容的完整性。我們的升級速度比GKE / EKS慢，但何時才能確保群集中捆綁的整個堆疊都能正常工作，而不僅僅是Kubernetes的核心。

並且，我們可以深入瞭解您的費用（直至pod級別），並通知使用者有關過度配置的潛在節省。這是帶有此資訊的Grafana儀表板的PoC：

在提出明確的主張之前，我已經提出了要點，以便在商品選擇商品化後便可以輕鬆轉向商業選擇。這是我們與EKS合作的策略。我們密切關注其路線圖，並已向AWS提供了有關我們需求的反饋。一旦對我們來說，EKS是適合Kubernetes的基礎安裝，我們就準備在頂部提升和轉移我們的整合。

零摩擦入門

所有這些（可能）非常酷，但是如果工程師需要數週或數月才能開始使用它，沒有人會這樣做。這是一年前我們面臨的最大挑戰之一。PaaS的核心元件大部分都在那兒，但是每個團隊將不得不花費數天或數週的時間在其儲存庫上手動配置它們。在過去的一年中，我們在簡化入門流程上投入了大量資金。我們將類似於宜家的經歷變成了幾乎無縫的過程。使用者獲得一個Web介面，輸入其儲存庫URL，單擊一個按鈕，然後我們的自動化程式便從那裡獲取它。他們的儲存庫需要約10分鐘的時間自動配置為CI / CD管道，然後部署到其團隊的私有名稱空間，並與度量標準和日誌記錄系統整合。如果某些操作失敗或需要我們的平臺團隊採取手動操作。

這裡有一點關於自動化的重要性，但是我想強調一下。如果您認為平臺團隊與商業公司具有相當大的競爭範圍的主張，則 UX使用者體驗專家是必不可少的。一個足以服務數百名工程師的龐大團隊必須為優秀的UX設計人員保留人員。它將得到回報。您不僅將不再向工程師施加後端UI，而且因為平臺團隊將學習如何理解使用者的需求，測試他們的假設（其中大多數是錯誤的），他們對他們的影響工作，並提供更專業的產品。

負責這些自動化和UI的團隊一直在使用入職過程中收集的儀器資料來改善體驗，提高故障率並掩蓋極端情況。上個季度，他們著手解決平臺中的其他難題。例如，對失敗的部署進行故障排除。聖誕節後不久，我們計劃釋出一個團隊儀表板，其中包含由給定團隊維護的所有應用程式。它總結了每個狀態，並突出顯示了何時發生構建，部署管道或執行時失敗的情況，以及從PaaS中的任何系統收集的相關資訊。再次，膠水。

變化很痛，我們也應該感到

無論我們為改善使用者的入門體驗付出了多少努力，最終，我們都將工程師從已知領域，其內部基礎架構EC2或他們今天執行其服務的任何地方轉移到了未知領域一。在某個時候，每次遷移都像這樣。

發生這種情況時，我們團隊中的某人應該和他們一起漂流。

特別針對中型/大型遷移專案，我們至少分配1-2名工程師來支援現場團隊。舉個例子，我們現在有一個正在進行的遷移專案，該遷移專案旨在從西班牙所有站點遷移約200個微服務。幾個月來，我們的團隊中的工程師以及西班牙阿德溫塔內的本地Platform團隊一起坐在一個共享的座位區中。兩者共享OKR，定期計劃，每週同步等。在我們先前與Subito.it團隊的合作中，我們的三名工程師在本季度內前往義大利呆了幾個星期。我們還建立了不同的研討會，供我們重新使用並適應新加入的團隊，包括Kubernetes基礎知識，動手練習等。

與我們的使用者緊密合作有兩個關鍵成果：

• 信任：產品團隊中的工程師不再以鬆懈的態度來感知平臺團隊中的工程師，但是實際的人卻可以放心地向他們提問。市場上的本地平臺團隊開始將我們視為合作伙伴，而不是存在的威脅。
• 我們平臺團隊的工程師學習產品工程師的需求，並獲得使用我們構建的工具的感受。他們還利用本地平臺團隊的專業知識，這些團隊已經在各自的市場中從事該領域多年的工作。儘管很難離開您的團隊數週或數月，但這種經歷令人大開眼界，每個人都為我們的團隊帶來了寶貴的見解。

工作正常嗎？

從本質上來說這是一個顛簸的旅程，但是是的。我們如何衡量？

如上所述，像Accelerate提出的那些指標似乎很相關，因為它們可以精確地衡量我們希望改進的屬性。在獲得專業產品管理顧問Itamar Gilad的幫助後，我們決定每週以“ 成功之星”作為“ 北極星”。

我們認為，這是我們要激勵的生產習慣的良好替代：部署簡單且自動化，工作可以儘早到達使用者，可以快速修復缺陷。對於我們來說，更頻繁的部署有兩個積極的影響：更多的服務使用我們的PaaS，而使用它的服務則通過更頻繁地部署來產生高效的行為。我們僅計算“成功”部署的數量，以確保我們的工具能夠幫助並激勵健康程式碼的釋出。

本季度，我們花了一些時間收集了一系列影響北極星的其他指標（例如，活動倉庫的數量，建造工期等），這對於定義良好的OKR至關重要。

來自使用者的反饋更難量化，但更易於理解。演講的前幾天，我們在Twitter上的一位西班牙市場上的工程師當時在Twitter上發現了這一點，當時他們正在平臺上使用該平臺。

我們有很多粗糙的邊緣和改進的潛力，但是感覺我們走在正確的道路上。我的那頂帽子+10，向所有為實現這一目標做出了貢獻的優秀同事（從基礎架構到UX以及介於兩者之間的所有內容）進行提示。