电竞比分网-中国电竞赛事及体育赛事平台

分享

五年磨一劍:滴滴順風(fēng)車服務(wù)端之穩(wěn)定性規(guī)范

 airen89 2020-06-15

桔妹導(dǎo)讀:本文給出其中穩(wěn)定性相關(guān)的規(guī)范,這些規(guī)范都是順風(fēng)車成立五年來,對大量真實(shí)線上故障復(fù)盤、總結(jié)得到的,希望對大家服務(wù)的穩(wěn)定性提升有所幫助。

本文轉(zhuǎn)自:滴滴技術(shù)

服務(wù)端作為順風(fēng)車技術(shù)部內(nèi)最大的工程團(tuán)隊(duì),隨著人員的擴(kuò)張和迭代,流程規(guī)范在其中扮演著原來越重要的角色。一方面規(guī)范化可以提高我們的交付質(zhì)量、交付效率,另一方面,我們也希望在一次次的實(shí)戰(zhàn)中不斷的總結(jié),探索出適用于我們團(tuán)隊(duì)的最佳實(shí)踐。

基于此,我們制定并推廣了一套適用于服務(wù)端開發(fā)的可執(zhí)行、最小限制的工程規(guī)范,包括研發(fā)流程、穩(wěn)定性、性能成本等多個(gè)方面。

本文給出其中穩(wěn)定性相關(guān)的規(guī)范,這些規(guī)范都是順風(fēng)車成立五年來,對大量真實(shí)線上故障復(fù)盤、總結(jié)得到的,希望對大家服務(wù)的穩(wěn)定性提升有所幫助。

1

名詞解釋

下文的描述中,會(huì)用到很多的技術(shù)名詞,為更容易的理解,在這里對這些名詞做下簡要說明:

  • 服務(wù)分級(jí): 

    根據(jù)業(yè)務(wù)需要,一般的我們需要針對最小系統(tǒng)劃分為一級(jí)服務(wù),一旦出問題需要第一優(yōu)先級(jí)跟進(jìn)。我們將影響業(yè)務(wù)核心指標(biāo)(比如發(fā)單量、成單量等)的服務(wù)定義為一級(jí)服務(wù),其他為二級(jí)服務(wù)。

  • 預(yù)覽集群: 和線上生產(chǎn)環(huán)境的部署完全一致的一套環(huán)境,只是無線上流量,可以內(nèi)部訪問,集群內(nèi)流量閉環(huán)。

  • 小流量集群: 和線上生產(chǎn)環(huán)境的部署完全一致的一套環(huán)境,通過流量控制,只有個(gè)別城市的流量會(huì)落到此集群,集群內(nèi)流量閉環(huán)。

  • 灰度發(fā)布: 將發(fā)布過程分為預(yù)覽集群、灰度城市集群、10%流量、50%流量、100%流量的發(fā)布機(jī)制,確保安全上線過程。

  • 全鏈路壓測: 在不影響線上服務(wù)的前提下,對生產(chǎn)環(huán)境進(jìn)行壓力測試的解決方案。用以摸清生產(chǎn)環(huán)境的容量、瓶頸點(diǎn)等。

  • 機(jī)房多活: 通過多機(jī)房部署,當(dāng)一個(gè)機(jī)房出現(xiàn)故障時(shí),可以快速將流量切到其他機(jī)房,以減少損失。涉及流量路由、流量閉環(huán)、數(shù)據(jù)同步、數(shù)據(jù)一致性、災(zāi)難應(yīng)對等諸多環(huán)節(jié)的整套解決方案。




2. 

穩(wěn)定性規(guī)范

部署和運(yùn)維
  1. 【強(qiáng)制】嚴(yán)禁在臨時(shí)腳本中未通過接口或封裝方法,直接操作線上數(shù)據(jù),如有需要,必須經(jīng)過QA測試;

  2. 【強(qiáng)制】服務(wù)上線必須通過上線平臺(tái),并接入質(zhì)量平臺(tái)(功能包括自動(dòng)化case、核心曲線圖及其他上線checklist),強(qiáng)制停留觀察’

  3. 【強(qiáng)制】一級(jí)服務(wù)需要包含預(yù)覽集群、小流量集群(除部分特殊服務(wù))并且雙機(jī)房部署;

  4. 【建議】非一級(jí)線上服務(wù)建議包含預(yù)覽集群;

  5. 【建議】新服務(wù)上線建議進(jìn)行容量規(guī)劃,建議通過接口壓測或全流量壓測驗(yàn)證模塊容量。

