作者：京東物流 馮志文

背景

在軟件開發和運維領域，變更管理是一個至關重要的環節。無論是對現有系統的改進、功能的增加還是修復漏洞，變更都是不可避免的。這些變更可能涉及到軟件代碼的修改、配置的調整、服務器的擴容、三方jar包的變更等等。然而，變更的執行過程往往伴隨著一系列的風險和挑戰。變更管理對于確保系統的穩定性至關重要。只有通過有效的變更管理措施，如合理的變更計劃、全面的測試和驗證、及時的問題解決等，才能夠最大限度地減少變更帶來的風險，確保系統的穩定性和可靠性。因此，對于任何一個組織或團隊來說，都需要高度重視變更管理，并將其作為穩定性建設的重要組成部分。

一、兼容設計

在變更管控各項變更中，如果考慮好兼容設計，其整體的變更就會比較平滑，整個變更的兼容設計會從硬件、軟件、數據三個層面展開，其中軟件部分還區分基礎軟件和應用軟件，現在從以上部分展開對應的兼容設計需要考慮的原則如下描述。

1、硬件變更兼容設計

硬件平臺變更，原則上不應該影響在其之上運行的應用服務（主機硬件平臺升級，網絡設備升級，存儲設備升級，防火墻升級），所有硬件升級必須考慮線下兼容性，需要在線下環境進行詳細的測試驗證，保證生產系統變更穩定性。

2、基礎軟件變更兼容設計

任何基礎技術和系統軟件的升級，原則上不應該影響使用其的應用服務（框架，消息組件，緩存，存儲中間件，操作系統，JVM，Apache，JBoss，Tomcat等），所有基礎軟件必須考慮線下兼容性，需要在線下進行嚴格并且詳細的測試，保證生產系統變更穩定性。

案例1：mysql數據庫5.5升級5.7風險點 1、MySQL版本從5.5升級到5.7，最大的風險在于數據精度不同，尤其體現在時間類型的精度方面。 2、timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' 類型在5.5版本中，create_time雖然定義為not null ,但是實際是能插入null值，會自動轉換為current_time，5.6版本直接報錯，攔截語句插入。 3、timestamp 時間類型在5.6.4版本后支持毫秒。例如：timestamp(3)即保留3位毫秒，如果不指，則不存儲毫秒。 4、數據精度變化，5.5直接截斷，5.6、5.7版本會按4舍5入取位。關于時間類型、數值類型、浮點類型請進行嚴格驗證。 mysql更新到5.6.4 之后 , 新增了一個叫factional seconds的特性 , 可以記錄時間的毫秒值. 但是目前的數據庫是不記錄毫秒值的 , 所以會產生一個java中時間的Milliseconds超過500就會四舍五入的問題. 例如一個時間是2015-08-31 23:59:59.520 , 毫秒值超過500 , 入庫的時候 , 時間就會變成2015-09-01 00:00:00 . 下面的兩條sql就可以看出效果.

insert into money_record
values(null,1711929,'jerry1bean',NULL,NULL, 20.00, 2.00, 1250,
'2015-08-31 23:59:59.500000',NULL,NULL,NULL,'just a test',NULL);

insert into money_record
values(null,1711929,'jerry1bean',NULL,NULL, 20.00, 2.00, 1250,
'2015-08-31 23:59:59.499999',NULL,NULL,NULL,'just a test',NULL);

5、5.5版本sql where 條件的值即使傳入帶毫秒，sql解析后也不帶毫秒，5.7 查詢sql解析后會帶著毫秒，所以在范圍查詢時同樣的sql查詢的結果可能不同。

3、應用軟件變更兼容設計

應用升級方案中應該考慮應用向下兼容能力，無法完全向下兼容的應用升級過程，在聯調、預發布及正式上線過程中會引起已有業務服務的不可用，在關鍵業務路徑上的一級服務如果發生不兼容現象后果更加嚴重，會直接導致變更過程中的大量業務處理中斷，引起核心業務下跌。應用可向下兼容的評估點包括但不僅限于：服務接口、方法、入參、返回值及服務方法具體實現的向下兼容性能力；其中服務方法具體實現向下兼容是應用向下兼容能力的最核心表現。對于一、二級關鍵服務，應用升級過程中必須完全向下兼容，確保發布過程中不產生兼容性問題進而導致業務下跌或其他關鍵服務不可用。同時服務消費端設計上需要做到客戶端可不要求同步升級。

