業務高速發展背後的困局  

隨著業務的快速發展，運維體系也逐步的完善起來。業務的穩定性和服務質量也在監控、可用性等體系的相互環抱下健康地成長。所有的問題、故障及影響穩定性的因素都在可控、可收斂的範圍內，一切都向著好的方向發展。

這一切的背後真的和看起來一樣美好嗎？實則不然，業務的高速發展勢必會留下種種隱患和問題。想想你是否也被類似的種種問題困擾著：

• 1. 監控報警通知的噪音太大，正常的報警通道被人為擁塞，實際閱讀率極低；是不是很熟悉？試想如果一個非常重要的業務監控報警被這樣淹沒，而被人為的忽略，後果作為運維的你會不會後背一身冷汗？除了對監控進行分層、精簡監控報警外，我們還能做些什麼？
• 2. 業務資料出現異常，但報警、可用性資料卻一直處在正常狀態；
  面對前端業務同學「為什麼監控沒有發現？」的指責，除了說一句「對不起，下次改進提升」。我們還能做些什麼？
• 3. 出現報警、可用性異常波動情況，但業務指標並沒有明顯波動。為了解決這個問題，明明是對業務非常有幫助的改進，但業務同學就是不理解，不支援。除了滿滿的無力感外，我們還能做些什麼？
• 4. ……

問題出在哪裡  

丟擲這些問題，我們再透過問題逐一看看它背後的實質是什麼？

它的根本原因還是我們採用了通過廣佈點、高覆蓋等方式並加以「查漏補缺」的方法來儘可能地減少因為監控點缺失而導致的業務異常時監控漏報的情況。

對，沒錯。初衷是好的，但結果往往事與願違。特別是在監控點數量及業務複雜度不斷提高時，由此監控報警帶來的資訊噪音就會越來越大。當報警資訊量達到一個臨界點時，所有的報警都將成為噪音甚至汙染。而監控報警系統的用途也會在達到這個臨界點後，像「多米諾骨牌」一樣瞬間垮掉，走向另一方向的無底深淵。

從實際的情況來看，情況可能並不樂觀。經常會出現運維與業務同學在對標、討論問題時，大家都是在相互「雞同鴨講，不知所云」。

對，或許問題的根結就在這裡。我們做的大量監控是否能對業務指標的穩定及提升起到正向的幫助呢？

特別上述第 2、3 點提到的情況從根本上講就是 運維與業務同學沒有在同一語境導致的。 一邊是業務資料導向思維，一邊是技術資料導向思維。

當然不是了，「業務大盤」就是在這種環境和情況下應運而生。「業務大盤」並不單單是一個工具、報表或平臺，它是一種基於業務關鍵指標為導向的技術化驅動思維方式，讓運維及業務等多方在相同語境下溝通的方法。

問題的破解之道  

首先，運維同學需要去轉變思路，站到業務方的立場上去考慮問題。 拋開所有的技術指標不談，先與業務同學進行嘗試溝通，瞭解他們最關心的指標是什麼？

• 以 Web 類業務為例，業務同學最關心的可能是 UV、PV、首頁開啟時長等；
• 以電商類業務為例，業務同學最關心的可能是交易轉換率，交易成功率等；
• 以發行類業務為例，業務同學最關心的可能是下載轉換率，次日留存率等；
• ……

明確了一系列關鍵指標後，再從中提取最為關鍵的 1~3 項。為什麼還要再次提取呢？

因為 業務的關鍵、核心路徑很重要，避免什麼指標都去關注，結果就是什麼都關注不到位的情況出現。

明確了關鍵指標後，我們再按照可用性體系的方法對關鍵指標進行建設。除了關鍵業務指標外，我們同時需要從以下幾個緯度進行分析：

• 基線及範圍：即關鍵業務指標的預設的基準值及活動閾值。以基線為中心，在活動閾值範圍內的預期波動為正常。跳出活動閾值範圍的即為異常。
• 環比：即關鍵業務指標同一時間週期及上一時間週期數據進行比較。比如，17 點22 的結果與 17 點 21 分的結果進行對比。如結果波動在閾值範圍內即為正常，反之為異常。
• 同比：即關鍵業務指標在兩個時間週期內相同時間點的比較。比如，4 月 25 日的17 點 01 分的結果，與 4 月 24 日的 17 點 01 分的結果進行對比。如結果波動在閾值範圍內即為正常，反之為異常。

為了減少解決誤報的情況，可以結合環比、同比，甚至基線指標綜合使用。

寫在最後  

有了相應的「業務大盤」指標資料結果後，因為是 基於業務核心指標為導向，就更容易將運維及業務相關同學放到同一語境下進行溝通，所以目標就更加清晰、解決問題的方向也更加聚焦。效率提升也就水道渠成。

當然，只有不斷地與業務同學對標，改進及優化相關的核心指標才能持續地享受「業務大盤」帶來的享受與快感。

基於「業務大盤」，我們是否還可以玩出更多的花樣，以進一步提升業務的穩定性。歡迎關注計劃近期出品的「讓運維穩定性走在業務前面——災備演練」

文章來自微信公眾號：高效運維開發；作者：胡楊