Xử lý sự cố website bất động sản: Quy trình 15 phút và checklist khôi phục

Website bất động sản thường không chỉ là trang giới thiệu. Nó có thể đang nhận traffic quảng cáo, thu số điện thoại, đẩy lead sang CRM, hiển thị bảng giá hoặc giúp khách đặt lịch xem nhà.

Vì vậy một sự cố tưởng nhỏ như form không gửi hoặc nút Zalo bị che trên mobile có thể nghiêm trọng hơn một lỗi giao diện dễ nhìn thấy.

Khi website gặp sự cố, mục tiêu đầu tiên không phải là:

“Sửa mọi thứ ngay.”

Mà là:

Xác định mức độ ảnh hưởng → giữ kênh nhận lead → ngăn lỗi lan rộng → khôi phục dịch vụ → tìm nguyên nhân → phòng tái diễn.

Bài viết này Bdsweb xây dựng một quy trình xử lý sự cố dành riêng cho website bất động sản đang phục vụ SEO, quảng cáo và thu lead, bao gồm cả lỗi kỹ thuật, vận hành, form, CRM, mobile và SEO.

Nguyên tắc đầu tiên: xử lý theo tác động kinh doanh, không theo độ “đáng sợ” của lỗi

Ví dụ:

• Một icon bị lệch → ảnh hưởng thấp;
• Form báo thành công nhưng CRM không nhận → ảnh hưởng rất cao;
• Một bài blog bị lỗi ảnh → ảnh hưởng thấp;
• Landing đang chạy Ads trả lỗi 500 → ảnh hưởng rất cao.

Do đó nên phân loại sự cố trước khi bắt đầu xử lý.

1. Phân cấp sự cố P1 – P2 – P3

Mức	Ví dụ	Ưu tiên
P1 – Critical	Website down, form toàn hệ thống lỗi, domain/DNS bị can thiệp, nghi bị hack, database không truy cập	Xử lý ngay
P2 – High	Filter lỗi, CRM không nhận lead, landing rất chậm, template dự án lỗi diện rộng	Ưu tiên cao
P3 – Normal	Một ảnh lỗi, một URL 404 đơn lẻ, lỗi CSS nhỏ, text sai	Xử lý theo lịch

Mỗi doanh nghiệp nên tự định nghĩa SLA phản hồi cho từng mức thay vì coi mọi ticket đều khẩn cấp như nhau.

2. Checklist 15 phút đầu: đừng sửa vội

Phút 0–2: xác nhận sự cố

• URL nào lỗi?
• Desktop hay mobile?
• Wi-Fi và 4G có cùng lỗi?
• Một người hay tất cả người dùng?
• Một trang hay toàn website?

Phút 2–5: xác định tác động tới lead

Kiểm tra ngay:

• Form;
• Gọi điện;
• Zalo;
• CTA;
• Landing quảng cáo;
• CRM;
• Email nhận lead.

Nếu conversion path bị lỗi, hãy ưu tiên tạo đường dự phòng.

Phút 5–10: containment

Mục tiêu là ngăn lỗi lan rộng.

Có thể:

• Tạm dừng deployment;
• Tắt module vừa cập nhật;
• Chuyển form sang kênh dự phòng;
• Tắt popup gây lỗi;
• Đưa website về maintenance có kiểm soát nếu cần;
• Chặn account/API đáng ngờ khi có dấu hiệu bảo mật.

Phút 10–15: chọn rollback hay fix-forward

Nếu nguyên nhân gắn trực tiếp với một thay đổi vừa triển khai và có bản backup/release ổn định, rollback thường là lựa chọn đáng cân nhắc.

Nếu lỗi nhỏ, nguyên nhân rõ và sửa nhanh ít rủi ro, có thể fix-forward.

Đừng vừa sửa nhiều file, vừa update plugin, vừa thay DNS khi chưa biết nguyên nhân.

3. Luôn “freeze change” khi đang xử lý P1

Khi xảy ra sự cố nghiêm trọng, tránh để nhiều người cùng thay đổi:

• Code;
• Plugin;
• DNS;
• Hosting;
• Database;
• Cache.

