注：本文來源於網路，版權歸原作者所有，用於知識分享，不任何商業用途。

前言

做運維的那麼多，快樂的能有幾個？

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

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

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

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

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

本文略長，主要目錄結構如下：

1. 什麼是高效運維

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

2.1 糟糕的分工及連環反應

2.2 做vs說的困境

2.3 資源錯配

3. 如何做到高效運維

3.1 明確分工/職責

3.2 技術的專業化

3.3

3.4 良好的客戶介面

4. 小結

好吧，我們正式開始。

1. 什麼是高效運維

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

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

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

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

合理的流程規範，就像血液，能讓部門穩定而高效的運轉，大家都覺得開心，這也是專業與否的重要組成部分。但如果希望做到高效運維，良好的客戶介面、合適的方法技巧，也非常有必要。這就像網站的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）介面，即良好的服務意識/技巧。這些投入足夠多，才會得到心儀的產出——高效運維。

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

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

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

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系統執行情況，還能進行資料遷移、主備切換等操作。

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

3.2.5 程式碼持續部署

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

Docker 高可用叢集，加上Jenkins釋出，可以把這些需求變成現實。Centos7的systemd用來底層支援Docker高可用，etcd實現了配置檔案的集中儲存，而不是分散在各臺伺服器的本地。fleet作為etcd和systemd之間的橋樑，並通過systemd來控制叢集伺服器。

Jenkins從svn伺服器獲取到新程式碼版本後，通過shell指令碼，打包成image，放入Docker私有庫，從而被Docker叢集伺服器update並使用。

3.3 管理的專業化

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

3.3.1 運維345法則

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

3.3.2 不要讓流程吞噬責任

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

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

3.4 良好的客戶介面

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

3.4.1 當面溝通

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

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

3.4.2 來的都是客

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

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

4. 小結

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

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