作者：京東物流 馮志文

背景

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

一、兼容設(shè)計(jì)

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

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

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

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

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

案例1：mysql數(shù)據(jù)庫(kù)5.5升級(jí)5.7風(fēng)險(xiǎn)點(diǎn) 1、MySQL版本從5.5升級(jí)到5.7，最大的風(fēng)險(xiǎn)在于數(shù)據(jù)精度不同，尤其體現(xiàn)在時(shí)間類型的精度方面。 2、timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' 類型在5.5版本中，create_time雖然定義為not null ,但是實(shí)際是能插入null值，會(huì)自動(dòng)轉(zhuǎn)換為current_time，5.6版本直接報(bào)錯(cuò)，攔截語(yǔ)句插入。 3、timestamp 時(shí)間類型在5.6.4版本后支持毫秒。例如：timestamp(3)即保留3位毫秒，如果不指，則不存儲(chǔ)毫秒。 4、數(shù)據(jù)精度變化，5.5直接截?cái)啵?.6、5.7版本會(huì)按4舍5入取位。關(guān)于時(shí)間類型、數(shù)值類型、浮點(diǎn)類型請(qǐng)進(jìn)行嚴(yán)格驗(yàn)證。 mysql更新到5.6.4 之后 , 新增了一個(gè)叫factional seconds的特性 , 可以記錄時(shí)間的毫秒值. 但是目前的數(shù)據(jù)庫(kù)是不記錄毫秒值的 , 所以會(huì)產(chǎn)生一個(gè)java中時(shí)間的Milliseconds超過(guò)500就會(huì)四舍五入的問(wèn)題. 例如一個(gè)時(shí)間是2015-08-31 23:59:59.520 , 毫秒值超過(guò)500 , 入庫(kù)的時(shí)候 , 時(shí)間就會(huì)變成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解析后會(huì)帶著毫秒，所以在范圍查詢時(shí)同樣的sql查詢的結(jié)果可能不同。

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

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

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

?

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

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

案例1：mysql表結(jié)構(gòu)變更 背景：新需求上線，表結(jié)構(gòu)需要增加個(gè)新的字段 1、代碼上線前，提交sql語(yǔ)句如下，字段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)致線上報(bào)錯(cuò)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申請(qǐng)類型';

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

1、停機(jī)性發(fā)布

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

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

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

3、發(fā)布時(shí)間點(diǎn)

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

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

三、灰度變更

1、灰度意義

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

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

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

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

5.灰度發(fā)布是一種有效的風(fēng)險(xiǎn)管理方法，可以幫助我們?cè)谲浖_(kāi)發(fā)過(guò)程中識(shí)別和解決潛在的問(wèn)題，提高產(chǎn)品質(zhì)量和用戶體驗(yàn)。

在灰度的落地與推進(jìn)過(guò)程中，有效性非常重要。因?yàn)榛叶仁且粋€(gè)很耗時(shí)的復(fù)雜的過(guò)程。如果不注意的話，很容易出現(xiàn)“形式化”的情況，即只是表面上的灰度，而實(shí)際上并沒(méi)有達(dá)到預(yù)期的效果。

為了確?；叶鹊挠行裕枰⒁庖韵聨讉€(gè)方面：

1.制定詳細(xì)的灰度計(jì)劃：在進(jìn)行灰度之前，應(yīng)該制定詳細(xì)的計(jì)劃，包括灰度的范圍、時(shí)間、節(jié)點(diǎn)等信息，以確保灰度過(guò)程的可控性和可預(yù)測(cè)性。

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

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

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

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

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

2、部署編排灰度

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

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

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

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

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

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

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

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

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

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

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

?

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

五、可回滾設(shè)計(jì)

1、制定回滾計(jì)劃

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

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

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

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

2、回滾原子性

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

切記：代碼需要及時(shí)回滾，以防在未修復(fù)問(wèn)題前，下次團(tuán)隊(duì)其他同事上線把未回滾代碼部署到線上導(dǎo)致二次問(wèn)題發(fā)生。

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

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

4、行云部署的回滾方式

4.1、部署編排回滾

優(yōu)點(diǎn)：回滾過(guò)程平滑，操作簡(jiǎn)單

缺點(diǎn)：回滾時(shí)長(zhǎng)與發(fā)布時(shí)長(zhǎng)相同，時(shí)間較長(zhǎng)。

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

4.2、分組回滾

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

缺點(diǎn)：需要每個(gè)分組單獨(dú)回顧。

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

六、配置變更控制

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

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

動(dòng)態(tài)配置變更的時(shí)機(jī)：預(yù)發(fā)布變更、發(fā)布后變更等；

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

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

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

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

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

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

?

七、復(fù)核驗(yàn)證

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

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

附：Promise的checklist清單及DoubleCheck機(jī)制

1、建立CheckList清單

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

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

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

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

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

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

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

6.jar包相關(guān)

7.JMQ配置檢查

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

9、代碼比對(duì)

10.上線過(guò)度方案檢查、回滾策略檢查

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

2、DoubleCheck驗(yàn)證機(jī)制

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

那DoubleCheck驗(yàn)證看哪些？

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

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

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

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

4、用戶角度

總結(jié)

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

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

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

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

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

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

?

參考：

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

審核編輯 黃宇