Nếu ba người cùng “thử sửa” một lúc, rất khó xác định thay đổi nào giúp hoặc làm lỗi nặng hơn.

Nên có một người giữ vai trò:

Incident Owner.

Người này không nhất thiết phải tự sửa kỹ thuật, nhưng chịu trách nhiệm:

• Điều phối;
• Ghi nhận thay đổi;
• Cập nhật trạng thái;
• Quyết định escalation.

4. Ghi lại bằng chứng trước khi thay đổi hệ thống

Trước khi xóa cache hoặc restart server, hãy lưu:

• Thời điểm xảy ra;
• URL;
• HTTP status;
• Ảnh/video lỗi;
• Error message;
• Browser/device;
• Log;
• Thay đổi gần nhất;
• Traffic tại thời điểm đó.

Đặc biệt với nghi vấn bảo mật, đừng xóa log hoặc “dọn sạch” hệ thống quá sớm vì có thể làm mất dấu vết cần điều tra.

5. Sự cố website không truy cập được

Dấu hiệu

• Connection timed out;
• Connection refused;
• 502/503/504;
• Trắng trang;
• Không truy cập được toàn domain.

Kiểm tra theo thứ tự

1. Domain/DNS có resolve đúng không?
2. Hosting/server có hoạt động không?
3. Disk có đầy không?
4. CPU/RAM có chạm giới hạn không?
5. Web server/PHP/database có hoạt động không?
6. Có deployment gần đây không?
7. Có traffic/bot bất thường không?

Phương án tạm thời

Nếu landing Ads bị down và chưa thể phục hồi ngay:

• Cân nhắc tạm dừng traffic trả phí;
• Chuyển Ads sang landing dự phòng nếu có;
• Giữ hotline/Zalo trên kênh khác;
• Thông báo sales về sự cố.

6. Lỗi HTTP 500: đừng sửa bằng cách đoán

HTTP 500 chỉ cho biết server gặp lỗi nội bộ. Nó không nói nguyên nhân cụ thể.

Cần kiểm tra:

• Error log;
• PHP log;
• Deployment gần nhất;
• Plugin/theme vừa update;
• Database;
• Permission;
• Memory/resource limit.

Nếu lỗi xuất hiện ngay sau một release:

Release A ổn → Release B lỗi

thì rollback B thường an toàn hơn việc sửa trực tiếp production trong trạng thái khẩn cấp.

7. Lỗi 502, 503 và 504 không giống nhau

502 – Bad Gateway

Thường cần kiểm tra giao tiếp giữa proxy/web server và upstream như PHP-FPM hoặc application server.

503 – Service Unavailable

Có thể liên quan:

• Server quá tải;
• Maintenance;
• Service không sẵn sàng;
• Giới hạn hosting.

504 – Gateway Timeout

Thường cho thấy upstream xử lý quá lâu.

Kiểm tra:

• Database query;
• External API;
• PHP process;
• Traffic peak;
• Deadlock/timeout.

Không nên tăng timeout vô hạn mà chưa tìm tác vụ nào đang xử lý quá lâu.

8. Database lỗi hoặc kết nối database thất bại

Dấu hiệu có thể gồm:

• “Error establishing database connection”;
• Website lúc được lúc không;
• Admin rất chậm;
• Query timeout.

Kiểm tra:

• Database service;
• Credential;
• Connection limit;
• Disk;
• Slow query;
• CPU/RAM;
• Thay đổi cấu hình gần đây.

Không nên chạy repair database hoặc xóa table trên production khi chưa có backup.

9. Form không nhận lead: sự cố nguy hiểm vì rất khó nhìn thấy

Website vẫn có thể trông hoàn toàn bình thường.

Khách vẫn bấm:

Gửi yêu cầu.

Nhưng phía sales không nhận được gì.

Đây là một trong những sự cố Bdsweb ưu tiên cao nhất.

Test toàn bộ flow

Không chỉ kiểm tra nút submit.

Cần kiểm tra:

Form
→ Validation
→ Server
→ Database
→ Email
→ CRM
→ Tracking
→ Success State

