最近跟朋友聊起工作，我說幹運維的，他略顯詫異的說這行業感覺有點low啊，好多專科技校、藍翔電腦培訓出來的孩子都搞這個。嗯，這朋友倒是蠻心直口快的，只好無奈一笑，不以為意。後來一想，這也許就是當前運維從業人員面臨的一個尷尬境地，給人的職業形象就是呆板和猥瑣，要麼是目光呆滯地蹲機房拆機器，要麼是焦頭爛額的處理各類業務故障，價值點不易被外界看到和認同。

當今的網際網路行業發展可謂風生水起，從傳統的ICP純內容生產到移動互聯O2O連線線上與線下，再到成為國家發展戰略的網際網路+深度擁抱各行各業，整個網際網路浪潮下催生出來的眾多業務形態、無數產品和創新的技術都在影響和改變著這個世界。而支撐起這整個網際網路基礎系統穩定運轉的人是誰？如當前一款遊戲產品PCU達百萬，一個web站點pv量上千萬，一個app的月活躍帳戶達數億，這些業務繁榮昌盛的背後有哪些工作要做？我掐指一算，大概涉及到資料中心、網路、伺服器等基礎架構的規劃、建設、運營及服務管理，涉及業務架構評估、部署方案優化、執行環境設計、容量與成本管理、可用性與連續性管理、故障恢復與維護等諸多方面，以上工作都需要運維這個特殊的職業群體來承擔。

運維作為業務發展的後腰團隊，一直致力於如何更快更好更省地支撐線上業務，既然是做業務支撐，得隨著業務的發展而發展，運維整體水平也往往與業務發展狀況和體量正相關，如國內BAT這些巨頭網際網路企業，其運維在標準化建設、規範化實施、資源規劃和運維效率質量等方面均已成體系，並基本能代表業界最NB水平。在一些中型網際網路企業，運維團隊和支撐體系可能正處於建設和發展階段，業務發展穩中有進，此時運維側關注的是如何提升效率、保障質量並控制成本以及自動化建設，當然最關鍵的是運維管理思路的轉變，工作介面切分、業務解耦、降低人員依賴度等等。在小微網際網路企業內部可能問題並沒有這麼複雜，甚至DO都不需要分離。但本人認為無論在哪種業務場景下，在如今網際網路行業如何猖獗、使用者如此海量的背景下，運維的價值需要輸出到產業鏈的上游中去，創造更多的空間。

那麼問題來了，運維往往是企業內部的屌絲團隊(不掙錢花錢又最多，起的比雞早睡的比雞晚，甚至顏值普遍偏低)，如何輸出更多價值，以本人有限的經驗來看，得練內功，即通過提升運維整體水平來輸出更多價值，簡單歸結為以下三方面

Chapter 1  運維支撐架構的進化

面對業務全面發展，使用者量膨脹，線上服務不斷增多，從運維整體支撐架構上，該如何轉變思路並擴充套件支撐能力?本人以為下述幾點措施可重點考慮。

1.   介面切分

這塊主要考慮的是運維人員組織結構的問題，當前的網際網路運維涉及的專業技術學科非常廣泛，從大的方向來講有兩類，一是基礎架構運維：這其中包括了IDC、網路、伺服器以及這幾塊縱向切分為規劃、建設、運營和ITSM。

這一類總結起來至少是三橫四縱，十二個專業領域，當然如果是再深度細分，如IDC這一塊又涉及基建、電力能源、製冷、暖通等等更多技術領域，總之這一大類不少於少林七十二絕技。第二類是業務運維，這一塊是貼近業務側，涉及的內容如下

業務運維人員接觸的是OS之上的各種應用系統，需要運維人員快速理解業務邏輯架構、前後端部署架構並深入業務邏輯細節，偏向於開發層面，涉及到的基礎IT技能包括：系統架構與原理、TCP/IP協議棧、dns/dhcp等各種網路服務、lvs/apache/redis/zeromq等各種開源元件、puppet/fabric/ansible/salt等各種管理工具、資料庫、指令碼程式設計、HA高可用、硬軟體效能評估等等太極108式。

