本文主要是從 DevOps 持續(xù)反饋的視角出發(fā)未状，圍繞著構建企業(yè)質量體系的目標，談談如何做好監(jiān)控析桥、做好告警司草、做好運營這3件運維繞不開的大事。

備注：本文由IT大咖說（id：itdakashuo）轉自數(shù)人云公眾號（id：dmesos）泡仗，此文是5月6日深圳DevOps與SRE線下技術交流大會埋虹，《DevOps最后一棒，有效構建海量運營的持續(xù)反饋能力》主題演講的文字稿娩怎。

嘉賓演講視頻回顧及PPT：http://suo.im/5bNLnb

1.DevOps持續(xù)反饋關鍵在于做好運營

這張圖概括了整個DevOps的體系搔课，它最后的一個環(huán)節(jié)，就是做運營和終結的環(huán)節(jié)截亦。對與運營和終結的理解爬泥，我認為應該包含兩個緯度，一是這次運維活動的質量運營與終結魁巩；二是產品的技術運營和生命周期的終結急灭。今天我們聊下在產品生命周期結束前，我們在技術運營階段構建的質量體系谷遂，以實現(xiàn)持續(xù)反饋和優(yōu)化的目標葬馋。

2.產品在運營階段運維發(fā)揮的關鍵作用

在騰訊運維看來，要做好持續(xù)反饋的落地肾扰，我們有必要做好3點：

①監(jiān)控——覆蓋率畴嘶、狀態(tài)反饋、指標度量

監(jiān)控要做到360度無死角集晚，業(yè)務出現(xiàn)了什么問題都能發(fā)現(xiàn)窗悯，有了監(jiān)控的反饋，可以看到實時監(jiān)控的狀態(tài)偷拔，同時蒋院，當指標發(fā)生變化的時候也需要看到一些反饋。

②告警——時效性莲绰、準確性欺旧、觸及率

業(yè)務越來越復雜，層次越來越多蛤签，每一個監(jiān)控點都會產生數(shù)據(jù)指標辞友、狀態(tài)異常，會收到越來越多的告警。未看到或者看到未處理都需要承擔責任称龙，因為收到的并非都是誤告警留拾。最重要還要有觸及率，告警由誰發(fā)現(xiàn)與處理鲫尊？

③運營——RCA痴柔、事件管理、報表/考核

問題再三出現(xiàn)疫向、必須從根源優(yōu)化竞帽。通過事件管理機制保證RCA可以落地，最后通過報表和考核去給運維賦予權利推動相關優(yōu)化活動的開展鸿捧，包括架構和代碼的優(yōu)化等等。

3.騰訊業(yè)務的立體化監(jiān)控

騰訊的業(yè)務按照不同的層級進行管理疙渣，從下向上匙奴，有服務器層、數(shù)據(jù)庫妄荔、邏輯層泼菌、中間計算的這一層，有接入層啦租、負載均衡哗伯，有我們的機房，DNS服務篷角、客戶端焊刹、用戶端，為了做到無死角恳蹲，我們規(guī)劃與建設了很多監(jiān)控點虐块，美其名曰立體化監(jiān)控。

在2014年實現(xiàn)用戶輿情監(jiān)控能力后嘉蕾，我們的監(jiān)控點做到了100%的覆蓋（不考慮時間緯度：P）贺奠，但并不能高枕無憂，因為當監(jiān)控點做得越多越立體化的360度無死角后错忱，每個最細節(jié)的點都會有指標去度量儡率，指標數(shù)據(jù)爆炸很有可能成為另一個潛在的監(jiān)控隱患。

4.監(jiān)控系統(tǒng)大興土木之后的思考

從而引出以清，我們迫切需要在運營階段要解決的難題：

繁 -> 簡

在具體生產過程中會產生運維的事件或者是故障儿普，經常會有死機，以及各層監(jiān)控告警玖媚，這些繁瑣的告警箕肃、故障，改如何簡單化今魔？

泛 -> 精