Các tình huống phổ biến

• Form submit lỗi;
• Form báo success nhưng backend lỗi;
• Database có lead nhưng email không tới;
• Email tới nhưng CRM không tạo lead;
• CRM có lead nhưng thiếu project/UTM;
• Tracking ghi conversion nhưng lead thực tế không tồn tại.

10. Khi form lỗi, ưu tiên tạo fallback ngay

Nếu đang chạy Ads, có thể tạm thời:

• Hiển thị hotline rõ hơn;
• Đưa Zalo lên CTA chính;
• Dùng form dự phòng;
• Chuyển lead sang email/database nếu CRM đang lỗi;
• Tạm dừng chiến dịch nếu không còn đường conversion an toàn.

Sau khi ổn định, mới xử lý nguyên nhân gốc.

Kiến trúc form tốt nên có nhiều lớp hơn một email notification đơn lẻ. Xem thêm hệ thống form và thu lead cho website BĐS.

11. CRM không nhận lead nhưng website vẫn báo thành công

Đây là tình huống cần đặc biệt lưu ý với hệ thống tích hợp.

Luồng lý tưởng không nên là:

CRM lỗi
→ mất lead

Nên có cơ chế:

Website
→ lưu lead nội bộ/queue
→ gọi CRM
→ nếu lỗi: log + retry + cảnh báo

Nhờ vậy outage của CRM không nhất thiết làm mất dữ liệu khách.

Với hệ thống có volume lead đáng kể, nên xây quy trình theo hướng website → chống spam → CRM → routing → sales thay vì phụ thuộc một request duy nhất.

12. Sau khi sửa form, phải kiểm tra lead bị rơi trong thời gian sự cố

Đây là bước thường bị bỏ qua.

Giả sử sự cố kéo dài từ:

10:15 → 11:40

Sau khi sửa xong, hãy đối chiếu:

• Server log;
• Form database;
• Email;
• CRM;
• Analytics;
• Ads conversions.

Mục tiêu là xác định:

• Có bao nhiêu submit?
• Bao nhiêu lead thực sự được lưu?
• Lead nào chưa sang CRM?
• Có thể phục hồi và giao lại cho sales không?

Khôi phục website chưa đồng nghĩa khôi phục dữ liệu kinh doanh.

13. Spam lead tăng đột biến

Dấu hiệu:

• Form submit tăng bất thường;
• SĐT/email vô nghĩa;
• Cùng payload lặp lại;
• Request tần suất cao;
• Sales phản ánh lead rác tăng mạnh.

Containment

• Rate limit;
• Honeypot;
• CAPTCHA/challenge khi cần;
• Chặn pattern rõ ràng;
• WAF rule;
• Temporary IP/network blocking khi có bằng chứng.

Không nên khóa form quá chặt chỉ để ngăn spam vì có thể đồng thời chặn khách thật.

Phần triển khai chuyên biệt có thể xem tại cách chống spam form website BĐS.

14. Website chậm đột ngột

Đừng bắt đầu bằng “nâng hosting”.

Hãy hỏi:

• Chậm từ khi nào?
• Tất cả URL hay một template?
• Backend hay frontend?
• Có deploy gần đây?
• Có traffic spike?
• Có bot?
• Có external API chậm?

Kiểm tra server

• CPU;
• RAM;
• Disk;
• PHP worker;
• Database;
• Cache hit;
• Network.

Kiểm tra frontend

• Ảnh mới upload;
• Video;
• Map;
• JavaScript;
• Chatbot;
• Tag mới;
• Popup;
• Slider.

Nếu vấn đề không phải outage mà là performance degradation, dùng quy trình tăng tốc website BĐS để tìm bottleneck thay vì xử lý ngẫu nhiên.

15. Website chậm chỉ vào giờ cao điểm

Đây thường là dấu hiệu cần xem:

• Concurrency;
• PHP worker;
• Database connection;
• Cache;
• Traffic bot;
• Server resource.

Website chạy tốt lúc 3 giờ sáng không chứng minh rằng hạ tầng đủ cho chiến dịch mở bán lúc 9 giờ.

Nên so sánh metric giữa:

