建站
咨詢
售后
建站咨詢
新聞中心
存在DevOps的這“七宗罪”絕不代表企業(yè)已經無可救藥。相反，意識到錯誤的存在正是加以解決的重要起點。
我們是公司2013年成立的成都網站建設公司,提供網站建設,電商網站設計開發(fā),外貿營銷網站建設,響應式網頁設計,小程序制作、等服務。為客戶創(chuàng)造有價值的品牌營銷體驗，讓互聯(lián)網提升企業(yè)的競爭力！
盡管我們可通過多種途徑正確實現(xiàn)DevOps，但鑄下大錯的可能性同樣不低。從缺少事故管理工具到忽視關鍵性警報的處理再到將DevOps作為一類工作頭銜，這一切都可能毀掉您的DevOps努力。
1. 將DevOps作為一種頭銜，而非理念
用眾多成功高管的話來說，“如果您在頭銜中加入了‘DevOps’，那么情況已經出錯了。”DevOps是一種理論，而非頭銜。單純引入相關職位完全無助于企業(yè)實現(xiàn)DevOps。
正如Bitilancer公司的Matt Juszczak所寫道:設置DevOps工程師、DevOps系統(tǒng)管理員或者DevOps測試員等職位本身，就是對DevOps的一種根本性誤解。這種誤解導致大量項目與計劃陷入失敗，損害團隊與企業(yè)，誤導業(yè)務方向及招聘人員。
相反，DevOps應當作為一種實現(xiàn)方法，旨在讓軟件開發(fā)與轉換更加簡潔。事實上，DevOps定義要求運維與開發(fā)工程師共同參與整個服務周期，包括設計、開發(fā)流程到生產支持。
2.未能受到員工及CIO的全面接納
DevOps成功的實質在于轉變對軟件及其業(yè)務重要性的認知。DevOps是一種根本性的企業(yè)運營方式轉變，而非技術性變革。具體來講，DevOps通常利用新型工具及實踐轉變技術與業(yè)務戰(zhàn)略間的結合途徑。
不過要讓企業(yè)整體通過DevOps受益，來自高層的支持必不可少。這意味著我們需要一位熟知DevOps的CIO支持并引導相關努力。
3.未著眼于量化指標
Peter Drucker言道：“如果無法量化，則無法加以改進?！绷炕笜耸荄evOps生命周期中的***步，亦應貫穿至每一步。如果不對版本號、平均修復時間或者故障率的變化加以衡量，我們將根本無法了解自己獲得了哪些收益甚至不清楚自己到底在做些什么。
AppDynamics寫道:正確的量化指標是確保DevOps轉型成功的關鍵。然而，亦不可單純受限于技術指標。除了平均修復時間（簡稱MTTR）或者平均無故障時間（簡稱MTBF）之外，大家還應重視流程與人員指標。每月或者每日活躍用戶等都能夠很好地幫助我們理解目前的實現(xiàn)效果。
4.將DevOps視為一種軍備競賽
不應將DevOps單純視為由工具數量所決定。在DevOps世界，關于發(fā)布、配置管理、業(yè)務流程、監(jiān)控、虛擬化以及容器化相關的工具層出不窮。雖然與時俱進并無不可，但我們仍應有針對性地關注其是否有能力真正實現(xiàn)自身改進目標。
真正的DevOps解決方案應該對開發(fā)者、運維人員及安全人員具備吸引力。正如一位工程師所寫道，
如果日常生活會因新型“DevOps”工具而受到影響，那么盡早確保相關團隊的接納態(tài)度至關重要。否則，其它團隊將很難接受這套解決方案，亦永遠無法真正發(fā)揮其全部潛力。
DevOps的核心在于打破壁壘與障礙，保證員工能夠更快完成工作。這意味著管理層需要全面投入，而非僅僅是購買更多工具。
5. 無法接受失敗
即使企業(yè)已經開始正確實施自動化方案并獲得管理層支持，但亦有不必DevOps團隊無法接收失敗的結果。舉例來說，Netflix公司就會主動誘發(fā)失敗狀況，從而保證自身為服務器宕機或者代碼出錯做好準備。
從理論層面上，管理層需要意識到失敗是構建及發(fā)布代碼的實踐活動中的必然因素。出現(xiàn)失敗之后，我們應當以建設性方式總結經驗并發(fā)現(xiàn)問題，而非一味相互指責。在理想情況下，一套失敗的發(fā)布版本應當：
“立足錯誤進行新一輪測試，保證其未來不會再次出現(xiàn)。只有做到這一點，企業(yè)才算是真正接納了DevOps的核心理論?！?/p>
6.仍然強行區(qū)分開發(fā)與運維
行之有效的DevOps“強調整體系統(tǒng)表現(xiàn)，而非特定工作或者部門的孤立表現(xiàn)。”
正如很多相關文章所提到，開發(fā)者不可能閉門編寫代碼并指望其可按照預期順利運行。相反，開發(fā)者與運維者應當協(xié)同配合。
這通常意味著開發(fā)與運維雙方應當隨時溝通。如果開發(fā)者需要為其代碼造成的問題負責，那么他們顯然會更為嚴肅地進行代碼編寫與測試。同樣的，如果運維人員感受到了開發(fā)者面臨的壓力，他們也會保持與之相符的工作態(tài)度。
7.未使用關鍵性警報工具
如果未能切實利用關鍵性警報工具向工程師們通報嚴重事故，那么DevOps體系必將遭遇更多其它問題。如果未能在DevOps團隊的核心理念當中融入關鍵性警報工具這一元素，那么：
- 該團隊的量化指標關注能力將大打折扣。舉例來說，如果我們根本不知道某一事故何時發(fā)生，那么如何才能降低平均修復時間？
- 有效取證將更加困難。關鍵性警報工具允許各團隊查看警告信息中交付的相關錯誤描述。
- 開發(fā)與運維間的隔閡將繼續(xù)存在。通過為兩支團隊同時分配“值班”任務，雙方都能夠隨時查看到警報內容。在對警報擁有明確認知之后，他們將更加有效地進行換位思考。
關鍵性警報工具對于削減停機時間、維持客戶滿意度以及快速解決問題方面至關重要。事實上，忽略這些要點并繼續(xù)使用那些根本無法切實達成警報目的的工具，應當被稱為一種瀆職行為。
總結
看完本篇文章，也許很多朋友感受被戳到了痛處。不過別太擔心，存在DevOps的這“七宗罪”絕不代表企業(yè)已經無可救藥。相反，意識到錯誤的存在正是加以解決的重要起點。另外，這里建議大家不要一味貪多求快。一次解決一宗罪往往是更安全也更為有效的處理辦法。
新聞標題：DevOps領域的“七宗罪”及解決辦法
文章鏈接：http://www.dlmjj.cn/article/djdgipe.html