案例1：JSF默認的Msgpack序列化，接口對象里增減字段如何處理？ 【現象描述】：JSF默認的Msgpack序列化，接口對象里增減字段如何處理 【原因分析】：Msgpack是按字段順序進行序列化和反序列化的，其缺點是無法改變字段順序。 【解決方案】： 因Msgpack序列化不能改變字段順序，所以在兩邊不同時升級的情況下，字段兼容規則如下：（包括Bean和枚舉） 1、不要調整原有字段順序，不能刪減字段，除非是刪最后一個字段。 2、新加的字段必須在字段最后面（只是字段順序，不是文件最后面，getter/setter方法等隨意）。 3、父類的字段不能變。因為父類一變相當于子類的中間插入一個字段。 滿足上面規則，服務端和客戶端哪邊先升級都無所謂。 如果是需要父類加字段，或者中間加減字段這種，則需要服務端和調用端同時升級。

?

4、數據變更兼容設計

應用軟件系統升級方案往往附有數據存儲格式變更，良好的數據兼容性設計對升級后應用平穩上線起到重要的保障作用。數據兼容性設計要求設計方案遵循安全的增量變更原則，即在保障已有的數據存儲結構不發生語義變化的前提下，合理增加升級應用所必須的數據列；并且所增加數據列不對已有業務服務造成影響，如外部系統所調用的查詢服務不會中斷、業務返回結果不變。原則上，當已有數據存儲結構語義發生變化，原存儲列所存儲值業務含義發生變化時，應該通過新增存儲列來完成，避免直接復用已有存儲列或修改已有存儲列名的做法。對于重要性高的服務，數據升級后必須完全向下兼容；確實無法做到數據向下兼容的，如原有存儲列完全廢棄的，應該首先確保外圍使用系統業務改造完成后方可上線。

案例1：mysql表結構變更 背景：新需求上線，表結構需要增加個新的字段 1、代碼上線前，提交sql語句如下，字段apply_type 為not null 未給默認值，導致不兼容線上邏輯

ALTER TABLE store_capacity_approve 
ADD COLUMN apply_type tinyint(4) NOT NULL 
COMMENT 'XXX類型' AFTER match_standard;

2、但由于代碼未上線，導致線上報錯Filed 'apply_type' doesn't hava a default value

3、修改sql，給apply_type該字段添加默認值，兼容線上代碼邏輯

ALTER TABLE store_capacity_approve 
MODIFY COLUMN apply_type tinyint(4) DEFAULT 0
COMMENT 'XXX申請類型';

二、新版本發布設計

1、停機性發布

原則上建議非高優先級系統不進行停機發布。對于高優先級系統，應在系統設計階段盡量避免停機發布，如因系統拆分，數據庫拆分，整體架構升級等原因一定需要停機，需嚴格限定停機范圍、停機的時間點與停機時長。如需停機的系統及業務可以獨立發布，則除這些系統外，其他系統盡量保障采取非停機平滑發布方式。如因系統耦合度或者業務耦合度復雜無法獨立發布，則進行整體停機發布；

2、發布順序是否合理

根據系統間依賴指定合適的發布先后順序。系統發布順序遵照以下原則：禁止系統啟動依賴，無因系統啟動依賴導致的發布順序依賴；對于業務依賴，需保證無相互依賴。高優先級系統原則上不應該依賴于低優先級系統；其他系統默認無發布順序，可以根據發布進度進行無序發布。

3、發布時間點

發布時間點需盡量避開業務高峰，尤其是發布過程會對業務產生影響的核心系統。系統發布因盡量避免影響業務，如確實對業務影響較大又無法在系統設計上避免，需將發布時間點放在絕對業務低峰點。

涉及新舊功能切換。驗證切換方案地合理性，可逆性。發布過程中涉及到的新舊功能切換方案，應確保可逆，即切換失敗后能及時切回到舊功能。方案需在研發環境進行詳細測試，如無法在研發環境進行測試，需在預發布環境進行模擬測試，確保方案正確有效，可回滾。

三、灰度變更

1、灰度意義

1.我們在編碼完成后會在測試環境中進行測試驗證，這是為了找到問題和錯誤。當我們完成整個測試流程后，我們可以認為已知的問題已經得到了解決。由于測試環境與線上真實業務和用戶環境是隔離的，所以測試環境中的問題不會對線上業務和用戶造成影響。

2.灰度發布是為了驗證我們的假設，即“還存在我們不知道的問題”。因此，在進行灰度發布時需要更加謹慎，確保即使問題在生產環境中出現，也能控制其對業務和用戶的影響。通過灰度發布，我們可以逐步驗證系統的穩定性和可靠性，減少風險并提高產品質量。

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

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

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

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

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

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

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

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

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

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

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

2、部署編排灰度

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

比如這分組每次發10%，具體分組灰度比例多少需根據業務特性而定。