Thời điểm bình thường vs thời điểm chậm.

16. SSL hết hạn hoặc HTTPS lỗi

Kiểm tra:

• Certificate còn hạn?
• Domain đúng?
• Certificate chain?
• Auto-renew hoạt động?
• DNS vừa thay đổi?
• HTTP → HTTPS redirect?
• Có redirect loop?
• Có mixed content?

Sau khi sửa, test:

• Homepage;
• Trang dự án;
• Form;
• Subdomain;
• API endpoint liên quan.

17. DNS hoặc domain gặp sự cố

Dấu hiệu:

• Domain không resolve;
• Một số mạng truy cập được, mạng khác không;
• Email cũng lỗi;
• Website trỏ nhầm server.

Kiểm tra:

• Nameserver;
• A/AAAA;
• CNAME;
• DNS provider;
• Domain expiration;
• Recent DNS changes.

Nếu nghi tài khoản registrar bị xâm nhập, đây là P1 bảo mật chứ không còn là lỗi cấu hình thông thường.

18. Hình ảnh không hiển thị

Khoanh vùng:

• Một ảnh hay toàn bộ uploads?
• Original file còn không?
• URL trả 404, 403 hay 5xx?
• CDN có lỗi không?
• Permission?
• Hotlink/security rule?
• Migration vừa xảy ra?

Không nên “regenerate toàn bộ thumbnail” ngay nếu chưa biết lỗi nằm ở media URL, CDN hay file system.

19. Gallery hoặc mặt bằng bị lỗi sau cập nhật

Kiểm tra:

• JavaScript console;
• Plugin/gallery version;
• Theme;
• Cache;
• Lazy-loading;
• Lightbox;
• Recent deployment.

Nếu module này nằm dưới trang nhưng Hero/CTA vẫn hoạt động, có thể xử lý theo P2 thay vì làm toàn website offline.

20. Giao diện mobile bị vỡ

Dấu hiệu:

• Horizontal scroll;
• Popup không đóng;
• CTA che form;
• Menu không mở;
• Filter không scroll;
• Button không bấm được.

Containment nhanh:

• Tắt popup lỗi;
• Tắt sticky element gây che;
• Ẩn module mới gây lỗi;
• Khôi phục CSS/release trước nếu cần.

Sau đó kiểm tra ở nhiều viewport thay vì chỉ thiết bị của developer.

Các lỗi màn hình nhỏ nên được phòng ngừa qua quy trình tối ưu website BĐS trên mobile.

21. Một URL dự án trả 404

Đầu tiên cần xác định URL đó:

• Đã bị xóa có chủ đích?
• Đổi URL?
• CMS mất record?
• Permalink lỗi?
• Routing lỗi?

Nếu có URL thay thế tương đương

Có thể dùng redirect vĩnh viễn phù hợp.

Nếu nội dung thực sự không còn và không có thay thế

Trả trạng thái 404/410 phù hợp thường tốt hơn redirect mọi URL lỗi về homepage.

22. 404 tăng hàng loạt sau migration

Đây không còn là lỗi từng page.

Kiểm tra:

• Redirect map;
• Slug;
• Category structure;
• Trailing slash;
• HTTP/HTTPS;
• www/non-www;
• Internal link;
• Sitemap.

Lấy một mẫu URL theo từng pattern thay vì sửa từng URL thủ công.

23. Website hoặc trang quan trọng biến mất khỏi Google

Đừng kết luận ngay rằng website “bị Google phạt”.

Kiểm tra theo thứ tự:

1. URL còn trả 200 không?
2. Có noindex không?
3. Robots.txt có chặn không?
4. Canonical trỏ đâu?
5. URL có trong sitemap không?
6. Internal link còn không?
7. Google có crawl được không?
8. Search Console báo trạng thái gì?

Google phân biệt rõ crawling và indexing. Vì vậy “không thấy trên Google” không phải lúc nào cũng được xử lý bằng submit sitemap lại nhiều lần.

24. Noindex nhầm toàn site sau khi chuyển từ staging

Đây là lỗi có thể xảy ra sau launch.

Kiểm tra:

