Hầu hết các tổ chức đều có backup. Rất ít tổ chức biết chắc mình khôi phục được. Khoảng cách giữa hai điều đó không được lấp bằng một dashboard toàn màu xanh, mà bằng việc định kỳ ngồi xuống, giả định một sự cố cụ thể, và thực sự khôi phục hệ thống trong lúc có người bấm giờ.

Bài viết này mô tả cách tổ chức một buổi diễn tập khôi phục sao cho nó tạo ra kết quả dùng được: một kịch bản đủ cụ thể, một bảng phân vai rõ ràng, tiêu chí đạt được thống nhất trước khi bắt đầu, cách bấm giờ đúng với RTO đã cam kết, cách kiểm chứng dữ liệu thực sự đúng chứ không chỉ có mặt, và cách viết lại kết quả để lần sau tốt hơn.

Vì sao job backup chạy thành công không phải bằng chứng

Một job backup báo thành công chỉ chứng minh rằng tiến trình ghi đã kết thúc mà không báo lỗi. Nó không nói gì về những thứ thực sự quyết định kết quả trong một sự cố:

Bản backup có bung ra được trên phiên bản phần mềm hiện tại hay không.
Nó có chứa đủ các thành phần cần thiết để hệ thống chạy được hay không — cấu hình, secret, schema, dữ liệu tham chiếu, chứ không chỉ bảng dữ liệu chính.
Người trực lúc ba giờ sáng có biết tìm nó ở đâu và cần quyền gì để lấy hay không.
Thời gian bung ra thực tế có nằm trong khung thời gian mà business chấp nhận được hay không.

Chỉ có một cách để trả lời bốn câu hỏi đó, và đó là làm thử.

Bước 1 — Thiết kế kịch bản

Một kịch bản tốt phải cụ thể tới mức người tham gia không cần hỏi lại. Nó cần nêu rõ: cái gì hỏng, hỏng lúc nào, ai là người phát hiện, và điều gì vẫn còn hoạt động. Điểm cuối cùng rất quan trọng — nếu bạn không nói rõ cái gì còn sống, mọi người sẽ mặc định là mọi thứ đều sống, và buổi diễn tập trở nên quá dễ.

Ba kịch bản nên có trong danh mục

Mất một database primary. Kịch bản kinh điển: instance database chính không còn truy cập được, replica ở trạng thái không rõ ràng. Kiểm tra khả năng khôi phục và quy trình chuyển đổi.
Dữ liệu bị mã hóa lan trên file server dùng chung. Ở kịch bản này, điều cần kiểm tra không chỉ là khôi phục, mà là việc xác định thời điểm sạch cuối cùng: bản backup nào chưa bị ảnh hưởng. Điều này buộc đội phải thực sự làm việc với lịch sử phiên bản backup thay vì lấy bản mới nhất.
Xóa nhầm phát hiện muộn. Một tác vụ hoặc một thao tác thủ công xóa mất một tập dữ liệu, nhưng chỉ tới vài ngày sau mới có người báo. Đây là kịch bản khó nhất, vì nó buộc bạn khôi phục một phần dữ liệu vào một hệ thống đang chạy, không phải khôi phục toàn bộ vào môi trường trống.

Mỗi lần chỉ chạy một kịch bản. Nhồi cả ba vào một buổi sẽ khiến không kịch bản nào chạy tới nơi tới chốn.

Chọn mức độ thực tế

Bạn không nhất thiết phải làm hỏng hệ thống production để có một buổi diễn tập nghiêm túc. Ba mức thường dùng: khôi phục vào một môi trường tách biệt trong khi production vẫn chạy; khôi phục và cho một nhóm người dùng nội bộ sử dụng thật; hoặc chuyển hẳn tải sang môi trường vừa khôi phục. Hãy bắt đầu ở mức một và chỉ leo lên khi mức trước đã đạt liên tục vài lần.

Bước 2 — Phân vai

Diễn tập thất bại thường không phải vì thiếu kỹ năng mà vì không rõ ai quyết định cái gì. Hãy gán vai bằng tên người cụ thể trước khi bắt đầu và nói rõ giới hạn từng vai.

