DevOps真實失敗案例與解決辦法
譯文還需結合真實案例,確保DevOps帶來的潛在回報能夠發揮***價值。
DevOps在原則層面堪稱技術領域的烏托邦,其強調軟件開發者與其他IT員工及管理層間的協作與溝通,同時主張以自動化任務處理方式實現軟件交付及基礎設施更新。有了DevOps的幫助,軟件的開發、測試與發布工作皆能夠得到顯著加速,可靠性亦將有所提升。
然而盡管成功案例不少,但事實證明DevOps也有可能因為種種原因而走入歧途。為了防止這類狀況再次發生,我們將在今天的文章中通過實例進行分析。
缺少項目發展愿景
IBM公司早在2003年就開始進軍DevOps——當時這一詞匯甚至還沒有正式出現。藍色巨人希望借此實現一款新產品的敏捷軟件開發。雖然投入了不少資源,但其努力顯然并沒有獲得理想回報。根據IBM公司北美云與DevOps服務線負責人Mustafa Kapadia的說法,“開發方面的速度非常出色,但運維團隊卻無法及時跟上,這就使得客戶仍然不能快速獲得開發成果。”
作為DevOps舉措的一部分,IBM公司隨后決定以自動方式進行代碼部署,同時繼續秉承敏捷方法。然而這同樣未能提升軟件交付速度。IBM公司進行了“價值鏈分析”,并發現***的障礙并非源自敏捷或者自動化,而是整體開發與運行環境。盡管在手段上有所更新,但陳舊而遲緩的原有環境仍然令項目陷入滯后。
最終,IBM公司的DevOps嘗試宣告失敗。Kapadia表示,“如果我們不清楚要如何完成工作,也不知道哪些問題值得解決,那么無論如何變換敏捷方法都將無濟于事。”
而這也證明,只要管理者們能夠真正理解工作流程及其中影響速度的環節,那么DevOps就能夠真正得到針對性調整并實現應有效果。
可訪問性太高,相關培訓太少
早在2006年,專業內容共享網站SlideShare(如今已經被領英所收購)還是一家員工不足20位的小型初創企業。但雄心勃勃的他們希望利用DevOps模式加快速度并領先于競爭對手。
DevOps的目標在于盡可能提升工程團隊效率并傳播技術知識,這樣任何企業成員在休假或者離職時,其他人員都能順利頂替而上。
另外,DevOps的一大設計原則要求員工擁有更強的工作責任感。“這意味著開發者可能需要接觸基礎設施當中那些以往并不需要了解的部分,”前SlideShare公司成員Kalache指出。在SlideShare公司,工程師們需要訪問生產服務器與生產數據庫。
有位軟件工程師嘗試了一款MySQL數據庫的圖形化操作工具。“他決定重組該工具以提升其實際效果,”Kalache指出。“但他沒有想到的是,自己的修改對生產數據庫的執行序列造成了影響,最終數據庫鎖定并導致SlideShare.net網站無法訪問。”
而且在問題出現時,這位當事者甚至根本沒想到是自己的修改引發了狀況。“此次故障給我們帶來兩項警示。其一,雖然DevOps旨在失去大家參與到產品/服務周期的各個階段,但事實上這種廣泛的訪問能力也可能極為危險。此次狀況在當初的小型企業中可能影響不大,但對聲譽良好的大型公司而言則很可能是致命的。”
其二,開發者需要接受更好的培訓以了解生產基礎設施的相關知識。Kalache指出,“DevOps是一種高度強調人與人間互動的工作方式,我們不能先入為主地認為參與者了解某方面技能。因此,培訓必須以強制方式進行。”
DevOps覆蓋范圍不足
有時候,失敗的結果可能源自DevOps的指向性過強。
某家車輛租賃公司在全美擁有大量合作伙伴。每位前往合作伙伴處希望租車的用戶都將通過一款定制化應用獲得相關信息與申請服務。不過由于其中涉及資金交易,所以應用內也包含有第三方服務負責驗證。
“這款軟件的DevOps方案主要圍繞服務器指標,旨在確保應用性能始終穩定,”該公司軟件顧問Nathaniel Rowe表示。“但在幾周之前,我們曾經由于監控結果出現問題而被迫中斷了整套系統,”Rowe表示。“某項必要的第三方驗證服務出現了網絡中斷,這直接使得我們的基礎設施也陷入癱瘓。”
出現這一問題的原因相當復雜,包括設計上的缺陷與開發中為了節約成本而狂砍外包價格。總之,最終原本并非必要的系統指標變成了運行的必要條件,這實在讓該公司始料未及。
問題出現后,開發團隊立即介入并分享了特定驗證代碼,從而在根本上杜絕了發生此類狀況的可能性。“為了防止未來再次發生這種網絡故障,我們設置了全局重新路由機制,并在服務出現問題時立即向合作伙伴發出提醒。”
事實證明,前期時間與資金的投入非常必要。執著于眼前的小利而忽略了DevOps的適用范圍只會帶來更大的損失。
忽視人員與流程
CloudBees公司現任DevOps布道者Brian Dawson曾就職于美國政府的一家合同供應商,當時他們正幫助政府開發一款Web應用。“我們當時的工作是構建工具及流程以覆蓋全部定義與規則,構建、提交并發布代碼,具體手段則采取協同型開源啟發形式,”Dawson回憶道。
DevOps工具的部署與配置非常成功,然而遺憾的是DevOps不可能單純通過工具來實現。他強調稱,“人員、文化、流程與工具這幾大要素在DevOps中同樣重要。”
然而,政府方面只求快速完成平臺構建,卻忽略了人員與流程等環節。“這意味著雖然我們提供的是DevOps平臺,但其實際使用方式卻仍然相當陳舊,”Dawson指出。“整個敏捷流程根本沒能得到有效落實,實際生產負荷測試也沒有真正進行。”
最終,Web應用發布后立刻遭遇到大量故障。另外,由于涉及多個政府部門,因此解決問題的周期相當漫長。而在網站最終開始運作后,人們又發現其響應時間緩慢到令人難以忍受。
技術問題在幾個月后徹底消失,但文化層面的沖突卻始終不斷。Dawson指出,“如果沒有科學的人員、流程與工具相配合,DevOps根本無從談起。”
毫無疑問,DevOps是一種相當有效的軟件交付加速方案,但其同時也能夠為我們的團隊提供一種***凝聚力的文化氛圍。如果失去了這一點,那么DevOps根本無法掀起這一股新的技術轉型浪潮。