一直想努力向別人（甚至包括從事運維的人）解釋清楚什麼是運維，發現很難！

6月20號，在InfoQ高效運維群裡面，對運維創業做了一次激烈的討論，很自然地，過程中不可避免的談到運維苦逼和運維無法產品化的問題，這是一些運維需要說服自己，證明自己價值的問題。對於本人來說，運維的價值不容置疑，只要我們運維人能自我認識突破，更體系化的站在業務角度看待運維價值問題，那我們就不是一個苦逼的成本部門。此時我自然的想到了【IT運營】，它帶來的視界會更加開闊，能夠幫助更好的重新認識運維。

一、運維是什麼

運維從IT軟體工程的階段論來說，一般分為使用者需求階段、軟體開發實現、軟體測試和軟體維護幾個階段。因此很多人就把運維粗暴地解讀為執行+維護

其實運維對應的英語單詞是Operations，而不是Maintenance。Operations有“操作、運營”的意思，一般會和IT一起出現，稱之為IT Operations（IT運營），也就是我們現在說的運維，Maintenance只是一個維護的定位，早已退化。

二、什麼是IT運營（運維）

顯然從階段論的角度來看運維，無法概括運維的全貌，所以自己一直和別人說運維就是IT運營，那什麼是IT運營？以下是我做了一個產品通路的分解，然後分解出一條技術運營的主線。

當用戶的需求被識別出來之後，這個時候必然會產生兩種需求:一類是使用者需求的功能性描述，一類是使用者產品的技術實現描述

IT運營和產品運營很多落腳點是類似的，也是一種持續改進和閉環的策略，講產品的生命週期管理和優化，產品說，我是為了提供給使用者更好的服務或者價值；技術運營（即運維）說，我也是為了提供給使用者更好的服務或者價值。真的如此麼？那我們在看看什麼是使用者的價值。

對於使用者來說，一種更低成本更高質量的服務才是他們需要的，因此把使用者價值分成多個維度的描述，有產品功能和特性需求側的，有使用者體驗側的，有成本方面的（如上圖）。由此也可以看出很多的使用者價值訴求都會轉換成對軟體產品技術的需求，這類技術需求實現之後，需要運營手段來保證和持續改進。

在業務網際網路化的今天，使用者獲得同質服務的觸點變得越來越多，如何讓自家的業務脫穎而出，一方面考驗產品運營能力，另外一個方面更是在考驗技術運營的能力。在小米推出米聊後不久，騰訊就迅速推出微信，這是騰訊後臺技術架構對業務的敏捷支援；在有相同功能的兩個網際網路產品選擇下，你一定會選擇那個訪問快（速度），並且可用性高，易用性好的產品，特別是速度。在過去的工作中，可以列舉很多IT運營能力不足而影響業務發展的例子。

Gartner早期還有一個關於IT價值的模型描述，會有稍稍不同，列出供參考：

在這個模型圖裡面，關於IT產生的價值指標也非常明確，完全的導向了業務價值，比如說經濟性、質量、敏捷性、客戶滿意度和商業貢獻度等等。

• 經濟性。包含了投入成本、產出效率和生產率。

• 質量。包含了可用性、相應時間，交易速度等等。

• 敏捷性。IT對於業務變化的適應性和調整的速率，一個好的IT業務架構應該能夠適應業務的變化，從而快速對市場相應決策。

• 客戶滿意度。可以各個渠道收集客戶的意見，比如說appstore，產品論壇，客服，CRM渠道等等。

• 商業貢獻度。提供更多的商業價值，比如說更大的市場份額，更多的使用者獲取，更高的市場佔有率。

說這麼多，是想改變大家對運維的一個錯誤認識----運維是成本部門，而非收益部門。在一個分散式的x86的複雜架構環境中，如果沒有運維部門的統一規劃和管理，等於一個樂隊少了指揮，其技術建設、管理和運營肯定會陷入混亂，最終影響的是使用我們產品的使用者。

三、什麼是IT運營管理

IT運營管理，IT Operations Management（ITOM），其中最經典的描述是還來自於Gartner的經典解釋。Gartner從一個更全域性、更巨集觀的視野來分析了ITOM的組成及其趨勢。Gartner每年會發布多個領域的hype cycle的報告，hype clye是一種分析方法，把一個領域涉及的技術從誕生、發展、成熟等多個過程在一張圖中描述出來，並且預估它未來會爆發的時間表。從圖中的組成部分，可以看到IT運營的全貌，會涉及到ITOM的多個方面，2013年的報告內容如下（來自於Chuck Henry的一篇PPT分享)。

橫座標不解釋了，大家可以自己查查英語單詞，加深一下印象，另外不同的形狀標示著未來爆發的時間週期。比如說ITIL處於幻滅期，它的再次爆發至少要5到10年。

從這個PPT頁面中，你可以看到很多個方向，比如說DevOps、ITIL、APM、IT能力管理、配置管理、CMDB等等，你能說它們和你運維無關麼？其實做過網際網路運維的人都或多或少的知道上面圖形中術語的意思，因為很多都和我們日常的工作相關，有些是在執行ITIL的過程中接觸到的，比如說IT service catalog、CMDB；有些是在DevOps實踐中接觸到的，比如Application Release Automation，當然全域性的DevOps會包含更多哈；有些是我們在做資料分析的時候接觸到的，比如說Service-Level Reporting tool，Capacity Planning and Management。

