有贊移動(dòng)質(zhì)量提升探索與實(shí)踐

在技術(shù)團(tuán)隊(duì)，質(zhì)量的話題相信大家都不陌生。以有贊的業(yè)務(wù)為例，質(zhì)量問題無論是發(fā)生在業(yè)務(wù)上的交易鏈路還是在引流鏈路上，亦或是啟動(dòng)時(shí)的閃退或 loading 時(shí)間過長的性能問題，都會造成我們所服務(wù)的商家經(jīng)營上的低效和 GMV 的流失，導(dǎo)致商家對有贊的技術(shù)能力產(chǎn)生質(zhì)疑和抱怨，最終影響到有贊SaaS服務(wù)的續(xù)費(fèi)率。

但事實(shí)上，質(zhì)量不佳不僅會影響到業(yè)務(wù)和商家，對于技術(shù)團(tuán)隊(duì)自身的影響也不容小覷。

有贊移動(dòng)團(tuán)隊(duì)也曾經(jīng)歷過從0到1快速迭代功能上線而對代碼質(zhì)量重視不足的階段，這些挖下的坑在業(yè)務(wù)快速拓展的過程中帶來了大量的線上問題和故障。線上問題的頻發(fā)會讓整個(gè)團(tuán)隊(duì)陷入一種效率上的惡性循環(huán)：應(yīng)對線上問題會打斷進(jìn)行中的項(xiàng)目進(jìn)度，嚴(yán)重的時(shí)候很多開發(fā)同學(xué)甚至不得不整個(gè)白天都在忙于處理線上問題，到了晚上才有空開始補(bǔ)今天的開發(fā)進(jìn)度。這種情況下不僅會產(chǎn)生加班、延期等顯性的影響，更嚴(yán)重的是技術(shù)方案考慮不周、Code Review不細(xì)致等隱性影響，會進(jìn)一步降低線上代碼的質(zhì)量。這樣的惡性循環(huán)也會讓整個(gè)團(tuán)隊(duì)忙于救火，技術(shù)沉淀和氛圍更加無從談起。

質(zhì)量不佳對于技術(shù)團(tuán)隊(duì)會形成惡性循環(huán)

因此我們深刻的感受到，對于一個(gè)技術(shù)團(tuán)隊(duì)而言，質(zhì)量和穩(wěn)定性其實(shí)是團(tuán)隊(duì)的地基。在好的質(zhì)量基礎(chǔ)上，我們才能更好去追求業(yè)務(wù)上的支撐與推動(dòng)、研發(fā)效能提升、團(tuán)隊(duì)技術(shù)氛圍等其他目標(biāo)。

不同類型的業(yè)務(wù)場景中，對于移動(dòng)端的要求也會有不同的側(cè)重點(diǎn)。有些金融背景的業(yè)務(wù)會對于 app 的安全性要求更高，而另一些電商背景的業(yè)務(wù)可能對于動(dòng)態(tài)能力要求更高，而技術(shù)團(tuán)隊(duì)在質(zhì)量上努力的方向和側(cè)重點(diǎn)都與業(yè)務(wù)特點(diǎn)密切相關(guān)。

那么有贊的業(yè)務(wù)場景中對移動(dòng)端有哪些要求呢？我們歸納成以下兩個(gè)突出的特點(diǎn)：

• 離線的業(yè)務(wù)能力

• 受限的硬件水平。

1、離線的業(yè)務(wù)能力

對于市面上的大部分app，當(dāng)用戶在移動(dòng) app 上操作下單的過程中，移動(dòng)端通常只會負(fù)責(zé)信息的展示和用戶的交互。而訂單金額的營銷計(jì)算（比如某個(gè)商品是否可以用優(yōu)惠券減錢、某個(gè)商品是否在訂單中符合成為贈(zèng)品的條件）、數(shù)據(jù)的校驗(yàn)、訂單的生成這些敏感的業(yè)務(wù)邏輯都會放在后端進(jìn)行處理。

