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