Root Cause Analysis: Five Whys, Fishbone & Action Planning
Tại sao RCA Thường Bị Làm Sai
Root Cause Analysis (RCA) là phần cuối của incident lifecycle, và thường bị làm hời hợt vì áp lực từ nhiều phía: incident đã resolve, team mệt mỏi, stakeholders muốn "action items", và mọi người muốn move on.
Hậu quả của RCA hời hợt:
- Action items chỉ giải quyết triệu chứng (tăng memory limit, add retry) thay vì root cause
- Incident tái diễn sau vài tuần/tháng với cùng causal chain
- Team tốn engineering time cho firefighting thay vì phát triển
- Không có cải thiện detection → team luôn phát hiện khi khách hàng bị ảnh hưởng
RCA tốt không phải là viết văn. Nó là thinking framework để đảm bảo bạn đã tìm đến nguyên nhân thật sự, không phải dừng lại ở triệu chứng gần nhất.
Five Whys: Cơ Chế và Giới Hạn
Cơ Chế
Five Whys là technique đơn giản: hỏi "Tại sao?" liên tiếp cho đến khi tìm được root cause. Con số "5" chỉ là heuristic, không phải giới hạn cứng.
Ví dụ trong GKE context:
Problem: Service có 30% request errors trong 45 phút
Why 1: Tại sao 30% errors?
→ Vì backend Pods bị evict và chưa kịp được reschedule
Why 2: Tại sao Pods bị evict?
→ Vì node có DiskPressure, kubelet evict lowest QoS Pods
Why 3: Tại sao DiskPressure trên node đó?
→ Vì disk sử dụng đạt 97% (threshold 95%)
Why 4: Tại sao disk đầy đột ngột?
→ Vì một container ghi debug logs với verbose mode, tạo 20GB logs trong 2 giờ
Why 5: Tại sao debug verbose mode được bật trong production?
→ Vì deployment pipeline thiếu validation check cho environment-specific config
→ Developer enable debug trong config.yaml nhưng không được catch trước khi merge
ROOT CAUSE: Deployment pipeline thiếu validation ngăn debug config vào productionNhìn vào ví dụ: nếu dừng ở Why 2 ("Pods bị evict"), action sẽ là "add PodDisruptionBudget" — đúng nhưng không giải quyết vấn đề. Nếu dừng ở Why 3 ("DiskPressure"), action sẽ là "tăng disk size" — tốn tiền nhưng incident tái diễn khi debug logs đầy disk lớn hơn. Chỉ khi đến Why 5 mới thấy root cause thật.
Giới Hạn của Five Whys trong Distributed Systems
Giới hạn 1: Linear thinking trong nonlinear system
Five Whys assume một causal chain tuyến tính: A → B → C → D → E → F (root). Nhưng distributed system failures thường có multiple concurrent causes và nonlinear interactions:
Cause A: Memory leak (bắt đầu từ 2 ngày trước)
↘
→ OOM → Pod eviction → Latency spike
↗
Cause B: Traffic spike (bắt đầu từ 1 giờ trước)Nếu chỉ hỏi "Tại sao OOM?" → một trong hai causes. Bỏ qua cause kia → khi fix chỉ cause A, cause B vẫn có thể gây OOM khi traffic spike tiếp theo.
Giới hạn 2: "Stop too early" bias
Người hỏi có xu hướng dừng khi tìm thấy nguyên nhân đầu tiên có vẻ "technical enough" — như "memory leak trong code". Nhưng câu hỏi "Tại sao memory leak không được phát hiện trong testing?" hoặc "Tại sao không có alert cho memory trend?" cũng là những why quan trọng.
Giới hạn 3: "Blame person" trap
"Tại sao debug mode vào production? Vì developer X quên remove." DỪNG. Đây là blame, không phải root cause. Blameless postmortem culture đòi hỏi hỏi thêm: "Tại sao system design cho phép điều này xảy ra? Tại sao không có safeguard?"
Nguyên tắc: Five Whys phải dừng tại system-level failure (missing automation, missing test, missing alert, design flaw), không phải human error. Human error là triệu chứng của system failure.
Ishikawa (Fishbone) Diagram Cho Kubernetes
Tại sao Fishbone Phù Hợp Hơn Five Whys Cho Phức Tạp
Fishbone diagram (Cause and Effect diagram) phù hợp khi có nhiều potential causes cần explore đồng thời, không phải một causal chain tuyến tính.
Cấu trúc:
┌──────────────────────────────────────────┐
[Config] │ │ EFFECT
/ │ │ ────────
/ ─┼─────────────────────────────────────────►│ Service
▼ / │ │ Errors
───── / │ │
[People] / └──────────────────────────────────────────┘Categories Phù Hợp Cho Kubernetes/GKE Incidents
1. Workload (Application Layer):
- Resource requests/limits misconfigured?
- Liveness/readiness probe misconfigured?
- Graceful shutdown không implement đúng?
- Memory leak, goroutine leak?
- Connection pool không được manage đúng?
2. Platform (Kubernetes/GKE Layer):
- Node pool sizing không phù hợp?
- Autoscaler không scale kịp?
- NetworkPolicy quá restrictive?
- PodDisruptionBudget không set?
- RBAC permission thiếu?
3. Infrastructure (GCP Layer):
- VPC firewall rules block?
- Load balancer health check config?
- Cloud NAT capacity?
- Disk type (HDD vs SSD) không phù hợp với workload?
- Zone failure?
4. Process (Operational Layer):
- Deployment pipeline thiếu validation?
- Canary deployment không có proper rollback?
- Runbook chưa được cập nhật?
- Monitoring alerts quá nhiều noise → ignored?
- Change management (ai được phép change gì)?
5. Tooling/Observability:
- Alert thiếu hoặc không accurate?
- Logging thiếu context (không có trace ID)?
- Dashboard không có đủ visibility?
- Runbook không có command cụ thể để debug?
6. Environment/External:
- Upstream dependency thay đổi API?
- Certificate expired?
- Rate limit từ external service?
- DNS propagation delay?
Cách Sử Dụng Fishbone Trong RCA
- Vẽ fishbone diagram với effect là "incident symptom" ở đầu mũi tên
- Brainstorm potential causes trong mỗi category (không filter ngay)
- Với mỗi potential cause, hỏi "Có evidence nào confirm/deny điều này không?"
- Đánh dấu: Confirmed (evidence), Ruled out (evidence ngược), Unknown (cần investigate)
- Với Confirmed causes, áp dụng Five Whys để đào sâu
- Kết quả: Danh sách root causes (có thể nhiều hơn 1) với evidence support
Proximate Cause vs Root Cause: Phân Biệt Quan Trọng
Proximate cause (nguyên nhân gần): Sự kiện trực tiếp ngay trước incident. Root cause (nguyên nhân gốc rễ): Điều kiện cơ bản cho phép proximate cause xảy ra.
Ví dụ:
- Proximate cause: Pod bị OOM kill lúc 14:23
- Contributing factor: Memory limit set quá thấp (200Mi cho workload cần 350Mi)
- Root cause: Sizing process khi deploy service không có baseline memory profiling
Fix proximate cause: Tăng memory limit → incident không tái diễn ngay, nhưng service tiếp theo deploy với limit sai cũng sẽ OOM. Fix root cause: Add memory profiling step trong deployment checklist → tất cả service đều được size đúng.
Một incident thường có:
- Một proximate cause (cái trigger cuối cùng)
- Nhiều contributing factors (các yếu tố làm incident tồi tệ hơn hoặc khó recover)
- Một hoặc vài root causes (system-level gaps)
Tất cả cần được address — chỉ fix root cause không đủ nếu contributing factors vẫn còn đó.
Action Items Framework: 3 Tầng
RCA tốt sinh ra action items không phải "tăng memory limit" — mà là có structured plan để address toàn bộ causal chain.
Tầng 1: Immediate Mitigation (Stop Bleeding)
Xảy ra trong 0-4 giờ. Mục tiêu: restore service, không phải fix root cause.
Ví dụ:
- Rollback deployment về version trước
- Manually scale up Pods
- Tạm thời tăng resource limits
- Disable feature flag gây incident
- Restart service (với understanding rằng chỉ là temporary)
Lưu ý quan trọng: Immediate mitigation phải được document — "Chúng ta restart Pod lúc 15:10, nhưng root cause chưa được fix. Service có thể fail lại." Nếu không document, team có thể nghĩ vấn đề đã được fix và không follow up.
Tầng 2: Tactical Fix (Fix the Symptom Properly)
Xảy ra trong 1-7 ngày. Mục tiêu: giải quyết đúng triệu chứng để incident không tái diễn trong thời gian ngắn.
Ví dụ:
- Tăng memory limit với profiling-backed values (không phải guess)
- Set up PodDisruptionBudget để prevent mass eviction
- Tune liveness probe settings dựa trên actual startup time
- Fix bug trong application gây memory leak
Tactical fix phải có success criteria rõ ràng: "Memory usage không vượt quá 70% limit trong 7 ngày tiếp theo" — không phải "fix memory issue".
Tầng 3: Strategic Improvement (Address Root Cause)
Xảy ra trong 1-4 tuần. Mục tiêu: thay đổi system để class of incident này không thể xảy ra, hoặc được phát hiện sớm hơn.
Ví dụ:
- Thêm memory profiling step vào deployment process
- Tạo automated validation trong CI pipeline check config values
- Set up predictive alerting cho memory trend (alert khi memory tăng 10% week-over-week)
- Implement load testing với realistic production traffic patterns
- Update Terraform module defaults để có resource limits hợp lý
Strategic improvements thường khó nhất vì cần thay đổi process, không chỉ code. Cần có owner rõ ràng và deadline để không bị "lost in backlog".
Cải Thiện Detection: Từ Reactive sang Proactive
Một trong những outcome quan trọng nhất của RCA là câu hỏi: "Chúng ta có thể phát hiện sớm hơn không?"
Phân Tích Detection Timeline
Từ incident timeline đã xây dựng (xem Chapter 05), identify:
- T0: Root cause bắt đầu (ví dụ: memory leak bắt đầu từ deploy lúc T0)
- T_detect: Team phát hiện incident (ví dụ: customer complain lúc T+2h)
- Detection lag: T_detect - T0 = 2 giờ
Gap analysis: Tại mỗi điểm trong 2 giờ đó, có signal nào có thể phát hiện vấn đề không?
- T+15m: Memory usage tăng 5% → có alert cho memory trend?
- T+45m: P99 latency tăng 20% → có alert cho latency degradation?
- T+90m: Error rate tăng 0.1% → có alert cho error rate?
Nếu có signal nhưng không có alert → thêm alert. Nếu có alert nhưng bị ignored (noise) → tune alert threshold. Nếu signal không tồn tại → thêm metric/log.
Alert Effectiveness
Alert tốt trong production GKE:
- High signal-to-noise ratio: Alert fire → team investigates → thực sự có vấn đề (không phải false positive)
- Actionable: Alert message cho biết làm gì tiếp theo (link đến runbook)
- Timely: Alert fire đủ sớm để có thể mitigate trước khi user impact
- Minimal: Không quá nhiều alerts → alert fatigue → alerts bị ignored
Common anti-pattern: Alert trên causes thay vì symptoms. Alert "CPU > 80%" không actionable vì CPU cao đôi khi bình thường. Alert "P99 latency > 2s" thì actionable vì đó là user-facing impact.
Google's approach (SRE): Alert trên SLO burn rate — tốc độ đang consume error budget. Nếu error budget đang burn 14x faster than normal → alert, dù error rate tuyệt đối còn thấp. Đây là early warning system thay vì threshold-based alert.
Blameless Culture: Tại sao Quan Trọng và Cách Thực Hành
Blameless không có nghĩa là "không có accountability". Nó có nghĩa là:
- Focus vào system failures thay vì human failures
- Người gây incident không sợ nói thật → thu thập đầy đủ thông tin
- Team học từ incident thay vì giấu diếm
Trong GKE context: Khi developer vô tình deploy config sai vào production:
- Blame approach: "Developer X deploy sai → cần training"
- Blameless approach: "Tại sao system cho phép deploy config sai vào production? Cần validation step trong pipeline"
Blame approach làm developer ngại mention vấn đề trong tương lai. Blameless approach improve system.
RCA Document Template
Một RCA document tốt không cần dài. Cần có:
## Incident Summary
- Service/Component bị ảnh hưởng:
- Thời gian (start → resolve):
- User impact:
- Severity:
## Timeline
[Events theo thứ tự thời gian, từ trigger đến resolve]
## Root Cause Analysis
- Proximate cause:
- Contributing factors:
- Root cause(s):
## Why This Wasn't Caught Earlier
[Gap trong monitoring/alerting/testing/process]
## Action Items
| Action | Type | Owner | Due Date | Success Criteria |
|--------|------|-------|----------|-----------------|
| [Immediate mitigation] | Immediate | | T+4h | |
| [Tactical fix] | Tactical | | T+7d | |
| [Strategic improvement] | Strategic | | T+30d | |
## What Went Well
[Điều gì hoạt động tốt trong response?]Anti-Pattern: Action Items Không Có Owner và Deadline
Tại sao phổ biến: Sau RCA, team viết action items vào Google Doc, share vào Slack. Không có assignment rõ ràng, không có deadline.
Hậu quả: 3 tháng sau, incident tương tự xảy ra. Team mở RCA cũ và thấy action items chưa được implement.
Fix đơn giản: Mỗi action item phải có:
- Owner: Tên cụ thể, không phải team hay role
- Due date: Ngày cụ thể, không phải "soon" hoặc "next sprint"
- Success criteria: Làm sao biết action item đã hoàn thành?
- Review mechanism: Ai review completion? Khi nào?
Thường best practice là track action items trong project management tool (Linear, Jira, GitHub Issues) với proper tracking, không chỉ trong RCA document.
Kết Luận: Vòng Lặp Cải Thiện Liên Tục
Framework debugging hoàn chỉnh tạo ra một vòng lặp:
Incident detect
↓
Immediate mitigation (restore service)
↓
Root cause analysis (understand why)
↓
Action items (fix system, not symptoms)
↓
Detection improvement (catch earlier next time)
↓
[System improved → fewer incidents, faster detection]
↓
[Next incident, if any, at different layer] → repeatĐây không phải "debugging incidents" — đây là engineering reliability vào hệ thống. Mỗi incident là cơ hội để hệ thống tốt hơn. RCA tốt + action items hoàn thành = investment vào reliability của toàn bộ platform.