背景

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

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

圖片

一、灰度要有耐心

1、灰度意義

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

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

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

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

2、灰度發(fā)布

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

3、灰度有效性

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

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

• 制定詳細的灰度計劃：在進行灰度之前，應該制定詳細的計劃，包括灰度的范圍、時間、節(jié)點等信息，以確保灰度過程的可控性和可預測性。
• 逐步推進灰度：在進行灰度時，應該逐步推進，而不是一下子全面鋪開。比如，可以先在一個機房的一個分組中部分節(jié)點進行灰度，然后再擴大到全部節(jié)點和集群，最后再擴展到另外一個機房的相同步驟。
• 監(jiān)控和反饋：在進行灰度時，應該及時監(jiān)控和反饋，以發(fā)現(xiàn)和解決可能出現(xiàn)的問題和風險。關鍵點在于時間和流量

時間：

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

流量：

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

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

4、灰度驗證

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

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

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

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

4.2核心鏈路灰度驗證

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

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

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

4.3切量灰度

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

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

commonSwith.percent=10

5、灰度注意事項

• 灰度驗證要細心。其實跟上線一樣，主要都是依賴日志&監(jiān)控&報警規(guī)則的建設和配置。只不過灰度的比例小，通過ump監(jiān)控等報警沒有那么敏感，核心還是需要關注灰度對應logbook日志，業(yè)務上下游鏈路可視化相關驗證。
• 灰度回滾：灰度過程務必具備整體暫停回滾能力。灰度過程中發(fā)生問題，立即暫停灰度，并且把之前灰度機器操作回滾，如機器少可JSF下線或者停止機器。如灰度比例高，則不可停服務，需要快速回滾（通過ducc開關代碼隔離、或者代碼回滾）
• 灰度回滾過程中歷史數(shù)據(jù)需要糾正處理

二、驗證需要兼容

可監(jiān)控

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

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

日志

向后兼容性

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

1、制定回滾計劃

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

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

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

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

2、回滾原子性

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

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

3、代碼回滾之開關技術

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

四、結論

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

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

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

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