1. 調(diào)試工具與技巧的底層邏輯重構1.1 為什么調(diào)試能力是區(qū)分開發(fā)者水平的分水嶺干了這么多年技術我越來越覺得寫代碼這件事本身其實沒那么難真正拉開差距的是調(diào)試能力。同樣一個Bug有人十分鐘定位到根因有人折騰兩天還在外圍打轉(zhuǎn)。這中間的差距不是智商問題而是方法論和工具鏈的差距。調(diào)試的本質(zhì)是什么我的理解是在有限的信息中用最小的代價逼近真相。你面對的是一個黑盒系統(tǒng)它表現(xiàn)出了異常行為你需要通過一系列手段逐步縮小可能性空間最終鎖定那個導致問題的變量。這個過程跟刑偵破案幾乎一模一樣——現(xiàn)場勘查、線索收集、假設驗證、排除嫌疑、最終定罪。很多人調(diào)試效率低根本原因在于沒有建立系統(tǒng)化的調(diào)試思維。他們習慣性地“瞎試”——改一行代碼跑一下不行再改一行。這種方式在簡單場景下偶爾能碰對但一旦遇到復雜系統(tǒng)的問題就完全失效了。因為你面對的可能是一個涉及多線程、網(wǎng)絡通信、緩存一致性、第三方依賴的復合型問題靠碰運氣是不可能解決的。我在帶新人的時候最常強調(diào)的一點就是先想清楚再動手。你每一次修改代碼、每一次加日志、每一次抓包都應該是有目的的驗證行為而不是隨機嘗試。這就像醫(yī)生看病先問診、再檢查、最后開藥而不是一上來就把所有藥都試一遍。1.2 調(diào)試工具鏈的分層模型調(diào)試工具不是越多越好關鍵是要分層使用。我習慣把調(diào)試工具分成四個層次第一層日志與打印。這是最原始但也最通用的手段。優(yōu)點是零依賴、隨處可用缺點是侵入性強、信息粒度粗、生產(chǎn)環(huán)境往往不方便用。第二層斷點調(diào)試器。包括IDE內(nèi)置的Debugger、瀏覽器DevTools的斷點功能等。優(yōu)點是能實時查看變量狀態(tài)、調(diào)用棧、內(nèi)存快照缺點是對環(huán)境有要求分布式系統(tǒng)或生產(chǎn)環(huán)境很難直接用。第三層鏈路追蹤與監(jiān)控。比如分布式追蹤系統(tǒng)、APM工具、Metrics面板。優(yōu)點是全局視角、非侵入、適合生產(chǎn)環(huán)境缺點是需要提前建設基礎設施。第四層專項分析工具。比如內(nèi)存分析器、CPU Profiler、網(wǎng)絡抓包工具、系統(tǒng)調(diào)用追蹤等。優(yōu)點是能深入到特定領域的最底層缺點是學習曲線陡峭需要專業(yè)知識。注意很多人的問題在于只會在第一層打轉(zhuǎn)遇到復雜問題就束手無策。你需要根據(jù)問題的性質(zhì)主動往更高層次走。1.3 調(diào)試思維的三個核心原則在展開具體工具之前我想先把調(diào)試思維的三個核心原則講清楚因為工具只是手段思維才是根本。原則一二分法定位。這是最高效的定位策略。不管是代碼邏輯問題還是性能問題你都要學會快速縮小范圍。比如一個接口返回異常你先確認是前端問題還是后端問題確認是后端之后再確認是業(yè)務邏輯問題還是數(shù)據(jù)問題確認是數(shù)據(jù)問題之后再確認是寫入問題還是讀取問題。每一步都砍掉一半的可能性空間很快就能逼近根因。原則二最小復現(xiàn)。能穩(wěn)定復現(xiàn)的問題才是好問題。如果你面對的是一個偶發(fā)問題第一優(yōu)先級不是去猜原因而是想辦法提高復現(xiàn)頻率。我通常會嘗試增加并發(fā)量、縮短觸發(fā)間隔、調(diào)整時序參數(shù)、模擬特定環(huán)境條件。一旦能穩(wěn)定復現(xiàn)問題就解決了一半。原則三假設驅(qū)動。每次調(diào)試都應該基于一個明確的假設。比如“我懷疑是緩存沒失效導致讀到舊數(shù)據(jù)”然后你去驗證這個假設——清掉緩存再試一次如果問題消失假設成立如果問題依舊假設推翻換下一個。這種“假設-驗證”的循環(huán)比漫無目的地翻代碼高效得多。2. 日志與打印最樸素但最有效的調(diào)試手段2.1 日志級別與輸出策略的合理設計日志這東西看起來簡單但用好了真不容易。我見過太多項目日志要么打得太多——滿屏都是無用信息關鍵線索淹沒在里面要么打得太少——出了問題什么都查不到。合理的日志策略應該是分級分類的。分級就是常見的DEBUG、INFO、WARN、ERROR但關鍵是要明確每個級別的使用場景級別使用場景生產(chǎn)環(huán)境是否開啟典型示例DEBUG開發(fā)調(diào)試細節(jié)如變量值、循環(huán)次數(shù)否“當前處理第3條記錄IDxxx”INFO關鍵業(yè)務流程節(jié)點是“訂單創(chuàng)建成功訂單號xxx”WARN可恢復的異常情況是“緩存未命中回源查詢數(shù)據(jù)庫”ERROR需要人工介入的異常是“數(shù)據(jù)庫連接失敗重試3次后放棄”分類則是按業(yè)務模塊或功能維度來組織日志比如訂單模塊、支付模塊、用戶模塊各自有獨立的Logger。這樣出問題的時候你可以快速過濾出相關模塊的日志而不是在幾萬行日志里大海撈針。我個人的經(jīng)驗是在關鍵路徑的入口和出口各打一條INFO日志記錄輸入?yún)?shù)和輸出結果。這樣即使出了問題你至少知道是哪個環(huán)節(jié)掛了。然后在可疑的中間步驟加DEBUG日志定位到具體行之后再關掉。2.2 結構化日志與上下文傳遞傳統(tǒng)的文本日志有個致命問題難以檢索和關聯(lián)。比如你想查某個用戶的所有操作記錄如果用文本日志你得grep用戶名但用戶名可能出現(xiàn)在各種不同的日志格式里很容易漏掉或誤匹配。結構化日志通常用JSON格式解決了這個問題。每條日志都是一個JSON對象包含時間戳、級別、模塊、消息、以及任意自定義字段。這樣你可以用日志系統(tǒng)如ELK、Loki等做精確查詢和聚合分析。{ timestamp: 2025-01-15T10:23:45.123Z, level: ERROR, module: payment, message: 支付回調(diào)驗簽失敗, orderId: ORD-20250115-001, userId: U-12345, traceId: abc-def-ghi-123, errorCode: SIGN_INVALID }這里特別要提的是traceId。在分布式系統(tǒng)中一個請求可能經(jīng)過多個服務每個服務都打自己的日志。如果沒有一個統(tǒng)一的traceId串聯(lián)你根本沒法把一次請求的完整鏈路拼出來。我通常的做法是在請求入口生成一個唯一的traceId然后通過上下文Context在整個調(diào)用鏈中傳遞每個服務的日志都帶上這個traceId。這樣排查問題時只需要用traceId搜一下整條鏈路的日志就全出來了。實操心得traceId的生成可以用UUID也可以用雪花算法。關鍵是保證全局唯一且有序有序的話方便按時間排序。另外traceId一定要在跨進程通信時透傳比如HTTP Header、消息隊列的Message Header里都要帶上。2.3 日志的坑與避坑指南日志這塊我踩過的坑不少挑幾個典型的說說?？右蝗罩纠锎蛴∶舾行畔?。這個不用多說密碼、密鑰、身份證號這些東西絕對不能進日志。我見過有項目把用戶的完整請求體打進日志里面包含密碼明文這是嚴重的安全事故?？佣髮ο髏oString導致性能問題。有些開發(fā)者習慣把整個對象toString后打進日志如果這個對象很大比如包含幾千條記錄的列表toString本身就很耗時而且會產(chǎn)生大量日志拖慢系統(tǒng)。正確的做法是只打印關鍵字段?？尤罩就綄憣е伦枞Ｔ诟卟l(fā)場景下如果日志是同步寫磁盤的磁盤IO可能成為瓶頸。解決方案是用異步Appender把日志先寫入內(nèi)存隊列由后臺線程批量刷盤。但要注意隊列滿了之后的降級策略——是丟棄還是阻塞需要根據(jù)業(yè)務場景權衡。坑四日志文件沒有輪轉(zhuǎn)。這個屬于運維層面的問題但開發(fā)也要關注。如果日志文件不輪轉(zhuǎn)磁盤很快就會被寫滿然后整個服務掛掉。通常用Logrotate或日志框架自帶的RollingPolicy來解決。3. 斷點調(diào)試器交互式排查的利器3.1 斷點類型與使用場景很多人用斷點就只會打一個行斷點然后一步步Step Over。其實斷點的種類遠不止這一種不同場景下用不同類型的斷點效率天差地別。行斷點是最基礎的在指定行暫停執(zhí)行。適合精確定位到某一行代碼的邏輯問題。條件斷點是行斷點的增強版只有滿足特定條件時才暫停。比如你在一個循環(huán)里只想在i100的時候停下來就可以用條件斷點。這個在調(diào)試大數(shù)據(jù)量循環(huán)時特別有用否則你要手動Continue 99次。異常斷點是在拋出指定異常時暫停。這個在排查“不知道為什么拋異?！钡膱鼍跋路浅８咝?。你可以設置只在特定異常類型拋出時暫停然后查看當時的調(diào)用棧和變量狀態(tài)。方法斷點是在進入或退出某個方法時暫停。適合你想跟蹤某個方法的調(diào)用情況但不想在方法內(nèi)部逐行調(diào)試的場景。字段斷點也叫Watchpoint是在某個字段被讀寫時暫停。這個在排查“這個值什么時候被改掉的”這類問題時簡直是神器。比如你發(fā)現(xiàn)一個對象的某個字段莫名其妙變成了null就可以在這個字段上打一個寫斷點誰改的、什么時候改的一目了然。斷點類型適用場景典型問題行斷點精確定位某行邏輯變量值不符合預期條件斷點循環(huán)中特定條件觸發(fā)第N次循環(huán)時結果異常異常斷點異常拋出點不明不知道哪里拋的異常方法斷點跟蹤方法調(diào)用方法被誰調(diào)用了字段斷點字段值被意外修改值什么時候變的3.2 遠程調(diào)試的配置與實戰(zhàn)本地調(diào)試很簡單但很多時候問題只出現(xiàn)在測試環(huán)境或預發(fā)環(huán)境你沒法在本地復現(xiàn)。這時候就需要遠程調(diào)試。以Java為例遠程調(diào)試的原理是通過JDWPJava Debug Wire Protocol協(xié)議讓本地的IDE連接到遠程JVM的調(diào)試端口。具體操作是在啟動參數(shù)里加上java -agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005 -jar app.jar然后在IDE里配置一個Remote JVM Debug填入遠程IP和端口就可以像本地調(diào)試一樣打斷點了。但遠程調(diào)試有幾個必須注意的點第一suspend參數(shù)。如果設為yJVM啟動時會暫停等待調(diào)試器連接設為n則正常啟動調(diào)試器隨時可以連上。生產(chǎn)環(huán)境絕對不要開遠程調(diào)試測試環(huán)境建議設為n。第二網(wǎng)絡延遲。遠程調(diào)試時每次斷點暫停、查看變量都需要網(wǎng)絡往返體驗比本地差很多。所以遠程調(diào)試更適合“精準打擊”——你已經(jīng)大致知道問題在哪只需要確認一下變量值而不是漫無目的地單步執(zhí)行。第三超時問題。如果斷點暫停時間過長可能導致客戶端請求超時、心跳斷開等連鎖反應。調(diào)試完成后一定要記得斷開連接并移除調(diào)試參數(shù)。注意有些團隊會在測試環(huán)境的啟動腳本里默認開啟遠程調(diào)試端口這其實有安全風險。建議只在需要時臨時開啟用完就關。3.3 斷點調(diào)試的高級技巧斷點調(diào)試有一些技巧掌握了能大幅提升效率。技巧一修改變量值。在斷點暫停時很多IDE允許你直接修改變量的值然后繼續(xù)執(zhí)行。這個在驗證假設時非常有用——比如你懷疑某個變量為null導致空指針可以手動把它改成非null看看問題是否消失。技巧二表達式求值。斷點暫停時你可以執(zhí)行任意表達式比如調(diào)用某個方法、計算某個值。這個在你想驗證某個邏輯但沒有寫在代碼里時特別方便。技巧三多線程調(diào)試。多線程場景下斷點默認會暫停所有線程但你可以配置為只暫停當前線程。另外IDE通常提供線程面板可以看到所有線程的狀態(tài)和調(diào)用棧對排查死鎖、線程饑餓等問題很有幫助。技巧四Drop Frame。這個功能允許你回退到上一個方法調(diào)用的起點重新執(zhí)行。相當于“時光倒流”在你不小心Step Over過頭了的時候特別有用。但要注意Drop Frame只能回退棧幀不能撤銷已經(jīng)產(chǎn)生的副作用比如已經(jīng)寫入數(shù)據(jù)庫的數(shù)據(jù)。4. 鏈路追蹤與生產(chǎn)環(huán)境調(diào)試4.1 分布式追蹤的核心概念單體應用時代一個請求的所有處理邏輯都在一個進程里出了問題看日志就夠了。但在微服務架構下一個請求可能經(jīng)過網(wǎng)關、認證服務、業(yè)務服務、緩存、數(shù)據(jù)庫、消息隊列等十幾個組件任何一個環(huán)節(jié)出問題都可能導致整體異常。分布式追蹤的核心思想是給每個請求分配一個全局唯一的Trace ID并在每個處理環(huán)節(jié)記錄Span跨度信息。一個Trace由多個Span組成每個Span代表一個處理單元比如一次RPC調(diào)用、一次數(shù)據(jù)庫查詢包含開始時間、結束時間、耗時、狀態(tài)等元信息。這樣你就能看到一個請求的完整調(diào)用鏈路Trace: abc-123 ├── Span: API Gateway (0ms - 5ms) ├── Span: Auth Service (5ms - 15ms) ├── Span: Order Service (15ms - 120ms) │ ├── Span: Redis Query (20ms - 25ms) │ ├── Span: MySQL Query (30ms - 80ms) │ └── Span: MQ Publish (85ms - 95ms) └── Span: Response (120ms - 125ms)一眼就能看出瓶頸在MySQL查詢上耗時50ms。如果沒有鏈路追蹤你只能看到總耗時120ms根本不知道時間花在哪了。4.2 生產(chǎn)環(huán)境調(diào)試的安全邊界生產(chǎn)環(huán)境調(diào)試是個敏感話題。一方面很多問題只在生產(chǎn)環(huán)境出現(xiàn)你不得不在生產(chǎn)環(huán)境排查另一方面生產(chǎn)環(huán)境直接面向用戶任何操作都可能影響業(yè)務。我的原則是只讀操作可以做寫操作必須極度謹慎。安全的操作包括查看日志、查看監(jiān)控面板、查看鏈路追蹤、查看線程棧jstack、查看內(nèi)存快照heap dump、查看網(wǎng)絡連接狀態(tài)netstat。這些操作基本不影響業(yè)務運行。需要謹慎的操作包括動態(tài)調(diào)整日志級別可能產(chǎn)生大量日志影響性能、動態(tài)修改配置可能觸發(fā)意外行為、遠程調(diào)試會暫停JVM。這些操作一定要在低峰期進行并且提前通知相關方。絕對禁止的操作包括在生產(chǎn)環(huán)境直接修改代碼、重啟服務除非是緊急故障處理、執(zhí)行未經(jīng)審核的SQL。實操心得我通常會在生產(chǎn)環(huán)境預留一個“調(diào)試開關”通過配置中心動態(tài)開啟DEBUG日志或特定埋點。出問題時打開開關收集信息收集完立即關閉。這樣既不影響日常運行又能在需要時獲取足夠的信息。4.3 從監(jiān)控指標反推問題根因鏈路追蹤解決的是“單個請求為什么慢”的問題而監(jiān)控指標解決的是“整體系統(tǒng)健康狀況”的問題。兩者配合使用效果最好。常用的監(jiān)控指標包括RED指標Rate請求速率、Errors錯誤率、Duration響應時間。這是服務級別的黃金指標能快速判斷服務是否正常。USE指標Utilization使用率、Saturation飽和度、Errors錯誤數(shù)。這是資源級別的指標適用于CPU、內(nèi)存、磁盤、網(wǎng)絡等。業(yè)務指標訂單量、支付成功率、用戶活躍度等。這些指標能反映業(yè)務層面的異常。排查問題時我通常先看RED指標確認哪個服務異常然后看USE指標確認是不是資源瓶頸最后用鏈路追蹤定位到具體的慢操作。這套組合拳下來大部分問題都能快速定位。5. 專項分析工具與進階技巧5.1 內(nèi)存與CPU問題排查內(nèi)存泄漏和CPU飆高是兩類最讓人頭疼的問題因為它們往往不是邏輯錯誤而是資源管理問題靠看代碼很難發(fā)現(xiàn)。內(nèi)存問題排查的常用工具是堆轉(zhuǎn)儲Heap Dump和內(nèi)存分析器。當發(fā)現(xiàn)內(nèi)存持續(xù)增長時先抓一份堆轉(zhuǎn)儲文件jmap -dump:formatb,fileheap.hprof pid然后用MAT或VisualVM等工具打開查看對象占用情況。重點看兩個東西一是占用內(nèi)存最多的對象類型二是對象之間的引用鏈。通常能找到某個集合類不斷增長但從不清理或者某個緩存沒有設置過期時間。CPU問題排查的常用工具是線程棧和CPU Profiler。當CPU飆高時先連續(xù)抓幾份線程棧jstack pid thread1.txt sleep 5 jstack pid thread2.txt然后對比幾份線程?？茨男┚€程一直處于RUNNABLE狀態(tài)且調(diào)用棧相同。那個反復出現(xiàn)的調(diào)用棧就是熱點代碼。常見的原因包括死循環(huán)、正則表達式回溯、頻繁GC、鎖競爭等。問題類型首選工具關鍵指標常見根因內(nèi)存泄漏Heap Dump MAT對象增長趨勢集合未清理、緩存無過期CPU飆高jstack Profiler線程狀態(tài)分布死循環(huán)、正則回溯、GC線程死鎖jstack死鎖檢測鎖順序不一致磁盤IO高iostat lsofIO等待時間日志同步寫、大文件讀寫5.2 網(wǎng)絡抓包與協(xié)議分析有些問題出在網(wǎng)絡層面比如請求超時、連接被重置、數(shù)據(jù)包丟失等。這時候就需要抓包分析。常用的抓包工具是tcpdump和Wireshark。tcpdump用于在服務器上抓包Wireshark用于圖形化分析。tcpdump -i eth0 -w capture.pcap port 8080抓包時要注意幾點一是過濾條件要精確否則抓出來的包太大沒法分析二是抓包時間要覆蓋問題發(fā)生的時間段三是注意權限tcpdump通常需要root權限。抓到包之后用Wireshark打開重點關注TCP三次握手是否正常、是否有重傳、是否有RST包、TLS握手是否成功、HTTP請求和響應是否完整。這些信息能幫你判斷問題出在網(wǎng)絡層、傳輸層還是應用層。5.3 動態(tài)追蹤技術動態(tài)追蹤是一種在生產(chǎn)環(huán)境低開銷排查問題的高級技術。它的核心思想是在不修改代碼、不重啟服務的前提下動態(tài)地在指定位置插入探針收集運行時信息。常見的動態(tài)追蹤工具包括DTrace、SystemTap、eBPF等。以eBPF為例你可以用它追蹤系統(tǒng)調(diào)用、內(nèi)核函數(shù)、用戶態(tài)函數(shù)而且性能開銷極低。動態(tài)追蹤適合排查那些“偶發(fā)、難以復現(xiàn)、不想加日志”的問題。比如你想知道某個系統(tǒng)調(diào)用為什么偶爾返回錯誤就可以用eBPF掛一個探針只在錯誤發(fā)生時輸出上下文信息。不過動態(tài)追蹤的學習曲線比較陡需要了解操作系統(tǒng)內(nèi)核和編程語言運行時的知識。建議先從簡單的場景入手比如追蹤文件IO、網(wǎng)絡連接逐步深入。6. 常見調(diào)試場景與速查手冊6.1 接口超時問題排查思路接口超時是最常見的問題之一。排查思路可以總結為“從外到內(nèi)逐層剝離”。第一步確認超時發(fā)生的具體環(huán)節(jié)。是客戶端到網(wǎng)關超時還是網(wǎng)關到服務超時還是服務內(nèi)部處理超時這可以通過鏈路追蹤或日志時間戳來判斷。第二步如果是服務內(nèi)部處理超時看是CPU密集型還是IO密集型。CPU密集型通常是計算邏輯有問題IO密集型通常是數(shù)據(jù)庫查詢、RPC調(diào)用、文件讀寫慢。第三步針對IO密集型進一步確認是哪個依賴慢。數(shù)據(jù)庫慢可能是索引缺失、鎖等待、數(shù)據(jù)量過大RPC慢可能是下游服務本身慢或網(wǎng)絡延遲文件讀寫慢可能是磁盤性能問題。第四步針對具體原因采取優(yōu)化措施。加索引、加緩存、異步化、限流降級等。6.2 內(nèi)存泄漏快速定位方法內(nèi)存泄漏的排查有一套標準流程確認是否真的泄漏?？碐C日志如果Full GC后老年代內(nèi)存仍然持續(xù)增長基本可以確認泄漏。抓取堆轉(zhuǎn)儲。在內(nèi)存增長到接近上限時抓取這樣泄漏對象最明顯。用MAT分析支配樹?？茨男ο笳加昧俗疃鄡?nèi)存以及它們的引用鏈。找到泄漏根因。通常是某個靜態(tài)集合不斷添加元素、ThreadLocal未清理、監(jiān)聽器未注銷等。修復并驗證。修復后持續(xù)觀察內(nèi)存曲線確認不再增長。避坑技巧抓堆轉(zhuǎn)儲時會觸發(fā)Full GC默認行為可能導致服務暫停幾秒。如果服務對延遲敏感可以加上-all參數(shù)只抓存活對象或者用jcmd的GC.heap_dump命令。6.3 并發(fā)問題的調(diào)試策略并發(fā)問題是最難調(diào)試的一類問題因為它們往往不可穩(wěn)定復現(xiàn)而且涉及時序和狀態(tài)。我的策略是先復現(xiàn)再分析最后驗證。復現(xiàn)階段嘗試提高并發(fā)量、調(diào)整線程池大小、增加隨機延遲來放大問題。有時候加一行Thread.sleep(1)就能讓隱藏的競態(tài)條件暴露出來。分析階段用線程棧、鎖信息、內(nèi)存屏障等工具來理解線程之間的交互。重點關注共享變量的讀寫、鎖的獲取釋放順序、volatile和synchronized的使用。驗證階段修復后要用壓力測試反復驗證確保問題不再出現(xiàn)。并發(fā)問題的修復往往需要多次迭代不要指望一次就能搞定。并發(fā)問題類型典型表現(xiàn)排查工具解決思路競態(tài)條件結果不一致線程棧、日志加鎖、CAS死鎖線程卡死jstack統(tǒng)一鎖順序活鎖線程空轉(zhuǎn)線程棧退避策略內(nèi)存可見性讀到舊值內(nèi)存分析volatile、屏障7. 調(diào)試效率的持續(xù)提升7.1 建立個人調(diào)試知識庫調(diào)試能力不是一蹴而就的需要持續(xù)積累。我建議每個人都建立自己的調(diào)試知識庫記錄每次排查問題的過程、用到的工具、最終的根因和解決方案。這個知識庫不需要很正式用筆記軟件就行。關鍵是要記錄“癥狀-工具-根因-解決”這條鏈路。下次遇到類似癥狀時可以直接翻出來參考省去大量摸索時間。我自己的知識庫已經(jīng)積累了幾百條記錄覆蓋了各種奇葩問題。比如“MySQL連接池耗盡導致接口全部超時”、“Redis大key導致主從同步延遲”、“線程池隊列滿導致任務被拒絕”等等。每次翻到類似的記錄都能快速定位方向。7.2 工具鏈的自動化與集成手動調(diào)試效率有限把常用調(diào)試操作自動化能省不少時間。比如寫一個腳本一鍵抓取線程棧、堆轉(zhuǎn)儲、GC日志、網(wǎng)絡連接狀態(tài)打包成一個診斷包。在CI/CD流程里集成靜態(tài)分析工具提前發(fā)現(xiàn)潛在的資源泄漏、并發(fā)問題。配置告警規(guī)則當關鍵指標異常時自動觸發(fā)診斷腳本把現(xiàn)場信息保存下來。這些自動化手段能讓你在問題發(fā)生時快速拿到第一手資料而不是手忙腳亂地一個個登錄服務器執(zhí)行命令。7.3 從調(diào)試到預防的思維轉(zhuǎn)變最后我想說的是調(diào)試的最高境界是不需要調(diào)試。也就是說通過良好的設計、充分的測試、完善的監(jiān)控把問題消滅在發(fā)生之前。具體來說寫代碼時考慮邊界條件和異常路徑做設計時考慮容量和降級上線前做充分的壓測和混沌測試上線后配置完善的監(jiān)控和告警。這些工作做到位了需要調(diào)試的場景自然就少了。當然完全不調(diào)試是不可能的。但每次調(diào)試完之后都應該問自己一個問題這個問題能不能通過改進流程或工具來避免再次發(fā)生如果能就去改進。這樣你的系統(tǒng)會越來越健壯調(diào)試的負擔也會越來越輕。我在實際工作中最大的體會是調(diào)試工具和技巧固然重要但更重要的是調(diào)試的心態(tài)。遇到問題不要慌不要瞎猜按照“觀察-假設-驗證-結論”的循環(huán)一步步來。大部分問題都是可以被解決的只是需要耐心和方法。