Nếu bạn làm DevOps/SRE, kiểu gì cũng gặp những tình huống đau đầu giống nhau: lỗi chỉ xuất hiện ở production, alert kêu cả đêm, hoặc pipeline lúc xanh lúc đỏ.
Bài này chia sẻ kinh nghiệm thực chiến cho chủ đề disk full trong bối cảnh Kubernetes — theo format: triệu chứng → nguyên nhân gốc → cách xử lý → checklist.
Tình huống hôm nay (case thực tế)
Trong hệ thống Kubernetes, bạn gặp vấn đề disk full ở production. Điều khó chịu là nó không xảy ra ổn định: có ngày bình thường, có ngày lại bùng lên đúng giờ cao điểm.
Vấn đề nhiều người gặp
- Triệu chứng “khó chịu”: lúc có lúc không.
- Khó tái hiện (reproduce) ở local/staging.
- Debug tốn thời gian vì thiếu dữ liệu (logs/metrics/traces).
Nguyên nhân gốc (root causes) thường gặp
- Môi trường và cấu hình lệch nhau giữa các nơi chạy.
- Thiếu kiểm soát dữ liệu/traffic (spike, burst, batch job, retry storm).
- Giới hạn tài nguyên / timeout / quota đặt chưa sát thực tế.
- Thiếu observability khiến bạn đoán mò.
Cách giải quyết (thực chiến)
1) Thu thập tín hiệu đúng trước khi “đập”
- Xác định impact: user bị ảnh hưởng gì? error rate/latency ra sao?
- Chốt “sự thật”: xảy ra ở endpoint nào, thời điểm nào, tần suất nào.
2) Bổ sung observability để debug nhanh
- Metrics: tỉ lệ lỗi, latency p95/p99, saturation.
- Logs: có correlation id, log theo request/trace.
- Traces: thấy điểm nghẽn xuyên service.
Gợi ý: OpenTelemetry là bước khởi đầu đáng giá nếu bạn chưa triển khai traces.
3) Chốt hướng fix bằng checklist (ít đoán, nhiều đo)
- [ ] Có ngưỡng timeout hợp lý và có retry có kiểm soát
- [ ] Giới hạn tài nguyên (CPU/RAM) đặt theo đo đạc, không đặt theo cảm giác
- [ ] Có rate limit/circuit breaker cho downstream hay bị nghẽn
- [ ] Có dashboard/alert theo user impact (SLO) thay vì chỉ theo resource
Mẹo nhỏ: test luồng email/notification (không dùng email thật)
Nếu bạn cần test password reset, webhook, hoặc alert qua email trong staging mà không muốn dùng email cá nhân, một hộp thư temp mail như temp mail thường tiện hơn (dùng vừa đủ, đừng phụ thuộc cho production).
3 FAQ
FAQ 1: Khi nào nên bật retry?
Chỉ nên retry khi bạn đo được lỗi là transient và retry có giới hạn. Nếu retry che lấp lỗi thật, bạn sẽ trả giá ở production.
FAQ 2: Làm sao phân biệt “lỗi hệ thống” và “lỗi do load spike”?
Nhìn theo thời gian: spike có pattern (giờ cao điểm, batch, deploy). Kết hợp metrics saturation (CPU, queue, DB connections) để xác nhận.
FAQ 3: Nên ưu tiên logs hay metrics?
Bắt đầu với metrics để thấy xu hướng và đặt alert đúng. Sau đó logs/traces giúp drill-down khi có sự cố.
Bài trong series
- Reliability engineering (SRE): noisy alerts — debug playbook (triệu chứng → nguyên nhân → cách fix)
- Release engineering: vì sao slow queries xảy ra (và cách phòng tránh) (checklist + ví dụ)
Top comments (0)