DR Drill cho website là buổi diễn tập Disaster Recovery nhằm kiểm tra không chỉ backup có restore được hay không, mà cả con người, quyền truy cập, dependency, quyết định, communication, runbook và thời gian phục hồi thực tế. Đây là cách biến một kế hoạch DR trên giấy thành năng lực có thể kiểm chứng.
Tóm tắt: Restore test chứng minh recovery point; DR Drill chứng minh cả hệ thống phục hồi. Một buổi drill nên có kịch bản, scope, observer, timer, tiêu chí pass/fail, log sự kiện, go/no-go và action items sau buổi diễn tập.
DR Drill khác restore test như thế nào?
Restore test tập trung vào backup và ứng dụng. DR Drill dùng Disaster Recovery Runbook để mô phỏng toàn bộ quá trình từ phát hiện incident đến recovery, go-live và monitoring sau phục hồi.
| Restore Test | DR Drill |
|---|---|
| Kiểm tra recovery point | Kiểm tra toàn bộ recovery capability |
| Chủ yếu kỹ thuật | Kỹ thuật + coordination + decision |
| Có thể làm trên staging | Mô phỏng incident và runbook |
| Đo restore duration | Đo end-to-end recovery time |
| Phát hiện lỗi backup | Phát hiện lỗi con người, quyền và dependency |
Khi nào nên tổ chức DR Drill?
- sau khi xây DR plan/runbook mới;
- sau migration hoặc thay hạ tầng quan trọng;
- sau thay đổi lớn về hosting, DNS, payment, CRM hoặc backup;
- khi đội vận hành thay người/agency;
- sau một incident thật có bài học quan trọng;
- theo chu kỳ phù hợp với mức độ critical của website.
Cách chọn kịch bản drill
Kịch bản nên đủ thực tế để kiểm tra dependency, không cần quá kịch tính. Ví dụ:
- database production bị corrupt;
- hosting chính không thể truy cập;
- website bị compromise và cần dựng môi trường sạch;
- deploy lỗi làm checkout không hoạt động;
- DNS account bị khóa;
- backup gần nhất không dùng được, phải chọn recovery point cũ hơn.
Không nên test mọi failure mode trong một buổi. Chọn một kịch bản chính để có kết quả đo được.
Chuẩn bị trước DR Drill
- xác định scope và hệ thống không được phép tác động;
- chọn incident scenario;
- chỉ định incident lead, operator và observer;
- chốt kênh communication;
- snapshot/backup trước drill nếu có thao tác rủi ro;
- chuẩn bị timer và event log;
- định nghĩa pass/fail và điều kiện dừng;
- xác định dữ liệu test, payment/email/webhook an toàn.
Chạy DR Drill từng bước
Bước 1: Bắt đầu kịch bản
Observer công bố triệu chứng, không nhất thiết đưa luôn root cause. Đội vận hành phải dùng monitoring và thông tin sẵn có để xác định impact.
Bước 2: Tuyên bố incident và kích hoạt runbook
Ghi thời điểm chính thức bắt đầu. Đây là mốc quan trọng khi so với RPO/RTO.
Bước 3: Kiểm tra quyền và dependency
Đội vận hành phải truy cập đúng registrar, DNS, hosting, backup, repository, secret và monitoring theo runbook. Nếu phải nhắn một người không có trong tài liệu để xin mật khẩu, đó là finding.
Bước 4: Chọn recovery point
Không cung cấp sẵn đáp án. Người thực thi phải dùng RPO, timeline incident và retention để chọn bản phù hợp. Với hệ thống có offsite/immutable backup, drill nên kiểm tra đường truy cập lớp này ít nhất định kỳ.
Bước 5: Restore và smoke test
Khôi phục theo runbook rồi test homepage, login, form/checkout, email, API, cron, media và luồng business-critical.
Bước 6: Quyết định go/no-go
Đội phải chứng minh vì sao website đủ điều kiện mở lại. Nếu có lỗi critical, runbook cần cho biết continue, workaround, rollback hay escalation.
Bước 7: Monitoring sau recovery
Sau khi giả lập go-live, dùng Website Monitoring để xác nhận availability, error, form/checkout và các tín hiệu cần thiết.
Bước 8: Kết thúc drill
Dừng timer khi đạt trạng thái usable theo tiêu chí đã định. Ghi recovery duration, recovery point, blocker và mọi deviation khỏi runbook.
DR Drill cần đo những gì?
| Metric | Mục đích |
|---|---|
| Time to declare | Đo tốc độ nhận diện và quyết định |
| Time to access recovery assets | Phát hiện blocker về quyền |
| Restore duration | Đo thời gian kỹ thuật |
| Time to usable | So với RTO |
| Data gap | So với RPO |
| Runbook deviation | Phát hiện tài liệu thiếu/cũ |
| Failed test cases | Xác định luồng chưa phục hồi |
DR Drill không nên biến thành “bài thi cá nhân”
Mục tiêu của drill là tìm điểm yếu hệ thống, không phải đổ lỗi cho người thao tác. Nếu operator phải đoán vì tài liệu thiếu, finding thuộc về quy trình. Cách review này giúp đội vận hành báo lỗi thật thay vì cố “diễn cho pass”.
Tabletop, technical drill và full drill
- Tabletop: thảo luận kịch bản, vai trò, quyền và quyết định mà không restore thật.
- Technical drill: dựng recovery environment và chạy restore/smoke test.
- Full drill: mô phỏng gần end-to-end nhất, có coordination, communication và chuyển traffic giả lập hoặc thực tế khi đã được phê duyệt.
Có thể tăng dần độ khó. Không cần bắt đầu bằng full failover nếu hệ thống chưa từng tabletop hoặc restore test.
Action items sau DR Drill
- runbook step nào thiếu hoặc sai;
- credential nào khó truy cập;
- dependency nào không có owner;
- restore duration nào vượt kỳ vọng;
- recovery point nào không usable;
- monitoring nào phát hiện chậm;
- smoke test nào còn thiếu;
- communication nào không rõ;
- RPO/RTO có cần điều chỉnh thực tế hơn không.
Mỗi action item nên có owner và deadline; nếu chỉ lưu biên bản mà không sửa hệ thống, drill không tạo ra improvement.
Checklist DR Drill tối thiểu
- scenario và scope;
- owner/observer;
- runbook hiện hành;
- recovery point;
- timer/event log;
- smoke test;
- RPO/RTO;
- go/no-go;
- monitoring;
- action items;
- ngày retest.
FAQ
DR Drill có làm website thật downtime không?
Không bắt buộc. Nhiều drill có thể chạy trên môi trường tách biệt hoặc mô phỏng chuyển traffic. Tác động production chỉ nên thực hiện khi phạm vi và rollback đã được phê duyệt.
Tabletop có đủ không?
Tabletop tốt cho role và decision nhưng không chứng minh backup, dependency hoặc thời gian restore. Nên kết hợp technical restore test theo mức rủi ro.
DR Drill có cần sau mỗi incident không?
Không nhất thiết ngay lập tức, nhưng incident thật phải tạo lessons learned. Nếu phát hiện runbook hoặc recovery path có vấn đề, nên retest sau khi sửa.
Kết luận
DR Drill là vòng kiểm chứng cuối cùng của Backup & Disaster Recovery: backup tạo recovery point, restore test chứng minh bản sao, runbook định nghĩa hành động, còn drill chứng minh con người và hệ thống có thể thực thi toàn bộ quy trình trong thời gian chấp nhận được.
Trong mô hình Managed Website, kết quả drill nên quay lại backlog vận hành để cải thiện monitoring, backup, quyền truy cập, runbook và SLA.
Đ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ả.
