[[340220]]

【51CTO.com快譯】最近，我們通過針對一些企業內各個運營團隊與工程師開展了一項調查。我們發現：大約有70%的受訪者會使用MTTA(Mean Time To Answer，平均應答時間)和MTTR(Mean time to Repair，平均響應時間)作為主要運營能力的指標之一;而20%的受訪者關注的是計劃內與計劃外的工作占比;還有10%的受訪者則表示他們并無既定的衡量標準。當然，在實際運營過程中，光靠MTTA和MTTR是遠遠不夠的。隨著系統復雜性的增加，我們需要對各項服務的運行狀況獲取更加充分的了解。

下面，我們將和您在健康運營的過程中，企業所面臨的各項挑戰、痛點、以及需要衡量的各項關鍵指標。在此基礎上，我們會進一步給出一個標準成熟度模型，以及對應的實踐案例。

根據痛點，創建實用標準

在運營時，為了避免陷入海量卻有無用的信息陷阱中，我們需要事先設計好準確的儀表板和監控指標。以下便是運營與基礎架構團隊經常遇到各種痛點和挑戰。

• 數據不足：我們的APM(應用平臺管理)、派單、運營聊天工具等平臺，都會分散地產生不同類型的數據。同時，由于不同團隊各司其職、各自為政，因此數據孤島的現象在企業中屢見不鮮。
• 缺乏反饋：各種發生過或正在發生的事件，無法相互聯系與關聯，無法反饋給后續的行動。運營團隊疲于應付各種計劃外的事故。
• 標準缺失：傳統的APM和分析工具雖然功能強大，但是由于缺乏針對目標系統所制定的具體標準與規范，因此運營團隊難以使用這些工具，達到預期的效果。
• 千篇一律：有時候，某些數據能夠對一個團隊非常實用，并不一定對另一個團隊也有用。因此，我們需要在不同的場景中監控不同的數據指標，不可千篇一律。

那么基于上述痛點，我們該制定哪些關鍵性運營標準呢?

健康運營的關鍵指標

顯然對于由系統產生的紛繁復雜的各類數據，我們并非只是為了監控而進行獲取。我們需要確保在充分了解其所處上下文環境的基礎上，合理進行選擇，按需進行調整，以提高運營團隊的能力與效率。如下是各個企業，特別是落地了DevOps的企業最常用的一些監控指標，您可以根據實際情況酌情進行選擇：

• 速度
  • 它是最常用、最普遍且值得監控和衡量的指標之一。
  • 對應的KPI包括：沖刺能力的規劃，以及團隊將新功能推入生產環境的速度。
• 可用性
  • 系統在給定時間內正常運行的占比。
  • 對應的KPI包括：了解本系統和團隊能夠從事故或中斷中恢復正常的能力。
• 工程時間
  • 由于系統的不穩定性，導致團隊運營效率低下的耗時。
  • 對應的KPI包括：減少擁塞，提高自動化。
• 產品質量和客戶滿意度
  • 了解客戶的滿意水平。
  • 對應的KPI包括：了解用戶的關鍵服務水平目標(Service Level Object，SLO)狀態，反應式事件響應(reactive incident response)等。

值得注意的是，如果單獨地去考量上述指標中的某一項，我們可能會被誤導。例如，表面上看，那些部署能力高的團隊似乎會比部署效率低下的團隊更成功。但是，如果效率高的團隊自身反而失敗率或錯誤率也高的話，那就不能簡單地將其認定為成功了。因此，我們需要花一些時間，弄清楚與每項指標相關的上下文環境。進而在此基礎上，為每個團隊或組織建立不同的標準成熟度模型級別。

標準成熟度模型

我們可以通過如下成熟度模型，來描述從脆弱到該領域的領導者，這種不斷成長和提升的變化過程。下面是每個檔次的不同關鍵特征：

• 脆弱(Fragile)：目前，大多數企業和團隊都處于該成熟度層次上，他們雖然在運營中有一定的響應能力，但是也時常倍感壓力。在這個脫離了上下文環境的階段中，團隊主要著眼于事件數量、或派單數量。例如：在單位時間內產生的50個事件，看似比40個事件的絕對數量要大。但是，如果團隊對于那50個事件中的絕大多數都能夠擁有預案，而且可以快速解決，那么這50個事件實際所造成的影響其實并不大。此外，由于沒有明確的參考與分級標準，團隊可能會將大多數事件都界定為高嚴重等級，進而動輒耗費大量的人力、物力、乃至于時間去處理。
• 統一(Unified)：在該級別上，團隊可能會按照類型和既定的標簽對事件進行分類，從而有的放矢地對各類事件予以處置。同時，隨著那些突發事件的可見度增加，團隊既能夠不斷地改進既有的事件分類和處置能力，又能夠集中精力去解決那些計劃外的嚴重事故(通常占比為30-50%)。
• 優勢(Advantage)：處于該成熟度級別的團隊，擁有更高級的SLO和相關指標，能夠前攝性地預防各類事故所帶來的影響。為了權衡數據驅動所要求的服務質量，他們需要讓系統平穩地提供各項功能的同時，確保整體的可靠性。其中，更加成熟的團隊還能夠通過更小、更頻繁的變更，更好地定位和限制事故的影響半徑，進而讓那些計劃外的處理工作的占比少于30%。
• 領導者(Leader)：目前，只有不到1%的企業能夠達到這種成熟度水平。其特點在于擁有各項高級實踐，例如：通過適當的服務降級、或自身容錯功能，以應對那些大規模的意外事件所造成的影響。因此，他們能夠將主要精力專注于解決那些占比少于20%計劃外的嚴重事故上。

可見，領導者級別是無法一蹴而就的，運營團隊需要從目標系統的細微處入手，循序漸進地建立恰當的監控與處置標準。下面，我們來共同研究一個典型案例。

案例研究

2019年初，一家全球性電商公司的運營團隊開始從那些最基礎的關鍵性指標入手，其中包括：花費在事件處理上的時間，事件嚴重性級別的劃分，以及區分何為計劃內的工作(即功能性的)、何為計劃外的工作(如：事件與錯誤)等。

通過半年的時間，他們建立了堅實的基準性指標，并從中了解到各項指標數據的發展趨勢和改進機會。據此，他們發現：整個團隊總工程時間的45%被花費在了計劃外的工作上，這相當于每月額外消耗了20萬美元。其中，主要事件都集中在產品頁面上的各個處理流程中，包括：頁面加載時間和故障排查時間等。

有了這些數據，他們開始進行深入分類，以分析出到底是什么導致了用戶訂單流程出現了問題。通過進一步的調查，他們認定這些錯誤與某個第三者反欺詐服務，以及支付商的數據庫標簽和API有關。

2020年第一季度，該運營團隊進行了如下重點改進：

• 重寫了數據庫的查詢和索引，以提高數據質量和系統性能。
• 改進了API的連接處理和錯誤處理方式。
• 替換了其中的一個反欺詐服務提供商。
• 修改了CDN的提供程序，以提高動態對象的加載速度，并增加靜態對象的TTL。

在2020年第一季度之后，團隊再次進行了評估與衡量。他們發現：在用戶使用流程(如：產品頁面和支付結算流程)上的事件數量減少了76%;在計劃外事故上花費的總工程時間占比下降了40%。盡管這并非他們健康運營的終點，但的確是一個很好的開端。

原標題：Here Are the Metrics you Need to Understand Operational Health，作者: Hannah Culver

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】