在云計算的時代大背景下，我們推薦采用研發(fā)技術(shù)棧管理平臺來集中管理組織中的技術(shù)棧，允許基于一個技術(shù)棧創(chuàng)建開發(fā)測試PaaS和生產(chǎn)PaaS兩個PaaS服務(wù)，從而支撐開發(fā)、測試、生產(chǎn)三種運行時環(huán)境。通過三種運行時環(huán)境的區(qū)分，技術(shù)棧管理平臺實質(zhì)上設(shè)置了一條標(biāo)準(zhǔn)的精益軟件生產(chǎn)流水線，為軟件研發(fā)生命周期中的三個核心工種——開發(fā)、測試、運維——布置了標(biāo)準(zhǔn)的“工位”。在實施技術(shù)棧管理平臺時，從這三個核心工種之中的任何一個切入，都可以優(yōu)先建設(shè)該工種對應(yīng)的工位，從而拉動整條云化生產(chǎn)流水線的實施。

從開發(fā)切入，打造規(guī)范的軟件開發(fā)底座

在數(shù)字化的大背景下，眾多IT組織都面臨技術(shù)能力短缺的境況。尤其是傳統(tǒng)企業(yè)的IT部門，需要用有限的研發(fā)專業(yè)技能交付越來越多、變化越來越頻繁的IT系統(tǒng)，還需要管理外包合作方的團(tuán)隊，對于開發(fā)底座規(guī)范化的要求日益顯著。這些開發(fā)團(tuán)隊常見的一些挑戰(zhàn)包括：

■技術(shù)實踐能力有限，不能保證每個項目采用業(yè)界最佳的框架與工具組合。

■開發(fā)流程不規(guī)范，代碼質(zhì)量關(guān)注不夠，技術(shù)債累積嚴(yán)重。

■外包團(tuán)隊管理乏力，對外包團(tuán)隊的開發(fā)實踐缺乏約束。

實施技術(shù)棧管理平臺以后，整個組織可以識別并聚焦幾種具有普遍代表性的軟件形態(tài)（例如“Java微服務(wù)”、“Java Web應(yīng)用”、“安卓移動應(yīng)用”等），集中技術(shù)骨干力量，搭建項目基礎(chǔ)架構(gòu)，以技術(shù)棧的形式固化下來。開發(fā)團(tuán)隊要啟動一個項目時，只需要從技術(shù)棧管理的PaaS平臺上選擇自己需要的技術(shù)棧，就可以立即生成自己的構(gòu)建運行時，其中包括代碼倉庫、應(yīng)用基礎(chǔ)框架、依賴軟件、自動化構(gòu)建工具等。基于這個構(gòu)建運行時，開發(fā)團(tuán)隊可以基于已經(jīng)搭好的腳手架立即開始編寫代碼，并在PaaS云上進(jìn)行基本的驗證，然后提交到團(tuán)隊代碼倉庫。團(tuán)隊的技術(shù)領(lǐng)導(dǎo)者不需要考慮開發(fā)環(huán)境應(yīng)該如何配置，開發(fā)人員也不需要在自己的電腦上做任何環(huán)境準(zhǔn)備工作，從而極大地降低了項目啟動的技術(shù)門檻。

作為對開發(fā)工位的規(guī)范要求，技術(shù)棧中會規(guī)定“提交門”的質(zhì)量標(biāo)準(zhǔn)，達(dá)不到質(zhì)量標(biāo)準(zhǔn)的代碼將無法提交到團(tuán)隊代碼庫中。這個實踐與持續(xù)集成一樣，都是源自豐田生產(chǎn)方式的“安燈”實踐：如果出現(xiàn)質(zhì)量隱患，應(yīng)該立即停線修復(fù)，而不是讓帶著質(zhì)量隱患的生產(chǎn)線繼續(xù)運轉(zhuǎn)。在一般的開發(fā)團(tuán)隊中，提交門的質(zhì)量標(biāo)準(zhǔn)至少包括（1）代碼能通過編譯；（2）代碼能通過靜態(tài)質(zhì)量檢查。通過引入代碼復(fù)雜度、代碼規(guī)范性檢查等基本質(zhì)量標(biāo)準(zhǔn)，能促使開發(fā)團(tuán)隊關(guān)注代碼質(zhì)量，避免基本的技術(shù)債不斷累積。水平較高的團(tuán)隊會在提交門中包含單元測試，單元測試不通過、或單元測試覆蓋率達(dá)不到標(biāo)準(zhǔn)的代碼將無法提交。

如果需要引入外包團(tuán)隊來協(xié)助開發(fā)，外包團(tuán)隊可以直接從技術(shù)棧管理PaaS服務(wù)商獲得自己的構(gòu)建運行時，絕大部分的開發(fā)規(guī)范可以用提交門驗證的形式來承載，從而將組織的質(zhì)量要求固化到開發(fā)環(huán)境中，降低規(guī)范化管理外包團(tuán)隊的難度和成本。

從測試切入，建立云測試平臺

