Debugging & Troubleshooting: Nghệ thuật Giải quyết Vấn đề

Trả lời: Là quá trình tìm kiếm, xác định nguyên nhân và loại bỏ các lỗi (bugs) trong mã nguồn hoặc hệ thống.

Trả lời:

• Syntax error: Code sai quy tắc ngôn ngữ, không thể chạy được (dễ tìm).
• Bug logic: Code chạy được nhưng kết quả sai so với mong đợi (khó tìm hơn).

Trả lời: Dùng các lệnh như echo, print_r, var_dump, dd() để in giá trị biến ra màn hình. Dùng cho các lỗi đơn giản, nhanh chóng.

Trả lời: Thông báo lỗi thường chứa 90% thông tin cần thiết để sửa bug (loại lỗi, file nào, dòng bao nhiêu). Đừng bỏ qua chúng!

Trả lời: Là việc tìm ra các bước cụ thể để lỗi đó lặp lại một cách ổn định. Nếu không reproduce được, bạn sẽ rất khó để kiểm tra xem mình đã sửa đúng chưa.

Trả lời: Log chứa lịch sử hoạt động và các thông báo lỗi ẩn mà trình duyệt hoặc terminal có thể không hiển thị hết.

Trả lời: Bình tĩnh. Đọc kỹ thông báo lỗi. Copy thông báo lỗi lên Google hoặc StackOverflow để xem người khác xử lý thế nào.

Trả lời: Comment một nửa đoạn code nghi ngờ lỗi. Nếu lỗi mất -> lỗi nằm ở nửa đó. Tiếp tục chia đôi cho đến khi tìm đúng dòng lỗi.

Trả lời: Là danh sách các hàm được gọi theo thứ tự ngược lại dẫn đến điểm xảy ra lỗi. Giúp bạn biết request đã “đi qua những đâu” trước khi chết.

Trả lời: Giải thích từng dòng code cho một con vịt cao su (hoặc bất cứ đồ vật nào). Quá trình diễn đạt bằng lời giúp não bộ nhận ra lỗ hổng logic nhanh hơn.

Trả lời: Cho phép bạn dừng chương trình tại một dòng (Breakpoint), xem giá trị của tất cả biến hiện tại và chạy từng dòng một để quan sát thay đổi.

Trả lời: Dùng Network tab trong Chrome DevTools để xem: URL gọi đúng chưa, Headers (Token, Cookie) có đủ không, và Payload gửi lên có đúng cấu trúc không.

Xử lý: 1. Kiểm tra file log trong storage/logs/laravel.log. 2. Kiểm tra quyền ghi thư mục storage. 3. Kiểm tra file .env (đặc biệt là APP_DEBUG).

Xử lý: 1. Kiểm tra sự khác biệt phiên bản PHP/Library. 2. Kiểm tra cấu hình server (Nginx, PHP-FPM). 3. Kiểm tra các kết nối bên thứ 3 bị chặn bởi Firewall.

Trả lời: Công cụ tự động tìm commit lỗi bằng cách duyệt qua lịch sử commit theo thuật toán tìm kiếm nhị phân.

Xử lý: 1. Tìm vòng lặp vô tận. 2. Tìm các mảng dữ liệu quá lớn nạp vào RAM. 3. Dùng memory_get_usage() tại các điểm nghi ngờ để theo dõi dung lượng RAM tăng.

Xử lý: Dùng Laravel Debugbar hoặc Clockwork. Chúng sẽ liệt kê toàn bộ các câu query SQL thực thi trong request đó và cảnh báo nếu có query lặp lại.

Xử lý: 1. Chuyển queue driver sang sync để chạy trực tiếp trong request. 2. Hoặc dùng Log::info() bên trong hàm handle() của Job. 3. Kiểm tra bảng failed_jobs.

Trả lời:

• Bohrbug: Lỗi xuất hiện ổn định khi lặp lại các bước.
• Heisenbug: Lỗi biến mất hoặc thay đổi khi bạn cố gắng quan sát/debug nó (thường do race condition hoặc bộ nhớ).

