在DevOps到來之前，我們更多的是討論極限編程、敏捷開發和Scrum等方法論，而很少關注運維體系的建設和提高運維的效率。DevOps時代，我們關注的是從業務出發，提高整個價值鏈的交付速度，從而爲企業獲得競爭力和生產力。今天我們就來談談如何實現敏捷運維，助力運維人員轉型。
01 新的業務和技術架構對運維提出了更高的挑戰
一方面，隨着互聯網時代和數字化轉型的到來，通過科技創新和開拓新業務來提高企業核心競爭力和生產力，比如銀行業的網貸、信貸、網上銀行、API Bank和區塊鏈等業務，同時新的業務對科技部門提出了更高的要求：在安全穩定的前提下，快速的交付業務功能，從而實現業務價值。那麼科技部門就必須提高業務端到端的交付效率，主要包括持續集成（需求管理、源碼管理、編譯構建、代碼掃描和自動化測試）、持續部署（配置管理、基礎資源和組件自動部署、應用自動化發佈）和持續運營（監控、數據分析和業務運營）。
另一方面，隨着業務的高速發展以及超大規模業務體量的驅動下，大部分企業引入了更爲靈活的微服務架構。我們知道，微服務架構是從單體架構或分層架構演進而來的，從一個單體工程拆分出n個獨立模塊，如下圖所示：
注：上圖出自於趙成老師的書籍《進化：運維技術變革與實踐探索》
引入微服務架構後，軟件架構的細化拆分和靈活多變大大提升了開發人員的開發效率，繼而提升業務需求的響應和迭代速度。但是隨之而來的是架構複雜度大大增加，對後續的交付和運維帶來了極大的難度和挑戰。
02 配置管理（標準化）和自動化是亟需解決的運維問題
在傳統的模式下，研發團隊和運維團隊分歧的焦點主要在軟件新版本、新配置的變更和發佈速度上。研發團隊最關注如何能夠快速地構建和發佈新功能，而運維團隊更關注的是如何能在他們值班期間避免發生故障。換句話說，研發部門想要“隨時隨地發佈新功能”，而運維部門則想要“一旦系統在生產環境正常工作了，就不要再進行任何改動”。所以在傳統意義上這兩個部門的目標是互相矛盾的。
在DevOps模式下，只有一個共同的目標，旨在通過合適的準時制（JIT）業務流程來最大化業務產出，例如增加銷售和利潤率、提升業務速度、或儘量降低運營成本。DevOps知識體系由三大支柱（規範敏捷、持續交付、IT服務管理）和一個基礎（精益管理）組成。
注：上圖出自於EXIN DevOps Master 白皮書
很多企業成功了應用了Agile、Scrum和XP等方法論，即使提高了開發效率，但對業務速度提升還是覺得遠遠不夠，原因在於：表面上看起來是開發過程的瓶頸，但在調查中發現開發過程並非瓶頸，相反是業務流程應該被改進。所以我們應該從業務的目標出發，度量並改進和優化端到端的業務流程，比如：提高系統發佈頻率、降低發佈失敗率。
如上圖，我們調研了一些企業的IT管理工具後發現，從需求管理、代碼管理到持續集成已經有一系列的開源或商用工具支撐了，同時也具備了一系列的監控平臺，包括基礎監控（Zabbix、Prometheus和IBM Tivoli）、APM（應用性能管理）、NPM（網絡性能管理）和BPC。但是配置管理中心和運維自動化幾乎是空白的，仍然依靠人工運維和腳本化運維。由此可見，配置管理和運維自動化是目前持續交付最大的瓶頸，從而影響到整個業務流的效率。實現運維自動化和提高運維效率，進而實現敏捷運維，是亟需解決的問題。
03 敏捷運維的重點在於運維場景服務化工具的快速落地
在本文中，我把“敏捷運維”定義爲：IT運維團隊根據業務的需求，快速響應運維要求，並實現運維場景服務化工具的快速落地。這裏請注意重點在於“服務化工具”的落地，而不是單純的解決一次性的運維需求，我們再來看看似曾相識的幾個運維場景：
幫忙創建N臺XX配置的XX操作系統的虛擬機，今天下班之前需要；
幫忙提取XX機器下的XX日誌；
XX系統明天要正式上線，今晚大家做好通宵的準備；
這個週末是年度的災備切換演練，大家做好加班的準備；
對於以上的運維場景是否覺得很熟悉和痛苦呢，若是有對應服務化的工具你就可以這樣回覆以上的需求了：
我們提供了“雲資源管理平臺”自助申請功能，您提交資源要求申請即可，審批通過後會自動創建好資源，並將結果郵件給你；
我們提供了“日誌查詢”自助服務工具，您可以按需查詢和檢索對應系統下的日誌內容；
我們提供了“應用發佈自動化”自助服務工具，可以實現應用的一鍵發佈和上線；
我們提供了“災備切換演練”自助服務工具，使用實現災備切換的一鍵完成，整個過程在30分鐘內完成，並提供全程可視化實時展示頁面，直觀的看到過程進展。
唯有快速構建服務化工具，才能真正實現敏捷運維，體現運維的價值，實現運維轉型。
04 引入PaaS體系和運維場景工具，解決當前運維壓力
很多運維人員會抱怨說，我們現在每天都加班哪有什麼時間來構建運維工具呢？但隨着AI和微服務時代的到來，面向新技術、新架構和新業務，運維人員該何去何從呢？我這邊總結了運維建設的三個階段：
手工/腳本化運維：依靠人肉運維，運維人員長期處於被動支持的情況，7*24小時隨時待命，人員穩定性都難以保障，更不用談提升運維團隊能力了；
煙囪自動化：藉助商業產品和開源工具來解決一部分的運維壓力，人員壓力得到了一定的釋放。但帶來了另外的兩個問題，一是運維人員的能力仍然沒有提到提升；二是構建了一系列的煙囪式工具難以實現全鏈路調度自動化，當然數據化和智能化運維就更加困難了；
平臺化建設：引入PaaS體系和運維場景工具，解決當前運維壓力的同時，通過API網關向下治理企業內部煙囪式系統實現一體化管理，向上提供運維開發平臺，讓運維人員低門檻的構建個性化運維場景工具，實現運維能力的提升。
圍繞PaaS平臺搭建的工具在少數互聯網巨頭中已經有相對成熟的體系，也有在持續的對外輸出，我們可以看看過往一些基於騰訊藍鯨的PaaS平臺，嘉爲輸出的一些範例：
數據中心運維自動化工具：
應用運維自動化工具：
05 運維開發平臺，助力運維轉型
通過第一步，開箱即用的運維工具解決了當前的運維壓力，將運維日常重複的手工工作服務化和自助化，這樣將運維人員的精力和時間空出來纔有可能進入第二步，開始傳統運維到運維開發的轉型。此時運維人員又有顧慮：我們很少寫代碼，就怕我們Hold不住。但事實上，運維開發的門檻沒有想象中那麼高，況且運維人員纔是真正懂運維流程的，沒有比運維人員來開發運維工具更合適的人了。
面向開發人員，PaaS體系提供了很多的 “開發者服務”，讓開發者可以簡單、快速地創建、部署和管理運維工具。
以藍鯨平臺爲例，它提供了完善的前後臺開發框架、API 網關（ESB）、調度引擎、公共組件等模塊，幫助開發者快速、低成本、免運維地構建支撐工具和運營系統。PaaS 平臺爲一個應用（運維工具）從創建到部署，再到後續的維護管理提供了完善的自助化和自動化服務，如日誌查詢、監控告警、運營數據等，從而使開發者可以將全部精力投入到應用的開發之中。主要功能有：支持多語言的開發框架 / 樣例、免運維託管、運營數據可視化、企業服務總線（API 網關）、可拖拽的前端服務（MagicBox）等。
06 提升團隊能力，真正成功實現運維轉型
打造PPP（人員、平臺和流程），提升運維團隊能力體系，我們很清楚的看到敏捷的趨勢、也有很多優秀的互聯網公司把成熟的方案進行輸出，作爲進取的運維團隊除了優化系統的結構外，更是要透過學習和實踐確保適用於新的體系。
DevOps時代的到來，讓我們重新定義運維團隊的目標和價值，構建運維場景服務化工具的落地和運維開發轉型只是一個過程，而結果往往是激動人心的：通過提高運維效率，助力數字化轉型，提高企業競爭力和盈利能力纔是終極目標。