世間可有萬中無一的奇才既精通少林72絕技又習得武當太極108式？曾經我想說我就是這種人，結果被一巴掌拍倒在地。但事實證明是有的，不是某個人而是團隊。如此多的細分工作需要分配到組織架構的各個團隊中去。當業務不多，體量較小的時候可能幾個人就可以搞定，一人多職縱向支撐也不會有太大問題，但業務劇增，體量巨大時，對基礎架構容量與健壯性、資源交付效率、維護與實施的質量等各方面都有著更高的要求，具體體現在專業深度和中長期規劃能力上。此時可梳理當前運維工作涉及的所有塊面按專業進行橫向切分，定義各團隊的工作介面，以高效的方式橫向支撐公司各業務。典型的組織方式：首先整體上切分為基礎架構團隊和業務運維團隊，基礎架構團隊負責資源的規劃與提供、硬體環境的管理維護工作，最終向上交付的是可用的OS。業務運維團隊負責OS之上的業務相關應用執行環境的設計、應用部署結構的優化和實施、線上應用的管理與維護等。

介面清晰職責明確是可執行落地的前提，不要出現應用維護人員還需要去裝機器、配置網路路由器、做儲存分割槽，搞機房的同事還需要去管理應用程序狀態、部署配置業務應用等情況。基礎架構團隊再細分下去典型的又可分為IDC團隊、網路團隊、SA團隊、監控與安全等，根據實際情況而定了；業務運維團隊內部可按業務型別或上游研發團隊來細分，具體可視人員規模業務體量技術型別等情況去定了。總之運維工作介面的切分目的是為合理組織人員，優化分配工作，明確職能和提升專業深度，粒度和維度視企業環境可靈活配置。

2.   流程整合

流程化是為了保證工作的質量。定義工作介面後，各職能團隊完成的是某個節點，團隊通過內部流程來實施作業任務，團隊間通過外部流程有序串聯，完成某個具體業務邏輯的工作。對於流程的整合本人認為做到內部閉環和外部閉環是關鍵，內部閉環指某個職能團隊內部在實施具體任務過程中的閉環，如IDC團隊在伺服器資源供應中整個流程鏈條一般是：

單伺服器採購這一塊涉及到的東西又很多，供應商管理、資源評估與規劃、成本管理等。生產這一塊可理解為把金屬物體變成對業務可用的OS資源，伺服器從出廠到上架到灌OS再到軟環境的標準初始化等等，這一塊在海量業務需求下對產能、資源供應效率的要求很高，傳統的手動安裝方式當然滿足不了，於是IDC的同學要考慮批量快速生產的方案如kickstart，本人接觸最高產能的部署系統是每小時部署5000臺物理伺服器OS，當然隨著虛擬化雲技術的應用，徹底改變了傳統的基礎架構資源生產和配置方式。調配這一塊也是需要IDC同學去考慮的重點，如何管理業務需求，如何分配伺服器資源，如何管理資訊，伺服器資源的排程等，站在更高的層面來說這一塊就是如何靈活排程資源來滿足業務需求，且能合理利用與控制成本，以下措施可以一試：

    維護這塊是基本工作，其中涉及的處理流程、技術細節與硬體裝置本身關係很大，本人接觸到的dell/hp/ibm/Lenovo/華賽等各廠商的在用主流型號伺服器達100多款，日常維護這塊的工作量很大，作為IDC的同學當然也要從思路、平臺等方面去優化，比如建立帶外網路集中維護和管理、基於日誌的自動分析和報障、事件與問題管理等等。資源回收與資源分配是同等重要的環節，宗旨是能做到有需求時放、無需求時收，這塊要考慮的是如何對資源利用狀態的監管，如何快速回收，彈性伸縮。以上只是大概說了伺服器資源管理這條鏈的內部閉環流程。實際上在職能團隊內部，類似的業務支撐流程很多很多。這些流程內部往往需要運維人員去考慮管理思路、實施技術、綜合解決方案等多方面。外部閉環體現在多團隊之間的工作協作上了，拿一個例子來說：某遊戲產品需求在國內搭建一個大區，這個就需要運維多個團隊來協作了，簡化的流程如下：