四、數據遷移分析

發布過程所需的數據遷移方案，需事先在線下環境進行模擬演練，反復梳理遷移過程執行步驟，將可能發生的遷移風險降到最小。數據遷移方案的可行性包括：

方案的完整性：是否本次升級內容所必須包含的待遷移數據項全部覆蓋到位。

方案的安全性：對于敏感信息如用戶隱私信息的遷移方案，是否存在由于遷移腳本的不合理導致隱私信息泄露風險。

方案的可實施性：包括數據遷移操作方案的合理度（發布過程中完成或者發布前、發布中、發布后多階段完成），相關角色配合實施步驟，同時必須考慮本項目的數據遷移方案所占用時間是否對同一發布窗口的其他項目造成影響。

方案的可檢測性：遷移過程各個階段的數據完整性、準確性檢查腳本是否準備到位。

方案的可回滾性：遷移過程中各個階段如果發生了計劃外風險，必須要終止遷移操作的，是否具備了已遷移數據回滾能力。

涉及重要性高的服務的數據遷移方案必須完整、安全、可實施、可檢測、可回滾。

案例：可參考 Redis漸進式rehash 兼容性 擴展或收縮哈希表需要將 ht[0]里面的所有鍵值對 rehash 到 ht[1]里面， 但是， 這個 rehash 動作并不是一次性、集中式地完成的， 而是分多次、漸進式地完成的。 這樣做的原因在于，如果哈希表里保存的鍵值對數量很大時， 如：四百萬、四千萬甚至四億個鍵值對， 那么一次性將這些鍵值對全部 rehash 到 ht[1] 的話，龐大的計算量(需要重新計算鏈表在桶中的位置)可能會導致服務器在一段時間內停止服務(redis是單線程的，如果全部移動會引起客戶端長時間阻塞不可用)。 因此， 為了避免 rehash 對服務器性能造成影響， 服務器不是一次性將 ht[0]里面的所有鍵值對全部 rehash 到 ht[1]， 而是分多次、漸進式地將 ht[0]里面的鍵值對慢慢地 rehash 到 ht[1]。

?

總結：漸進式 rehash 執行期間的哈希表操作 （1）刪除和查找：在進行漸進式rehash的過程中，字典會同時使用ht[0]和ht[1]兩個哈希表，所以在漸進式rehash進行期間，字典的刪除、查找、更新等操作會在兩個哈希表上進行。比如說，要在字典里面查找一個鍵的話，程序會先在ht[0]里面進行查找，如果沒找到的話，就會繼續到ht[1]里面進行查找，諸如此類 （2）新增數據：在漸進式 rehash 執行期間，新添加到字典的鍵值對一律會被保存到ht[1]里面，而ht[0]則不再進行任何添加操作。這一措施保證了ht[0]包含的鍵值對數量會只減不增，并隨著rehash操作的執行而最終變成空表。

五、可回滾設計

1、制定回滾計劃

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

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

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

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

2、回滾原子性

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

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

3、代碼回滾之開關技術

