公眾號回覆：乾貨，領取IT管理體系文檔
公眾號回覆：ITIL教材，領取最新ITIL4中文教材
由於自己一直是做應用運維的，所以今天主要是和大家講應用運維相關的，我個人總結了一些體系和方法論，希望能對你們有幫助。
第一部分：我講應用運維是什麼；第二部分：我講應用運維需要什麼樣的團隊；
第三部分：給個案例講講運維能做什麼？
第一部分：應用運維是什麼
其實很多時候非運維的人員不知道運維是什麼，他們都理解你們是網管、提供伺服器的，處理故障的，其實這些都不是。
恰好這幾天有個產品經理社區說讓我去講運維，那麼我要把運維和他們講清楚，我不斷在想運維是什麼?
對於我來說，運維就是技術運營，和產品運營差不多。
對於用戶的需求，一方面有實際的產品實現服務交付，另一個方面需要技術去支撐產品，無論是客戶端還是服務端、無論是網絡還是伺服器，涉及的技術很多，因此我覺得對於運維來說，如何把你維護的技術棧運營好是非常重要的。而把產品和技術拉到同一個點上的就是用戶價值。那什麼是用戶價值呢？我把客戶的價值是獲取服務需要一定的成本之上，所獲得的服務能力。這個裡面有產品提供的功能能力（產品指標）、獲取的可用性（運維指標）、體驗（產品+運維指標）和成本（產品+運維指標）。
其實這個思路確定之後，會影響我們後續很多應用的方法論以及團隊之間合作的感覺。我們運維和產品、技術等等都是服務於用戶，最終的價值點都是用戶的，這樣把我們的合作點都拉到了相同的對象上來了。接下來我講我整個應用運維的方法論。我把它理解成幾部分，
第一：運維整體的原則；
我很多時候都看這個，一定是價值導向。前面講了用戶的價值導向，我們技術運營的好，就是讓用戶使用我們的產品很爽。
設計這麼多的技術棧靠人肉一定是沒法運營好的，這個時候必須要平臺支撐，我把平臺分成兩部分，一部分是自動化平臺（實現價值交付），一部分是數據化平臺（實現價值衡量）。
服務透明，分成兩部分，一部分是離線服務，一部分是在線服務。離線服務比如說運維伺服器資源提供，運維擴容能力，甚至是ITIL的服務等等，這些服務能力一定要對研發和業務部門透明。千萬別設置很多的表格來研發或者產品理解。
在線服務的透明，我其實講得更多的是服務公共化能力，打造公共化的服務平臺。原生memcache、mysql都是組件，而不是服務。而需要在此基礎上讓他們具備可運維性，一個重要衡量基準就是透明性。
最後一定要數據來驅動，別動不動跑到研發那邊說，你這個不好那個不好，拿一些數據出來，告訴他們那個地方不好，包括我們自己哪兒不好，其實這個和服務部分也有些關聯。我們的數據驅動可以驅動我們內部的服務優化，另外一個就是驅動線上的服務優化了。用戶價值已經說了，接下來說說平臺。
在很多運維人的眼裡，ITIL就是運維的平臺，而我說不是，我很多觀點都在講去ITIL化，去ITIL到底要去什麼呢。
一個是去流程化的意識，一個是去服務化的意識。
在一個故障發生的時候，不要埋怨人做錯了什麼，我是不是可以通過流程或者加入什麼審核機制來規避掉，那是傳統的做法，不建議。建議找技術驅動優化的方法，待會兒後面有個案例會說這個觀點。去服務化，是因為現在的運維服務範疇已經大大的發生了變化，這個服務的邊界已經拓展了很多。最低級的如果你還按照服務某個研發或者業務的方式去做運維的，最後運維是沒有出路的。高級一點，我把ITIL裡面涉及到的一一幾個流程做成產品，封裝服務，其實你會發現很多服務在網際網路化下已經發生變化了。
因此我自己把運維平臺做了一個總結，我覺得可以適用大部分團隊。
（注意這個圖中寫了「此服務非彼服務」，這個服務是將的一種動態能力，而ITIL服務講的是一種靜態能力。）
裡面你可以理解有幾個部分，基礎架構及服務（IAAS及私有IT設施），配置及服務（CMDB）、架構及服務（公共服務能力那塊）、數據及服務、監控及服務、持續集成服務、適當的考慮一下ITIL那塊服務能力的封裝，比如說事件。問題管理就不需要了，做了這麼多家，從來沒有去實現問題管理。
架構及服務，我後面在運維路徑裡面再講一下。數據及服務，我把技術數據的本質理解成指標和事件數據，運維應該有能力去採集這些數據，然後分析、在此基礎上進行告警。甚至我覺得監控是數據服務上一個場景，因為對於很多用戶來說，監控的維度非常複雜，其實想傳統的nagios和zabbix完全不能滿足這種柔性。
剛剛講了整體的原則。接下來我把應用運維三部曲，做應用運維都是在這個路徑上去走。第一步做標準化，第二步做公共服務化，第三步做服務去狀態化。
這個我之前寫過一篇文章，裡面詳細介紹了每部分的內容，這個地方再簡單的和大家過一下。
一定不要忽略標準化的價值，當你從底向上把運維標準化做好了，你以後的運維成本會大大的降低，比如說自動化，甚至是服務發現等等。我之前把標準化分成：伺服器的、OS的、機房部署的、應用環境的等等。這個裡面發揮一下想像力，能標準化就標準化，小到一個進程的屬主和路徑，達到機房甚至是架構選型。特別是架構選型這塊，一定不要被開發牽著走，特別是有些研發說性能很高，我希望你們給到的回覆是，我多給你幾臺伺服器。還有一個標準化很重要的是協議，在YY有一個標準化的YY協議，目前我負責的業務這邊都採用http協議，在統一協議之上做一些運維能力封裝特別簡單，比如說監控、數據採集等等。
服務化，我剛才說mc、mysql都是組件化能力，不是服務化能力，真正服務化的平臺一定是運維友好的，一定是對前端應用是無狀態感知的，比如說mysql擴容和遷移等等，都可以做到對APP無感知，這才是服務化能力。
無狀態，等我們所有基礎設施都標準化了，這個時候，我們就要去無狀態化了，去識別架構中的單點問題，挖掘出來優化他。這個裡面有方法論可以遵循，早期騰訊有個海量服務運營之道，大家可以網上找找。
我這次有個項目優化也遵循了這個原則，收到很好的效果。
應用運維也有了路徑，接下來就是怎麼落地了，那麼我會在不同的階段，制定不同的方向，比如說我現在的團隊來說，我的方向如下：
就是做數據化運維、自動化運維和精細化運維。
緊扣當前階段的目標，識別當前團隊的矛盾點，設定具體的KPI方向，持續以周為單位進行跟蹤。
都會有明確的要求，每周滾動。這個群裡面很多我的同事。這個地方的建議，一定不要把擴容變更能力、伺服器提供能力作為指標放到你的KPI中。做得不透明和不好是我們的恥辱，做得好是應該的。所以很多時候我說運維是要帶著恥辱感去工作，每天我做重複的事情，點按鈕，敲命令就該想想什麼地方要改進了。
這是運維團隊能力要求，裡面有三個部分，業務運維即應用運維、運維研發、運維技術研究。
我希望大家日常的運維工作，在業務運維這塊越少越好，而運維研發和技術研究越多越好。 還有一個非常重要的東西，運維工作是什麼驅動的，這個代表著不同類型的三種團隊。
問題驅動，救火隊員，你天天在救火，有沒有感覺每天半夜要起來苦逼，如果是這樣的話，一定要去把問題找出來，這個階段都有，按照我說的三部走一定可以解決。
事務和需求驅動，我覺得就是一個保姆角色，做內部服務的提供者，研發找我要伺服器，我給伺服器，找我部署，我去部署，找我...我幹...最後一個是價值、優化、用戶驅動的運維團隊，我們需要走出來，把自己的能力放大一下，運維能做的事情很多呢，三部曲裡面那麼多東西可以做，還有自動化平臺建設，還有數據化平臺建設。特別是T3、T4職級，我覺得一定是從運維研發能力走過來的，只有你做過自動化，你才能對運維的東西進行抽象，其實這個和測試一樣，長期做功能測試，你最後都失去了對測試美好願景的想像，運維也是如此的。
技術能力希望大家再全棧一點，很多應用運維一個薄弱的環節就是對數據能力的了解。其實我有時候還建議大家去看看Oracle資料庫呢，這個能力非常重要。恰恰我覺得應用運維做到最後如果能不了解業務就最好了，做到業務無差異化運維。
其實運維開始非常苦逼，是吧！但是你把這個事情當成一個挑戰來看和對自己的一個不斷完美的要求，你會覺得運維是有很多美感的，這個美感我在之前一篇文章裡面講過了。在此就不複述了。
（圖還是要給，強化一下大家對美感的認識）
這一部分我講了團隊能力要求，驅動模型，個人能力要求和運維美感，不全是苦逼。
最後一部分我講一下一個故障看運維的價值。
說一下家醜，去年12月13號，我們一個核心業務，因為交換機故障，導致我們服務終端45分鐘，100%服務不可用，恥辱。
這個故障暴漏了很多問題，我們有冷備中心用不起來，復盤的時候發現很多架構問題。。
問題真的很多很多，這個地方有個經驗，問題是運維最好的老師，特別是線上故障，如果一個故障產生的時候，運維一定要挑頭把這個故障進行復盤（騰訊運維的經驗），最後你能識別出很多需要改進的地方。
好吧，問題已經發生了，我們要解決它，領導說了，別跟我說那麼多沒用的，簡單指標，5分鐘發現故障、三分鐘解決。怎麼解決啊，幾乎是不可能的任務，不過領導說的，咱們硬著頭皮也要挑戰一下。不過UC有一個很棒的地方，團隊合作特別好，一群優秀的人。我們就成立了一個專項組：把產品、測試、運維、研發、還有項目管理都卷進來了。13號出的故障，14號我們復盤了，15號了，我們就成立項目組了。
簡單而極致的要求是我們平時需要不斷告訴自己的，最怕的心裡狀態是這個故障跟我沒關係，頭都不挑，其次一種怕，就是說技術能力不足，會不會被研發挑戰。
簡單而極致的要求是我們平時需要不斷告訴自己的，最怕的心裡狀態是這個故障跟我沒關係，頭都不挑，其次一種怕，就是說技術能力不足，會不會被研發挑戰。
不要怕呢，我們都是為用戶服務的。
我在項目一開始，也確定了一些原則，其中總結起來最核心的就是」技術驅動優化「，而不是流程優化。
這個裡面分成了六個方向：服務降級、雙中心、統一調度、過載保護、業務分離、立體化監控。
為什麼需要這些簡單的原則？這個有利於項目一致的理解。其實剛剛頭條新聞也發生了500錯誤，從服務影響時間來看，30分鐘左右，我猜是後臺資料庫壓力過大導致，在這些原則裡面都能找到解決方案，比如說過載保護，服務分離等等。
這些原則和方向許多都是運維參與的，比如說雙中心就涉及到運維參與方案的討論，給出數據雙中心的方案、立體化監控也是80%是運維來做的，統一調度，我們藉助了天雷調度（httpdns）。
然後在這六個方向上我們就制定了具體的改進措施，最終完成了剛才說的5+3目標。
這個故障其實可以看到運維很多東西可以做的，首先運維一定牽頭，第二運維一定要提出自己的要求，第三運維跟進參與整個改進方案的實施，第四，運維要最後給出最終的結果報告，我們做了這麼多到底怎麼樣。
自己希望的一個願景吧，沒有操作就是好的運維，最後應用運維沒有運維就是好的運維。
其實許多時候不要讓大家感受到我們運維，我們運維就是成功了，運維的SAAS化一定是未來的趨勢。
接下來是問答環節：
1、目前自動化運維這塊有什麼好的學習建議嗎？
王：我對自動化有分層化的理解，我建議應用運維第一個把持續集成作為重點，其次是把配置管理作為方向（比如說puppet、saltstack）等等。
持續集成帶來的收益非常大，可以吧運維從日常繁瑣、低價值的任務中釋放出來，並且是跨越了研發、測試和運維三個團隊，這個裡面解放了幾個團隊的生產力，收益很大。
但我建議你們持續集成一定以標準化為前提，否則做起來很累。具體的表述見文章：2、問題類似：技術驅動，那些技術？
王：這個技術驅動，其實是一些技術的方法論，基於這個方法論，當然你也需要很多的技術儲備，無論是存儲的、還是應用的，還是協議的，還是程序研發的，甚至是測試的，都需要了解了，全棧。3、請問，很多企業把運維細化到分片分區管理，你說的運維理念又很難實施了。
王：這個應該是傳統企業來的吧，這個變革力就看大家的要求了。我的預見是總有一天用戶會逼著你做出改變，這種外力比內力推動力更強。4、具體的學習路線
王：如饑似渴的學習和運維相關的一切知識，ITIL、網絡的、作業系統、應用組件的沒有好的學習路線來遵循，把你崗位上做到機制，把周邊知識都吸收進來，比如說你從網絡上去看應用運維5、學習建議
王：我的建議不要浮於表面做運維，當你遇到一個不懂的問題時候，你要深究到底，然後順著他就可以打開知識體系了，舉兩個簡單的例子，top命令看到的那些CPU佔用的指標，user、sys、idle、io....我以前面試就經常問這個，可惜很多人都不知道。
如果你能說出來原理，就說明你把知識地圖打開了。其次我們經常定位問題用的strace，但你真正的去了解strace原理的時候，裡面有很多作業系統的知識涉及到，當年因為strace，我還把作業系統的書重新看了一遍。不放過任何一個細節，總結和思考自己目前正在做的。我覺得其他的東西都好解決了。
6、請教：運維人如何做績效考核？東西很難量化，主觀意識太強？
王：去掉主觀的東西，識別自己需要優化的地方，平時記錄下來，然後要求組員也記錄下來，到每個Q制定規劃的時候，大家一起提。在此很感謝老王為大家帶來這次分享。
來源於網際網路運維雜談