• 業務運維團隊進行環境的設計，依據網路覆蓋質量資料和使用者分佈資料，選址服務端該放到哪個地區、哪個運營商。依據效能測試資料和使用者量預估資料來確定需要多少機器資源和頻寬資源；資源需求提交給基礎架構團隊。
• IDC資源團隊根據提交的需求進行資源的匹配，或排程或採購或其他方式來保障資源的按時到位。
• SA團隊進行資源的生產，可能是利用工具平臺完成指定OS的部署，深度加工並配置，最後進行標準的初始化操作，交付給業務運維團隊。
• 業務運維團隊分發並部署應用，當然其中設計到的部署方案、實施技術、效能評估等每個環節均需要細緻考量。
• 監控團隊部署監控環境，完成對OS層面、業務層面各項指標的實時監控展現。
• 安全團隊需要規範OS層面、軟體應用層面的安全基線，並實時監測線上應用的安全狀況。

流程的整合，需要看每個企業內部運維的職能團隊、工作介面劃分以及承載的業務邏輯，尤其對於全業務運維的團隊，流程的制定很重要。一個好的流程，既要合理又要儘量簡單，較大的運維團隊要明確的一點是：保障一切正常運轉的是規範的流程，而不是個人。

3.   自動化實施

老話題了，對於業務量稍微上來、網路與伺服器規模稍大一些的企業，都已經意識到這點的重要性。運維不做自動化，生活不會幸福。關鍵是怎麼做，如何整體規劃並大方向佈局，見過很多運維自動化的實施方案，涉及運維工作中的各類場景。自動化實現方面大概有三個層次：

• 一是指令碼階段，依靠運維自行編寫shell、bat、perl等各種指令碼去完成自動任務執行，批量處理，功能封裝的好的話，用起來也挺省心省力。這種方式在管理規模較小的環境時沒太多問題，但對於成千上萬機器規模，或處理邏輯較複雜的情況時，顯得雞肋了。
• 二是依託ITIL理論建立起來的適應運維各種業務邏輯的自動化系統和工具，這也許是當前絕大多數網際網路企業採用的方式。整個基礎架構和業務運維這塊盤子，從IT管理的角度來做運維，並結合實際狀況尋找最佳實踐，如做資訊管理我們需要CMDB，CMDB主要用來管理線上線下資訊的對稱性和準確性，在此基礎上給其他各類業務系統提供一致的資料輸入；做事件管理我們需要事件管理系統；還有需求管理這塊，給內部和外部提供統一的需求入口；還可能有作業平臺，幫忙業務運維團隊自動化完成相關運維任務，此外安全、監控等等眾多的垂直型功能系統。這些自動化的系統確實能很好的幫忙運維去掉重複單調的工作、減輕日常工作負擔，並能量化工作和為優化質量指標提供資料支撐。但多數企業在實施這些自動化系統中，往往是缺什麼補什麼，整個自動化的實現分散在多個獨立的系統中，且可能沒有介面，資料不能互通，需要運維人員人工對接多個系統來完成某個運維場景的自動化實施。如一個釋出任務，可能需要先到需求系統開啟電子流，根據裡面的資訊去倉庫系統拉取版本，然後去分發系統分發版本，去監控系統遮蔽告警，然後去釋出系統做相應的操作等等。這類垂直功能的相互獨立的自動化系統確實能幫助運維人員解決很大一部分問題，在效率上有很大提升，使得運維的工作基本全部實現線上化。但這夠嗎？可以想象擁有百萬機器，數萬款線上應用的規模，這種方式還有待優化。
• 三是智慧化的整合平臺，這類運維自動化的平臺目前接觸到的只有騰訊藍鯨了，它是一個橫向的PAAS平臺，為遊戲運維領域提供了整套統一的解決方案，基於平臺，運維可以自由定製需要的工具，可按各種運維場景實現一鍵式作業，前端幾乎可適應任何業務，後端支援的自動化操作幾乎涵蓋所有，運維人員需要做的不是運維，而是任務設計。

自動化的建設水平在行業內差異化還是明顯的，如果處於運維自動化剛起步的階段，那麼本人的建議是：從整體上規劃，基於ESB思想盡量讓平臺與業務邏輯解耦。

如上所示，我們先拋開基礎架構側的自動化不論，對於業務運維而言，整個工作面無非就是對業務運營環境的各種操作、配置，已經對業務應用程式的管理，簡單來說就是OS層和應用層，要做自動化實施首先得有準確對稱的資料，然後需要一個統一的管控平臺，能併發的控制和操作遠端大量主機，這解決了OS層面的操作問題，但需要管理應用層面的東西及需要與應用的研發人員確認相應的介面，對於開源元件而言一般不會有什麼問題。因此如果是從零開始做自動化，個人認為CMDB、管控平臺、業務管理工具這三部分是地基。在此基礎之上，可以針對運維各類場景和業務邏輯去做相應的垂直功能系統，再上一層，可以使用流程引擎之類的元件來實現業務運維流程的縱向整合，最終實現運維場景化一鍵式作業。

