apache 微软 wordpress Windows java 程序员 云计算 mysql centos Python Ubuntu shell php Android linux google Firefox 编程 nginx 开源

高效運維七字訣,不再憋屈的運維

這篇是《中生代》轉載的一個關於運維的文章。作者是觸控科技運維總監蕭田國。文章在運維圈子流傳甚廣。特別也發在社區,分享給感興趣的朋友。

前言

做運維的那麽多,快樂的能有幾個?

我們那麽努力,為什麽總感覺過得那麽憋屈、苦悶?做的事情那麽多,為什麽業務部門、直接領導和公司貌似都那麽不領情?怎麽做才能自己更加開心些?

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

技術專欄就非得那麽中規中矩麽?咱這個專欄試圖以更輕松活潑的文字,徐徐道來,就當是個老朋友,輕松愉快中,希望能給大家帶來收獲和啟發。

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

補充一句:本文實際上既是本專欄的開篇,也是綜述。後續專欄文章,會就各個部分,進行詳細闡述,敬請期待 。

本文略長,主要目錄結構如下:

1. 什麽是高效運維

2. 為什麽難以做到高效運維

2.1 糟糕的分工及連環反應
2.2 做vs說的困境
2.3 資源錯配
3. 如何做到高效運維

3.1 明確分工/職責
3.2 技術的專業化
3.3 管理的專業化
3.4 良好的客戶界面
4. 小結

好吧,我們正式開始。

1. 什麽是高效運維

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


ca09952e2aacb65d4e6be19831ef132b017cc934

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

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

45267a78f19dc9dc19fa2e0397e82cec822a8bfa

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

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


 2. 為什麽難以做到高效運維


做不到高效運維,公司和業務部門不滿意,上級領導不滿意,自己也不滿意。原因很多,我們從管理者和員工角度分別來講。

2.1 糟糕的分工及連環反應

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

公司業務擴大很多後,如果運維組織結構不隨之而變,分工不明確,就會發現大家都在疲於奔命,什麽都會的結果就是什麽都不精。在運維技術如此龐雜的今天,就是把人活活的架在火上烤。這樣引發的是多米諾骨牌效應:分工不明確 —> 職責不清楚 —> 考核不量化—> 流程不合理—> 缺規範 、少文檔。


2.2 做VS說的困境


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

另外,從人腦結構來看,做和說兩難全,也是合理的。控制計算、推理能力的是左腦,而表現力等由右腦控制。如果強行要求會做還會說,說不定會導致紊亂、崩潰甚至“腦裂”呢,呵呵(當然,這個問題也是有解決方法的)。

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


2.3 資源錯配


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

管理者如果把錯誤的人安排在錯誤的崗位,那麽註定是個錯誤。例如,某位同學喜歡鉆研技術,不喜表達,非得讓他作為和外部門的接口人,那自然費力不討好,大家都不開心。

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

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

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

3)沈迷單個業務模塊。這是另一個特例。一般發生在內部提拔時。例如某位同學,之前是DBA組的負責人,提拔為運維部經理後,還是習慣於抓其擅長的數據庫工作,這也是不應該的,否則就沒必要提拔了嘛。

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


3. 如何做到高效運維


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


3.1 明確分工/職責


美國著名管理學者史蒂芬·柯維在暢銷書《高效能人士的七個習慣》中提出了產出/產能平衡原則。想多產出,先得擴大產能。想金雞多下蛋,就不能殺雞取卵。那麽對於高效運維而言,產能是什麽呢?

包括三部分:

1)框架,即合理的分工/職責/KPI,抱歉我提到了KPI,多麽讓人如此愛恨交織的詞語;

2)血液,即專業的流程/規範;

3)界面,即良好的服務意識/技巧。這些投入足夠多,才會得到心儀的產出——高效運維。

在貫徹實施這些一段時間後,外部門會詫異的感覺:喲,怎麽運維變化這麽大。雖然他們不知道原因,但我們可以微微一笑,呵呵。

13baa73473c89c844eefa3eafadb24e441ab7183

具體到運維部門而言,我們的分工,區別於內網IT部。一個是服務外部客戶,一個是服務內部客戶,差別還是蠻大的。根據部門分工,拆解出各個小組的分工,再落實到每個員工頭上。有章法,大家也覺得舒心。

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

8c7bc6a7750b61fe73d63f404b883592ba26e3bf

3.2 技術的專業化

技術上的專業化運維,涉及面也很廣,下面僅列舉幾例。

3.2.1 優化監控系統

誰來監控監控系統?怎麽保證比業務部門先發現問題?是否需要添加業務監控?URL監控是否返回狀態碼200即萬事大吉?是否需要文件監控?短信報警、郵件報警是否足夠?是否需要自動語音報警及垂直升級功能?

監控是門學問,是專業運維的入口。展開說可以很大篇幅,先拋磚引玉,提出這些問題。實際上,對於資深、聰明的運維同學,看到問題,就已經有了自己的答案。

3.2.2 減少人為事故

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

3.2.3 運維自動化

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

3.2.4 合理優化架構

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

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

a485acc057e2158f0c1043df4c711e6d4b4241e2

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

3.2.5 代碼持續部署

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

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

Jenkins從svn服務器獲取到新代碼版本後,通過Shell腳本,打包成image,放入Docker私有庫,從而被Docker集群服務器update並使用。


421936898cdc8479cc5c45ce2235c38b12dd0dc5

3.3 管理的專業化

管理上的專業化運維,甚至包括調試通報和故障通報,都很有說法。系統運行一段時間後趨於穩定,調試/更新就變成了故障的主要來源之一,怎麽讓調試少出人為事故,順利如期的完成?這是個技術活。

3.3.1 運維345法則

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

532e6f748a479047d9b6ca112980a0157b249bdb

3.3.2 不要讓流程吞噬責任

流程規範是很好,不可或缺,好處誰都曉得。只是,流程有時會成為擋箭牌,會讓人變得本位,不願擔當,也不願從事個人職責之外的事情。

ce13483a9927fa5135281993f31045553b113a1b

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

3.4 良好的客戶界面

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

3.4.1 當面溝通

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

24c10f073f6c5f1ffa001dbb1766a3ed427221ed

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

3.4.2 來的都是客


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

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

 4. 小結

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

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

延伸阅读

    评论