雲時代的研發環境：實施路徑

02-02

前文講到，在雲計算的時代大背景下，我們推薦採用研發技術棧管理平台來集中管理組織中的技術棧，允許基於一個技術棧創建開發測試PaaS和生產PaaS兩個PaaS服務，從而支撐開發、測試、生產三種運行時環境。通過三種運行時環境的區分，技術棧管理平台實質上設置了一條標準的精益軟體生產流水線，為軟體研發生命周期中的三個核心工種——開發、測試、運維——布置了標準的「工位」。在實施技術棧管理平台時，從這三個核心工種之中的任何一個切入，都可以優先建設該工種對應的工位，從而拉動整條雲化生產流水線的實施。

從開發切入，打造規範的軟體開發底座

在數字化的大背景下，眾多IT組織都面臨技術能力短缺的境況。尤其是傳統企業的IT部門，需要用有限的研發專業技能交付越來越多、變化越來越頻繁的IT系統，還需要管理外包合作方的團隊，對於開發底座規範化的要求日益顯著。這些開發團隊常見的一些挑戰包括：

技術實踐能力有限，不能保證每個項目採用業界最佳的框架與工具組合。
開發流程不規範，代碼質量關注不夠，技術債累積嚴重。
外包團隊管理乏力，對外包團隊的開發實踐缺乏約束。

實施技術棧管理平台以後，整個組織可以識別並聚焦幾種具有普遍代表性的軟體形態（例如「Java微服務」、「Java Web應用」、「安卓移動應用」等），集中技術骨幹力量，搭建項目基礎架構，以技術棧的形式固化下來。開發團隊要啟動一個項目時，只需要從技術棧管理的PaaS平台上選擇自己需要的技術棧，就可以立即生成自己的構建運行時，其中包括代碼倉庫、應用基礎框架、依賴軟體、自動化構建工具等。基於這個構建運行時，開發團隊可以基於已經搭好的腳手架立即開始編寫代碼，並在PaaS雲上進行基本的驗證，然後提交到團隊代碼倉庫。團隊的技術領導者不需要考慮開發環境應該如何配置，開發人員也不需要在自己的電腦上做任何環境準備工作，從而極大地降低了項目啟動的技術門檻。

作為對開發工位的規範要求，技術棧中會規定「提交門」的質量標準，達不到質量標準的代碼將無法提交到團隊代碼庫中。這個實踐與持續集成一樣，都是源自豐田生產方式的「安燈」實踐：如果出現質量隱患，應該立即停線修復，而不是讓帶著質量隱患的生產線繼續運轉。在一般的開發團隊中，提交門的質量標準至少包括（1）代碼能通過編譯；（2）代碼能通過靜態質量檢查。通過引入代碼複雜度、代碼規範性檢查等基本質量標準，能促使開發團隊關注代碼質量，避免基本的技術債不斷累積。水平較高的團隊會在提交門中包含單元測試，單元測試不通過、或單元測試覆蓋率達不到標準的代碼將無法提交。

如果需要引入外包團隊來協助開發，外包團隊可以直接從技術棧管理PaaS服務商獲得自己的構建運行時，絕大部分的開發規範可以用提交門驗證的形式來承載，從而將組織的質量要求固化到開發環境中，降低規範化管理外包團隊的難度和成本。

在開發工位實施技術棧管理後，隨著開發規範化底座的建立和開發階段質量要求的逐漸提升，開發團隊將具備逐步縮短交付周期的能力。隨著開發交付周期縮短，待測試、待發布的版本會累積起來，對後續的測試和運維工位形成壓力。此時研發管理者應該密切留意測試工位的累積情況。如果測試團隊抱怨轉測版本太多、人手不足，都反映出工位之間產能失衡的問題。當這一問題出現時，就應該抓住契機，提升測試工位的標準化和自動化程度，使測試工位能跟上開發的交付周期。

從測試切入，建立雲測試平台

在數字化、互聯網化的IT大背景下，軟體系統上線的周期不斷縮短，兩周一迭代已經成為眾多團隊的標準配置，一些創新型業務已經要求將上線周期縮短到一周、幾天、甚至一天幾次。不斷縮短的上線周期，使很多IT組織在測試方面的問題暴露出來：

測試自動化程度低，手工回歸測試跟不上頻繁上線的節奏。
測試環境爭用，環境管理工作量大。
性能、安全等非功能性需求的測試投入不足，到項目晚期才開始測試。

如果這些問題是一個組織當前最大的痛點，技術棧管理平台的實施也可以從測試工位開始入手，為整個組織打下堅實的質量保障基礎。測試和開發的技術骨幹可以一同選擇適宜的自動化測試工具，將其連接配置好，準備好自動化測試的腳手架，打包到技術棧的驗證運行時中。測試人員只需按照業務需求編寫自動化測試例，並放在技術棧中規定的「驗證門」環節自動執行。當系統最重要的功能都能被自動化測試覆蓋，測試人員就能從繁重的手工回歸測試中解脫。