但是在有贊的門店業(yè)務(wù)場景中，我們?yōu)殚T店收銀員開發(fā)的收銀終端 HD 應(yīng)用需要提供離線開單的能力。

這是因?yàn)殚T店場景中面對的是來店的顧客和真實(shí)排在收銀臺前的待付款消費(fèi)者。這種場景要求收銀系統(tǒng)在面臨斷網(wǎng)或者服務(wù)端宕機(jī)的挑戰(zhàn)時(shí)，需要具有本地收銀的能力。如果來店的消費(fèi)者因?yàn)槭浙y系統(tǒng)卡住而離店，那么商家就會蒙受巨大的損失。

門店場景中供門店收銀的HD應(yīng)用

本地去做營銷計(jì)算和訂單生成的要求不僅對于移動(dòng)端本地?cái)?shù)據(jù)緩存能力、數(shù)據(jù)變更及時(shí)性、邏輯復(fù)雜度、數(shù)據(jù)安全性提出了更高要求，在質(zhì)量保障上還帶來了兩點(diǎn)挑戰(zhàn)：

• 營銷計(jì)算中的資損風(fēng)險(xiǎn)

• 問題的及時(shí)修復(fù)能力

營銷計(jì)算中的資損風(fēng)險(xiǎn)：如果移動(dòng)端在創(chuàng)建訂單過程中只負(fù)責(zé)信息展示和用戶點(diǎn)擊操作時(shí)，移動(dòng)端由于自身 bug 導(dǎo)致資損風(fēng)險(xiǎn)的概率是極低的。但是當(dāng)商品的折扣計(jì)算、優(yōu)惠分?jǐn)偂⒔M包拆包、優(yōu)惠疊加互斥邏輯都落在移動(dòng)端本地時(shí)，編碼 bug 導(dǎo)致訂單金額計(jì)算錯(cuò)誤，進(jìn)而導(dǎo)致商家或者消費(fèi)者資損的概率就會直線上升。比如一個(gè)商品并不在商家的限時(shí)折扣活動(dòng)范圍中，但是由于bug導(dǎo)致給這個(gè)商品也打了折扣賣了出去，就會給商家?guī)碣Y損。而資損故障是非常嚴(yán)重的。這就要求我們必須有更嚴(yán)格的機(jī)制去確保核心代碼的L0級穩(wěn)定性。

問題的及時(shí)修復(fù)能力：當(dāng)線上問題可能涉及資損時(shí)，也進(jìn)而會對移動(dòng)端的問題修復(fù)能力提出更高的要求。

就問題修復(fù)及時(shí)性而言，移動(dòng)端相對于前后端有著天然的劣勢。后端或者前端同學(xué)發(fā)現(xiàn)線上問題時(shí)，可以通過回滾做到幾分鐘內(nèi)止血。但移動(dòng)端不可能讓每個(gè)終端卸載重裝老版本，同時(shí)市面上的熱修手段也存在諸多限制。這讓我們不得不對于問題修復(fù)流程中的每個(gè)環(huán)節(jié)做更深入的思考與探索，盡可能在問題發(fā)生時(shí)能夠快速止血，降低影響面。

2、受限的硬件水平

在門店場景中，我們?yōu)殚T店收銀員提供的HD應(yīng)用安卓端是運(yùn)行在收銀機(jī)上的。對于收銀機(jī)的硬件能力，我們可以通過一個(gè)簡單的對比感受一下：

• 商米 T2 收銀機(jī)，也是我們目前客戶中使用率較高的一款設(shè)備，內(nèi)存2G，某電商平臺上售價(jià)3000多元

• 紅米 Note9 手機(jī)，安卓千元機(jī)，內(nèi)存6G，某電商平臺售價(jià)999

  
  

我們拋去 CPU 能力等其他因素，但看內(nèi)存這一項(xiàng)就存在著巨大的差距。有限的內(nèi)存能力，要求我們移動(dòng)技術(shù)同學(xué)不僅在編碼和技術(shù)方案設(shè)計(jì)階段在性能上有更細(xì)致的考量和設(shè)計(jì)，也要求我們對于線上的 app 性能卡頓問題有更強(qiáng)的分析能力和解決能力。

