[[168093]]

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

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

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

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

IBM公司早在2003年就開始進軍DevOps——當時這一詞匯甚至還沒有正式出現(xiàn)。藍色巨人希望借此實現(xiàn)一款新產(chǎn)品的敏捷軟件開發(fā)。雖然投入了不少資源，但其努力顯然并沒有獲得理想回報。根據(jù)IBM公司北美云與DevOps服務線負責人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)應有效果。

可訪問性太高，相關培訓太少

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

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

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

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

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

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

DevOps覆蓋范圍不足

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

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

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

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

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

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

忽視人員與流程

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

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

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

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

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

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