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

[[176830]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 無法接受失敗

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

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

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

6.仍然強(qiáng)行區(qū)分開發(fā)與運(yùn)維

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

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

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

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

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

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

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

總結(jié)

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

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

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