《業務高速發展的運維困局，如何保證系統穩定性？》要點：
本文介紹了業務高速發展的運維困局，如何保證系統穩定性？，希望對您有用。如果有疑問，可以聯系我們。

業務高速發展背后的困局 ?

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

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

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

問題出在哪里 ?

拋出這些問題,我們再透過問題逐一看看它背后的實質是什么?

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

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

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

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

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

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

問題的破解之道 ?

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

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

明確了一系列關鍵指標后,再從中提取最為關鍵的 1~3 項.為什么還要再次提取呢?

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

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

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

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

寫在最后 ?

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

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

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

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/3760.html