本文分為三個部分，第一部分從服務傳遞和服務度量兩方面介紹運維可視化；第二部分介紹什麼是devops以及它給運維帶來的改變和影響；第三部分結合最新的資料資料和趨勢聊一聊運維人可能面臨的危機。
part 1
可視化
沒有比“可視化”更好的一個詞能概括運維的本質，而“可視化”又應該分成兩部分：可視化的服務傳遞和可視化的服務度量。
一、可視化的服務傳遞
早期的運維是從itil開始的，那個時候大家都不知道運維是什麼，幸好找到了一個it服務最佳實踐——itil。開始了網際網路運維的摸索之路，從cmdb、服務台、事件管理、變更管理、可用性管理、容量管理等逐漸去了解，并同步建設對應的管理平台。但我們很快發現，這一完備的流程架構如果遇到了大規模運維的情況，就無法應對，原因在于過多的聚焦于流程以及規範，我們發現很難提升運維靈活度和精細性，并且我們還是不知道一個完整的it服務邊界在哪兒？如何實作它？
不過在itil的實踐過程中，其實提出了一個很好的概念——it服務。對于運維來說，提供一種高效、一緻性、透明化、面向使用者的服務是運維的價值所在，這樣就要求運維屏蔽其提供的服務背後的所有實作細節。
從運維具體事務或者活動的角度來說，如何對其進行一次或者多次的組合封裝，把它們變成一個完整的it運維服務，是此時的運維自動化重點方向。畢竟繁雜的運維事務不進一步封裝，對個人或者團隊來說，都意味着很高的學習成本和事務執行成本。在傳統的it運維組織中，我們能看到彼此事務之間的割裂非常明顯，比如說網絡、機房、伺服器、應用部署等，都是在不同的團隊完成，彼此工作獨立進行。在靈活和精益運維驅動之下，必須要求有一個內建平台來把這些事務流排程起來，否則無法提高事務執行的效率和品質，真正地把運維傳遞功能變成了傳遞服務的模式。
對于如何封裝這些事務或者活動，從devops提倡的“自動化一切” （auto everything)可以找到些答案，其核心的自動化主線就是面向使用者的靈活持續傳遞。我把持續傳遞又分成兩類場景：一種是持續傳遞基礎設施，一個是持續應用傳遞 （持續建構、持續測試、持續部署、持續回報)，他們有點近似iaas和paas的關系。
持續傳遞基礎設施在公有雲iaas平台中得到很好的解決，利用軟體定義計算、存儲、網絡等技術來實作對上層應用所需資源的快速傳遞。在私有it環境中，目前有大量客戶采用虛拟機方案或者私有雲方案來解決傳遞難和慢的問題。最新的輕量級虛拟化技術docker更是熱點，根本的原因是把應用的傳遞在鏡像級别完成，進而讓應用傳遞更加快速。
持續傳遞軟體從代碼産生的那一刻就開始進行管理，到編譯、到測試、到灰階環境驗收再到正式環境部署，并且希望這條主線完全自動化。面向程式包的持續內建非常簡單，現在有很多的開源解決方案來實作，如jenkins、go等，但有一種情況需要特别注意，就是程式包的配置管理問題，這個也往往是影響部署的重要因素。是以我們很多時候使用開源平台隻是為了建構程式包，後續包及其其中的配置管理以及執行個體化部署，特别是大規模叢集部署，都是由單獨的持續部署平台來解決，而非之前的持續內建工具（雖然它們也支援釋出），但持續部署平台需要有和持續內建平台無縫對接的能力。
基于軟體包的傳遞解決之後，我們希望傳遞的粒度更大，如何實作全應用（從應用的前端接入到後端存儲)的傳遞，此時便有了paas平台和基于應用架構的可視化部署服務兩種方案。這兩種實作思路有很大的不同，我們知道完整的paas平台提供了對底層公共服務的向上api統一抽象，比如說資料庫服務、存儲服務、cache服務。paas平台最經典的實作應該是cloud foudry了，國内很多paas平台基本上都是參考cf來實作的。阿裡uc也有一個類似的paas平台，示意圖如下。
而在現實的情況中，很少公司有能力把mysql、mc、fastdfs封裝公共服務供上層應用直接調用，意味着對研發程式有着一定的要求，是否還有一種更輕量的無限制自動化方式呢？我們可以把運維的全應用部署轉變下思路，此時把應用架構中的各個部分拆解成對象元件（包含屬性和狀态)，比如說機房、os、應用包等，全應用部署就是這些對象的編排，類似可視化ide程式設計環境。
綜上所述，運維的自動化最終要實作可視化，複雜的運維工作流必須通過可視化來表達，可視化後的自動化才能讓所有人了解一緻、執行一緻、結果一緻。
二、可視化的服務度量
“除了上帝，一切人都必須用資料說話”，這是運維人員必須恪守的信條。我寫過一篇完整的資料驅動運維的文章“關于資料驅動運維的幾點認識”，裡面系統地介紹了資料化運維的目的、資料的來源以及如何建構資料體系，等等。
最近也在進行一個資料實踐，就是建立面向應用的端到端資料分析體系，該體系對資料有個标準化的分層歸類，從基礎設施、上層元件、到應用服務、到接口、再到使用者側，基于應用的拓撲架構，收集各類名額，統一到一個分析平台中展現，如下圖所示。
基于這套分層化的資料體系标準，我們也有對應的系統實作，如下圖所示。
當形成标準的資料采集、分析和展現體系之後，可以向其他應用不斷去複制這套方案，大家隻需要遵循一套資料标準即可，最後資料的采集、分析、展現和告警都是标準化完成。這套資料體系建設完成之後，可以在運維的故障定位、服務優化、架構改進、運維規劃等各方面找到應用場景。
此時有人會有疑問如何面向應用把這些資料整合關聯起來？我們目前是基于配置檔案的靜态視圖和基于接口調用而生成的動态視圖來內建。動态調用視圖生成會複雜一點，可以讓線上的接口調用統一由名字服務中心來接管排程，抽樣對接口調用進行染色，進而生成動态的通路關系。
以上視圖能快速發現和定位規模故障，但對于單個使用者的故障名額上則應對乏力。此時分布式trace服務的作用就顯現出來了，可以借鑒twitter的zippkin和google的dapper的實作思路。目前我們就結合自身的業務架構特點，實作了一個統一的服務排程架構和名字服務中心，在業務代碼無侵入的情況下，可以把業務排程鍊的染色資料上報和關聯，實作對于單個問題的快速定位。
資料的可視化能力非常重要，需要在面向整體和面向某個業務流上都有實作。它首先展現出你對運維的了解是什麼樣的，從可視化dashboard上可以看到最直接的運維經驗；其次基于可視化之上的資料共享，讓大家對資料的了解達成一緻；最後利用一緻化的可視化資料發揮運維的驅動能力，驅動devops，資料的核心價值就在于此。
是以可視化的能力就代表了運維的能力，可視化的程度越高，運維的能力越高。那麼你現在到底可視化了哪些運維服務，并能進行度量呢？
part 2
devops，值得運維擁抱！
最近公司組織大家出去讨論關于協同效率問題，之前在騰訊也讨論過部門牆的問題。随着公司的日益增大，這類問題會一直存在，且一直在解決而不能徹底解決。此時，我從運維的角度來談devops還是比較應景的，它恰好給這個問題提出了一個全新的解決方案。結合之前自己總結的一個devops ppt，在下文中，我通過我的ppt逐漸來談談我對devops的了解（部分來自于自己的總結，部分來自于之前的讀書筆記）：devops到底是什麼?給運維帶來了什麼樣的改變和影響？
一、devops是什麼？
1、devops的初印象
devops在很多人看來就是一個代号，先不管它的到底是什麼，但這個代号有一個很大的好處，統一了溝通交流術語，如同之前的靈活。另外從字面上第一次把devops放在一起來看，抛棄了之前的一些概念，比如說運維，甚至更早期的d/o分離等等。
devops和dev/ops、dev & ops是有着一些差別。首先、dev/ops、dev & ops都強調兩個獨立的職能角色；其次dev/ops用分離的視角來看研發和運維，最典型的後果就是研發隻看功能需求，不考慮可運維性，而dev & ops在一定程度上兩個團隊的合作能力是更強了(平行團隊)，但是還沒有做到真正的跨職能。把devops融入到各自的日常活動中，無論是研發、測試和運維都需要面向共同的目标、價值觀、思維模式等等。
2、devops是一種文化（culture）
單純的說是一種文化，非常空洞。文化的表現必須是通過一種運動的形式來表達其内在的價值訴求，就如同文藝複興和五四新文化運動一樣。同樣在devops領域，也是因為多種運動不斷催生的産物，比如說一天10次部署運動、平台及服務運動、持續疊代運動等等，最終達到其文化價值的傳遞，比如說高品質、高效率的服務傳遞。從我的角度來說，持續內建、xx(架構、監控)及服務及運維資料化是devops的核心，可視化是其最終的呈現。
3、devops是一種價值觀（valueset）
價值觀是devops需要恪守的準則：
（1）持續優化。任何一個工作都不存在完美的狀态，應該持續的推動他，自動化平台的建設如此，資料驅動devops更是如此，因時而變。
（2）合作共赢。把彼此的合作放在第一位，完成面向使用者的共同價值輸出，而非個人所在部門的利益達成。
（3）杜絕浪費。任何停滞都是一種浪費，不作為更是一種浪費。
（4）關注使用者。使用者的價值為最終的導向，并且讓使用者的價值反向傳導到内部工作流節點上。
4、devops是一種思維模式（mindset）
在早前我寫過一篇文章探讨過網際網路+和雲+之間的關系。我也特意對兩者的思維模式做了一個對比。
其實在思維角度來說，這兩種思維也有很大的相近之處。網際網路思維，雷軍的七字訣不做過多的解釋。在devops的思維層面上來說，我也做了一個總結，大緻如下：
(1) 精益
精益思想（lean thinking）源于20世紀80年代日本豐田發明的精益生産（lean manufacturing）方式。豐田的精益制造有14項基本原則，後面有人對其的管理思想進行提煉，總結出精益思想有五項基本原則：
從客戶的角度來定義産品價值。價值由客戶定義，而非自己定義。
識别價值流。精益思想識别價值流的含義是在價值流中找到那些是真正增值的活動、那些是可以立即去掉的不增值活動。精益思想将所有業務過程中消耗了資源而不增值活動叫做浪費。識别價值流就是發現浪費和消滅浪費。
讓價值流流動起來。精益将所有的停滞作為企業的浪費，是以要求創造價值的各個活動（步驟）流動起來，強調的是不間斷地“流動”。
拉動式價值創造。按照客戶的需求進行生産，設定好對應的投入和産出。
持續改進式到盡善盡美。“通過盡善盡美的價值創造過程為使用者提供盡善盡美的價值”。
在很多管理思想上，原理是互通的，pdca、全面品質管理、六西格瑪等等，甚至是所遵循的方法論，devops也是如此。
(2) 價值
當網際網路思維在強調他的使用者口碑的時候，而我們的技術服務則強調他對使用者的價值輸出，進而為産品赢得口碑。價值在上面也提到是使用者關注的價值，而不是我們認為的價值。高可用、穩定的服務是品質的根本，品質則是價值的一部分，而不斷的滿足使用者需求的服務才是重中之重，這就讓各自的團隊有了一個共性的衡量标準。
(3) 跨界
其實網際網路思維的專注是讓你對事情有更深入的了解，才能做到極緻。而在devops所倡導的思維模式，并不是讓你去失去專注，而是在此基礎上讓你更加跨界。在強調職能分工的企業中，過多的限制在某個崗位上行駛某個職能，不利于事務的整體推動。而運維是那個全局觀能力最強的人，恰恰需要這個時候從整個價值鍊的活動來全局觀察，并提出方案。同樣，研發和測試也需要不斷跨出自己的職責區，去和運維一起優化産品和技術方案。
(4) 靈活
業務要求快，技術則要求靈活，無論是流程的靈活，還是服務傳遞都需要非常靈活。傳統的靈活觀點是要技術如何更好服務業務部門的需求，是dev和biz的之間的合作模式，而現今的靈活則從持續內建、持續傳遞、持續部署等多個層次對靈活提出了新的要求，是dev、test、ops甚至是産品部門一部協奏曲。
5、devops是一種工具觀（toolset）
devops首先倡導的原則是自動化一切，但資料化同樣重要，并且我提出要把他們都可視化呈現出來。自動化是可視化一切價值流的過程，資料化則可視化價值節點的狀态。這個在之前的運維可視化部分裡，有全面的闡述。
二、devops的最佳實踐
damon列舉了一系列實踐與舉措，對于這些舉措，我也用幾個詞做了備注。這些實踐與舉措在那些成功應用了devops的組織中已經成為它們日常工作的一部分，如下：
去除“完成”這個詞，服務是永不停止的，它們一直在運作并應該得到持續
關注【持續優化】
将運維需求與功能需求一樣視為一等公民，使運維方能夠及早發現需求影
響【合作共赢】
将工作流程可視化，使所有人對全局有了解，瓶頸自然顯現【可視化】
協同比對價值流，這樣才能了解系統全局并發現浪費【價值驅動】
将資訊流變為産品流，以降低資訊傳遞中的歧義并澄清人員間必須的交流【拒絕浪費】
将相關資料組合起來形成有意義的名額，讓組織中不同利益相關者都能意識到【資料可視化】
通過将變更關聯到相應名額并将它們圖形化來提升對變更的認知【資料可視化】
有目的地妝點辦公室牆，使每個人都感覺到自己是整個系統的一分子【工作滿意度】
去中心化管控，讓産品的開發者和運維者就責任達成一緻（例如：開發者負責代碼的正常運作，運維負責平台的正常運作，諸如此類）【共享責任文化】
舉行内部小型會議，大家可以在會上就已經完成和可以完成的事項達成一緻，會上也鼓勵大家就變更發表自己的意見。【共同參與】
強制在運維的幫助下對所有開發送出的服務進行部署驗證檢查，以避免在運維時才出現問題【持續部署】
釋放你的猴子，這能使你對自己的服務承諾産生巨大的自信【信任】
在問題發生時不僅在管内（pipeline flow）流轉（要引入更多的變更和工作），而是關注在找到瓶頸發生的真正原因并加以修正【杜絕浪費】
保證對客戶透明，在出現問題時勇于擔當，在問題解決後保持警惕，客戶自然有理由心滿意足【關注使用者】
在團隊和日常工作流以外建立良好關系，例如通過“guess the admin”遊戲或與公司内不同的人一起共進午餐【合作與分享】
2013年puppetlabs做了一次devops調查，也談到了最佳實踐，彙總如下：
三、devops和itil對比
devops和itil有着明顯的不同，從這個不同的也也可以看出，devops代表着未來，itil已經不适用網際網路的業務運維模式（傳統企業還不敢說）。itil應該算是運維第一個階段的指導思想，但在日益快速變化的網際網路運維面前，它已經無法勝任。當然現在有些文章也在表達itil的思想和devops思想的相同之處，比如說也在強調服務生命周期的管理，最佳實踐也是在指導系統平台的建設。但我覺得從本質上來講，itil完全沒法覆寫運維的活動，其次沒有從價值鍊的傳導過程設計運維實踐，比如說持續內建，這些都是其緻命的弱點。
四、devops的核心技術名額（吞吐率和延時）
從devops的最佳實踐及自動化要求來看，devops本質上就是為了更好地解決組織的吞吐率（throughout）和延時（latency）問題！在前面也談到過，我們可以把所有的運維活動提煉成面向使用者的價值流（flow），這些流從技術層面上來說，真的有點類似于我們線上應用系統的一次請求。對于技術請求來說，對其性能的衡量就是吞吐率和延時，那麼對于運維服務性能（ops performance）來說，也可以轉換成吞吐率和延時。那麼這兩個名額具體有代表什麼呢？
1、吞吐率
(1) 持續內建性能，可以從不同的團隊角色出發提煉出不同的名額。
從研發團隊來說，每天觸發持續建構及單元測試的數量、....；
從測試團隊來說，每天回歸測試的數量、每天自動化測試的數量、....；
從運維的角度來說，每天持續部署的數量、生成持續回報報告的數量、....；
(2) 其他的變更性能
一個運維人或者團隊，一定周期内的運維變更能力，比如說可以支援多少個業務多少個變更能力。不過這個變更能力取決于兩個方面能力，一個是工具的自動化能力；另外一個取決于線上服務公共化的能力。前者大家很好了解，後者大家就不好了解了。舉個例子，當一個被調用服務需要擴容的時候，此時這個服務被前端服務放在配置檔案中還是dns服務中，這個變更的複雜度完全是不一樣的。
是以對一個運維團隊來說，在建構自動化平台的同時，也别忘了和研發一起做架構上的優化，提升運維的吞吐能力。
2、延時
(1) 持續內建延時
之前提到過把能力不斷前置，其實是把服務的延時不斷降低，類似技術架構中的cache機制。我們都知道，為了讓業務通路資料庫更快，就不斷的把資料推到離應用程式更近的地方；為了讓使用者下載下傳更快，我們把檔案通過cdn分布到離使用者一公裡。過往的實踐告訴我們，打破原有的思維定勢非常必要。在過去的觀點中，運維應該是應用環境的第一負責人和執行人，但在持續部署平台完善的情況下，釋出工作可以不斷往前推置；dns服務的管理也可以不斷的交給應用運維自己去管理，甚至直接開放api供應用程式直接排程修改使用。這些工作都需要相關團隊的彼此推進和結合，否則很難實作以上所說的角色轉換。前置的最極緻表現，就是使用者的行為對系統産生影響的時候(高容量)，變更即刻自動化完成。
集中式也必須不斷走向分散式，使用去中心化的管理模式。我們都知道中心化能帶來良好的管理和控制，但是最大的影響就是效率，多對一的情況下，那個一很容易成為瓶頸。但在無平台的情況下，我不建議這種能力直接往前端推置，不同的人的管理很容易不統一，這個會給後期的統一自動化平台建設帶來更大的成本，而在有平台的情況下，把相關的服務能力直接傳遞給前端。
(2) 故障恢複延時
故障恢複越快越好，這就意味着對使用者影響更小。但為了達到這個故障恢複延時很小，則需要監控平台、資料平台強大的支援。如果把故障分解成三階段：發現故障、定位故障、解決故障，則每個步驟依賴的能力是不同的，縮短每一個階段的延時，是我們日常運維在故障處理這塊的工作重點之一。
更高吞吐率、更低延時的運維就是更好的運維，我們須持續不斷的推動及優化！
五、devops，運維需要做的改變
1、組織的改變
按照以前職能分工的組織結構造成隔離的責任制文化，大家都隻關注自己的崗位職責，而不去care其他。但在devops的要求之下，運維活動需要經常的跨職能進行，這也要求部門之間需要有一個共享責任的文化氛圍去更好的銜接部門之間的關系。目前在國外的一些調查報告中可以看出，已經出現了獨立的devops部門和devops工程師。從組織的角度來說，需要一些devops教育訓練，如同組織引入靈活教育訓練一樣。
2、個人的改變
目前每個人要認識到，運維不再是簡單的參與維護職責，而是整體事務的推動者和解決者，此時需要利用運維人的全局觀去把控整體項目的影響等等。
運維人也需要不斷跳出舒适區，去跨界識别風險和提供優化方案；需要讓自己變成善于整合資源的人，集中各團隊的優勢能力，讓我們的運維傳遞更快、服務更穩定。面向問題和面向事務的運維需要往面向使用者價值的運維轉變！
3、工具觀的改變
以前以itil為中心的流程系統建設方法論，需要徹底的改變，把持續內建自動化當作第一要務。有了持續內建的平台之後，不斷去解決底層（如：作業系統安裝）及上層應用排程的自動化，最終形成自底向上的自動化排程平台方案。
其實devops不就是那個協同效率的解決方案麼？
part 3
運維危機，你嗅到了麼？
運維危機是運維人的危機，你感覺到了麼？
其實這個時候談運維危機有點像在當下讨論股市危機一樣，是以寫這個話題時，内心很糾結，特别是這個網際網路運維才産生沒多少年（10年）的行業，怎麼你就來談危機了？沒辦法，都因技術發展太快。
首先帶大家看一組資料，國外著名企業級公有雲管理市場上司者rightscale每年都會釋出一份雲計算市場報告，rightscale應該是雲管理裡面的鼻祖，2013年他們平台管理的伺服器達到580萬台，是以他的資料報告還是有一定的權威性，從這個報告中可以讓我們看到一些趨勢。
一、雲的使用情況
1、雲的使用度已經達到93%的水準，而在具體的雲使用政策上，可以看到未來多雲（82%）和混合雲（55%）是未來的趨勢。
其實這兩組資料給我們展現都是雲的趨勢越來越明顯，使用者的接受度越來越高。而雲計算到底對運維有着什麼樣的颠覆力？
2、個人也對對國内的公有雲使用情況做了一次調研，使用者的使用水準也是相當的高（遊戲領域），達到76.19%。因為樣本量不大，應該會更高。
3、rightscale報告中，也對devops的使用情況做了統計。使用者應用devops的理念或者工具很廣泛，達到66%的水準，相比去年有一定的增長，并且在it更複雜、靈活性要求更高的大企業中，devops的應用比例更高。在devops工具的使用上主要是puppet、salt、chef、docker幾類。調查報告中用了“devops rises，docker soars”來總結devops和docker。
4、為了進一步去驗證devops理念的應用情況，我把puppetlabs的devops的報告又找出來了，總結了devops的核心理念及實踐。報告反複強調自動化、強調devops文化價值、強調資料驅動等等，這些對運維又有着什麼樣的影響呢？
二、危機在哪兒？
1、雲計算平台對運維的影響
我們都知道雲計算平台有iaas平台、paas平台、saas平台之分，不同的部分對運維的角色都有着不同程度的影響。
iaas把基礎架構做成一個服務，資源即需即得，這也正式創業公司都願意使用公有雲平台的一個原因。按照傳統的模式，創業公司自己需要聯系機房、購買伺服器、電信機房放置調試伺服器/網絡等等一堆基礎設施的工程，影響項目周期不說，還需要一定的專業技能，而iaas把創業公司都從這些需求中解放出來。再進入到iaas内部幾大部分，軟體定義計算、軟體定義存儲、軟體定義網絡，進一步降低對運維人的依賴，確定一個大資源池的整體服務能力。讓軟體代替人，是iaas層基本思想，都知道對于一個海量的服務架構，同時要面向不同的業務形态，iaas隻能依賴這樣的軟體定義能力，靠人是跟不上的。剛剛paypal分享他們遷移到openstack經驗，其中一個資料很有意思，以前paypal對伺服器故障的容忍度是1%，而遷移雲平台之後容忍度是3%到5%。要知道這個比率提高意味着什麼，對運維的實時事務處理要求進一步降低，也就是對人的需求減少了。結論：不需要那麼多基礎運維人員了。
paas部分，進一步對服務進行抽象，變成一個公共的服務架構，研發程式隻需要遵從一定的開發和配置限制，最後服務的運作、釋出等都由paas平台統一接管，進一步釋放對運維的依賴，且此時根本就沒有iaas層維護成本；結論：不需要那麼多應用運維人員了。
最後到saas部分，這塊目前在國外非常活躍，國外從運維領域的監控、自動化部署、資料分析、資源管理等領域都有多家公司在提供服務。之前依賴運維從無到有的建構，現在也不需要了。在傳統的模式下，運維都是自己搭建監控平台，自己建構部署系統。目前情況下，對于小的企業來說，可以直接使用雲平台自帶的服務，足夠應付。對于更大規模的企業環境來說，你可以選擇其他雲服務，隻要你許可他們的agent安裝在你的伺服器上，采集資料/部署都可以完成。再回過頭看看iaas雲中提供的rds服務（類似saas服務），裡面把一切對mysql的管理都封裝成webui；對于系統中慢查詢，在給出報告的同時，還能給出相應的優化建議，備份、遷移管理都一應俱全。不過幸運的是，國内目前這塊的産品還不多。結論：不需要那麼多應用運維人員和dba了。
随着在雲計算不同層次的雲服務水準的不斷提升，對傳統的運維模式（流程性、功能性、技能型）逐漸形成颠覆力。可能還是會有很多人有疑問？從公有雲擷取到伺服器資源之後，總還需要做一些一些人去做系統管理的工作吧？不需要，你是否想過未來假設有人基于puppet或者salt封裝一個appstore的模式供使用者使用，裡面所有的sa管理方案都可以通過下載下傳的方式應用到自己的os環境；paas現在很難應用起來，部署工作總還需要運維吧？我認為即使paas應用不起來，通過其他的持續部署方案和更上的自動化編排方案都可以解決自動化的問題，因為本質上就是釋出檔案和執行指令；應用需要經常變更、擴容、故障定位總需要運維吧？我也不這麼看，你所會的技能很多都隐藏在資料之中，通過容量資料可以驅動應用變更和擴容，并且容器docker的出現可以讓這個工作變得更簡單，關于故障定位，很多時候都是依賴一些故障定位技巧，而這些技巧都是可以通過資料來做root cause分析的，隻需要把資深的一些運維人經驗提煉成産品。
是以我更願意相信在不久的将來會有一個完整的運維産品存在（類似erp），該運維産品能夠解決自動化運維的問題，能夠把一切技術資料收集起來，按照運維人的經驗來提煉資料的價值，應用到各個運維場景中去，比如說容量、故障定位、擴容、變更等等。
2、devops對運維的影響
在前面給了一些關于devops的資料，首先可以看出devops的理念已經開始逐漸被更多的企業所接受，其次devops關注的焦點也和過去的流程itil有着本質的差別，他就是需要通過自動化不斷的降低浪費、驅動靈活、打破團隊邊界等等。在前不久，我參加了今年puppetlabs的一個線上調查，裡面可以看到國外已經有專門的devops部門存在，且有專門的devops工程師。我是如何看devops？就是把後端的ops服務不斷的推到前面dev，讓前面的dev具備ops能力，這就是devops。當然背後是靠平台和工具支援的，流程肯定是不行，這是傳統運維急需要改變的地方。把這種對人的依賴和運維的經驗都轉換到平台中。在早期，所有的釋出變更都依賴運維來完成，後來我們搭建釋出平台，可以讓測試來做釋出，再往後釋出平台和自動化測試平台進一步對接，這個釋出工作再進一步傳遞給研發，運維從過去的執行者變成了稽核者，自動化驅動一切，品質、靈活驅動一切。
再去到資料化運維部分。由于研發、運維都是技術人員，是以大家很容易對技術資料達成一緻的認識，甚至有時是研發會更敏感，因為他更了解自己的服務該如何衡量。過去我們都有錯誤的認知，把資料當着運維團隊的核心資産且保密，隻有運維團隊使用，而其他的團隊隻能關注到一些運維給到的結果，其實這是違背devops原則的。而我的建議是，運維提供采集一切資料的能力，把上層的分析和展現能力開放給所有技術人員，運維人員隻是資料使用的一個角色，可以按照自己的價值次元和場景抽象幾個資料産品出來，比如說監控、容量、品質、可用性等等。研發人員也是資料使用的一個角色，它可以按照自己對服務的了解，去任意的加工資料，這個有點回歸到以前bi的那套思路了。
是以運維最終要變成經驗平台的建設者，而非簡單的事務執行者。
3、開源技術對運維的影響
現在還有什麼開源解決不了的呢？請直接搜尋【開源的devops開發工具箱】或者關注部落格【http://www.devopsbookmarks.com】。
而我想說，在運維的每個部分都有相應的開源解決方案存在，難道我們還說對運維的依賴很重麼？在任何一個運維開源技術面前，運維能表現出比研發更強的把握能力麼？說實話，開源技術把之前運維的技能牆打破了，都可以擷取技術的能力。不過這個地方有運維的一個存在價值，也就是國外devops部門的存在價值，我的思考是devops部門提供的是運維平台統一規劃和建設能力，否則對于一個企業來說，技術和目标的協調無法完成。開源技術降低了擷取門檻，但也提高了被濫用的可能，而運維部門可以避免這種濫用。
一方面我們要注意到當下的雲端技術變化趨勢以及對運維的影響，另一方面要清楚的知道單純的流程性/功能性/技能型運維，已不是時下需要，危機正在悄悄走進你。目前運維的存在空間，還有部分是因為開發不懂什麼是運維，他們連puppet都不知道。當有一天運維也像開發、測試一樣變成雲端服務，運維就不需要依賴某個運維人和某個運維團隊了。是以請盡快擁抱自動化運維、資料化運維，并往運維産品化、規劃方向提升，一起做好運維轉型準備吧。
優維科技公司創辦人。
2007年進入騰訊公司接觸運維，經曆伺服器從百到萬的運維曆程。
先後在yy和uc參與不同業務形态的運維，期間帶過多種運維團隊。
極力倡導網際網路價值運維理念，即面向使用者的價值是由自動化平台傳遞傳遞，同時由資料化來提煉和衡量。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-02-17</b>