2017運維/devops線上技術峰會上，阿裡雲平台研發進階專家連銘帶來devops的相關演講。本文主要從什麼是devops開始聊起，接着對比了devops與傳統模式的差別，并且列舉了devops的難點和需要解決的問題，包括尋找平衡點、責權劃分和制約考核，最後進行了簡要總結。一起來了解下吧。
以下是精彩内容整理：
近幾個月，運維事件頻發。從“爐石資料被删”到“mongodb遭黑客勒索”，從“gitlab資料庫被誤删”到某家公司漏洞被組合攻擊。這些事件，無一不在呐喊——做好運維工作的重要性。然而，從傳統it部署到雲，人肉運維已經是過去式，雲上運維該怎麼開展？尤其是雲2.0時代，運維已經向全局化、流程化和精細化模式轉變。與此同時，人工智能的發展，“威脅論”也随之襲來——運維是不是快要無用武之地了？如何去做更智能的活，當下很多運維人在不斷思考和探尋答案。
什麼是devops？
devops 是一種工程模式，本質上是一種分工，通過對開發、運維、測試，配管等角色職責的分工，實作工程效率最大化，進而滿足業務的需求。
devops的核心是角色的分工，而不是組織架構變化，垂直化的組織架構不代表可以實作devops所需要的分工模式，橫向的組織架構也不代表傳統的分工模式。
devops的目标是工程效率最大化，它本身也隻是一種方法論，是為了實作工程效率最大化的目标而存在的。
devops與傳統模式的差別
傳統分工模式下，pd将需求提出來，開發者根據需求寫代碼，然後告訴scm，scm拿着代碼去打包，打包後告訴qa，qa測試完成後通知運維ops上線，ops進行上線部署，最後整個需求得到release。
它的優勢在于：分工與責任清晰，品質有保障，層層制約，容易把控。
它的劣勢也很明顯：溝通成本與等待成本高，每一個環節都有成為瓶頸的風險，比如dev知道怎樣寫代碼，但qa也需要了解需求才能知道怎麼做測試，ops也需要了解需求維持線上穩定性，ops負責傳遞，容易演變成擦屁股的角色，包括日常出現的bug。
在devops分工模式下，一切都改變了，不再是每個人做完自己的事情然後交給下一個人。這個分工模式下，開發通過工具驅動所有流程運轉向前走，比如開發寫完代碼通過工具驅動自動化打包，自動化測試，自動化部署或更新，還會配備監控；scm、ops和qa等在工具的外圍，確定在工具中的每一個環節可以正常運轉，它們支撐工具的目的是確定dev可以使用工具完成人肉完成的事情，這是決策的變化，還要保證工具中的幾個子產品可以支撐最新的業務變化，當業務有了更新的變化時，須保證工具可以支撐開發。
devops分工模式的好處很明顯：可以減少溝通成本與等待風險，降低正常需求傳遞所需時間，dev負責傳遞，避免傳遞扯皮。
devops分工模式的劣勢也很突出：每個環節參與角色較多，風險較高，對于業務形态比較多的企業較明顯，工具支撐多種業務形态的成本是非常高的，當工具搞不定時，需要人肉補位保證業務釋出，如果補位較多，那麼devops分工就失敗了；專業度會有降低，工具隻能支援在精确輸入的情況下以非常精确的方式完成一件固定的事情，一旦輸入有變化而超出規則，該環節就比較麻煩了，工具的專業提升比人要慢的多；dev權利過大，容易軍閥化。
devops的難點和需要解決的問題
<b>尋找平衡點</b><b></b>
devops是為了追求工程效率最大化而存在的，但是工程效率和穩定性的目标在大部分場景下都是相悖的，如何能夠在工程效率提升的前提下，保證穩定性不出問題？
傳統分工模式是ops團隊負責，在devops分工模式中已經沒有ops團隊了，隻能開發團隊負責，當一個團隊同時負責兩個互相有沖突的case時，該怎麼辦呢？如果分成兩部分人分别負責業務kpi和穩定性kpi，就回到了傳統的分工模式。
<b>責權劃分</b><b></b>
對于開發者而言，主業是coding，其它包括打包、測試、釋出都是輔業，它是工具的使用者，并不能完全将所有事情做得完美，在除coding以外的所有環節中，責任和分工要怎麼來分，除了開發以外的事情要占用開發人員多少精力，才能保證dev使用順暢，跟上公司業務發展？
其中核心是工具，工具是将二者粘合在一起的，工具起到了賦能和粘合的作用，工具還須可介入，需要人肉補位；另外，工具的進化要運維團隊、測試團隊和scm團隊來負責，工具自己要足夠開放，才能讓其它團隊可以不斷優化某一環節；工具也要保證可持續成長，跟上時代的發展。
<b>制約與考核</b><b></b>
打破原先的平衡以後，新的平衡如何建立？重建立立平衡是需要時間的，dev在工程中話語權加大，權利是一定會被制約的，不是内部，就是外部市場。
每一個問題都要根據公司的實際情況尋找一個平衡點，找到責權劃分，怎樣去考核和制約，隻有将這三個點解完，才可能活下來将分工模式持續跑下去。
<b>devops</b><b>怎麼衡量？</b><b></b>
devops可以由四個角度做衡量：
工程效率：從某一個開發的團隊接到需求，到需求傳遞上線的時間有多長。工程效率能夠提升多少代表devops發揮作用的大小；
穩定性：當穩定性沒有保證時，效率越高死的越快；
非研發工作占比：當占比非常大時，離失敗就不遠了；
業務規模與運維人員比例：谷歌的每一個sre也要管理2000台機器的業務。
總結
1.
實作自動化運維後，很多運維人員就會面臨失業，但這是時代發展的必然結果，我們隻需欣然接受；
2.
devops沒有最佳實踐，我們該更關注一些案例的環境和業務背景，devops本身不是目标，是一個方法，一個理論；
3.
devops和傳統模式沒有好壞之分，隻有适不适合。