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的難點和需要解決的問題

1. 尋找平衡點

DevOps是為了追求工程效率最大化而存在的，但是工程效率和穩定性的目標在大部分場景下都是相悖的，如何能夠在工程效率提升的前提下，保證穩定性不出問題？

傳統分工模式是OPS團隊負責，在DevOps分工模式中已經沒有OPS團隊了，只能開發團隊負責，當一個團隊同時負責兩個相互有衝突的case時，該怎麼辦呢？如果分成兩部分人分別負責業務KPI和穩定性KPI，就回到了傳統的分工模式。

2. 責權劃分

對於開發者而言，主業是coding，其它包括打包、測試、釋出都是輔業，它是工具的使用者，並不能完全將所有事情做得完美，在除coding以外的所有環節中，責任和分工要怎麼來分，除了開發以外的事情要佔用開發人員多少精力，才能保證DEV使用順暢，跟上公司業務發展？

其中核心是工具，工具是將二者粘合在一起的，工具起到了賦能和粘合的作用，工具還須可介入，需要人肉補位；另外，工具的進化要運維團隊、測試團隊和SCM團隊來負責，工具自己要足夠開放，才能讓其它團隊可以不斷優化某一環節；工具也要保證可持續成長，跟上時代的發展。

3. 制約與考核

打破原先的平衡以後，新的平衡如何建立？重新建立平衡是需要時間的，DEV在工程中話語權加大，權利是一定會被制約的，不是內部，就是外部市場。

每一個問題都要根據公司的實際情況尋找一個平衡點，找到責權劃分，怎樣去考核和制約，只有將這三個點解完，才可能活下來將分工模式持續跑下去。

四、DevOps怎麼衡量？

DevOps可以由四個角度做衡量：

• 工程效率：從某一個開發的團隊接到需求，到需求交付上線的時間有多長。工程效率能夠提升多少代表DevOps發揮作用的大小；
• 穩定性：當穩定性沒有保證時，效率越高死的越快；
• 非研發工作佔比：當佔比非常大時，離失敗就不遠了；
• 業務規模與運維人員比例：谷歌的每一個SRE也要管理2000臺機器的業務。

五、總結

1. 實現自動化運維後，很多運維人員就會面臨失業，但這是時代發展的必然結果，我們只需欣然接受；

2. DevOps沒有最佳實踐，我們該更關注一些案例的環境和業務背景，DevOps本身不是目標，是一個方法，一個理論；

3. DevOps和傳統模式沒有好壞之分，只有適不適合。