舉個案例勺像，在一臺核心的交換機下障贸，假設其下聯(lián)有1000臺的機器分布到數(shù)據(jù)層、邏輯層吟宦、接入層等等篮洁，當這臺交換機故障不可用時，由于有立體化監(jiān)控的存在殃姓，每個監(jiān)控點都會產生大量的告警信息袁波，我們要如何發(fā)現(xiàn)這些告警是由于這臺核心交換機故障引起的呢？

亂 -> 序

由于指標采集方式和計數(shù)據(jù)量的不同蜗侈，直接導致了監(jiān)控的流處理效率是不一樣的篷牌，告警收到的次序不一樣，我們要如何排序踏幻，如何有效識別優(yōu)先級枷颊？

所以我們今天重點聊下，在監(jiān)控匱乏的時代我們在積極的搞建設该面，但是告警泛濫的時候我們要學會過濾夭苗。

5.理清監(jiān)控對象與指標的關系

騰訊業(yè)務要監(jiān)控的對象如左圖，按照業(yè)務邏輯從下往上隔缀，下面是通用的監(jiān)控層面题造，網(wǎng)絡、服務器猾瘸、虛擬化還有應用界赔，應用包括了組件的一些監(jiān)控。

這里舉了申請QQ號的業(yè)務場景案例牵触，假設用戶在PC端發(fā)起申請QQ號的業(yè)務請求仔蝌，請求走到WEB前端，而后是注冊服務荒吏，注冊QQ包含了三個信息：個人信息敛惊、個性化的設置、增值服務绰更。

基于立體化的監(jiān)控瞧挤，假設用組件的監(jiān)控，無論是QQ還是QQ空間儡湾、QQ音樂特恬，都有一些通用的指標可以衡量。如徐钠，打開的內存是多少癌刽？長連接數(shù)是多少？用戶進程、吞吐量显拜、流量衡奥、CPU，業(yè)務層面返回碼的分別是什么远荠？省市連接的成功率矮固、請求量的分布是什么？這都與具體的業(yè)務邏輯無關譬淳。

為了理清海量的監(jiān)控數(shù)據(jù)档址，我們把指標劃分成兩大類：

低層次指標。把公共的邻梆、基礎設施等在業(yè)務邏輯之下的指標稱之為低層次的指標守伸，網(wǎng)絡、硬件浦妄、虛擬化等含友。低層次指標可以通過自動化運維體系實現(xiàn)告警的自動處理與恢復，也是業(yè)內常聽到的故障自愈校辩。

高層次指標。高層次的指標要能更直接的反饋業(yè)務可用性的情況辆童，如成功率宜咒、延時、請求率等把鉴。高層次指標在信息爆炸的時代故黑，能清晰的說明問題點，但倘若要排障還是有可能需要分析低層次的指標庭砍。

越基礎的低層次的指標會給讓監(jiān)控系統(tǒng)或者是告警帶來的噪音越大的场晶，在規(guī)劃監(jiān)控處理或者優(yōu)化監(jiān)控策略時，要盡量把低層次的指標自動化處理或收斂掉怠缸，盡量以高緯度的指標來告警诗轻，因為這才是最核心需要關注的，也是最能反饋業(yè)務可用性的揭北。如果某個運維團隊還在因低層次指標的故障而疲于救火扳炬，是很難全局管控好業(yè)務質量的。

高層次的指標搔体，是要能夠實時反饋業(yè)務的真實狀況的恨樟。以騰訊經驗為例，在海量規(guī)模的業(yè)務運維場景下疚俱，靠人沒辦法看到單機的層面劝术，必須要看到集群的層面。以織云運維理念舉例，CMDB將模塊作為統(tǒng)一的運維對象养晋，模塊是提供單一業(yè)務功能的集群衬吆。為什么要管理到集群呢？簡單的理解就是把運維對象做抽象匙握，做減法咆槽。在SNG業(yè)務體量下，有10萬+的服務器圈纺，抽象成模塊后只有一萬多個模塊秦忿，相當于以前面對10萬個運維對象的N個指標的告警量，現(xiàn)在面對一萬個模塊告警量要輕松不少蛾娶。再把低層次的告警優(yōu)化掉灯谣，可能只面對5000臺的告警了。

