高效運(yùn)維最佳實踐七字訣,不再憋屈的運(yùn)維!

責(zé)任編輯:editor005

作者:蕭田國

2015-02-04 14:51:53

摘自:51CTO

本專欄的主線實際是一個運(yùn)維人員的十年成長史,從菜鳥到運(yùn)維總監(jiān)。本人做運(yùn)維這么些年,結(jié)合各種失敗與成功、痛苦與苦痛的經(jīng)驗,終于悟出高效運(yùn)維的七字訣:專業(yè)、熱情、方便、快。

做運(yùn)維的那么多,快樂的能有幾個?

我們那么努力,為什么總感覺過得那么憋屈、苦悶?做的事情那么多,為什么業(yè)務(wù)部門、直接領(lǐng)導(dǎo)和公司貌似都那么不領(lǐng)情?怎么做才能自己更加開心些?

本專欄的主線實際是一個運(yùn)維人員的十年成長史,從菜鳥到運(yùn)維總監(jiān)。但不是基礎(chǔ)技術(shù)教學(xué),也不會在運(yùn)維技術(shù)的某一方面過深涉及。更多的是應(yīng)用技巧、實踐經(jīng)驗及案例剖析。專欄中的系列文章,包含作者在運(yùn)維各個細(xì)分領(lǐng)域的技術(shù)和個人成才的心得體會。因此也可以成為廣大運(yùn)維朋友的工具書,伴隨大家從初級運(yùn)維成長為高級技術(shù)型運(yùn)維管理人才。

技術(shù)專欄就非得那么中規(guī)中矩么?咱這個專欄試圖以更輕松活潑的文字,徐徐道來,就當(dāng)是個老朋友,輕松愉快中,希望能給大家?guī)硎斋@和啟發(fā)。

前段時間有位IT大佬在網(wǎng)絡(luò)上發(fā)聲,我這么有錢,為什么不幸福?誠然,有錢是幸福的最重要條件之一,但有錢就一定幸福么?真的是充分必要條件?當(dāng)然更悲催的是運(yùn)維行當(dāng),技術(shù)好是被認(rèn)可(幸福)的最重要條件,但技術(shù)再好,外部門不說咱們“壞話”,已經(jīng)是很不錯的了。

1. 什么是高效運(yùn)維

我們收集了一些來自外部門對運(yùn)維的印(tou)象(su),如下圖所示。其中,大家看是否也多少有自己的影子?

高效運(yùn)維最佳實踐七字訣

往往看自己都很美,但從外部門來看,槽點多到乃至無力吐槽。首先,做事情不專業(yè),人為事故多(更多是低級的人為事故);很多時候,都是我們業(yè)務(wù)部門告訴運(yùn)維,運(yùn)維才知道發(fā)生故障了,而且故障解決時間過長;做個調(diào)試,老超出調(diào)試時間,超時也不說,是不是完成了也不知會一聲;部門內(nèi)老玩踢皮球的游戲,做個需求,老讓我挨個找人;申請個服務(wù)器,老費(fèi)勁了,扔我一個申請表,當(dāng)自己是衙門呢?或者扔我一個技術(shù)文檔,我哪看得懂?

專業(yè)、熱情、方便、快,這是為根治上述各種疑難雜癥,經(jīng)多年自我治療并綜合各方經(jīng)驗,得出的高效運(yùn)維七字訣。我們用一個簡單的公式來表示高效和專業(yè)的關(guān)系。專業(yè)是高效的基石,否則無從談起高效與否,而技術(shù)是專業(yè)的基石。但這恰恰也是運(yùn)維技術(shù)人員的誤區(qū)所在,誤以為,技術(shù)比較強(qiáng),就足夠了,并因此而忽視其他重要方面。

實際上,對外部門而言,運(yùn)維是個黑盒子,是一個輸入輸出的關(guān)系:外部門提出需求,運(yùn)維給出結(jié)果:完成、或未完成。本質(zhì)上而言,外部門不關(guān)心(也無法關(guān)心)我們采用什么技術(shù)來實現(xiàn)的,只關(guān)心是否如期完成。

合理的流程規(guī)范,就像血液,能讓部門穩(wěn)定而高效的運(yùn)轉(zhuǎn),大家都覺得開心,這也是專業(yè)與否的重要組成部分。但如果希望做到高效運(yùn)維,良好的客戶界面、合適的方法技巧,也非常有必要。這就像網(wǎng)站的UI,給人感覺舒服了,后面很多事情也能輕松愉快、順理成章地進(jìn)行。

2. 為什么難以做到高效運(yùn)維

做不到高效運(yùn)維,公司和業(yè)務(wù)部門不滿意,上級領(lǐng)導(dǎo)不滿意,自己也不滿意。原因很多,我們從管理者和員工角度分別來講。