hoặc header:

X-Robots-Tag: noindex

Sau khi gỡ, cần đảm bảo crawler có thể truy cập URL để đọc trạng thái mới.

Không nên vừa chặn URL bằng robots.txt vừa kỳ vọng công cụ tìm kiếm đọc được thẻ noindex trên chính trang bị chặn.

25. Sitemap lỗi không đồng nghĩa toàn bộ SEO mất ngay

Sitemap hỗ trợ discovery nhưng không phải đường duy nhất công cụ tìm kiếm tìm thấy URL.

Khi sitemap lỗi:

• Sửa file;
• Kiểm tra status;
• Kiểm tra URL bên trong;
• Kiểm tra lastmod nếu sử dụng;
• Submit lại khi cần.

Đừng thay đổi toàn bộ URL website chỉ vì sitemap tạm thời gặp lỗi.

26. Website bị hack hoặc nghi bị can thiệp

Dấu hiệu:

• Xuất hiện admin lạ;
• Redirect sang website khác;
• Trang spam;
• File lạ;
• Google cảnh báo Security Issue;
• Traffic bất thường;
• Credential/API bị sử dụng lạ.

Ưu tiên

Contain trước – điều tra sau.

Có thể cần:

• Hạn chế quyền truy cập;
• Vô hiệu credential đáng ngờ;
• Đưa hệ thống bị ảnh hưởng ra khỏi luồng;
• Lưu log/bằng chứng;
• Xác định phạm vi ảnh hưởng;
• Khôi phục từ nguồn tin cậy.

Không nên chỉ xóa file malware nhìn thấy rồi tuyên bố hệ thống đã sạch.

27. Nếu nghi lộ tài khoản, đổi mật khẩu thôi chưa chắc đủ

Cần xem xét:

• Session/token còn hoạt động;
• API key;
• FTP/SFTP;
• SSH;
• Database credential;
• Hosting;
• Registrar;
• Email quản trị;
• CRM.

Tùy phạm vi, có thể phải rotate nhiều credential chứ không chỉ mật khẩu WordPress.

28. Website bị traffic bot hoặc DDoS

Dấu hiệu:

• Traffic tăng rất mạnh;
• CPU/bandwidth tăng;
• Nhiều request giống nhau;
• Server bắt đầu 503/504.

Giải pháp có thể gồm:

• CDN/WAF;
• Rate limit;
• Challenge;
• Block pattern;
• Cache;
• Scale tạm thời.

Không nên block cả một quốc gia hoặc dải IP lớn nếu chưa hiểu tác động tới khách thật và crawler hợp lệ.

29. Sau cập nhật WordPress/plugin/theme, website lỗi

Quy trình:

1. Dừng thêm update;
2. Ghi lại phiên bản vừa thay;
3. Kiểm tra log;
4. Xác định phạm vi lỗi;
5. Rollback nếu ảnh hưởng lớn;
6. Dựng lại trên staging;
7. Tìm conflict;
8. Chỉ deploy lại sau khi test.

Không nên update thêm năm plugin khác với hy vọng chúng “tự hết lỗi”.

30. Khi nào nên rollback?

Rollback thường phù hợp khi:

• Lỗi xuất hiện ngay sau deployment;
• Release trước đã ổn định;
• Ảnh hưởng lớn;
• Cần khôi phục nhanh;
• Backup/release artifact đáng tin.

31. Khi nào không nên rollback mù?

Cần cẩn trọng nếu:

• Database đã có lead mới;
• Schema đã migration;
• Khách đã tạo dữ liệu;
• Backup cũ;
• Không biết backup có sạch hay không;
• Sự cố là security compromise.

Restore database về sáng hôm trước có thể làm mất toàn bộ lead của ngày hiện tại.

32. Rollback code và restore database là hai quyết định khác nhau

Ví dụ:

Code lỗi sau deploy lúc 14:00.

Nếu database vẫn bình thường, có thể chỉ cần rollback code.

Không nhất thiết phải restore database về bản 08:00.

Phân biệt hai phần này giúp giảm nguy cơ mất dữ liệu.