在高層次指標中蛔琅，還要有效的區(qū)分開單服務的高層次的指標胎许，和業(yè)務功能的高層次的指標。我們要先理清兩個概念罗售，可靠性和可用性辜窑。

可靠性是指單個服務失敗的次數(shù)，由于單個服務的失敗并不一定會影響整個申請QQ號業(yè)務功能的可用性的下降寨躁，因為微服務自身有失敗重試的邏輯穆碎，在騰訊的運維經驗中，我們會在可靠性和可用性之間做出一定取舍职恳。

低層次的指標雖然比較基礎或者可以自動化的解決所禀，但往往是一些高層次指標的根源的問題，善用這些低層次的指標能夠幫助運維快速的定位高層次指標的故障原因放钦。

6.看清監(jiān)控的本質

那么我們可以看清監(jiān)控的本質色徘，無非就是收集和計算得到一些值和率，通過一定的分析策略或算法操禀，然后把結論以不同的形式展現(xiàn)褂策，最終達到分析狀態(tài)和發(fā)現(xiàn)異常的目標。（把值和率分開是有考慮的颓屑，因為值報上來就是一個值了辙培，率是經過一定的計算才變成率的，其實都是把扁平化的信息包裝成高層次的指標邢锯。）

7.海量運營監(jiān)控需要強調信息的有效性

立體化的監(jiān)控扬蕊，會帶來監(jiān)控指標的爆炸，更有可能帶來告警數(shù)據(jù)的失控丹擎，如果不能妥善處理尾抑，就會把告警通知演變成“狼來了”歇父，失去了原來警報的效用。要有效的解決告警多再愈、誤告警多我們要面對幾點：

1.關聯(lián)分析榜苫。把一些真正重要的，需要通過事件翎冲、活動垂睬、指標提取出來。希望不要把什么事情都告警出來抗悍，而過多的消耗告警的誠信驹饺。

2.無誤告警。怎么樣把收斂策略缴渊、屏蔽的策略用到極致赏壹，必要時可以將兩者組合，以達到更強化的效果衔沼。

3.持續(xù)運營蝌借。做好持續(xù)運營就是做好跟進，為了保證重要的事情有人跟指蚁、有人度量菩佑，防止問題再三出現(xiàn)，要在流程上有保障的機制凝化。這樣就要求我們有一個質量體系來閉環(huán)管理稍坯，當監(jiān)控發(fā)現(xiàn)業(yè)務架構不合理、代碼不合理等問題缘圈，能夠通過該質量體系，推動業(yè)務袜蚕、開發(fā)糟把、運維去將優(yōu)化措施落地，這也是為了最終的商業(yè)價值牲剃，這是DevOps的觀點遣疯。

8.一個多維分析的監(jiān)控案例

一起看個小案例：扼殺真相的“結論”。

這是手機Qzone的一個多維監(jiān)控案例凿傅。當客戶端第一次連接服務端缠犀，會有一個心跳包，它是一個命令字聪舒，我們以成功率來度量其質量辨液，其實就是考量它維持長連接的可靠性。（如果長連接斷開移動客戶端連服務端的話要跟基站建立長連接箱残，起碼3滔迈、4秒耗掉了止吁，好友消息沒有辦法接收。）如圖燎悍，一般的功能敬惦，我們要求三個9的質量。但是千萬別被平均數(shù)所蒙騙了谈山，我們一起展開看看真實的情況俄删。

騰訊的服務是多地多活的，有一些分布在規(guī)模相對小的AC點奏路，有些分布在比較大的DC點畴椰。根據(jù)全國用戶訪問的服務端的點的不同，騰訊內部稱之為SET思劳。講平均數(shù)按SET的緯度展開迅矛，為什么“無SET”的成功率只有2個9？再展開一下潜叛。