自動化測試需要可靠且可複製的測試環境來執行，這正是雲計算的優勢所在。在技術棧管理PaaS中定義了測試運行時環境後，每當測試人員或自動化的驗證門要執行自動化測試例時，就會從雲中取出一個測試運行時，其中除了被測系統的依賴軟體外，還包含了配置好的各種測試工具。被測系統會被載入到測試運行時環境中，執行自動化測試例，收集測試報告，然後測試運行時環境就會被銷毀回收。整個過程中不需要測試人員手工管理測試環境，也不需要與其他測試或開發人員共用一套環境。

一旦測試人員不用「人肉回歸」大部分軟體功能，他們就可以把更多的精力投入非功能性測試。性能測試、安全性測試等非功能性測試所需的工具集同樣可以被內建在技術棧中，方便測試人員日常工作。同時，測試人員還可以把非功能性測試編寫成自動化的測試例，將其加入驗證門的測試集，從而使非功能性需求也持續得到保障，以免在項目晚期才發現重大性能或安全問題。

當雲測試平台建立起來，有了基本的自動化測試覆蓋，測試人員就可以起到質量監督和建議的作用，而不是跟在開發後面做簡單重複的手工驗證。由於軟體產品必須在驗證運行時上通過測試，研發管理者就可以藉此拉動開發團隊使用雲測試平台進行自驗證，在習慣養成後再逐步在開發過程中推廣使用構建運行時，從而用一個技術棧拉通開發和測試的工作環境。

從運維切入，構建高響應運維能力

同樣，數字化、互聯網化的大背景也對運維團隊提出了新的挑戰。從業務客戶的角度，他們不僅希望自己的需求能儘快上線被用戶使用，而且還希望及時獲得來自用戶的反饋，幫助他們做出調整。在一些領先的企業，運維更是能支持業務客戶針對真實用戶進行快速的受控實驗，從而驗證自己的業務假設。在這些新的要求下，很多IT組織的運維團隊暴露出了能力上的不足：

運維自動化程度低，需要大量手工操作，工作量大，可靠性低，容易出錯。
系統監控不完備，出現故障時不能及時發現和快速排錯。
生產系統的信息不能快速轉換成業務洞見，無法支持頻繁的線上受控實驗。

技術棧管理平台的實施同樣可以從運維工位入手，以打造高效的DevOps體系為優先目標。

你說的是哪種DevOps？
由於歷史原因，如今大家在談起「DevOps」這個詞時，其中包含的可能是三重相關但不同的含義：

如何藉助基礎設施即服務、運維自動化等手段，加快代碼部署到生產環境的速度。

如何藉助日誌和監控手段，及時把生產環境的情況反饋到開發團隊。

如何藉助端到端的埋點、數據採集、分析和可視化，把用戶行為反饋到業務。

以運維視角優先切入時，技術棧的建設就自然地偏向運維工具。在支持計算資源彈性分配的IaaS層（例如基於ScaleWorks的私有雲）之上，將自動化配置管理工具（例如Chef、Puppet、Ansible）及其他常用的運維工具打包在應用運行時中，運維人員可以隨時從技術棧管理的PaaS服務中獲得完整且配置好的應用運行時，再從通過了測試驗證（可能是手工驗證）的發布候選鏡像中選擇一個版本放入應用運行時，即可快速完成應用的部署上線。生產環境的配置以代碼形式記錄，可以由技術能力較強的DevOps團隊專門維護，從而省去了大多數運維人員手動管理運行時環境的工作量與風險。

在應用運行時環境中，可以根據軟體系統的特徵預先配置好日誌工具（例如ELK、Splunk）和服務指標監控工具（例如Collectd），使開發團隊無需額外工作就能獲得豐富有用的生產環境信息。一些水平更高的團隊會在應用運行時環境中設置更智能化的運維功能（例如基於Hystrix的服務熔斷機制），使運維更具響應力。

應用運行時環境中還可以植入端到端綜合語義監控所需的工具設置，從而支持對業務場景埋點和分析，甚至是結合流量路由技術進行受控實驗，用數據為業務決策提供支撐。業務有了縮短反饋周期的訴求，運維有了快速響應變化的能力，兩端夾擊可以倒逼研發環節提升響應力、縮短交付周期，這也是研發組織變革的一個套路。

運維工位採用技術棧管理平台以後，研發管理者可以從交付物入手倒逼開發和測試環節，要求通過測試的發布候選版本以容器鏡像的形式交付，以保證上線效率和可靠性；同時提供基於技術棧管理PaaS的構建和鏡像版本管理基礎設施，方便開發和測試團隊構建符合要求的交付物。等開發和測試團隊養成基於雲和容器環境的交付方式，就可以逐步實施雲測試平台和基於技術棧的開發底座。

小結

技術棧管理平台的目標是為現代IT組織創造雲環境下的精益軟體生產流水線。但對於很多組織而言，這條流水線並非一步到位，而是一個分階段建設的過程。在這條流水線上，開發-測試-運維三個核心工位都可以成為實施技術棧管理的切入點。從組織當前最顯著的痛點出發，選擇一個工位開始實施雲化的技術棧管理平台，並依循瓶頸理論拉動其他工位的逐步改進，這對於眾多不以IT能力見長的組織而言，是一條可行的雲化、數字化道路。