作者：京東物流 馮志文

背景

從研發(fā)的流程階段來看，在確定產(chǎn)品需求后，我們會經(jīng)歷架構(gòu)設(shè)計、編碼、測試、聯(lián)調(diào)驗證和上線這幾個階段來交付系統(tǒng)。在這個過程中，我們需要特別關(guān)注上線環(huán)節(jié)，因為它是事故高發(fā)的階段。

為了應(yīng)對這種情況，我們實施了嚴(yán)格的發(fā)布標(biāo)準(zhǔn)操作程序，簡稱為“發(fā)布三板斧”。這包括可灰度發(fā)布、可驗證發(fā)布和可回滾發(fā)布。通過這三個步驟，我們可以確保在發(fā)布過程中盡量減少風(fēng)險，提高系統(tǒng)的穩(wěn)定性和可靠性。

一、灰度要有耐心

1、灰度意義

1.灰度發(fā)布是為了驗證我們的假設(shè)，即“還存在我們不知道的問題”。因此，在進行灰度發(fā)布時需要更加謹慎，確保即使問題在生產(chǎn)環(huán)境中出現(xiàn)，也能控制其對業(yè)務(wù)和用戶的影響。通過灰度盡可能的減少問題的影響面，如果通過灰度過程發(fā)現(xiàn)一個線上問題，那么去掉灰度的保護，可能就會產(chǎn)生一個嚴(yán)重的故障。 我們可以逐步驗證系統(tǒng)的穩(wěn)定性和可靠性，減少風(fēng)險并提高產(chǎn)品質(zhì)量。

2.我們需要明確一點：灰度從來不是為了測試。它的主要目的是對抗“未知的不確定性” 。在軟件開發(fā)過程中，我們無法預(yù)測所有可能的問題和錯誤，因此需要通過灰度發(fā)布來驗證系統(tǒng)的穩(wěn)定性和可靠性。

3.在分布式系統(tǒng)中常見通用的灰度過程有 beta 發(fā)布、藍綠發(fā)布，進行流量級別的灰度過程，能夠滿足絕大部分變更灰度驗證需求。如果變更復(fù)雜度較高或者業(yè)務(wù)比較重要，在方案設(shè)計中也需要進行更精細變更影響面控制，例如按照影響用戶維度逐步生效的設(shè)計，但要注意一次業(yè)務(wù)完整流程中開關(guān)一致性問題。

4.灰度發(fā)布是一種有效的風(fēng)險管理方法，可以幫助我們在軟件開發(fā)過程中識別和解決潛在的問題，提高產(chǎn)品質(zhì)量和用戶體驗。

2、灰度發(fā)布

為解決用戶手動部署操作耗時高、對人依賴度高、人工容易遺漏等導(dǎo)致線上問題痛點，強烈推薦您使用 【部署編排】 功能，用戶可靈活制定部署策略，實現(xiàn)從編譯構(gòu)建到實例部署的自動化運行，提高部署效率！但部署編排第一次使用的時候需要驗證好。

3、灰度有效性

在灰度的落地與推進過程中，有效性非常重要。因為灰度是一個很耗時的復(fù)雜的過程。如果不注意的話，很容易出現(xiàn)“形式化”的情況，即只是表面上的灰度，而實際上并沒有達到預(yù)期的效果。

為了確保灰度的有效性，需要注意以下幾個方面：

1.制定詳細的灰度計劃：在進行灰度之前，應(yīng)該制定詳細的計劃，包括灰度的范圍、時間、節(jié)點等信息，以確保灰度過程的可控性和可預(yù)測性。

2.逐步推進灰度：在進行灰度時，應(yīng)該逐步推進，而不是一下子全面鋪開。比如，可以先在一個機房的一個分組中部分節(jié)點進行灰度，然后再擴大到全部節(jié)點和集群，最后再擴展到另外一個機房的相同步驟。

3.監(jiān)控和反饋：在進行灰度時，應(yīng)該及時監(jiān)控和反饋，以發(fā)現(xiàn)和解決可能出現(xiàn)的問題和風(fēng)險。關(guān)鍵點在于時間和流量

時間： 每個灰度階段至少有 5 ~ 10 分鐘的觀察時間，這個時間可以根據(jù)業(yè)務(wù)系統(tǒng)的具體情況進行調(diào)整。在觀察期間，需要密切關(guān)注監(jiān)控、日志和各方反饋等信息，以發(fā)現(xiàn)和解決可能出現(xiàn)的問題和風(fēng)險。只有當(dāng)這些信息沒有異常時，才能擴大灰度范圍，進一步推廣灰度計劃。在灰度過程中，需要保持高度警惕和敏銳的洞察力，及時發(fā)現(xiàn)和解決問題，以保證系統(tǒng)的穩(wěn)定和可靠性。

