Hiện tượng: Docker container hoạt động ổn định trên máy cá nhân (local), nhưng khi deploy lên production lại phát sinh lỗi hoặc crash, mặc dù digest của image hoàn toàn khớp nhau.

Nguyên nhân cốt lõi: Sự khác biệt về môi trường thực thi bên ngoài container (host OS, phần cứng, tài nguyên), cấu hình mạng, biến môi trường, hoặc quyền truy cập tệp tin hệ thống.

Các yếu tố chính cần kiểm tra & điều tra

1. Biến môi trường & Tệp cấu hình (Environment Variables & Configs):
   • Kiểm tra xem các file .env hoặc biến truyền vào khi chạy container trên production có bị thiếu, sai định dạng hoặc khác biệt so với local hay không.
2. Tài nguyên hệ thống (Resource Limits):
   • Production có thể áp đặt giới hạn về CPU hoặc RAM (cgroup limits) khiến ứng dụng bị OOM (Out Of Memory) hoặc thiếu tài nguyên xử lý.
3. Kiến trúc phần cứng / OS (Architecture & CPU Architecture):
   • Xung đột kiến trúc (ví dụ: build image trên máy Mac Apple Silicon ARM64 nhưng deploy lên server chạy Linux AMD64/x86_64).
4. Volumes & File System Mounts:
   • Vấn đề phân quyền (permissions), thiếu dữ liệu mount, hoặc sự khác biệt về hệ thống tệp (case-sensitivity giữa macOS/Windows và Linux).
5. Mạng & Cấu hình tường lửa (Networking & DNS):
   • Khác biệt về cấu hình port binding, kết nối database nội bộ, hoặc cấu hình phân giải tên miền (DNS) trên server production.

Quy trình điều tra và khắc phục khi container chạy hoàn hảo trên môi trường local nhưng lại gặp lỗi ở production dù sử dụng chính xác cùng một image

Hiện tượng: API hoạt động hoàn hảo sau khi deploy, nhưng sau khoảng 6 giờ, dung lượng bộ nhớ (memory) tăng vọt lên 95%. Khởi động lại server chỉ khắc phục được tạm thời.

Nguyên nhân cốt lõi: Ứng dụng bị rò rỉ bộ nhớ (Memory Leak) hoặc nghẽn tài nguyên do cấp phát bộ nhớ liên tục nhưng không được giải phóng hay thu gom rác (Garbage Collection).

Các bước điều tra & chẩn đoán

1. Thu thập dữ liệu (Metrics & APM): Kiểm tra các công cụ giám sát để xem lượng RAM tăng có đồng bộ với một endpoint cụ thể, traffic spike hay background job nào không.
2. Chụp Heap Dump: Lấy heap dump khi RAM chạm ngưỡng cao (95%) và so sánh với bản snapshot thời điểm vừa khởi động để tìm các object tăng trưởng bất thường về số lượng/kích thước.
3. Profiling: Chạy công cụ profiler chuyên dụng của ngôn ngữ (pprof, node heap snapshot, Java Flight Recorder...) để truy vết hàm hoặc module đang giữ tham chiếu.

Các thủ phạm phổ biến cần kiểm tra

• Unbounded Caches: Cache trong bộ nhớ không có giới hạn kích thước (Max size) hoặc thời gian sống (TTL).
• Event Listeners: Đăng ký lắng nghe sự kiện nhưng quên hủy (unsubcribe) sau khi dùng.
• Connection Pools: Kết nối database hoặc HTTP client không được đóng đúng cách.
• Global Variables / Singletons: Lưu trữ trạng thái tích lũy vô thời hạn qua các request.
• Background Workers: Hàng đợi xử lý công việc chậm hơn tốc độ đẩy task vào, khiến queue phình to trong RAM.

Quy trình từng bước điều tra và khắc phục sự cố rò rỉ bộ nhớ (Memory Leak) khiến RAM tăng vọt lên 95% sau 6 giờ hoạt động trong các ứng dụng Backend.

Khám phá cách đánh index theo composite key, sử dụng index filter và giám sát query execution plan với EXPLAIN ANALYZE trên MySQL/MariaDB.

Tối ưu hóa chỉ mục B-Tree hỗn hợp và chiến lược phân vùng bảng (partitioning) khi quy mô dữ liệu vượt qua hàng triệu bản ghi.