共創共識 相互支撐——小米公司軟件服務端質量提升背后的故事

共創共識 相互支撐

——小米公司軟件服務端質量提升背后的故事

□ 本報記者 彭 燮

大面積宕機、大規模斷網、大量用戶無法訪問……近年來，多家互聯網企業接連發生服務端質量事故。因此，軟件服務端質量保障成為各企業關注的重點項目，小米公司也不例外。

服務端被稱為軟件系統的“基礎設施”，一旦出現故障，會給業務端帶來很大負面影響。但由于其自身的復雜性以及軟件開發的隨機復雜性，服務端“零故障”在現有條件下是不可能實現的。因此，作為一家服務全球數億用戶的移動互聯網公司，小米公司能做的就是，盡可能降低服務端質量事故發生的概率，以及在事故發生后，盡可能減少對用戶的負面影響。

這也是小米公司軟件服務端質量提升專項（以下簡稱“專項”）的目標。2023年1月，小米公司由負責基礎服務的集團信息技術部牽頭，聯合4個重點業務部門以及集團質量辦共同成立專項工作組，圍繞10個重點業務和25個核心基礎服務，全力治理軟件服務端的質量風險，目的是夯實基礎服務容災能力，并提升重點業務的逃生能力。

容災和逃生，聽起來像是應對各類災害的專業用語，在專項工作組看來，服務端質量故障，就屬于“技術災害”，提高防災減災救災能力，是小米公司必須要修煉的“內功”。

相互支撐的5毫秒

服務端和業務端共同完成各項互聯網應用技術保障，分工不同，但目標一致。而專項工作組的工作之一就是要加強服務端和業務端的雙向配合。

配合的基礎是共識，在技術上被稱為“SLA握手”，即雙方就基礎服務的具體技術指標達成一致。其難度在于，業務端主要關注業務指標對于提升用戶體驗和質量水平的重要性，而軟件服務端主要從現有能力出發，更多考慮業務指標的提升路徑和相應成本。

專項工作組給記者講述了一個關于“5毫秒”的故事。

5毫秒，對于日常生活來說，是完全可忽略不計的時間。可對于Redis（一個存儲數據庫）日志組件來說，5毫秒卻是目前業界公認的，能實現良好用戶體驗的最短延遲時長。

在軟件服務端質量提升專項實施之前，米家工程師小張并不了解，在小米，其實有兩個5毫秒：一個5毫秒是他所熟悉的，米家相關應用Redis日志延遲時長的標準，盡管延遲超過100毫秒用戶才會明顯感覺到“有點慢”，但米家依然把延遲時長標準定為5毫秒，這也是目前業界公認的最高標準；另一個5毫秒是軟件服務端監測的服務器Redis日志延遲時長，目的也是想給米粉們提供最好的體驗。

可問題是，這兩個5毫秒，并不能劃等號。

小張說，在實際應用中，他們時常發現Redis日志延遲時長達到6-7毫秒，雖然用戶對于多出的1-2毫秒并無感知，但小米的工程師們不會視而不見。他猜想，是不是軟件服務端出了問題？

通過專項，小張發現自己想錯了——軟件服務端的工程師們一直堅守著“5毫秒”的標準，而且從目前技術數據看，基本上不會出現延遲時長達到6-7毫秒的情況。

那問題到底出在哪里呢？

經過雙方工程師的共同排查和數據“拉齊”，他們找到了延時時長增加的原因，小張管它們叫“中間地帶”，包括網絡、云平臺容器等。一般來說，它們會增加1~2毫秒的延遲時長。甚至有一次云平臺容器基礎設施升級，業務端的延遲時長最高超過20毫秒。

問題找到了，那實現“SLA握手”的有兩種方案：一是以業務端的5毫秒為基準，讓軟件服務端把“中間地帶”造成的延遲算進去，進一步縮短延遲；另一種是以軟件服務端的5毫秒為基準，綜合考慮“中間地帶”的因素，業務端適當提高延遲時長標準。

對于小張和同事們來說，第一種方案顯然是最簡便也是最好操作的，因為只需要看好自己業務的數據，就可以保證不出現延遲問題。但最終，他們卻自愿選擇了第二種方案。