33. Backup phải gắn với RPO và RTO

Hai khái niệm hữu ích:

RPO – Recovery Point Objective

Doanh nghiệp chấp nhận mất tối đa bao nhiêu dữ liệu?

Ví dụ:

Nếu chấp nhận mất tối đa 1 giờ dữ liệu, backup database mỗi 24 giờ là chưa phù hợp.

RTO – Recovery Time Objective

Doanh nghiệp chấp nhận website ngừng hoạt động bao lâu?

Một landing đang chạy ngân sách quảng cáo lớn có RTO khác một blog ít traffic.

34. Backup tốt phải khôi phục được

Cần có:

• File;
• Database;
• Media;
• Cấu hình cần thiết;
• Bản sao ngoài production;
• Retention;
• Quy trình restore.

Quan trọng nhất:

Test restore định kỳ.

Một file backup chưa từng thử phục hồi chưa phải là kế hoạch disaster recovery đáng tin cậy.

35. Cache lỗi sau khi cập nhật

Dấu hiệu:

• Admin thấy nội dung mới nhưng người dùng thấy cũ;
• CSS cũ;
• Trang này đúng, trang khác sai;
• CDN và origin trả nội dung khác nhau.

Khoanh vùng:

• Browser cache;
• Page cache;
• Object cache;
• CDN;
• Service worker nếu có.

Không nên purge toàn bộ mọi lớp liên tục nếu hệ thống lớn; cần biết lớp nào đang chứa phiên bản cũ.

36. Giá hoặc trạng thái dự án hiển thị dữ liệu cũ

Đây là lỗi đặc thù BĐS cần ưu tiên vì ảnh hưởng niềm tin khách hàng.

Kiểm tra:

• CMS đã cập nhật chưa?
• Cache?
• API?
• CRM/source data?
• Scheduled sync?
• Timezone?

Nếu không thể sửa ngay, nên cân nhắc tạm ẩn dữ liệu không đáng tin thay vì tiếp tục hiển thị thông tin sai.

37. API bên thứ ba gặp sự cố

Website có thể phụ thuộc:

• CRM;
• Maps;
• Chat;
• Email;
• SMS/OTP;
• Payment/booking;
• Listing feed.

Cần thiết kế fallback.

Ví dụ:

CRM down
→ vẫn lưu lead
→ queue retry

hoặc:

Maps API down
→ vẫn hiển thị địa chỉ text

Một dependency bên ngoài không nên khiến toàn bộ trang dự án không render được nếu có thể tránh.

38. Monitoring nên theo dõi nhiều hơn uptime

Website trả HTTP 200 chưa chắc hoạt động đúng.

Nên theo dõi:

• Uptime;
• Response time;
• 5xx;
• Disk;
• CPU/RAM;
• Database;
• SSL expiration;
• Form success;
• CRM failure;
• Spam spike;
• Traffic anomaly.

Đặc biệt, một synthetic test gửi form định kỳ có thể phát hiện lỗi conversion mà uptime monitor không nhìn thấy.

39. Cảnh báo phải tới đúng người

Một hệ thống alert gửi 100 email/ngày thường bị bỏ qua.

Nên định tuyến:

• Infrastructure → kỹ thuật;
• Form/CRM → kỹ thuật + sales ops;
• SEO index → SEO;
• Security → người phụ trách bảo mật;
• Domain/SSL → quản trị hệ thống.

Cảnh báo tốt cần đủ thông tin để người nhận biết phải làm gì tiếp.

40. Có nên tạm dừng quảng cáo khi website lỗi?

Cân nhắc tạm dừng hoặc chuyển destination nếu:

• Landing down;
• Form chính lỗi;
• Trang quá chậm tới mức khó sử dụng;
• Website có cảnh báo bảo mật;
• Thông tin chiến dịch đang sai nghiêm trọng.

Nếu vẫn còn conversion fallback hoạt động tốt, có thể không cần dừng toàn bộ.

Quyết định nên dựa trên:

Khách còn hoàn thành mục tiêu được hay không?

41. Sau khi khôi phục, đừng đóng incident ngay

Khi website hoạt động trở lại, cần thêm một bước:

