事件背景
作者所在的公司核心業(yè)務(wù)是做政府信息化軟件的，就是為政府部門開發(fā)信息化系統(tǒng)。其中有一款信息化軟件是客戶每天需要使用的，并且他們面向的客戶就是老百姓。
某年某月，某地區(qū)信息化系統(tǒng)，周末升級系統(tǒng)以后，后面連續(xù)一周，持續(xù)出現(xiàn)系統(tǒng)不穩(wěn)定、宕機、服務(wù)假死、數(shù)據(jù)庫鎖表等事件。甚至星期五下午，出現(xiàn)三個多小時無法恢復系統(tǒng)，造成惡劣影響。
系統(tǒng)整體運行架構(gòu)
相對傳統(tǒng)的一個負載均衡運行架構(gòu)。系統(tǒng)建設(shè)時間比較早(2016年)，沒有分布式框架，就是傳統(tǒng)的SpringMVC+MyBatis架構(gòu)，并且服務(wù)器都是基于windows Server 2008的。
這套架構(gòu)是出問題之前的架構(gòu)，存在比較大的問題，在后續(xù)負載均衡章節(jié)會詳細說明。事件過程
事件持續(xù)了一周左右，出現(xiàn)了好幾類的嚴重問題。
事件造成的影響
- 公司口碑受到重大影響，此次事件公司常務(wù)副總、研發(fā)中心經(jīng)理、主管全部出動，去安撫客戶和解決問題(系統(tǒng)所在地區(qū)是沿海省會級城市，面向百姓，影響比較大)。
- 出嚴重問題當天，剛好有督查組來訪問，碰到這個事件，機構(gòu)年度考核扣了好多分。
- 后續(xù)行機構(gòu)收到了大量投訴，影響了很多人考評。
9.21日上午，系統(tǒng)出現(xiàn)大面積服務(wù)假死，訪問長時間沒有響應。服務(wù)器網(wǎng)絡(luò)延遲也非常嚴重。
分析過程
- 查看服務(wù)器發(fā)現(xiàn)CPU異常飆高;
- 通過jstack發(fā)現(xiàn)大量服務(wù)在等待中(當時時間緊迫，不允許做太多的操作，要馬上恢復)。直接重啟了其中一臺服務(wù)器上的所有服務(wù)。
- 發(fā)現(xiàn)沒有變化，新來的請求還是直接掛起，推測不是服務(wù)的問題；
- 檢查網(wǎng)絡(luò)狀態(tài)，發(fā)現(xiàn)服務(wù)器的網(wǎng)絡(luò)延遲非常嚴重，開始懷疑是否是網(wǎng)絡(luò)出現(xiàn)問題，聯(lián)系網(wǎng)絡(luò)管理員排查發(fā)現(xiàn)只有我們系統(tǒng)所在服務(wù)器出現(xiàn)延遲，其他服務(wù)器都正常，并且本身服務(wù)器CPU也異常，基本排除了網(wǎng)絡(luò)引起的原因(為什么網(wǎng)絡(luò)會大面積延遲，后面會提起)；
- 馬上去查看數(shù)據(jù)庫監(jiān)控，發(fā)現(xiàn)數(shù)據(jù)庫CPU和IO異常(數(shù)據(jù)庫由第三方公司管理，我們前期無法直接查看，聯(lián)系他們以后給的監(jiān)控報告)
- 通過DBA查詢數(shù)據(jù)庫掛起的腳本，發(fā)現(xiàn)有個update請求把數(shù)據(jù)庫資源全部占用了，導致其他數(shù)據(jù)庫請求無法進來或者響應非常慢，從而導致服務(wù)都假死了。
經(jīng)查詢，發(fā)現(xiàn)此次操作是一個名為更新“數(shù)據(jù)實例”功能，每次升級版本需要手動操作下此功能(情況比較復雜，無法做成自動處理)。所有的歷史實例數(shù)據(jù)都會存在這個表，發(fā)生事故的時候，這張表大概有1億3千多萬的數(shù)據(jù)(Oracle比較能抗，數(shù)據(jù)量不算太大)，更新實例這個功能又包含了表結(jié)構(gòu)調(diào)整、索引重建、數(shù)據(jù)更新等功能(業(yè)務(wù)場景需要，原則上屬于每次升級操作一次就可以)，所以操作的時候會鎖全表。
本來這個操作是要在系統(tǒng)升級完成以后操作的，但是升級的時候現(xiàn)場人員是新人不太熟悉情況，運行過程中客戶發(fā)現(xiàn)數(shù)據(jù)有問題，經(jīng)溝通后發(fā)現(xiàn)少了更新實例的操作，客戶催的比較急，就直接在上線期間去操作了這個功能。因為這張表是核心表，所有業(yè)務(wù)都會走這張表的，就造成所有服務(wù)都卡死了。
后來是直接重啟了數(shù)據(jù)庫服務(wù)器(那時候DBA已經(jīng)無法干掉進程，重啟服務(wù)也失敗，時間比較緊迫，經(jīng)過溝通以后直接重啟服務(wù)器), 之后系統(tǒng)恢復了，整個過程大約持續(xù)了30分鐘。
解決措施
- 系統(tǒng)優(yōu)化，原來實例表是單表，數(shù)據(jù)量后續(xù)也會越來越大，就對程序做了改造，針對這張表做了分表功能(按照時間點建立分表，程序自動處理數(shù)據(jù)，自動建立分表，相應的查詢統(tǒng)計等都做了調(diào)整)；
- 增加了權(quán)限控制，更新實例功能只允許管理員角色操作；
- 強化現(xiàn)場實施人員培訓，哪些操作是決不允許在上線期限操作的；
因為系統(tǒng)所在區(qū)域的業(yè)務(wù)量還算是比較龐大的，數(shù)據(jù)積累很快，所以很久以前的一些架構(gòu)設(shè)計其實是存在問題的，后續(xù)針對類似這些數(shù)據(jù)表都做了相同的處理。
本來想改整體業(yè)務(wù)架構(gòu)的，但是發(fā)現(xiàn)帶來的代價太大，不僅僅涉及本身系統(tǒng)修改，還涉及一系列供應鏈上系統(tǒng)的修改，所以就放棄了這個方案。事件二之Tomcat內(nèi)存溢出崩潰
9.21日下午，發(fā)現(xiàn)兩個核心服務(wù)會不定時出現(xiàn)內(nèi)存溢出，然后tomcat直接崩潰， 9.22日下午，發(fā)現(xiàn)另外一個服務(wù)不定期出現(xiàn)tomcat內(nèi)存溢出問題，同樣造成tomcat崩潰
做過軟件的都知道，雖然異常表象是一樣的，但是實際產(chǎn)生的原因可能是完全不一樣的。分析過程
因為涉及到tomcat崩潰，在tomcat目錄下產(chǎn)生了hs_err_pid.log日志，所以原因相對比較容易找，結(jié)合業(yè)務(wù)日志反查分析以后，就定位到了問題所在。
原因追溯死循環(huán)
9.21下午出現(xiàn)的兩個核心服務(wù)不定時出現(xiàn)內(nèi)存溢出，查詢?nèi)罩景l(fā)現(xiàn)出問題時間段內(nèi)會出現(xiàn)大量的服務(wù)訪問日志，經(jīng)過追溯代碼以后，發(fā)現(xiàn)前端的判斷邏輯存在問題，會造成服務(wù)死循環(huán)訪問，即A-->B，A-->B，.....
歷史原因，部分業(yè)務(wù)邏輯代碼在前端進行處理，本來服務(wù)A訪問成功以后，會繼續(xù)訪問B服務(wù)，然后B服務(wù)訪問成功以后就結(jié)束了。但是這里的代碼在特定條件下邏輯判斷不嚴謹，會觸發(fā)刷新服務(wù)，會一直重復訪問A，B服務(wù)。模糊查詢
9.22下午出現(xiàn)的另外一個服務(wù)內(nèi)存溢出，經(jīng)過同樣的分析以后，發(fā)現(xiàn)是一個模糊查詢的請求出現(xiàn)異常了，正常看代碼沒什么問題，但是分析日志以后發(fā)現(xiàn)，都是一些模糊條件比較簡單的請求，初步懷疑是數(shù)據(jù)沒做過濾，當時數(shù)據(jù)全部加載到內(nèi)存里了。
因為分析的時候是上線期間，防止系統(tǒng)出現(xiàn)問題，沒有直接抓出原請求去復現(xiàn)問題。后面是讓DBA，基于查詢的SQL語句，去數(shù)據(jù)庫日志里查詢當時的執(zhí)行記錄，發(fā)現(xiàn)這幾個請求平均返回的記錄數(shù)都在200萬以上。至此基本上知道造成內(nèi)存溢出的原因，程序里不僅僅是加載數(shù)據(jù)，還有進行數(shù)據(jù)處理的計算。
解決措施
- 第一個問題比較容易處理，程序修復就行，后續(xù)對這段代碼邏輯重新進行了審計，最大限度排除邏輯上的缺陷。這些情況也整理了相應的測試用例，后續(xù)納入常規(guī)測試計劃里。
- 第二個問題處理過程比較簡單，對模糊查詢做了數(shù)據(jù)量返回限制，以當時的業(yè)務(wù)場景，限制返回1000條，找不到記錄再輸入更精確的查詢條件，并簡化了代碼里面的邏輯運算，大部分場景移到數(shù)據(jù)庫計算(不影響整體性能)。但是這個程序本身出現(xiàn)的問題其實比較低級，當時審計過程也存在問題，這種問題不應該出現(xiàn)
后面問過當事人，為什么要這么查詢，一問發(fā)現(xiàn)還是我們自己的問題(設(shè)計不合理)。這個版本上線增加了回車查詢的功能，然后客戶在一個詞輸完以后，習慣性地會敲回車，然后觸發(fā)了查詢，就造成了前面的事故。比如要查詢XXXX省的某個坐落門牌號，然后在輸入XXXX省以后輸入按了回車，就變成把全部的XXXX省數(shù)據(jù)都查詢出來了。
事后公司內(nèi)部小組內(nèi)也進行了案例分析，其實很多開發(fā)人員對這種問題不以為然，認為不是太大的問題，就改兩句代碼就行。但是實際造成的后果可以對標互聯(lián)網(wǎng)的P0級事故，這個帶來的可不是人力成本上的損失，還有很多看不見的諸如口碑，信任等損失。負載均衡問題
21號-24號中間出現(xiàn)幾次問題，其實大部分時候都是某一臺服務(wù)器上的服務(wù)出現(xiàn)問題，但是發(fā)現(xiàn)負載均衡沒有發(fā)揮任何作用，服務(wù)都掛掉了，請求也一直過來。
剛好周五下午也出現(xiàn)了更重大的事故，所以在后面就把整體策略調(diào)整了。負載均衡設(shè)備的問題也算是為我們周五的大事故轉(zhuǎn)移了一些視線吧，壓力相對減輕了一些
原先的運行架構(gòu)圖
存在的問題
- 負載均衡監(jiān)測策略不對，只是針對端口做了類似te.NET測試，只要端口能訪問就行，服務(wù)假死的時候，端口還是可以訪問的，所以他認為服務(wù)還是正常的，請求照樣過來。
- 負載均衡訪問策略也不是很合理，事故前設(shè)置的按照IP哈希的方式(經(jīng)詢問，原先是為了會話保持，設(shè)備的訪問策略也很少，只有兩三種方式)，當中間一臺下線，請求轉(zhuǎn)到另外一臺以后，后續(xù)另外一臺重啟起來，請求就不會過來了。所以很多時候，監(jiān)測會發(fā)現(xiàn)，兩臺服務(wù)器的壓力差異非常大。
- 整體負載均衡方案也有問題，只做了服務(wù)器負載，系統(tǒng)整體架構(gòu)是A-->B-->C這種形式的，如上圖，策略只針對兩臺服務(wù)器的服務(wù)1所在端口做了負載，就是如果服務(wù)1端口沒有問題，服務(wù)都會一直過來。如上圖鏈路上服務(wù)2，服務(wù)3不管出現(xiàn)什么問題，請求還是照樣會過來的。
廠商其實是個小代理商，設(shè)備也比較low，前期的時候也比較拽，上面的幾個問題據(jù)說前期都是溝通過的，但是人不配合。做過政府信息化軟件的都清楚，內(nèi)部會涉及多方博弈，有時候很多問題不是技術(shù)能解決的。
這次事故也算是一件好事，至少讓甲方意識到設(shè)備是有問題的，叫上了設(shè)備供應商對負載均衡各項內(nèi)容進行了調(diào)整；對我們來說，甲方的炮火也適當轉(zhuǎn)移了一部分，我們的壓力也減輕了。解決措施
- 增加了服務(wù)監(jiān)測(原來的端口監(jiān)測保留，也增加其他服務(wù)的端口監(jiān)測)，為了不影響系統(tǒng)運行，我們針對每個服務(wù)額外編寫了一個監(jiān)測服務(wù)接口，專門用于設(shè)備配置服務(wù)監(jiān)測。(因為老系統(tǒng)是基于jsp運行的，所以不能是html頁面，需要jsp頁面，返回200表示正常，其他就是異常
- 訪問策略修改成輪詢策略，平衡分布請求流量
- 調(diào)整程序配置，支持服務(wù)之間負載(類似分布式架構(gòu))
服務(wù)和端口監(jiān)測場景
服務(wù)訪問場景
所有內(nèi)部服務(wù)訪問都通過負載去轉(zhuǎn)發(fā)，做到每個服務(wù)都高可用。
需要承擔的風險：
1、高度依賴負載均衡設(shè)備的穩(wěn)定性，以前請求較少，現(xiàn)在請求都會經(jīng)過。(后面出現(xiàn)過一次負載扛不住壓力，系統(tǒng)全面崩盤的情況)。
2、會話保持需要依賴于軟件架構(gòu)的設(shè)計，如果會話保持無法做到，此套架構(gòu)無法使用
當時負載均衡策略根據(jù)上述的方式做了調(diào)整，效現(xiàn)場果還是不行。
當時設(shè)置完成以后，廠商才告訴我們，老的設(shè)備監(jiān)測有問題了，要10分鐘才會切換(好像是老設(shè)備的問題)，需要更換新的設(shè)備才行。 10分鐘對業(yè)務(wù)來說太長了，這種效果根本沒用。
回到當時內(nèi)部的多方博弈，業(yè)務(wù)部門要求換，信息部門要求我們軟件供應商寫一個保證，更換設(shè)備以后，系統(tǒng)100%不出問題。這種說法就是耍流氓了，我敢說沒有一家軟件公司敢說自己產(chǎn)品100%沒有Bug，再說硬件負載切換更換，為什么要軟件公司來保障。后來這個事情就不了了之了。
網(wǎng)上經(jīng)常說的那句話，“往往最樸素的方法就是最有效的方法”，甲方后來也知道他們硬件設(shè)備不行，采用了重啟大法，他們會定期(差不多一個月)的樣子，重啟下所有設(shè)備，后面確實沒發(fā)生什么大問題了。
后來我們在公司內(nèi)部完全模擬了現(xiàn)場的情況，采用了國內(nèi)知名硬件廠商的負載均衡設(shè)備(不打品牌了，有打廣告的嫌疑)， 發(fā)現(xiàn)效果非常理想，可以達到預期的切換的效果。說明說做的策略沒有任何問題。系統(tǒng)宕機，無法恢復
9.25下午開始，那就是災難性的了，也是那天，所有領(lǐng)導齊聚現(xiàn)場，安撫客戶。 這天出現(xiàn)了將近三個小時無法恢復系統(tǒng)，業(yè)務(wù)直接停擺。
黑色的一個星期五，我也是在這天到現(xiàn)場的，前面都是遠程指揮的(開發(fā)負責人在現(xiàn)場)
整個事件莫名其妙來，莫名其妙走，從星期五晚上開始(通宵了兩晚)，一直到星期六半夜里吧，經(jīng)過多人的頭腦風暴以后，才基本確定了問題的所在。
真的找到問題以后發(fā)現(xiàn)過程很可笑，但是代價太慘痛
前面我們是一直在懷疑是中午12:00左右更新的代碼引起的問題，因為從各種現(xiàn)象來說，就是更新了以后出現(xiàn)的問題，但是經(jīng)過一個多小時的反復驗證和討論，直接排除這方面的原因，那時候就直接開玩笑說了，敢用腦袋擔保新加的代碼是沒問題的。
后面開始翻看各種本地日志，那時候日志文件很大，好幾百兆(其實這個文件大小就是有問題了，只是所有人都沒意識到，為了排查方便，是每天備份清理日志的，正常業(yè)務(wù)不應該產(chǎn)生這么大的日志，況且這天下午基本沒有業(yè)務(wù)辦理，只是那時候我剛到，不了解情況，也沒多想)，日志非常大，加載又慢，看了一大堆無用的運行日志，沒發(fā)現(xiàn)任何有價值的信息
快到天亮的時候，翻看了很多代碼和日志，也是毫無頭緒。真的是毫無頭緒，連疑似的原因都找不到，本來說讓性能測試組過來，看能不能復現(xiàn)，但是源頭都沒有，性能測試總不可能一個個場景壓過去去找問題吧。
白天休息了一個多小時吧，起來繼續(xù)工作了。
因為我屬于被拉過去的，正兒八經(jīng)排查代碼是有其他開發(fā)負責人在的，前面我大部分時間就是跟他們頭腦風暴，然后翻翻日志文件什么的。那時候潛意識也是認為應該跟代碼沒什么關(guān)系，還是跟環(huán)境有關(guān)系。所以第二天一早，我開始查看服務(wù)器上的部署文件，算是漫無目的吧，因為根本沒頭緒。
細節(jié)決定成敗， 我在翻看配置文件的時候，發(fā)現(xiàn)同級目錄下的log4j.properties文件的修改時間不正常，是25號下午17:03分，這個時間差不多就是我們最后一次重啟的時間，那時候本能的反應就是這個和這次事故有關(guān)系。打開文件看了下內(nèi)容，看起來很正常，日志級別也是ERROR的(我們要求生產(chǎn)環(huán)境不允許開啟debug日志的)，但是這個修改時間表明當時這個文件被覆蓋過或者修改過。那時候真的，一下子來了精神，看到曙光了。
我叫上相關(guān)的所有人，開始反推當時從12:00更新開始的全過程，也把當時更新服務(wù)器的開發(fā)人員叫上，努力回想當時干了什么事情。經(jīng)過將近兩個多小時左右的回溯和頭腦風暴，終于把事情理清楚了。
- 星期五中午的時候，開發(fā)人員更新了幾個文件，其中就有l(wèi)og4j.properties，他自己也沒注意到，然后覆蓋上去的文件，是開啟日志模式為Debug的。當時下午大家一團鬧哄哄，他潛意識也壓根聯(lián)想不到這塊，后來也是明確定位到這個文件，他才想起來。
- 我們重新把配置文件修改成Debug模式，然后啟動服務(wù)，果然出現(xiàn)了當時的情況，兩臺服務(wù)器CPU飚高了，但是大概10幾分鐘以后恢復下來了，所以中午重啟完以后，我們都去吃飯了，也沒管服務(wù)器，那時候應該也是CPU異常，只是后續(xù)自動恢復了。(這個也很郁悶，到時如果我們能多等一會，可能就不會造成這么大的事故了)。
- 分析了下，為什么開啟Debug以后會造成CPU異常，原因就是系統(tǒng)啟動的時候tomcat控制臺瘋狂刷日志，導致控制臺假死，進而導致服務(wù)器CPU異常系統(tǒng)假死(為什么會這樣，后面會詳細描述)。
- 而導致控制臺瘋狂刷日志的原因是因為會話同步的功能，因為架構(gòu)比較老，并且是負載均衡，需要保持會話一直，所以采用的是Shiro+Ehcache緩存來管理會話，然后通過Ehcache來實現(xiàn)兩臺服務(wù)器的會話同步。因為會話是做了持久化+超期時間的方式，所以后續(xù)每次啟動的時候都會執(zhí)行會話同步的功能。
- 本來這個事情也沒什么關(guān)系，但是因為業(yè)務(wù)場景需要，會話里是存了用戶大部分的信息，其中就包括指紋特征碼(系統(tǒng)支持指紋登錄)，然后指紋特征碼是一串Base64編碼的字符串，非常長，所以同步的過程中日志都輸出了，在控制臺瘋狂滾屏，就造成了第4步描述的局面。后面關(guān)掉會話同步的功能，程序就啟動正常了，不會假死，也印證了我們的猜想（單臺服務(wù)啟動，不一會兒也會假死，也是這個會話同步造成的）。
- 然后就是下午14:00的時候，上班高峰期為什么也會造成系統(tǒng)崩潰，那時候會話同步已經(jīng)結(jié)束了，因為知道tomcat控制臺瘋狂刷日志，所以反向分析，當時應該是大量登錄的場景，所以我們找了客戶端打開系統(tǒng)，登錄了下，果然發(fā)現(xiàn)問題了，只要一打開系統(tǒng)，控制臺就開始瘋狂刷新日志，CPU也逐漸上去了，那時候幾百個客戶端差不多時間登錄，那就造成系統(tǒng)崩潰了
- 查看日志以后發(fā)現(xiàn)也是在刷用戶信息(同會話同步)，進一步排查代碼以后是指紋登錄功能引起的。 指紋登錄的設(shè)備是甲方自己采購的，當時設(shè)備沒有提供JAVA的SDK，只有JS的SDK，也就是不支持后臺比對指紋，所以當時的做法是把所有用戶(大幾百個)的指紋信息輸出到前端，然后前端根據(jù)指紋特征碼循環(huán)去比較，匹配以后，找到指紋對應的用戶，在進行系統(tǒng)登錄。(客戶要求直接按指紋就登錄，而不是先用用戶名登錄，然后再指紋二次登錄，所以用了比較傻瓜的方式，指紋特征碼也不能直接Base64字符串比較，要根據(jù)匹配程度，然后有一套算法去匹配的。也得虧系統(tǒng)在內(nèi)網(wǎng)，帶寬高，不然這種玩法，老早掛了)
到此為止，基本上已經(jīng)分析清楚了造成問題的原因，也一步步復現(xiàn)了當時系統(tǒng)所有的異常現(xiàn)象。
為什么控制臺刷日志會造成CPU異常
但是最關(guān)鍵的問題來了，為什么控制臺刷日志會造成CPU異常，這個也是阻礙我們排查問題的最大原因，我們也在自己筆記本上做了大量模擬，包括通過JMeter做壓測，都沒發(fā)現(xiàn)控制臺刷日志會造成CPU異常。
其實解決過程很簡單，關(guān)閉debug日志，系統(tǒng)基本就是正常了，但是本著刨根究底的態(tài)度，這個問題卡在這里很難受，這類問題也就獨此一家吧。
因為那天甲方人也在，硬件公司也來了，聊天的過程中終于發(fā)現(xiàn)了問題所在。
你看的沒錯，運行了系統(tǒng)這么久的服務(wù)器居然是兩臺VM虛擬機。
用過虛擬機的都知道，虛擬機是公用主機的內(nèi)存和CPU，是通過動態(tài)計算分配出來的，經(jīng)過和專業(yè)人士交流以后，虛擬機內(nèi)部很多操作都是通過軟件模擬出來的，比如網(wǎng)絡(luò)。這也解釋了9.21號服務(wù)器CPU異常以后，造成網(wǎng)絡(luò)大面積延遲。
大概的過程基本就是CMD封裝刷日志-->CPU異常-->進而掛起了其他所有操作(包括網(wǎng)絡(luò)等)，等待CMD日志刷完，釋放CPU以后，又恢復正常了。
因為對操作系統(tǒng)原理其實不是特別了解，所以也一直分析不到到底是什么情況，到時cmd刷日志占用了所有的CPU，也不給我們權(quán)限去查看VM服務(wù)端相關(guān)的日志，這個屬于硬件公司管轄范圍
硬件公司死活不承認VM虛擬化做服務(wù)器是有問題的，但是從我的角度看，單單就是CPU飆高，網(wǎng)絡(luò)會出現(xiàn)大面積延遲就是有問題的。可能硬件公司知道貓膩吧，所以也不給我們看服務(wù)端日志，他們一直強調(diào)服務(wù)器是沒問題的。
前面也講到，回公司以后，我們搭建過一套一模一樣的環(huán)境(實體機)，就是怎么也復現(xiàn)不了控制臺瘋狂刷日志，造成CPU異常，系統(tǒng)假死的情況。總結(jié)
人的習慣就是這樣，第一印象把問題都會甩給“異常輸出的平臺”，所以這個事件基本上由我們軟件平臺全部背鍋了，我們事后還寫了很大一份“事故總結(jié)報告”，各種“保證書”等等。
事件總結(jié)
- 工藝流程不規(guī)范，有現(xiàn)場操作的工藝流程，比如在不該操作的時候進行操作；質(zhì)量管理流程不規(guī)范，比如代碼審計不足，環(huán)境模擬不充分(模糊查詢問題，公司只有幾千條數(shù)據(jù))，公司沒有搭建負載均衡環(huán)境測試等等；分析設(shè)計不充分，比如模糊查詢的問題。
- 老系統(tǒng)日志系統(tǒng)比較欠缺，很多問題都是靠人工查看控制臺或者翻閱本地log4j日志，也浪費了大量的時間。
- 突發(fā)危機處理能力不夠，比如當時多等待10分鐘就沒問題了， 單臺服務(wù)器其實可以使用的(那時候已經(jīng)沒有登錄場景了，都已經(jīng)登錄過了)等等。那時候很多人堆在一起，鬧哄哄七嘴八舌的，也沒有冷靜下來思考，導致事態(tài)嚴重化了。
- 應急方案沒有，系統(tǒng)掛了就沒有第二套方案去應急。
這是一次典型事件，碰到了我職業(yè)生涯沒碰到過的異常，又積累了一筆經(jīng)驗。
大家喜歡可以關(guān)注我，每天只分享Java干貨！ 鏈接：https://juejin.cn/post/7152449257700589576
