在前文中我們說到，傳統企業在逐步建設自己的數字平臺過程中，需要抓住交付基礎設施、API和架構治理、數據自服務、創新實驗基礎設施和監控體系、用戶觸點技術這五個支柱。那么，當我們談“交付基礎設施”，我們究竟在談什么?怎樣的交付基礎設施能加速數字化項目的交付?

[[211220]]

一、什么是交付基礎設施

云時代的研發環境應該以原生支持云計算的方式提供、管理和維護。在提供基礎的彈性計算能力的IaaS平臺之上，交付基礎設施負責為交付團隊提供便利的、***是自助式的工作環境，讓交付團隊專注于交付軟件的功能性需求，而不必操心軟件功能之外的“腳手架”工作。按照ThoughtWorks數字平臺戰略的定義，這些腳手架包括：

• 彈性基礎設施，交付團隊使用底層云計算平臺的方式，既包括各種虛擬機和鏡像的管理，也包括生產環境的水平伸縮能力。
• 持續交付流水線，交付團隊編寫的代碼需要通過這條流水線最終變成可以上線運行的軟件。
• 部署運行時，軟件在開發、測試、試運行、用戶驗收、培訓、生產等各種環境需要部署的環境。
• 監控，為交付團隊提供生產環境(及其他環境)的可觀測性，方便他們發現和解決問題。
• 安全，把安全內建在軟件的研發過程中，盡量避免因為人為失誤造成安全隱患。

從前這些交付基礎設施腳手架通常是由每個交付團隊的技術***(Tech Lead)來負責搭建和維護的。并且由于軟硬件資源的稀缺和不靈活，團隊經常需要微調自己的實踐來適應不同的環境。所以，即使在同一家公司，各支團隊所使用的交付基礎設施也可能大相徑庭。交付基礎設施不一致、不規范的情況會迫使團隊花費額外的精力去操心腳手架工作，并且使***實踐不易推廣普及。走上數字化道路的企業必定有大量的軟件項目，尤其是微服務架構風格的引入會使企業擁有數量更多、單體規模更小的軟件應用，此時交付基礎設施不一致、不規范的情況就會對企業的數字化進程帶來更大的阻力。

云計算帶來的彈性和靈活性讓組織級的交付基礎設施標準化、規范化成為可能。一個跨越項目團隊的、組織級的交付基礎設施團隊現在可以在IaaS的基礎上封裝標準的腳手架，甚至把腳手架本身以PaaS的形式提供給交付團隊。通過把整個企業優秀技術***的知識與經驗內嵌在交付基礎設施腳手架中，降低了對單個交付團隊的技術要求，幫助企業緩解優秀技術***難以獲得的人才挑戰。從這個意義上，以PaaS形式提供的交付基礎設施本質上是技術***作為服務(Tech Lead as a Service)的云計算應用形式，它解決的是優秀技術人才的彈性和靈活性問題，讓企業能夠以一種創新的方式使用這些人才。

二、交付基礎設施解讀

下面我們來看看，在“交付基礎設施”這頂帽子下面，架構師/技術***們究竟應該關心哪些問題，又有哪些***實踐應該被納入他們的視線。

1. 彈性基礎設施

允許交付隨需獲得計算能力。在微服務語境下，這種彈性有兩層常見的含義：在生產環境下，服務可以隨負載動態獲得和釋放計算資源，從而更高效地使用計算資源，更自動化地應對負載變化;在研發環境下，開發、測試、運維等不同角色可以隨需動態獲得完整的環境，從而統一環境、標準化研發實踐、規范化研發能力，并且給研發提供體驗更好的開發環境。

為了實現彈性基礎設施，一方面基礎設施需要支持彈性，例如使用支持彈性計算的公有/私有云，并且有對生產環境的監控和自動化手段;另一方面應用本身需要有可擴展性，例如服務能分別獨立部署、無狀態化、容器化、有透明的前端負載均衡機制。有狀態服務(比如數據庫服務)的彈性伸縮問題是特別需要考慮的重要挑戰。

