作者：京東物流 馮志文

背景

從研發的流程階段來看，在確定產品需求后，我們會經歷架構設計、編碼、測試、聯調驗證和上線這幾個階段來交付系統。在這個過程中，我們需要特別關注上線環節，因為它是事故高發的階段。

為了應對這種情況，我們實施了嚴格的發布標準操作程序，簡稱為“發布三板斧”。這包括可灰度發布、可驗證發布和可回滾發布。通過這三個步驟，我們可以確保在發布過程中盡量減少風險，提高系統的穩定性和可靠性。

一、灰度要有耐心

1、灰度意義

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

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

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

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

2、灰度發布

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

3、灰度有效性

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

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

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

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

3.監控和反饋：在進行灰度時，應該及時監控和反饋，以發現和解決可能出現的問題和風險。關鍵點在于時間和流量

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

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

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

4、灰度驗證

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

4.1、新功能業務灰度：

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

操作步驟：代碼無開關，代碼上線確保不影響老邏輯即可。通過業務線上灰度驗證相關邏輯準確性

4.2、核心鏈路灰度驗證

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

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

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

4.3、切量灰度

適用場景：比如重構、技術改造、黃金鏈路上線的重要功能

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

commonSwith.percent=10

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

5、灰度注意事項

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

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

3.灰度回滾過程中歷史數據需要糾正處理

二、驗證需要兼容

1、可監控

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

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

2、日志

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

3、向后兼容性

功能A上線，驗證A功能沒問題后，需要看下其他功能是否有問題（比如系統的核心環節功能）。

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

1、制定回滾計劃

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

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

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

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

2、回滾原子性

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

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

3、代碼回滾之開關技術

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

四、結論：

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

1.風險程度： 在評估系統穩定性和可靠性時，需要對可能出現的問題和風險進行充分的評估，并根據風險程度制定相應的灰度計劃、驗證兼容和回滾策略。

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

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

審核編輯 黃宇