最近幾年，由於負責的範圍的變化。工作逐漸從某個IT領域或者部門，開始關注到整個IT體系的運轉和管理。中間也遇到不少困難，同時也有機會去從更高的層面去學習和實踐IT治理。文章主要是總結一下我對DevOps相關的理解和認識。
爲什麼會有DevOps，解決了什麼問題：
- 現代企業其實都是通過IT系統進行管理和運營的，在變化迅速和競爭激烈的領域，IT系統的新需求數量越來越多，軟件發佈的頻率越來越高，不少互聯網公司24小時內會發布幾十個到上百個release到生產環境。與此同時，業務對IT服務和系統的穩定性和質量的要求也在不斷提高。如何高效穩定地開發並上線新的業務功能，同時提供高質量的IT服務，關係到企業競爭能力的強弱，關乎商業價值的實現。
- 開發團隊和運維團隊在傳統的的企業IT部門中是兩個獨立的團隊。他們的構成和人員背景差異非常大，軟件開發團隊通常擅長於設計和開發軟件功能，算法，他們希望能夠儘可能多和快得完成客戶或產品部分的需求。而運維團隊通常把完成的軟件部署到生產環境，負責監控和解決軟件系統運行時的問題，希望的是系統的穩定地運行，他們竭盡一切需要達到SLA的標準。
關於測試團隊：Test這個環節通常會有專門的測試團隊負責，在很早期的時候，測試團隊和開發團隊也是分開的。不過自從敏捷開發流行以後，測試團隊的成員就已經被看做開發部門的一部分了，這也部分歸功於微軟的貢獻，他們當時新發明了SDET（軟件開發測試工程師）這個概念，以表明測試工程師也是開發人員。他們寫測試用例，進行功能和壓力測試，同時需要懂得一些開發技術並擁有自動化測試的能力。開發人員對自己的代碼質量也要負責，需要寫自己負責模塊的單元測試代碼，軟件開發人員之間需要交叉進行代碼review。
下面的DevOps圖相信很多朋友都見過了，當然這個圖也有不同的變化版本。通過這個圖來看，開發和運維團隊銜接的最關鍵環節在Release-Deploy這三個步驟。而這一部分是否能夠做得好，直接關係到DevOps在整個IT部門實施的成敗。這一部分現在的主要解決方案就是CI/CD-持續集成和持續發佈。DevOps不只是一個方法論，其涉及到整個IT團隊文化的調整，多種新觀念新方法論的實踐以及現代化運維工具的應用這三個方面。
DevOps兩大流派
對於DevOps問題的解決上，其實分成了兩大流派。讓我們來探討一下這兩派的觀點和適用範圍。
傳統IT公司的DevOps解決方案，代表 – AWS，IBM…
從傳統的運維模式轉變到更加靈活和高效的DevOps模式。IT部門還是保持傳統的人員配置和工作技能，但是在合作，實踐和工具的應用上有很多方向的實踐轉變。
IT部門文化的轉變
開發和運維部門必須打破傳統的界限，需要共同承擔軟件系統運行的穩定性和性能上的責任和義務。運維團隊有權利去拒絕沒有達到生產環境准入標準的Release。開發和運維之間，測試和運維之間充分的透明度和溝通機制。最好能夠在在一起辦公，或者至少部分運維團隊成員和開發團隊成員坐在一起。能夠容忍錯誤的發生，當錯誤的發生時，不要立刻責罰，而要通過分析，找到根本原因，並通過持續的改進來做好系統的強壯性和避免人爲錯誤造成嚴重的系統故障。
技術和方法論層面的變革
-
微服務的應用: IT系統應該逐漸從monolithic的模式轉向微服務的模式，這樣不同功能/模塊的開發和發佈能夠相對獨立，不同的敏捷團隊可以更加快速地迭代和測試，同時交給運維團隊的發佈包的粒度更小，出問題後對整個系統影響更小。同時採用新的運維工具可以無感知逐漸升級微服務，迅速恢復或者回滾故障的微服務。
-
CI&CD：持續集成和持續交付，這個概念其實提出的很早。但是直到最近幾年纔開始被主流的業界接受。傳統的軟件發佈頻率往往是以周或者月爲單位進行的。在很多情況下這已經不能滿足業務快速迭代的要求，同時也越來越不適應快速迭代的敏捷開發模式。而且這種大粒度的集成和發佈（通常一段時間的許多變更會在一個發佈中上生產環境）出現問題的可能性和影響都比較大。 而持續集成和持續交付的粒度小到開發人員每一次代碼的提交。一旦完成代碼提交就會觸發構建並執行自動化測試腳本和單元測試，同時測試團隊的成員也會收到通知進行測試確認。一旦通過就能夠自動發佈到stage環境進行最後的UAT確認，接着在運維團隊確認後自動發佈到生產環境。這種小顆粒的集成和發佈其實降低了每一次發佈的風險。同時給開發和運維團隊提供了一個快速溝通和協作的流程。另一方面，CI/CD也保證了開發環境，測試環境和生成環境的代碼高度得一致性，這給定位和解決問題帶來了便利。
-
Infrastructure as Code: 如今的IT基礎架構都運行在虛擬化的平臺-共有或者私有云上，從網絡，存儲到計算能力都是可以同過軟件來配置的。這給到基礎設施團隊和運維團隊部署新的服務和計算資源的效率和能力極大得提升。
-
持續監控和記錄：通過監控和日誌分析統計實時監控所有系統的運行狀態，在出現問題前預警，甚至自動干預和解決，提高整個運維的穩定性和效率。讓團隊關注在最有可能出問題的環節和系統，提前準備和預防。
運維工具的應用
下圖列出的是DevOps各個環節的常用工具。代碼的版本管理是Git(Git應該算是一統天下了,其他的版本工具基本都已經很邊緣化了）構建工具每種語言都不同，下圖裏列的是Java相關的構建工具Maven和Gradle。在整個DevOps工具庫中最重要和關鍵的工具必然是CI&CD工具，這是CI/CD在DevOps的核心地位決定的。CI&CD最流行的工具的就是Jenkins了，功能強大而且是開源軟件。通過持續集成和交付，真正串聯起了開發，測試和運維團隊，通過工具和流程讓三個團隊能夠協同工作。其次我覺得是自動化部署工具也非常重要，讓運維團隊能夠迅速發佈和創建標準環境。這些工具有Chef，Puppet和Ansible。總體來講，我覺得Ansible是比較推薦的工具，第一是能夠很好的和Docker一起結合使用。另外一點是Ansible採用的是Push模式去部署應用環境，不需要在其他節點上安裝任何Agent程序，靈活性很高。
頂級互聯網公司SRE派，代表 – Google （SRE是指Site Reliability Engineer 網站可靠性工程師）
兩本指導手冊，可以在這個網站免費看。在 https://landing.google.com/sre/ 有Google總結的很多關於SRE相關的信息和資源，可以作爲參考。這也是是谷歌力推的運維團隊的模式。不過這種模式也只有類似Google這樣的“豪門”公司可以採用。我閱讀了那個網站的介紹，並大概看了兩本指導手冊，發現SRE就是事實上谷歌的運維團隊。但是谷歌本身有着極高的准入標準，哪怕是運維團隊的成員也是以SDE（Software Develop Engineer）的能力和標準來招聘的，其SRE團隊成員中軟件工程師和系統工程師各佔一半。他們通常會以軟件工程的思維去處理運維問題，做一些自動化的流程，編寫工具提高運維效率和系統穩定性，甚至能夠直接去review開發團隊提交的代碼。SRE團隊和產品，開發團隊基本處在平等的地位，甚至相比之下還有些許特權。他們不但可以直接拒絕不符合運維要求的版本，甚至可以在某些情況下退出運維的工作，交給原來的開發團隊。
谷歌制定了一套標準，還整出了SLI，SLO和SLA三種系統運維指標，其中SLO是由SRE制定的。一旦開發出來的系統達不到SLO（service level objective），SRE團隊會要求開發團隊必須將主要精力放在增強穩定性上。爲此他們還發明瞭一個名詞叫Error Budget，就是說一個系統能夠有一定的錯誤餘量（原因是只要是人類做的東西總是有可能會出問題~~~），如果某時間段的Error Budget被用完了，那麼這個系統的最優先級任務將不再是新功能開發和上線，而是保證其質量和穩定性，直到其Error Budget再次恢復爲正。
我們其實可以看到，與其說SRE是運維人員，還不如把他們歸類爲專注於系統性能和穩定性的軟件工程師團隊。這種用軟件工程師團隊覆蓋運維工作的做法，在成本上和實際的企業文化上可能並不是所有公司都能夠採用的。不過如果有能力採用這種模式的公司，我覺得還是應該嘗試一下。
最後引用Google自己的一句話作爲結尾吧，
這句話其實說出了谷歌團隊心目中的SRE和DevOps的關係，
class SRE implements interface DevOps