按APN（接入方式wifi秽褒、4G、3G等）展開威兜，服務質量越來越差销斟，只有兩個綠了，你會4G是100%椒舵，wifi的環(huán)境為什么只有兩個9了蚂踊？

按運營商展開，質量數(shù)據(jù)更紅（差）了笔宿，雖然符合預期犁钟，但最終的問題還沒有找到。

繼續(xù)按地區(qū)展開泼橘，發(fā)現(xiàn)全是紅的涝动，但還是沒有頭緒。

當再次按地域展開時炬灭，展開到浙江地區(qū)醋粟，我們發(fā)現(xiàn)出錯的全是安卓的版本。而IOS的版本重归，全是100%的成功率米愿，共性問題呼之欲出？

倘若我們在第三步的時候直接展開鼻吮，真相就已經出來了育苟，其實是安卓的某幾個版本，可能有這樣的隱患椎木，導致我們這個心跳邏輯有問題宙搬。

這里說明一個問題笨腥，我們對待海量的多維數(shù)據(jù)的處理，分析方案很重要勇垛，在我們規(guī)劃和建設監(jiān)控體系時脖母，應該考慮好這點。今天給大家?guī)砹?個小技巧闲孤，希望能給大家在做監(jiān)控數(shù)據(jù)分析時有幫助谆级。

9.對海量數(shù)據(jù)的分析需要有技巧

為此我們得出海量監(jiān)控數(shù)據(jù)分析的3個小技巧：

- 溯源

- 根因

- 優(yōu)選

為了加快告警信息量的處理往往把監(jiān)控的協(xié)議格式化，格式化處理完了之后進一步的格式化讼积，把很多原始數(shù)據(jù)的蛛絲馬跡丟掉了肥照，導致沒有辦法查到真正的問題。因為之前做的格式化會讓監(jiān)控數(shù)據(jù)失真勤众，影響排障的效率舆绎，所以上報協(xié)議的時候盡可能的保留字段。

10.溯源分析實踐簡介

先談談溯源：

高緯與降維打擊们颜。高維與降維打擊吕朵，把一個指標的結果值或率以不同的緯度展開，要把每一個緯度的指標組合的狀態(tài)異常都變成告警窥突，這是很不現(xiàn)實的努溃，因為壓根處理不過來。反而多維度的指標異常能通過日常的報表匯總分析就能發(fā)現(xiàn)的異常阻问，然后通過考核去持續(xù)的推動梧税，把異常指標給理順、優(yōu)化掉称近，這是就是高維第队、降維的打擊。

級聯(lián)分析刨秆。網(wǎng)絡有一個詞叫微突發(fā)凳谦，網(wǎng)絡突然擁塞了，導致一大波低層次和高層次的告警產生坛善。舉個案例晾蜘，一個交換機異常邻眷，引發(fā)下聯(lián)的服務器爆炸式的告警眠屎，當此類情況發(fā)生，我們的統(tǒng)一告警平臺全部不理肆饶，做好全局的收斂改衩，以保證監(jiān)控告警的有效性不受影響。

逆向思維驯镊。意思是不能只看結果數(shù)據(jù)葫督，要回到原始數(shù)據(jù)來看竭鞍。如果要做到逆向思維可生效，那流處理集群在真正加工完橄镜，存儲的結果數(shù)據(jù)之前要做最基礎的清晰偎快，把那部分日志備份到大數(shù)據(jù)平臺做離線的計算，然后結果數(shù)據(jù)再走正常的流洽胶，去做告警也好晒夹，異常波動也好，因為很多異常的東西必須要看到原始數(shù)據(jù)姊氓。我們曾經深入分析相冊的日上傳照片流水日志丐怯，找到了大量異常的用戶照片，從而節(jié)省了大量的運營成本翔横，這些都是結果數(shù)據(jù)無法做到的效果读跷。

11.根因分析實踐簡介

再看根因分析：

