[[340220]]

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

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

根據(jù)痛點，創(chuàng)建實用標準

在運營時，為了避免陷入海量卻有無用的信息陷阱中，我們需要事先設(shè)計好準確的儀表板和監(jiān)控指標。以下便是運營與基礎(chǔ)架構(gòu)團隊經(jīng)常遇到各種痛點和挑戰(zhàn)。

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

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

健康運營的關(guān)鍵指標

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

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

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

標準成熟度模型

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

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

可見，領(lǐng)導者級別是無法一蹴而就的，運營團隊需要從目標系統(tǒng)的細微處入手，循序漸進地建立恰當?shù)谋O(jiān)控與處置標準。下面，我們來共同研究一個典型案例。

案例研究

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

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

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

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

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

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

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

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