Checklist kiểm tra định kỳ hệ thống phục hồi sau thảm họa

Trong nhiều doanh nghiệp, kế hoạch phục hồi sau thảm họa (Disaster Recovery Plan) thường chỉ là một tập tài liệu nằm yên trên Google Drive sau khi vượt qua đợt đánh giá ban đầu. Đội ngũ kỹ thuật tin rằng hệ thống đã an toàn vì có lệnh cron sao lưu hàng ngày và hợp đồng thuê máy chủ dự phòng vẫn được thanh toán đều đặn. Tuy nhiên, qua thời gian vận hành, các thay đổi kiến trúc diễn ra liên tục: cơ sở dữ liệu phình to sau các đợt cập nhật, nhiều microservice mới chưa kịp bổ sung kịch bản sao lưu, trong khi nhân sự từng nắm khóa giải mã có thể đã chuyển công tác.

Khi sự cố thực tế xảy ra, sự lệch pha giữa kế hoạch trên giấy và hiện trạng hạ tầng sẽ khiến thời gian gián đoạn kéo dài hơn nhiều so với dự tính. Việc rà soát và kiểm tra định kỳ hệ thống phục hồi sau thảm họa (Disaster Recovery Readiness Audit) là cơ chế giám sát độc lập, giúp người quản lý kỹ thuật và đội ngũ SRE đối soát hiện trạng hệ thống với các chỉ tiêu cam kết bằng số liệu và bằng chứng cụ thể.

Đối soát bằng chứng kỹ thuật thay vì tin vào báo cáo

Kiểm tra hệ thống phục hồi sau thảm họa khác với buổi diễn tập thực hành (GameDay). Nếu như Kịch bản diễn tập phục hồi thảm họa cho đội ngũ kỹ thuật tập trung vào phản xạ phối hợp và thao tác gõ lệnh của con người dưới áp lực thời gian, thì đợt kiểm tra định kỳ tập trung vào tính đầy đủ của hạ tầng, sự hợp lệ của chính sách bảo vệ dữ liệu và tính pháp lý của quy trình.

Một đợt kiểm tra đạt chuẩn không thể chỉ dựa vào câu trả lời "hệ thống đã cấu hình xong" trên các buổi họp. Mọi tiêu chí đều phải đi kèm hồ sơ bằng chứng kỹ thuật (Audit Evidence):

• Không chỉ ghi nhận "có sao lưu", mà phải xuất log xác nhận bản ghi giao dịch mới nhất được nạp thành công vào môi trường kiểm thử.
• Không chỉ ghi nhận "có kho lưu trữ đám mây", mà phải kiểm tra thời hạn hiệu lực của cờ khóa chống xóa (Object Lock Retention Period) qua lệnh API.
• Không chỉ ghi nhận "có quyền truy cập máy chủ", mà phải thử nghiệm đăng nhập trực tiếp qua cổng điều khiển ngoại vi (Out-of-band Console) khi máy chủ đã bị ngắt kết nối mạng ngoài.

Phân tầng dữ liệu theo mức độ ưu tiên của dịch vụ

Một sai lầm phổ biến khiến chi phí hạ tầng đội lên gấp nhiều lần là coi mọi dữ liệu trong doanh nghiệp đều quan trọng như nhau. Việc cố gắng thiết lập cơ chế đồng bộ tức thời (Active-Active) cho toàn bộ terabyte dữ liệu log và file upload sẽ làm tiêu tốn tài nguyên mạng và ngân sách không cần thiết.

Quy trình đánh giá yêu cầu tổ chức phải phân loại hệ thống thành 3 tầng phục hồi rõ ràng (Data Recovery Tiering):

Tầng 1 (Tier 1 - Mission-Critical): Hệ thống sống còn

Bao gồm cơ sở dữ liệu giao dịch đơn hàng, số dư tài khoản, cổng xác thực người dùng (Auth Service) và bảng định tuyến thanh toán.

• Mục tiêu cam kết: RPO ≤ 15 phút, RTO ≤ 60 phút.
• Yêu cầu kỹ thuật: Cần có máy chủ dự phòng Thiết lập máy chủ dự phòng trên hai nhà cung cấp khác nhau kết hợp cơ chế nhân bản bất đồng bộ liên tục, và snapshot dữ liệu lên kho khóa bảo lưu hàng giờ.
• Tần suất kiểm tra: Tối thiểu 3 tháng một lần (hàng quý).

