[[340220]]

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

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

根據(jù)痛點(diǎn)，創(chuàng)建實(shí)用標(biāo)準(zhǔn)

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

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

那么基于上述痛點(diǎn)，我們該制定哪些關(guān)鍵性運(yùn)營標(biāo)準(zhǔn)呢?

健康運(yùn)營的關(guān)鍵指標(biāo)

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

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

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

標(biāo)準(zhǔn)成熟度模型

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

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

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

案例研究

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

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

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

2020年第一季度，該運(yùn)營團(tuán)隊(duì)進(jìn)行了如下重點(diǎn)改進(jìn)：

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

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

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

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