您的位置:首頁>科技>正文

數位化企業的交付基礎設施

數位化企業的三個關鍵字

首先, 傳統企業們需要清楚一件事:“傳統”不應該是貶義詞, 它同時意味著數十年積累的寶貴資產, 包括客戶關係、資料、品牌形象、供應鏈、管道等等。 傳統企業要在互聯網時代的競爭環境中占得一席之地, 靠的不是突破最高精尖的技術領域, 而是以數位化的形式啟動自己多年累積的核心資產, 將核心資產轉變為可以在互聯網上使用的服務, 使其煥發新的價值。 對眾多成功的數位化企業的調研顯示, 這些企業有著一些引人注目的共性。 在“啟動核心資產”的過程中, 他們對三個關鍵字的關注特別值得我們關注:IT效能;生態系統;創新實驗。

什麼是交付基礎設施

雲時代的研發環境應該以原生支援雲計算的方式提供、管理和維護。 在提供基礎的彈性計算能力的IaaS平臺之上, 交付基礎設施負責為交付團隊提供便利的、最好是自助式的工作環境, 讓交付團隊專注於交付軟體的功能性需求, 而不必操心軟體功能之外的“腳手架”工作。 這些腳手架包括:

彈性基礎設施, 即交付團隊使用底層雲計算平臺的方式, 既包括各種虛擬機器和鏡像的管理, 也包括生產環境的水準伸縮能力。

持續交付流水線, 交付團隊編寫的代碼需要通過這條流水線最終變成可以上線運行的軟體。

部署運行時, 軟體在開發、測試、試運行、用戶驗收、培訓、生產等各種環境需要部署的環境。

監控, 為交付團隊提供生產環境(及其他環境)的可觀測性, 方便他們發現和解決問題。

安全, 把安全內建在軟體的研發過程中, 儘量避免因為人為失誤造成安全隱患。

從前這些交付基礎設施腳手架通常是由每個交付團隊的技術領導者(Tech Lead)來負責搭建和維護的。 並且由於軟硬體資源的稀缺和不靈活, 團隊經常需要微調自己的實踐來適應不同的環境。 所以, 即使在同一家公司, 各支團隊所使用的交付基礎設施也可能大相徑庭。 交付基礎設施不一致、不規範的情況會迫使團隊花費額外的精力去操心腳手架工作, 並且使最佳實踐不易推廣普及。 走上數位化道路的企業必定有大量的軟體專案,

尤其是微服務架構風格的引入會使企業擁有數量更多、單體規模更小的軟體應用, 此時交付基礎設施不一致、不規範的情況就會對企業的數位化進程帶來更大的阻力。

雲計算帶來的彈性和靈活性讓組織級的交付基礎設施標準化、規範化成為可能。 一個跨越專案團隊的、組織級的交付基礎設施團隊現在可以在IaaS的基礎上封裝標準的腳手架, 甚至把腳手架本身以PaaS的形式提供給交付團隊。 通過把整個企業優秀技術領導者的知識與經驗內嵌在交付基礎設施腳手架中, 就降低了對單個交付團隊的技術要求, 幫助企業緩解優秀技術領導者難以獲得的人才挑戰。 從這個意義上,

以PaaS形式提供的交付基礎設施本質上是技術領導者作為服務(Tech Lead as a Service)的雲計算應用形式, 它解決的是優秀技術人才的彈性和靈活性問題, 讓企業能夠以一種創新的方式使用這些人才。

架構師是否應該寫代碼

關於“架構師是否應該寫代碼”這個問題, 業界有各種不同的聲音。 在敏捷的社區裡, 意見傾向於認為架構師需要寫代碼, 因為這是他們獲得關於技術決策的回饋和建立技術領導力的重要方式。 將交付基礎設施明確提出來, 就給了架構師又一個清晰的程式設計目標——他們需要用代碼的形式描述軟體交付中的基礎設施和最佳實踐。 除了培訓、開會、代碼評審等我們已經知道效率並不太高的方式以外, 架構師對交付團隊的指導和監管現在可以用實實在在的代碼來承載。