● 糟糕的分工及連環(huán)反應(yīng)

發(fā)生在中小公司的糟糕情況,往往從不明確的分工,開始悲劇之旅。有些游戲創(chuàng)業(yè)公司,剛開始時運(yùn)維人員也就2、3個,基本每人都得會運(yùn)維的各個工種,游戲運(yùn)維、網(wǎng)站運(yùn)維(Nginx/PHP等)、數(shù)據(jù)庫運(yùn)維(MySQL等)、系統(tǒng)運(yùn)維(Linux/Windows等)、服務(wù)器上架、故障報修、甚至做網(wǎng)線。

公司業(yè)務(wù)擴(kuò)大很多后,如果運(yùn)維組織結(jié)構(gòu)不隨之而變,分工不明確,就會發(fā)現(xiàn)大家都在疲于奔命,什么都會的結(jié)果就是什么都不精。在運(yùn)維技術(shù)如此龐雜的今天,就是把人活活的架在火上烤。這樣引發(fā)的是多米諾骨牌效應(yīng):分工不明確 —>職責(zé)不清楚 —>考核不量化—> 流程不合理—> 缺規(guī)范 、少文檔。

● 做vs說的困境

一般運(yùn)維技術(shù)人員都不善于溝通(至少表面上,雖然大家都普遍有火熱的心,呵呵)。在微信、QQ大行其道的今天,這個問題變得更嚴(yán)重,而不是減輕。這也和工作性質(zhì)有關(guān),想想,一天到晚和服務(wù)器說話的時間,比和人說話時間都多。

另外,從人腦結(jié)構(gòu)來看,做和說兩難全,也是合理的??刂朴嬎恪⑼评砟芰Φ氖亲竽X,而表現(xiàn)力等由右腦控制。如果強(qiáng)行要求會做還會說,說不定會導(dǎo)致紊亂、崩潰甚至“腦裂”呢,呵呵(當(dāng)然,這個問題也是有解決方法的)。

更嚴(yán)重的是,很多同學(xué)沒意識到自己的溝通表達(dá)是有問題的,說句話能把人嗆死,也不知道如何有效表達(dá)。這樣就談不上熱情了。

● 資源錯配

管理者和員工都可能存在資源錯配的問題。對管理者而言,包括人員錯配和時間錯配,員工主要是時間錯配。

管理者如果把錯誤的人安排在錯誤的崗位,那么注定是個錯誤。例如,某位同學(xué)喜歡鉆研技術(shù),不喜表達(dá),非得讓他作為和外部門的接口人,那自然費(fèi)力不討好,大家都不開心。

管理者的時間錯配包括三種情況。

1)沉迷解決技術(shù)問題。這一般發(fā)生在剛從技術(shù)崗位提拔為管理者的時候,忘記自己是管理者了。解決復(fù)雜技術(shù)問題,能帶來愉悅感,否則就是挫折感。于是遇到技術(shù)問題時,非得死磕到底,然后一周過去了,而部門其他同學(xué)卻放羊一周。

2)一心撲在管理上。這又是一個極端了,忘記自己的技術(shù)身份。把自己變成一個項目經(jīng)理,整天只關(guān)心時間節(jié)點,不關(guān)注技術(shù)人員的小情懷,不協(xié)助他們解決具體的技術(shù)問題。

3)沉迷單個業(yè)務(wù)模塊。這是另一個特例。一般發(fā)生在內(nèi)部提拔時。例如某位同學(xué),之前是DBA組的負(fù)責(zé)人,提拔為運(yùn)維部經(jīng)理后,還是習(xí)慣于抓其擅長的數(shù)據(jù)庫工作,這也是不應(yīng)該的,否則就沒必要提拔了嘛。

員工的資源錯配主要體現(xiàn)在時間安排上。事情多了,分不清輕重緩急,沒有一個合理的排序原則、指導(dǎo)思想;混淆技術(shù)進(jìn)步和工作要求(有時過分追求技術(shù)進(jìn)步),簡單的問題復(fù)雜化,降低客戶滿意度。

3. 如何做到高效運(yùn)維

高效運(yùn)維從來不是一個簡單的事情,需要多方面共同努力來實現(xiàn),本文先擇其要點簡述之,以后專欄系列文章會有更多深入闡述。

● 明確分工/職責(zé)

美國著名管理學(xué)者史蒂芬·柯維在暢銷書《高效能人士的七個習(xí)慣》中提出了產(chǎn)出/產(chǎn)能平衡原則。想多產(chǎn)出,先得擴(kuò)大產(chǎn)能。想金雞多下蛋,就不能殺雞取卵。那么對于高效運(yùn)維而言,產(chǎn)能是什么呢?

