記今天的部署事故 習慣累積沉澱 新浪部落格

2021-09-25 19:12:53 字數 380 閱讀 6573

不知道怎麼用手機發csdn博文。

部署出錯了,原因是測試不充分,系統中有個資料庫版本控制的模組,如果發現應用中的資料庫版本與實際資料庫版本不同就執行版本控制裡的更新sql。

包頭一直由我負責增量更新,我來負責更新什麼。然後由我測試給客戶發更新。

但是還是有沒考慮,而且沒測試到

這次是這樣,我這執行都對,但更新給了客戶後客戶那程式與資料庫版本不一致,無法登入系統,分析原因是版本控制這塊有更新,但我不知道 ,而且涉及了幾個類。我這沒測出問題是因為我用的資料庫裡的版本標識一直是最新的

這次事故得到了教訓

1更新要全面,而不是之前更新需要更新的我以前以為為了安全應盡量少的更新(這個專案多個段使用)。但事實是不全部更新就會可能有漏掉的,如果測試沒覆蓋到就會有問題

記一次慢查詢引發的事故

首先,測試環境上線新版本,並且通過黑盒測試以及功能測試。然後,我們就上線了新的版本。但是在執行3天後,整個伺服器大部分介面都失效了,基本上都是timeout。檢查伺服器情況 cpu基本上佔滿了。接著查了資料庫狀態,通過mysql命令show processlist 存在大量的waiting for ...

記生產上的一次事故

問題描述 生產環境上,使用者在登入登出時跳轉到了空白頁面,觀察位址列發現由原本的https變成了http,但是在測試環境上sit uat都是正常的。生產環境的部署大致是這樣子 ssl nginx f5 應用,在訪問ssl的時候請求是https,到了nginx請求就已經變成了http,proxy re...

記一次dirty ratio引起的線上事故

磁碟 75 最終累計到100 load1 遠遠 8 cpu mem 85 kernel報錯如下 預設情況下,linux會最多使用40 的可用記憶體作為檔案系統快取。當超過這個閾值後,檔案系統會把將快取中的記憶體全部寫入磁碟,導致後續的io請求都是同步的。將快取寫入磁碟時,有乙個預設120秒的超時時間...