結(jié)合前文提到的有贊業(yè)務(wù)場景的要求，我們著重圍繞以下幾個(gè)命題，思考和探索如何提升移動(dòng)質(zhì)量：

• 如何深度防范資損故障，讓資損的風(fēng)險(xiǎn)盡可能清零？

• 如何體系性的提升移動(dòng)端質(zhì)量，讓線上問題數(shù)量保持在較低的水平？

• 如何搭建完善的性能監(jiān)控體系，全面提升app性能，降低卡頓的發(fā)生？

我們將探索中的心得歸納為以下幾點(diǎn)：

• 主動(dòng)發(fā)現(xiàn)問題

• 更早發(fā)現(xiàn)問題

• 有效的流程機(jī)制支撐

• 重視性能

1、主動(dòng)發(fā)現(xiàn)問題

在我們曾經(jīng)出現(xiàn)過的一例線上資損故障中，由于場景實(shí)際觸發(fā)頻率較低，導(dǎo)致測試過程中被遺漏了。這個(gè)bug是6月6日發(fā)布上線的，但是直到7月10日有一個(gè)商家上報(bào)了一例我們才發(fā)現(xiàn)了這個(gè)涉及資損的問題。這件事情引發(fā)了我們的反思，對于核心業(yè)務(wù)鏈路上的異常行為，難道我們發(fā)現(xiàn)問題的途徑只能依賴用戶上報(bào)嗎？

天網(wǎng)數(shù)據(jù)報(bào)警平臺

事實(shí)上，主動(dòng)去發(fā)現(xiàn)和修復(fù)問題對于移動(dòng)端同學(xué)并不陌生。一個(gè)移動(dòng)團(tuán)隊(duì)即使是在建立初期也會通過一些三方平臺，對自己每個(gè)上線的版本進(jìn)行 crash 的監(jiān)控和分析。crash 平臺就是主動(dòng)發(fā)現(xiàn)和解決問題的表現(xiàn)。那么業(yè)務(wù)流程中的問題，我們是否也能做到主動(dòng)上報(bào)、主動(dòng)發(fā)現(xiàn)、主動(dòng)修復(fù)處理呢？答案一定是可以的。

因此我們搭建了天網(wǎng)報(bào)警平臺，目標(biāo)就是對于核心業(yè)務(wù)鏈路上的異常情況，可以達(dá)到 crash 上報(bào)、分析、跟蹤的同樣效果。一套 crash 分析平臺通常具備以下能力：問題上報(bào)、數(shù)據(jù)聚合、任務(wù)分配、版本過濾、上下文信息等，我們的天網(wǎng)平臺也提供了相同的完整能力：

• 數(shù)據(jù)上報(bào)：通過業(yè)務(wù)核心環(huán)節(jié)的主動(dòng)埋點(diǎn)，對異常進(jìn)行主動(dòng)上報(bào)，根據(jù)問題不同分級支持設(shè)置不同的上報(bào)優(yōu)先級策略

• 數(shù)據(jù)聚合：相同的問題通過后臺進(jìn)行聚合，提供問題列表并支持各種條件篩選

• 任務(wù)分配：問題可以分配給責(zé)任人跟進(jìn)

• 消息報(bào)警：當(dāng)問題符合報(bào)警策略，自動(dòng)關(guān)聯(lián)到企微報(bào)警，并直接at對應(yīng)業(yè)務(wù)域的負(fù)責(zé)人，第一時(shí)間介入處理

• 版本過濾：問題修復(fù)后支持設(shè)置已修復(fù)版本，后續(xù)上報(bào)問題如果小于等于已修復(fù)版本則不再報(bào)警，如果大于已修復(fù)版本則代表問題再次發(fā)生，會再次報(bào)警需要跟進(jìn)

• 周報(bào)日報(bào)：周期性匯總線上報(bào)警問題數(shù)量和狀態(tài)，提醒責(zé)任人及時(shí)處理

