【51CTO.com快譯】存在DevOps的這“七宗罪”絕不代表企業(yè)已經(jīng)無可救藥。相反，意識到錯誤的存在正是加以解決的重要起點。

[[176830]]

盡管我們可通過多種途徑正確實現(xiàn)DevOps，但鑄下大錯的可能性同樣不低。從缺少事故管理工具到忽視關(guān)鍵性警報的處理再到將DevOps作為一類工作頭銜，這一切都可能毀掉您的DevOps努力。

1. 將DevOps作為一種頭銜，而非理念

用眾多成功高管的話來說，“如果您在頭銜中加入了‘DevOps’，那么情況已經(jīng)出錯了。”DevOps是一種理論，而非頭銜。單純引入相關(guān)職位完全無助于企業(yè)實現(xiàn)DevOps。

正如Bitilancer公司的Matt Juszczak所寫道:設(shè)置DevOps工程師、DevOps系統(tǒng)管理員或者DevOps測試員等職位本身，就是對DevOps的一種根本性誤解。這種誤解導(dǎo)致大量項目與計劃陷入失敗，損害團隊與企業(yè)，誤導(dǎo)業(yè)務(wù)方向及招聘人員。

相反，DevOps應(yīng)當(dāng)作為一種實現(xiàn)方法，旨在讓軟件開發(fā)與轉(zhuǎn)換更加簡潔。事實上，DevOps定義要求運維與開發(fā)工程師共同參與整個服務(wù)周期，包括設(shè)計、開發(fā)流程到生產(chǎn)支持。

2.未能受到員工及CIO的全面接納

DevOps成功的實質(zhì)在于轉(zhuǎn)變對軟件及其業(yè)務(wù)重要性的認知。DevOps是一種根本性的企業(yè)運營方式轉(zhuǎn)變，而非技術(shù)性變革。具體來講，DevOps通常利用新型工具及實踐轉(zhuǎn)變技術(shù)與業(yè)務(wù)戰(zhàn)略間的結(jié)合途徑。

不過要讓企業(yè)整體通過DevOps受益，來自高層的支持必不可少。這意味著我們需要一位熟知DevOps的CIO支持并引導(dǎo)相關(guān)努力。

3.未著眼于量化指標(biāo)

Peter Drucker言道：“如果無法量化，則無法加以改進。”量化指標(biāo)是DevOps生命周期中的***步，亦應(yīng)貫穿至每一步。如果不對版本號、平均修復(fù)時間或者故障率的變化加以衡量，我們將根本無法了解自己獲得了哪些收益甚至不清楚自己到底在做些什么。

AppDynamics寫道:正確的量化指標(biāo)是確保DevOps轉(zhuǎn)型成功的關(guān)鍵。然而，亦不可單純受限于技術(shù)指標(biāo)。除了平均修復(fù)時間（簡稱MTTR）或者平均無故障時間（簡稱MTBF）之外，大家還應(yīng)重視流程與人員指標(biāo)。每月或者每日活躍用戶等都能夠很好地幫助我們理解目前的實現(xiàn)效果。

4.將DevOps視為一種軍備競賽

不應(yīng)將DevOps單純視為由工具數(shù)量所決定。在DevOps世界，關(guān)于發(fā)布、配置管理、業(yè)務(wù)流程、監(jiān)控、虛擬化以及容器化相關(guān)的工具層出不窮。雖然與時俱進并無不可，但我們?nèi)詰?yīng)有針對性地關(guān)注其是否有能力真正實現(xiàn)自身改進目標(biāo)。

真正的DevOps解決方案應(yīng)該對開發(fā)者、運維人員及安全人員具備吸引力。正如一位工程師所寫道，

如果日常生活會因新型“DevOps”工具而受到影響，那么盡早確保相關(guān)團隊的接納態(tài)度至關(guān)重要。否則，其它團隊將很難接受這套解決方案，亦永遠無法真正發(fā)揮其全部潛力。

DevOps的核心在于打破壁壘與障礙，保證員工能夠更快完成工作。這意味著管理層需要全面投入，而非僅僅是購買更多工具。

5. 無法接受失敗

即使企業(yè)已經(jīng)開始正確實施自動化方案并獲得管理層支持，但亦有不必DevOps團隊無法接收失敗的結(jié)果。舉例來說，Netflix公司就會主動誘發(fā)失敗狀況，從而保證自身為服務(wù)器宕機或者代碼出錯做好準備。

從理論層面上，管理層需要意識到失敗是構(gòu)建及發(fā)布代碼的實踐活動中的必然因素。出現(xiàn)失敗之后，我們應(yīng)當(dāng)以建設(shè)性方式總結(jié)經(jīng)驗并發(fā)現(xiàn)問題，而非一味相互指責(zé)。在理想情況下，一套失敗的發(fā)布版本應(yīng)當(dāng)：

“立足錯誤進行新一輪測試，保證其未來不會再次出現(xiàn)。只有做到這一點，企業(yè)才算是真正接納了DevOps的核心理論。”

6.仍然強行區(qū)分開發(fā)與運維

行之有效的DevOps“強調(diào)整體系統(tǒng)表現(xiàn)，而非特定工作或者部門的孤立表現(xiàn)。”

正如很多相關(guān)文章所提到，開發(fā)者不可能閉門編寫代碼并指望其可按照預(yù)期順利運行。相反，開發(fā)者與運維者應(yīng)當(dāng)協(xié)同配合。

這通常意味著開發(fā)與運維雙方應(yīng)當(dāng)隨時溝通。如果開發(fā)者需要為其代碼造成的問題負責(zé)，那么他們顯然會更為嚴肅地進行代碼編寫與測試。同樣的，如果運維人員感受到了開發(fā)者面臨的壓力，他們也會保持與之相符的工作態(tài)度。

7.未使用關(guān)鍵性警報工具

如果未能切實利用關(guān)鍵性警報工具向工程師們通報嚴重事故，那么DevOps體系必將遭遇更多其它問題。如果未能在DevOps團隊的核心理念當(dāng)中融入關(guān)鍵性警報工具這一元素，那么：

• 該團隊的量化指標(biāo)關(guān)注能力將大打折扣。舉例來說，如果我們根本不知道某一事故何時發(fā)生，那么如何才能降低平均修復(fù)時間？
• 有效取證將更加困難。關(guān)鍵性警報工具允許各團隊查看警告信息中交付的相關(guān)錯誤描述。
• 開發(fā)與運維間的隔閡將繼續(xù)存在。通過為兩支團隊同時分配“值班”任務(wù)，雙方都能夠隨時查看到警報內(nèi)容。在對警報擁有明確認知之后，他們將更加有效地進行換位思考。

關(guān)鍵性警報工具對于削減停機時間、維持客戶滿意度以及快速解決問題方面至關(guān)重要。事實上，忽略這些要點并繼續(xù)使用那些根本無法切實達成警報目的的工具，應(yīng)當(dāng)被稱為一種瀆職行為。

總結(jié)

看完本篇文章，也許很多朋友感受被戳到了痛處。不過別太擔(dān)心，存在DevOps的這“七宗罪”絕不代表企業(yè)已經(jīng)無可救藥。相反，意識到錯誤的存在正是加以解決的重要起點。另外，這里建議大家不要一味貪多求快。一次解決一宗罪往往是更安全也更為有效的處理辦法。

原文標(biāo)題：7 Deadly DevOps Sins and How to Avoid Them  原文作者：Orlee Berlove

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】