包括三部分:1)框架,即合理的分工/職責(zé)/KPI,抱歉我提到了KPI,多么讓人如此愛恨交織的詞語;2)血液,即專業(yè)的流程/規(guī)范;3)界面,即良好的服務(wù)意識/技巧。這些投入足夠多,才會得到心儀的產(chǎn)出——高效運(yùn)維。在貫徹實施這些一段時間后,外部門會詫異的感覺:喲,怎么運(yùn)維變化這么大。雖然他們不知道原因,但我們可以微微一笑,呵呵。

具體到運(yùn)維部門而言,我們的分工,區(qū)別于內(nèi)網(wǎng)IT部。一個是服務(wù)外部客戶,一個是服務(wù)內(nèi)部客戶,差別還是蠻大的。根據(jù)部門分工,拆解出各個小組的分工,再落實到每個員工頭上。有章法,大家也覺得舒心。

運(yùn)維是支持部門,成本中心,難以產(chǎn)生利潤。所以其中重要的考核指標(biāo)其實是客戶滿意度,請相關(guān)業(yè)務(wù)部門給運(yùn)維同學(xué)打分,運(yùn)維內(nèi)部根據(jù)分工,也可以相互打分,這對應(yīng)著外部滿意度和內(nèi)部滿意度。KPI雖然令人不舒服,但總的來說,還是有存在的合理性。

  ● 技術(shù)的專業(yè)化

技術(shù)上的專業(yè)化運(yùn)維,涉及面也很廣,下面僅列舉幾例。

1)優(yōu)化監(jiān)控系統(tǒng)

誰來監(jiān)控監(jiān)控系統(tǒng)?怎么保證比業(yè)務(wù)部門先發(fā)現(xiàn)問題?是否需要添加業(yè)務(wù)監(jiān)控?URL監(jiān)控是否返回狀態(tài)碼200即萬事大吉?是否需要文件監(jiān)控?短信報警、郵件報警是否足夠?是否需要自動語音報警及垂直升級功能?

監(jiān)控是門學(xué)問,是專業(yè)運(yùn)維的入口。展開說可以很大篇幅,先拋磚引玉,提出這些問題。實際上,對于資深、聰明的運(yùn)維同學(xué),看到問題,就已經(jīng)有了自己的答案。

2)減少人為事故

人為事故是運(yùn)維最頭疼、最不專業(yè)的事情之一。例如網(wǎng)站運(yùn)維中,如果每次更新都需要登錄服務(wù)器,svn update/git pull,難免會出差錯。所以可以用類似Jenkins的工具,實現(xiàn)Web更新,這樣,除非重大更新(包括數(shù)據(jù)庫更新),否則都只需要點點鼠標(biāo)即可。甚至,可以把網(wǎng)站更新外包回開發(fā)部門,這樣還能減少運(yùn)維操作帶來的溝通成本、時間成本。

3)運(yùn)維自動化

運(yùn)維自動化是個大課題,網(wǎng)絡(luò)上的討論也很多。建議選擇合適自己的方式、方法。輕量級工具如ansible,無需在被管理服務(wù)器安裝客戶端程序,這在針對多臺服務(wù)器進(jìn)行分發(fā)管理(特別是管理僅有臨時賬號權(quán)限的服務(wù)器時),具有較大優(yōu)勢。另一個吸引人的地方是,操作結(jié)果和操作日志集中存儲。

4)合理優(yōu)化架構(gòu)

近幾年國內(nèi)優(yōu)秀的開源軟件層出不窮,設(shè)計和優(yōu)化架構(gòu),很多時候并不是非得自己從零起步來搞。例如Redis,以其高效、穩(wěn)定,已成為緩存系統(tǒng)的最好選擇之一,但Redis單實例的支撐能力有限,目前Redis集群的實現(xiàn),大多采用Twemproxy,但使用起來老感覺有些美中不足,那么,有沒有一個取而代之的產(chǎn)品?

Codis就是其一,Codis由豌豆莢開源,并廣泛用于其自身的業(yè)務(wù)系統(tǒng)。Codis剛好擊中Twemproxy兩大痛點(無法sharding,運(yùn)維不友好)。Codis可以平滑的擴(kuò)容/縮容,隨時增減Redis服務(wù)器;并提供友好的運(yùn)維界面,不僅能看到Codis系統(tǒng)運(yùn)行情況,還能進(jìn)行數(shù)據(jù)遷移、主備切換等操作。

另外,Codis還提供工具,將依賴于Twemproxy的Redis集群,平滑的遷移至Codis(太酷了,那畫面太美,我簡直不忍看)。性能方面,經(jīng)我們實測,在正常Value長度下,Codis的get/set性能,優(yōu)于Twemproxy。

