[[168093]]

還需結(jié)合真實案例，確保DevOps帶來的潛在回報能夠發(fā)揮***價值。

DevOps在原則層面堪稱技術(shù)領(lǐng)域的烏托邦，其強調(diào)軟件開發(fā)者與其他IT員工及管理層間的協(xié)作與溝通，同時主張以自動化任務(wù)處理方式實現(xiàn)軟件交付及基礎(chǔ)設(shè)施更新。有了DevOps的幫助，軟件的開發(fā)、測試與發(fā)布工作皆能夠得到顯著加速，可靠性亦將有所提升。

然而盡管成功案例不少，但事實證明DevOps也有可能因為種種原因而走入歧途。為了防止這類狀況再次發(fā)生，我們將在今天的文章中通過實例進行分析。

缺少項目發(fā)展愿景

IBM公司早在2003年就開始進軍DevOps——當(dāng)時這一詞匯甚至還沒有正式出現(xiàn)。藍色巨人希望借此實現(xiàn)一款新產(chǎn)品的敏捷軟件開發(fā)。雖然投入了不少資源，但其努力顯然并沒有獲得理想回報。根據(jù)IBM公司北美云與DevOps服務(wù)線負責(zé)人Mustafa Kapadia的說法，“開發(fā)方面的速度非常出色，但運維團隊卻無法及時跟上，這就使得客戶仍然不能快速獲得開發(fā)成果。”

作為DevOps舉措的一部分，IBM公司隨后決定以自動方式進行代碼部署，同時繼續(xù)秉承敏捷方法。然而這同樣未能提升軟件交付速度。IBM公司進行了“價值鏈分析”，并發(fā)現(xiàn)***的障礙并非源自敏捷或者自動化，而是整體開發(fā)與運行環(huán)境。盡管在手段上有所更新，但陳舊而遲緩的原有環(huán)境仍然令項目陷入滯后。

最終，IBM公司的DevOps嘗試宣告失敗。Kapadia表示，“如果我們不清楚要如何完成工作，也不知道哪些問題值得解決，那么無論如何變換敏捷方法都將無濟于事。”

而這也證明，只要管理者們能夠真正理解工作流程及其中影響速度的環(huán)節(jié)，那么DevOps就能夠真正得到針對性調(diào)整并實現(xiàn)應(yīng)有效果。

可訪問性太高，相關(guān)培訓(xùn)太少

早在2006年，專業(yè)內(nèi)容共享網(wǎng)站SlideShare（如今已經(jīng)被領(lǐng)英所收購）還是一家員工不足20位的小型初創(chuàng)企業(yè)。但雄心勃勃的他們希望利用DevOps模式加快速度并領(lǐng)先于競爭對手。

DevOps的目標(biāo)在于盡可能提升工程團隊效率并傳播技術(shù)知識，這樣任何企業(yè)成員在休假或者離職時，其他人員都能順利頂替而上。

另外，DevOps的一大設(shè)計原則要求員工擁有更強的工作責(zé)任感。“這意味著開發(fā)者可能需要接觸基礎(chǔ)設(shè)施當(dāng)中那些以往并不需要了解的部分，”前SlideShare公司成員Kalache指出。在SlideShare公司，工程師們需要訪問生產(chǎn)服務(wù)器與生產(chǎn)數(shù)據(jù)庫。

有位軟件工程師嘗試了一款MySQL數(shù)據(jù)庫的圖形化操作工具。“他決定重組該工具以提升其實際效果，”Kalache指出。“但他沒有想到的是，自己的修改對生產(chǎn)數(shù)據(jù)庫的執(zhí)行序列造成了影響，最終數(shù)據(jù)庫鎖定并導(dǎo)致SlideShare.net網(wǎng)站無法訪問。”

而且在問題出現(xiàn)時，這位當(dāng)事者甚至根本沒想到是自己的修改引發(fā)了狀況。“此次故障給我們帶來兩項警示。其一，雖然DevOps旨在失去大家參與到產(chǎn)品/服務(wù)周期的各個階段，但事實上這種廣泛的訪問能力也可能極為危險。此次狀況在當(dāng)初的小型企業(yè)中可能影響不大，但對聲譽良好的大型公司而言則很可能是致命的。”