在大部分場景下，開關技術才是線上代碼問題快速止血，快速回滾的最佳方式（需根據業務系統特性而定）。如遇線上問題的話，采用通用的回滾方式需要5-10+分鐘(）并且回滾如果操作不當會加重問題,而采用開關技術則是秒級。同時Promise在處理日常迭代需求和穩定性保障方面，功能開關技術同樣發揮了重要的作用。針對改動范圍大、影響面廣的需求，我通常會問上線了最壞情況是什么？應急預案是什么？你帶開關了嗎？。當然開關也是有成本的，

4、行云部署的回滾方式

4.1、部署編排回滾

優點：回滾過程平滑，操作簡單

缺點：回滾時長與發布時長相同，時間較長。

應用場景：對于非緊急場景，我們建議使用部署編排一鍵回滾的方式。

4.2、分組回滾

優點：回滾步伐靈活可控，速度快。

缺點：需要每個分組單獨回顧。

應用場景：針對需要快速止血的場景，可以采用分組回滾的方式，這樣可以更快地恢復系統狀態。需要注意的是，我們需要設置好回滾批次間隔，以確保回滾操作不會對系統造成過大的影響。

六、配置變更控制

涉及生產配置參數的變更，原則上必須進行嚴格變更審批流程保障。所有對于生產動態配置變更由專業運維保障團隊統一操作。

動態配置能力可以從以下方面進行設計：

動態配置變更的時機：預發布變更、發布后變更等；

動態配置的可驗證：變更接收方能夠以日志等形式驗證推送的內容，否則是否推送，何時推送，推送的內容正確與否無法確證；

動態配置的生效同步性：在某動態配置涉及多個系統都需要同步時，應用需要考慮在多個系統間不同步時會出現的問題；

動態配置的容錯性處理：防止進行線上配置填寫錯誤時，系統即按照錯誤的情況運行，動態配置必須有默認值;

動態配置是否系統啟動時加載：需要系統初起時加載的內容，需要防止出現系統啟動依賴；

周期性動態配置：對于定時刷新緩存方式實現的動態配置，需要保證刷新成功后才更新或者替換緩存內容；不能在主線程中判斷和刷新緩存，而應該另起線程刷新，防止刷新緩存出現抖動或者阻塞而影響主線程的功能。

案例： 1、修改JMQ的消費策略，可能影響下游鏈路相關風險（比如依賴的下游流量、中間件等） 2、修改JSF限流，可能導致對應風險點

?

七、復核驗證

每個變更都需要有復核人，對于標準變更，復核人可只對結果進行復核。對于普通變更和重大變更，復核人需要對變更流程、變更表單、實際操作進行核對確認，對變更后的結果進行日志、監控等檢查。復核人應對變更不當而引發的問題負責。

每個變更后，需要有一系列的基于變更清單管理的效果檢查的內容。如：服務是否正常啟動，功能是否可用，性能是否正常，以及變更的內容是否符合預期。通過對變更效果進行驗證，才能最終確認本次變更是否正確。同時，針對服務相關的全局核心指標的監控，在變更期間既不應該出現異常，也不應該隨意屏蔽。

附：Promise的checklist清單及DoubleCheck機制

1、建立CheckList清單

檢查列表可以提醒人遺漏的東西、用來減少失敗，保持一致性和完整性。把checklist清單作為xbp流程中一部分，集成到了行云部署發布中，申請上線的時候必須填寫。

附：Promise上線案例之CheckList清單，包含

1、向下兼容，是否兼容之前功能

2.抽取文件檢查，比如JSF別名配置，JIMDB配置等

3.ducc配置檢查、是否新增加了開關

4.生產環境DDL檢查，比如數據庫表字段等

5.JSF別名配置，如上新接口或者服務需檢查

6.jar包相關

7.JMQ配置檢查

8.新日志文件檢查（異步）

9、代碼比對

10.上線過度方案檢查、回滾策略檢查

11.UAT環境是否測試、性能測試、R2引流驗證等

2、DoubleCheck驗證機制

小組群同步上線信息，并且執行DoubleCheck機制

那DoubleCheck驗證看哪些？

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

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

3、通過可視化界面驗證線上訂單全流程（用戶、業務角度等）。

比如xxx訂單號，預分揀環節命中了上線的機器，通過持久化頁面發現跟其他環節（轉移、worker環節）時效是一樣，并且通過OM系統查看全程跟蹤時效也是一直。說明上線的機器跟之前機器算出來時效是一直的，如果不一致，需要分析是由于業務剛修改了配置還是系統代碼問題。

4、用戶角度

總結

變更管理在穩定性建設中扮演著至關重要的角色。它涵蓋了兼容設計、新版本發布計劃、灰度變革、數據遷移、可回滾設計、配置變更控制和復核驗證等多個方面，旨在確保系統在變更過程中的穩定性和可靠性。

首先，兼容設計和新版本發布計劃是變更管理的基礎。通過充分考慮現有系統的功能和架構，我們可以預測并解決可能出現的兼容性問題。同時，制定詳細的新版本發布計劃，可以確保變更過程有序進行，避免對用戶造成不必要的影響。

其次，灰度變革和數據遷移是降低變更風險的重要手段。通過逐步引入變更，我們可以及時發現和解決問題，減少對整個系統的影響。而數據遷移則是確保用戶數據安全和完整性的關鍵步驟，需要仔細規劃和執行。

另外，可回滾設計和配置變更控制是保障變更可控性的重要措施。可回滾設計意味著我們可以隨時將系統恢復到變更前的狀態，以應對可能出現的問題。而配置變更控制則可以確保變更過程的合規性和安全性，防止未經授權的變更發生。

最后，復核驗證是確認變更有效性和正確性的關鍵步驟。通過對變更后的系統進行全面的測試和驗證，我們可以確保變更沒有引入新的問題，并且達到了預期的效果。

綜上所述，變更管理在穩定性建設中起著至關重要的作用。通過合理的變更管理措施，我們可以降低變更帶來的風險，確保系統的穩定性和可靠性。只有在充分重視和有效實施變更管理的前提下，我們才能夠建立一個穩定、可靠的系統。

?

參考：

信通院穩定性建設指南

審核編輯 黃宇