自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

【穩(wěn)定性】上線三板斧(可灰度、可驗(yàn)證、可回滾)

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

背景

從研發(fā)的流程階段來看,在確定產(chǎn)品需求后,我們會經(jīng)歷架構(gòu)設(shè)計(jì)、編碼、測試、聯(lián)調(diào)驗(yàn)證和上線這幾個階段來交付系統(tǒng)。在這個過程中,我們需要特別關(guān)注上線環(huán)節(jié),因?yàn)樗鞘鹿矢甙l(fā)的階段。

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

圖片圖片

一、灰度要有耐心

1、灰度意義

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

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

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

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

2、灰度發(fā)布

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

3、灰度有效性

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

為了確?;叶鹊挠行裕枰⒁庖韵聨讉€方面:

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

時間:

每個灰度階段至少有 5 ~ 10 分鐘的觀察時間,這個時間可以根據(jù)業(yè)務(wù)系統(tǒng)的具體情況進(jìn)行調(diào)整。在觀察期間,需要密切關(guān)注監(jiān)控、日志和各方反饋等信息,以發(fā)現(xiàn)和解決可能出現(xiàn)的問題和風(fēng)險(xiǎn)。只有當(dāng)這些信息沒有異常時,才能擴(kuò)大灰度范圍,進(jìn)一步推廣灰度計(jì)劃。在灰度過程中,需要保持高度警惕和敏銳的洞察力,及時發(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)在實(shí)際使用中的穩(wěn)定性和可靠性。因此,在進(jìn)行灰度測試時,需要確保有足夠的有效流量來觸發(fā)這些特定的業(yè)務(wù)場景。同時,還需要注意監(jiān)控和日志等信息,及時發(fā)現(xiàn)和解決可能出現(xiàn)的問題和風(fēng)險(xiǎn)。通過這種方式,可以更好地保證系統(tǒng)的穩(wěn)定和可靠性,提高灰度測試的效果和價(jià)值。

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

4、灰度驗(yàn)證

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

4.1新功能業(yè)務(wù)灰度:

適用場景:新的鏈路功能,比如提供新的API,跟歷史代碼邏輯無關(guān)

操作步驟:代碼無開關(guān),代碼上線確保不影響老邏輯即可。通過業(yè)務(wù)線上灰度驗(yàn)證相關(guān)邏輯準(zhǔn)確性

4.2核心鏈路灰度驗(yàn)證

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

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

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

4.3切量灰度

適用場景:比如重構(gòu)、技術(shù)改造、黃金鏈路上線的重要功能

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

commonSwith.percent=10
切量比例需要注意hashCode() 返回值為負(fù)數(shù),潛在的放大了期望的切量比例。

5、灰度注意事項(xiàng)

  • 灰度驗(yàn)證要細(xì)心。其實(shí)跟上線一樣,主要都是依賴日志&監(jiān)控&報(bào)警規(guī)則的建設(shè)和配置。只不過灰度的比例小,通過ump監(jiān)控等報(bào)警沒有那么敏感,核心還是需要關(guān)注灰度對應(yīng)logbook日志,業(yè)務(wù)上下游鏈路可視化相關(guān)驗(yàn)證。
  • 灰度回滾:灰度過程務(wù)必具備整體暫?;貪L能力?;叶冗^程中發(fā)生問題,立即暫?;叶龋⑶野阎盎叶葯C(jī)器操作回滾,如機(jī)器少可JSF下線或者停止機(jī)器。如灰度比例高,則不可停服務(wù),需要快速回滾(通過ducc開關(guān)代碼隔離、或者代碼回滾)
  • 灰度回滾過程中歷史數(shù)據(jù)需要糾正處理

二、驗(yàn)證需要兼容

可監(jiān)控

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

核心接口UMP(TP99、可用率、流量)或者M(jìn)Q 等,這個沒什么好講的

日志

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

向后兼容性

功能A上線,驗(yàn)證A功能沒問題后,需要看下其他功能是否有問題(比如系統(tǒng)的核心環(huán)節(jié)功能)。

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

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

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

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

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

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

2、回滾原子性

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

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

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

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

四、結(jié)論

復(fù)雜需求或者高風(fēng)險(xiǎn)需求的前提下,在架構(gòu)設(shè)計(jì)階段,應(yīng)該將灰度計(jì)劃、驗(yàn)證兼容和回滾策略等考慮在內(nèi),并做好評估與平衡。具體來說,需要考慮以下兩個方面:

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

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

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


責(zé)任編輯:武曉燕 來源: 京東云開發(fā)者
相關(guān)推薦

2019-09-06 11:12:53

2013-07-03 11:13:58

DevOps

2014-07-29 11:25:18

LinuxMySQL

2011-03-09 15:23:25

Windows Ser

2020-09-03 15:32:08

Wireshark數(shù)據(jù)包分析

2017-03-23 10:54:58

LINUXMYSQL優(yōu)化

2017-08-21 23:50:45

線上內(nèi)存OOM

2009-02-19 10:20:00

2012-11-08 16:05:23

2020-11-18 08:17:14

Java源碼Class

2020-03-09 13:37:49

Serverless無服務(wù)器騰訊云

2019-05-30 14:30:42

技術(shù)管理架構(gòu)

2022-07-22 09:55:29

軟件工程師

2022-05-07 11:47:36

服務(wù)器架構(gòu)

2021-02-15 22:07:18

項(xiàng)目策略模式

2023-04-26 18:36:13

2019-08-13 16:23:19

JavaScript數(shù)組方法

2010-05-28 09:17:45

ARM服務(wù)器

2021-03-29 17:51:00

瑞數(shù)信息攻防演練

2010-12-29 10:29:31

Linux磁盤管理dfdu
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號