Post-Incident Review.

Tối thiểu trả lời:

• Chuyện gì xảy ra?
• Bắt đầu lúc nào?
• Phát hiện bằng cách nào?
• Ảnh hưởng gì?
• Nguyên nhân gốc là gì?
• Vì sao monitoring không phát hiện sớm hơn?
• Lead/data nào bị ảnh hưởng?
• Đã khôi phục thế nào?
• Làm gì để không tái diễn?

42. Phân biệt root cause và trigger

Ví dụ:

Trigger: update plugin.

Root cause: production không có staging và không kiểm tra compatibility.

Hoặc:

Trigger: traffic tăng.

Root cause: thiếu cache và PHP worker không đủ.

Nếu chỉ sửa trigger, sự cố tương tự có thể tái diễn.

43. Sau sự cố form, cần cập nhật quy trình chứ không chỉ sửa code

Ví dụ hành động phòng ngừa:

• Form lưu database;
• Alert nếu success giảm về 0;
• Test form tự động;
• Retry CRM;
• Fallback email;
• Checklist trước mỗi campaign.

Mục tiêu là biến một sự cố thành cải tiến hệ thống.

44. Sau sự cố update, hãy xây release checklist

Ví dụ:

• [ ] Backup;
• [ ] Staging test;
• [ ] Ghi phiên bản;
• [ ] Deploy;
• [ ] Purge cache phù hợp;
• [ ] Smoke test;
• [ ] Form test;
• [ ] Mobile test;
• [ ] Monitoring sau release.

45. Sau sự cố bảo mật, cần rà lại phạm vi ảnh hưởng

Đừng chỉ hỏi:

“Website đã sạch chưa?”

Cần hỏi:

• Credential nào có thể đã lộ?
• Dữ liệu nào có thể bị truy cập?
• Account nào được tạo?
• Có persistence/backdoor không?
• API key có bị dùng?
• Log còn đủ không?
• Có cần thông báo nội bộ/đối tác/người dùng theo nghĩa vụ áp dụng không?

Với security incident lớn, nên có chuyên gia phù hợp thay vì tự xử lý chỉ bằng plugin scan malware.

46. Incident log mẫu cho website BĐS

Trường	Nội dung
Incident ID	INC-...
Bắt đầu	Thời gian phát hiện/ước tính
Mức độ	P1 / P2 / P3
URL/System	Trang hoặc dịch vụ bị ảnh hưởng
Tác động	Traffic/lead/data
Thay đổi gần nhất	Deploy/update/config
Containment	Đã làm gì để giảm ảnh hưởng
Recovery	Cách khôi phục
Root Cause	Nguyên nhân gốc
Preventive Action	Việc phòng tái diễn

47. Checklist xử lý P1 cho website đang chạy Ads

• [ ] Xác nhận sự cố;
• [ ] Chỉ định Incident Owner;
• [ ] Freeze change;
• [ ] Test conversion path;
• [ ] Bật kênh lead dự phòng;
• [ ] Cân nhắc pause/chuyển Ads;
• [ ] Lưu log/bằng chứng;
• [ ] Khoanh vùng component;
• [ ] Quyết định rollback/fix-forward;
• [ ] Khôi phục;
• [ ] Test form thật;
• [ ] Kiểm tra CRM;
• [ ] Kiểm tra lead rơi;
• [ ] Theo dõi sau recovery;
• [ ] Postmortem.

48. Checklist phòng sự cố trước chiến dịch mở bán

Hạ tầng

• [ ] Uptime monitoring;
• [ ] Resource monitoring;
• [ ] SSL;
• [ ] Backup;
• [ ] Restore plan;
• [ ] Capacity đủ cho traffic dự kiến.

Lead

• [ ] Form test;
• [ ] Database lưu lead;
• [ ] Email;
• [ ] CRM;
• [ ] Retry/fallback;
• [ ] UTM/context.

Marketing

• [ ] Landing đúng URL;
• [ ] CTA hoạt động;
• [ ] Tracking;
• [ ] Conversion event;
• [ ] Có người biết cách pause Ads.

Kỹ thuật