“我們覺得，考慮問題不能只想著自己怎么方便怎么來，而是要從集團整體角度來判斷，什么是最優解的。”小張的考慮有兩方面，一是在現有技術條件下，如果要保證業務端的5毫秒，就意味著軟件服務端要把延時控制在3~4毫秒，這需要公司投入巨大成本，投入產出嚴重不成比例；二是對于軟件服務端的同事來說，他們平時主要是著眼于基礎服務，對“中間地帶”的運行原理和相關情況的了解不如業務線多，讓他們去負責排查“中間地帶”的問題，要多花費很多的時間和人力。“這樣做，他們的壓力太大了，不光要管自己，還要管自身以外的一些業務。”小張說。

就這樣，原本是“自說自話”的兩個5毫秒，通過“SLA握手”，雙向奔赴、合二為一。而工程師們也從在一個園區里上班卻少有聯絡的“網友”，變成了互相支持、互相信賴的真朋友。

讓人“上癮”的“噩夢”演練

如果盤點小米工程師的“噩夢”，交換機斷網肯定可以算一件。 一臺交換機斷網已是大事故，更不用說兩臺交換機同時斷網了。然而，就在2023年5月20日凌晨，小米公司近百位工程師共同“圍觀”兩臺交換機同時斷網。那個場面讓軟件服務端運維工程師劉工至今難忘。

為了驗證專項通過推進“SLA握手”提升災備能力的成效，提升各業務端和軟件服務端的協調作戰能力，工作組先后組織了4場集團級別的應急有損演練——幾乎輻射小米所有業務線。作為應急演練的具體負責人，劉工用“糾結”兩個字來形容自己當時的心情。

讓人糾結的點在于，因為是有損演練，萬一演練過程中引發了更大的問題，波及的用戶數量可能是數以億計的。“雖然公司不追責，但怎么和米粉們交代呢？”劉工記得，有位業務工程師曾質問他：“干嘛非要搞個事出來！”

“沒事找事”的背后，是因為工作組深知，問題不會因為不演練就不發生，與其因為意外情況失控，還不如通過有損演練把預案做好。這就和消防演練對防火工作的重要性一樣。再難也得干！而且他們直接挑戰兩臺交換機同時斷網，這在小米歷史上是從未發生過的。

2023年7月25日凌晨，近百名小米工程師在工作群里集合，之所以選擇這個時間，也是為了盡量減少對用戶可能造成的影響。

“倒計時10分鐘。”

劉工發出第一條指令。各業務線工程師開始按照之前預演過的流程進行準備，監控相關數據。

“倒計時5分鐘。”

劉工發出第二條指令。各業務線工程師再次確認應急預案。相關操作人員進行準備。

“倒計時1分鐘。”

劉工發出第三條指令。這一刻好像空氣都凝固了，群里看似靜悄悄，又仿佛能聽到大家的心跳。

“光纖接口已斷開。”

負責“制造”交換器斷網的工程師在群里發布了最新情況，隨后群里逐漸熱鬧了起來。有的工程師表示，確實如預判的一樣，后臺數據明顯波動，但好在有預案，用戶基本感受不到；有的工程師表示，居然沒有出現預想的問題；有幾位本來是“觀戰”的工程師說，自己的業務后臺數據竟然出現了抖動。

讓人糾結的演練終于結束了，結果令人欣慰——事實證明，軟件服務端質量提升專項確實提升了業務端和服務端的“合力”和災備能力，通過雙方“握手”和數據“拉齊”實現的預防方案，能夠應對突發情況的挑戰。

更讓人欣慰的變化是，這場演練居然讓小米工程師“上癮”了，一些之前觀望的業務線，主動找到工作組要求參與演練；工程師在評估業務量的時候會考慮演練所涉及的容災內容；甚至有些工程師在得知演練沒有發現問題的時候，會感嘆“白演練了”。

實踐證明，故障演練很好地驗收了對前期項目推進的成效，也全面檢驗了各團隊應急響應能力、預案執行效率、系統協同能力。

從“治病”到“治未病”，從“救火”到“防火”，這是專項給小米質量工作帶來的積極變化。雖然推進過程非常艱難且糾結，但正如劉工所說：“我們多糾結一點，用戶選擇小米的心就會更加堅定一些。”

《中國質量報》