平臺工程的十大謬誤 - Humanitec

平臺工程入門
Luca Galante 將平臺工程定義為
“設計和構建工具鏈和工作流的學科，為雲原生時代的軟體工程組織提供自助服務功能。平臺工程師提供的整合產品通常被稱為“內部開發人員平臺”，涵蓋了應用程式整個生命週期的運營需求。”
因此，我們最終致力於將開發運維粘合在一起，形成一個易於消化的內部開發人員平臺，以平衡軟體工程師的認知負荷，以便他們能夠更好地處理設定的複雜性。
開發人員自助服務不應該意味著您需要 1,000 名 Kubernetes 專家來圍繞 Kubernetes 執行 1,000 種不同的服務。
 
收集了團隊在開始平臺工程時最常犯的 10 個錯誤：
 

#1 優先順序謬誤 
除非您碰巧為 Google 工作，否則您的預算可能有限，對此您無能為力。對優先順序進行長時間的思考是非常重要的。我所說的 8/10 團隊犯了這個錯誤，這些錯誤代價高昂。最常見的例子是團隊在應用程式和開發生命週期中首先想到的事情並將其作為最高優先順序，而不是從整體上看待整個生命週期。
大多數平臺團隊從最佳化入職體驗以及如何建立新的應用程式或服務開始。
但這種情況多久發生一次？僅僅執行一個指令碼可能還不夠嗎？ 
那麼，您如何以正確的方式考慮優先順序呢？我有一個非常簡單的經驗法則。進行 100 次部署。現在詢問您的基礎架構、運營和應用程式開發團隊：

• 部署只是對映象進行簡單更新的頻率如何？ 
• 他們多久啟動一次新環境？ 
• 他們多久加入新同事？ 
• 他們多久新增一次新的微服務？
• 他們多久更改或新增資源（資料庫、檔案儲存、DNS）？
• 他們多久新增或更改一次環境變數？

#2 視覺化謬誤 
我最喜歡的例子來自世界最大的線上零售商之一。他們投資了驚人的 104 名 FTE 來構建他們的平臺。在那裡，開發人員可以透過開啟的 PR 和他們的應用程式開始他們的早晨瀏覽。每個服務都顯示在目錄中。高管們喜歡這樣的儀表板體驗。它還讓他們感覺對誰是哪個服務的所有者具有透明度。但它仍然沒有解決任何問題。 
萬一發生災難，高管們會說“我沒有人可以打電話，因為我們現在完全透明瞭”。聽起來不錯，但開發人員可以在他們的日常工作流程中檢視 Github 和其他工具。當災難發生時，他們通常知道該給誰打電話。 
這樣的解決方案不會告訴您究竟出了什麼問題以及原因。問題應該是如何降低變更失敗率。
因此，如果您檢視他們的開發者門戶的實際使用資料，您會發現人們只在開始新服務時登入以搜尋其他服務。
正需要做的事情：清理應用程式配置和非結構化指令碼中的混亂，這些指令碼會因維護和錯誤而消耗時間。
第二件事是基礎架構編排和配置，因為這通常涉及多個不同的團隊，因此會產生等待時間。 
  

#3 “你無法打贏的戰爭”謬誤 
你的任務是清理混亂，因為你的團隊使用了“太多的工具”。
一個團隊使用 Jenkins，一個 Gitlab，一個 Azure DevOps，您構建了在完美世界中您的團隊將只使用一個 CI 系統。
解決辦法很簡單，把CI工具限制在構建映象上，把它們連線到平臺API上，把這部分集中起來，並與基礎設施和叢集連線起來。這對CI設定有淨化作用，你得到了你真正關心的東西的集中和精簡。無論你在哪個團隊工作，開發者的體驗都是完全一樣的。
 

