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

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

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

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

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

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

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

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

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

從測試切入，建立云測試平臺(tái)

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

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

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

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

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

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

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

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

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

■運(yùn)維自動(dòng)化程度低，需要大量手工操作，工作量大，可靠性低，容易出錯(cuò)。

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

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

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

你說的是哪種DevOps？

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

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

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

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

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

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

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

小結(jié)

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