Day 15 我們學到 Reliability 的核心：
Failure → Detect → Isolate → Recover
但這裡有一個問題：
我們怎麼知道 Failure 發生了？
User 只告訴你：
「網站今天很慢。」
原因可能是 Backend、Database、Redis、External API、Traffic 或新的
Deployment。
如果沒有資料可以觀察，Engineer 只能猜。
所以今天要學：
Observability
Production System：
真正正式提供給 User 使用的 System。
自己的電腦 → Local Development
測試環境 → Testing / Staging
真實 User → Production
Production 出問題時，我們需要知道：
發生什麼？
在哪裡發生？
什麼時候開始？
影響多少 User？
可能原因是什麼？
Observability（可觀測性）：
透過 System 對外產生的資訊，理解 System 內部正在發生什麼。
例如：
User
↓
API Gateway
↓
Backend
↓
Redis
↓
Database
User 說 Request 很慢。
如果看到：
Backend = 30 ms
Redis = 5 ms
Database Query = 4.8 sec
就可以把調查方向放在 Database。
這就是 Observability 的核心。
Observe = 觀察。
像醫生透過：
體溫
血壓
心跳
驗血
症狀
判斷身體內部狀況。
Software 也一樣。
Signal：
System 產生、可以幫助 Engineer 判斷內部狀態的資訊。
例如：
CPU = 95%
Error Rate = 10%
Latency = 5 sec
DB Connections = 100/100
Observability 常見三種核心 Signal：
Metrics
Logs
Traces
Monitoring：
持續收集與查看已知的重要指標，確認 System 是否正常。
例如：
CPU > 90%？
Memory > 90%？
Error Rate > 5%？
DB Connections 快用完？
超過門檻時可以發出 Alert。
Monitoring 比較像：
我知道要注意哪些問題，所以持續監看。
Observability 比較像：
遇到沒有預先想到的問題時，我是否有足夠資料調查原因。
例如只有 Taiwan User 的 Checkout 變慢，可能沒有一個預先設定好的「Taiwan
Checkout Problem」Alert，但 Metrics、Logs、Traces 可以幫助調查。
Metric：
用數字表示 System 某個狀態或行為。
例如：
CPU Usage = 82%
Memory Usage = 70%
Request Count = 10,000/min
Error Rate = 2%
Latency = 200 ms
簡單記：
Metric = 可以持續測量、比較、畫成趨勢圖的數值。
**CPU（Central Processing Unit）**可以先想成 Computer
執行計算工作的核心資源之一。
CPU Usage：
CPU 現在有多忙？
20% → 比較空閒
95% → 非常忙
但 CPU 高不一定代表 Bug，也可能只是 Traffic 增加。
所以不能只看一個 Metric 就直接判斷 Root Cause。
這裡的 Memory 主要指 RAM：
Program 執行時暫時存放資料的高速空間。
如果：
Memory = 99%
可能需要調查。
原因可能是：
正常 Cache
大量 Traffic
Large Data Processing
Memory Leak
Memory Leak：
Program 使用 Memory 後，本來應該釋放卻沒有正常釋放，導致 Memory
Usage 持續增加。
例如：
10:00 → 40%
11:00 → 55%
12:00 → 70%
13:00 → 85%
14:00 → 98%
這種 Pattern 可能值得檢查。
Root Cause：
造成問題最核心的原因。
Symptom：
問題表面呈現出來的症狀。
例如：
User sees 500 Error
↓
Backend Error
↓
DB Connection Failed
↓
Connection Pool Exhausted
↓
Connection Leak
500 Error 是 Symptom。
真正 Root Cause 可能是 Connection Leak。
就像「發燒」是症狀，不一定是疾病真正原因。
Latency：
一個 Operation 從開始到得到結果需要多久。
Request sent 10:00:00.000
Response arrives 10:00:00.200
Latency：
200 ms
ms = millisecond（毫秒）
1000 ms = 1 second
假設：
100 ms
120 ms
130 ms
150 ms
5000 ms
Average：
1100 ms
但真實情況是：
4 個 Request 很快
1 個 Request 超級慢
Average 不一定能完整描述 User Experience。
因此 Production Monitoring 常看：
Percentile
Percentile（百分位數）：
把 Request Latency 從快到慢排序。
p50：
約 50% Request 的 Latency 小於或等於這個值。
p95：
約 95% Request 小於或等於這個值。
p99：
約 99% Request 小於或等於這個值。
例如：
p50 = 100 ms
p95 = 500 ms
p99 = 3 sec
表示：
大部分 Request 很快
但最慢的一小群可能非常慢
Tail = 尾巴。
Tail Latency：
Latency Distribution 中最慢的那一小部分 Request。
常觀察：
p95
p99
p99.9
因為 Average 很漂亮，不代表所有 User Experience 都很好。
Throughput：
System 在一段時間內能處理多少工作。
例如：
1,000 Requests / second
RPS：
Requests Per Second
也就是每秒 Request 數。
Latency
→ 一個 Request 多久？
Throughput
→ 一段時間處理多少 Request？
Error Rate：
所有 Request 中，發生 Error 的比例。
例如：
Total Requests = 10,000
Failed = 500
Error Rate = 5%
如果平常 0.1%，突然變成 10%，就是很重要的 Signal。
Traffic：
進入 System 的 Request / Data Flow 數量。
例如：
Normal = 1,000 RPS
Black Friday = 10,000 RPS
System 變慢時要先問：
System 壞了？
還是 Traffic 突然增加？
Saturation：
某個 Resource 已經接近或達到可承受上限。
例如：
CPU = 100%
Connection Pool = 100/100
Disk I/O ≈ Limit
像停車場：
100 個車位
100 個已滿
新的車只能等待。
Service Monitoring 常見四個重要方向：
Latency
Traffic
Errors
Saturation
簡單記：
Latency → Request 多久？
Traffic → 有多少 Request？
Errors → 有多少失敗？
Saturation → Resource 快滿了嗎？
Log：
Program 執行過程留下的事件文字紀錄。
例如：
2026-09-28 18:30:01 INFO User login success userId=123
2026-09-28 18:30:03 ERROR Database connection timeout
Metrics 可能告訴你：
Error Rate ↑
Logs 可以進一步告訴你：
發生哪一種 Error？
常見：
DEBUG
INFO
WARN
ERROR
DEBUG
很詳細、主要幫助開發與 Debug 的資訊。
INFO
正常但值得記錄的重要 Event。
WARN
有異常，但 System 可能仍能繼續。
ERROR
Operation 發生明確 Failure。
Bug：
Software 裡的錯誤或問題。
Debug：
找出、理解並修正 Software 問題的過程。
Logs 是 Debug Production Problem 的重要工具。
普通 Log：
User 123 failed login from Taiwan
人很好讀，但 Machine 不一定方便分析。
Structured Log：
把 Log 按固定欄位保存，方便 Search、Filter、Analyze。
例如：
{
"level": "ERROR",
"service": "auth-service",
"userId": 123,
"event": "LOGIN_FAILED"
}
可以搜尋：
service = auth-service
AND
event = LOGIN_FAILED
Timestamp：
某件事情發生的時間紀錄。
例如：
2026-09-28 18:30:03
它可以幫助 Engineer 對照：
18:30 Traffic ↑
18:31 CPU ↑
18:32 Error Rate ↑
18:32 DB Timeout Logs ↑
理解事件發生順序。
第三個核心 Signal：
Trace
在 Microservices：
User
↓
API Gateway
↓
Order Service
↓
Payment Service
↓
Inventory Service
↓
Database
User 只知道：
Checkout took 5 sec
到底哪一步慢？
Trace：
記錄一個 Request 經過多個 Service / Component 的路徑與時間。
當 Request 經過多個 Distributed Services：
Gateway
↓
Order
↓
Payment
↓
Database
追蹤整條路徑就叫：
Distributed Tracing
Distributed = 工作分散在不同 Component / Machine。
Tracing = 追蹤 Request 的旅程。
同時有 10,000 Requests 時，怎麼知道哪些資料屬於同一個 Request？
可以給 Request：
Trace ID = abc123
然後：
Gateway traceId=abc123
Order Service traceId=abc123
Payment traceId=abc123
搜尋 abc123 就可以串起整個 Request。
Request ID：
用來唯一識別某一次 Request 的 ID。
簡單 System 中 Request ID 可能已足夠。
Distributed Tracing 通常還會使用：
Trace ID
Span ID
Span：
一個 Trace 裡的一小段工作。
例如：
Trace
├── Gateway 20 ms
├── Order Service 100 ms
├── Payment 800 ms
└── Database 50 ms
每一段就是一個 Span。
Trace = 多個 Spans 組成
Span ID：
唯一識別某一個 Span 的 ID。
Trace ID = abc123
Span ID = s001 → Gateway
Span ID = s002 → Order
Span ID = s003 → Payment
Trace ID 回答：
是不是同一趟 Request？
Span ID 回答：
這趟 Request 裡是哪一段？
Order Service
↓
Payment Service
Order 的 Span 可以是：
Parent Span
Payment：
Child Span
Parent = 父層。
Child = 子層。
這能幫助重建 Service 之間的呼叫關係。
最簡單可以記：
System 現在有沒有異常？
例如：
Error Rate = 10%
p99 = 5 sec
到底發生了什麼？
例如：
DatabaseConnectionTimeout
這個 Request 經過哪裡？
哪一段最慢？
例如：
Gateway 20 ms
Order 50 ms
Payment 4500 ms ← Problem
Database 80 ms
Dashboard：
把重要 Metrics 用 Graph / Chart 集中顯示的畫面。
例如：
Request Rate : 5,000 RPS
p95 Latency : 300 ms
Error Rate : 0.2%
CPU : 65%
Engineer 不需要一直手動查每個數字。
Time Series：
按照時間順序記錄的一連串數值。
18:00 CPU 40%
18:05 CPU 45%
18:10 CPU 70%
18:15 CPU 95%
Trend：
數值隨時間大致往哪個方向變化。
例如 Memory：
40 → 50 → 60 → 70 → 80
持續上升的 Trend 可能值得調查。
Engineer 不可能 24 小時盯 Dashboard。
所以需要 Alert：
某個重要 Condition 發生時，自動通知相關人員。
例如：
Error Rate > 5%
for 5 minutes
Threshold：
判斷 Metric 是否超出正常範圍的門檻。
這裡的：
5%
就是 Threshold。
如果什麼都 Alert：
CPU 70% → Alert
CPU 71% → Alert
One Retry → Alert
One Failed Request → Alert
Engineer 每天收到 500 個 Alert，最後可能開始忽略。
這叫：
Alert Fatigue
也就是 Alert 太多造成「警報疲勞」。
好的 Alert 應該盡量對真正需要人處理的問題發出通知。
False Positive：
發出 Alert，但實際上沒有真正需要處理的問題。
例如 CPU 只短暫 95% 兩秒，這其實是正常 Spike。
False Negative：
真的有問題，但 Monitoring 沒有發出 Alert。
例如：
Checkout Failure = 30%
卻完全沒有警報。
SLI：
Service Level Indicator
Indicator = 指標。
SLI = 用來衡量 Service Quality 的實際數值。
例如：
Availability = 99.95%
p95 Latency = 200 ms
Success Rate = 99.9%
簡單記：
SLI = 實際量到多少？
SLO：
Service Level Objective
Objective = 目標。
SLO = 希望某個 SLI 達到什麼目標。
例如：
SLI:
Actual Availability = 99.95%
SLO:
Availability >= 99.9%
簡單記：
SLO = 我們希望做到多少？
SLA：
Service Level Agreement
Agreement = 協議。
SLA = Service Provider 和 Customer 之間對 Service Level
的正式承諾或協議。
例如：
Monthly Availability >= 99.9%
沒有達到時，Agreement 可能規定 Service Credit 或其他處理方式。
最簡單記：
SLI
→ 實際量到多少？
SLO
→ 希望做到多少？
SLA
→ 對 Customer 正式承諾多少？
例如：
SLI = 99.95%
SLO = 99.9%
SLA = 99.5%
實際公司的定義與數字會依 Business 而不同。
假設一個月約 30 天：
30 days
= 43,200 minutes
99.9% Availability 代表約 0.1% 時間可以不可用。
粗略：
43,200 × 0.001
≈ 43.2 minutes
也就是每月約 43 分鐘。
這只是建立直覺，實際 SLA 要依 Agreement 的計算方式。
如果：
SLO = 99.9%
代表允許大約：
0.1%
沒有達到 Availability。
這個可容忍範圍常叫：
Error Budget
不是說我們故意製造 Error。
而是承認：
100% Reliability 通常需要非常高的 Cost，因此 Business 要決定合理的
Reliability Target。
Incident：
影響或可能影響正常 Production Service 的異常事件。
例如：
Checkout Down
Payment Failure
Massive Latency Increase
Incident Response：
Team 發現、處理、恢復並追查 Incident 的流程。
Alert
↓
Investigate
↓
Find affected service
↓
Mitigate
↓
Recover
↓
Find Root Cause
Mitigation：
先降低問題造成的影響，不一定已經完全修掉 Root Cause。
例如新的 Deployment 造成 Error Rate 暴增。
先：
Rollback
讓 User 可以正常使用。
真正 Bug 之後再深入修。
Deployment：
把新的 Software Version 發布到某個 Environment 執行。
Code
↓
Build
↓
Test
↓
Deploy to Production
Rollback：
從新的 Version 切回前一個較穩定 Version。
Version 2
↓ Error Rate ↑
Rollback
↓
Version 1
假設：
18:00 Deploy V2
18:02 Error Rate ↑
18:03 p99 ↑
看起來 Deployment 和 Error 有關。
這叫 Correlation：
兩件事在時間或變化上看起來有關聯。
但：
Correlation 不一定等於 Causation。
Causation：
A 真正造成 B。
例如確認：
New Code
↓
DB Connections never closed
↓
Connection Pool exhausted
才比較能說找到真正原因。
這裡的 Request Path 不是 URL /users/123。
它是：
一個 Request 從進入 System 到完成，中間經過哪些 Component。
例如：
User
↓
Gateway
↓
Order
↓
Payment
↓
Database
Tracing 就是在觀察這條旅程。
Day 9 已經看過 Cardinality：
一個 Field 有多少不同 Value。
在 Metrics 也很重要。
例如：
status = 200
status = 404
status = 500
不同 Value 不多。
但：
user_id = 1
user_id = 2
...
user_id = 10,000,000
有非常多不同 Value。
這叫：
High Cardinality
可能增加：
Storage
Memory
Query Cost
Complexity
Label：
用來分類 Metric 的額外欄位。
例如：
http_requests_total{
method="GET",
status="200"
}
method 和 status 就是 Labels。
不是所有資訊都適合放進 Metric Label。
Observability 不代表：
把所有東西全部 Log
敏感資料例如：
Password
Access Token
Credit Card Number
Private Personal Data
通常不應直接寫進 Logs。
Logs 本身也需要：
Access Control
Security
Retention Policy
Retention：
Observability Data 要保留多久。
例如概念上：
Metrics → 90 days
Logs → 30 days
Traces → 7 days
保留越久：
Storage Cost ↑
所以要做 Trade-off。
假設：
1 Billion Requests / day
如果每一個 Request 都保存完整 Trace，Cost 可能非常高。
所以可以用：
Sampling
Sampling：
只挑部分 Request 保存完整觀察資料。
例如：
100 Requests
↓
Keep 10 Traces
就是約 10% Sampling。
Trade-off：
Cost ↓
但可能漏掉 Rare Problem
Rare Problem 就是非常少見的問題，例如 100,000 個 Request
才發生一次。
收集越多：
Metrics
Logs
Traces
需要越多：
Storage
Network
CPU
Monitoring Infrastructure
Money
所以不是：
Log Everything Forever
而是：
收集足夠資訊
+
控制 Cost
+
保護 Sensitive Data
User
↓
API Gateway
↓
Backend Services
/ | ↓ ↓ ↓
Redis Database External API
│ │ │
└───────┼───────┘
↓
Observability Data
/ | ↓ ↓ ↓
Metrics Logs Traces
\ | /
\ | /
↓ ↓ ↓
Dashboard
↓
Alert
↓
Engineer
不要一開始就回答：
Restart Server
可以：
1. Check Metrics
2. Check Traffic
3. Check Latency
4. Check Error Rate
5. Check Saturation
6. Check Logs
7. Check Traces
8. Check Recent Deployment / Config Change
9. Identify Bottleneck
10. Mitigate
11. Find Root Cause
User：
Checkout takes 5 sec
Metrics：
Traffic = Normal
CPU = Normal
Error Rate = Normal
p99 Latency = High
Trace：
Gateway 20 ms
Order 80 ms
Payment 4500 ms
Database 70 ms
Payment 最慢。
Payment Logs：
External Bank API Timeout
所以調查過程：
Symptom
Checkout Slow
↓
Metrics
p99 High
↓
Trace
Payment Slow
↓
Logs
External API Timeout
↓
Investigation
Root Cause
可以先記：
Metrics
↓
發現「有問題」
Logs
↓
了解「發生什麼」
Traces
↓
了解「問題在哪一段 Request Path」
不一定永遠照這個順序，但這是一個很容易理解的 Debugging Flow。
可以依序：
1. 確認 Error Rate 何時開始上升
2. 看同時間 Traffic 是否增加
3. 看 CPU / Memory / Connection Pool 是否 Saturated
4. 看 Error Logs 的 Error Type
5. 用 Trace 找 Failure 集中的 Service
6. 檢查最近 Deployment / Configuration Change
7. 先 Mitigate User Impact
8. 再確認 Root Cause
Average：
120 ms
看起來很好。
但：
p99 = 5 sec
代表最慢的一小群 Request 非常慢。
所以不能只看 Average，還要看：
p95
p99
Tail Latency
Gateway
↓
Order
↓
Inventory
↓
Payment
User 回報 Error。
使用：
Trace ID
串起：
Gateway Log
Order Log
Inventory Log
Payment Log
再透過 Distributed Trace 找：
哪個 Span Failure？
哪個 Span Latency 特別高？
1. Production System 是什麼？
2. Observability 是什麼？
3. Signal 是什麼？
4. Monitoring 是什麼？
5. Monitoring vs Observability？
6. Metrics 是什麼？
7. CPU / Memory Usage 是什麼？
8. Memory Leak 是什麼？
9. Root Cause vs Symptom？
10. Latency 是什麼？
11. Average Latency 有什麼限制？
12. Percentile 是什麼？
13. p50 / p95 / p99？
14. Tail Latency 是什麼？
15. Throughput / RPS 是什麼？
16. Latency vs Throughput？
17. Error Rate 是什麼？
18. Traffic 是什麼？
19. Saturation 是什麼？
20. Four Golden Signals？
21. Log 是什麼？
22. Log Levels？
23. Debug 是什麼？
24. Structured Log 是什麼？
25. Timestamp 為什麼重要？
26. Trace / Distributed Tracing？
27. Trace ID / Request ID？
28. Span / Span ID？
29. Parent / Child Span？
30. Metrics vs Logs vs Traces？
31. Dashboard 是什麼？
32. Time Series / Trend？
33. Alert / Threshold？
34. Alert Fatigue？
35. False Positive / False Negative？
36. SLI 是什麼？
37. SLO 是什麼？
38. SLA 是什麼？
39. SLI vs SLO vs SLA？
40. 99.9% Availability 大概代表什麼？
41. Error Budget 是什麼？
42. Incident / Incident Response？
43. Mitigation 是什麼？
44. Rollback / Deployment？
45. Correlation vs Causation？
46. Request Path 是什麼？
47. Cardinality / High Cardinality？
48. Metric Label 是什麼？
49. Sensitive Data 可以直接放 Log 嗎？
50. Retention 是什麼？
51. Sampling 是什麼？
52. Sampling 有什麼 Trade-off？
53. Observability 為什麼有 Cost？
54. Website 變慢怎麼調查？
55. Average 很低為什麼 User 還可能抱怨慢？
56. Microservices 怎麼 Debug？
Observability 的核心問題：
透過 System 對外產生的資訊，我們能不能理解內部正在發生什麼？
三個重要 Signal：
Metrics
Logs
Traces
可以先這樣記：
Metrics
→ System 有沒有異常？
Logs
→ 發生了什麼？
Traces
→ Request 經過哪裡？哪一段有問題？
重要 Service Signals：
Latency
Traffic
Errors
Saturation
Service Level：
SLI
→ 實際量到多少
SLO
→ 希望做到多少
SLA
→ 對 Customer 承諾多少
Production Problem：
Alert
↓
Metrics
↓
Logs / Traces
↓
Investigate
↓
Mitigation
↓
Root Cause
↓
Fix
最重要的一句：
沒有 Observability 的 Distributed
System，就像在沒有儀表板與警示燈的情況下開車；System
可能還在跑，但出問題時你很難知道到底發生了什麼。
現在我們可以發現 Failure、查看 Error、追蹤 Request。
下一個重要問題：
誰可以使用 API？
誰可以讀 Data？
Password 怎麼存？
HTTPS 保護什麼？
Attacker 一直嘗試登入怎麼辦？
下一篇：
Day 17｜Security：Authentication、Authorization、Encryption
到底差在哪裡？
會從零解釋：
Authentication
Authorization
Identity
Credential
Password Hashing
Salt
Session
Cookie
Token
JWT
HTTPS
TLS
Encryption
Hashing
Least Privilege
RBAC
SQL Injection
XSS
CSRF
並把 Security 放回我們前面建立的 System Architecture。
iThome鐵人賽
看影片追技術