運維自動化的宗旨是把運維人員的專業經驗和技術知識轉化為工具，讓工具去做事情，讓人去享受生活。

4.   標準交付

運維在工作切分和實施流程化之後，時常會出現溝通障礙、資訊不同步不對稱、權責劃分不清的情況，導致的結果可能是釀成各種悲劇慘劇、相互推諉、甚至多年兄弟基情破裂，本人認為這種情況的根源應該是團隊與團隊之間沒有交付標準，對應的流程的上下游沒有入口規範和出口規範，這沒什麼好說的，解放方案就是針對業務流程中各個節點制定好交付標準，這也是衡量團隊工作質量的重要指標。線上應用出了狀況，排除外界因素外，定是內部實施中某個環節沒有達標，標準可能是這樣的：

運維涉及的工作紛繁複雜，沒有交付標準很難確保萬無一失，各團隊、各流程節點均按標準交付，實際出狀況的概率會降到最低，且團隊之間的協助溝通也會順暢得多。

Chapter 2  運維團隊價值的提升

如前面所述，運維團隊往往處於整個業務發展的幕後環節，在價值體現方面也較難讓臺前的觀眾們看到，但運維團隊自我意識要清醒，在整個業務發展中貢獻的價值是不可或缺的，且要不斷提升自身價值，本人以為下述幾方面對運維團隊價值提升有很大幫忙。

1.   從操作到優化

從運維工作中的某個點來說，運維所做的工作最終都對映到某個操作上去，如對硬體裝置進行的操作、對OS環境進行的修改、對程式檔案的各種配置與更新、對資料的管理操作、對系統平臺的各種維護等等。這種工作特性往往會讓很多運維團隊陷入埋頭苦幹，重複勞動、思維僵化的境地，尤其是在管理風格較封閉的團隊裡，一切的流程和實施方案均已被定死，沒有全員參與感，下面的執行團隊根本不知道中心整體規劃是什麼，整體目標是什麼，也不會去為團隊整體的發展做考慮，只能機械的完成上級交待的操作任務。

記得看過一部叫《雪國列車》的科幻電影，在一列號稱永動機供能的高逼格列車上，某個小零件壞了且維修空間狹小，於是把一定尺寸的小孩抓過去當成沒有生命的金屬工具使用，小孩被訓練得僵化服從，並始終重複一個動作在一堆機械中完成某個特定的操作，從而維持整輛列車的繼續前行。看後不禁毛骨悚然，我們運維人員也該思考一下，當前你是否也處於這種狀態？當然運維操作是基本工作職責，但運維團隊該思考的是如何從這些操作任務中提取共性、去重、優化操作流程從而自動化去完成，大的平臺系統暫且不考慮，小的工作上的優化無處不在。

比如在伺服器資源初始化環節，業務運維針對提交過來的伺服器進行業務相關初始化配置工作，各團隊運維人員針對不同業務各自進行這項操作，繁瑣費時，還不一定保證質量，此時去梳理各業務初始化需求，發現絕大部分是共性的，將這些共性的東西提取出來，再隨便做個初始化工具，將工具整合在OS部署環境中，這樣OS生成出來後就自動完成各業務相關的初始化工作了，最終交付給業務團隊的是標準的統一的OS環境，大家都省時省力且質量還高。再舉一個例子，各業務需求CDN資源，且各自上傳到各自對應的site，線下的域名站點資訊、許可權目錄資訊等各業務團隊分別管理，在資訊溝通和管理上較費事，如做一個優化，將前端做成統一平臺，後端讓系統去自動完成差異化分發，再加上覆蓋率、下載率、頻寬等資料的統計分析等等則是較完善的一個CDN管理平臺了。類似的可優化方面太多太多，運維人員需要去思考如何優化，而不僅僅是完成操作任務，當發現一切細節都賞心悅目的時候，團隊的價值自然就提升了。

2.   從實施到規劃

規劃工作講究的是長遠計劃，早做打算未雨綢繆。在我們的運維工作中，業務需求是不斷變化的，滿足有計劃性的通用型的需求遠比滿足零散的個性化的需求要容易得多，運維規劃能力體現在以下兩個方面：