用高層次的告警收斂低層次的告警。同一個集群下既產生了低層次的告警禾唁，又產生了高層次的告警效览，低層次的告警不用發(fā)。

用主調的告警收斂被調的告警蟀俊。模塊A調用模塊B钦铺，B掛了，A受不受影響肢预？從保障業(yè)務可用性的角度矛洞，如果A沒有產生告警，證明該場景只是B的可靠性告警烫映，告警通知開發(fā)而不是運維沼本。但如果B掛了，A也產生了告警锭沟，運維就應該收到A的告警抽兆，B還是告警給開發(fā)。推進告警分級（分值族淮、分級辫红、分人、分通道）的機制祝辣，其實是慢慢把一些運維要做的事情分給開發(fā)贴妻，運維只看核心的，軟件可靠性這些開發(fā)來看蝙斜，可靠性是開發(fā)的問題名惩，可用性是運營質量的問題。

用原因告警收斂現(xiàn)象告警孕荠。在業(yè)務邏輯的調用聯(lián)調中娩鹉，用原因告警收斂掉現(xiàn)象告警攻谁。（具體可參考2016年3月深圳運維大會上，我關于監(jiān)控的分享PPT）弯予。

用主動觸發(fā)的活動去屏蔽一個對象的告警戚宦。有些告警是由于變更的行為引起的，要收斂掉锈嫩。如正在做升級引發(fā)了告警阁苞，運維系統(tǒng)要能關聯(lián)這些事件與告警。有高層次的告警祠挫、低層次的告警那槽，還有運維的活動事件，都把這些集中在一起等舔，通過權重的算法骚灸，有一個排序決策說告警應該是告這條鏈路，而不是每一個對象都重復的告警慌植。

12.優(yōu)選指標實踐簡介

最后甚牲，是優(yōu)選指標DLP：

核心指標論。騰訊內部的系統(tǒng)代號叫DLP蝶柿，是一種通過人工來篩選核心指標的方法丈钙。舉例，一個模塊可能有300－400個指標交汤，這300－400個指標中雏赦，包含有低層次的指標，高層次的指標芙扎，但當這個模塊出問題的時候星岗，這300－400個指標可能都會產生告警芙委，那么應該怎么樣收斂呢锹杈？倘若我們提前已經對該模塊進行過核心指標的人工篩選拒炎，這個指標能代表模塊最真實的指標弱恒。

監(jiān)控的相關性。監(jiān)控與監(jiān)控之間是相關的袍榆，例如300個指標告警了最岗，最核心的那個也會告警烙常，最核心的告警了這300個指標可以不告警磷蜀，只看核心的就可以了召耘，為什么要人手選核心指標，因為暫時沒有辦法人工識別蠕搜。

告警分級管理怎茫。可以基于核心的指標對告警做分級收壕，非核心的開發(fā)自己收妓灌，核心的運維收轨蛤，高規(guī)格保障。

降低流試監(jiān)控的計算量虫埂。監(jiān)控點越多祥山，流的數(shù)據(jù)越大，整個監(jiān)控流處理集群規(guī)模很大掉伏，10萬臺機器光是流處理的集群都是接近1500臺缝呕，當運營成本壓力大時，我們也可以重點的保障DLP的指標的優(yōu)先計算資源斧散，保證優(yōu)先給予容量的支持供常。

13.織云用戶輿情監(jiān)控簡介

除上述介紹的監(jiān)控指標外，還有一個很核心的指標鸡捐，就是織云用戶輿情監(jiān)控系統(tǒng)栈暇。簡單的介紹這個系統(tǒng)，用戶輿情監(jiān)控顧名思義就是監(jiān)控用戶的聲音和反饋箍镜。用戶的意見反饋來源可以分幾部分源祈，一是appstore的入口，另一個是app內嵌的反饋入口色迂，還有的就是騰訊的用戶反饋論壇香缺，所有的數(shù)據(jù)都會被匯集到織云輿情監(jiān)控平臺上，然后通過機器學習實現(xiàn)自動分類歇僧。系統(tǒng)會把類似“QQ空間打不開”图张、“QQ空間不用好”等這些詞匯進行語意分析和歸類，然后統(tǒng)一告警成“QQ空間異痴┖罚”埂淮，時間間隔是15分鐘顆粒度。（技術細節(jié)可以參考我在2016年在北京TOP100大會上的分享主題写隶。）

