昨天聊到工程師可以透過監控系統知道伺服器現在的狀況
但我又突然想到一個問題
如果工程師發現系統真的出問題了，那麼多台伺服器和服務，到底要怎麼快速找到是哪裡壞掉？
而且如果每個服務都互相連接
一個地方出問題，會不會連帶影響其他地方？

所以今天就來看看，一個系統到底是怎麼找到問題的

一、系統出問題時，工程師怎麼知道？
假設今天我們打開一個 App
結果一直轉圈圈
或是突然跳出「發生錯誤」
對使用者來說可能只是一個很普通的錯誤訊息

但對工程師來說
背後可能同時發生很多事情

例如某個伺服器負載太高
某個 API 沒有回應
資料庫突然變慢
或者某個服務直接停止運作

所以工程師不能只看使用者看到的畫面
而是要從系統留下來的各種資訊慢慢找原因

二、可以把系統想成一條生產線
我覺得一個很好理解的方法
就是把整個系統想成一條工廠的生產線

假設一個產品需要經過很多個步驟
第一個工作站處理完
交給第二個工作站
第二個再交給第三個
最後產品才會完成

如果最後的產品出問題
我們不能只看最後一個工作站
因為前面的任何一個環節都有可能出錯
網站和 App 其實也有點像
使用者發出請求之後
可能會經過前端、API、後端、資料庫等不同服務
最後才把結果送回使用者

所以當最後出現問題時
工程師需要一步一步往回找

三、這時候 Log 就很重要
昨天有提到 Log
今天可以更進一步理解它的用途
Log 就像系統留下來的「行車紀錄器」
它會記錄系統在某個時間做了什麼事情

例如
什麼時間收到請求
什麼時間發生錯誤
哪個服務出現問題
資料庫有沒有成功回應
如果系統突然出錯
工程師就可以去查看相關的 Log
看看問題發生之前到底發生了什麼
這樣就不用完全靠猜的

四、那如果服務太多怎麼辦？
大型系統可能會有非常多不同的服務
如果每一個服務都有自己的 Log

那工程師可能會遇到另一個問題
Log 多到看不完

所以實際上通常還會使用一些集中式的監控和 Log 管理工具
把不同服務產生的紀錄集中起來
工程師就可以根據時間、錯誤訊息或服務名稱去搜尋

例如今天晚上 8 點開始
使用者大量出現登入失敗
工程師就可以去查看這個時間附近的相關紀錄
找出到底是哪一個服務開始出現異常

五、一個地方壞掉，真的會影響其他地方嗎？
答案是
有可能!!

因為現代的網站和 App 通常不是一個獨立的程式
而是很多不同服務互相連接
例如
App → API → 後端服務 → 資料庫
如果中間其中一個環節出問題
後面的流程就可能受到影響

例如資料庫突然無法使用
那需要讀取資料庫的功能可能也會跟著出問題
這就是為什麼工程師除了找「哪裡壞掉」
還要找
這個問題到底影響了哪些東西

六、工程師怎麼縮小問題範圍？
當系統出問題時
工程師通常不會直接從幾千台伺服器裡面一台一台猜
而是會先從監控數據、Log、錯誤訊息和服務之間的關係開始判斷

例如發現
某個 API 的錯誤突然增加
接著發現資料庫回應時間也突然變長
那問題就可能跟資料庫或資料庫連線有關
再繼續往下查
就可以慢慢把問題範圍縮小
這個過程其實有點像在玩推理遊戲
只是線索不是腳印
而是大量的數據和紀錄

七、心得
以前我以為工程師遇到系統出問題
就是直接去看程式碼
但今天才發現
真正的大型系統裡
工程師通常需要先從很多不同的線索判斷問題在哪裡
監控數據告訴你「哪裡怪怪的」
Log 告訴你「發生過什麼事情」
服務之間的關係則可以幫助你了解「問題可能影響到哪裡」
最後才慢慢找到真正的原因
所以一個網站看起來只是突然不能用
背後可能已經有很多工程師正在忙著找出到底是哪個環節出了問題

⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯

明日預告

今天知道一個系統出問題時
工程師可以透過監控、Log 和各種數據慢慢找出問題
但我又突然想到一個問題
如果現在很多系統都有這麼多資料，那 AI 到底是怎麼從這些資料裡面學會東西的？
我們平常說的 AI 到底是真的「學會」了
還是其實只是把很多資料記起來？

那明天就來討論一下
「AI 到底是什麼？」