運維價值的提煉，直接決定了團隊（個人）對運維理解的高度和精度！
從很多傳統的視角去看運維，運維的確承擔了很多職能，但這些職能還是都和具體的崗位相關，如下：
在過往的運維經歷中，很多研發甚至是運維自己都把運維就放在了一個資源（服務器、網絡）提供者定位上，造成很多運維團隊的成就感不是很強。很多運維人也經常問，我們的價值到底在哪兒？“保姆”/“救火”/“苦逼”好像就是運維的標簽，難道我們的運維真的只能如此？這篇文章就和大家好好談談運維的價值在哪兒？讓大家看看運維都能做些什么？
價值不等於作用，說到價值，一定有其內涵,該內涵且可以通過幾個關鍵詞來表達的。關鍵詞表達的好處可以避免理解泛化，同時也概括了對運維理解的抽象能力。在早期的騰訊運維經歷中，那時我們把運維價值分成了幾個方向：質量（高）、成本（低）、效率（快）、安全（風險），到現在我始終認為這一模型還在普遍受用。具體的個人理解如下：
一、質量(Quality)
我們還需要從經典的質量定義開始，用【層次分析法】逐漸打開，去認識質量體系的全貌。
美國著名的質量管理專家朱蘭（J.M.Juran）博士從顧客的角度出發，提出了產品(服務)質量就是產品(服務)的適用性，即產品(服務)在使用時能成功地滿足用戶需要的程度。
此時我們看到的“滿足用戶需要的程度”，其實是一個很不精確的概念。但是這個定義中提到了一個很好的詞--“程度”，這就意味着產品的質量是需要被度量的，否則沒法來說明我們現在產品(服務)到底怎么樣，那如何可以被度量呢？我們還可以從運維的角度來看，把產品進一步進行歸類：
A、內部產品
比如說像機房、機架、服務器甚至是OS等產品，這個產品完全是運維部門自己產出的，並且是提供給研發使用的，對用戶是完全透明的，對內部產品的好與壞的最直接衡量就是可用性。比如說我們可以定時出具報告，最近服務器的可用性怎么樣？最近OS的可用性怎么樣？最近機房的可用性如何？用這些數據來驅動我們運維流程和運維規范不斷完善。內部產品的可用性數據獲取可以通過事件單的記錄故障時間的方式來獲取。
B、外部產品
首先需要把外部產品進一步分解成一個一個的功能（服務），然后衡量功能（服務）的可用性。就拿我現在維護的游戲SDK業務來說，SDK是一個產品，這個產品提供了很多功能（服務），有統一登陸服務、統一注冊服務、統一支付服務等等，這些服務在用戶使用的過程是否一直能滿足用戶的需要。注意：一定要從用戶直接感知的功能和服務去分解，不要摻雜任何內部的視角，也不要去衡量非核心服務，比如說SDK的DNS自動切換能力。對非核心服務來說，服務的異常，客戶不是太敏感，並且可以通過技術的手段（服務降級）去臨時降低用戶對產品的期望。
其次互聯網產品是一個體驗式服務，需要有一個對體驗的衡量指標---速度。
許多研究都表明，用戶最滿意的打開網頁時間，是在2秒以下。用戶能夠忍受的最長等待時間的中位數，在6～8秒之間。這就是說，8秒是一個臨界值，如果你的網站打開速度在8秒以上，那么很可能，大部分訪問者最終都會離你而去。研究顯示，如果等待12秒以后，網頁還是沒有載入，那么99%以上的用戶會關閉這個網頁，不再等待。
Google也做過一個試驗，顯示10條搜索結果的頁面載入需要0.4秒，顯示30條搜索結果的頁面載入需要0.9秒，結果后者使得Google總的流量和收入減少了20%。Amazon的統計也顯示了相近的結果，首頁打開時間每增加100毫秒，網站銷售量會減少1%。
Google最新的pagerank算法中納入了網站的速度指標，可見速度是多么重要。
再者用戶滿意度也是一個產品和服務的衡量標准。用戶滿意度可以通過客服投訴或者論壇的客戶投訴情況來度量，設定一個產品的不滿意的基准，然后根據這兒閾值去衡量用戶滿意度。滿意度可以統計歷史的數據，然后設定一個合理的基准，在這個基准之上，持續的改進，從而設定新的基准。
最后在業務自身維度上，還有一些指標可以采用。對於下載類業務來說，也許要看下載速度；對於通道類業務來說（短信網關），還要看到達率等等；對於流媒體類業務，可以看卡頓情況；對於資訊媒體類的業務，甚至還看百度SEO指數等等。這個地方可以采用層次分析法，多挖掘業務的特性指標。這個地方記得控制指標不宜過多，最好控制在3個左右，過多的指標會讓最終的質量數據波動太大，從而不能更好的牽引優化團隊向前，也可以A階段用A指標，等A優化完成后，在B階段再納入另外一個指標。
此時我們也講一下可用性和質量的區別，順便也介紹一下可用性。業界有一個明確的定義，可用性就是連續服務時間占總服務時間之比，該文章【http://blog.csdn.net/cszhouwei/article/details/38459095】介紹非常詳細，因此就有了不同時間粒度的可用性（日、周、月、季度）等等。那什么是可用的服務呢？對於功能（服務）來說，就是功能正常（服務狀態碼），並且能夠快速的返回（低於服務延時），就是正常。
再用一個完整的圖來概括一下運維質量的譜系，如下圖：
二、成本（Cost）
運維不是直接的效益部門，但是可以通過成本控制產生效益。在一個海量服務的情況下，帶寬/服務器/人力都是非常昂貴的資源，成本的控制精細化考驗了運維團隊的技術能力和管理能力。
首先需要一個完整的數據去展現當前服務資源的利用率情況，其次需要根據這份數據來推動不斷推動相應的優化。
從服務器的角度來說，我們可以把服務器的四大資源(cpu、內存、IO、網絡IO）的利用率作為直接的服務資源使用率參考（取他們的最大值），一定要注意避免使用操作系統的load來衡量服務器的利用率情況。設定一個合理使用率為基准，強制要求業務必須在這個閾值之上，並且鼓勵業務更充分的利用資源。問題來了，研發會說，我如果把服務器資源利用率使用到50%，萬一業務壓力突增，會影響我的業務？對運維的技術要求就來了，我們是否有實時的擴容和調度能力，是對運維自動化變更能力的挑戰，所以說考驗運維的技術能力。
從帶寬的角度來說，可以把單用戶占用帶寬的情況統計出來，同時也要把帶寬的消耗分布提取出來，對web型業務，需要去分解頁面的帶寬占用消耗分布；對於下載類服務來說，多維度分析帶寬的消耗原因，然后分析是否可以借助用戶的下載灰度控制、P2P技術、錯峰、增量更新、預下載等手段去控制帶寬的使用。YY語音的帶寬控制非常出色，最終到每個語音包上的苛求優化，非常精細。
在人力的角度來說，可以轉換成人均維護服務器的數量，這個地方可以衡量人的運維能力，運維的服務器越多就意味着人力成本越低。也用一個完整的圖來表達成本的控制：
三、效率（Efficiency)
運維效率能夠看到運維平台化的能力。從場景的角度可以分解出很多種對運維效率的要求，比如說故障發現問題效率、故障定位問題效率、發布效率、(DNS/LVS/網絡/業務)變更效率、資源交付效率等等。運維都不提倡面向業務部門的SLA，但所有的運維團隊都在這些維度提出自我要求，從而不斷去驅動運維平台和規范的建設。特別是涉及到線上服務部分，比如說故障定位能力、擴容變更能力等等，這些能力目標提出來之后，可以檢驗我們那些地方做的不足【PDCA的精髓】。大家現在經常說的持續集成，也主要是在效率維度能帶來全流程優化的收益。具體也可以分解成如下圖：
上圖只是列了部分的場景，其實場景非常多，比如說DNS、LVS等等。在底層各專有事務系統成熟之后，最終檢驗運維效率的一個核心指標就是面向業務整體調度和整體交付能力。
四、安全（Security)
安全是一個互聯網產品的生命基線，需盡早安全的制度和規范應該在早期的產品研發過程中參與進來，其次要建立一個全面的安全體系，從系統級、數據級別、應用級別等各個維度去對待安全的問題。對於數據的安全保護，更是中重中之重。數據要建立分級體系，不同的數據分級需要有不同的管理策略和數據使用策略，這些策略包含訪問密碼加密、訪問日志的脫敏、數據隔離訪問、數據加密、數據的備份、數據的加密獲取等等。這里面涉及的內容非常的多，需要建設專業的運維安全團隊。
在上面我們看到運維價值的四個維度，在其中有很多需要運維去細化的工作，此時你是不是覺得自己有很多事情要干了？你要搭建平台，你要建規范，做標准，還要學會用數據驅動運維/研發/測試。在之前的文章中也說過運維的本質是可視化，在這些維度的具體工作上都有體現，無論是自動化的可視化還是數據的可視化。
總而言之，運維需要建立一個強勢且一致性的質量文化，由質量來驅動研發/測試/運維；用最低的成本和最快的速度完成面向用戶的價值交付。