高效運維最佳實踐七字訣，再也不憋屈的運維!

咱們那麼努力，爲何總感受過得那麼憋屈、苦悶?作的事情那麼多，爲何業務部門、直接領導和公司貌似都那麼不領情?怎麼作才能本身更加開心些?

作運維的那麼多，快樂的能有幾個?

咱們那麼努力，爲何總感受過得那麼憋屈、苦悶?作的事情那麼多，爲何業務部門、直接領導和公司貌似都那麼不領情?怎麼作才能本身更加開心些?

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

技術專欄就非得那麼中規中矩麼?咱這個專欄試圖以更輕鬆活潑的文字，徐徐道來，就當是個老朋友，輕鬆愉快中，但願能給你們帶來收穫和啓發。

前段時間有位IT大佬在網絡上發聲，我這麼有錢，爲何不幸福?誠然，有錢是幸福的最重要條件之一，但有錢就必定幸福麼?真的是充分必要條件?固然更悲催的是運維行當，技術好是被承認(幸福)的最重要條件，但技術再好，外部門不說我們「壞話」，已是很不錯的了。

1. 什麼是高效運維

咱們收集了一些來自外部門對運維的印(tou)象(su)，以下圖所示。其中，你們看是否也多少有本身的影子?

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

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

實際上，對外部門而言，運維是個黑盒子，是一個輸入輸出的關係：外部門提出需求，運維給出結果：完成、或未完成。本質上而言，外部門不關心(也沒法關心)咱們採用什麼技術來實現的，只關心是否如期完成。

合理的流程規範，就像血液，能讓部門穩定而高效的運轉，你們都以爲開心，這也是專業與否的重要組成部分。但若是但願作到高效運維，良好的客戶界面、合適的方法技巧，也很是有必要。這就像網站的UI，給人感受舒服了，後面不少事情也能輕鬆愉快、瓜熟蒂落地進行。

2. 爲何難以作到高效運維

作不到高效運維，公司和業務部門不滿意，上級領導不滿意，本身也不滿意。緣由不少，咱們從管理者和員工角度分別來說。

● 糟糕的分工及連環反應

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

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

● 作vs說的困境

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

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

更嚴重的是，不少同窗沒意識到本身的溝通表達是有問題的，說句話能把人嗆死，也不知道如何有效表達。這樣就談不上熱情了。

● 資源錯配

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

管理者若是把錯誤的人安排在錯誤的崗位，那麼註定是個錯誤。例如，某位同窗喜歡鑽研技術，不喜表達，非得讓他做爲和外部門的接口人，那天然費力不討好，你們都不開心。

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

1)沉迷解決技術問題。這通常發生在剛從技術崗位提拔爲管理者的時候，忘記本身是管理者了。解決複雜技術問題，能帶來愉悅感，不然就是挫折感。因而遇到技術問題時，非得死磕到底，而後一週過去了，而部門其餘同窗卻放羊一週。

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

3)沉迷單個業務模塊。這是另外一個特例。通常發生在內部提拔時。例如某位同窗，以前是DBA組的負責人，提拔爲運維部經理後，仍是習慣於抓其擅長的數據庫工做，這也是不該該的，不然就不必提拔了嘛。

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

3. 如何作到高效運維

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

● 明確分工/職責

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

包括三部分：1)框架，即合理的分工/職責/KPI，抱歉我提到了KPI，多麼讓人如此愛恨交織的詞語;2)血液，即專業的流程/規範;3)界面，即良好的服務意識/技巧。這些投入足夠多，纔會獲得心儀的產出——高效運維。在貫徹實施這些一段時間後，外部門會詫異的感受：喲，怎麼運維變化這麼大。雖然他們不知道緣由，但咱們能夠微微一笑，呵呵。

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

運維是支持部門，成本中心，難以產生利潤。因此其中重要的考覈指標實際上是客戶滿意度，請相關業務部門給運維同窗打分，運維內部根據分工，也能夠相互打分，這對應着外部滿意度和內部滿意度。KPI雖然使人不舒服，但總的來講，仍是有存在的合理性。

● 技術的專業化

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

1）優化監控系統

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

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

2）減小人爲事故

人爲事故是運維最頭疼、最不專業的事情之一。例如網站運維中，若是每次更新都須要登陸服務器，svn update/git pull，不免會出差錯。因此能夠用相似Jenkins的工具，實現Web更新，這樣，除非重大更新(包括數據庫更新)，不然都只須要點點鼠標便可。甚至，能夠把網站更新外包回開發部門，這樣還能減小運維操做帶來的溝通成本、時間成本。

3）運維自動化

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

4）合理優化架構

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

Codis就是其一，Codis由豌豆莢開源，並普遍用於其自身的業務系統。Codis恰好擊中Twemproxy兩大痛點(沒法sharding，運維不友好)。Codis能夠平滑的擴容/縮容，隨時增減Redis服務器;並提供友好的運維界面，不只能看到Codis系統運行狀況，還能進行數據遷移、主備切換等操做。

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

5）代碼持續部署

線上系統程序代碼能否自動打包、持續部署? 測試環境的新版本發佈能否由開發人員本身來作，甚至本身來作測試? 這些無疑能夠很大提高運維和開發效率。

Docker高可用集羣，加上Jenkins發佈，能夠把這些需求變成現實。Centos 7的systemd用來底層支持Docker高可用，etcd實現了配置文件的集中存儲，而不是分散在各臺服務器的本地。fleet做爲etcd和systemd之間的橋樑，並經過systemd來控制集羣服務器。

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

● 管理的專業化

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

1）運維345法則

故障通報是細究故障的不二法門，一次長時間的故障，每每有不少細節能夠推敲，咱們總結出運維345法則。3是指故障時長被分紅三部分，4是指對應的四個故障時刻點，5是指在這個過程當中咱們能夠作的五件事。這樣，咱們就能夠有的放矢地進行優化解決了。

2）不要讓流程吞噬責任

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

這實際上是錯誤的、短視的，「害人害己」的。若是真的出了一個很是嚴重的故障，我的就能「出污泥而不染」麼?沒戲。若是是頂級故障，老闆想的甚至是把整個運維部門端掉，皮之不存、毛將焉附?

● 良好的客戶界面

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

1）當面溝通

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

咱們通常都會要求素未謀面的小夥伴，先當面聊一下。舉個真實的例子，有位同窗以前和某位運營同窗一直QQ、郵件溝通，某次實在說不清楚，因而面聊，發現對方竟然是個美女，因而以後合做很愉快(雖然美中不足的是，該女士已有男朋友)。

2）來的都是客

作運維的，應該放下身段，不必定非得低三下氣地作事情，但至少意識獲得位。運維的溝通中，也適應心理學的投射原理：越是以爲別人盛氣凌人、服務不到位，其實本身也每每是這樣的。

來的都是客。若是本身實在忙不開，響應慢。禮貌用語老是能夠的嘛，很差意思，對不起，抱歉，謝謝。

4. 小結

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

本人作運維這麼些年，結合各類失敗與成功、痛苦與苦痛的經驗，終於悟出高效運維的七字訣：專業、熱情、方便、快。不必定徹底適合您，但終歸是多年的領悟，自成一個小體系，如各位盆友喜歡，之後逐一闡述，如能對你們有所裨益，幸莫大焉。