Tầng 2 (Tier 2 - Business Operations): Hoạt động vận hành phụ trợ

Bao gồm phần mềm quản lý quan hệ khách hàng (CRM), hệ thống ERP nội bộ, cổng xuất bản tin tức (CMS) và tài liệu trao đổi nội bộ.

• Mục tiêu cam kết: RPO ≤ 4 giờ, RTO ≤ 4 giờ.
• Yêu cầu kỹ thuật: Sử dụng công cụ sao lưu dạng khối (như Restic) chạy định kỳ hàng ngày, nén dữ liệu và đẩy lên kho S3 có khóa bảo lưu. Môi trường có thể dựng lại từ các template Docker Compose chuẩn bị sẵn.
• Tần suất kiểm tra: Tối thiểu 6 tháng một lần.

Tầng 3 (Tier 3 - Archival & Analytics): Lưu trữ và phân tích dữ liệu

Bao gồm các tệp log lịch sử nhiều tháng, video/file media thô, kho dữ liệu phân tích (Data Warehouse).

• Mục tiêu cam kết: RPO ≤ 24 giờ, RTO ≤ 24 giờ đến 48 giờ.
• Yêu cầu kỹ thuật: Lưu trữ trên các dịch vụ đám mây tầng lạnh (Cold Storage như Wasabi hoặc AWS S3 Glacier), chỉ khôi phục khi có yêu cầu thanh tra hoặc phân tích dài hạn.
• Tần suất kiểm tra: Mỗi năm một lần thông qua đối soát mã băm checksum (SHA-256).

Kiểm tra cơ chế chống xóa và phân quyền kho sao lưu

Khi tin tặc xâm nhập vào hệ thống hoặc phần mềm tống tiền phát tán, mục tiêu đầu tiên của kẻ tấn công là tìm kiếm thông tin đăng nhập kho sao lưu để xóa sạch các bản snapshot trước khi kích hoạt mã hóa dữ liệu. Nếu kho sao lưu cho phép tài khoản thông thường xóa tệp, toàn bộ hệ thống sao lưu sẽ mất đi giá trị bảo vệ.

Như đã phân tích trong bài viết Sao lưu chống Ransomware với Restic và S3 Object Lock, quy trình kiểm tra kho sao lưu cần tập trung vào 3 yếu tố bảo vệ then chốt:

[Máy chủ ứng dụng] ──(Tài khoản chỉ nạp: PutObject)──> [Kho S3 Object Lock]
                                                              │
   Không thể sửa đổi / Không thể xóa (Compliance Mode) ───────┘
                                                              ▲
[Tài khoản Quản trị kho] ──(Tách biệt hoàn toàn + MFA) ──────┘

1. Trạng thái khóa bảo lưu (Compliance Mode): Kỹ sư phụ trách cần kiểm tra trực tiếp qua giao diện dòng lệnh (CLI) của kho lưu trữ đám mây để xác nhận cờ Object Lock đang ở chế độ Compliance (chế độ tuân thủ nghiêm ngặt), đảm bảo không ai (kể cả tài khoản root của dịch vụ lưu trữ) có thể rút ngắn thời hạn khóa trước thời hạn:

   # Kiểm tra trạng thái Object Lock của bucket lưu trữ sao lưu
   aws s3api get-object-lock-configuration --bucket company-backup-immutable

1. Nguyên tắc đặc quyền tối thiểu (Least Privilege IAM): Kiểm tra các cặp khóa truy cập (Access Key / Secret Key) đang lưu trên máy chủ VPS. Tài khoản này chỉ được phép chứa quyền s3:PutObject và s3:GetObject. Mọi quyền xóa như s3:DeleteObject, s3:DeleteObjectVersion cần được cấu hình từ chối tường minh (Explicit Deny).
2. Mã hóa độc lập (Client-side Encryption): Xác nhận dữ liệu đã được mã hóa từ phía máy chủ nguồn trước khi truyền tải qua mạng theo nguyên tắc của Quy tắc sao lưu 3-2-1 cho máy chủ.

