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

[[211220]]

一、什么是交付基礎設施

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

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

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

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

二、交付基礎設施解讀

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

1. 彈性基礎設施

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

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

2. 持續(xù)交付流水線

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

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

[[211221]]

3. 部署運行時

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

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

4. 監(jiān)控

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

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

5. 安全

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

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

三、小結

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

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

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