流量： 在進行灰度時，流量是一個非常重要的因素，需要特別注意。特別是對于一些業(yè)務(wù)場景，可能需要特定的觸發(fā)條件才能進行灰度測試，比如只有滿足某些條件的用戶或訂單才能參與測試。 在這種情況下，僅僅通過單位時間內(nèi)是否存在異常來判斷灰度是否成功是不足夠的。還需要確保有足夠的有效流量來觸發(fā)這些特定的業(yè)務(wù)場景。否則，即使系統(tǒng)在灰度測試中沒有出現(xiàn)異常，也不能完全保證系統(tǒng)在實際使用中的穩(wěn)定性和可靠性。 因此，在進行灰度測試時，需要確保有足夠的有效流量來觸發(fā)這些特定的業(yè)務(wù)場景。同時，還需要注意監(jiān)控和日志等信息，及時發(fā)現(xiàn)和解決可能出現(xiàn)的問題和風(fēng)險。通過這種方式，可以更好地保證系統(tǒng)的穩(wěn)定和可靠性，提高灰度測試的效果和價值。

有效的灰度可以把問題影響鎖定在一個小范圍內(nèi)，但是同樣也降低了問題的“明顯性”，所以你要通過監(jiān)控和日志更加仔細、謹慎地去尋找、觀測異常并對比發(fā)現(xiàn)問題。灰度是一個復(fù)雜的過程，需要仔細考慮和規(guī)劃。通過制定詳細的計劃、逐步推進和及時監(jiān)控和反饋等措施，可以確保灰度的有效性和可持續(xù)性。

4、灰度驗證

如果灰度發(fā)布的時候都是帶有開關(guān)功能，則全部發(fā)布上線后，需要通過DUCC開關(guān)來進行灰度驗證。

4.1、新功能業(yè)務(wù)灰度：

適用場景:新的鏈路功能，比如提供新的API，跟歷史代碼邏輯無關(guān)

操作步驟：代碼無開關(guān)，代碼上線確保不影響老邏輯即可。通過業(yè)務(wù)線上灰度驗證相關(guān)邏輯準(zhǔn)確性

4.2、核心鏈路灰度驗證

適用場景： 如果是在原有鏈路添加新功能，則系統(tǒng)上線后，業(yè)務(wù)需要在生產(chǎn)環(huán)境中進行灰度驗證。這樣可以在生產(chǎn)環(huán)境中不影響其他用戶體驗的情況下去測試新功能，只影響灰度的數(shù)據(jù)，縮小影響范圍。

操作步驟： DUCC功能開關(guān)可以配置相關(guān)的驗證參數(shù)組合（比如下單前根據(jù)用戶pin、百分百、門店ID、下單后訂單號、倉庫ID等）。DUCC配置如下：

jitSwitch.storeId=1-1,1-2,1-3,1-4,****

4.3、切量灰度

適用場景：比如重構(gòu)、技術(shù)改造、黃金鏈路上線的重要功能

操作步驟：根據(jù)訂單號或者pin百分比逐步切量進行線上驗證。如下圖DUCC配置 ：

commonSwith.percent=10

切量比例需要注意hashCode() 返回值為負數(shù)，潛在的放大了期望的切量比例

5、灰度注意事項

1.灰度驗證要細心 。 其實跟上線一樣，主要都是依賴日志&監(jiān)控&報警規(guī)則的建設(shè)和配置。只不過灰度的比例小，通過ump監(jiān)控等報警沒有那么敏感，核心還是需要關(guān)注灰度對應(yīng)logbook日志，業(yè)務(wù)上下游鏈路可視化相關(guān)驗證。

2.灰度回滾：灰度過程務(wù)必具備整體暫停回滾能力 。 灰度過程中發(fā)生問題，立即暫停灰度，并且把之前灰度機器操作回滾，如機器少可JSF下線或者停止機器。如灰度比例高，則不可停服務(wù)，需要快速回滾（通過ducc開關(guān)代碼隔離、或者代碼回滾）

3.灰度回滾過程中歷史數(shù)據(jù)需要糾正處理

二、驗證需要兼容

1、可監(jiān)控

完善的監(jiān)控告警比人工反饋響應(yīng)更快，也會減少故障的持續(xù)時間進而降低影響。在推進監(jiān)控落地的過程中，你要和團隊成員講明監(jiān)控的重要性，還要確保監(jiān)控的完善與有效。對監(jiān)控的覆蓋程度與范圍要求越來越細致。一般情況下，我們監(jiān)控的都是 API 這一層面，但是單純的技術(shù)指標(biāo)并不能完整發(fā)現(xiàn)，往往要結(jié)合業(yè)務(wù)場景去設(shè)計，才能夠更加精細化地感知異常。

核心接口UMP（TP99、可用率、流量）或者MQ 等，這個沒什么好講的

2、日志

根據(jù)日志驗證對應(yīng)場景（新功能場景及之前線上核心流程場景） 。比如promise場景復(fù)雜，上線會驗證不同訂單類型的下傳時間等相關(guān)的重要場景訂單，如下圖：

3、向后兼容性

功能A上線，驗證A功能沒問題后，需要看下其他功能是否有問題（比如系統(tǒng)的核心環(huán)節(jié)功能）。

三、回滾就是變更的“后悔藥”

1、制定回滾計劃

故障恢復(fù)最好的手段是各種預(yù)案，而回滾則是預(yù)案中最普遍、也最有效的。