Xử lý: Kiểm tra Header Access-Control-Allow-Origin ở phía Server. Đảm bảo server cho phép domain của frontend gọi tới.

Trả lời: Thêm log chi tiết kèm timestamp (ms). Sử dụng các công cụ như Distributed Tracing. Cố gắng cô lập và tái hiện lỗi bằng cách giả lập độ trễ mạng khác nhau.

Trả lời: Theo dõi các tín hiệu mà ứng dụng gửi cho nhân hệ điều hành (mở file, kết nối mạng). Cực kỳ hữu ích khi app bị treo mà không có log.

Xử lý: Dùng EXPLAIN để xem DB có dùng index không. Kiểm tra log slow_query_log của MySQL. Xem xét việc query có bị block bởi một transaction khác đang lock bảng không.

Xử lý: Xem log lỗi của DB engine (ví dụ SHOW ENGINE INNODB STATUS). Sắp xếp lại thứ tự update bảng trong code để luôn thống nhất, tránh việc 2 transaction chờ nhau.

Xử lý: 1. Thu thập dữ liệu ngữ cảnh tối đa (user nào, lúc mấy giờ, input là gì). 2. Kiểm tra các yếu tố ngẫu nhiên (Cache, External API). 3. Kiểm tra sự quá tải tài nguyên tại thời điểm đó.

Trả lời: Các công cụ này cho bạn cái nhìn chi tiết về thời gian chạy của từng hàm, số lần gọi, và lượng RAM tiêu thụ, giúp tối ưu hóa code một cách khoa học.

Xử lý: 1. Kiểm tra logic xóa cache khi dữ liệu đổi. 2. Kiểm tra xem có 2 nơi cùng ghi vào 1 key không. 3. Tạm thời tắt cache để xác nhận lỗi nằm ở cache hay logic DB.

Xử lý: Dùng docker logs, docker exec -it <container_id> bash để vào bên trong kiểm tra file hệ thống, quyền hạn và kết nối mạng nội bộ.

Xử lý: Dùng htop để theo dõi. Sử dụng các công cụ như valgrind (cho C extension) hoặc theo dõi memory_get_usage() và tự động restart worker định kỳ.

Xử lý: Kiểm tra log access của Nginx. Sử dụng các công cụ giám sát hạ tầng để xem tài nguyên nào cạn kiệt trước (CPU, RAM, hay số lượng DB connections).

Trả lời:

1. Phát hiện (Monitoring/Alert). 2. Phản ứng (Xác nhận lỗi, thông báo team). 3. Cô lập (Tắt tính năng lỗi, switch sang dự phòng). 4. Khắc phục. 5. Post-mortem (Phân tích nguyên nhân và giải pháp ngăn chặn).

Trả lời: Cần Structured Log kèm Correlation ID. Phân cấp log lưu trữ: Hot data (Elasticsearch) cho 7 ngày, Cold data (S3) cho 1 năm. Đảm bảo không log thông tin nhạy cảm.

Trả lời: Tích hợp các SDK như Sentry/Bugsnag. Khi có exception, app tự động đính kèm trạng thái biến, thông tin user, và các bước request trước đó gửi về server tập trung.

Trả lời: Dùng ML để nhận diện pattern lỗi từ log và gợi ý giải pháp. Tự động rollback các bản deploy nếu phát hiện chỉ số Error rate tăng đột biến (Canary Analysis).

Xử lý: 1. Kiểm tra kết nối tới các API bên thứ 3 (có thể bị timeout). 2. Kiểm tra số lượng DB connections (có thể bị kịch trần). 3. Kiểm tra tốc độ mạng (Bandwidth). 4. Kiểm tra DNS resolution.

Xử lý: 1. Dùng tính năng “Impersonate” để đăng nhập dưới quyền user đó. 2. Xem kỹ log riêng của user đó. 3. Kiểm tra xem dữ liệu của user đó có gì đặc biệt (ký tự lạ, dung lượng quá lớn).