IT Operations(IT 運營），運維的更價值化認識

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

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

1、運維是什麼

運維從IT軟件工程的階段論來講，通常分爲用戶需求階段、軟件開發實現、軟件測試和軟件維護幾個階段。所以不少人就把運維粗暴地解讀爲運行+維護。不過慶幸的是，運維人本身已經認爲咱們不是簡單的維護角色了。維護的角色是一種職能化的表述，意味着你是郵件工程師、服務器工程師、網絡工程師等等。

其實運維對應的英語單詞是Operations，而不是Maintenance。Operations有「操做、運營」的意思，通常會和IT一塊兒出現，稱之爲IT Operations（IT運營），也就是咱們如今說的運維，Maintenance只是一個維護的定位，早已退化。

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

顯然從階段論的角度來看運維，沒法歸納運維的全貌，因此本身一直和別人說運維就是IT運營，那什麼是IT運營？如下是我作了一個產品通路的分解，而後分解出一條技術運營的主線。

當用戶的需求被識別出來以後，這個時候必然會產生兩種需求:一類是用戶需求的功能性描述，一類是用戶產品的技術實現描述。接下來從不一樣的需求出發，此時會產生產品運營和技術運營的要求。技術運營必定是基於技術產品和業務產品中的技術部分，包括基礎平臺產品（網絡、機房、服務器、DNS）、應用產品（application、協議）。爲了確保它們可以知足業務的目標，運維須要提供多種保障措施，好比說構建自動化平臺（配置管理、調度平臺、IT產品管理平臺）和技術產品數據運營平臺(監控、應用性能管理、能力管理等等)。以上的分解思路，能夠解釋運維是否須要構建大數據平臺，且和產品大數據平臺的差別點與邊界。

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

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

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

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

在這個模型圖裏面，關於IT產生的價值指標也很是明確，徹底的導向了業務價值，好比說經濟性、質量、敏捷性、客戶滿意度和商業貢獻度等等。

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

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

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

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

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

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

3、什麼是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能夠幫咱們更全面的去看待運維。不過切忌照搬哈。

4、IT運營的目標衡量

IT運營對象是技術產品，它的特性決定了IT運營的要求和策略的不一樣，概括總結有以下：

一、功能性

軟件提供的功能是否知足了用戶須要？這個地方還有不少個維度能夠衡量裏面有是否提供了正確的功能（適合性）、適合用戶需求的功能（正確性）、安全的功能（安全性）等等。

二、可靠性

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

三、易用性

易用性是一種產品化的能力，能夠體如今產品是否可以被用戶快速理解的，可以易於使用的，且操做友好的。不要讓用戶拿到一個產品以後，本身捉摸該如何操做，對於某個核心功能來講，操做的深度很深。操做友好就體現着相同的產品功能下，設計的不一樣，給用戶帶來的操做複雜度是徹底不一樣的。同是紅包功能，微信紅包、QQ紅包、支付寶紅包給用戶帶來的易用性徹底不一樣。

四、效率

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

五、可維護性

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

可變動性。架構的變動能力很是重要，若是一個架構引入變動就須要對用戶服務產生中斷或者影響的話，說明這個架構是有不足的或者變動方案設計是不足的。

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

如何實現可監控性？我的以爲首先要有一個監控平臺，其次監控平臺須要有采集一切數據的能力，且能自動分析數據的關聯，最後纔是經過數據實現端到端的監控能力。

可變動性和容錯性，是在架構設計和實現的階段，就要考慮後續對運維友好，設計和實現一個彈性可擴展服務架構對運維來講很是重要，數據解耦和服務解耦是優先要考慮的原則。舉個例子，對於一個用戶註冊的功能來講，能夠有URI和域名兩種實現方案來區分服務，顯然前者的區分對運維不友好，當由於容量的問題，要實現註冊核心業務分離的時候，須要在七層代理服務上按照URI進行服務轉發，而採用域名的解決方案，則簡單許多，DNS指向修改便可。

六、可移植性

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

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

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

不少時候，咱們會擔憂運維作久了，特別是運維被雜事和故障所牽繞的狀況下，會忘了咱們還能作什麼，更是忘了咱們實際上是從IT運營而來，從IT運營的角度看運維，特別是和ITOM結合起來去看運維，帶來的感受又徹底不一樣：

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

第2、不斷去思考運維帶來的業務價值。從以前的討論中均可以看到運維的最終價值點，它們都有一個業務價值的通用描述，咱們是否有結合本身的業務仔細思考過，提煉過？我把這些又歸納爲運維的外在思考。

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

注：這篇文章還能夠談談IT運營的方法和策略，可是限於篇幅，不做深刻展開！