Kiểm tra kênh cứu hộ ngoại vi khi mất kết nối mạng

Một tình huống sự cố thường gặp là tường lửa bị cấu hình sai, dịch vụ SSH bị treo, hoặc nhà mạng gặp sự cố định tuyến khiến bạn không thể truy cập vào máy chủ qua địa chỉ IP công cộng thông thường. Nếu chỉ phụ thuộc vào kết nối SSH tiêu chuẩn, đội ngũ vận hành sẽ mất quyền kiểm soát máy chủ.

Người kiểm tra cần trực tiếp xác minh tính sẵn sàng của các kênh cứu hộ ngoại vi (Out-of-band Management):

• Web Console và VNC của nhà cung cấp: Đăng nhập vào bảng điều khiển quản trị của nhà cung cấp máy chủ (Hetzner Cloud Console, OVH vSphere, DigitalOcean Recovery Console) và mở giao diện VNC Console để xác nhận bàn phím và màn hình ảo vẫn tương tác được với hệ điều hành.
• Tài khoản khẩn cấp (Break-glass Account): Kiểm tra việc thiết lập tài khoản quản trị cục bộ độc lập, không gắn liền với hệ thống định danh tập trung (SSO / LDAP / Authentik). Khi mạng nội bộ sập, tài khoản này là con đường duy nhất để kỹ sư truy cập hệ thống.
• Môi trường Rescue OS: Xác nhận máy chủ có thể chuyển đổi sang chế độ cứu hộ (Rescue Mode chạy trên RAM) trong vòng 5 phút để thao tác sửa đổi file hệ thống hoặc khôi phục bảng phân vùng ổ đĩa khi kernel bị lỗi.

Lưu trữ biến môi trường và khóa giải mã bên ngoài máy chủ

Trong nhiều vụ việc gián đoạn dịch vụ, bản sao lưu dữ liệu vẫn còn nguyên vẹn nhưng hệ thống không thể khởi động lại vì toàn bộ biến môi trường .env, chứng chỉ số SSL và khóa giải mã đều bị lưu trữ cục bộ trên máy chủ vừa bị phá hủy.

Danh mục các thành phần độc lập ngoại vi cần được đối soát:

Quy trình 4 bước kiểm tra định kỳ

Để hoạt động đánh giá diễn ra minh bạch và mang lại giá trị thực tế, quy trình kiểm tra cần tuân theo chu trình 4 giai đoạn khép kín:

1. Kiểm kê và phân tầng tài nguyên (Inventory & Tiering): Rà soát toàn bộ danh mục ứng dụng mới phát sinh trong kỳ. Gán nhãn cấp độ phục hồi Tier 1, Tier 2 hoặc Tier 3 cho từng dịch vụ.
2. Kiểm tra cơ chế chống xóa và kênh ngoại vi (Immutability & Out-of-band): Kiểm tra trạng thái cờ khóa Object Lock trên S3, rà soát phân quyền tài khoản IAM và thử nghiệm kết nối VNC Web Console.
3. Phục hồi thực chứng trên Sandbox (Evidence-based Verification): Kéo bản sao lưu ngẫu nhiên từ kho lưu trữ và giải nén trên máy chủ độc lập sạch hoàn toàn. Bấm giờ RTO thực tế và đối soát bản ghi cơ sở dữ liệu để xác nhận chỉ số RPO.
4. Nghiệm thu và phân công khắc phục (Sign-off & Action Items): Lập bảng tổng kết, ghi nhận các điểm không đạt cam kết và phân công nhiệm vụ khắc phục với thời hạn cụ thể.

Bảng checklist 20 hạng mục kiểm tra định kỳ

Dưới đây là bảng kiểm tra chi tiết phục vụ cho các đợt rà soát định kỳ hàng quý hoặc hàng năm của đội ngũ kỹ thuật:

Nhóm A: Danh mục tài nguyên và Cam kết SLA