其二，開發(fā)者需要接受更好的培訓(xùn)以了解生產(chǎn)基礎(chǔ)設(shè)施的相關(guān)知識。Kalache指出，“DevOps是一種高度強調(diào)人與人間互動的工作方式，我們不能先入為主地認為參與者了解某方面技能。因此，培訓(xùn)必須以強制方式進行。”

DevOps覆蓋范圍不足

有時候，失敗的結(jié)果可能源自DevOps的指向性過強。

某家車輛租賃公司在全美擁有大量合作伙伴。每位前往合作伙伴處希望租車的用戶都將通過一款定制化應(yīng)用獲得相關(guān)信息與申請服務(wù)。不過由于其中涉及資金交易，所以應(yīng)用內(nèi)也包含有第三方服務(wù)負責(zé)驗證。

“這款軟件的DevOps方案主要圍繞服務(wù)器指標(biāo)，旨在確保應(yīng)用性能始終穩(wěn)定，”該公司軟件顧問Nathaniel Rowe表示。“但在幾周之前，我們曾經(jīng)由于監(jiān)控結(jié)果出現(xiàn)問題而被迫中斷了整套系統(tǒng)，”Rowe表示。“某項必要的第三方驗證服務(wù)出現(xiàn)了網(wǎng)絡(luò)中斷，這直接使得我們的基礎(chǔ)設(shè)施也陷入癱瘓。”

出現(xiàn)這一問題的原因相當(dāng)復(fù)雜，包括設(shè)計上的缺陷與開發(fā)中為了節(jié)約成本而狂砍外包價格?？傊罱K原本并非必要的系統(tǒng)指標(biāo)變成了運行的必要條件，這實在讓該公司始料未及。

問題出現(xiàn)后，開發(fā)團隊立即介入并分享了特定驗證代碼，從而在根本上杜絕了發(fā)生此類狀況的可能性。“為了防止未來再次發(fā)生這種網(wǎng)絡(luò)故障，我們設(shè)置了全局重新路由機制，并在服務(wù)出現(xiàn)問題時立即向合作伙伴發(fā)出提醒。”

事實證明，前期時間與資金的投入非常必要。執(zhí)著于眼前的小利而忽略了DevOps的適用范圍只會帶來更大的損失。

忽視人員與流程

CloudBees公司現(xiàn)任DevOps布道者Brian Dawson曾就職于美國政府的一家合同供應(yīng)商，當(dāng)時他們正幫助政府開發(fā)一款Web應(yīng)用。“我們當(dāng)時的工作是構(gòu)建工具及流程以覆蓋全部定義與規(guī)則，構(gòu)建、提交并發(fā)布代碼，具體手段則采取協(xié)同型開源啟發(fā)形式，”Dawson回憶道。

DevOps工具的部署與配置非常成功，然而遺憾的是DevOps不可能單純通過工具來實現(xiàn)。他強調(diào)稱，“人員、文化、流程與工具這幾大要素在DevOps中同樣重要。”

然而，政府方面只求快速完成平臺構(gòu)建，卻忽略了人員與流程等環(huán)節(jié)。“這意味著雖然我們提供的是DevOps平臺，但其實際使用方式卻仍然相當(dāng)陳舊，”Dawson指出。“整個敏捷流程根本沒能得到有效落實，實際生產(chǎn)負荷測試也沒有真正進行。”

最終，Web應(yīng)用發(fā)布后立刻遭遇到大量故障。另外，由于涉及多個政府部門，因此解決問題的周期相當(dāng)漫長。而在網(wǎng)站最終開始運作后，人們又發(fā)現(xiàn)其響應(yīng)時間緩慢到令人難以忍受。

技術(shù)問題在幾個月后徹底消失，但文化層面的沖突卻始終不斷。Dawson指出，“如果沒有科學(xué)的人員、流程與工具相配合，DevOps根本無從談起。”

毫無疑問，DevOps是一種相當(dāng)有效的軟件交付加速方案，但其同時也能夠為我們的團隊提供一種***凝聚力的文化氛圍。如果失去了這一點，那么DevOps根本無法掀起這一股新的技術(shù)轉(zhuǎn)型浪潮。