今天看了一下日期已經到20年的6月份,距離上次的生產事故已經過去了半個月了,各種覆盤,總結,解決方案和代碼優化也已經上生產了,在進行逐步驗證中
事故復原背景:
組織大型促銷活動,我們的APP 是一個支付軟件,活動的優惠力度比較大,
- 5折立減 沒有門檻最高優惠20元
- 活動上午8點開始
- 區分 運營商用戶(電信用戶獎池最多, 移動/聯通 用戶多但是獎品池少)
- 活動是5天,前4天是搶紅包活動,最後一天是立減,出事的也就是最後一天
公司每年都會舉行這種活動/年中一次年尾一次,所以特別重視, 公司的組織架構管理層除外:
參與活動部門有: 安全/運維/DBA/專項項目組/事業羣/運營(活動)/運營(配置)/技術部門/客服/賬號/理財/保險/消費金融/大數據/AI 所以能力也是可以的,而且這種活動也是舉行了很多次,插個話題(以前也是舉行了很多次,但是以前是 大部分部門都是進行降級服務的在活動高峯時期)
我負責的業務背景: App 的首頁啓動支撐,展示層數據 活動/大數據推薦/保險/理財數據/搜索/短視頻/公益項目/尊貴的運營商plus會員用戶數據 提供接口出去給前端的原生使用. 一共是拆了兩個應用提供這些基本功能出去的一個模塊基本包含了大部分所以部署的機器是25臺,另外一個模塊 20臺機器,所有的配置都一樣的,虛擬出的節點.
爆點活動開始
活動開始時間是上午8點,我們組我距離公司比較近,加上業務也是比較熟悉的有幸參與值班人員6.50已經到了公司領完早餐7點多一點,監控一切正常,我還在和其他組的哥們聊天/吹B,時間過得好快,一會就到了8點一到時間點 我的微信電話就響起了 配置運營組打來緊急電話生產環境配置平臺掛了,所有頁面都是腳本異常,這個平臺就做配置,對數據庫的CRUD 操作,如果出現問題,優先級是比較低的,但是生產很少出行問題的,所以就記錄下來,問題點和時間,準備一會查看原因,突然日誌 平臺刷刷的異常,短信/電話/郵箱 都爆了,瞬間就慌了, 就像黑暗中被人打了一拳,但不知道在對手在哪裏,只有查看日誌錯誤原因是哪個接口掛了,這個時間點大家都來了差不多了,看到羣裏有反饋是網關層出現大量異常,調用各個模塊超時,我緩了一口氣,這和我們應該關係不大吧,然後滿滿排查bug,怎麼有一些sql 的異常呢,而且都是數據庫的連接超timeout 的異常. 頓時,老腦中出現了許多疑惑.
因爲代碼中有60%是我寫的,所以我知道,這邊這些接口都是一次查詢 放到redis中,然後通過技術用戶匹配的數據,這樣做到千人千面的數據+大數據的數據 所以我對我們的數據庫還是有信心的,應該是這會活動訪問量大,一會就好了,時間就這樣過去了,我繼續查看異常信息,代碼是沒有出行邏輯bug,RPC也很少出行異常,這個時候告警還是沒有降下去,自己嘗試切換登錄後發現登錄模塊也有問題了,我們共用的是同一個庫
// 數據庫連接數過高是平時10倍
AM:8:40
拿出我自己準備的預案講一些不不要的接口的開關進行關閉降級處理,看看是否有效果,剛進行關閉樓下的運維瘋狂@我們 說數據庫 連接數過高啊,是不是緩存被穿透了,怎麼壓力都到了數據庫,心中慌的一逼.哎,羣裏大佬 紛紛跟隨出主意,最終確定,輪詢將一些節點進行重啓,這樣數據庫鏈接有些阻塞的線程就死了,能保證數據庫不會掛,同時 網關模塊也表示壓力太大了,需要進行緊急擴容,這會 屋逢連夜偏漏雨.
// 運維組擴容失敗 網關擴容出現問題
事後瞭解到,網關大量的請求過高,無法進行正常的分配 和調用 導致請求無法及時到業務方. 現在又卡在一塊了,網關/app啓動支撐模塊,按照安排
網關緊急庫容/我們查找原因同時降級處理/
AM:9:00
DBA給出了訪問數據庫比較多的sql 讓我們查爲什麼這幾個調用頻率怎麼這麼高,網關也把所有業務線上響應比較上的倒排序, 其中大部分都是我們的,(其他應用基本上都是做的dubbo 接口註冊上去的)我們的創建接口的時候設置的是HTTP 接口,無法進行限流處理, 查看這幾個接口的重要性,快速評估,優先保證主鏈路沒有問題,不重要的進行下線處理,後續再說,同時給我們應用也擴容,這個點我能做的是把可以關閉的都關閉了,也是定位到了訪問數據庫壓力比較大的業務,將接口線下處理.這已經是把內褲都脫了,保證生產了,哎
AM:9.30
基本平臺沒有什麼問題,也是有一些報錯和告警,業務量也上去了,同時看都底層交易平臺也逐步穩定(剛纔網關出現問題導致大量的數據積壓 消息需要處理,)客服的收到的投訴也在逐步處理中,待閉環的下降,多地方顯示支付正常,參與活動的用戶滿意度也有好轉,但是現在時間已經快了10點了上午的活動快結束了,給大量用戶帶來不好的體驗,同時我們有個應用是做乘車碼的 作用和地鐵入口/出口直接掃描就可以出去了,在我們這邊開啓免密支付,直接扣餘額的場景. 但是客戶端啓動出現問題,用戶登錄都有error,有部分用戶在8點前進去地鐵,後面出現癱瘓導致出不去地鐵.帶來了大量的投訴. App端 所有子應用都是進不去的,我們有個應用是話費充值應用 用戶使用這個應用的非常多到了月底用戶開始衝話費了 正好到了月底,交易量又受到影響,
AM:10:00
所有的系統都開始逐步的恢復正常,但是還是有一部分的Exception 數據庫的連接超時,整體接口 成功率80%
調查
接口不支持進行限流:
我們後面的新的模塊連接 網關的是使用的是dubbo 之間調用,這樣可以控制流量,和響應時間控制,請求時間,響應時間,同時引入框架Sentinel 或者 Hystrix 都是可以的,但是這次出事的幾個接口隨着業務的迭代沒有人去關心了,原來一直保持的http 接口,但是網關是沒有對http管理 進行管理,這裏的管理是指,限流方面的,所以網關模塊也是有許多需要改動的,比如接口的限流,接口的流量的優先級,流量的動態圖,所有接口的可視化展示
數據庫查詢頻率過高
有幾個接口查詢數據的頻率非常高,這是平時不會出現的[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-YvimvEle-1592039451359)(D:\文檔\0613CSDN\f70602ee314aad964a16388d691f802.png)]這就可以看到平時連接數是非常低,即使大型活動的時候 如果業務架構設計的好,也不會出現非常高的,突然來了一個珠穆朗瑪峯,DBA 都要提着刀過來了,排查後發現是沒有惡意攻擊的,都是最簡單的 先走redis 後數據庫,當大量用戶突然登錄,需要查詢用戶組/白名單/可見範圍權限的時候數據庫的流量一下子就上去了 這個是沒有任何開關的
機器的CPU資源
我們這個模塊有原來是有60–75臺機器的,歷史上是正常的,後來因爲歷史原因,應用拆分,大部分接口在這個模塊上但是機器缺分給我們只有25臺使用的,平時流量是沒有的,CPU負載是正常範圍的,但是活動的那天,[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-1EkkNTHI-1592039451360)(D:\文檔\0613CSDN\cpu當時的負載情況.png)]
代碼配置
數據庫的配置最大鏈接池的大小一開始的設置的是50,其實還是算比較少的,後面改爲了這個需要看業務和數據庫情況調節,沒有具體的值.所以不寫出來給大家做參考了哦
代碼設計問題
上面也發現了,好多是先redis->mysql 這種情況來走到的,但是如果一個值是沒有的,突然大流量進來的時候緩存沒有建立起來,流量還是到了數據庫
解決方案
- 短期
- 修改數據庫最大連接數
- redis 做二級緩存
- 業務支持降級開關
- 在大型活動的時候向運維組申請臨時加機器
- 接口改造 http 接口改爲dubbo接口 同時加入限流框架Sentinel
- 老的接口下線處理,前後端都下線,APP端接口下線/不影響用戶體驗,後端針對模塊進行排查接口的業務邏輯
- 中期
- 代碼的評審也就是 CodeReview
- 接口的設計 需要更加的思考
- 開發我們自己的工具 來引對大流量的場景
- 加入到全鏈路 監控組內,方便實時動態的查看生產情況
- 全員培訓 生產的敬畏之心
- 長期
- 嚴防 流量入口 dubbo/Http/Kakfa 保證平臺的穩定型
- 代碼的質量, 如果代碼比喻爲一塊塊紅磚,那麼項目就是我們所建起來的高樓大廈,我們的目標是建設上海中心這樣的項目總不能做豆腐渣工程吧 質量是第一把關 代碼評審
- 合作大數據 將每天的日誌,撈出異常的日誌,和日誌分析,發送報告給我們,同時配合AI部門做出代碼的質量檢測 (缺陷/修復 建議)
總結
思考
撈出異常的日誌,和日誌分析,發送報告給我們,同時配合AI部門做出代碼的質量檢測 (缺陷/修復 建議)
總結
思考