搭建了完整的平臺能力之后，我們也深知整套系統(tǒng)的有效運(yùn)轉(zhuǎn)其實(shí)是深度依賴于業(yè)務(wù)同學(xué)在業(yè)務(wù)流程的關(guān)鍵環(huán)節(jié)中的主動(dòng)分析和埋點(diǎn)，豐富的業(yè)務(wù)埋點(diǎn)才能讓這套系統(tǒng)真正在業(yè)務(wù)主動(dòng)防控中發(fā)揮效果，因此我們還匯總了適合業(yè)務(wù)主動(dòng)埋點(diǎn)的最佳實(shí)踐：

• 數(shù)據(jù)校驗(yàn)：對于端上通過輸入或者計(jì)算產(chǎn)生的數(shù)據(jù)，可以通過交叉校驗(yàn)分析異常；

• 關(guān)鍵內(nèi)容缺失：各環(huán)節(jié)在收口階段均可以校驗(yàn)自己獲取的參數(shù)完整性，如果有關(guān)鍵內(nèi)容缺失可以主動(dòng)上報(bào)；

• 系統(tǒng)異常：無論是 iOS 系統(tǒng) API 返回了 error，還是 Android 系統(tǒng)中 try/catch 的異常，都代表本地系統(tǒng)調(diào)用出現(xiàn)了預(yù)期外的行為，可以主動(dòng)上報(bào)

以下是一個(gè)天網(wǎng)報(bào)警的例子，在收銀員操作一筆訂單的過程中，移動(dòng)端上報(bào)后端的開單參數(shù)中會包含以下信息：

• 商品信息（如一聽可樂，售價(jià)3元）

• 營銷信息（限時(shí)折扣7折，或者會員價(jià)2.5元）

• 支付信息（最終通過會員價(jià)2.5元結(jié)算，通過現(xiàn)金進(jìn)行支付）

• 會員信息（用戶登錄的會員、在該筆訂單中所使用的是哪張會員卡等）

  
  

我們曾經(jīng)出現(xiàn)過的一個(gè)bug是在大型項(xiàng)目改造的過程中，在調(diào)用后端API傳參時(shí)沒有傳選中的會員卡號。這個(gè)場景下，當(dāng)這張會員卡有發(fā)放多倍積分的設(shè)置時(shí)，就會導(dǎo)致該筆訂單最終發(fā)放的積分錯(cuò)誤。這種場景下，我們增加對參數(shù)的主動(dòng)校驗(yàn)：當(dāng)開單參數(shù)中的營銷信息中存在會員卡優(yōu)惠，但是會員信息中又沒有傳卡信息時(shí)，就很有可能是開發(fā)中出現(xiàn)了bug，通過這樣的參數(shù)內(nèi)部交叉校驗(yàn)，我們就可以進(jìn)行主動(dòng)上報(bào)。

事實(shí)上，在一年后的一次重構(gòu)過程中，開發(fā)同學(xué)真的又一次出現(xiàn)了同樣的失誤，而天網(wǎng)報(bào)警提供的信息這次就給與了我們很大的幫助。

截止目前，我們已經(jīng)在業(yè)務(wù)核心鏈路上預(yù)埋了上百個(gè)報(bào)警點(diǎn)，并在線上多次真實(shí)預(yù)警了線上問題，讓我們可以第一時(shí)間進(jìn)行主動(dòng)修復(fù)。

2、更早發(fā)現(xiàn)問題

看完前文可能有細(xì)心的同學(xué)已經(jīng)會問了：如果對問題進(jìn)行了埋點(diǎn)報(bào)警，那么又何必等到它上線再去處理呢？是不是在上線前就可以把問題修復(fù)掉？

回歸階段

答案當(dāng)然是可以的。有贊的移動(dòng)端發(fā)版是采用發(fā)版車機(jī)制，每周一我們會將測試驗(yàn)收通過的需求代碼 merge 到 dev分支，去打出“高鐵包”給測試同學(xué)進(jìn)行回歸，并且配合自動(dòng)化測試進(jìn)行核心流程的回歸驗(yàn)收，下周一高鐵包將會發(fā)布到市場。而高鐵的這一周時(shí)間，就是回歸發(fā)現(xiàn)問題的最佳時(shí)機(jī)。