5)代碼持續(xù)部署

線上系統(tǒng)程序代碼可否自動打包、持續(xù)部署? 測試環(huán)境的新版本發(fā)布可否由開發(fā)人員自己來做,甚至自己來做測試? 這些無疑可以很大提升運(yùn)維和開發(fā)效率。

Docker高可用集群,加上Jenkins發(fā)布,可以把這些需求變成現(xiàn)實。Centos 7的systemd用來底層支持Docker高可用,etcd實現(xiàn)了配置文件的集中存儲,而不是分散在各臺服務(wù)器的本地。fleet作為etcd和systemd之間的橋梁,并通過systemd來控制集群服務(wù)器。

Jenkins從svn服務(wù)器獲取到新代碼版本后,通過shell腳本,打包成image,放入Docker私有庫,從而被Docker集群服務(wù)器update并使用。

  ● 管理的專業(yè)化

管理上的專業(yè)化運(yùn)維,甚至包括調(diào)試通報和故障通報,都很有說法。系統(tǒng)運(yùn)行一段時間后趨于穩(wěn)定,調(diào)試/更新就變成了故障的主要來源之一,怎么讓調(diào)試少出人為事故,順利如期的完成?這是個技術(shù)活。

1)運(yùn)維345法則

故障通報是細(xì)究故障的不二法門,一次長時間的故障,往往有很多細(xì)節(jié)可以推敲,我們總結(jié)出運(yùn)維345法則。3是指故障時長被分成三部分,4是指對應(yīng)的四個故障時刻點,5是指在這個過程中我們可以做的五件事。這樣,我們就可以有的放矢地進(jìn)行優(yōu)化解決了。

  2)不要讓流程吞噬責(zé)任

流程規(guī)范是很好,不可或缺,好處誰都曉得。只是,流程有時會成為擋箭牌,會讓人變得本位,不愿擔(dān)當(dāng),也不愿從事個人職責(zé)之外的事情。

這其實是錯誤的、短視的,“害人害己”的。如果真的出了一個非常嚴(yán)重的故障,個人就能“出污泥而不染”么?沒戲。如果是頂級故障,老板想的甚至是把整個運(yùn)維部門端掉,皮之不存、毛將焉附?

● 良好的客戶界面

伸手不打笑臉人。合適的言語表達(dá),可以大事化小、小事化了,反之亦然。只是對做技術(shù)的運(yùn)維同學(xué)而言,這是很不容易的事情,甚至有人寧愿多加班,也不去和人溝通。但,工作的要求有時往往需要善于表達(dá),其實也可以換個角度想,把良好的溝通當(dāng)做一門技術(shù)來攻克,如何?

1)當(dāng)面溝通

即時聊天工具如QQ、微信實際上是加劇了溝通成本。大家變得更加依賴與此,本來當(dāng)面溝通或電話溝通,幾分鐘就能說明白的事情,來來去去幾十分鐘,更有甚者,還能吵起來,沒法愉快的玩耍了。根據(jù)國外一項調(diào)查,一次有效溝通中,詞句內(nèi)容僅占據(jù)一小部分。

我們一般都會要求素未謀面的小伙伴,先當(dāng)面聊一下。舉個真實的例子,有位同學(xué)之前和某位運(yùn)營同學(xué)一直QQ、郵件溝通,某次實在說不清楚,于是面聊,發(fā)現(xiàn)對方居然是個美女,于是之后合作很愉快(雖然美中不足的是,該女士已有男友)。

2)來的都是客

做運(yùn)維的,應(yīng)該放下身段,不一定非得低三下氣地做事情,但至少意識得到位。運(yùn)維的溝通中,也適應(yīng)心理學(xué)的投射原理:越是覺得別人盛氣凌人、服務(wù)不到位,其實自己也往往是這樣的。

來的都是客。如果自己實在忙不開,響應(yīng)慢。禮貌用語總是可以的嘛,不好意思,對不起,抱歉,謝謝。

4. 小結(jié)

絮絮叨叨說了這多,也不知大家看煩木有。運(yùn)維很苦悶,讓苦悶的人變得更苦悶。但不管怎樣,也是一門技術(shù)。這年頭,有門手藝,雖然發(fā)達(dá)需良機(jī),但至少生存無憂。話說回來,哪行都不容易。

本人做運(yùn)維這么些年,結(jié)合各種失敗與成功、痛苦與苦痛的經(jīng)驗,終于悟出高效運(yùn)維的七字訣:專業(yè)、熱情、方便、快。不一定完全適合您,但終歸是多年的領(lǐng)悟,自成一個小體系,如各位盆友喜歡,以后逐一闡述,如能對大家有所裨益,幸莫大焉。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號