10年經驗總結:企業級IT系統運維怎么搞?
其實不能說這是錯誤的理解,IT 運維人員的工作小到修電腦、理網線,大到部署整個數據中心。
負責運維的設備,小的從個人電腦,大的到數以億計的高精尖計算設備(比如 IBM 的大型機 Z13)。
從運維的工作層次來分,又分為硬件運維、桌面運維、系統運維、數據庫運維和應用運維。幾乎所有的和系統相關的問題,都與 IT 運維人員有關。
根據公司 IT 系統規模的不同,有的運維團隊不到 10 人,有的甚至達到數百人。每晚通宵達旦,為 IT 系統保駕護航。
但是始終還是有很多的人和同事會質疑:為什么我的電腦還這么卡?網絡速度還這么慢?某某系統還是上不去,很影響業務運營等等。
這些質疑讓運維人員很尷尬也很無語,有些問題甚至類似客戶沒有插網線,抱怨上不去網。
有時候甚至會胡思亂想,究竟運維的意義是什么?這么努力怎么還這么受氣?
前段時間與運維方面的朋友一起交流的時候,大家總是時不時的訴苦,抱怨運維苦逼,沒有成就感,甚至經常成為“竇娥”、“背鍋俠”的代名詞。
種種抱怨和不滿,也促使我更加的想表達一下如何做好 IT 運維方面的經驗和個人見解(不一定對,歡迎拍磚),尤其是企業級的 IT 系統運維。
因為企業級的 IT 系統運維不但系統分支多,而且夠復雜。業務頻繁變更,要求 IT 系統必須隨需應變。
本文作者將分為如下幾個部分剖析企業級IT系統運維者如何才能體現真正價值?
- 運維的價值
- 什么是運維
- 運維方法淺談
- 總結
運維的價值
我畢業后就一直從事 IT 系統運維方面的工作,從當初的桌面技術人員到現在的運維總監,一路荊棘,回想起來已有超過 10 年的運維經驗了。
雖然談不上老道,更說不上是大咖,但是也總結了一些自己對運維工作的理解,對運維價值的理解。
多年的摸爬滾打,我對運維總結成了兩句話:“技術只是手段,業務才是王道”。運維的好壞評定標準其實就是你給公司及業務帶來了哪些價值及哪些影響。
業內有很多的運維專場,每年不下數十場。從之前傳統運維到現在的敏捷運維甚至 AIOps,這些都是在說運維的方法。
通過這些方法讓運維變得更靈敏、讓運維人員更好的理解用戶的需求。但是萬變不離其宗的道理是,這些行為都是圍繞著不同的業務需求而展開,為了滿足不同階段業務的發展而設計。
無論是小企業還是大企業,很多時候,運維人員的確做了很多的事情,處理了很多緊急的事件,甚至都是在凌晨才動手,確實非常辛苦,真所謂是“累成狗,起的比雞早,睡得比豬晚”。
但是這些事情真正為業務創造了多少價值呢?老板知道嗎?可能這個就是運維人員該好好思考一下的了。
當然,我并不是否定我們運維在做的事情,畢竟我也是做運維出身的。這些事情的確是運維人員必須要做的。
但是我的觀點是不能陷在這個自我感覺良好的漩渦中——自認為運維做了很多的事情,非常的辛苦,甘做幕后英雄。
如果有這樣的想法,那一定是運維人員自己的問題了。運維不光是需要技術上的不斷改進與創新,更需要思維觀念的改變,學會站在業務的角度思考問題。往往在這個改變的過程中,運維的價值就會逐步的得到體現。
在這里,我總結了一下多年來自己做運維的經驗分享給大家,踩過的坑,背過的鍋,還歷歷在目。
希望大家可以避開這些問題,做好企業 IT 系統的運維,體現運維的真正價值給公司。
什么是運維
運維是一件對知識面要求很高的工作,它要求運維者不僅要懂得基本的系統與網絡知識,還要對運維的業務系統有較深的理解,知道整套業務系統的工作模式與工作原理。
這也是對運維人員學習能力的一種考驗。一聽到故障描述,就可以大概知道問題的故障點所在。同時知道如何通過技術手段及清晰的邏輯方法去發現和解決問題。
運維是一件對自動化要求很高的工作,隨著 IT 技術的不斷發展,越來越多的方便運維的技術應運而生。
從互聯網時代開始,業務系統的交付和迭代也變得越來越頻繁,從每月的迭代一次,甚至到了每天迭代多次的場景。
如果沒有自動化的手段快速響應與處理,對用戶的影響可想而知。自動化的主要目的個人認為主要是三個:
效率提升
初期自動化主要解決的是和日常運維例行工作相關的操作。
比如各種平臺的資源分配&回收、統一配置管理、CI&CD(持續集成&發布)、操作系統的部署、系統空間的擴容與縮容、簡單應用部署、文件分發等等,這些都是運維最基礎的工作,也是自動化最容易實現和集中的領域。
個人覺得凡是那些偏日常和重復的工作都應該自動化,解放運維的生產力,提升運維效率,降低人為失誤,讓運維的同事可以有更多的精力去學習更多的技能。
做更有價值的事情,無論互聯網時代還是大數據時代,人才畢竟是最貴的。
目前自動化的解決方案都相對完善了很多,所以可以放心的去實踐和應用。對于重要的領域和操作,一定要經過嚴謹的測試才能應用,否則自動化帶來的災難也是不可估量的。
可靠可控
可控對于運維人員來說是再重要不過的了,自身經驗是,如果運維一套不可控的系統,無疑是攥著一顆不知道什么時候會爆炸的定時炸彈,時刻擔心它會產生不可預知的后果。
可控要細說我覺得大致可以分為穩定性可控、性能可控和安全可控。
穩定性可控
作為企業級的運維人員,我們要運維的系統不但數量多,而且網絡架構復雜。
包括的硬件更是多樣,除了熟知的服務器、存儲、網絡設備、負載均衡設備等,可能還有很多是運維人員沒有接觸過的新玩意。
而這些硬件又承載了各種應用,組成了各類不同的系統供用戶訪問,復雜程度不言而喻。
如何讓這些設備在損壞的情況下也不影響業務,不影響運維人員陪女朋友看電影。
做到心中有數,掌控硬件損壞會對系統有什么影響,需要多少時間來修復等等。
性能可控
合理的分配系統資源產生合理的性能對系統的穩定性起到了至關重要的作用。
一個系統慢與快并不是運維人員最擔心的,而是時快時慢是最可怕的,因為那種狀態是最不可控的狀態,這樣的系統是不可能承載企業核心或者重要的業務的。
最典型的應用場景就是云計算平臺的資源分配。一旦平臺資源被錯誤的分配,對業務的影響是不可估量的,排錯過程也是運維人員最頭疼的。
安全可控
現在運維圈子流行的模塊化管理、運維自動化、可視化甚至是基于大數據決策的運維,本質上都是希望達到運維可控的目標。安全是唯一一個貫穿運維全部過程的模塊。
所以運維人員每日都會花費特別多的精力在系統的安全建設和防御上,比如防止哪些未授權行為,所有的操作必須通過堡壘機,關鍵操作必須通過審計等等。
IT 運維安全方面的內容還是相當復雜的,比如應用交付可控,各種變更可控以及效率可控都是值得特別關注的。
為什么我們熟悉的工作往往是最容易出問題的工作。簡單分析一下就是因為我們平常一直在周而復始的做一件事,產生了麻痹。
同理,IT 運維大部分都是一些重復性的操作與工作,但是又是必須的。合理的通過自動化代替人工操作,可以非常有效的避免低級錯誤的發生。
這對于企業級的復雜系統是至關重要的,可以明顯提高可靠性,減輕運維人員繁瑣的人工任務。
降低人員依賴
運維工作是個很有意思的工作,他不是靠人多堆出來的工種。運維工作對人員的技能要求還是比較高的,可謂是要精不要多,多培養精兵強將。
任何問題的處理都要避免靠堆人來解決,這種方式不一定會解決問題,但是一定會增加運維的成本。
運維是一件對精細化要求很高的工作,那么什么是精細化管理呢?
引用一段官方解釋:“精細化管理是源于發達國家的一種企業管理理念,它是社會分工的精細化,以及服務質量的精細化對現代管理的必然要求,是建立在常規管理的基礎上,并將常規管理引向深入的基本思想和管理模式,是一種以最大限度地減少管理所占用的資源和降低管理成本為主要目標的管理方式”。
現在的 IT 運維已經進入了精細化管理的時代,而不是以前的大鍋飯年代了。分工明確,注重細節、注重過程、注重質量。
通過技術手段對全部的信息進行收集,管理員可以隨時知道目前系統的運行狀態。從而提高運維管理的整體水平和效果,實現了靈活的彈性擴容能力。
運維是一件對責任心要求很高的工作,各行各業都對責任心有很強的要求,運維也是如此。
因為不同系統的應用等級不同,影響范圍也會不同。如果運維人員因為疏忽大意導致業務系統崩潰,所帶來的影響可能是災難性的。比如銀行的結算系統、股票的交易系統等等。
我認為一個運維人員技術可以不是那么精深,做事可以不是那么敏捷,但是一定要有一顆較強的責任心,否則一切歸零。
運維方法淺談
隨著信息技術的發展以及企業業務的不斷擴張,運維人員所面臨的系統架構越發的復雜,關聯度越發緊密。
從技術角度上,對運維人員的要求也會越來越高,需要個個都是精兵強將,對業務系統了如指掌。
現在的運維已經不像 N 年前那種被動式的運維了,需要運維人員快速轉變觀念,學會通過主動運維的方式應對復雜多變的 IT 問題,保證業務系統的穩定。
需要更多的站在客戶的角度思考問題,解決問題。當然,每個人的經歷不同,職責不同。
所以對運維的理解也會有不同,我們可以將運維說的高大上、高精尖,也可以將運維說的稀疏平常、平易近人。
高精尖、高大上是在于運維使用了很多非常牛 X 的技術,在業務系統沒有感知的情況下實現了業務的變更、升級。
終端用戶可以在無感知的情況下繼續進行自己的支付操作、游戲操作等等。
稀疏平常是在于用戶每天都有機會和運維人員打交道,或多或少,或深或淺都會有不同程度的交集。哪天不和運維人員發個牢騷、抱怨一下就會覺得自己沒有來上班一樣。
以下是我總結歸納的一些不成規律的運維經驗,不成方法的運維手段。正如前文所述,不同的人就會有不同的見解,不同的經驗就會碰撞出不同的火花。歡迎運維愛好者一起討論、拍磚。
結合自己多年的經驗,總結了一些運維經驗,希望可以拋磚引玉得到更多愛好者甚至專家的指點,促使我不斷的進步。
下文方法主要分為五大類:
- 文檔
- 流程
- 技術
- 監控
- 備份
文檔
正所謂兵馬未動,糧草先行。一個好的系統或者項目,必定有很多的文檔進行支撐。
比如系統建設前期,一定要做好系統的需求文檔、設計文檔、實施文檔。在系統建設中要依據前期的文檔進行實施和設計,并生成系統相關的問題總結文檔和更新實施文檔。
系統建設完成后,要基于系統的業務能力和使用對象編寫操作手冊和運維手冊等。
有些業務在交付的過程中,并未按照要求提供相關的文檔,系統上線后問題層出不窮,導致運維人員手忙腳亂,不知道從何下手處理,往往會讓運維人員繞很多的彎路,錯失良機。
文檔也分好多種,比如配置文檔、實施文檔、設計文檔、系統規范性文檔、項目管理文檔等等。
基于種種,所以要求運維人員一定要具備相應的文檔編寫能力和整理能力。同時一定要嚴格按照之前的文檔進行實施,有問題要學會及時溝通,并把修正后的問題更新到文檔中。
以前文檔的管理大多數是放在用戶的本地,高級點是放在共享的 NFS 或者 FTP 中。但是很多的功能受到技術限制,不能滿足高效、敏捷、互動的要求。
通過知識庫的一個文檔管理功能,不僅可以解決如上問題,還可以將不同運維人員的經驗和知識轉化為生產力,協同辦公。類似的軟件比如 Confluence、Wiki 等。
流程
正所謂無規矩不成方圓。隨著 IT 環境的不斷擴大,業務變更的頻繁度越來越高,就要求運維人員一定要基于一個既定的規則來干活。
而不是完全按照業務的要求,被扯來扯去,拆東墻補西墻,畢竟業務人員專注點與運維人員的專注點不同,責任也不同。這規則就稱為流程。
在 IT 界最有名也最實用的流程莫過于英國政府部門 CCTA 在 20 世紀 80 年代末制定的 ITIL 了(即 IT 基礎架構庫(Information Technology Infrastructure Library,ITIL,信息技術基礎架構庫)。
當然現在由英國商務部 OGC(Office of Government Commerce)負責管理,版本也從當初的 V1 到了現在的 V3。
ITIL 為企業的 IT 服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規范。
這次我不是要細講 ITIL 的內容,有興趣的朋友可以 Google、Baidu 一下,認真研讀 ITIL,一定會讓你受益匪淺,尤其是運維人員。
ITIL 環形圖
在整個系統的運維過程中,流程由始至終貫穿整條鏈路。它是對運維人員的保障,同時也是對所做變更合規可控的保證。
合理的流程設置不僅節約了運維成本,也可以推進事情有序的進行,達到預期效果。那么如何制定符合實際需求的流程呢?這個就仁者見仁,智者見智了。
我把整個過程分成三個階段:
- 要做啥?就是說這個流程要完成什么任務,目的是什么,切記一定是一個或者唯一的任務,不是多個任務。比如要安裝軟件、要變更配置、要發布程序等等。
- 誰來做?就是說要完成這個事情,需要涉及到哪些部門的哪些人。請切記,流程一定要落實到人,否則就是空談。
- 多長時間?一個流程從開始到結束一定是有個時間約束的,也就是說這個流程被要求多長時間內必須完成。
一般這個往往和業務系統的 SLA 有關,達不到要求可能會扣銀子,那就不好玩了。
當然流程不是固定不變的。隨著 IT 業務和人員的變更,要學會對流程進行優化和改進,以適應最新的 IT 環境和業務要求。
技術
正所謂工欲善其事,必先利其器。如今是一個知識爆炸的時代,想獲取什么知識只需要打開瀏覽器即可。
不像以前還要頻繁的出入圖書館,我記得當年自己經常去的就是新華書店啦(主要是因為那里可以坐下來慢慢的看書,而且還可以將其抄錄下來),暴露年齡啦!
現如今很多的企業都在強化以用戶服務為中心,專業技術為驅動的理念,可見擁有過硬的技術是多么的重要。
這里所說的技術,我主要想從兩個方面入手,一個是指人員自身所掌握的技能,另一個是指對主流技術的剖析與實踐能力。
人員自身技能
運維對技術的要求還是很高的,不是誰都可以做運維的。首先運維人員要對自己所負責的系統有較深的理解,全程參與系統的設計、實施與運維。
正所謂打鐵還需自身硬,就像武俠名著所說,每個武俠人物都會有個看家本領,比如喬峰的“降龍十八掌”,段譽的“六脈神劍“。
運維人員也是如此,一定要具備相關領域的技術積累,有較豐富的設計或者排錯經驗。
同時要具備較為靈敏的技術嗅覺,不敢說需要十八般武藝樣樣精通,但是也要對相關輔助技能略知一二,此稱為硬實力。
光有硬技能其實只能證明你可以解決系統的硬性問題,但是不具備更好的解決問題的能力。很多重大的問題幾乎都與外界系統相關聯,甚至是強關聯。
這個時候單純的技術能力就很難解決了,需要運維人員具備以下軟實力:
我認為首先要具備的就是溝通能力:記得剛工作的時候,我們部門的技術人員被戲稱為“傻、呆、倔”,腦子里裝的都是代碼和命令,什么風花雪月、人情世故都成功的過濾了我們。
隨著困難增多,坑踩多了后,才知道溝通是多么的重要。良好的溝通可以很快與多部門協同工作,了解大家的共同點和痛點,對癥下藥,可以更快速的解決問題。
合作心態很重要:這么多年,我一直認為團隊作戰遠比孤軍奮戰要強,效率要高。尤其現在很多的公司都有分公司,IT 運維人員往往也是分布式的。
總部與分公司員工之間只有保持合作心態才可以高效、快速的發現問題、解決問題。
同理心讓溝通事半功倍:很多人認為同理心是企業中負責用戶體驗部門的技能,實際上隨著互聯網技術的發展,IT 與業務的緊密融合,運維人員是非常需要同理心的。
當運維人員接到故障報告或者通知,需要及時與客戶溝通,站在客戶的角度理解問題,解決問題,避免無謂的抱怨與投訴,提高運維滿意度。
善于寫作的基礎:無論是系統還是項目從孵化到交付都離不開文檔的支持。運維人員應該具備良好的文檔寫作能力,可以將系統設計說明清晰,問題描述清晰,解決方案條理清晰。
運維人員如果每天都往機房跑,一定是有問題的。多數時間應該是在學習、探索,自我提升、總結問題,避免二次發生。這些都需要文檔的記錄與支撐。
認真做事的態度:認真做事的態度在任何的行業都是通用的好模板。記得一本書上說過“你做事的態度,決定你的高度”對于運維人員來說,一定要高度熱愛自己的工作,如果你不熱愛它,肯定不會認真的去做。
這不是一句口號,而是要以結果為導向,具備不達目的不罷休的精神。有些運維上的問題,就是某個細節所決定的,只有認真才能從眾多亂麻中,找到線索,解決問題。
主流技術的剖析與實踐
運維人員一定要對現在的主流技術有一定的涉獵(云計算、邊緣計算、大數據、AIOps、人工智能、深度學習等等),要與時俱進。
經常參與線上或者線下的相關討論和交流學習。了解目前流行的 IT 技術,并學習它,思考如何將其用于企業的業務中,為企業創造價值,提升運維效率。所以具備主流技術的捕捉能力,也是運維人員的必修課之一。
監控
正所謂與其后悔于已然,不如防患于未然,監控的目的就是防患于未然。通過監控,運維人員能夠及時了解到企業網絡的運行狀態。
一旦出現安全隱患,可以及時預警或者是以其他方式通知運維人員,讓運維監控人員有時間處理和解決,避免影響業務系統的正常使用,將一切問題的根源扼殺在搖籃當中。
監控的方式很多,軟件更多。如何選擇監控對象、設計監控指標就需要運維人員根據不同業務的實際情況自己去實踐了。
但是一定要記住,現在的監控工具可以在監控指標觸發時,自動修復一些故障,但是它最多幫你做些簡單的自動化任務,更高階的自動化任務需要運維人員具備較深的腳本和系統知識。
所以監控作為運維人員的眼睛,要時刻保持 12 分精神,運維人員要定期對監控系統進行“照料”,避免“視覺疲勞”,影響監控效果。
備份
正所謂天有不測風云,人有旦夕禍福。備份是一種保障機制,一般用不到,用到就是大事。
備份可以說是運維人員的最后一根救命稻草,用好這最后一根稻草可以起死回生,用不好就會死無葬身之地呀。
其實一點也不夸張,公司將重資產都交給運維來做,是對運維的信任,運維人員自然要對這些資產和數據負責,對公司負責,這也是運維價值的一種體現。
現在備份軟件很多,國產的、國外的,所以選擇一款適合自己業務需要的備份軟件很重要。
不是什么數據都需要備份,要首先甄別出哪些數據需要備份,確定備份范圍。
制定好備份策略,不同的數據需要不同的策略設定。選擇靠譜的備份介質,到底是選擇磁帶、硬盤還是光介質等,這些都是需要運維人員根據業務需求而制定。
總結
以上這些算是自己對這十年運維經驗的小小總結,很多內容不可能一次說完,也不可能全部寫下來,畢竟運維這東西很多還是看自己的感悟和直覺。
在運維方法淺談章節中,我僅僅是總結了自己做運維用到的一些主要方法,并未涉及具體的技術。
可能有些朋友會問,為啥沒有體現當下流行的 CMDB、可視化運維、ITSM 等。
其實這些都只是工具,一種讓運維更透明,讓運維人員更輕松,讓老板更放心的運維工具。在實際工作中,可以根據需要自行采購或者自己開發,滿足業務要求。
最后和運維的朋友分享一段心里話:“運維是一件細致的工作,不允許一絲馬虎。運維人員一定要富有勇于創新的精神和對工作的激情,有了這些東西,我相信,你一定是個非常優秀的運維人員。”
結尾祝做運維的朋友在運維的道路上越走路越寬,技術更上一層樓。也祝自己在以后的工作中學習到更多,分享更多給大家。
作者:張志強
簡介:從事信息技術服務及管理工作,多年的云計算、虛擬化架構設計、企業信息化建設、自動化運維經驗。熟練掌握 X86、Power、存儲、虛擬化等硬件設備調優與配置。擁有豐富的混合元架構及管理經驗,信息安全及網絡架構的設計與運維。