在數(shù)字化、互聯(lián)網(wǎng)化的IT大背景下，軟件系統(tǒng)上線的周期不斷縮短，兩周一迭代已經(jīng)成為眾多團(tuán)隊的標(biāo)準(zhǔn)配置，一些創(chuàng)新型業(yè)務(wù)已經(jīng)要求將上線周期縮短到一周、幾天、甚至一天幾次。不斷縮短的上線周期，使很多IT組織在測試方面的問題暴露出來：

■測試自動化程度低，手工回歸測試跟不上頻繁上線的節(jié)奏。

■測試環(huán)境爭用，環(huán)境管理工作量大。

■性能、安全等非功能性需求的測試投入不足，到項目晚期才開始測試。

如果這些問題是一個組織當(dāng)前最大的痛點，技術(shù)棧管理平臺的實施也可以從測試工位開始入手，為整個組織打下堅實的質(zhì)量保障基礎(chǔ)。測試和開發(fā)的技術(shù)骨干可以一同選擇適宜的自動化測試工具，將其連接配置好，準(zhǔn)備好自動化測試的腳手架，打包到技術(shù)棧的驗證運行時中。測試人員只需按照業(yè)務(wù)需求編寫自動化測試?yán)⒎旁诩夹g(shù)棧中規(guī)定的“驗證門”環(huán)節(jié)自動執(zhí)行。當(dāng)系統(tǒng)最重要的功能都能被自動化測試覆蓋，測試人員就能從繁重的手工回歸測試中解脫。

自動化測試需要可靠且可復(fù)制的測試環(huán)境來執(zhí)行，這正是云計算的優(yōu)勢所在。在技術(shù)棧管理PaaS中定義了測試運行時環(huán)境后，每當(dāng)測試人員或自動化的驗證門要執(zhí)行自動化測試?yán)龝r，就會從云中取出一個測試運行時，其中除了被測系統(tǒng)的依賴軟件外，還包含了配置好的各種測試工具。被測系統(tǒng)會被加載到測試運行時環(huán)境中，執(zhí)行自動化測試?yán)占瘻y試報告，然后測試運行時環(huán)境就會被銷毀回收。整個過程中不需要測試人員手工管理測試環(huán)境，也不需要與其他測試或開發(fā)人員共用一套環(huán)境。

一旦測試人員不用“人肉回歸”大部分軟件功能，他們就可以把更多的精力投入非功能性測試。性能測試、安全性測試等非功能性測試所需的工具集同樣可以被內(nèi)建在技術(shù)棧中，方便測試人員日常工作。同時，測試人員還可以把非功能性測試編寫成自動化的測試?yán)瑢⑵浼尤腧炞C門的測試集，從而使非功能性需求也持續(xù)得到保障，以免在項目晚期才發(fā)現(xiàn)重大性能或安全問題。

從運維切入，構(gòu)建高響應(yīng)運維能力

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

■運維自動化程度低，需要大量手工操作，工作量大，可靠性低，容易出錯。

■系統(tǒng)監(jiān)控不完備，出現(xiàn)故障時不能及時發(fā)現(xiàn)和快速排錯。

■生產(chǎn)系統(tǒng)的信息不能快速轉(zhuǎn)換成業(yè)務(wù)洞見，無法支持頻繁的線上受控實驗。

技術(shù)棧管理平臺的實施同樣可以從運維工位入手，以打造高效的DevOps體系為優(yōu)先目標(biāo)。

你說的是哪種DevOps？

由于歷史原因，如今大家在談起“DevOps”這個詞時，其中包含的可能是三重相關(guān)但不同的含義：

1、如何借助基礎(chǔ)設(shè)施即服務(wù)、運維自動化等手段，加快代碼部署到生產(chǎn)環(huán)境的速度。

2、如何借助日志和監(jiān)控手段，及時把生產(chǎn)環(huán)境的情況反饋到開發(fā)團(tuán)隊。

3、如何借助端到端的埋點、數(shù)據(jù)采集、分析和可視化，把用戶行為反饋到業(yè)務(wù)。

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

在應(yīng)用運行時環(huán)境中，可以根據(jù)軟件系統(tǒng)的特征預(yù)先配置好日志工具（例如ELK、Splunk）和服務(wù)指標(biāo)監(jiān)控工具（例如Collectd），使開發(fā)團(tuán)隊無需額外工作就能獲得豐富有用的生產(chǎn)環(huán)境信息。一些水平更高的團(tuán)隊會在應(yīng)用運行時環(huán)境中設(shè)置更智能化的運維功能（例如基于Hystrix的服務(wù)熔斷機(jī)制），使運維更具響應(yīng)力。

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

小結(jié)

技術(shù)棧管理平臺的目標(biāo)是為現(xiàn)代IT組織創(chuàng)造云環(huán)境下的精益軟件生產(chǎn)流水線。但對于很多組織而言，這條流水線并非一步到位，而是一個分階段建設(shè)的過程。在這條流水線上，開發(fā)－測試－運維三個核心工位都可以成為實施技術(shù)棧管理的切入點。從組織當(dāng)前最顯著的痛點出發(fā)，選擇一個工位開始實施云化的技術(shù)棧管理平臺，并依循瓶頸理論拉動其他工位的逐步改進(jìn)，這對于眾多不以IT能力見長的組織而言，是一條可行的云化、數(shù)字化道路。