監(jiān)控告警

  1. 【強(qiáng)制】線上服務(wù)機(jī)器必須有基礎(chǔ)監(jiān)控報(bào)警,包含CPU、IO、內(nèi)存、磁盤、coredump、端口;

  2. 【強(qiáng)制】線上服務(wù)必須有基礎(chǔ)的服務(wù)監(jiān)控,包括接口qps、fatal數(shù)量、耗時(shí);
  3. 【建議】核心業(yè)務(wù)指標(biāo)(發(fā)單量、搶單量、支付量等)必須有監(jiān)控和報(bào)警;
  4. 【建議】需要有服務(wù)整體大盤,能夠涵蓋該方向核心模塊監(jiān)控,方便快速定位服務(wù)問題。

預(yù)案管理

  1. 【強(qiáng)制】必須有多活切流預(yù)案,且需要保障有效性,必須定期組織演練,建議1月1次;
  2. 【強(qiáng)制】全鏈路壓測通道需要保證有效性,定期組織壓測;
  3. 【強(qiáng)制】一鍵限流預(yù)案需要保障有效性,定期review和演練;
  4. 【強(qiáng)制】強(qiáng)依賴降級(jí)預(yù)案需要保障有效性,定期演練。

3.1.容災(zāi)和容錯(cuò)設(shè)計(jì)

反模式3.1.1 

過度的節(jié)點(diǎn)熔斷策略

【實(shí)例】

為了提高請求成功率,在下游故障時(shí)對下游節(jié)點(diǎn)采取熔斷措施,比如1分鐘內(nèi)連續(xù)出現(xiàn)5次訪問出錯(cuò),則將該節(jié)點(diǎn)熔斷,不再調(diào)用(過一段時(shí)間后再恢復(fù)),某天網(wǎng)絡(luò)抖動(dòng),下游服務(wù)4個(gè)實(shí)例中的3個(gè)均進(jìn)入熔斷模式,導(dǎo)致訪問下游的所有流量均落到剩余的這個(gè)實(shí)例上,壓力過大,將該實(shí)例壓垮。下游服務(wù)雪崩,整個(gè)系統(tǒng)不可用。

【解決方案】

熔斷模式下,還需要有熔斷保護(hù)措施,避免過度熔斷帶來的穩(wěn)定性問題。

反模式3.1.2 
固定的重試序列

【實(shí)例】

每次重試序列都為“下一臺(tái)”。

【后果】
一個(gè)是雪崩:假設(shè)某一類 query 的重試序列為A B,當(dāng) A 出現(xiàn)故障時(shí),B 要承受兩倍的壓力,如果 B 扛不住,那么 B 的下一個(gè)也會(huì)被壓垮;一個(gè)是上線損失流量:假設(shè)重試次數(shù)是2,上線時(shí)如果 A 和 B 同時(shí)重啟,那么重試序列為 A B的 query 必然無結(jié)果。

【解決方案】
評估新的重試算法,比如隨機(jī)重試。不過相對于固定的重試序列,隨機(jī)重試序列也可能給系統(tǒng)帶來風(fēng)險(xiǎn),例如可能會(huì)降低下游模塊的cache命中率,降低系統(tǒng)性能。

反模式3.1.3 
不合理的超時(shí)設(shè)置

【實(shí)例】

上游服務(wù)超時(shí)時(shí)間設(shè)置不合理,下游出現(xiàn)問題時(shí),直接把上游服務(wù)拖垮。

【解決方案】
應(yīng)該根據(jù)鏈路的99分位耗時(shí)來設(shè)置超時(shí)時(shí)間,同時(shí)定期對鏈路的通信相關(guān)配置進(jìn)行review。

反模式3.1.4 
未考慮同一請求中多次調(diào)用下游的影響

【實(shí)例】
服務(wù)調(diào)用下游時(shí)超時(shí)時(shí)間設(shè)置沒有問題,但同一請求中會(huì)串行多次調(diào)用某個(gè)下游服務(wù),下游服務(wù)故障時(shí),也會(huì)把上游服務(wù)直接拖垮。

【解決方案】
除了考慮對下游服務(wù)的單次超時(shí),還需要考慮對下游服務(wù)的總體超時(shí)。

反模式3.1.5 
不合理的重試邏輯

【實(shí)例】
整條鏈路多個(gè)地方有重試,下游服務(wù)故障時(shí),重試被放大,導(dǎo)致服務(wù)雪崩。

【解決方案】
評估重試機(jī)制,梳理請求處理的整個(gè)鏈路,保證重試收斂在一個(gè)地方。

反模式3.1.6 
沒有考慮到業(yè)務(wù)毛刺的影響
【實(shí)例】
某業(yè)務(wù)形態(tài)有個(gè)特點(diǎn),在半點(diǎn)和整點(diǎn)時(shí)刻有請求尖刺,某次受節(jié)假日影響,訪問下游的流量瞬間暴增,導(dǎo)致下游服務(wù)雪崩。

【解決方案】
對業(yè)務(wù)尖刺進(jìn)行平衡處理,減少對下游服務(wù)的峰值流量沖擊。

