> 原文出處：http://www.infoq.com/cn/articles/effective-ops-part-02 > 作者：蕭田國 ## 前言 本專欄的第一篇文章獲得諸多同行贊許，也被多位技術大佬轉發、點贊，確屬始料未及。興奮之余，誠惶誠恐，思來想去，唯有繼續碼字，方能聊表謝意。也預祝大家在羊年里幸福快樂，心情愉悅。 春節剛過，廣大運維朋友又面臨著新的工作壓力。讓大家苦惱的是，我能力這么好，為什么不幸福？怎么能讓工作不那么累心，怎么能多些成就感？甚至，還有機會幸福嗎？ 通常，幸福感很大程度來自于外部的認同（以及基于此的自我認同），例如外部門、領導或同事的贊賞。應該只有極少數的人，能在不被外部認同的情況下，還能自我陶醉（那該是何等強大的內心啊）。 導致技術人員不幸福的原因不勝枚舉，本文主要針對個人自我管理上容易出現的四大問題，分析其根源，并試圖給出些許改進建議。因篇幅有限，至于技術、流程規范等方面的問題，以后單開專題深入分析。 PS： 文末有彩蛋哦（但…不建議直接翻頁到最后，謝謝！） 本文略長，主要目錄結構如下： [TOC=3] 好吧，我們開始。 ## 1\. 過于追求技術進步及改進建議 技術人員有時會過于追求個人技術進步，有意無意的混淆個人成長和公司要求之間的差別。這樣的結果，往往會降低客戶滿意度，即需求方對我們工作的不認同。這種不認同，又會以各種形式表現出來，并反作用到我們自己身上。 例如，新來一個業務需求，經分析，嗯，有兩種方案：1）采用新技術，大概1周完成。可用上自己關注了很久的某新開源軟件，看上去一舉兩得：個人技術有機會進步了，而且是服務于公司的項目；2）采用老套路，3天完成。但沒啥技術含量，一堆shell腳本拼湊，對個人而言是重復勞動，而且實現起來很不優雅。 我們會選擇哪個方案？實際中往往采用新技術的居多。技術人員（特別是技術能力強的同學），難免對個人能力有所自負，潛意識認為，自己很棒，任何問題基本上都能解決。于是自信滿滿地和需求部門拍胸脯，然后結果就是……（你懂的，又延期了唄。） 新技術可能導致時間不可控，開源產品可能bug不斷，中途遇到問題就麻煩了：社區不完善（發帖半天沒人回），網上搜索不到管用的解決方案。反之，老套路時間可控，甚至閉著眼睛都能交活。有差不多現成的腳本，東改改西改改，出了問題也好解決，如果業務實在催得緊，多買幾灌某牛加加班，保證按期交付。 其實，需求部門根本不在乎我們用什么技術來實現（而且他們也沒必要在乎）。對他們而言，運維是個黑盒子，他們知道的輸出結果只有兩種：搞定了，沒搞定。需求部門最無奈的是，技術人員沒搞定，然后拿一堆聽不懂的技術分析反復解說，而且自己還得在旁邊賠笑臉、假裝略懂。 正確的作法是怎樣？ 首先，主觀上，需要遏制自己的那股技術沖動；其次，提前預估到各種風險，覺得難度有些大，就選用老辦法。先按時交付業務需求，然后可以利用空閑時間，搞搞新技術的實現。 這樣一來，皆大歡喜。雖然沒業務壓力的情況下，新技術的完成時間會延長很多。但不管怎樣，這時，事情的性質轉變了——由公司需求變成了個人問題。 ## 2\. 分不清輕重緩急及改進建議 運維人員其實有相當多的時間，都在用于處理日常業務需求。或者說，一天到晚都在處理故障的情況，并不多見。所以，同比例的，外界對我們的認可程度，較大程度上取決于我們日常工作的交付能力。 分不清輕重緩急是個普遍存在的問題，例如：1）新員工，剛參加工作幾年，每個業務人員都說自己的需求重要緊急，可時間就那么多，又想好好表現，于是手忙腳亂；2）老員工，多個需求、問題一涌而來，這時也難免手忙腳亂。 僅僅手忙腳亂還好說，如果因此導致人為事故，業務中斷，系統不穩定，大客戶流失，重要內部客戶不滿意，影響公司決策支持，那么就更加麻煩了，而且會嚴重損害自己的自信心和信譽值。 那么，如何避免此類事情發生呢？可以從以下幾個方面改進。 ### 2.1 給事情正確地分類 當手頭要處理的工作超過5個，就需要分類了。按照時間緊迫性和重要程度的不同，可分為緊急、不緊急，重要、不重要。手頭的各種工作，可以自己搞個白板，按四個象限，分顏色貼上便利貼。  這個圖相信不少人都了解過。現在大家可以閉目幾分鐘，回憶下，想想過去的一周，自己完成的事情，都可以放入哪幾個象限，相信結果定會讓你大吃一驚。 往往不重要、緊急的事情，占用了我們大量的時間，每個業務人員，都看上去火急火燎，甚至愿意站在辦公位旁等結果。另外，不重要、不緊急的事情，有時也會占用我們大量時間。 那么，問題來了，我們允許大量時間被自己低效地消耗掉，對自己有什么好處？好處是：逃避現實（有時也用于逃避重要不緊急事情），尋求一個心理安慰——你看，我也好忙的（備注：這些文字可能會刺痛某些同學，但這類情況還比較普遍，權當共勉！）。 ### 2.2 要事第一的關鍵所在 要事第一的關鍵所在，是將更多時間和注意力，放在重要、不緊急的事情上，而不是重要、緊急的事情（這意味著我們能實現卓越、還是止步于優秀）。我們建議至少留出20%的時間，來做重要不緊急的事情。這符合2/8原則，而且，往往也能產生80%的效能。 這樣的好處是：可以減少重要緊急、不重要緊急的事情。例如，給某大型游戲導入用戶的banner廣告出現重大Bug，該廣告雖由投放系統動態生成，但需運維同學緊急更新相應CSS文件才能在線上環境生效，這屬于重要緊急范疇；正常情況下，這屬于舉手之勞的小操作，但運維人員在地鐵上，不能穩定連入服務器。多悲催？！如果之前持續投入時間，利用Jenkins等實現了Web更新，那就可放權給需求部門自己更新，運維人員甚至不用參與。 糾結之處在于，因為事情重要但不緊急，所以容易被一拖再拖。如果各種痛心疾首后，還是仍然經常忘記重要、不緊急的事情，怎么辦？收藏本文章，時不時的閱讀一下，如此甚好。 ### 2.3 做事原則、排序原則 各種原則很多，說多了大家也都容易忘掉，這里僅列舉3個簡潔實用的。 #### 2.3.1 一次只做一件事 技術工作的特性，決定了得有整段時間（一般至少15~30分鐘），才能沉下心來、分析解決問題，才有效率。一般來說，一次只做一件事。我們看下最高指導（新華網發布于2015年1月13日）。  有些時候，甚至可以戴上耳機，關掉QQ，忽略非重要郵件。不要把自己搞得有三頭六臂似的，貌似很忙，實則瞎忙。 #### 2.3.2 故障是第一位的 故障是最重要緊急的，也應該優先處理。這個貌似很簡單的事實，有時都會被忽略。這發生在： 1. 該類故障，并未明確規定第一責任人，大家相互扯皮； 2. 故障第一責任人，沉浸在其他問題的解決中； 3. 故障第一責任人，心急火燎地在想辦法，其他人主觀感覺和自己沒關系，沒主動跟進、群策群力去反向推動和解決。 例如公司官網無法訪問，這個情況可能是DNS有問題、Nginix掛掉了，PHP出問題了，MySQL出故障了，網絡堵塞了。各種情況都可能有，除非有智能監控，故障自愈系統，或者責任人有豐富的處理經驗，否則運維部門所有工種，都應該主動去排查自己負責的部分是否有異常，并協助相關同學分析解決。 #### 2.3.3 部門內部工作靠后 如果手頭有多個重要緊急的業務需求，應及時向上級請示，將部門內部工作排序靠后，先做部門外的業務需求。 部門內部工作，一般由運維負責人提出，如遷移Zabbix數據庫、PHP性能調優、新技術測試等。這類事情，實際上，交付日期是可協商的，往往并非重要緊急。 但也正因為是自己領導的需求，所以，往往被同學們分配更多的時間和更高的優先級，以博得領導贊賞——畢竟，給外部門做得再多，考核自己的，主要還是上級。 這是潛意識指導下的、一種合乎理性的行為，我們不能簡單的否定。所以，這方面需要運維負責人的配合：需要主動、周期性的告知部門同學這個觀點，并且鼓勵這種插隊行為（當然，前提是和上級溝通了）。 ### 2.4 怎么更好地接單？ 為了更好地接單，竊以為關鍵點是，對自己狠一點：接到業務需求時，需主動問詢時間節點要求。從經驗教訓來看，事前商量好，總比事后被人催要好（雖然會有些痛苦）。有些業務需求的回答往往是：越快越好（暈）。這時就得幫助他們設定一個時間節點，而且得具體，不能模糊——如下周或元旦后。一旦達成一致，就是一個契約。 如果完不成，請提前預警。客客氣氣地說幾句好話、打個電話，真誠道歉一把。最怕的情況是，設定的交付日期早過了，需求方來問進展，然后呆萌呆萌地說：我忘了，還沒開始做…… ### 2.5 勇于說不，合理拒絕 有辦法禮貌地拒絕某些需求嗎？還真有辦法。拒絕別人得有理有據、不卑不亢。例如，在工作量非常飽和的情況下，業務方（甚至自己領導）來加塞，說又有一個非常重要、緊急的需求，需要立刻、馬上開始，而且耗時還較長。這時怎么辦？ 這時可以拿出自己的工時分配表來。就說，您看，這是我最近兩周的工作安排，都有這些事情，都是給這些部門做的。如果您的事情確實需要我來完成，您可以和這些事情的需求方談一談，看是否能做個調配，或者我們也可以一起去找我的上級，看是否能做個乾坤小挪移，等等。 另外，重要緊急往往是對別人而言，要關注那種每個需求都號稱重要緊急、恨不得就給他一個人服務的同學。所以，對需求方，我們也可以甄別下，區別對待。 ## 3\. 不善表達及改進建議 不善表達更多是性格使然，關于這部分的原因分析及建議方法，在上一篇[“高效運維最佳實踐（01）：七字訣，不再憋屈的運維”](http://www.infoq.com/cn/articles/effective-ops-part-01)中已有重點表述，大家可以參閱一下。本文再次提及，只是因為這個問題，情況普遍、殺傷力大，而且容易改善，效果顯著。 喜歡鉆研技術，并能尋找到樂趣和認同感，這是運維人員的普遍情況。有些同學和別人討論技術問題，也能頭頭是道，在QQ/微信上也話多、幽默。只是一遇到當面交流，就分分鐘變成了“沉默的羔羊”。 如果需求方也是個不善表達的同學，相互多少有些“宿怨”，在日常溝通中再夾雜著情緒，那可能就更加不好。有例為證。  這種情況并非少見，是求虐、求投訴么？多說幾個字，用些客氣的字句、來些語氣助詞，真的那么難？必須得惜字如金么？又不是從身上割肉，不用舍不得…… 改善客戶界面，首先從意識層面反省，是否存在客戶界面不友好的問題。解決方法包括，盡量當面溝通，真誠道歉。 ## 4\. 愛抱怨及改進建議 我們是公司的一份子，小公司問題很多，大公司更有各種通病。在一家公司呆個一年半載后，往往發現不如當初期望的那么美好，心情不暢，再加上還得面對生活的各種壓力，難免各種壞情緒紛至沓來。 其中，抱怨是我們最常見的情緒之一，甚至是一種背景式的存在。觀察下我們腦海里不時冒出的自言自語，十有八九是抱怨。牢騷太多防斷腸，抱怨可能會集結成怨恨、甚至怨氣，嚴重損害自己身體。 ### 4.1 抱怨及其本質 抱怨隱含的意思是：我是對的，并將自己放在一個幻想中的道德優越感上。抱怨是一種低調的攻擊，常被用于自我保護，捍衛自我。抱怨的，都是過去的事情，會白白的消耗自己的能量。（話語可能有些刺耳，請大家盡量看完下面的文字。） 建議輕度抱怨，勿沉迷，別走心。如果把抱怨當做朋友間的一個話題，也無傷大雅，當然，希望在這些時候，你知道自己是在抱怨（觀察到抱怨的過程，很有意義，但也很難，不信你試試）。 事情不會因為我們抱怨，就變少。反而因我們抱怨，可能變得更加繁雜。 抱怨越多的人，往往是被抱怨越多的。其結果往往是，消極被動。所以好消息是，積極主動，專治抱怨。 另外，我正在策劃一個情緒管理的專題“我的戰爭”，里面有對抱怨、焦慮、恐懼等常見情緒的更多剖析，敬請期待。 ### 4.2 積極主動的真正含義 美國管理學大師史蒂芬·柯維在資深暢銷書《高效能人士的七個習慣》中，給積極主動下的定義很有意思：當我們的行為，將影響圈擴大（借此蠶食關注圈——蕭田國注），則被稱為積極主動，否則就是消極被動。 所謂影響圈，就是那些我們能掌控（直接控制）的事情；而只能間接控制、或無法掌控的事情，都屬于關注圈。  那么，我們能掌控的事情，都有哪些？思來想去，其實也就是自己的行為。如果我們管理著一個團隊，可以指揮同學們做這個、做那個，這屬于間接控制的事情。天氣，則屬于無法控制。 我們往往將注意力放在關注圈，這是導致抱怨、并且被抱怨的重要原因。 舉個例子，業務推廣因為網站不堪重負而失敗，老板開罵。這時： > 網站運營說，我早就告訴運維負責網站的哥們了，他就是不給我好好搞； > > 網站運維說，我早就告訴系統組的同事了，他就是不及時給機器； > > 系統運維說，我早就告訴采購部門了，他們一直沒給我機器； > > 采購部門說，我早就告訴供應商了，他們說缺1TB的硬盤，沒法發貨。 大家都對，但也都不對。例如，對網站運維而言，沒法把控系統運維的服務器交付日期，但自己能做的事情，真的到此為止了么？這個情況，你是否及時向自己的上級和業務部門匯報？是否真的沒辦法，從自己負責的業務中，臨時調撥下？ 對系統運維而言，是否真的不能從別的業務借用幾臺服務器先扛著？對采購部門而言，是否真的不能從服務器供應商借幾臺服務器先用著？ > 【問】我周遭的環境這么糟糕，我都苦不堪言了，你還讓我積極主動，你不是在往我傷口上撒鹽嗎？ > > 【答】真的抱歉啊，朋友們。大家都是苦水里泡大的，個中滋味，我感同身受。只是，除了改變自己，我們真的不能再做什么了啊。權當良藥苦口了唄？一起共勉之。 ### 4.3 通力合作 如果出現重大故障，不要先假設自己負責的部分（如數據庫）是沒問題的，并帶著主觀傾向去分析問題，這樣在言語表達上可能讓人反感，而且也往往不正確。  另外，也不要覺得自己負責的這部分沒問題，于是對發生的重大故障，就再也不管不問、隔岸觀火。應該主動和大家一起分析討論，群策群力，解決問題。如果下次你負責的這部分出現了嚴重故障，其他人都漠然坐上觀，你是否也會寒心？ 還是那句話，大家是一條線上的蚱蜢。重大故障出現了、長時間未解決，公司和外部門會說，你運維部不行、不專業。這時候，即使能獨善其身，又有什么用？ ## 彩蛋 實在搞不懂輕重緩急，怎么辦？這個好辦，問上級唄，千萬別自己憋著。領導是干什么的？不就是幫屬下分憂解難的么，呵呵。甚至，偷偷地說，如果有個需求，實在完成不了了，也不要老是自己去和外部門解釋，可以請領導出面。自己領導和需求方領導聊一聊，可能大事變小事哦。 下一篇文章，我們談技術，主題暫定“高效運維最佳實踐（03）：Redis集群技術及Codis實戰”，敬請期待。