測試奇譚，BUG不見。
大家好，我是譚叔。
一提到線上問題，很多測試小白要麼”原則性“恐懼，要麼憨憨如也，不知如何下手。
本篇文章，我再細化下這道常見的面試題，跟大家捋捋發生線上問題，作為測試人，該有的思路。
首先，直接給出萬金油三步公式：
第一步，初步排查，快速恢複業務；
第二步，查找問題根本原因，徹底解決；
第三步，團隊分享，避免出現類似問題。
這三步中的措辭，十分重要。特别是第一點——初步排查，快速恢複業務。
出現問題，不要一來就盲目定位，本着不找到根本原因不罷休的思想去處理突發問題，是不可取的。
線上有問題，最重要的是快速恢複業務。
你可以先檢查CPU、記憶體、網絡IO、磁盤IO等，看看有無明顯的抖動。比如CPU過高，可以嘗試重新開機。
接着檢視調用情況，判定是依賴系統的問題，還是自身系統的問題。如果是依賴系統的問題，有降級方案的優先做降級處理，無降級方案的馬上聯系依賴系統負責人協同解決。
如果是自身系統問題，優先判斷資料庫類問題。若有慢查詢，就先kill掉，重新開機資料庫；若通路量不足，就先做擴容或者限流。再查查Full GC，如果Full GC過多，先重新開機服務，再通過DUMP記憶體找對象，修複并上線。
前面所述，都提到了重新開機服務——人人都說重新開機大法好，因為它是真的香。
有時候，重新開機是快速恢複業務的一種方式。但這種方式，治标不治本。
治本是在快速恢複業務之後，定位問題，去徹底解決它；去做總結分析，避免出現類似問題。
比如，剛剛提到，若是資料庫慢查詢，想要快速恢複業務，可以kill掉慢查詢，重新開機資料庫。此時，業務雖然恢複，但它是短暫的恢複，你還得繼續定位。你定位到問題原因是新加的表索引不夠，那你得馬上加索引，并在事後開個會或者做個組内總結，聊聊庫表設計的問題，聊聊上線方案的問題等等，避免再出現類似問題。
其實，在生産環境，引起大面積故障，導緻系統不可用的問題一般有三大類：依賴系統故障、資料庫故障、程式問題導緻記憶體不足引發Full GC。
請牢記并背誦這三大類，絕對實用！！！
再細分點講，資料庫慢查、死鎖、連接配接數不夠，redis有大key，Full GC過多，線程DUMP，記憶體DUMP，MQ消費積壓，都是常見的線上問題，也可以說，是絕大部分問題。
這些内容，每個都可以開一篇專題聊聊，故此文不再拓展。
在中大型公司，以上這些都是通用知識點。出現線上問題，體驗并實操幾次，自然而言就懂了。
作為測試，你可以不深入它們，但你一定得了解它們，或者說，你可以把他們作為你進階提升的課程表，挨個去學習。
最後，願天下測試人都不會遇到線上BUG。