Vai	Trách nhiệm	Không được làm
Điều phối diễn tập	Công bố kịch bản, giữ mạch thời gian, dừng buổi diễn tập khi cần	Không tự tay thực hiện thao tác khôi phục
Người khôi phục	Thực hiện các bước khôi phục, chỉ dựa trên tài liệu runbook hiện có	Không dùng kiến thức ngầm không có trong tài liệu mà không ghi chú lại
Người ra quyết định	Chọn thời điểm khôi phục, chấp nhận mức mất mát dữ liệu, tuyên bố hoàn tất	Không can thiệp vào thao tác kỹ thuật
Người kiểm chứng	Chạy các kiểm tra toàn vẹn và nghiệm thu nghiệp vụ	Không tham gia khôi phục để giữ tính độc lập
Người ghi chép	Ghi lại mọi mốc thời gian, mọi lần bị kẹt, mọi câu hỏi phát sinh	Không gợi ý cách làm cho người khôi phục
Quan sát viên	Đại diện business hoặc bộ phận liên quan, theo dõi và đặt câu hỏi sau buổi	Không chỉ đạo trong lúc đang chạy

Hai chi tiết đáng lưu ý. Thứ nhất, người khôi phục nên là người ít quen hệ thống nhất trong nhóm đủ điều kiện, chứ không phải chuyên gia đã dựng ra nó. Chuyên gia sẽ hoàn thành nhanh nhờ trí nhớ, và bạn sẽ không phát hiện được rằng runbook thiếu ba bước. Thứ hai, người kiểm chứng phải độc lập; nếu người vừa khôi phục cũng là người tuyên bố dữ liệu đúng, bạn đang tự chấm bài của mình.

Bước 3 — Thống nhất tiêu chí đạt trước khi bắt đầu

Tiêu chí đạt phải được viết ra và được các bên đồng ý trước khi kịch bản được công bố. Nếu định nghĩa sau khi đã biết kết quả, nó sẽ luôn được điều chỉnh cho vừa với kết quả đó. Một bộ tiêu chí đủ dùng thường gồm:

Thời gian. Dịch vụ trở lại trạng thái phục vụ được trong khoảng thời gian không vượt RTO đã cam kết.
Mất mát dữ liệu. Lượng dữ liệu mất nằm trong RPO đã cam kết, và được đo bằng con số cụ thể chứ không phải nhận định.
Toàn vẹn. Vượt qua toàn bộ các phép kiểm tra toàn vẹn đã định nghĩa ở bước sau.
Chỉ dùng tài liệu. Quá trình khôi phục hoàn tất mà không cần gọi cho người không có mặt trong ca trực giả định.
Không tác dụng phụ. Không có hệ thống nào ngoài phạm vi kịch bản bị ảnh hưởng.

Ghi rõ rằng một buổi diễn tập không đạt vẫn là một buổi diễn tập thành công về mặt tổ chức. Mục tiêu là tìm ra vấn đề khi chưa có thiệt hại, và nếu đội cảm thấy việc không đạt sẽ bị quy trách nhiệm, họ sẽ vô thức chọn kịch bản dễ.

Bước 4 — Bấm giờ cho đúng

Con số thời gian chỉ có ý nghĩa nếu mọi người thống nhất mốc bắt đầu và mốc kết thúc. Cách đo thường gây tranh cãi nhất là bắt đầu tính từ lúc kỹ sư gõ lệnh đầu tiên — cách này bỏ qua toàn bộ phần chậm nhất của một sự cố thật.

Hãy đặt mốc t0 tại thời điểm sự cố được phát hiện, không phải thời điểm bắt đầu thao tác, và ghi lại các mốc sau:

t0 — thời điểm phát hiện.
t1 — thời điểm người ra quyết định xác nhận cần khôi phục.
t2 — thời điểm chọn xong bản backup và điểm khôi phục.
t3 — thời điểm dữ liệu đã bung xong.
t4 — thời điểm ứng dụng khởi động và kết nối được.
t5 — thời điểm người kiểm chứng xác nhận đạt.
t6 — thời điểm tuyên bố phục vụ được người dùng thật.

RTO được đo bằng khoảng t6 trừ t0. Các mốc trung gian cho bạn biết thời gian mất ở đâu, và trong hầu hết các buổi diễn tập đầu tiên, khoảng t0 tới t2 dài hơn nhiều so với dự đoán của mọi người — thời gian tìm tài liệu, tìm người có quyền, và tranh luận xem nên lấy bản nào.

Bước 5 — Kiểm chứng toàn vẹn, không chỉ kiểm chứng sự có mặt

