Website bị down, không truy cập được: Cách triage và phục hồi an toàn

Website bị down hoặc không truy cập được là tình huống người dùng không thể mở website, nhưng nguyên nhân có thể nằm ở nhiều lớp khác nhau: domain, DNS, SSL, CDN, hosting, web server, database, application hoặc một thay đổi vừa triển khai. Cách xử lý an toàn là triage theo lớp thay vì thử ngẫu nhiên.

Tóm tắt: Hãy xác nhận phạm vi, kiểm tra DNS/SSL trước, sau đó origin/server, resource, database, application và recent change. Freeze thay đổi, giữ log/snapshot cần thiết, chọn recovery path nhỏ nhất có thể và smoke test sau khi website online lại.

Bước đầu tiên: xác nhận website thật sự đang down

Không nên dựa vào một trình duyệt hoặc một mạng. Kiểm tra từ nhiều thiết bị/mạng hoặc probe ngoài hệ thống. Xác định lỗi xảy ra với toàn site hay chỉ một URL, frontend hay admin, mọi khu vực hay một location.

Uptime Monitoring giúp phát hiện availability, nhưng incident response cần đi thêm bước xác định lớp nào gây lỗi.

Checklist triage theo từng lớp

1. Domain và DNS

Kiểm tra domain còn hiệu lực, nameserver đúng, A/AAAA/CNAME có resolve về địa chỉ kỳ vọng và có thay đổi DNS gần đây không. Xem giám sát Domain, DNS và SSL để có baseline trước khi sự cố xảy ra.

2. SSL và HTTPS

Nếu DNS đúng nhưng browser báo certificate, kiểm tra expiry, hostname, chain và renewal/deployment gần nhất. Không nên tắt HTTPS hoặc bỏ qua lỗi chứng chỉ như một “cách sửa”.

3. CDN / reverse proxy

Nếu dùng CDN hoặc proxy, kiểm tra status, origin connectivity, cache rule và recent change. Một 502/504 có thể xuất phát từ proxy hoặc upstream chứ không nhất thiết từ WordPress.

4. Hosting và web server

Kiểm tra node có online, web server có chạy, disk còn dung lượng, CPU/memory có saturation và error log có tăng bất thường không. Với shared hosting, status từ provider có thể là đầu vào nhưng vẫn cần xác minh site của mình.

5. Database

Website có thể down nếu database không kết nối, bị lock, quá tải hoặc disk đầy. Không nên tự repair database diện rộng trước khi có backup/snapshot và hiểu phạm vi lỗi.

6. Application

Kiểm tra PHP fatal, plugin/theme, deploy, config hoặc code custom. Nếu site vừa update WordPress/plugin/theme, xem quy trình xử lý WordPress lỗi sau cập nhật.

7. Dependency bên ngoài

API, payment, storage hoặc authentication provider có thể làm một phần website không hoạt động. API Monitoring giúp phân biệt application issue với dependency ngoài.

Website down khác lỗi 5xx thế nào?

“Down” là symptom người dùng nhìn thấy; lỗi 5xx là một nhóm tín hiệu HTTP cụ thể. Website có thể down vì DNS không resolve hoặc SSL invalid mà không hề trả 5xx. Nếu server vẫn phản hồi 500/502/503/504, xem quy trình xử lý lỗi 5xx.

Freeze change trước khi sửa

Nếu nhiều người đang deploy, update plugin hoặc đổi DNS cùng lúc, việc tiếp tục thay đổi sẽ làm incident khó điều tra. Tạm freeze change, ghi timestamp, người phụ trách và các thay đổi gần nhất.

Chọn recovery path nhỏ nhất có thể

• rollback một config nếu lỗi do config;
• rollback deploy nếu lỗi xuất hiện ngay sau release;
• restart service nếu có bằng chứng service bị treo;
• restore backup chỉ khi recovery point phù hợp và không làm mất dữ liệu mới;
• kích hoạt Disaster Recovery nếu production không còn đáng tin cậy hoặc hạ tầng chính không thể phục hồi trong ngưỡng.

Smoke test sau khi website online lại

Không dừng ở homepage. Kiểm tra:

• homepage và route quan trọng;
• admin/login;
• form;
• checkout nếu có;
• email;
• API/webhook;
• cron/background jobs;
• SSL/DNS từ bên ngoài;
• error rate và latency.

Khi nào cần coi đây là P1?

Thường là P1 khi toàn site mất truy cập, checkout ngừng hoàn toàn, nhiều người dùng bị ảnh hưởng hoặc không có workaround. Severity cần gắn với SLA vận hành website và business impact thực tế.

Những sai lầm dễ làm downtime kéo dài

• đổi DNS liên tục mà không ghi lại baseline;
• update thêm plugin trong lúc site đang down;
• xóa cache/log trước khi triage;
• restore backup cũ mà không bảo toàn dữ liệu mới;
• đổ lỗi ngay cho hosting mà chưa xác định layer;
• chỉ kiểm tra site từ mạng nội bộ;
• không monitor sau recovery.

Runbook 10 phút đầu

1. ghi thời điểm phát hiện;
2. test từ ngoài;
3. xác định scope;
4. freeze change;
5. check domain/DNS/SSL;
6. check origin/server;
7. check error log/recent deploy;
8. chọn rollback/recovery path;
9. smoke test;
10. monitor và cập nhật stakeholder.

Khi nào nên escalation?

Nếu không có quyền DNS/hosting, nghi ngờ compromise, không xác định được change gần nhất hoặc site đang gây thiệt hại kinh doanh đáng kể, escalation sớm sẽ tốt hơn thử ngẫu nhiên. Xem Website Incident Response để điều phối severity và recovery, hoặc dịch vụ sửa lỗi website khẩn cấp khi cần hỗ trợ trực tiếp.

FAQ

Website down có phải luôn do hosting?

Không. Domain, DNS, SSL, CDN, database, application hoặc dependency ngoài đều có thể gây mất truy cập.

Có nên restart server ngay?

Chỉ khi có bằng chứng phù hợp và biết rollback/impact. Restart có thể xóa trạng thái hữu ích cho điều tra hoặc không giải quyết root cause.

Website online lại là incident đã xong chưa?

Chưa. Cần smoke test, monitor ổn định và ghi nguyên nhân/action để tránh tái diễn.

Đọc tiếp trong cụm Website Incident Response

• Website Incident Response: framework chung về severity, containment, recovery và verify.
• Lỗi 500/502/503/504: triage server-side failure theo mã và upstream.
• WordPress lỗi sau cập nhật: rollback change gây lỗi có kiểm soát.
• WordPress Critical Error / White Screen: xử lý fatal error và Recovery Mode.
• Disaster Recovery: dùng khi recovery thông thường không còn đủ.

Kết luận

Website bị down cần được triage theo lớp thay vì “thử mọi cách”. Khi có baseline domain/DNS/SSL, monitoring, recent-change log và runbook rõ, đội vận hành có thể khoanh vùng nhanh hơn và phục hồi với ít rủi ro hơn.