因此我們將 crash 分析報(bào)警和天網(wǎng)業(yè)務(wù)告警的范疇都拓展到了回歸階段。高鐵階段的問題同樣會主動(dòng)觸發(fā)報(bào)警，過去一年間，這兩個(gè)平臺都有多次在 bug 上線前主動(dòng)報(bào)警的立功表現(xiàn)。

開發(fā)階段

回歸階段報(bào)警并不是我們思考的終點(diǎn)，核心鏈路問題的發(fā)現(xiàn)和解決還可以更早嗎？在開發(fā)階段，甚至是方案設(shè)計(jì)階段，有機(jī)會提前把一些線上問題扼殺在萌芽中嗎？

我們在針對端上可能發(fā)生資損的環(huán)節(jié)設(shè)計(jì)了單元測試，并將單測的運(yùn)行接入到了 CI 流程中，這樣代碼在提交時(shí)，就會直接經(jīng)過單測的檢驗(yàn)。

那么什么樣的代碼適合寫單元測試呢？

我們經(jīng)過討論，將范圍圈定在了移動(dòng)端重新建模和發(fā)生運(yùn)算兩種場景上，各個(gè)業(yè)務(wù)域的同學(xué)通過梳理產(chǎn)出自己的單測用例。

方案設(shè)計(jì)階段

還有比開發(fā)階段更早的時(shí)機(jī)嗎？可以在項(xiàng)目開發(fā)前就主動(dòng)預(yù)防嗎？我們在移動(dòng)端設(shè)計(jì)了行為校驗(yàn)機(jī)制

行為校驗(yàn)

所謂行為校驗(yàn)，就是將用戶的操作行為和數(shù)據(jù)進(jìn)行交叉校驗(yàn)，這個(gè)校驗(yàn)可以增加一個(gè)新的維度來預(yù)防 bug 的發(fā)生。

我們?nèi)匀徊捎蒙衔奶岬降挠唵螀?shù)中忘記傳會員卡信息的 bug 為例，這里選中卡這個(gè)操作是客戶端用戶點(diǎn)擊觸發(fā)的，那么用戶選卡的這個(gè)操作就是最終開單參數(shù)中應(yīng)當(dāng)包含會員卡的交叉校驗(yàn)點(diǎn)。

這樣的校驗(yàn)邏輯對于我們就是一條“校驗(yàn)規(guī)則”，我們開發(fā)了行為校驗(yàn)的底層SDK，就是在核心開單業(yè)務(wù)鏈路上通過將全流程的用戶操作行為和最終訂單數(shù)據(jù)進(jìn)行double check，新增一個(gè)維度來為業(yè)務(wù)保駕護(hù)航，提前避免開發(fā)過程中的低級失誤引入 bug 的可能性。

類似的規(guī)則例子還有很多，比如一筆在線訂單收款成功之前，一定曾經(jīng)成功調(diào)用過支付接口，可以用來預(yù)防一些同學(xué)在頁面跳轉(zhuǎn)上的bug；

目前我們的行為校驗(yàn)已承載了核心業(yè)務(wù)鏈路上的多條規(guī)則，大大降低了資損故障的可能性。

問題的發(fā)現(xiàn)和解決貫穿整個(gè)研發(fā)流程

3、有效的流程機(jī)制支撐

雖然我們有了多樣的工具平臺來報(bào)警和及時(shí)發(fā)現(xiàn)問題，但是這樣就可以提升質(zhì)量了嗎？在實(shí)踐中，我們深刻的認(rèn)識到，工具只有在配套高效合理的流程機(jī)制支撐，才能真正發(fā)揮威力。