2. 持續交付流水線

用持續交付實踐打通微服務的開發、構建、驗證和部署流程。在數字化、服務化的背景下，眾多互相依賴的微服務形成的系統架構，對構建、驗證和部署造成更大的壓力：各個服務有獨立的代碼庫和構建流程，又需要隨時能組合成可用的軟件;構建產物需要有統一的存儲管理;完整的運行時環境應該能按需獲得;配置和部署應該能快速準確地完成。

為了應對這些挑戰，交付基礎設施中應該包含完整的持續交付概念：流水線、環境管理、構建產物管理等。應該鼓勵對服務虛擬化，***是每個主機運行一個微服務，而不共享使用主機。應該包含配置自動化工具，例如Chef、Puppet等。在服務化的背景下，持續交付流水線需要體現服務間的依賴關系和團隊間的協作關系，設計一個運轉良好的流水線不是容易的任務。

[[211221]]

3. 部署運行時

交付基礎設施應該包含生產系統所使用的運行時環境，并把生產環境前向拉通到驗證和研發環節。為了在研發流程的出口得到服務化友好的交付物，***是在整個開發過程中一直使用與生產環境近似的環境。例如開發人員應該使用全套環境隨時驗證，自動化測試和手工測試都基于全套環境開展。在這種情況下，環境的設置、管理、更新不可能由每個開發人員和測試人員自己進行，所以環境的管理更新必定是集中進行的，環境的設置必定是自動化的。

在《技術棧管理：云時代的研發環境》一文中，我們已經介紹過“一個平臺、兩個PaaS服務、三個運行時環境”的技術棧管理理念。特別需要注意的是，如何將生產數據拉通到驗證和研發環節。

4. 監控

在微服務架構中，系統由多個小服務組成，且廣泛使用異步通信，使問題和故障更難定位。因此交付基礎設施需要提供全面可靠的監控機制，幫助交付團隊了解系統的整體狀況。

監控的實現涉及日志、服務指標跟蹤、業務語義綜合監控等方式。在云環境下如何劃分和管理監控的層級，監控系統如何無侵入的在各個微服務體系中收集故障和信息，如何有效管理監控的反饋環，如何在前后端分離和移動應用情況下收集和監控客戶端日志，都是常見的挑戰。

5. 安全

當數字化、服務化IT系統的數量劇增，安全的設置會變得更加復雜。在微服務架構下，系統的安全性需要有一個整體的考慮。例如單點登錄、服務間的身份驗證和授權、各種防御措施等安全考量不應該下放到交付團隊，而應該被涵蓋在交付基礎設施中統一提供、統一管理、統一更新。

交付基礎設施還應該鼓勵安全實踐內建(Build Security In)，例如團隊應該熟悉OWASP安全列表和測試框架、需求分析中應該包含安全需求和惡意用戶需求、測試過程中應該包含安全性測試、應該進行自動化安全性測試并納入持續交付流水線。這些流程與工作方法雖然不能完全以軟件代碼的形式承載，但它們同樣是交付基礎設施的重要組成部分。

三、小結

數字化、服務化的IT大背景會讓企業開發和擁有的IT系統數量劇增。當企業IT交付更多地以“兩個pizza團隊”的形式組織，依賴于每個交付團隊的技術***來搭建和維護一套完整高效的交付基礎設施腳手架，這種期望即使不是完全不現實，也會對企業的人才積累提出非常高的要求。因此，企業應該集中優秀的技術人才(包括架構師們)，打造一套標準的交付基礎設施，充分考慮生產環境與研發環境的彈性、持續交付、部署運行時的統一、監控、安全等因素，并借助云計算的彈性和靈活性將其提供給交付團隊。用便利的腳手架賦能一支能快速交付的團隊，這是企業的數字化旅程的***步。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文