• [ ] Không deploy lớn ngay trước chiến dịch;
• [ ] Staging đã test;
• [ ] Rollback plan;
• [ ] Contact hosting/dev có sẵn.

49. Những sai lầm thường gặp khi xử lý sự cố

• Sửa trước rồi mới xem log;
• Nhiều người cùng thay production;
• Restart mọi thứ mà chưa lưu bằng chứng;
• Restore toàn database khi chỉ code bị lỗi;
• Xóa cache như giải pháp cho mọi sự cố;
• Nâng hosting khi chưa biết bottleneck;
• Chỉ kiểm tra homepage;
• Form báo success là coi như xong;
• Không đối chiếu lead bị mất;
• Không có fallback;
• Không kiểm tra mobile;
• Không lưu timeline;
• Khôi phục xong nhưng không làm postmortem.

50. Câu hỏi thường gặp

Website down thì việc đầu tiên nên làm gì?

Xác nhận phạm vi lỗi và tác động trước. Nếu website đang tạo lead, kiểm tra conversion path và kích hoạt kênh dự phòng, sau đó mới khoanh vùng DNS, hosting, application hoặc database.

Có nên restore backup ngay khi website lỗi?

Không phải lúc nào cũng nên. Nếu chỉ một file code lỗi, restore toàn database có thể làm mất lead mới. Hãy xác định chính xác phần cần rollback và chất lượng bản backup trước khi khôi phục.

Form gửi thành công nhưng không nhận email thì lead có mất không?

Phụ thuộc kiến trúc. Nếu form có lưu database hoặc queue thì lead có thể vẫn còn. Nếu hệ thống chỉ gửi email trực tiếp và không lưu dữ liệu, rủi ro mất lead cao hơn.

Website không xuất hiện trên Google có phải bị phạt?

Không thể kết luận như vậy. Cần kiểm tra HTTP status, khả năng crawl, noindex, robots.txt, canonical, sitemap, internal link và trạng thái trong Search Console trước.

Có nên chặn toàn bộ bot khi server bị quá tải?

Không nên làm máy móc. Cần xác định traffic nào bất thường để tránh vô tình chặn người dùng hoặc crawler hợp lệ.

Có nên cập nhật plugin ngay trên production?

Website nhỏ có thể chấp nhận quy trình đơn giản hơn, nhưng website đang tạo lead nên có backup và ưu tiên test thay đổi đáng kể trên staging trước khi production.

Backup mỗi ngày đã đủ chưa?

Phụ thuộc RPO. Nếu website nhận lead liên tục và doanh nghiệp không chấp nhận mất một ngày dữ liệu, backup database mỗi ngày có thể chưa đủ.

Khi nào cần chuyên gia bảo mật?

Khi nghi có xâm nhập, lộ dữ liệu, backdoor, credential bị đánh cắp hoặc phạm vi ảnh hưởng chưa rõ, nên có người có chuyên môn security/forensics phù hợp thay vì chỉ xóa các file nhìn thấy.

Kết luận

Xử lý sự cố website bất động sản không nên là quá trình:

thấy lỗi → thử vài cách → hy vọng website hoạt động lại.

Một quy trình tốt cần đi theo:

Detect → Triage → Protect Lead → Contain → Diagnose → Recover → Validate → Reconcile Data → Learn.

Đối với web BĐS, có hai thứ cần bảo vệ song song:

• Dịch vụ: website, landing, form, CRM phải hoạt động;
• Dữ liệu kinh doanh: lead, nguồn traffic và lịch sử khách không bị thất lạc.

Vì vậy sau mỗi sự cố, đừng chỉ hỏi “website đã lên chưa?”. Hãy hỏi thêm:

Lead có bị rơi không? Dữ liệu có đúng không? Nguyên nhân gốc đã được xử lý chưa? Lần sau hệ thống có phát hiện sớm hơn không?

Để giảm số sự cố phải xử lý, nên kết hợp runbook này với hệ thống bảo mật và hiệu năng website BĐS, monitoring, backup ngoài production và quy trình release có staging trước khi thay đổi hệ thống đang tạo lead.