穩(wěn)定性建設(shè)之變更管理

作者：京東物流 馮志文

背景

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

一、兼容設(shè)計

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

1、硬件變更兼容設(shè)計

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

2、基礎(chǔ)軟件變更兼容設(shè)計

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

案例1：mysql數(shù)據(jù)庫5.5升級5.7風(fēng)險點 1、MySQL版本從5.5升級到5.7，最大的風(fēng)險在于數(shù)據(jù)精度不同，尤其體現(xiàn)在時間類型的精度方面。 2、timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' 類型在5.5版本中，create_time雖然定義為not null ,但是實際是能插入null值，會自動轉(zhuǎn)換為current_time，5.6版本直接報錯，攔截語句插入。 3、timestamp 時間類型在5.6.4版本后支持毫秒。例如：timestamp(3)即保留3位毫秒，如果不指，則不存儲毫秒。 4、數(shù)據(jù)精度變化，5.5直接截斷，5.6、5.7版本會按4舍5入取位。關(guān)于時間類型、數(shù)值類型、浮點類型請進(jìn)行嚴(yán)格驗證。 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查詢的結(jié)果可能不同。

3、應(yīng)用軟件變更兼容設(shè)計

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

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

?

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

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

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

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

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

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

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

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

1、停機性發(fā)布

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

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

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

3、發(fā)布時間點

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

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

三、灰度變更

1、灰度意義

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

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

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

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

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

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

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

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

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

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

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

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

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

2、部署編排灰度

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

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

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

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

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

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

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

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

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

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

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

?

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

五、可回滾設(shè)計

1、制定回滾計劃

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

回滾的必要性：應(yīng)用上線應(yīng)該制定詳盡的回滾計劃，能夠在最短時間內(nèi)將應(yīng)用恢復(fù)至上一穩(wěn)定運行版本；然而系統(tǒng)并不是天然可以無縫回滾的，想要系統(tǒng)具備回滾的能力，在設(shè)計與實現(xiàn)階段需要付出額外的精力?？苫貪L的本質(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)境得到完整模擬演練并確認(rè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ù)問題前，下次團(tuán)隊其他同事上線把未回滾代碼部署到線上導(dǎo)致二次問題發(fā)生。

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

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

4、行云部署的回滾方式

4.1、部署編排回滾

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

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

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

4.2、分組回滾

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

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

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

六、配置變更控制

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

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

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

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

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

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

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

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

案例： 1、修改JMQ的消費策略，可能影響下游鏈路相關(guān)風(fēng)險（比如依賴的下游流量、中間件等） 2、修改JSF限流，可能導(dǎo)致對應(yīng)風(fēng)險點

?

七、復(fù)核驗證

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

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

附：Promise的checklist清單及DoubleCheck機制

1、建立CheckList清單

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

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

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

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

3.ducc配置檢查、是否新增加了開關(guān)

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

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

6.jar包相關(guān)

7.JMQ配置檢查

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

9、代碼比對

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

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

2、DoubleCheck驗證機制

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

那DoubleCheck驗證看哪些？

1、對外核心接口UMP（TP99、可用率、流量）或者M(jìn)Q 等，這個沒什么好講的。

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

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

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

4、用戶角度

總結(jié)

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

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

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

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

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

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

?

參考：

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

審核編輯 黃宇