回滾的必要性 ： 應(yīng)用上線應(yīng)該制定詳盡的回滾計劃，能夠在最短時間內(nèi)將應(yīng)用恢復(fù)至上一穩(wěn)定運行版本；然而系統(tǒng)并不是天然可以無縫回滾的，想要系統(tǒng)具備回滾的能力，在設(shè)計與實現(xiàn)階段需要付出額外的精力。可回滾的本質(zhì)是系統(tǒng)的兼容性設(shè)計與實現(xiàn)，比如常見的“只增不改”，一個 API 內(nèi)要調(diào)整很多實現(xiàn)邏輯才能滿足新業(yè)務(wù)的需求，此時不妨直接新增一個 API ，兩個 API 保持參數(shù)一致，那么一旦新 API 有異常直接通過開關(guān)技術(shù)切換回舊的 API 即可。一般情況下應(yīng)用本身可回滾，而數(shù)據(jù)層面的可回滾性是重要的考量因素之一。遵循安全的增量變更原則所設(shè)計的數(shù)據(jù)變更方案具備可回滾能力，發(fā)布過程中所產(chǎn)生的增量數(shù)據(jù)列存儲值要求可廢棄。原則上任何應(yīng)用服務(wù)在發(fā)布之前都必須具備可回滾的能力，沒有回滾能力的系統(tǒng)不允許發(fā)布上線。

回滾操作對業(yè)務(wù)的影響： 由于應(yīng)用升級的回滾實施，必然會影響本次升級業(yè)務(wù)所服務(wù)的業(yè)務(wù)需求，同時會直接影響對本次升級有依賴的其他業(yè)務(wù)系統(tǒng)；回滾方案中必須明確本次發(fā)布窗口所有相關(guān)性需求項目，明確一旦發(fā)生回滾處理受影響范圍，提前告知相關(guān)項目組及業(yè)務(wù)方，同時盡可能降低多個業(yè)務(wù)關(guān)聯(lián)性較強項目同一發(fā)布窗口的回滾風(fēng)險。

涉及重要性較高的服務(wù)應(yīng)用升級方案要求必須提供回滾方案，且此回滾方案事先在線下環(huán)境得到完整模擬演練并確認可行；回滾完成后要求不得中斷服務(wù)，業(yè)務(wù)運行正常

2、回滾原子性

回滾的復(fù)雜性 ： 除應(yīng)用本身及數(shù)據(jù)層面的可回滾性考慮外，若服務(wù)使用客戶端已完成同步升級，則必須考量客戶端的可回滾性；極端情況下，若客戶端的本次同步升級也造成了其作為服務(wù)提供方的使用客戶端同步升級，則存在多個應(yīng)用系統(tǒng)復(fù)雜的連帶可回滾需求；相關(guān)系統(tǒng)也需要評估其應(yīng)用本身及其數(shù)據(jù)層面的可回滾能力，作為本次應(yīng)用升級回滾方案的一并考慮項。在升級方案設(shè)計中，應(yīng)該提前預(yù)知復(fù)雜回滾方案的實施成本，防止發(fā)生上述的同步升級的多重強依賴關(guān)系。回滾方案包括但不僅限于：應(yīng)用回滾、數(shù)據(jù)回滾及清理、代碼回滾、運維策略回滾、監(jiān)控方案回滾等。

切記：代碼需要及時回滾，以防在未修復(fù)問題前，下次團隊其他同事上線把未回滾代碼部署到線上導(dǎo)致二次問題發(fā)生。

3、代碼回滾之開關(guān)技術(shù)

在大部分場景下，開關(guān)技術(shù)才是線上代碼問題快速止血，快速回滾的最佳方式（需根據(jù)業(yè)務(wù)系統(tǒng)特性而定）。比如作為下單黃金鏈路，如遇線上問題的話，采用通用的回滾方式需要5-10+分鐘(500+臺機器）并且回滾如果操作不當(dāng)會加重問題,而采用開關(guān)技術(shù)則是秒級。

四、結(jié)論：

復(fù)雜需求或者高風(fēng)險需求的前提下，在架構(gòu)設(shè)計階段，應(yīng)該將灰度計劃、驗證兼容和回滾策略等考慮在內(nèi)，并做好評估與平衡。具體來說，需要考慮以下兩個方面：

1.風(fēng)險程度： 在評估系統(tǒng)穩(wěn)定性和可靠性時，需要對可能出現(xiàn)的問題和風(fēng)險進行充分的評估，并根據(jù)風(fēng)險程度制定相應(yīng)的灰度計劃、驗證兼容和回滾策略。

2.成本投入： 在進行灰度計劃、驗證兼容和回滾策略時，需要考慮相應(yīng)的成本投入，包括人力、物力、時間等方面，以確保實施計劃的可行性和經(jīng)濟性。

綜上所述，灰度計劃、驗證兼容和回滾策略等應(yīng)該在架構(gòu)設(shè)計階段就進行充分的考慮和評估，以便在實施過程中能夠做到有條不紊、穩(wěn)妥可靠。

審核編輯 黃宇