• 整體把握長遠打算：拿遊戲運維工作來說，最新的運營計劃時間節點是什麼，當前業務工作重點有哪些，問題和風險以及相應的解決方案是什麼，未來一個月、一個Q、甚至未來半年的工作重點是什麼，實施計劃是否已做好，要非常清楚自己該做什麼，而不要讓別人來提醒你該做什麼。
• 化零為整：業務側的需求經常給人的感受就是，突發性的、零零碎碎的、個性化的，有時運維人員白天盯16個小時都沒需求找你，到你睡覺的那幾個小時偏偏就有需求找來了，事情很小可能最終就只是上機器敲個命令而已，但業務說很急很急，這種情景相信每個運維都遇到過不少。那麼從運維角度如何去規劃這些零散的瑣碎的需求，完成的同時讓工作變得輕鬆。這個是需要與需求方協商一起來解決的，需求入口的規範性、SLA和達標率的明確制定、通過系統平臺自助實施的方案等等可以較好的解決此類問題，最後你會發現其實最終那些不可控的非常緊急的突發需求其實並沒有那麼多，計劃性的常規需求是佔絕大部分的。

這些導致你工作不爽的問題，運維自己不去考慮沒人會替你考慮，抱怨是沒有用的，要從多次實施的經驗中去總結併合理規劃你的工作。

3.   從粗放型到精細化

精細化這塊要做起來，得有度量手段和資料的採集，運維的工作實現線上化後資料的獲取是便捷的，在此基礎上再做容量、成本、業務可用性、工作量、工作質量、達標率等各項指標方面的分析也較為容易，依據這些資料來量化工作、優化流程和實施細節，精細化的關鍵是一切基於資料。有些運維團隊可能覺得我支撐的業務量不大，人員也不多，沒有精力去做精細化方面的工作，粗放型的模式實施下來也並沒有太大問題，如應用伺服器配置經常是根據運維經驗或類對其他應用直接拍板、系統承載能力和使用者量預估沒有實際資料支撐、應用部署結構沒有標準模型、運維工作評估沒法量化等等。個人理解，精細化的思路是恰到好處、精確匹配。

如在進行業務資源調配時，考慮業務邏輯模型和各模組效能資料，差異化的資源分配策略能做到恰到好處的資源利用，而不是一把抓使用同一規格的資源配置的粗放方式。

再比如對伺服器資源利用率的控制可以非常精細化，某業務部署了很多伺服器，我們從成本管理的角度去看，使用的這些伺服器資源與其業務量、使用者量匹配嗎？實際的負載達到多少了？有多少比例的機器是長期處於低功耗狀態？通過什怎樣的部署優化措施可以減少成本？但我們把這些資料監控起來後，經常發現這樣的情況：某業務共部署了1000臺機器，有50的機器長期處於低負載狀態(比如cpu峰值長期低於5%、記憶體峰值長期低於20%，io峰值長期低於10%等等)，但業務運維還在擴充套件機器資源，說效能達不到要求，為什麼？再深入分析發現30%用於接入模組的機器是高磁碟IO，低cpu配置，40%用於中間邏輯模組的機器是高cpu、低記憶體、高IO配置，30%用於儲存模組的機器是低磁碟IO、低記憶體、低cpu的配置，一句話部署結構未精細化、資源配置沒有資料支撐。當然你也可以粗放的每個模組全部配置高CPU、高記憶體、高IO的機器資源，也不會對業務執行有什麼影響，但這樣真的好嗎？

以上只是運維工作中的很小的可以精細化的例子，類似的非常多，從巨集觀角度看如運維人力的分配、時間的分配、各類標準模型、各種實施流程的完善等等都值得運維去深挖。

4.   從CASE-BY-CASE到統一解決方案

運維所支撐的上層應用是多種形態的個性化系統，如遊戲業務、web業務、音視訊業務、搜尋業務等等，邏輯架構、技術特徵、部署方案、執行環境需求等不盡相同。涉及的運維場景同樣是千變萬化、需求各異，如釋出、變更、遷移、合併、備份、故障處理等等各方面。在業務量少的情況下，通過case by case 方式運維可以很好的支撐起幾塊產品的維護工作，針對每款產品組建團隊搞一套流程並配備相應的工具即可，但隨著業務的發展，想象下幾百款到上千上萬款線上產品同時運作的情形，case-by-case是下下之策，因為資源是有限的，人員也不可能無限增長，這個時候你可能要去尋找統一解決方案，目標是能遮蔽前端多款業務的差異性，建立統一的流程和平臺來完成相同場景的運維任務。這個平臺是遵循ESB設計思想的，提取共性解耦前端業務邏輯，實現支撐一百款業務跟支撐一款業務付出幾乎同等的運維成本。一個簡單的抽象如下：