反模式3.1.7 
沒有對異常輸入進(jìn)行容錯(cuò)處理

【實(shí)例】
業(yè)務(wù)沒有對異常輸入進(jìn)行容錯(cuò)處理,仍然按照正常邏輯處理,導(dǎo)致數(shù)據(jù)混亂。

【解決方案】
業(yè)務(wù)特別是業(yè)務(wù)入口,必須對不合理的異常輸入進(jìn)行容錯(cuò)處理,保證整個(gè)系統(tǒng)的健壯性。

反模式3.1.8 
接口不支持冪等性設(shè)計(jì)
【實(shí)例】
接口不支持冪等性,網(wǎng)絡(luò)故障時(shí)引發(fā)大量的重試,導(dǎo)致核心數(shù)據(jù)大量出錯(cuò)。

【解決方案】
接口設(shè)計(jì)的時(shí)候就需要考慮冪等性的需求。

反模式3.1.9 
沒有對非核心流程弱依賴化

【實(shí)例】
沒有對流程進(jìn)行弱依賴化,導(dǎo)致系統(tǒng)整體上比較脆弱,每個(gè)依賴單元故障都會(huì)導(dǎo)致整個(gè)業(yè)務(wù)癱瘓。

【解決方案】
定期對系統(tǒng)的流程進(jìn)行梳理,最小系統(tǒng)化,非必須流程盡量弱依賴化。

反模式3.1.10 
沒有考慮ID溢出的影響

【實(shí)例】
某ID使用int32,超出后ID溢出,導(dǎo)出服務(wù)異常。

【解決方案】
增加資源相關(guān)的ID字段時(shí)要考慮ID的范圍,是否有溢出風(fēng)險(xiǎn)
定期對資源相關(guān)的ID字段進(jìn)行review,提前預(yù)防,最大限度防止故障的發(fā)生

3.4.變更管理

反模式3.4.1 
代碼搭車上線

【實(shí)例】
由于缺乏有效的代碼修改管理機(jī)制,某產(chǎn)品線由于代碼搭車上線,出現(xiàn)過多次線上故障
并且由于變更時(shí)涉及的修改比較多,導(dǎo)致問題定位和追查時(shí)非常困難

【解決方案】
建立嚴(yán)格的代碼管理機(jī)制,嚴(yán)禁代碼搭車上線,保證任何時(shí)刻主干沒有未上線驗(yàn)證的代碼

反模式3.4.2 
服務(wù)回滾時(shí)遺漏回滾代碼

【實(shí)例】
上線出現(xiàn)問題,服務(wù)回滾后沒有第一時(shí)間把代碼回滾掉。第二天其他同學(xué)上線時(shí)將未回滾的問題代碼再次帶上線,上線時(shí)導(dǎo)致連續(xù)兩天出現(xiàn)系統(tǒng)故障

【解決方案】
服務(wù)回滾的時(shí)候同時(shí)第一時(shí)間回滾代碼

反模式3.4.3 
過高的并發(fā)部署設(shè)置

【實(shí)例】
部署配置的并發(fā)個(gè)數(shù)太高,導(dǎo)致同一時(shí)刻只有少數(shù)機(jī)器可用,引發(fā)集群雪崩

【解決方案】
服務(wù)部署配置的并發(fā)個(gè)數(shù),要保證剩余機(jī)器能夠承載業(yè)務(wù)全部流量

反模式3.4.4 
服務(wù)啟動(dòng)或回滾時(shí)間過長

【實(shí)例】
服務(wù)上線異常,回滾時(shí)單個(gè)服務(wù)回滾時(shí)間太長,導(dǎo)致未能短時(shí)間內(nèi)快速止損

【解決方案】
定期檢查服務(wù)的啟動(dòng)和回滾時(shí)間,保證出現(xiàn)故障時(shí)可以第一時(shí)間完成回滾操作

反模式3.4.5 
配置文件缺少有效的校驗(yàn)機(jī)制

【實(shí)例】
配置文件由模型產(chǎn)出,數(shù)據(jù)配送系統(tǒng)實(shí)時(shí)配送到線上服務(wù),模型產(chǎn)生的配置文件有問題,引發(fā)線上故障

【解決方案】
針對配置文件,尤其是模型產(chǎn)出的配置文件,建立嚴(yán)格的檢查和校驗(yàn)機(jī)制

反模式3.4.6 
配置變更沒有灰度

【實(shí)例】
配置相關(guān)修改,穩(wěn)定性意識(shí)上重視度不夠,沒有進(jìn)行足夠的觀察和灰度,導(dǎo)致故障

【解決方案】
所有變更,包括服務(wù)變更、配置變更、數(shù)據(jù)變更以及環(huán)境變更,都需要進(jìn)行嚴(yán)格的觀察和灰度,保證變更的質(zhì)量

