1. 上線窗口前的最后檢查在發(fā)布按鈕敲下去之前測(cè)試在盯什么我見過太多項(xiàng)目組把上線當(dāng)成一個(gè)動(dòng)作實(shí)際上它是一整套流程里風(fēng)險(xiǎn)最密集的一段。很多測(cè)試同學(xué)對(duì)需求階段、開發(fā)階段、測(cè)試階段的活很熟練一到上線就發(fā)慌——因?yàn)樯暇€這件事拼的不是執(zhí)行測(cè)試用例的熟練度而是風(fēng)險(xiǎn)判斷、環(huán)境掌控和臨場(chǎng)決策的能力。聊一套我自己的上線前檢查路徑不一定適合所有團(tuán)隊(duì)但框架可以作為參考。1.1 上線前第一件事確認(rèn)要發(fā)布的版本到底包含什么聽起來像廢話但這是翻車率最高的環(huán)節(jié)。開發(fā)說代碼已經(jīng)提了測(cè)試說測(cè)試通過了結(jié)果上線后線上跑的版本和測(cè)過的版本根本不是同一套這種事在不少團(tuán)隊(duì)都發(fā)生過。我的習(xí)慣是上線前至少半天找開發(fā)要一份最終的版本變更清單然后做三件事用代碼倉(cāng)庫(kù)的版本對(duì)比工具查一遍從上一個(gè)已上線版本到當(dāng)前待發(fā)布版本的所有提交記錄確認(rèn)提交內(nèi)容與變更清單一致沒有夾帶私貨比如順手改了某個(gè)公共類、動(dòng)了某個(gè)配置項(xiàng)。把變更清單里的每個(gè)功能點(diǎn)和測(cè)試用例、缺陷單做一次映射檢查。已經(jīng)關(guān)閉的缺陷要重新確認(rèn)關(guān)閉時(shí)的驗(yàn)證環(huán)境、驗(yàn)證版本不能拿舊環(huán)境的結(jié)論充數(shù)?？醋兏鍐卫镉袥]有非功能性改動(dòng)——依賴升級(jí)、框架版本調(diào)整、數(shù)據(jù)庫(kù)腳本、定時(shí)任務(wù)配置調(diào)整。這類改動(dòng)往往沒有專門的功能測(cè)試覆蓋但恰恰是上線后最容易惹事的。提示如果團(tuán)隊(duì)里連一個(gè)像樣的變更清單都沒有建議在上線流程文檔里把這條固化下來哪怕一開始只是維護(hù)一個(gè)簡(jiǎn)單的共享表格也比上線前臨時(shí)翻代碼要可靠得多。1.2 風(fēng)險(xiǎn)評(píng)估上線前要說清楚萬一掛了怎么收?qǐng)錾暇€窗口前測(cè)試要做的不是拍胸脯保證肯定沒問題而是基于現(xiàn)有測(cè)試覆蓋和信息判斷風(fēng)險(xiǎn)點(diǎn)都有哪些。我一般從三個(gè)角度來拆分改動(dòng)量維度這次是全新模塊、存量功能改造還是只更新了文案和樣式改動(dòng)量越大風(fēng)險(xiǎn)面越廣上線后需要盯守的時(shí)間就越長(zhǎng)。存量功能的改造往往比新功能更危險(xiǎn)因?yàn)樾鹿δ苡绊懙氖窃隽坑脩舳脑煊绊懙氖撬性谟糜脩?。影響面維度這個(gè)改動(dòng)是否涉及支付、登錄、訂單等核心鏈路是否涉及底層數(shù)據(jù)結(jié)構(gòu)的變更是否會(huì)影響多個(gè)業(yè)務(wù)模塊的公共接口通過影響面分析確定回歸測(cè)試的范圍至少把主鏈路、周邊強(qiáng)關(guān)聯(lián)模塊、基礎(chǔ)公共能力鑒權(quán)、配置加載、日志鏈路都過一遍。回滾成本維度這是很多人會(huì)忽略的一點(diǎn)。有的版本發(fā)布后如果出問題回滾只需要把鏡像切回去幾分鐘就行有的版本伴隨數(shù)據(jù)庫(kù)表結(jié)構(gòu)變更、數(shù)據(jù)遷移腳本回滾就需要專門做數(shù)據(jù)逆向操作費(fèi)時(shí)費(fèi)力風(fēng)險(xiǎn)還高。對(duì)這類不可逆上線測(cè)試階段就要格外謹(jǐn)慎并且要提前和運(yùn)維、開發(fā)一起把回滾預(yù)案寫好。這三步走完之后我會(huì)輸出一份上線風(fēng)險(xiǎn)評(píng)估里面明確寫本次版本的高中低風(fēng)險(xiǎn)點(diǎn)分別是什么、每個(gè)風(fēng)險(xiǎn)點(diǎn)對(duì)應(yīng)的驗(yàn)證情況、哪些功能做了多少輪測(cè)試、哪些區(qū)域是測(cè)試盲區(qū)需要上線后重點(diǎn)觀察。這份材料既是給自己上線后的盯守做備忘也是給項(xiàng)目組的風(fēng)險(xiǎn)告知——上線不是測(cè)試一個(gè)人的事風(fēng)險(xiǎn)要讓每個(gè)參與者都知道。1.3 上線窗口選擇不是什么時(shí)候想發(fā)就能發(fā)上線時(shí)機(jī)的選擇測(cè)試的話語權(quán)往往不夠但我建議測(cè)試還是要參與意見。從測(cè)試視角看一個(gè)好的上線窗口至少要滿足三個(gè)條件不在業(yè)務(wù)高峰時(shí)段。之前有個(gè)同事曾經(jīng)想吃肯德基工作日中午去結(jié)果排隊(duì)排了20分鐘看著前面的隊(duì)伍心里焦躁得不行。上線同理高峰時(shí)段用戶請(qǐng)求量大出問題后影響人數(shù)多排查問題時(shí)壓測(cè)流量也容易干擾判斷。電商、金融類項(xiàng)目最忌諱的就是大促時(shí)段發(fā)布大版本。留出足夠的盯守時(shí)間。別周五下午四點(diǎn)半發(fā)版五點(diǎn)半大家準(zhǔn)時(shí)下班。上線后至少要有2到3個(gè)小時(shí)的黃金觀察期核心人員都得在線。配合灰度發(fā)布策略。現(xiàn)在很多團(tuán)隊(duì)會(huì)先發(fā)小流量比如先放給5%的用戶觀察半小時(shí)沒問題再逐步放量。測(cè)試要提前了解這次的灰度策略明確自己在每個(gè)階段的驗(yàn)證動(dòng)作是什么。2. 環(huán)境差異為什么測(cè)試通過的系統(tǒng)上線后還是會(huì)有問題經(jīng)歷過幾次線上問題后我深刻意識(shí)到一件事測(cè)試環(huán)境驗(yàn)證通過只能說明在測(cè)試環(huán)境里沒問題不代表在線上環(huán)境沒問題。環(huán)境差異導(dǎo)致的上線事故比代碼邏輯錯(cuò)誤更難排查也更容易被甩鍋。2.1 環(huán)境漂移配置對(duì)不上是最常見的隱形炸彈很多團(tuán)隊(duì)有多個(gè)測(cè)試環(huán)境、預(yù)發(fā)環(huán)境、沙箱環(huán)境環(huán)境之間大多沒有做好嚴(yán)格的配置同步。測(cè)試環(huán)境把接口地址指向了某個(gè)Mock服務(wù)到了線上忘了切換預(yù)發(fā)環(huán)境連的是測(cè)試庫(kù)結(jié)果驗(yàn)證數(shù)據(jù)的時(shí)候被一堆臟數(shù)據(jù)干擾。這些都是很典型的環(huán)境漂移問題。應(yīng)對(duì)方式我是這樣做的在測(cè)試接近尾聲時(shí)拉著開發(fā)和運(yùn)維做一次上線環(huán)境的預(yù)演Dry Run把發(fā)布腳本、環(huán)境變量、配置中心的值逐項(xiàng)核對(duì)一遍確保線上配置文件里每一項(xiàng)關(guān)鍵配置和測(cè)試時(shí)理解的預(yù)期一致。人工核對(duì)配置容易漏可以用腳本把測(cè)試環(huán)境、預(yù)發(fā)環(huán)境、線上環(huán)境的關(guān)鍵配置項(xiàng)做一次diff把差異項(xiàng)打印出來人工確認(rèn)。這個(gè)過程哪怕只跑一次也能省掉不少上線后的折騰。配置變更要留痕。誰的配置改了、為什么改、影響了什么要有記錄臨時(shí)手滑改完就忘的行為是配置問題的最大來源。2.2 數(shù)據(jù)差異測(cè)試數(shù)據(jù)永遠(yuǎn)比線上干凈得多測(cè)試環(huán)境的數(shù)據(jù)量級(jí)、數(shù)據(jù)分布、數(shù)據(jù)特征跟線上完全不是一個(gè)量級(jí)的。最常見的坑是測(cè)試環(huán)境一張表幾萬條數(shù)據(jù)SQL執(zhí)行得飛快線上那張表幾千萬條同樣的SQL跑了幾百秒沒出來直接把數(shù)據(jù)庫(kù)拖垮了。這類問題測(cè)試階段其實(shí)能做很多事壓測(cè)階段對(duì)核心SQL做執(zhí)行計(jì)劃分析看有沒有走全表掃描、索引失效的情況。對(duì)數(shù)據(jù)增長(zhǎng)量有預(yù)判。比如新功能上線后預(yù)計(jì)每月新增多少數(shù)據(jù)量核心查詢的耗時(shí)增長(zhǎng)趨勢(shì)是什么樣。特殊數(shù)據(jù)邊界比如超級(jí)長(zhǎng)的字段、null值、空列表、超大數(shù)據(jù)量下的分頁查詢都值得專門構(gòu)造測(cè)試用例去驗(yàn)證。2.3 功能開關(guān)與灰度配置改動(dòng)要留后路這一點(diǎn)我自己吃過虧有一次功能改造涉及老版本數(shù)據(jù)展示邏輯當(dāng)時(shí)覺得反正新版本數(shù)據(jù)都是新結(jié)構(gòu)就把兼容代碼刪了。結(jié)果上線后發(fā)現(xiàn)有用戶的歷史數(shù)據(jù)還是舊結(jié)構(gòu)的展示直接裂開。后來學(xué)乖了凡是涉及數(shù)據(jù)結(jié)構(gòu)變更、展示邏輯變更的都要求開發(fā)加一個(gè)功能開關(guān)默認(rèn)走新邏輯但開關(guān)一關(guān)就能回退到舊邏輯。這樣上線后即使出問題也能快速止損而不是干等代碼回滾。至于開關(guān)加在哪個(gè)層級(jí)開關(guān)的默認(rèn)值是什么開關(guān)關(guān)閉后對(duì)數(shù)據(jù)是否有影響這些都要在測(cè)試階段驗(yàn)證一遍。上線流程文檔里也應(yīng)該把這個(gè)環(huán)節(jié)寫進(jìn)去。3. 上線當(dāng)天的測(cè)試節(jié)奏不是發(fā)完版本就結(jié)束了很多剛?cè)胄械臏y(cè)試同學(xué)以為上線就是運(yùn)維把包發(fā)出去然后測(cè)試點(diǎn)幾個(gè)頁面確認(rèn)一遍就完事。實(shí)際不是的上線當(dāng)天的測(cè)試工作要分三段走。3.1 發(fā)布過程中的觀察點(diǎn)一秒都不能走神發(fā)布動(dòng)作從開始到完成通常有幾秒到幾分鐘的時(shí)間窗口。這個(gè)窗口內(nèi)系統(tǒng)可能處于新舊版本交替、重啟、實(shí)例切換的狀態(tài)最需要盯的是發(fā)布日志有沒有報(bào)錯(cuò)。啟動(dòng)報(bào)錯(cuò)、連接超時(shí)、依賴初始化失敗的日志尤其是那些不影響啟動(dòng)但會(huì)影響功能的warning級(jí)別日志寧可早點(diǎn)發(fā)現(xiàn)早點(diǎn)處理也不要等用戶來報(bào)。鏈路狀態(tài)。如果公司在用注冊(cè)中心、網(wǎng)關(guān)這類基礎(chǔ)設(shè)施觀察服務(wù)實(shí)例是否正常注冊(cè)、流量是否在預(yù)期范圍內(nèi)切換。關(guān)鍵告警有沒有觸發(fā)。這時(shí)候不能只看業(yè)務(wù)日志CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)I/O這些系統(tǒng)指標(biāo)也得盯著一旦有異常波動(dòng)多半是發(fā)布出來的副作用。我的做法是準(zhǔn)備一個(gè)發(fā)布觀察清單上面列著本次發(fā)布需要關(guān)注的服務(wù)名、關(guān)鍵日志關(guān)鍵字、重點(diǎn)指標(biāo)發(fā)布的時(shí)候拿著清單逐項(xiàng)看不靠腦子記。3.2 冒煙驗(yàn)證清單從主流程開始優(yōu)先級(jí)最高的事先做發(fā)布完成后最先做的是冒煙測(cè)試不是全量回歸。冒煙測(cè)試的目的是用最快的速度確認(rèn)系統(tǒng)能跑通最核心的業(yè)務(wù)路徑比如用戶能不能登錄、主流程能不能走完、核心交易能不能完成。所以冒煙用例要短、要核心、要快優(yōu)先級(jí)排布可以參考這樣的邏輯第一條跑對(duì)系統(tǒng)存亡影響最大的鏈路比如登錄鑒權(quán)、網(wǎng)關(guān)轉(zhuǎn)發(fā)、數(shù)據(jù)庫(kù)連通性。第二條跑本次版本涉及的最核心功能改動(dòng)點(diǎn)。第三條跑老版本主流程確認(rèn)沒有明顯回歸。第四條看關(guān)鍵的聯(lián)調(diào)外部服務(wù)支付網(wǎng)關(guān)、短信服務(wù)、第三方推送等是否可連通。提前把這些冒煙用例寫成自動(dòng)化腳本可以節(jié)省不少人力而且比起手工點(diǎn)頁面腳本跑出來的結(jié)果更客觀也更快速。手工冒煙的缺點(diǎn)就是容易遺漏而且執(zhí)行人一緊張就容易操作變形。3.3 手工探索的核心區(qū)域重點(diǎn)用戶路徑的抽查自動(dòng)化冒煙過了不代表高枕無憂。我會(huì)再抽幾條重點(diǎn)用戶路徑做手工走查尤其關(guān)注和這次變更相關(guān)的邊緣場(chǎng)景。比如改了訂單狀態(tài)邏輯那就重點(diǎn)走一遍不同類型訂單的狀態(tài)流轉(zhuǎn)改了支付流程那就把各種支付方式都點(diǎn)一遍。這些手工走查的好處是可以結(jié)合界面上下文和各種異常狀態(tài)比腳本覆蓋的場(chǎng)景更靈活。4. 發(fā)布后的黃金盯守期前30分鐘到前3小時(shí)每一條告警都要當(dāng)回事版本發(fā)布后的頭幾個(gè)小時(shí)是最關(guān)鍵的。用戶反饋還沒大規(guī)模擴(kuò)散問題發(fā)現(xiàn)得越早影響面就越小。這段時(shí)間測(cè)試不能閑著要做的事情很多。4.1 線上回歸的執(zhí)行順序與版本風(fēng)險(xiǎn)點(diǎn)逐一對(duì)應(yīng)我一般會(huì)做三輪線上的回歸盯守第一輪發(fā)布后15分鐘內(nèi)核心鏈路巡檢。用上面的自動(dòng)化冒煙腳本跑一遍加上關(guān)鍵日志的關(guān)鍵詞掃描比如ERROR、Exception、超時(shí)等看有沒有異常情況。第二輪發(fā)布后1小時(shí)內(nèi)圍繞本次版本變更點(diǎn)的功能驗(yàn)證。把測(cè)試環(huán)境驗(yàn)證過的業(yè)務(wù)場(chǎng)景在線上環(huán)境各走一遍主邏輯路徑。第三輪發(fā)布后2到3小時(shí)觀察用戶行為鏈路。這個(gè)階段更多是靠日志和監(jiān)控?cái)?shù)據(jù)比如核心接口的耗時(shí)趨勢(shì)有沒有上升、錯(cuò)誤率有沒有明顯波動(dòng)、用戶側(cè)有沒有形成投訴。測(cè)試階段的線上回歸目標(biāo)不是把線下的所有用例在線上重跑一遍——線上環(huán)境和數(shù)據(jù)條件都不允許。真正要做的是把風(fēng)險(xiǎn)最高的那部分驗(yàn)證點(diǎn)覆蓋掉然后用監(jiān)控?cái)?shù)據(jù)來兜底。4.2 線上問題與Bug的處理邊界什么該提單什么該立即上報(bào)線上出問題的時(shí)候最忌諱的就是按測(cè)試階段的方式走提Bug-開發(fā)修復(fù)-驗(yàn)證-關(guān)閉的流程這會(huì)耽誤事。線上問題的處理要按嚴(yán)重級(jí)別分流嚴(yán)重級(jí)別表現(xiàn)處理動(dòng)作P0主流程不可用、大面積報(bào)錯(cuò)、資損、數(shù)據(jù)損壞立即上報(bào)通知研發(fā)/運(yùn)維/產(chǎn)品決策是否回滾測(cè)試配合復(fù)現(xiàn)和定位P1核心功能受損但有小路可走、部分用戶受影響30分鐘內(nèi)響應(yīng)評(píng)估影響范圍確認(rèn)是否有臨時(shí)該干的事P2非核心功能異常、不影響主流程正常提單按常規(guī)迭代節(jié)奏處理測(cè)試在線上問題中的作用不只是復(fù)現(xiàn)一下這個(gè)bug更關(guān)鍵的是快速判斷影響范圍受影響的是哪些用戶群、哪些功能模塊、什么時(shí)候開始出現(xiàn)的。這些信息能給到?jīng)Q策層做判斷是緊急修復(fù)、回滾還是先撐一下再看。4.3 回滾決策的思路什么樣的評(píng)價(jià)要在一小時(shí)內(nèi)做出來回滾是一個(gè)很重的動(dòng)作但是很多問題撐到最后也只能回滾。測(cè)試要清楚一件事回滾不僅僅是一個(gè)技術(shù)動(dòng)作它代表著一整套流程要倒退重來。所以回滾決策不是出了錯(cuò)就要回滾而是要看幾個(gè)因素問題影響面是否還在擴(kuò)大。如果影響范圍可控可能先用功能開關(guān)把新邏輯關(guān)掉如果影響面不可控回滾要趁早。問題的修復(fù)成本和時(shí)間。如果開發(fā)預(yù)計(jì)一小時(shí)內(nèi)能修復(fù)可能不必回滾先出個(gè)熱修包試試如果修復(fù)時(shí)間無法估算回滾是更優(yōu)的選擇。不可逆的變更要對(duì)沖。如果是涉及數(shù)據(jù)庫(kù)遷移之類的不可逆操作更要提前在發(fā)布方案里plan好回滾之后的補(bǔ)償邏輯。這里分享一個(gè)經(jīng)驗(yàn)回滾決策要前置回滾方案不要等出問題的時(shí)候才臨時(shí)寫。測(cè)試在發(fā)布前評(píng)審階段就應(yīng)要求研發(fā)把每次發(fā)布的回滾方案寫清楚方案里必須有明確的觸發(fā)條件、執(zhí)行步驟、驗(yàn)證方法。多數(shù)團(tuán)隊(duì)能做好第一項(xiàng)和第三項(xiàng)第二項(xiàng)的執(zhí)行步驟往往寫不細(xì)。出問題的時(shí)候運(yùn)維和執(zhí)行人要么靠臨場(chǎng)反應(yīng)要么靠不完全的方案動(dòng)作變形就會(huì)在后面造成更多麻煩。5. 上線流程里的三類不顯眼但致命的問題數(shù)據(jù)、緩存、外部依賴有些問題不是邏輯錯(cuò)也不是環(huán)境差而是軟件系統(tǒng)里一些底層模塊在上線流程里被忽略了。這三個(gè)大頭我單獨(dú)提出來給同行們多個(gè)參考維度。5.1 數(shù)據(jù)層面的上線動(dòng)作不是只有DDL那么簡(jiǎn)單發(fā)布單里有表結(jié)構(gòu)變更的測(cè)試階段必須驗(yàn)證數(shù)據(jù)遷移腳本的可執(zhí)行性和可重復(fù)性。有的腳本只能跑一次跑第二次就報(bào)錯(cuò)這種腳本在灰度發(fā)布場(chǎng)景下就很危險(xiǎn)。要專門驗(yàn)證腳本在空庫(kù)、有歷史數(shù)據(jù)、有大表等不同場(chǎng)景下的表現(xiàn)。初始化數(shù)據(jù)的冪等性也要驗(yàn)證。線上執(zhí)行初始化腳本時(shí)如果腳本里包含插入默認(rèn)配置之類的操作一旦執(zhí)行到一半因?yàn)槟硹l數(shù)據(jù)重復(fù)導(dǎo)致中斷后續(xù)再補(bǔ)跑就很容易出現(xiàn)數(shù)據(jù)錯(cuò)亂。規(guī)格上應(yīng)要求每次發(fā)布的腳本都把冪等邏輯寫清楚。老數(shù)據(jù)的清洗和兼容性處理要有專門的測(cè)試用例。新代碼上線后老數(shù)據(jù)必須能被正常讀出來、正常展示。我知道有些團(tuán)隊(duì)測(cè)試階段只造新數(shù)據(jù)不提前歷史數(shù)據(jù)這就遺漏了一個(gè)風(fēng)險(xiǎn)面。5.2 緩存層面的上線動(dòng)作版本更新后緩存怎么辦緩存是上線最容易被繞過去的環(huán)節(jié)。改了商品詳情的展示邏輯但緩存里有舊邏輯生成的商品數(shù)據(jù)用戶看到的和預(yù)期不符。這個(gè)問題不致命但很容易讓項(xiàng)目組以為上線失敗了。處理方式有這么幾種按成本和效果排發(fā)布前評(píng)估本次改動(dòng)是否會(huì)涉及緩存結(jié)構(gòu)變化如有應(yīng)提前設(shè)計(jì)好緩存預(yù)熱方案別拿空緩存去扛流量。關(guān)鍵緩存設(shè)置好版本號(hào)發(fā)布時(shí)切換緩存版本新版本自然用新邏輯生成緩存。發(fā)布后巡檢緩存命中率如果出現(xiàn)命中率大面積掉下來的情況得留意是不是緩存key的變化導(dǎo)致緩存大量失效引發(fā)后端壓力升高。5.3 異步消息與時(shí)序問題上線后最磨人的問題來源還有一類問題測(cè)試環(huán)境死活測(cè)不出來上線后間歇性閃現(xiàn)最后定位到是異步消息或任務(wù)調(diào)度的時(shí)間順序問題。比如用戶下單后發(fā)送消息通知庫(kù)存扣減但消息消費(fèi)的時(shí)序在兩個(gè)環(huán)境里不一致定時(shí)任務(wù)在發(fā)布期間被重復(fù)觸發(fā)導(dǎo)致數(shù)據(jù)重復(fù)寫。應(yīng)對(duì)這類問題的思路測(cè)試階段要設(shè)計(jì)時(shí)序類、并發(fā)類的用例別只測(cè)單線程場(chǎng)景。了解本次發(fā)布涉及哪些消息隊(duì)列、哪些定時(shí)任務(wù)確認(rèn)它們的消費(fèi)者/執(zhí)行器的變更情況必要時(shí)在發(fā)布期間屏蔽定時(shí)任務(wù)的觸發(fā)窗口。發(fā)布方案里把消息中間件、任務(wù)調(diào)度平臺(tái)的運(yùn)維注意事項(xiàng)寫清楚有需要暫停調(diào)度任務(wù)的話務(wù)必申請(qǐng)暫停時(shí)間。說句實(shí)在的這三類問題里數(shù)據(jù)問題最要命緩存問題最隱蔽異步問題最磨人。但好在它們都是可以提前設(shè)計(jì)的只要在流程里固化相應(yīng)的檢查項(xiàng)上線風(fēng)險(xiǎn)能降一大截。6. 把上線流程固化成一個(gè)可復(fù)制的機(jī)制線上發(fā)布檢查清單與交付到這兒上線流程已經(jīng)不是某個(gè)人的經(jīng)驗(yàn)而是一個(gè)有章可循的標(biāo)準(zhǔn)動(dòng)作。項(xiàng)目團(tuán)隊(duì)最怕的是一批人走了流程經(jīng)驗(yàn)跟著走了下一批人重新踩坑。所以流程要落成文件、要落成清單這既是工作效率的保障也是測(cè)試團(tuán)隊(duì)話語權(quán)的體現(xiàn)。6.1 發(fā)布checklist該怎么設(shè)計(jì)設(shè)計(jì)checklist的時(shí)候如果條目太多就等于沒有checklist因?yàn)閳?zhí)行人根本看不完。我會(huì)把它分成兩類必做項(xiàng)硬性門檻變更清單完整、可回溯測(cè)試環(huán)境和線上環(huán)境的配置差異項(xiàng)已確認(rèn)已知缺陷的影響范圍評(píng)估完成且有處置結(jié)論數(shù)據(jù)遷移腳本已驗(yàn)證可執(zhí)行、可重復(fù)、可回滾回滾方案、功能開關(guān)預(yù)案已落實(shí)核心鏈路自動(dòng)化冒煙用例通過職責(zé)項(xiàng)按角色拆分的檢查內(nèi)容開發(fā)確認(rèn)代碼分支無誤、上線腳本已驗(yàn)證、配置項(xiàng)提交完整測(cè)試冒煙清單通過、監(jiān)控告警已接入、線上回歸計(jì)劃就緒運(yùn)維發(fā)布窗口已確認(rèn)、監(jiān)控大屏就緒、資源水位有數(shù)產(chǎn)品運(yùn)營(yíng)側(cè)公告/客服話術(shù)就緒、用戶溝通預(yù)案就位這套checklist的價(jià)值不只是上線前逐項(xiàng)打勾更是給大家一個(gè)統(tǒng)一的溝通語言避免同一件事你說東他說西。6.2 發(fā)布復(fù)盤怎么開才有用很多團(tuán)隊(duì)上線后例行開個(gè)復(fù)盤會(huì)結(jié)果開了兩張嘴皮子就散了沒留下什么可改進(jìn)的東西。我的建議是復(fù)盤會(huì)不要糾結(jié)誰的責(zé)任而要復(fù)現(xiàn)三件事本次發(fā)布過程中的時(shí)間線。什么時(shí)候發(fā)布、什么時(shí)候發(fā)現(xiàn)異常、什么時(shí)候決策、什么時(shí)候解決。把這條時(shí)間線擺出來大家自然知道哪個(gè)環(huán)節(jié)花的時(shí)間不合理哪個(gè)環(huán)節(jié)的決策被拖住了。下一步需要改進(jìn)的機(jī)制性動(dòng)作。不能只停留在下次小心點(diǎn)這次多注意。要有明確的任務(wù)分配比如下次上線前測(cè)試要提前兩天檢查數(shù)據(jù)遷移腳本下次發(fā)布運(yùn)維要在發(fā)布開始前確認(rèn)告警通道可用。做得好的部分也要總結(jié)。別光盯著問題。哪個(gè)環(huán)節(jié)因?yàn)榱鞒糖逦?jié)省了時(shí)間、哪個(gè)功能因?yàn)闇y(cè)試覆蓋到位沒有出問題把這些經(jīng)驗(yàn)提煉出來變成后續(xù)流程的執(zhí)行標(biāo)準(zhǔn)。6.3 測(cè)試自動(dòng)化的切入點(diǎn)上線流程里的自動(dòng)化不只是為了省人力更是為了保證上線那一刻的動(dòng)作不變形。從我的經(jīng)驗(yàn)看以下幾個(gè)自動(dòng)化點(diǎn)收益最高值得優(yōu)先投入核心鏈路的發(fā)布后冒煙腳本。花不了太多工作量但每次上線都能跑一遍安心程度提升一大截。數(shù)據(jù)/配置差異對(duì)比腳本。測(cè)試環(huán)境、預(yù)發(fā)環(huán)境、線上環(huán)境的配置對(duì)比用腳本掃一遍比自己人肉對(duì)一遍可靠得多。發(fā)布日志的關(guān)鍵詞監(jiān)控。在日志平臺(tái)里配好ERROR、Exception、timeout等關(guān)鍵字的實(shí)時(shí)告警異常情況不用人肉眼去翻日志。線上核心接口的自動(dòng)化巡檢。定時(shí)跑關(guān)鍵接口的正確率和耗時(shí)上線后如果指標(biāo)掉下去能提早捕捉到問題。這些自動(dòng)化的投入不一定需要多大成本先從最痛的點(diǎn)開始跑順了一個(gè)再逐漸擴(kuò)展。我見過太多團(tuán)隊(duì)一上來就想著搞一套全自動(dòng)的發(fā)布流水線結(jié)果搭了三個(gè)月還沒跑通連最基礎(chǔ)的冒煙腳本都沒人寫。先小步快跑跑起來再優(yōu)化比大而全的空想方案強(qiáng)得多。說白了項(xiàng)目上線流程這一整套東西本質(zhì)上是把一個(gè)高風(fēng)險(xiǎn)的儀式變成一套可控的、可預(yù)期的標(biāo)準(zhǔn)作業(yè)。測(cè)試在這個(gè)流程里既是最后一公里質(zhì)量的守門人也是發(fā)布風(fēng)險(xiǎn)的早期預(yù)警者。這一套流程能跑順不是某個(gè)人特別厲害而是每個(gè)參與者都對(duì)流程有敬畏心知道每一步該干什么、為什么這么干。