支撐業務量少時，以上模式沒有太大問題，為各業務做定製化保姆式運維響應。當業務量增長到一定程度，明顯人員和組織架構不可能成正比無限增長，此時可能需要如下這種橫向支撐的模式

當然做到這個程度，有很多前置工作要做，如標準化的建設、自動化的建設與持續整合、運維工作的高度抽象與持續整合、甚至可能需要從研發、測試這些上游流程上去做改變。這是個從小工作坊到工業化流水生產線的過程，革命性的轉變非一日之功。

Chapter 3  運維人員的自我修養

運維人員在專業技術上的積累這個是基本功了，凡是IT領域的東西都該去多瞭解一些，主要是技術應用方法了，對於解決常規的業務需求可以拿來即用，對於需要深入理解的方面還是要系統性的學習，建議是去搞清楚整個來龍去脈、找到根源和理論基礎，這塊涉及的東西太廣泛，就不多說，除此之外的以下方面本人覺得往往對個人的成長起到更大的作用。

1.   改善溝通

稍微有些職場經驗的人都知道，很多時候問題的關鍵不在於資源、路徑或者是技術問題，而在於人的問題，你所在的部門領導、你的leader、流程上下游相關的人、業務相關介面人等等，這些在你處理某個事務時有交集的所有人都可能影響到整個事務的成敗。既然是人的問題，就需要通過溝通來解決，在運維工作中，我們涉及的業務介面人、流程相關方、細節資訊確認方等經常是錯綜複雜，有時甚至斡旋於多個團隊之間太極打的風生水起，還是搞不清楚這事誰負責，到底該找誰解決。關於溝通方面體會最深的有以下幾點：

• 一次性原則：說一件事情，用最簡短的語言把整個事情描述清楚，且讓人沒有疑問，不要擠牙膏式的給資訊。在團隊協作做某項實施時，經常遇到這類溝通：

A：那誰一會幫忙把DB重啟下

B：哪個DB？

A：xxx業務的一區的DB

B：一區DB機器有3個例項，是哪個？

A：3310例項啊

B：現在重啟嗎，還是等你通知？

A：等我通知。。。

這種溝通可簡化為：

A：等我這邊把前端停掉，你幫忙將xxx業務一區DB機器(192.168.1.1)的3310 例項重啟下，等我通知再操作！

B：好的。

簡化，表達清楚，簡單的事情一次性說清，不留疑問，配合你的人一看就明白要做什麼。

• 確定正確理解：這個是雙方面的，當你更他人溝通事情時，確保他正確理解了你要表達的，沒有任何疑問，有時需要再三確認他真的理解了，舉一個例子：本人曾經在電信IDC與動力人員配合做電力割接，由於是兩路市電，UPS出來到列頭分A/B路接伺服器的雙電源，所以只要兩路電不同時停則伺服器不會斷電，已經跟動力實施人員溝通好，一會先停A路電，割接完成後恢復A路然後再停B路電，他表示已經懂了，結果在實施的時候他還是將A、B路一起停了，五六雙眼睛盯著他，表示無限惋惜…。後來想想，如果當時直接在空開上做個標記，按實施順序編號給動力實施人員講解可能就不會出問題了。有時他人的理解跟你想表達的完全不同，確定他理解的是你想表達的很重要，尤其對於運維這種高危職業而言。

• 找對溝通的物件：這個需要運維人員先熟悉整個組織架構和工作介面劃分，什麼事找什麼人，這塊內部溝通還好，在外部溝通中往往出現問題，導致非常簡單的事情兜了好幾圈都沒解決，所以找對那個真正負責此事的人來配合你的工作，如你不清楚外部團隊的內部分工，就找外部團隊介面人。
• 要主動不要被動：運維作為業務支撐團隊，我們的工作安排和計劃均基於業務側運營側的相關計劃，這就要求運維側要主動去跟上游或周邊團隊溝通，儘早拿到上游資訊，儘早著手安排相關工作，凡是趕早不趕晚。運維工作中其實最難把控的就是突發緊急情況、臨時需求變更等等，主動溝通可有效減少這類情況發生，並使運維工作變得有序合理。