當交付團隊不理解架構師說的某件事應該怎麼做, 現在他們更有理由要求架構師“show me the code”。

交付基礎設施解讀

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

彈性基礎設施

允許交付隨需獲得計算能力。 在微服務語境下, 這種彈性有兩層常見的含義:在生產環境下, 服務可以隨負載動態獲得和釋放計算資源, 從而更高效地使用計算資源, 更自動化地應對負載變化;在研發環境下, 開發、測試、運維等不同角色可以隨需動態獲得完整的環境, 從而統一環境、標準化研發實踐、規範化研發能力, 並且給研發提供體驗更好的開發環境。為了實現彈性基礎設施,一方面基礎設施需要支援彈性,例如使用支援彈性計算的公有/私有雲,並且有對生產環境的監控和自動化手段;另一方面應用本身需要有可擴展性,例如服務能分別獨立部署、無狀態化、容器化、有透明的前端負載均衡機制。有狀態服務(比如資料庫服務)的彈性伸縮問題是特別需要考慮的重要挑戰。

持續交付流水線

用持續交付實踐打通微服務的開發、構建、驗證和部署流程。在數位化、服務化的背景下,眾多互相依賴的微服務形成的系統架構,對構建、驗證和部署造成更大的壓力:各個服務有獨立的代碼庫和構建流程,又需要隨時能組合成可用的軟體;構建產物需要有統一的存儲管理;完整的運行時環境應該能按需獲得;配置和部署應該能快速準確地完成。為了應對這些挑戰,交付基礎設施中應該包含完整的持續交付概念:流水線、環境管理、構建產物管理等。應該鼓勵對服務虛擬化,最好是每個主機運行一個微服務,而不共用使用主機。應該包含配置自動化工具,例如Chef、Puppet等。在服務化的背景下,持續交付流水線需要體現服務間的依賴關係和團隊間的協作關係,設計一個運轉良好的流水線不是容易的任務。

部署運行時

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

監控

在微服務架構中,系統由多個小服務組成,且廣泛使用非同步通信,使問題和故障更難定位。因此交付基礎設施需要提供全面可靠的監控機制,説明交付團隊瞭解系統的整體狀況。監控的實現涉及日誌、服務指標跟蹤、業務語義綜合監控等方式。在雲環境下如何劃分和管理監控的層級,監控系統如何無侵入的在各個微服務體系中收集故障和資訊,如何有效管理監控的回饋環,如何在前後端分離和移動應用情況下收集和監控用戶端日誌,都是常見的挑戰。

安全

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

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

小結

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

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

持續交付流水線

用持續交付實踐打通微服務的開發、構建、驗證和部署流程。在數位化、服務化的背景下,眾多互相依賴的微服務形成的系統架構,對構建、驗證和部署造成更大的壓力:各個服務有獨立的代碼庫和構建流程,又需要隨時能組合成可用的軟體;構建產物需要有統一的存儲管理;完整的運行時環境應該能按需獲得;配置和部署應該能快速準確地完成。為了應對這些挑戰,交付基礎設施中應該包含完整的持續交付概念:流水線、環境管理、構建產物管理等。應該鼓勵對服務虛擬化,最好是每個主機運行一個微服務,而不共用使用主機。應該包含配置自動化工具,例如Chef、Puppet等。在服務化的背景下,持續交付流水線需要體現服務間的依賴關係和團隊間的協作關係,設計一個運轉良好的流水線不是容易的任務。

部署運行時

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

監控

在微服務架構中,系統由多個小服務組成,且廣泛使用非同步通信,使問題和故障更難定位。因此交付基礎設施需要提供全面可靠的監控機制,説明交付團隊瞭解系統的整體狀況。監控的實現涉及日誌、服務指標跟蹤、業務語義綜合監控等方式。在雲環境下如何劃分和管理監控的層級,監控系統如何無侵入的在各個微服務體系中收集故障和資訊,如何有效管理監控的回饋環,如何在前後端分離和移動應用情況下收集和監控用戶端日誌,都是常見的挑戰。

安全

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

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

小結

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

Next Article
喜欢就按个赞吧!!!
点击关闭提示