近幾個月，運維事件頻發。從「爐石資料被刪」到「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的難點和需要解決的問題
尋找平衡點
devops是為了追求工程效率最大化而存在的，但是工程效率和穩定性的目標在大部分場景下都是相悖的，如何能夠在工程效率提公升的前提下，保證穩定性不出問題？
傳統分工模式是ops團隊負責，在devops分工模式中已經沒有ops團隊了，只能開發團隊負責，當乙個團隊同時負責兩個相互有衝突的case時，該怎麼辦呢？如果分成兩部分人分別負責業務kpi和穩定性kpi，就回到了傳統的分工模式。
責權劃分
對於開發者而言，主業是coding，其它包括打包、測試、發布都是輔業，它是工具的使用者，並不能完全將所有事情做得完美，在除coding以外的所有環節中，責任和分工要怎麼來分，除了開發以外的事情要占用開發人員多少精力，才能保證dev使用順暢，跟上公司業務發展？
其中核心是工具，工具是將二者粘合在一起的，工具起到了賦能和粘合的作用，工具還須可介入，需要人肉補位；另外，工具的進化要運維團隊、測試團隊和scm團隊來負責，工具自己要足夠開放，才能讓其它團隊可以不斷優化某一環節；工具也要保證可持續成長，跟上時代的發展。
制約與考核
打破原先的平衡以後，新的平衡如何建立？重新建立平衡是需要時間的，dev在工程中話語權加大，權利是一定會被制約的，不是內部，就是外部市場。
每乙個問題都要根據公司的實際情況尋找乙個平衡點，找到責權劃分，怎樣去考核和制約，只有將這三個點解完，才可能活下來將分工模式持續跑下去。
devops怎麼衡量？
devops可以由四個角度做衡量：
工程效率：從某乙個開發的團隊接到需求，到需求交付上線的時間有多長。工程效率能夠提公升多少代表devops發揮作用的大小；
穩定性：當穩定性沒***時，效率越高死的越快；
非研發工作佔比：當佔比非常大時，離失敗就不遠了；
業務規模與運維人員比例：谷歌的每乙個sre也要管理2000臺機器的業務。
總結實現自動化運維後，很多運維人員就會面臨失業，但這是時代發展的必然結果，我們只需欣然接受；
devops沒有最佳實踐，我們該更關注一些案例的環境和業務背景，devops本身不是目標，是乙個方法，乙個理論；
devops和傳統模式沒有好壞之分，只有適不適合。
DevOps第一講 什麼是DevOps
devops第一講 什麼是devops devops概念早先公升溫於2009年的歐洲，因傳統模式的運維之痛而生。devops是為了填補開發端和運維端之間的資訊鴻溝，改善團隊之間的協作關係。不過devops其實包含了四個部分 產品 開發 測試和運維。devops希望做到的是軟體產品交付過程中it工具鏈...
什麼是DevOps？ 虛擬化 容器 微服務
提到devops這個詞，我相信很多人一定不會陌生。作為乙個熱門的概念，devops近年來頻頻出現在各大技術社群和 的文章中，備受行業大咖的追捧，也吸引了很多吃瓜群眾的圍觀。那麼，devops是什麼呢？有人說它是一種方法，也有人說它是一種工具，還有人說它是一種思想。更有甚者，說它是一種哲學。越說越玄乎...
阿里二面 什麼是mmap？
平時在面試中你肯定會經常碰見的問題就是 rocketmq為什麼快？kafka為什麼快？什麼是mmap？這一類的問題都逃不過的乙個點就是零拷貝，雖然還有一些其他的原因，但是今天我們的話題主要就是零拷貝。在開始談零拷貝之前，首先要對傳統的io方式有乙個概念。基於傳統的io方式，底層實際上通過呼叫read...