• ☐ 1. Toàn bộ cơ sở dữ liệu, dịch vụ web và container mới triển khai trong kỳ đều đã được đưa vào danh mục giám sát sao lưu.
• ☐ 2. Mọi hệ thống đều được phân loại theo 3 cấp độ (Tier 1, Tier 2, Tier 3) với ngưỡng cam kết RTO/RPO bằng văn bản.
• ☐ 3. Cam kết RTO và RPO kỹ thuật đã được người phụ trách sản phẩm hoặc ban quản lý xác nhận phù hợp với chi phí hạ tầng.
• ☐ 4. Không có dịch vụ nào phụ thuộc vào tài khoản cá nhân của một kỹ sư duy nhất mà thiếu cơ chế ủy quyền thay thế.

Nhóm B: Cơ chế chống xóa và An toàn dữ liệu

• ☐ 5. Kho sao lưu đám mây (S3/Wasabi/R2) được kích hoạt cờ Object Lock ở chế độ Compliance Mode với thời hạn lưu giữ tối thiểu 14 ngày.
• ☐ 6. Cặp khóa API cấp cho máy chủ ứng dụng chỉ có quyền ghi (PutObject), không có bất kỳ quyền xóa (DeleteObject) nào.
• ☐ 7. Tài khoản quản trị cấp cao nhất (Root/Owner) của dịch vụ lưu trữ đám mây được kích hoạt xác thực hai lớp bằng khóa bảo mật vật lý (FIDO2 / YubiKey).
• ☐ 8. Dữ liệu sao lưu được mã hóa đầu cuối bằng thuật toán tiêu chuẩn (AES-256) trước khi rời khỏi máy chủ nguồn.

Nhóm C: Kênh cứu hộ và Khả năng tiếp cận ngoại vi

• ☐ 9. Bảng điều khiển quản trị máy chủ (Web Console, VNC, Serial Console) đã được kiểm tra đăng nhập thành công từ mạng ngoài.
• ☐ 10. Mật khẩu tài khoản cứu hộ khẩn cấp (Break-glass Account) được lưu trữ tại két sắt số an toàn và hoạt động độc lập với máy chủ SSO.
• ☐ 11. Tính năng khởi động bằng hệ điều hành cứu hộ (Rescue OS) của nhà cung cấp máy chủ được thử nghiệm và sẵn sàng trong vòng 5 phút.
• ☐ 12. Danh sách số điện thoại khẩn cấp và kênh liên lạc dự phòng ngoại vi (như nhóm Signal kín) được cập nhật đầy đủ thông tin nhân sự trực chiến.

Nhóm D: Cấu hình và Môi trường ứng dụng

• ☐ 13. Toàn bộ file biến môi trường bí mật (.env) của môi trường sản xuất được lưu trữ phiên bản mới nhất tại kho quản lý bí mật tập trung.
• ☐ 14. Mật khẩu giải mã bản sao lưu (Passphrase / Private Key) có ít nhất 2 bản sao lưu độc lập bên ngoài hạ tầng máy chủ chính.
• ☐ 15. Tài liệu hướng dẫn khôi phục (Runbook) được kiểm tra thực tế, đảm bảo không chứa các câu lệnh phụ thuộc vào trí nhớ cá nhân.
• ☐ 16. Kịch bản chuyển hướng tên miền chuyển vùng DNS tự động khi Data Center sự cố có thời gian TTL được duy trì ở mức an toàn (dưới 120 giây).

Nhóm E: Kiểm chứng thực tế trên môi trường Sandbox

• ☐ 17. Đã tiến hành kéo bản sao lưu ngẫu nhiên trong kỳ và phục hồi thành công trên một máy chủ thử nghiệm hoàn toàn mới.
• ☐ 18. Chỉ số RPO thực tế đo được qua bản ghi dữ liệu mới nhất nằm trong giới hạn cam kết của từng phân tầng.
• ☐ 19. Các luồng kiểm thử nghiệp vụ cốt lõi (đăng nhập tài khoản, tạo đơn thử nghiệm, hiển thị hình ảnh) vượt qua bài kiểm tra chức năng.
• ☐ 20. Biên bản nghiệm thu đợt kiểm tra được lập đầy đủ hồ sơ bằng chứng và có chữ ký xác nhận trách nhiệm của Lead SRE cùng người đại diện quản lý kỹ thuật.

Mẫu biên bản nghiệm thu sau đợt kiểm tra