#4 "所有東西和所有人都在一起 "的謬論 
如果你想自上而下地、一次性地、高度標準化地進行文化轉型是很難的。僱傭顧問大軍對開發人員進行雲原生的培訓，等於白做：你正在做的是你在逼迫人們。人們討厭被逼迫。
你把一些東西放在一起，然後告訴人們去使用它，也是這樣。
解決辦法：找到一個燈塔團隊，花大量的時間與他們在一起，使其正確。從內部培養大使和傳教士，給他們時間和自由來影響團隊的其他人。
一步一步地開始，將同樣多的時間放在優先順序和規劃上。讓你的管理層明白，他們需要降低路線圖的期望值。
與你的開發人員交談。迪斯尼在這方面做得很好。他們定期舉辦工具鏈駭客活動，在此期間，團隊最佳化他們的設定，並對平臺的路線圖產生影響。識別你押注的未來技術，並將其正確化。
 

#5 "新設定並不更好 "的謬論 
這個問題與之前的 "一次性完成 "謬論緊密相連。團隊傾向於一次做太多事情（或者被逼著以超過他們能力的速度交付），建立一個充其量是平庸的平臺。新的平臺有一個問題，就是它們是新的（哈哈）。意味著人們必須習慣於它們，而且根據定義，它們的邊緣是粗糙的。

就平臺而言，同樣困難的是：你如何找到MVP？正如退伍軍人聯合會的平臺產品負責人Alan Barr在之前的聚會中提到的。

"平臺往往是厚重的，它們必須做很多事情，你要找的是複製你已經有的工作。"
在日常使用中，小事情就是算數，而且需要時間。許多轉型失敗是因為新的平臺是新的，但它並不比以前的解決方案更好。在這種情況下，沒有新的功能可以真正讓開發者的生活更輕鬆。但是，沒有人能夠真正闡明為什麼個人的犧牲會對整個組織的理智帶來好處。你的新平臺必須要比以前的設定好幾倍，否則就會失敗。

緩解這種謬論：
從小處著手，用真正的產品思維，這一點我怎麼強調都不過分。以一個燈塔式的應用程式為例，它無論如何都是領先的，是完全容器化的，在你的最佳基礎設施堆疊上執行。現在過度投資於這一設定，就像沒有明天一樣。構建一個好得多的東西，讓使用者成為佈道者，而其他團隊也非常想擁有這個東西。不要試圖建立一個統治一切的平臺（見上一個謬論）。在大型機和Kubernetes之間不存在良好的體驗。這是一個值得停止夢想的夢想。
 

#6 抽象的謬誤
工程師討厭為了抽象而失去對底層技術的使用。我們中的許多人都見過這樣的日子：不被理解的標準化嘗試讓我們無法做事，並拖累了我們。有沒有在一個超級嚴格的OpenShift例項中工作過，你一直在等待中央運營團隊搞清楚你要求的選項是否應該成為標準？不要落入這個陷阱。抽象不應該意味著限制。你的同事會立刻討厭你，這可不是一個好地方。

緩解這種謬論 ：
建立黃金通道而不是籠子。我的意思是，並不是說抽象本身是錯誤的，但你必須想使用它們。如果它們不起作用，團隊應該能夠在任何時間點上規避它們。讓我給你一個具體的例子：你的基礎設施協調方法是，如果一個開發人員請求一個資料庫，就啟動一個預設的Terraform模組。這已經透過了安全審查，在大多數情況下是可行的。你的開發人員有一個合格的邊緣案例。與其關閉規避預設的選項，不如讓他們自己來擴充套件模型。透過給予一定的保證，使他們不必為預先審查的設定負責或隨叫隨到，從而促使他們保持在這條道路上。
 

#7 "最響亮的聲音 "的謬誤 
這一點很重要。我見過的幾乎所有的團隊都被這個謬論騙了。隨便找一個由7人組成的工程團隊，其中有一個人物我稱之為 "核心駭客"。對這個人來說，如果某樣東西不在資源庫裡，它就不存在。她每天都在用Aduino對她的烤麵包機進行重新程式設計，並透過bash指令碼向她的夥伴求婚。

這個人非常善於圍繞整個運營和交付計劃的結構進行闡述。這就構成了一個很高的風險，即你要根據這個人的規格來最佳化平臺和整個設定。只是因為這個人的自信心讓其他人都閉口不談。問題是，其他人都必須操作這個設定，否則你就會陷入低於自由的謬論。