當實現(xiàn)了用戶輿情監(jiān)控后倔撞，我們基本有把握說業(yè)務的監(jiān)控360度無死角的（假設用戶都會反饋問題，且不考慮時間因素:P）慕趴。這套監(jiān)控先天就有門檻痪蝇，因為要基于用戶的主動反饋行為，同時需要較多的用戶反饋數(shù)據(jù)量冕房，因為騰訊的用戶量基數(shù)很大躏啰，用戶主動反饋的量也很大。同時耙册，輿情監(jiān)控可以用于監(jiān)控技術上的質量問題给僵，也能用于監(jiān)控產品的體驗或交互問題。

14.監(jiān)控告警的策略與自愈

告警自動化處理的前提是標準化運維體系，在SNG織云監(jiān)控體系下帝际，所有告警處理會先經過預處理策略蔓同，然后再經過統(tǒng)一告警平臺的策略和算法，最終才被決策會否發(fā)出蹲诀。

15.常用算法與策略簡介

在定義指標狀態(tài)異常時斑粱，我們的經驗是盡量不要用固定閥值，要用也是動態(tài)閥值脯爪，否則在監(jiān)控對象的閥值管理上就會有大量的人工管理的成本则北。其他的推薦策略如圖。

16.常見監(jiān)控圖形與策略

我們在日常運維工作中痕慢，面對的監(jiān)控的圖形就如上圖尚揣，趨勢有小波動、毛刺掖举、無規(guī)律的惑艇，建議大家有針對性的套用監(jiān)控策略，讓監(jiān)控告警更精準拇泛。

17.監(jiān)控資源案例

分享一個織云監(jiān)控實現(xiàn)進程自愈的案例滨巴，流程中的模塊在部署時，運維自動化流程就會把進程和端口的信息注冊到CMDB中俺叭，然后監(jiān)控服務會讀取該模塊需要監(jiān)控的進程與端口信息恭取，并把監(jiān)控配置發(fā)送每臺機器的監(jiān)控agent上，本地的監(jiān)控agent通過定時的ps檢測進程和端口的運行情況熄守，如果發(fā)生異常蜈垮，則自動通過標準化的管理找到啟動的命令啟動，如果啟動成功便實現(xiàn)了進程自愈裕照。如果啟動不了發(fā)給統(tǒng)一告警平臺攒发，統(tǒng)一告警平臺來決策是否需要告警。當該告警原因是因為基礎設施正在做變更影響時晋南，也不會發(fā)出告警惠猿。一系列的監(jiān)控自愈的方案都是構建在織云的自動化運維體系中的，詳情可以參考以前織云的相關技術分享负间。

18.常用收斂算法簡介

毛刺收斂偶妖。在織云監(jiān)控中，我們的告警策略為了防止毛刺的影響政溃，會將告警策略定義為10分鐘發(fā)生3次類似的模式趾访。

同類收斂。一個模塊有300個監(jiān)控實力董虱，產生了300條的告警扼鞋，只要有一條告給運維，對于運維同類收斂掉了。

時間收斂云头。生產環(huán)境中有很多定時的任務捐友，如定時跑批會引起I/O的陡增等異常，這種可以針對性的收斂掉盘寡。

晝夜收斂。有一些告警撮慨，在分布式服務的高可用架構下竿痰，晚上不需要告警出來，可以等白天才告警砌溺，更人性化的管理影涉。

變更收斂。如果告警的時間點有運維的活動规伐，就要收斂掉它蟹倾。怎么做到的？取決于要把運維的活動都收口在標準化運維的平臺猖闪，運維平臺對生產環(huán)節(jié)都要講變更日志寫入在變更記錄中心那里鲜棠，然后統(tǒng)一告警系統(tǒng)能夠關聯(lián)變更記錄來決策是收斂還是發(fā)出告警。