反模式3.4.7 
變更沒有經(jīng)過嚴(yán)格的測試

【實(shí)例】
變更較小,感覺沒有必要進(jìn)行測試,結(jié)果出現(xiàn)低級(jí)錯(cuò)誤,導(dǎo)致故障

【解決方案】
任何變更都要測試、double check,修改一行代碼,也可能導(dǎo)致線上的穩(wěn)定性故障

反模式3.4.8 
變更時(shí)沒有嚴(yán)格按照變更規(guī)范執(zhí)行

【實(shí)例】
上線時(shí),小流量和A機(jī)房均嚴(yán)格按照規(guī)范檢查,服務(wù)和各種曲線沒有問題,上線B機(jī)房時(shí)沒有進(jìn)行檢查。結(jié)果B機(jī)房出現(xiàn)故障。
經(jīng)排查是因?yàn)锽機(jī)房配置缺失

【解決方案】
任何變更都要嚴(yán)格按照變更規(guī)范嚴(yán)格檢查,上線的每個(gè)階段都要檢查服務(wù)的各種曲線和指標(biāo)

反模式3.4.9 
離線直接通過sql更新db數(shù)據(jù)

【實(shí)例】
直接通過sql進(jìn)行離線更新數(shù)據(jù)庫,沒有做好限流保護(hù),導(dǎo)致db壓力大,線上服務(wù)訪問時(shí)出現(xiàn)大量超時(shí)

【解決方案】
  • 除非特殊情況,嚴(yán)禁直接通過sql操作db數(shù)據(jù),修改需通過接口修改,方便通過曲線觀察,也可降低直接改庫的風(fēng)險(xiǎn);

  • 批量修改db數(shù)據(jù)需要通報(bào)dba,經(jīng)過review,確認(rèn)沒有問題時(shí)才可以進(jìn)行操作;

  • 批量增改、增加數(shù)據(jù)務(wù)必做好限流措施。


3.7.穩(wěn)定性原則和意識(shí)

反模式3.7.1 
對穩(wěn)定性缺乏敬畏之心

【實(shí)例】
以為服務(wù)出故障是正常的,對穩(wěn)定性不以為然

【解決方案】
技術(shù)同學(xué)需要對代碼、線上穩(wěn)定性保持敬畏之心,不能有任何僥幸心理
一行代碼的bug,就可能導(dǎo)致整個(gè)業(yè)務(wù)癱瘓掉

反模式3.7.2 
故障時(shí)沒有第一時(shí)間止損

【實(shí)例】
服務(wù)出現(xiàn)故障時(shí),相關(guān)同學(xué)第一時(shí)間在定位故障原因,沒有第一時(shí)間進(jìn)行止損

【解決方案】
出現(xiàn)故障必須第一優(yōu)先級(jí)處理,第一時(shí)間止損

反模式3.7.3 
使用未充分驗(yàn)證過的技術(shù)和方案

【實(shí)例】
某服務(wù)使用了mq的廣播特性,該特性在公司還沒有在線上被使用過,上線后觸發(fā)mq廣播消費(fèi)代碼中的一個(gè)bug,導(dǎo)致mq集群不可用的故障

【解決方案】
盡量避免使用未充分驗(yàn)證過的技術(shù)和方案
如果因?yàn)槟承┰虮仨毷褂茫欢ㄒ邢鄳?yīng)的兜底措施,同時(shí)控制好接入的節(jié)奏
在非關(guān)鍵服務(wù)上驗(yàn)證充分后,才能應(yīng)用到核心鏈路上

反模式3.7.4 
使用新技術(shù)時(shí)未控制好接入節(jié)奏

【實(shí)例】
某服務(wù)使用了mq的廣播特性,在非核心服務(wù)驗(yàn)證時(shí)間不夠的情況下,將此特性引入核心服務(wù),核心服務(wù)的流量比較大,觸發(fā)mq廣播消費(fèi)代碼中的一個(gè)bug,導(dǎo)致mq集群不可用的故障

【解決方案】
引入新技術(shù)時(shí)一定要控制好接入的節(jié)奏
在非關(guān)鍵服務(wù)上驗(yàn)證充分后,才能應(yīng)用到核心鏈路上

反模式3.7.5 
穩(wěn)定性改進(jìn)方案未及時(shí)落實(shí)

【實(shí)例】
某服務(wù)出現(xiàn)故障,復(fù)盤時(shí)制定了相應(yīng)的改進(jìn)措施,但是未及時(shí)有效落實(shí);后該問題再次爆發(fā),又一次服務(wù)故障。

【解決方案】
建立改進(jìn)措施落實(shí)的有效跟蹤機(jī)制,保證改進(jìn)措施的有效落實(shí)。

    本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點(diǎn)。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點(diǎn)擊一鍵舉報(bào)。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多