緩解這種謬論：
好的設定是為鏈條中最弱的環節而不是最強的環節設計的。當你起草你的戰略時，當你確定工作的優先次序時，當你把你的平臺設計成一個產品時，確保你向開發者徵求意見。不要在具有高度多樣性的大型會議上詢問他們。而是要單獨詢問不同的人群。如果你把鐵桿SRE放在JS開發者旁邊，你會得到錯誤的輸入。謹防抽象謬誤。核心駭客不應該被限制。讓他們成為擴充套件平臺的一部分，讓他們進入工作小組，並清楚地說明為什麼某些事情要這樣做，以服務於更廣泛的社群而不是少數人。
 

#8 自由謬論 
在一個歇斯底里的嘗試中，為了贏得他們工程團隊的心，工程經理們剝離了最後一點標準，把AWS的訪問權交給了每個人。中央運營團隊已經成為過去，權力被轉移到個人貢獻者身上。耶，所有規模化工作的缺點，沒有任何好處。我沒有看到這一次是成功的，但它卻被一次又一次地嘗試。你可以從字面上觀察到事情是如何走偏的。首先，每個人都心不在焉，因為他們現在正在熟悉Helm、Terraform和ArgoCD的魅力。這也意味著他們沒有完成他們的工作。大多數開發者最終意識到了這一點，將他們的注意力轉移到手頭的工作上（編寫NodeJS應用程式，這已經很困難了）。不是因為他們沒有能力，而是因為讓7/7個團隊成員達到必要的專家水平並不划算。但總得有人來做這個工作，所以通常會有一個資深的同事來照顧一切。我把這些人稱為影子行動。長話短說：你記住我的話，在接下來的12個月裡，你的總生產力將下降15-25%。享受吧!

緩解這種謬論：
透過實現開發者自助服務來消除對關鍵人物的依賴，不應該與把額外的認知負荷扔給開發者有關，因為他們沒有能力處理。正如在Salesforce建立內部開發者平臺的Aaron Erickson所說："要在Kubernetes上執行1000個不同的服務，你不應該需要1000個Kubernetes專家來做。" 始終針對團隊能夠處理的認知負荷程度進行最佳化。
 

#9 "谷歌/Facebook/Netflix "的謬論 
挑釁的想法，但你不是谷歌、Facebook、Netflix，也不是Spotify。這在很多方面都是正確的：你沒有資金，你沒有影響力，你沒有足夠的規模。這也意味著你不能也不應該複製他們的做法。他們能給你帶來靈感嗎？也許吧。

但說實話，你很可能並不詳細瞭解他們的內部用例。例如，當人們談論Netflix時，很少有人知道他們主要只建立了一個大的主要服務，正如Nigel Kersten（Puppet）最近提到的。另外，如果你的企業在一個高度管制的行業或關鍵的基礎設施中運營，"快速移動，打破東西 "並不是好的建議。我們在花哨的會議上聽到的談話越多，我們就越有可能將自己與我們不應該比較的設定進行比較。讓我再給你舉個例子。最近，每個人都建立了開發者入口網站，為你需要一個新的微服務的情況進行最佳化。其中一個品牌有一個突出的產品，使之超級方便和簡單--為他們自己的需求而建，不一定是你的。但是，等等，你實際上多久會建立一個新的微服務？如果你是全球流媒體的領導者，那就非常、非常頻繁。如果你是 "德意志銀行"，就不是很經常了。這些產品也提出了大規模的模式，甚至更大的平臺和中央雲運營團隊。它們在非常特殊的情況下起作用，但在你的情況下不太可能起作用。

緩解這種謬論 ：
如果你的團隊中的任何人或任何顧問將這些品牌進行比較，你一定要有超強的判斷力。這樣做的機率很低。加入社群並與同行交談，確保這些設定實際上是可以比較的。
 

#10 "與AWS競爭 "的謬論 
你能讓AWS做的事情，就讓他們做吧。不要重新發明輪子。你永遠無法打敗他們的團隊。他們擁有世界上最好的工程師，他們的資源可能是你的1000倍。

緩解這種謬論：
在建立平臺時，要專注於你的設定所特有的東西，但要儘可能地使用專業工具。如果你想建立專業的工具，你應該在Terraform、AWS或Humanitec申請，在任何其他情況下，你應該專注於那些能推動發展的東西。很抱歉這麼直白，但其他的都是廢話。