Website có thể mở được nhưng khách vẫn gặp lỗi. Chẳng hạn, họ xem sản phẩm bình thường nhưng không gửi liên hệ hoặc thanh toán được. Khi đó, website có thể đang trả về lỗi 500, 502, 503 hoặc 504. Bài viết giúp bạn nhận biết mức ảnh hưởng, biết lúc nào cần báo kỹ thuật và cách kiểm tra sau khi sửa.
Nếu đang gặp lỗi: hãy ghi trang bị lỗi, giờ xảy ra và ảnh chụp. Với biểu mẫu hoặc thanh toán, kiểm tra yêu cầu đã được nhận chưa trước khi thử lại. Phần dưới hướng dẫn đội kỹ thuật đo số lần lỗi và tìm nguyên nhân.
Lỗi 5xx là gì? Phân biệt 500, 502, 503, 504
HTTP 5xx là nhóm mã lỗi cho biết máy chủ hoặc hệ thống phía sau không hoàn tất yêu cầu. Bốn mã thường gặp là:
- 500: ứng dụng hoặc máy chủ gặp lỗi xử lý chung.
- 502: máy chủ trung gian nhận phản hồi không hợp lệ từ máy phía sau.
- 503: dịch vụ tạm không sẵn sàng, có thể do bảo trì hoặc quá tải.
- 504: máy chủ trung gian chờ hệ thống phía sau quá lâu.
Mã 500–504 giúp đội kỹ thuật biết nên kiểm tra thành phần nào trước. Chúng chưa chỉ ra nguyên nhân chính xác. Chủ doanh nghiệp chỉ cần biết trang nào không dùng được và việc đó có làm mất liên hệ hoặc gián đoạn đơn hàng không.
Chủ doanh nghiệp cần làm gì khi xuất hiện lỗi 5xx?
Trước tiên, ghi địa chỉ trang lỗi, thời điểm và ảnh chụp màn hình. Nếu liên hệ hoặc thanh toán gặp lỗi, yêu cầu kỹ thuật kiểm tra ngay. Đừng tự tắt hàng loạt plugin hoặc khôi phục dữ liệu khi chưa có phương án an toàn.
| Khách nhìn thấy | Rủi ro | Việc cần xác nhận |
|---|---|---|
| Trang sản phẩm báo lỗi | Khách không xem được thông tin | Trang nào lỗi, xảy ra khi nào? |
| Gửi liên hệ bị lỗi | Có thể bỏ sót khách tư vấn | Yêu cầu đã được nhận chưa? |
| Thanh toán báo 502/504 | Giao dịch gián đoạn hoặc gửi lại | Đơn có thành công không, có bị trùng không? |
Vì sao trang chủ vẫn mở nhưng khách không gửi liên hệ được?
Trang chủ có thể trả mã 200 nhưng thanh toán lại báo 500. Do đó giám sát khả năng truy cập cần kết hợp đo lỗi ở các đường dẫn quan trọng, không chỉ kiểm tra trang chủ.
Dùng số liệu nào để biết website đang lỗi nhiều?
Tỷ lệ lỗi 5xx = số yêu cầu trả mã 5xx / tổng yêu cầu trong cùng thời gian × 100%. Ví dụ giả định: 30 lỗi/1.500 yêu cầu là 2%; 30 lỗi/60 yêu cầu là 50%. Một lỗi thanh toán vẫn có thể nghiêm trọng dù tỷ lệ lỗi toàn website thấp. Phải ghi rõ cách tính bot, yêu cầu thử và yêu cầu lặp.
Một website có ít lượt truy cập vẫn có thể gặp sự cố nghiêm trọng. Đừng chỉ nhìn phần trăm. Phải xem khách không dùng được chức năng nào, xảy ra lúc nào và có lỗi lặp lại hay không.
Dành cho kỹ thuật: kiểm tra từng mã lỗi 500–504
| Mã | Nghĩa kỹ thuật | Bằng chứng cần điều tra |
|---|---|---|
| 500 | Application/server gặp lỗi không xử lý được | Exception, PHP-FPM, web server log, thay đổi code |
| 502 | Gateway/proxy nhận phản hồi không hợp lệ từ upstream | Reverse proxy, origin, upstream headers và connection |
| 503 | Dịch vụ tạm không sẵn sàng, có thể bảo trì/quá tải | Tải hệ thống, trạng thái bảo trì, Retry-After khi áp dụng |
| 504 | Proxy/gateway không nhận phản hồi upstream đúng hạn | Upstream latency, timeout, pool, dependency |
Các mã chỉ xác định vị trí và loại triệu chứng, không chứng minh nguyên nhân gốc. Tham khảo định nghĩa HTTP 500, 502, 503 và 504 từ MDN.
Thông tin đội kỹ thuật cần để tìm nguyên nhân
- Mã lỗi 500/502/503/504 và đường dẫn bị ảnh hưởng (endpoint/route).
- Tỷ lệ lỗi (error rate), tổng yêu cầu và khoảng thời gian đo.
- Thời gian phản hồi (latency), p95/p99 nếu có số liệu.
- Thời điểm, múi giờ và lần cập nhật gần nhất (deployment).
- Dịch vụ phía sau (upstream), CPU/RAM và kết nối dữ liệu.
- Mã đối chiếu yêu cầu (request ID) và log đã che thông tin riêng tư.
Những nguyên nhân kỹ thuật cần kiểm tra
- Lỗi chương trình hoặc PHP sau cập nhật plugin/mã nguồn.
- Cơ sở dữ liệu phản hồi chậm hoặc hết kết nối.
- API bên ngoài lỗi, phản hồi quá chậm.
- CPU, RAM hoặc PHP-FPM hết khả năng phục vụ.
- Bộ nhớ đệm, proxy hoặc cấu hình chưa đúng.
- Tác vụ nền, bảo trì, mở rộng máy chủ chậm hoặc kết nối DNS/TLS.
Mã 5xx là triệu chứng, không phải kết luận. Nếu dùng CDN, cần phân biệt lỗi ở máy chủ gốc (origin) và lớp trung gian (edge). Cloudflare hướng dẫn đối chiếu hai lớp mã này.
Khi nào website cần gửi cảnh báo?
Không có ngưỡng cảnh báo chung. Nên xét tỷ lệ lỗi, lượng yêu cầu tối thiểu, khoảng đo và trang liên quan. Ví dụ giả định: đánh giá một trang có ít nhất 100 yêu cầu trong 5 phút theo ngưỡng riêng đã thống nhất. Với trang ít khách, vẫn cần thử thanh toán và biểu mẫu để tránh bỏ sót lỗi.
| Tín hiệu | Vì sao cần |
|---|---|
| Error rate theo route | Không để homepage khỏe che checkout lỗi |
| Số request / cửa sổ thời gian | Tránh so phần trăm của vài request với lượng truy cập lớn |
| Latency p95/p99, thời gian upstream | Phát hiện degradation trước khi timeout |
| Deployment marker và dependency | Xem sự cố có bắt đầu sau thay đổi không |
| Kiểm tra tổng hợp checkout/form | Phát hiện luồng kinh doanh lỗi ngay cả khi HTTP 200 |
Lỗi nào phải xử lý khẩn, lỗi nào có thể theo dõi?
- P1: error rate cao trên route business-critical hoặc 5xx diện rộng;
- P2: lỗi tăng rõ trên một nhóm endpoint nhưng còn workaround;
- P3: spike ngắn, một route ít quan trọng hoặc lỗi đã tự phục hồi.
Mức P1/P2/P3 cần theo thỏa thuận vận hành (SLA). Prometheus khuyến nghị cảnh báo khi thực sự cần người xử lý, tránh quá nhiều thông báo không hữu ích.
8 bước xử lý khi lỗi máy chủ tăng
Quy trình phải có người chịu trách nhiệm. Người trực xác định ảnh hưởng; kỹ thuật ứng dụng xem lỗi chương trình; kỹ thuật hạ tầng xem proxy, PHP-FPM và tài nguyên. Chỉ người được phép mới hoàn tác cập nhật (rollback). Không khởi động lại hàng loạt nếu chưa rõ ảnh hưởng đến dữ liệu.
- Xác nhận trang, mã lỗi và chức năng khách bị ảnh hưởng.
- Đối chiếu với bản cập nhật hay thay đổi gần nhất.
- Kiểm tra log ứng dụng, web server và request ID.
- Kiểm tra dữ liệu, API và hệ thống liên quan.
- Đối chiếu CPU, RAM, PHP-FPM và tỷ lệ lỗi.
- Chỉ hoàn tác thay đổi khi có căn cứ và phương án an toàn.
- Thử lại liên hệ, đăng nhập hoặc thanh toán bằng dữ liệu kiểm thử.
- Theo dõi lỗi, thời gian phản hồi và đơn hàng sau khi phục hồi.
Nếu lỗi đến từ dịch vụ kết nối bên ngoài thì sao?
Nếu lỗi đến từ upstream hoặc integration, API Monitoring giúp phân biệt application lỗi với dependency ngoài chậm hoặc timeout.
Làm sao biết đơn hàng hoặc yêu cầu tư vấn có bị ảnh hưởng?
Không thể khẳng định mất đơn chỉ từ tỷ lệ 5xx. Cần đối chiếu tình trạng thanh toán, đơn hàng và liên hệ. Giám sát hành trình khách hàng còn phát hiện thao tác thất bại dù hệ thống trả mã 200.
Mẫu phiếu báo lỗi gửi cho đội kỹ thuật
| Trường | Ví dụ mô phỏng |
|---|---|
| Phát hiện | Checkout /checkout, HTTP 502 tăng liên tục sau deploy |
| Thời gian và phạm vi | Từ 14:05 đến 14:15, mobile và desktop |
| Số liệu | 30 lỗi / 1.500 request = 2% trong 10 phút |
| Tác động | Có khả năng ảnh hưởng đặt hàng, chưa kết luận thất thoát tiền |
| Bằng chứng | Request ID, proxy log, ứng dụng, mốc release |
| Owner / quyết định | Đội vận hành triage; người phụ trách phê duyệt rollback |
| Xác minh phục hồi | Smoke test thanh toán, error rate và trạng thái đơn |
Bảng trên là ví dụ giả định, không phải lỗi đang xảy ra tại websitehcm.com. Không đưa mật khẩu, mã truy cập, token hoặc thông tin cá nhân vào phiếu công khai.
Danh sách kiểm tra giám sát lỗi 5xx
- Theo dõi mã lỗi và tỷ lệ 5xx theo từng đường dẫn.
- Ghi số yêu cầu, khoảng đo và trạng thái trang quan trọng.
- Theo dõi p95/p99, tải máy chủ, dịch vụ ngoài và lần cập nhật.
- Phân mức P1/P2/P3; giao người trực và quy trình xử lý.
- Thử cảnh báo và kiểm tra lại ngưỡng định kỳ.
Những sai sót khiến hệ thống bỏ sót lỗi
- Chỉ ping homepage và kết luận toàn bộ website khỏe.
- Chỉ cảnh báo tổng số lỗi không xét lượng truy cập và loại endpoint.
- Không phân biệt lỗi 5xx từ CDN, web server, ứng dụng và API bên ngoài.
- Alert mỗi lỗi đơn lẻ dẫn tới mệt mỏi cảnh báo và bỏ qua vấn đề thật.
- Rollback mà không đối chiếu ảnh hưởng dữ liệu, phiên xử lý và kết quả kiểm thử.
Sau xử lý, so log, request ID và số liệu trước/sau. Chỉ đóng sự cố khi chức năng thực tế hoạt động và tỷ lệ lỗi ổn định trong khoảng theo dõi phù hợp.
Câu hỏi thường gặp
Một lỗi 500 có cần P1 không?
Không nhất thiết. Nhưng một lỗi 500 ở thanh toán vẫn có thể phải báo khẩn nếu gây ảnh hưởng nghiêm trọng. Không chỉ nhìn số lần lỗi.
502 và 504 có luôn do hosting không?
Không. Lỗi có thể xảy ra ở máy chủ trung gian, máy chủ xử lý phía sau hoặc dịch vụ được kết nối. Kỹ thuật phải kiểm tra nhật ký trước khi kết luận.
Có nên theo dõi 4xx cùng 5xx?
Có thể theo dõi riêng. 4xx thường liên quan yêu cầu hoặc quyền truy cập; bài này tập trung vào lỗi 5xx phía hệ thống.
Kết luận
Giám sát 5xx giúp phát hiện lỗi trước khi toàn website ngừng hoạt động. Cần đo tỷ lệ lỗi theo đường dẫn và ảnh hưởng thực tế, rồi giao đúng người xử lý.
Trong Website Monitoring, error-rate monitoring là lớp nối giữa uptime, application health và incident response.
Tìm nguyên nhân sâu hơn khi vẫn còn lỗi
5xx là dấu hiệu ở lớp HTTP. Muốn tìm nguyên nhân trong chương trình, xem giám sát lỗi ứng dụng. Để đối chiếu sự kiện, xem nhật ký có cấu trúc và quan sát hệ thống website.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.