一個好的運維一定是擅長跟各種技術和業務團隊溝通的好手。

2.   優化意識

運維的工作往往很雜、很細、很亂，可能你每天都在處理重複的需求、做著重複的事情，埋頭在一堆單調重複的瑣事之中無法自拔，基本沒有時間去學習新的知識和技能，我相信每個運維都遇到這些情況，每天加班加點、且沒有成就感，也輸出不了什麼價值。如果到了這種狀態，我覺得往往是優化工作做的不夠。優化，可大可小，從自身出發，可先尋找個人工作中的優化點，一點一滴去做，什麼是優化點，簡單來說工作中你的痛點就是優化點！很多時候我們需要放下手上的瑣事多做總結和思考：

• 為什麼天天加班事情還是做不完，如何提升效率？
• 為什麼每天做重複的事情，有沒有固化的自動的方案？
• 為什麼總是在救火的時候出現問題，預案和演練平時有做嗎？

小到某個特定的執行細節、大到整個流程體系，甚至要推動多個團隊來配合，把這些讓你感覺費力的不爽的地方變得通暢，省時省力且質量還能提高，這些應該是最能體現運維能力和價值的地方。

如果運維工作中某個環節讓你很不爽，想想問題在哪裡，有何可行的優化方案，然後去推動和實施，抱怨解決不了問題，持續優化是很重要的意識，尤其對於運維從業者而言。當然有人可能會說這個問題領導或其他團隊不重視，推不動，無法優化，這種情況第一可能是你沒有讓別人看到優化方案的閃光點和預期收益，只對你方有利卻把麻煩拋給了他人，沒有製造雙贏或多贏的局面，可以再深入下方案，相信對大家都有利的事情都會願意去做。第二可能是管理上的問題了，公司制度使然，這種情況應該是極少數，就不去挑戰了，除非你能把老闆優化掉。

3.   規劃能力

沒有人會一直做運維執行和操作，到最後其實更多的是做運維規劃，尤其是在做海量業務支撐時，前期的規劃往往在很大程度上決定了後期的建設和維護成本。

• 如何制定伺服器資源供給與排程計劃？
• 如何規劃網路架構以適配多種形態業務的需求？
• 某業務上線各節點階段性的工作安排是什麼？
• 自動化建設的整體規劃和實施路徑是什麼？
• 如何搭建運維團隊，規劃人力分配？

大量的運維實施經驗和積累後，對於運維中的事務，多從規劃角度去考慮，往往能做得更好。

4.   學習與分享

這塊就不多說了，運維是一門實踐性很強的科學，專業眾多，保持學習的心態很重要，分享亦是一種美德，更是個人積累和成長的重要方式，每個人都有自己獨特的經驗和感悟可以分享出去，共同成長。

說了這麼多，不知能否改變我那位朋友覺得運維很low的印象。總而言之對於運維價值的體現和提升有更多的事情要做，本文只是杯水車薪。最近看《權利的遊戲》，整個影片構建了一個巨集大且殘忍的史詩級魔幻世界，裡面有個置身七國紛爭之外的特殊群體——守夜人，一個人只要是失去生活目標了、墮落了、不被社會認同了、或者感覺活膩了，你還有一個地方可以去，那就是加入守夜人團隊，從此將擺脫一切身份，洗去一切罪孽，斷掉一切念想，活在另一個世界為七國守衛絕境長城。

守夜人有非常霸氣的誓詞，以下獻給各位運維同仁：

Night gathers, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the watcher on the walls. I am the fire that burns against the cold, the light that brings the dawn, the horn that wakes the sleepers, the shield that guards the realms of men. I pledge my life and honor to the Night's Watch, for this night and all the nights to come.【長夜將至，我從今開始守望，至死方休。我將不娶妻、不封地、不生子。我將不戴寶冠，不爭榮寵。我將盡忠職守，生死於斯。我是黑暗中的利劍，長城上的守衛。我是抵禦寒冷的烈焰，破曉時分的光線，喚醒眠者的號角，守護王國的堅盾。我將生命與榮耀獻給守夜人，今夜如此，夜夜皆然】。