Sau khi hoàn tất việc đối soát theo bảng kiểm tra, kết quả cần được ghi nhận vào biên bản chính thức để lưu trữ hồ sơ theo dõi:

# BIÊN BẢN NGHIỆM THU HỆ THỐNG PHỤC HỒI SAU THẢM HỌA (DR READINESS SIGN-OFF)
Kỳ kiểm tra: Quý IV / 2026 | Ngày thực hiện: 28/10/2026

1. KẾT QUẢ ĐỐI SOÁT CHỈ TIÊU CỐT LÕI:
- Hệ thống kiểm tra: Cụm cơ sở dữ liệu giao dịch chính (Tier 1 - MySQL Production)
- Bản sao lưu được chọn ngẫu nhiên: Snapshot ngày 27/10/2026 lúc 02:00 UTC
- Thời gian phục hồi thực tế (RTO đo được): 48 phút (Mục tiêu cam kết: ≤ 60 phút) -> ĐẠT
- Độ thất thoát dữ liệu (RPO đo được): 12 phút (Mục tiêu cam kết: ≤ 15 phút) -> ĐẠT
- Trạng thái S3 Object Lock Compliance: CÒN HIỆU LỰC (Thời hạn bảo lưu: 30 ngày) -> ĐẠT

2. CÁC TỒN ĐỌNG KỸ THUẬT CẦN KHẮC PHỤC (ACTION ITEMS):
- [ ] Bổ sung biến môi trường mới của dịch vụ Notification vào kho bí mật Infisical (Hạn chót: 05/11/2026 - Người chịu trách nhiệm: Nguyễn Văn A)
- [ ] Thu hồi tài khoản SSH của kỹ sư cũ theo quy trình Offboarding (Hạn chót: 30/10/2026 - Người chịu trách nhiệm: Trần Văn B)

3. CHỮ KÝ PHÊ DUYỆT TRÁCH NHIỆM:
- Người thực hiện kiểm tra (Lead SRE): ........................................ (Ký và ghi rõ họ tên)
- Người phê duyệt hạ tầng (CTO / Head of Engineering): ....................... (Ký và ghi rõ họ tên)

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

Ai nên là người chủ trì đợt kiểm tra định kỳ?

Để đảm bảo tính khách quan, người chủ trì kiểm tra không nên là kỹ sư trực tiếp cấu hình hệ thống sao lưu hàng ngày. Trong các tổ chức vừa và nhỏ, vai trò này nên do Lead SRE, chuyên viên an toàn thông tin (SecOps) hoặc một kỹ sư cấp cao từ nhóm phát triển khác đảm nhiệm. Đối với các hệ thống lớn có yêu cầu tuân thủ khắt khe, bạn có thể mời đơn vị đánh giá độc lập bên ngoài để rà soát toàn diện.

Nếu phát hiện một tiêu chí kiểm tra không đạt thì có cần dừng hệ thống để xử lý ngay không?

Mục đích của đợt kiểm tra là tìm ra các lỗ hổng tiềm ẩn khi hệ thống vẫn đang hoạt động bình thường, do đó bạn không cần phải dừng khẩn cấp môi trường sản xuất. Tuy nhiên, các tiêu chí không đạt (ví dụ: kho sao lưu bị tắt cờ chống xóa, hoặc file .env bị thiếu) phải được phân loại thành các đầu việc khẩn cấp (P0/P1) trong biên bản nghiệm thu, đi kèm người chịu trách nhiệm và hạn chót khắc phục cụ thể không quá 7 ngày làm việc.

Có cần kiểm tra lại khi một thành viên trong nhóm kỹ thuật nghỉ việc không?

Có. Khi một nhân sự quản trị hệ thống rời khỏi tổ chức, ngoài việc thực hiện thu hồi tài khoản theo Quy trình thu hồi quyền quản trị hạ tầng khi nhân sự nghỉ việc, bạn cần tiến hành một đợt rà soát nhanh (Mini-Check) để kiểm tra việc đổi khóa mã hóa kho sao lưu, luân chuyển mật khẩu cứu hộ khẩn cấp và cập nhật danh sách đầu mối liên lạc trong kịch bản ứng phó sự cố.