本文來自AI前線，作者/Tina。
在InfoQ成立15周年之際，InfoQ編輯部發(fā)起了“2007-2022：云、運(yùn)維、架構(gòu)、前端的15年演進(jìn)史”特別策劃，將和業(yè)內(nèi)專家共同盤點(diǎn)云計(jì)算、運(yùn)維、架構(gòu)、前端四大技術(shù)領(lǐng)域的演進(jìn)歷史，試圖從幾個切面窺見IT技術(shù)的演進(jìn)規(guī)律。本文是運(yùn)維篇。
特此感謝岳上、劉毅二位老師對本文的貢獻(xiàn)，他們的真知灼見，是本文能與大家見面的關(guān)鍵。
運(yùn)維的工作主要是“運(yùn)行”和“維護(hù)”，本質(zhì)上是保證軟件系統(tǒng)的穩(wěn)定運(yùn)行。
中國互聯(lián)網(wǎng)從20世紀(jì)90年代開始形成，隨后進(jìn)入快速發(fā)展階段。中國互聯(lián)網(wǎng)的發(fā)展為我們創(chuàng)造出了一個科技神話，到了2007年，多個中國互聯(lián)網(wǎng)企業(yè)的市值先后超過100億美元，躋身全球最大互聯(lián)網(wǎng)企業(yè)之列。隨之用戶和設(shè)備規(guī)模不斷擴(kuò)大，運(yùn)維技術(shù)也不斷地發(fā)生變化。從人工運(yùn)維，到腳本和工具的使用，再到平臺建設(shè)，運(yùn)維技術(shù)體系不斷完善，逐漸向自動化、智能化方向發(fā)展。
在這過程中產(chǎn)生的一個重要而且前后看上去相互矛盾的變化是，運(yùn)維和開發(fā)人員從“分離”狀態(tài)轉(zhuǎn)變?yōu)?ldquo;融合”狀態(tài)。DevOps于2009年出現(xiàn)，從一種實(shí)踐方法論，逐漸涉及到開發(fā)和運(yùn)營生命周期的各個階段，進(jìn)而演進(jìn)成了一種“運(yùn)維文化”。
在這15年里，運(yùn)維人員的職責(zé)已經(jīng)從操作性的維護(hù)工作，發(fā)展為需要多方面知識、具備IT綜合能力的研發(fā)運(yùn)維工作，難度相當(dāng)于翻越了多個山頭。
運(yùn)維的進(jìn)化：從人工腳本到自研平臺
運(yùn)維行業(yè)的發(fā)展，是與互聯(lián)網(wǎng)的技術(shù)發(fā)展趨勢相輔相成的。
互聯(lián)網(wǎng)發(fā)展早期，線上系統(tǒng)規(guī)模和服務(wù)器數(shù)量不大，可以用腳本來進(jìn)行部署維護(hù)工作。最初的業(yè)務(wù)運(yùn)維，主要工作是做好服務(wù)器的部署和變更，及時地處理掉一些告警、排除隱患，保證整個系統(tǒng)的穩(wěn)定運(yùn)行。
2010年左右，隨著互聯(lián)網(wǎng)行業(yè)快速發(fā)展，用戶規(guī)模增大，需要維護(hù)的系統(tǒng)資源也有了大規(guī)模的增長，靠人工或腳本已經(jīng)捉襟見肘了。早先運(yùn)維的“資源”和運(yùn)維的“人數(shù)”，是兩條同步上升的直線，但到后來，資源可以大規(guī)模投入，運(yùn)維人員卻不能照樣同步增加。人工運(yùn)維也存在著一些風(fēng)險(xiǎn)，所以當(dāng)運(yùn)維的效率無法支撐業(yè)務(wù)規(guī)模化發(fā)展時，就進(jìn)化到用平臺去解決運(yùn)維問題的主流方向上。運(yùn)維平臺的研發(fā)也讓運(yùn)維和開發(fā)從兩者分離演變?yōu)榛ハ嘟Y(jié)合，DevOps的概念開始流行起來。
另一方面，互聯(lián)網(wǎng)也促進(jìn)了云計(jì)算的發(fā)展。到了這個階段，管理成千上萬規(guī)模的數(shù)據(jù)中心服務(wù)器，運(yùn)維必須從全局的角度思考如何用平臺化的手段解決問題，追求大規(guī)模場景下的效率，通過自研系統(tǒng)，用集中化的監(jiān)控平臺把云數(shù)據(jù)中心的告警等統(tǒng)一在一個地方管理。
安全和質(zhì)量是運(yùn)維最初始的職能，但云計(jì)算行業(yè)發(fā)展起來之后，運(yùn)維關(guān)注的核心就變成了安全、效率、質(zhì)量、成本，多個維度并重。而且云計(jì)算在成本上提出了更高的要求。云服務(wù)的成本是商業(yè)模式里面一個非常重要的因子，運(yùn)維需要考慮如何用最優(yōu)的成本去提供最優(yōu)質(zhì)的服務(wù)，并做到極致。
所有維度都要并重，還要追求極致的安全、效率和成本，那么就需要對系統(tǒng)有非常精細(xì)化的掌控，運(yùn)維有了開發(fā)職能，對研發(fā)能力的要求也更高了。所以，在行業(yè)發(fā)展過程中，運(yùn)維工作的內(nèi)容不斷地被豐富，職責(zé)范圍越來越寬廣，難度已經(jīng)不是腳本時代能比擬的了。
“全能”的云數(shù)據(jù)中心運(yùn)維人
這是運(yùn)維最好的時代。
隨著國家政策推進(jìn)企業(yè)上云，云服務(wù)逐漸成為了社會的基礎(chǔ)設(shè)施，主流云計(jì)算廠商加碼建設(shè)數(shù)據(jù)中心，數(shù)據(jù)中心的運(yùn)維是云服務(wù)正常運(yùn)行的一大支柱。
以前的技術(shù)不能滿足需求，必然倒逼著運(yùn)維人不斷攝取新技術(shù)并將其用到這個行業(yè)中。
首先是對自研能力的要求。“以前，在數(shù)據(jù)中心基礎(chǔ)設(shè)施層面，我們采用屬地化運(yùn)營，比如一些監(jiān)控、告警的操作都是由廠商提供的。隨著規(guī)模擴(kuò)大，效率要求提升，像騰訊的云數(shù)據(jù)中心就開始自研集中化、平臺化的統(tǒng)一運(yùn)維平臺。從遠(yuǎn)端的集中監(jiān)控中心到園區(qū)級，本地ECC監(jiān)控中心，再到具體的某一個模組，獨(dú)立的配電單元的監(jiān)控中心，然后再到下面的采集器層面，實(shí)現(xiàn)軟硬件上的全面自研。這在技術(shù)和模式上就有了非常大的變化，相應(yīng)的在廠商層面上就很難做到。”岳上舉例說道。
在此基礎(chǔ)上，數(shù)據(jù)中心的自研平臺需滿足一些極致的技術(shù)指標(biāo)。過去對基礎(chǔ)設(shè)施的監(jiān)控告警，從設(shè)施出現(xiàn)問題到捕獲到告警的時間大概是在分鐘級，而自研平臺的時效能提升到10秒以下，更及時地排除可能的故障。
（現(xiàn)代數(shù)據(jù)中心）
一個超大規(guī)模數(shù)據(jù)中心，可能包含了上百萬臺服務(wù)器，面對海量的運(yùn)維對象以及這些對象產(chǎn)生的海量數(shù)據(jù)，運(yùn)維行業(yè)將大數(shù)據(jù)引入到數(shù)據(jù)中心運(yùn)維里面。對于云數(shù)據(jù)中心，甚至還可以實(shí)現(xiàn)對基礎(chǔ)設(shè)施做物理模型的建模，用數(shù)字孿生技術(shù)實(shí)現(xiàn)對基礎(chǔ)設(shè)施的配電和暖通的圖形建模，形成一個圖模一體的技術(shù)框架來可視化地表征整個數(shù)據(jù)中心實(shí)時運(yùn)行狀況。
面對海量數(shù)據(jù)，數(shù)據(jù)中心運(yùn)維人員從監(jiān)控著手，用數(shù)據(jù)治理提升數(shù)據(jù)的可信度，實(shí)現(xiàn)數(shù)據(jù)上的“準(zhǔn)”、告警監(jiān)控性能上的“快”、系統(tǒng)可用性上的“穩(wěn)”?；趫D模一體的技術(shù)框架又可實(shí)現(xiàn)告警風(fēng)暴的收斂，包括告警的一些降噪處理，把影響到現(xiàn)場運(yùn)營效率的無效告警在平臺層面上處理掉。
并且云數(shù)據(jù)中心運(yùn)維還需要有一些跨界，比如要關(guān)注電力系統(tǒng)、空調(diào)系統(tǒng)，了解新能源儲能系統(tǒng)的設(shè)計(jì)，同時在軟件層面用到一些互聯(lián)網(wǎng)行業(yè)的優(yōu)秀方法論和技術(shù)。
“舉個例子，比如有些戶外空調(diào)因?yàn)閲娏?，會有一個集水盤，超過一定水位它就會告警。在過去行業(yè)里面，南方的一場大雨或者北方的一場大風(fēng)，就會產(chǎn)生相當(dāng)頻繁的告警，但是這些告警往往不需要特別處理，因?yàn)楦鶕?jù)設(shè)備特性，它會自動排出并恢復(fù)。這就需要我們了解設(shè)備工況并做出合理設(shè)計(jì)。”
在有海量數(shù)據(jù)積累的情況下，云數(shù)據(jù)中心的運(yùn)維還可以進(jìn)一步引入AI方面的技術(shù)，提升運(yùn)維效率、降低運(yùn)營成本、強(qiáng)化運(yùn)營安全。例如，運(yùn)維可以利用故障樹、知識圖譜等方式快速定位故障根因，從而節(jié)省故障排查時間；可以通過將機(jī)器學(xué)習(xí)算法和設(shè)備機(jī)理模型相結(jié)合，得到最優(yōu)設(shè)備運(yùn)營控制策略，從而節(jié)約運(yùn)營能耗；還可以應(yīng)用AI模型對設(shè)備進(jìn)行精準(zhǔn)預(yù)測，實(shí)現(xiàn)設(shè)備自動化巡檢，從而保障運(yùn)營安全等等。
無論是大數(shù)據(jù)還是AI技術(shù)的使用，都說明了在云的發(fā)展過程中，運(yùn)維人員隨著所運(yùn)維的主體的重要性增強(qiáng)、復(fù)雜度增強(qiáng)，對其要求也會持續(xù)提升。
運(yùn)維實(shí)踐是一個傳遞的過程。運(yùn)維工作可以將很多基礎(chǔ)設(shè)施工作代碼化，而業(yè)務(wù)運(yùn)維的層面在多年前已經(jīng)是自研平臺來管理，再往下還可以逐漸卷入更多層面，如SaaS、IaaS層，這也是IT運(yùn)營中“anything is code”的思路體現(xiàn)。岳上表示，“我覺得這是必然的趨勢，這個過程中，整個運(yùn)維的文化的傳承和發(fā)展演進(jìn)是一個蠻有意思的課題。”
DevOps的興起
運(yùn)維人要具有開發(fā)思維，研發(fā)人也要具有運(yùn)維思維。
我們看到運(yùn)維行業(yè)在平臺化、智能化的發(fā)展過程中，越來越要求運(yùn)維人員具有開發(fā)能力。但其實(shí)自運(yùn)維崗位誕生之后，在很長時間里，運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)（DO）相互獨(dú)立，猶如中間存在著一堵墻。DevOps的出現(xiàn)，將開發(fā)和運(yùn)維融合到了一起，DO分離反而成為了一種反模式。但它發(fā)展得這么火，變成一個全球性的“運(yùn)動”，卻是連DevOps之父Patrick Debois也意料不到的。
2007年，Patrick的項(xiàng)目遇到了難題，開發(fā)和運(yùn)維團(tuán)隊(duì)之間總是存在爭論，阻礙了項(xiàng)目的正常開展。畢竟研發(fā)團(tuán)隊(duì)在引入敏捷以后講究的是快速變更、快速迭代。但是在運(yùn)維層面，追求的還是穩(wěn)定性、可靠性、安全性。所以這兩個組織之間自然就會有隔閡，溝通協(xié)調(diào)要浪費(fèi)大量時間和精力。
后來他遇到了另一位關(guān)注同樣問題的Andrew Shafer，兩人討論出了一個解決方案：聘請“思維過程與開發(fā)人員一樣的運(yùn)維人員”，以一步構(gòu)建和部署項(xiàng)目。Patrick在Twitter上宣傳他的想法時創(chuàng)建了一個名為“DevOps”的標(biāo)簽，意外的是，這個標(biāo)簽很快就成了一種主流解決方案的代名詞。
DevOps想解決的問題到底有哪些
DevOps本身是開發(fā)和運(yùn)營兩個英文單詞拼在一起，顧名思義是想拆掉開發(fā)和運(yùn)維之間的墻，讓開發(fā)運(yùn)維兩種文化貫通融合，讓這兩個團(tuán)隊(duì)能充分地理解對方并協(xié)作，可以認(rèn)為它是一種方法論，一種“文化”。支撐這個文化的背后，是一系列的自動化整合實(shí)踐，最終的目的是讓所有的團(tuán)隊(duì)回到最初的目的上來，更快更可靠地構(gòu)建測試，更高效地交付軟件。
到2015年左右，越來越多的公司開始將這個方法論升級成一種運(yùn)動，更多強(qiáng)調(diào)工具化、自動化。
比如在流程工具選擇上，以前很多是用像assible這樣的自動化工具來解決單個環(huán)節(jié)的問題，慢慢的運(yùn)維從面向腳本、面向單點(diǎn)工具開始走向一站式流程工具，如DevOps這樣的pipeline CI/CD。這些pipeline也能在線上直接對接到plan的部分，甚至對接到知識管理部分，以及下游的面向運(yùn)維的像風(fēng)控響應(yīng)、故障響應(yīng)的系統(tǒng)，讓DevOps在一種標(biāo)準(zhǔn)化接口的層面順暢地跑起來。也就是說DevOps工程師還必須了解源代碼管理、持續(xù)集成和軟件測試自動化等流程是如何工作的。這些都是現(xiàn)代軟件開發(fā)鏈的核心組成部分。
發(fā)展到今天，DevOps已經(jīng)不僅僅是簡單地對過程的描述、對方法的描述，更多的是文化、實(shí)踐層面的事情，甚至慢慢影響了企業(yè)的“管理”。很多大公司對它的定義都不一樣，亞馬遜定義它是“哲學(xué)、實(shí)務(wù)和工具”，微軟定義它是“人員、流程和產(chǎn)品”，還有定義為“組織和文化”、“軟件交付方法”的。不得不說硅谷企業(yè)很善于形而上地把其抽象成一種理念和文化。
在國內(nèi)，最早擁抱DevOps的是互聯(lián)網(wǎng)企業(yè)，特別是頭部的互聯(lián)網(wǎng)企業(yè)將DevOps的思想和理念固化為對外的商業(yè)化DevOps產(chǎn)品和服務(wù)，能利用它有效屏蔽DevOps實(shí)施過程中底層的復(fù)雜度。而后逐漸影響到傳統(tǒng)的包括金融、汽車制造這樣的傳統(tǒng)行業(yè)，因?yàn)樗澈蟊苊饫速M(fèi)、自動化、全流程的思想給企業(yè)帶來了一定的收益，同時降低了信息化轉(zhuǎn)型過程中的門檻。
所以總的來說，除了強(qiáng)調(diào)協(xié)作和溝通，DevOps讓開發(fā)運(yùn)維兩個團(tuán)隊(duì)互相介入，變成一個融合的團(tuán)隊(duì)了。運(yùn)維團(tuán)隊(duì)在項(xiàng)目一開始就進(jìn)入了基礎(chǔ)架構(gòu)和技術(shù)路線的選擇流程里，甚至可以在代碼框架上、在代碼選型上給出合適的高可用性、高擴(kuò)展性、高維護(hù)性的運(yùn)維方案，涉及到了軟件開發(fā)生命周期SDLC的每一個環(huán)節(jié)，是一個在文化、技能、流程、工具上的綜合性文化體系。
“在我們看來，DevOps是敏捷發(fā)展的自然結(jié)果，敏捷解決了需求和開發(fā)之間的協(xié)同溝通的問題，但是到了最后一步，DevOps在運(yùn)維層面上打破了這堵墻，在最后一公里上銜接起來了。”騰訊云DevOps負(fù)責(zé)人劉毅表示。“DevOps的思想也一樣的，在我們談業(yè)務(wù)降本的時候，在分析每一個不良的中間環(huán)節(jié)時，都需要去思考怎么盡可能減少浪費(fèi)。”
DevOps的天時地利人和
2010年后技術(shù)的發(fā)展，讓DevOps有了順勢而上的機(jī)遇。
這一時期也正是微服務(wù)興起之時，它是更輕量的SOA，核心解決了軟件復(fù)雜度里面最重要的高類聚低耦合還有伸縮性這樣的問題。然而它有利有弊，微服務(wù)帶來了更高的復(fù)雜度，提高了可觀察、測試和運(yùn)維的難度，容器的出現(xiàn)為微服務(wù)提供了一個量身訂作的底座。
2013年Docker開源，容器編排工具Kubernetes也逐步獲得市場認(rèn)可，存儲、計(jì)算、網(wǎng)絡(luò)都通過Kubernetes這層進(jìn)行了統(tǒng)一抽象和封裝，讓已經(jīng)被容器統(tǒng)一的微服務(wù)能夠直接運(yùn)行到Kubernetes平臺，容器的一致性、自動化非常輕便地解決了底層支持的問題。
容器化提供了支持后，DevOps自動化的能力、成本管理能力都得到了加強(qiáng)。DevOps需要對全流程有更多的觀察，也需要有更多的透明性，容器技術(shù)也提供了直接的幫助。資源的伸縮、成本的控制，這些都很好地支撐了DevOps技術(shù)的發(fā)展。
更重要的是，容器平臺以及云原生的成熟度，提升了人員和IT系統(tǒng)之間的協(xié)作性。Dev人員滲透到Ops層面的時候，協(xié)作更為流暢。“所以也可以說容器和微服務(wù)極大地推動了DevOps技術(shù)的發(fā)展。”劉毅總結(jié)道。
容器和微服務(wù)技術(shù)加速了DevOps的落地，像騰訊這樣的企業(yè)在兩三年前也在內(nèi)部大規(guī)模實(shí)踐，將研發(fā)流程和使用的工具都進(jìn)行了統(tǒng)一和收斂，構(gòu)建倉庫、CI/CD流水線等都用DevOps來實(shí)現(xiàn)。而且據(jù)信通院發(fā)布的2021年《中國DevOps現(xiàn)狀調(diào)查報(bào)告》顯示，落地實(shí)踐成熟度處于全面級的企業(yè)多達(dá)35.40%。
DevOps的大規(guī)模應(yīng)用，也改變了企業(yè)的組織結(jié)構(gòu)。以前DO分離這種結(jié)構(gòu)慢慢在很多場景下變成一種“反模式”。一些組織會建設(shè)跨職能的DevOps團(tuán)隊(duì)，這種組織結(jié)構(gòu)貫穿了開發(fā)運(yùn)維甚至包括工具團(tuán)隊(duì)、架構(gòu)師，還有一些工程團(tuán)隊(duì)、業(yè)務(wù)團(tuán)隊(duì)，形成一個多角色組織在一起的跨職能團(tuán)隊(duì)，負(fù)責(zé)人一般直接向CTO或者CIO報(bào)告，從而推進(jìn)整個組織里DevOps文化的落地。
這些進(jìn)一步給開發(fā)運(yùn)維團(tuán)隊(duì)帶來了改善。因?yàn)殚_發(fā)和運(yùn)維有了共同目標(biāo)，開發(fā)的團(tuán)隊(duì)也在轉(zhuǎn)型，會去關(guān)注質(zhì)量的左移和右移，盡早發(fā)現(xiàn)問題，避免問題往下游走。同時也會更多地去關(guān)注運(yùn)維層面的問題，根據(jù)發(fā)生的問題去做復(fù)盤和根源分析，從而縮短問題解決時間（MTTR、MTTD），縮短所謂的lead time，實(shí)現(xiàn)更快地迭代，更高頻地交付。
運(yùn)維團(tuán)隊(duì)也會參與需求分析等業(yè)務(wù)設(shè)計(jì)中，關(guān)注前期的架構(gòu)設(shè)計(jì)層面的事情。這要求運(yùn)維角色具有架構(gòu)能力，能提供對架構(gòu)進(jìn)行抽象，特別應(yīng)用層、API層的架構(gòu)抽象，提供更標(biāo)準(zhǔn)化的架構(gòu)設(shè)計(jì)建議。因?yàn)闃?biāo)準(zhǔn)化的架構(gòu)設(shè)計(jì)就意味著能具有更好的更輕松的運(yùn)維能力，而抽象層的建設(shè)也能更好地實(shí)現(xiàn)運(yùn)維層面的自動化工作。這些在DO分離的時候很難實(shí)現(xiàn)，現(xiàn)在運(yùn)維角色的人參與到早期的架構(gòu)和代碼過程中，能在項(xiàng)目早期消滅掉可能的問題。
不可忽視的AIOps
AIOps是一個對運(yùn)維以及未來影響深遠(yuǎn)的技術(shù)方向。
這些年來，隨著云計(jì)算、微服務(wù)等技術(shù)的流行，以及業(yè)務(wù)的迅速發(fā)展，運(yùn)維人員要關(guān)注的運(yùn)維數(shù)據(jù)（日志、監(jiān)控信息、應(yīng)用信息等）也呈現(xiàn)了指數(shù)級增長。
DevOps在全流程的角度橫向解決了一些組織協(xié)作的問題，但Ops這件工作本身是有其專業(yè)性的，以前的專業(yè)性講究在人、在工具上，那么在深度上，在數(shù)據(jù)問題上，結(jié)合人工智能，就有了AIOps。
AIOps，也就是基于算法的IT運(yùn)維（Algorithmic IT Operations），是由Gartner定義的新類別。正好海量信息中有大量的需要去挖掘和觀察的信號，這正是AI擅長的范圍，那么AIOps就很及時地出現(xiàn)，通過挖掘在可觀測領(lǐng)域曝出來的這些數(shù)據(jù)，消滅噪音，做自動化告警的聚合，最終帶來更深入、更準(zhǔn)確、更快的運(yùn)維。AWS的數(shù)據(jù)顯示，他們的AIOps工具上線以后，很多中小企業(yè)都縮短了80%以上的MTDR實(shí)踐，AIOps帶來的價值是非常明顯的。
因?yàn)檫@種IT系統(tǒng)本身過于復(fù)雜，新員工剛接觸到Ops的時候可能也是一頭懵的：他發(fā)現(xiàn)原來生產(chǎn)環(huán)境每天有各種事情發(fā)生，有些看到的是結(jié)果，只是表面上的現(xiàn)象。其實(shí)各種信號到來以后，其中有一些只是小的故障信號或者一些小的隱患源頭。這些大量的報(bào)警信息分散著運(yùn)維人員的注意力。那么怎么把這些信號、事件和根因進(jìn)行關(guān)聯(lián)，怎么快速地得到因果關(guān)系，然后快速地選擇最正確的響應(yīng)變更路徑，這就是AI可以幫助解決的問題，它能將運(yùn)維人員從紛繁復(fù)雜的告警和噪音中解脫出來。AIOps運(yùn)維人員，可以借助它提升自己的故障預(yù)警、根因分析的能力，進(jìn)而建立起提前防御的機(jī)制。
AIOps也給運(yùn)維工程師提出了更高的要求。自動化運(yùn)維平臺和DevOps的實(shí)施，需要運(yùn)維人左移到架構(gòu)、代碼方向，現(xiàn)在他們更是需要提升一些更垂直的能力，比如掌握大數(shù)據(jù)、機(jī)器學(xué)習(xí)這些知識，將以前的運(yùn)維經(jīng)驗(yàn)結(jié)合運(yùn)維數(shù)據(jù)，用機(jī)器學(xué)習(xí)的方法對這些數(shù)據(jù)進(jìn)行歸納總結(jié)、模型評估、模型選擇、參數(shù)調(diào)整進(jìn)行運(yùn)維決策，成為一種多領(lǐng)域結(jié)合的專家。
除了DevOps、AIOps外，其實(shí)也還有更多值得關(guān)注的，比如DevSecOps、GitOps還有FinOps等，目前國外有很多大的公司在談這方面的理論、文化，小的公司開始做這方面的工具。“國內(nèi)企業(yè)比較務(wù)實(shí)，更多的還是關(guān)注工具、一些應(yīng)用的落地，去收斂一致性、重視技術(shù)架構(gòu)，很少對外談理念。但在未來的探索上，我們需要積極擁抱新技術(shù)，迎頭趕上去，不要只是follow別人的工具和理念。”劉毅評論道。
數(shù)字化轉(zhuǎn)型下的運(yùn)維
當(dāng)各行各業(yè)都建構(gòu)在數(shù)字化技術(shù)之上，運(yùn)維的重要性攀上了前所未有的高峰。
IT運(yùn)維一直是企業(yè)數(shù)字化的有力支撐，但很多傳統(tǒng)企業(yè)的IT運(yùn)維甚至還處在依賴人的階段。對一些企業(yè)而言，數(shù)字化轉(zhuǎn)型意味著引入新技術(shù)、流程和文化以實(shí)現(xiàn)共同目標(biāo)。那么對于運(yùn)維來說，也不再是靠人工在系統(tǒng)中翻找數(shù)據(jù)、然后根據(jù)自己腦子里的經(jīng)驗(yàn)去做判別，企業(yè)IT運(yùn)維必定也會引入自動化的平臺運(yùn)維。
拆開來看，就是一項(xiàng)項(xiàng)的具體工作，構(gòu)建包括資產(chǎn)全生命周期管理、實(shí)時掌握資源使用情況、系統(tǒng)健康狀態(tài)、實(shí)現(xiàn)數(shù)據(jù)可視化、實(shí)現(xiàn)自動化部署、自動化處置、自動化故障接管等，這給運(yùn)維帶來的不少挑戰(zhàn)：
數(shù)字化是對現(xiàn)實(shí)場景的數(shù)字化表征，首先要做到的是對運(yùn)營需求的理解，它是越來越精細(xì)化的，并且數(shù)字化一定是體現(xiàn)在在對數(shù)據(jù)的實(shí)時掌握的基礎(chǔ)上，所以要求數(shù)據(jù)的采集、監(jiān)控是全方位的，并且是立體的。
以基礎(chǔ)設(shè)施為例，這就要求在告警、維修以及變更等等之間進(jìn)行打通。包括現(xiàn)在的一些3D大屏、數(shù)據(jù)看板，是對整體運(yùn)行情況的一些數(shù)據(jù)的呈現(xiàn)，也反映了數(shù)據(jù)工程師們對業(yè)務(wù)的深入理解?，F(xiàn)在行業(yè)上也有很多的此類運(yùn)維產(chǎn)品，也有了獨(dú)立發(fā)展的空間，這也是所謂的挑戰(zhàn)帶來的新的商業(yè)上的機(jī)遇。
同時，數(shù)字化轉(zhuǎn)型也要求運(yùn)維工程師提高對數(shù)字精細(xì)化的敏感度。如果數(shù)據(jù)采集、計(jì)算存在一些不太準(zhǔn)確的情況，可能會帶來呈現(xiàn)上虛報(bào)，這其中考察的可能包括一些數(shù)據(jù)物聯(lián)網(wǎng)的采集新技術(shù)、數(shù)據(jù)的校驗(yàn)、以及運(yùn)維對數(shù)據(jù)業(yè)務(wù)的理解。
比方說高密度IT機(jī)架運(yùn)行大數(shù)據(jù)和AI業(yè)務(wù)時會消耗大量電力，要確保關(guān)鍵業(yè)務(wù)的可靠運(yùn)行，就必須保證機(jī)架峰值功率運(yùn)行在額定容量內(nèi)。如果機(jī)架采集功率數(shù)據(jù)發(fā)生異常，譬如電表精度不足、硬件故障、配置錯誤、通信異常等，就可能發(fā)生機(jī)架“超電”風(fēng)險(xiǎn)，此時對多維數(shù)據(jù)源進(jìn)行綜合分析，例如比較服務(wù)器擬合功率，就可以判斷機(jī)架采集功率是否可信，從而確保IT業(yè)務(wù)有足夠供電容量。沒有可信數(shù)據(jù)，就可能傾向于保守運(yùn)營，預(yù)留太多的冗余容量，如果數(shù)據(jù)可信，就可以在保證可靠的情況下充分提升電力容量利用率，不僅降低電力成本，也符合各企業(yè)碳中和的戰(zhàn)略目標(biāo)。像這種數(shù)據(jù)治理的問題，都是在數(shù)字化轉(zhuǎn)型過程中需要運(yùn)維工程師們特別注意的地方。
在數(shù)字化演變過程中，相應(yīng)的自動化包括可靠控制要求也會更高。作為一個生產(chǎn)系統(tǒng)，它的高可用方面也會提出更高的要求，包括整個系統(tǒng)要做到4個9、5個9的高可用等等。
另外，進(jìn)行數(shù)字化轉(zhuǎn)型就意味著團(tuán)隊(duì)需要應(yīng)對經(jīng)常發(fā)生沖突的挑戰(zhàn)，例如快速變更、快速迭代的研發(fā)和穩(wěn)定、安全的運(yùn)維之間的沖突。這恰恰也是DevOps的設(shè)計(jì)初衷。利用DevOps可以將人員、流程和技術(shù)結(jié)合在一起，同樣也給企業(yè)帶來了梳理企業(yè)開發(fā)全流程和改善組織協(xié)作的機(jī)遇。
DevOps的落地，對于數(shù)字化轉(zhuǎn)型中中小企業(yè)來說具有一定的復(fù)雜度，這意味著企業(yè)需要采取一些策略，例如：
一、建立學(xué)習(xí)型組織，需要團(tuán)隊(duì)中的每個角色都有全流程能力。
二、除了打破壁壘，還要在透明性上做強(qiáng)，包括對研發(fā)行為、運(yùn)維行為本身的透明性，對生產(chǎn)環(huán)境、對系統(tǒng)的透明性。因?yàn)槭窃谛碌墓ぞ哳I(lǐng)域?qū)嵺`，如果不了解它的變化，就不知道未來的進(jìn)展是好還是壞。
三、中小企業(yè)可以引入屏蔽了復(fù)雜度的研發(fā)運(yùn)維一站式全平臺，然后關(guān)注自己業(yè)務(wù)和平臺之間的切合性，降低在技術(shù)層面、工具層面、流程層面從零開始建設(shè)的成本。
寫在最后
從過去這15年歷史來看，運(yùn)維在未來有著非常好的發(fā)展前景。
運(yùn)維是一個“超載”的概念。最初作為業(yè)務(wù)運(yùn)維來講，可能只需做好資源的分配，及時地處理掉告警保證整個系統(tǒng)的穩(wěn)定運(yùn)行就好了。早前運(yùn)維崗位技術(shù)含量不是很高，如果提供開發(fā)或者運(yùn)維兩個崗位供人選擇，可能大部分人會選開發(fā)崗位。
到了云原生階段，運(yùn)維開始追求大規(guī)模的效率，從全局的角度思考如何用平臺化的手段解決問題，對運(yùn)維的要求也在持續(xù)提升，運(yùn)維又被賦予了更多研發(fā)層面、管理文化層面的含義......
“我非?？春眠\(yùn)維發(fā)展的可能性，”岳上表示，“所謂‘超載’，就是在不同的時期，根據(jù)業(yè)務(wù)需要被賦予不同的職責(zé)和責(zé)任，那么由此來看，運(yùn)維人員可以想像的空間越來越大，可以做的事情也越來越多，未來也肯定有更多可以發(fā)展的方向。”
嘉賓簡介：
岳上，騰訊云數(shù)據(jù)中心總監(jiān)，自動化負(fù)責(zé)人。ODCC智能監(jiān)控與管理組組長。騰訊懷來云數(shù)據(jù)中心在2021年信通院數(shù)據(jù)中心智能化管理評估中獲評唯一Level4最高等級。
劉毅，騰訊云Devops的負(fù)責(zé)人。騰訊在2020年信通院DevOps標(biāo)準(zhǔn)評估中獲評唯一卓越級。