19.織云監(jiān)控的指標體系

織云監(jiān)控構建的質量體系培慌，分成用戶端豁陆、客戶端、服務端吵护、基礎端盒音，定義核心指標DLP，并且善用分級告警馅而、分渠道告警祥诽，結合短信、QQ瓮恭、微信和電話等渠道實現(xiàn)告警通知雄坪，整個質量監(jiān)控體系都是圍繞預警、自愈屯蹦、分析诸衔、排障礙的能力構建。

20.織云監(jiān)控的質量體系

小結織云監(jiān)控的質量體系颇玷，我們希望打造一個閉環(huán)笨农，能夠實現(xiàn)持續(xù)反饋、度量帖渠、優(yōu)化谒亦，讓團隊間能夠有效的協(xié)同工作，更高效更有效。

監(jiān)控能力份招。全局的看切揭、需要什么樣的監(jiān)控能力和監(jiān)控點，同時要理清指標是怎么分層的锁摔，哪些指標是重要的廓旬？最終把它轉成業(yè)務看得懂的高層次指標。

業(yè)務可用性谐腰。運維要看什么孕豹，要看可靠性還是可用性，如果規(guī)模不大看可靠性可以十气，但是在海量的場景下可靠性要太細励背，要抽象核心指標來度量，用于衡量可用性砸西∫睹迹可靠性則可以通過考核體系去度量與管理，結合QA和老板的力量來推動開發(fā)團隊的投入與優(yōu)化芹枷。

用戶體驗衅疙。做技術運營會有視角的盲點，會經常迷戀可用性的數(shù)據(jù)是4個9鸳慈、5個9炼蛤，但這并不完全代表了我們服務質量好，當用戶連接不上我們的服務端時蝶涩，幾個9的意義都不大理朋。這是一個很現(xiàn)實的問題，因此用戶體驗監(jiān)控一定要做绿聘，因為內部的可用性再高都不代表用戶用得好嗽上。

技術解決。要有技術解決的方案熄攘，要有自動化的工具兽愤，有協(xié)助用戶排障的工具，有根因分析的算法平臺等等挪圾。

統(tǒng)計分析浅萧。最終形成可度量的指標、可考核的哲思、可展示的洼畅，最好是DIY展示的，監(jiān)控數(shù)據(jù)的統(tǒng)計/報表能力服務化棚赔，應發(fā)揮更多的角色來使用監(jiān)控數(shù)據(jù)帝簇，而非僅限于運維角色徘郭。

持續(xù)改進。最終持續(xù)的改進無論是架構的問題丧肴、代碼的問題残揉，還是因為標準化的問題或非功能落地推進不了的問題，都是需要數(shù)字來度量和推動芋浮。最好抱环，這個數(shù)字要能間接的反饋商業(yè)的價值，也就是DevOps提倡的思路纸巷。

最后镇草，質量體系肯定是反作用于監(jiān)控能力再去形成這樣的閉環(huán)，跟開發(fā)怎么溝通何暇？跟產品怎么溝通陶夜？跟QA凛驮、跟客服怎么溝通裆站？要把他們用起來，要把他們關注的點牽引住黔夭，最終落到運維想實現(xiàn)的目標上是最好的宏胯，這很DevOps，也撬動老板的思維本姥，爭取從上而下的支持做好質量體系的建設肩袍。

我們經常說DevOps很難落地，為什么難婚惫？因為我們總是想要去影響老板氛赐，先改變文化再改變工作方法，但這談何容易先舷。如果是運維和開發(fā)能聯(lián)合起來艰管，先從小的重點的業(yè)務抓起，用數(shù)據(jù)說話體現(xiàn)DevOps能給業(yè)務帶來的最終的商業(yè)價值蒋川，說不定會起到事半功倍的效果牲芋。

今天的分享就到這里，謝謝大家捺球！