在平臺搭建初期，線上的crash和數(shù)據(jù)校驗(yàn)報(bào)警平臺在報(bào)警時(shí)缺乏策略，沒有就報(bào)警頻率和at的負(fù)責(zé)人做收斂，導(dǎo)致單臺設(shè)備的一個(gè)小問題，機(jī)器人就會短時(shí)間在群里發(fā)出幾百條at所有人的報(bào)警消息。這種“狼來了”的報(bào)警只會讓大家關(guān)掉群消息提示，或者關(guān)掉企微的通知。

不懂得克制的報(bào)警，相當(dāng)于沒有報(bào)警。

因此我們反復(fù)優(yōu)化了報(bào)警策略，以“報(bào)出來的問題都是需要立即響應(yīng)，不需要立即響應(yīng)的都不要報(bào)出來”為原則，沉淀了一系列報(bào)警策略。

除去報(bào)警策略，我們另一個(gè)在流程規(guī)范上的沉淀是在Code Review環(huán)節(jié)上。

betterMR

在我們團(tuán)隊(duì)質(zhì)量問題最嚴(yán)峻的時(shí)期，我們扭轉(zhuǎn)被動(dòng)戰(zhàn)局的核心手段還是加強(qiáng)Code Review。但CR這件事情要想真的扎實(shí)做出效果，而不流于形式，是非常依賴好的流程機(jī)制進(jìn)行支撐的。在強(qiáng)化和落地CR的過程中，我們面臨以下挑戰(zhàn)：

• 效率問題：我們約定每個(gè)MR都需要2個(gè)reviewer去做CR。事實(shí)上在整個(gè)CR過程中是需要很多溝通成本的，開發(fā)同學(xué)將MR發(fā)給兩位reviewer，reviewer會提一些建議反饋，開發(fā)同學(xué)進(jìn)行修改后再次review，這個(gè)過程可能會反復(fù)多次，直到兩位reviewer都同意merge最后合并，整個(gè)過程中需要大量的溝通。而且reviewer常常手頭也在忙要晚些才有空，就更加會拖慢開發(fā)者的節(jié)奏。

CR過程中的溝通成本

• 顆粒度問題：一個(gè)項(xiàng)目中，改動(dòng)到幾十個(gè)文件數(shù)千行代碼并不是小概率事件。reviewer要想在這么大面積的代碼中找出一些細(xì)節(jié)的邏輯問題或者typo的低級問題并非易事。

• 時(shí)機(jī)問題：以往我們CR的時(shí)機(jī)是放在上線前，事實(shí)上這個(gè)時(shí)間提出的一些優(yōu)化建議已然太晚，如果想要優(yōu)化改造又需要測試再次介入。因此一些好的建議只能塵封積灰，有些可能很久都等不到下次優(yōu)化的機(jī)會。

我們意識到，CR的過程必須通過流程規(guī)范提高其效率，降低對開發(fā)同學(xué)的打擾和負(fù)擔(dān)，這樣大家才能真正高質(zhì)量的投入到CR中，相互保駕護(hù)航。

最終我們推出了betterMR機(jī)制，通過以下機(jī)制解決以上的挑戰(zhàn)：

• 硬性要求：所有上線代碼，至少2人review通過后才可以合入dev

  
  

• 時(shí)機(jī)問題&顆粒度問題：代碼在開發(fā)過程中，拆分成多個(gè)子任務(wù)，分批提MR合并到自己的feature分支。因此CR過程可以穿插到整個(gè)開發(fā)流程中，而不是在上線前最后review

• 溝通成本問題：企微通知全程介入CR流程，核心鏈路通知相關(guān)人，無需線下單獨(dú)溝通

• CR發(fā)起：開發(fā)同學(xué)在MR中at兩位reviewer，兩位reviewer都會收到企微通知消息

• CR建議：reviewer提出建議后，在評論中輸入[N]命令觸發(fā)企微通知給開發(fā)同學(xué)

• CR再次review：開發(fā)同學(xué)根據(jù)建議完成改造后，在評論中輸入[R]命令觸發(fā)企微通知給reviewer再次review代碼，確認(rèn)建議已落地