這麼多方向如要落地實施，一定是運維部門主導建設的，或許大家已經這麼幹了，此時你難道還說運維就是一個苦逼打雜的，運維沒有價值的？ITOM可以幫我們更全面的去看待運維。不過切忌照搬哈。

四、IT運營的目標衡量

IT運營物件是技術產品，它的特性決定了IT運營的要求和策略的不同，歸納總結有如下：

1、功能性

軟體提供的功能是否滿足了使用者需要？這個地方還有很多個維度可以衡量裡面有是否提供了正確的功能（適合性）、適合使用者需求的功能（正確性）、安全的功能（安全性）等等。

2、可靠性

軟體的執行是否可靠的？可以通過可用性指標來衡量，可用性的指標在上一篇文章結合故障有談到過如何計算。典型的兩個很衡量維度就是容錯性和可恢復性。前者將對故障的容錯處理能力（要麼不出故障），後者對出現故障之後的恢復能力（出故障後，要麼快速恢復）。

3、易用性

易用性是一種產品化的能力，可以體現在產品是否能夠被使用者快速理解的，能夠易於使用的，且操作友好的。不要讓使用者拿到一個產品之後，自己捉摸該如何操作，對於某個核心功能來說，操作的深度很深。操作友好就體現著相同的產品功能下，設計的不同，給使用者帶來的操作複雜度是完全不同的。同是紅包功能，微信紅包、QQ紅包、支付寶紅包給使用者帶來的易用性完全不同。

4、效率

體現在面向使用者的產品交付速度和內部IT支撐服務的響應速度。前者效率體現者使用者等待新功能/新特性需要付出的時間成本；後者體現在內部IT支援需要付出的時間成本，在業務量出現增長的情況下，我們需要多少時間能夠把支撐的資源提供到位。效率維度基本上都是DevOps自動化解決方案的範疇。

5、可維護性

可監控性。對於一個複雜架構，是否具備可監控的能力，它是一種能夠幫助你快速發現故障，快速定位故障直至恢復故障的能力。

可變更性。架構的變更能力非常重要，如果一個架構引入變更就需要對使用者服務產生中斷或者影響的話，說明這個架構是有不足的或者變更方案設計是不足的。

容錯性。是一種容錯的能力，特別是一些非期望錯誤的容錯能力，這個在前期的設計準則中需要考慮到一些不可靠性的設定，比如說網路不可靠、硬體不可靠等等。同時對於一些未知的錯誤，提供自動的降級服務或者容錯服務能力。

如何實現可監控性？個人覺得首先要有一個監控平臺，其次監控平臺需要有采集一切資料的能力，且能自動分析資料的關聯，最後才是通過資料實現端到端的監控能力。

可變更性和容錯性，是在架構設計和實現的階段，就要考慮後續對運維友好，設計和實現一個彈性可擴充套件服務架構對運維來說非常重要，資料解耦和服務解耦是優先要考慮的原則。舉個例子，對於一個使用者註冊的功能來說，可以有URI和域名兩種實現方案來區分服務，顯然前者的區分對運維不友好，當因為容量的問題，要實現註冊核心業務分離的時候，需要在七層代理服務上按照URI進行服務轉發，而採用域名的解決方案，則簡單許多，DNS指向修改即可。

6、可移植性

是IT產品的可遷移性，一則就涉及到IT技術產品的選型問題，當你選擇的IT技術產品開源和公共化程度越高，遷移的成本就越低。公有云服務很多都是基於開源協議的實現，就是一個典型的例子，確保使用者的技術產品能夠無縫切入到公有云；

其次要考慮雲端的服務遷移能力，包含了公有云之間的遷移能力（顯然目前不具備）和私有IT環境向雲端服務遷移的能力。

有了這些特性維度，基本上就有了IT運營的資料體系，做好IT運營，就是不斷去挖掘技術產品所產生的日誌和資料，去衡量IT技術產品的現狀以及未來的運營優化的方向。不過要注意的是在可維護性裡面不僅僅是度量這麼簡單，還有自動化平臺建設來滿足可變更性的要求，它的直接衡量指標就是之前提到的變更延時。

很多時候，我們會擔心運維做久了，特別是運維被瑣事和故障所牽繞的情況下，會忘了我們還能做什麼，更是忘了我們其實是從IT運營而來，從IT運營的角度看運維，特別是和ITOM結合起來去看運維，帶來的感覺又完全不同：

第一、平時運維的工作層面到底還有多少提煉和認識不夠的地方（以ITOM為對標）？同樣是做應用效能管理APM，程式碼級效能管理是不是唯一的方法，結合網際網路還有哪些實踐，他們之間的互補又在哪兒？能力管理的必要性是在哪兒？如何建設能力管理系統，從能力管理的三個層次來看，他們的成本和收益是什麼樣的？我把這些概括為運維的內在思考。

第二、不斷去思考運維帶來的業務價值。從之前的討論中都可以看到運維的最終價值點，它們都有一個業務價值的通用描述，我們是否有結合自己的業務仔細思考過，提煉過？我把這些又概括為運維的外在思考。

當我們把其內在和外在都思考清楚了，其實也就是把運維的某方面思考清楚了，此時我們結合行業的特點去做運維，提煉最佳實踐，是不是意味著運維更有價值了？

注：這篇文章還可以談談IT運營的方法和策略，但是限於篇幅，不作深入展開！