作者：京東物流 馮志文

背景

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

一、兼容設計

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

1、硬件變更兼容設計

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

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

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

案例1：mysql數(shù)據(jù)庫5.5升級5.7風險點 1、MySQL版本從5.5升級到5.7，最大的風險在于數(shù)據(jù)精度不同，尤其體現(xiàn)在時間類型的精度方面。 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、數(shù)據(jù)精度變化，5.5直接截斷，5.6、5.7版本會按4舍5入取位。關于時間類型、數(shù)值類型、浮點類型請進行嚴格驗證。 mysql更新到5.6.4 之后 , 新增了一個叫factional seconds的特性 , 可以記錄時間的毫秒值. 但是目前的數(shù)據(jù)庫是不記錄毫秒值的 , 所以會產(chǎn)生一個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、應用軟件變更兼容設計

應用升級方案中應該考慮應用向下兼容能力，無法完全向下兼容的應用升級過程，在聯(lián)調(diào)、預發(fā)布及正式上線過程中會引起已有業(yè)務服務的不可用，在關鍵業(yè)務路徑上的一級服務如果發(fā)生不兼容現(xiàn)象后果更加嚴重，會直接導致變更過程中的大量業(yè)務處理中斷，引起核心業(yè)務下跌。應用可向下兼容的評估點包括但不僅限于：服務接口、方法、入?yún)ⅰ⒎祷刂导胺辗椒ň唧w實現(xiàn)的向下兼容性能力；其中服務方法具體實現(xiàn)向下兼容是應用向下兼容能力的最核心表現(xiàn)。對于一、二級關鍵服務，應用升級過程中必須完全向下兼容，確保發(fā)布過程中不產(chǎn)生兼容性問題進而導致業(yè)務下跌或其他關鍵服務不可用。同時服務消費端設計上需要做到客戶端可不要求同步升級。

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

?

4、數(shù)據(jù)變更兼容設計

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

案例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申請類型';

二、新版本發(fā)布設計

1、停機性發(fā)布

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

2、發(fā)布順序是否合理

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

3、發(fā)布時間點

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

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

三、灰度變更

1、灰度意義

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

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

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

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

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

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

為了確?；叶鹊挠行?，需要注意以下幾個方面：

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

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

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

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

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

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

2、部署編排灰度

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

比如這分組每次發(fā)10%，具體分組灰度比例多少需根據(jù)業(yè)務特性而定。

四、數(shù)據(jù)遷移分析

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

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

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

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

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

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

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

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

?

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

五、可回滾設計

1、制定回滾計劃

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

回滾的必要性：應用上線應該制定詳盡的回滾計劃，能夠在最短時間內(nèi)將應用恢復至上一穩(wěn)定運行版本；然而系統(tǒng)并不是天然可以無縫回滾的，想要系統(tǒng)具備回滾的能力，在設計與實現(xiàn)階段需要付出額外的精力?？苫貪L的本質是系統(tǒng)的兼容性設計與實現(xiàn)，比如常見的“只增不改”，一個 API 內(nèi)要調(diào)整很多實現(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+分鐘(）并且回滾如果操作不當會加重問題,而采用開關技術則是秒級。同時Promise在處理日常迭代需求和穩(wěn)定性保障方面，功能開關技術同樣發(fā)揮了重要的作用。針對改動范圍大、影響面廣的需求，我通常會問上線了最壞情況是什么？應急預案是什么？你帶開關了嗎？。當然開關也是有成本的，

4、行云部署的回滾方式

4.1、部署編排回滾

優(yōu)點：回滾過程平滑，操作簡單

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

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

4.2、分組回滾

優(yōu)點：回滾步伐靈活可控，速度快。

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

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

六、配置變更控制

涉及生產(chǎn)配置參數(shù)的變更，原則上必須進行嚴格變更審批流程保障。所有對于生產(chǎn)動態(tài)配置變更由專業(yè)運維保障團隊統(tǒng)一操作。

動態(tài)配置能力可以從以下方面進行設計：

動態(tài)配置變更的時機：預發(fā)布變更、發(fā)布后變更等；

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

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

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

動態(tài)配置是否系統(tǒng)啟動時加載：需要系統(tǒng)初起時加載的內(nèi)容，需要防止出現(xiàn)系統(tǒng)啟動依賴；

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

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

?

七、復核驗證

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

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

附：Promise的checklist清單及DoubleCheck機制

1、建立CheckList清單

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

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

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

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

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

4.生產(chǎn)環(huán)境DDL檢查，比如數(shù)據(jù)庫表字段等

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

6.jar包相關

7.JMQ配置檢查

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

9、代碼比對

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

11.UAT環(huán)境是否測試、性能測試、R2引流驗證等

2、DoubleCheck驗證機制

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

那DoubleCheck驗證看哪些？

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

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

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

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

4、用戶角度

總結

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

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

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

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

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

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

?

參考：

信通院穩(wěn)定性建設指南

審核編輯 黃宇