Đây là phần bị làm hời hợt nhất. Việc file xuất hiện và dịch vụ khởi động được không đồng nghĩa với dữ liệu đúng. Hãy chuẩn bị sẵn bộ kiểm tra trước buổi diễn tập và giao cho người kiểm chứng chạy:

Đối chiếu số lượng. So số bản ghi của các bảng chính với giá trị kỳ vọng tại điểm khôi phục, không phải với giá trị hiện tại của production.
Kiểm tra checksum. Với tập tin và blob, so checksum thay vì kích thước.
Toàn vẹn tham chiếu. Chạy truy vấn tìm bản ghi con mồ côi, khóa ngoại trỏ vào hư không, hoặc chuỗi trạng thái bị đứt.
Bản ghi mốc. Chọn trước một số bản ghi cụ thể ở nhiều thời điểm khác nhau và kiểm tra từng trường một sau khi khôi phục.
Kiểm tra nghiệp vụ. Chạy lại một báo cáo đối soát quen thuộc và so kết quả — ví dụ tổng số dư, tổng đơn hàng theo ngày, hoặc số lượng bản ghi theo trạng thái.
Đường đi thật của người dùng. Thực hiện vài thao tác nghiệp vụ đầu cuối trên hệ thống vừa khôi phục: đăng nhập, tra cứu, tạo mới, sửa, và xem kết quả có bền vững sau khi tải lại.

Nếu hệ thống có nhiều thành phần được khôi phục riêng lẻ, hãy bổ sung phép kiểm tra tính nhất quán giữa chúng. Trường hợp hay gặp là database khôi phục về một thời điểm còn kho object về thời điểm khác, dẫn tới bản ghi trỏ tới tệp không tồn tại — lỗi không lộ ra trong smoke test nhưng lộ ngay khi người dùng thật mở bản ghi đó.

Bước 6 — Viết lại kết quả

Báo cáo diễn tập nên ngắn và luôn cùng một cấu trúc, để so sánh được giữa các lần. Một trang thường là đủ:

Kịch bản đã chạy, ngày giờ, người tham gia và vai.
Bảng các mốc thời gian t0 tới t6 và tổng thời gian so với RTO.
Mất mát dữ liệu đo được so với RPO.
Kết quả từng phép kiểm tra toàn vẹn: đạt hoặc không đạt, kèm chi tiết nếu không đạt.
Danh sách những chỗ bị kẹt, kèm nguyên nhân.
Các hành động khắc phục, mỗi hành động có một người chịu trách nhiệm và một hạn hoàn thành.

Mục cuối cùng là mục quyết định giá trị của cả buổi diễn tập. Một buổi diễn tập tìm ra chín vấn đề nhưng không ai sửa thì lần sau vẫn sẽ tìm ra đúng chín vấn đề đó. Hãy đưa các hành động khắc phục vào đúng hệ thống quản lý công việc mà đội đang dùng hằng ngày, thay vì để trong file báo cáo.

Nhịp diễn tập và những sai lầm thường gặp

Nhịp hợp lý với phần lớn tổ chức là một buổi nhỏ mỗi quý cho một hệ thống, và một buổi lớn mỗi năm có sự tham gia của business. Ngoài ra nên chạy một buổi bổ sung sau mỗi thay đổi lớn về kiến trúc lưu trữ hoặc sau khi đổi công cụ backup.

Những sai lầm hay lặp lại: báo trước quá kỹ khiến mọi người chuẩn bị sẵn; luôn để cùng một chuyên gia thực hiện; chỉ diễn tập khôi phục toàn bộ mà không bao giờ khôi phục một phần; bỏ qua cấu hình và secret; và quên kiểm tra rằng chính hệ thống backup cũng khôi phục được. Trường hợp cuối đáng lo nhất: nếu catalog backup nằm cùng chỗ với hệ thống vừa mất, bạn có dữ liệu nhưng không định vị được nó.

HiTechCloud có thể hỗ trợ gì

HiTechCloud là đối tác của AWS và Google Premier Partner, đồng thời vận hành hạ tầng trong nước. Với diễn tập khôi phục, chúng tôi có thể tham gia thiết kế kịch bản phù hợp với hệ thống của bạn, đóng vai điều phối hoặc kiểm chứng độc lập trong buổi diễn tập, xây dựng bộ kiểm tra toàn vẹn tự động hóa để chạy lại ở các lần sau, và rà soát runbook khôi phục dựa trên những chỗ đội bị kẹt trong lúc chạy thật.