• CR通過：reviewer通過后評論“+1”，當(dāng)MR中已累計(jì)兩個(gè)“+1”時(shí)，開發(fā)同學(xué)會收到企微通知，代碼已可以合并

• 及時(shí)性問題：團(tuán)隊(duì)對MR進(jìn)行了分級，對應(yīng)提出了及時(shí)性的要求

• 普通MR，要求24小時(shí)內(nèi)完成review建議

• 緊急MR，要求2小時(shí)內(nèi)完成review建議

• 數(shù)據(jù)匯總激勵(lì)：我們針對MR還統(tǒng)計(jì)了周報(bào)和月報(bào)，對于團(tuán)隊(duì)中積極review代碼的同學(xué)，在周會和月會上給與激勵(lì)，讓大家都認(rèn)可review的積極效果

這套機(jī)制我們在2020年6月推出后，團(tuán)隊(duì)的線上問題數(shù)量立刻得到了有效控制。我們在當(dāng)年Q3迅速將線上問題數(shù)量縮減到了之前的1/3，并在之后長期保持了很低的線上問題率。

過去兩年移動(dòng)團(tuán)隊(duì)的線上問題走勢

配合有效的流程機(jī)制，工具能力才能真正發(fā)揮效果

4、重視性能

前文也提到有贊移動(dòng)的性能挑戰(zhàn)。在性能問題上我們的動(dòng)作包括以下三個(gè)方面：

• APM平臺的搭建：主動(dòng)發(fā)現(xiàn)線上問題，并且為線上卡頓問題提供分析數(shù)據(jù)與線索。

• 線下監(jiān)控平臺：對于性能問題，我們也同樣在探索在問題上線前發(fā)現(xiàn)和解決的可能性。我們所搭建的線下監(jiān)控平臺，在回歸階段對關(guān)鍵環(huán)節(jié)進(jìn)行自動(dòng)化測試并采集數(shù)據(jù)，如果發(fā)現(xiàn)同比上個(gè)版本某個(gè)數(shù)據(jù)有顯著提升，就會報(bào)警提示開發(fā)接入排查；

• 主動(dòng)優(yōu)化：根據(jù)APM平臺和線下監(jiān)控平臺的數(shù)據(jù)與反饋，我們會主動(dòng)安排性能優(yōu)化的方案，對app性能進(jìn)行持續(xù)優(yōu)化。

可用性、性能與流程規(guī)范共同構(gòu)建了移動(dòng)質(zhì)量建設(shè)矩陣

質(zhì)量提升的成果

過去兩年我們在質(zhì)量上的深耕與探索也給我們帶來了豐厚的成果，這個(gè)成果不僅體現(xiàn)在我們的月均線上問題數(shù)量上，更體現(xiàn)在我們持續(xù)的技術(shù)產(chǎn)出上。技術(shù)同學(xué)救火的頻率低了，就有更多時(shí)間主動(dòng)出擊，去體系化的搭建系統(tǒng)去預(yù)防線上問題的發(fā)生，預(yù)防機(jī)制又能進(jìn)一步降低線上問題發(fā)生的概率，形成良性循環(huán)，這無論對于團(tuán)隊(duì)，還是開發(fā)同學(xué)個(gè)人的成長都是很有幫助的。

本文講到的有贊移動(dòng)質(zhì)量提升與實(shí)踐的過程，其實(shí)也一定程度上代表了我們團(tuán)隊(duì)的工作方式。我們在應(yīng)對有贊業(yè)務(wù)場景的過程中，會遇到如離線收銀、性能深度優(yōu)化等有挑戰(zhàn)有意思的技術(shù)難題。而面對這些挑戰(zhàn)和難題，我們會主動(dòng)出擊，尋求體系化的解決方法。這些解決方案中往往還會涉及到后端服務(wù)和前端頁面的工作，以及產(chǎn)品化的思考，我們移動(dòng)同學(xué)在此過程中不設(shè)邊界的拓展自己的技能包，最終形成讓人頗具成就感的技術(shù)沉淀。