Disaster Recovery Runbook cho website là tài liệu hướng dẫn từng bước để đội vận hành đưa website trở lại trạng thái sử dụng được sau một sự cố nghiêm trọng. Runbook không thay thế phán đoán kỹ thuật; nó giúp giảm quyết định ngẫu hứng bằng cách xác định trước ai làm gì, theo thứ tự nào, dùng recovery point nào, điều kiện go/no-go ra sao và khi nào cần rollback hoặc escalation.
Tóm tắt: Một runbook tốt phải đủ ngắn để dùng khi có áp lực, nhưng đủ cụ thể để người có quyền thực thi không phải đoán. Nó nên bao gồm trigger, owner, dependency, quyền truy cập, recovery point, các bước phục hồi, smoke test, chuyển traffic, monitoring, communication và post-incident review.
Disaster Recovery Runbook khác kế hoạch DR như thế nào?
Kế hoạch Disaster Recovery cho website xác định mục tiêu, chiến lược, RPO/RTO, dependency và nguyên tắc phục hồi. Runbook là phần thực thi: một chuỗi hành động có thứ tự để dùng khi DR được kích hoạt.
| DR Plan | DR Runbook |
|---|---|
| Giải thích mục tiêu và chiến lược | Hướng dẫn hành động cụ thể |
| Xác định RPO/RTO | Dùng RPO/RTO để chọn recovery point và ưu tiên |
| Mô tả dependency và vai trò | Chỉ rõ ai thực hiện từng bước |
| Được review theo chu kỳ | Được dùng trực tiếp trong test và sự cố thật |
| Trả lời “cần đạt điều gì?” | Trả lời “làm thế nào để đạt?” |
NIST SP 800-61 Rev.3 nhấn mạnh việc chuẩn bị, response, recovery và cải tiến liên tục trong quản lý incident. AWS Well-Architected cũng khuyến nghị dùng chính runbook trong các lần DR test để ghi lại vấn đề và sửa trước lần phục hồi tiếp theo.
Khi nào nên kích hoạt DR Runbook?
Không phải lỗi website nào cũng cần DR. Một lỗi giao diện hoặc plugin đơn lẻ có thể xử lý bằng rollback thông thường. Runbook DR phù hợp khi production không thể tiếp tục phục vụ an toàn hoặc con đường phục hồi thông thường không còn đủ.
- website hoặc hạ tầng chính mất khả dụng kéo dài;
- database corrupt, bị xóa hoặc sai lệch diện rộng;
- deploy/migration thất bại và rollback thông thường không khôi phục được;
- production bị compromise và không còn đáng tin cậy;
- hosting, storage, DNS hoặc dependency quan trọng gặp sự cố;
- cần khôi phục ở môi trường sạch hoặc hạ tầng thay thế;
- incident vượt ngưỡng thời gian hoặc mức ảnh hưởng đã định nghĩa.
Trigger phải đủ rõ để tránh hai cực: kích hoạt DR quá sớm cho lỗi nhỏ hoặc trì hoãn quá lâu khi website đã vượt RTO.
Runbook cần ghi những thông tin gì trước khi sự cố xảy ra?
1. Owner và quyền kích hoạt
Ghi rõ ai có quyền tuyên bố incident, ai kích hoạt DR, ai được thay DNS, ai được restore backup và ai phê duyệt go-live. Không nên để quyền quyết định nằm ngầm trong đầu một người.
2. Danh sách dependency
Runbook cần trỏ tới domain/registrar, DNS, hosting, database, storage, CDN, email, CRM, payment, API, secret, repository, backup repository và monitoring. Nếu một dependency không có owner hoặc đường vào rõ ràng, RTO trên giấy có thể không đạt.
3. Recovery point và tiêu chí chọn
Không ghi một file backup cố định trong runbook. Hãy ghi cách chọn: bản gần nhất thỏa RPO, đã qua integrity/restore test khi có thể và không nằm trong khoảng thời gian nghi ngờ bị compromise.
4. Kênh liên lạc dự phòng
Nếu email hoặc website chính nằm trong phạm vi incident, đội vận hành cần kênh khác để trao đổi: điện thoại, chat nội bộ hoặc danh sách liên hệ khẩn cấp đã được xác nhận.
5. Điều kiện go/no-go
Trước khi phục hồi, xác định điều kiện tối thiểu để chuyển traffic trở lại. Ví dụ: homepage, login, form/checkout, API quan trọng, DNS/SSL và monitoring phải đạt trạng thái chấp nhận được.
Disaster Recovery Runbook mẫu cho website
Bước 1: Xác nhận incident và phạm vi ảnh hưởng
Ghi thời điểm phát hiện, triệu chứng, hệ thống bị ảnh hưởng, mức độ business impact và người đang chỉ huy incident. Nếu đây là sự cố bảo mật, liên kết sang quy trình xử lý website bị hack để bảo toàn bằng chứng và cô lập phù hợp trước khi restore.
Bước 2: Freeze thay đổi
Tạm dừng deploy, update plugin/theme, chỉnh database, thay DNS không cần thiết và các change request khác. Mục tiêu là giữ trạng thái đủ ổn định để điều tra và phục hồi có kiểm soát.
Bước 3: Bảo toàn bằng chứng cần thiết
Nếu nghi ngờ compromise hoặc lỗi khó tái hiện, lưu log, timestamp, snapshot và các dấu vết cần thiết trước khi ghi đè hệ thống. Không để hành động recovery phá mất bằng chứng quan trọng cho root-cause analysis.
Bước 4: Chọn recovery strategy
Chọn một trong các đường phục hồi đã định nghĩa: rollback trên production, restore lên môi trường sạch, dựng lại ứng dụng, chuyển sang hạ tầng dự phòng hoặc kết hợp nhiều bước. Nên duy trì số lượng recovery path vừa đủ và thường xuyên kiểm thử thay vì có quá nhiều phương án chưa từng dùng.
Bước 5: Chọn recovery point
Đối chiếu thời gian backup với RPO, thời điểm incident bắt đầu và độ tin cậy của bản sao. Với backup chưa từng được kiểm chứng, xem quy trình restore test backup website để hiểu tiêu chí kiểm tra recovery point.
Bước 6: Dựng môi trường phục hồi
Nếu production bị nghi ngờ nhiễm malware, hỏng cấu hình hoặc dependency lỗi, ưu tiên môi trường tách biệt. Ghi rõ version PHP, database, web server, secret và service dependency cần để ứng dụng chạy.
Bước 7: Restore dữ liệu và ứng dụng
Khôi phục database, code, uploads, cấu hình, secret và integration theo đúng thứ tự. Nếu hệ thống có backup incremental/differential hoặc nhiều storage, runbook phải chỉ rõ chuỗi cần thiết.
Bước 8: Chạy smoke test
Không coi homepage tải được là recovery hoàn tất. Tùy website, smoke test nên gồm:
- homepage và landing page quan trọng;
- admin/login;
- form và dữ liệu lead;
- cart/checkout/order flow;
- email giao dịch;
- API/webhook;
- cron/background job;
- media/upload/download;
- redirect/canonical quan trọng nếu migration có liên quan;
- tracking cần thiết cho vận hành.
Bước 9: Quyết định go/no-go
Người được ủy quyền đối chiếu checklist. Nếu một chức năng critical vẫn lỗi, lựa chọn có thể là tiếp tục recovery, dùng workaround đã phê duyệt hoặc rollback về bước trước. Không nên chuyển traffic chỉ vì áp lực thời gian.
Bước 10: Chuyển traffic và xác nhận
Thực hiện DNS/load balancer/CDN switch theo runbook nếu cần. Sau đó kiểm tra từ bên ngoài, không chỉ từ mạng nội bộ hoặc phiên đăng nhập của kỹ thuật.
Bước 11: Monitoring sau recovery
Theo dõi availability, 5xx, latency, form/checkout, error log và các tín hiệu bảo mật. Website Monitoring nên được dùng để xác nhận trạng thái ổn định sau go-live thay vì chỉ dựa vào kiểm tra thủ công.
Bước 12: Kết thúc incident và review
Ghi RTO thực tế, recovery point đã dùng, dữ liệu mất thực tế, lỗi phát sinh, bước tốn thời gian nhất, quyền còn thiếu và hành động cải tiến. Những gì học được phải quay trở lại runbook.
Mẫu bảng trách nhiệm trong DR Runbook
| Hoạt động | Owner chính | Người phê duyệt | Bằng chứng cần lưu |
|---|---|---|---|
| Tuyên bố incident | Incident lead | Business/technical owner | Timestamp, impact |
| Freeze change | Technical lead | Incident lead | Danh sách change bị dừng |
| Chọn recovery point | Backup/ops owner | Technical lead | Backup ID, thời gian, integrity |
| Restore | Ops/engineer | Technical lead | Log restore, lỗi |
| Go-live | Technical lead | Business owner | Checklist pass |
| Close incident | Incident lead | Stakeholder phù hợp | RTO/RPO thực tế, action items |
Vai trò trên chỉ là mẫu. Website nhỏ có thể một người giữ nhiều vai trò, nhưng trách nhiệm vẫn phải được ghi rõ.
Điều kiện PASS trước khi mở lại website
- recovery point đã được xác nhận phù hợp;
- website trả nội dung bình thường từ bên ngoài;
- database và file ở trạng thái kỳ vọng;
- luồng business-critical đã qua smoke test;
- SSL/DNS hoạt động;
- email/payment/webhook đúng môi trường;
- không còn lỗi 5xx diện rộng;
- monitoring và alert đã hoạt động;
- nếu là security incident, quyền/credential bị ảnh hưởng đã được xử lý;
- có người chịu trách nhiệm theo dõi sau go-live.
Những lỗi thường làm DR Runbook thất bại
- runbook mô tả quá chung chung như “restore backup” nhưng không chỉ cách tìm backup;
- tài khoản cần thiết thuộc agency hoặc nhân sự cũ;
- không ghi secret hoặc dependency quan trọng;
- recovery path chưa từng được thử;
- runbook chứa screenshot/UI cũ nhưng không có nguyên tắc thay thế;
- không có tiêu chí go/no-go;
- không đo thời gian thực tế nên không biết có đạt RTO;
- không cập nhật runbook sau test hoặc incident;
- có quá nhiều recovery path nhưng đội vận hành không quen đường nào.
AWS Well-Architected khuyến nghị kiểm thử recovery path thường xuyên và dùng runbook trong chính lần test để ghi lại vấn đề. Runbook vì vậy nên được xem là tài liệu sống, không phải file PDF tạo một lần rồi cất đi.
Runbook nên được kiểm thử như thế nào?
Ít nhất cần có ba mức kiểm tra:
- Tabletop review: đội liên quan đọc kịch bản và xác nhận vai trò, quyền, dependency.
- Restore test: chứng minh recovery point và ứng dụng có thể khôi phục trên môi trường tách biệt.
- DR drill: chạy càng gần quy trình thật càng tốt, đo thời gian, communication, decision và khả năng đáp ứng RPO/RTO.
Không cần mọi lần test đều tác động production. Mức test phải phù hợp rủi ro và kiến trúc, nhưng con đường phục hồi quan trọng không nên chỉ tồn tại trên giấy.
Runbook có nên chứa mật khẩu và secret?
Không nên đặt secret dạng plaintext ngay trong tài liệu vận hành thông thường. Runbook nên ghi nơi lưu được phê duyệt, loại credential cần dùng, ai có quyền truy cập và thủ tục khẩn cấp nếu vault hoặc tài khoản chính không khả dụng.
Runbook nên được lưu ở đâu?
Không nên chỉ lưu bên trong chính website hoặc hệ thống có thể bị mất khi incident xảy ra. Cần có bản sao được kiểm soát ở nơi đội vận hành vẫn truy cập được khi production, hosting hoặc email gặp sự cố.
Checklist DR Runbook tối thiểu
- trigger kích hoạt;
- incident owner và người phê duyệt;
- kênh liên lạc;
- dependency và đường truy cập;
- RPO/RTO tham chiếu;
- cách chọn recovery point;
- recovery strategy;
- thứ tự restore;
- smoke test;
- go/no-go;
- chuyển traffic;
- monitoring;
- rollback/escalation;
- evidence cần lưu;
- post-incident review;
- ngày test gần nhất và owner cập nhật.
FAQ
Runbook có phải càng chi tiết càng tốt?
Không. Quá ngắn thì phải đoán; quá dài thì khó dùng khi có áp lực. Chi tiết nên tập trung vào quyết định, thứ tự, dependency, quyền truy cập và kiểm tra. Những hướng dẫn kỹ thuật dài có thể tách thành procedure rồi được runbook dẫn tới.
Website nhỏ có cần DR Runbook không?
Có thể dùng bản rất gọn. Chỉ cần biết ai chịu trách nhiệm, backup ở đâu, khôi phục ở đâu, kiểm tra gì và ai quyết định go-live đã tốt hơn một quy trình chỉ tồn tại trong trí nhớ.
Runbook khác checklist restore test thế nào?
Restore test tập trung chứng minh backup có thể khôi phục. DR Runbook rộng hơn: nó bao gồm trigger, coordination, quyền, recovery strategy, go-live, monitoring và close incident.
Bao lâu nên review runbook?
Nên review sau thay đổi lớn về hạ tầng, hosting, DNS, plugin/theme quan trọng, đội ngũ hoặc dependency; đồng thời cập nhật sau mỗi restore test, DR drill hoặc incident thật có bài học mới.
Kết luận
Disaster Recovery Runbook biến một chiến lược phục hồi thành hành động có thể thực thi. Giá trị của runbook không nằm ở số trang mà ở khả năng giúp đội vận hành phục hồi đúng thứ tự, đúng người, đúng recovery point và có tiêu chí rõ để biết khi nào website đủ an toàn để mở lại.
Trong mô hình quản trị và vận hành website, runbook nên được nối với backup, restore test, Website Monitoring và Incident Response, sau đó được cập nhật từ kết quả test thực tế.
Nguồn tham khảo: NIST SP 800-61 Rev.3 và AWS Well-Architected – Test disaster recovery implementation.
Đ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ả.
