CapordiaXác định trạng thái cần khôi phục trước khi chọn tệp
Hãy bắt đầu bằng một câu có thể kiểm chứng: tiếp tục các tác vụ chưa hoàn thành, đọc lại các kết quả đã được chấp nhận hoặc tiếp tục một quá trình huấn luyện từ một trạng thái đã lưu. Những mục tiêu này không đòi hỏi cùng một gói. Nêu rõ phiên bản ứng dụng, tập dữ liệu đầu vào, các tham số và thời điểm tham chiếu. Một ngày tháng tệp gần đây tự nó không cho biết rằng mọi thành phần đều đại diện cho cùng một trạng thái công việc.
Đối với một quá trình huấn luyện PyTorch, tài liệu phân biệt các tham số của mô hình và một checkpoint để tiếp tục, bao gồm cả trạng thái của bộ tối ưu hóa. Hãy xác định các yếu tố cần thiết cho quy trình của riêng bạn: tiến độ, bộ lập lịch nếu có, dữ liệu và các trạng thái ứng dụng khác. Một bản xuất chỉ dành cho suy luận có thể phù hợp cho mục đích đó nhưng lại không đủ để tiếp tục huấn luyện tại cùng một điểm.
Làm cho lần thử độc lập với thư mục làm việc
Hãy chuẩn bị một đích đến riêng biệt, với dung lượng và quyền cần thiết. Xác định rõ bản sao lưu đã chọn và bảo vệ bản sao tham chiếu của nó. Bài kiểm tra không được ghi đè lên công việc đang tiến hành cũng như công bố kết quả thay cho các đầu ra đã được chấp nhận. Hãy tắt hoặc chuyển hướng các hành động bên ngoài của ứng dụng: gửi thông báo, ghi vào một thư mục chia sẻ hoặc khởi chạy một chiến dịch bổ sung.
Hãy sử dụng chức năng khôi phục của công cụ bạn dùng trong phạm vi này. Ví dụ, Restic cho phép chọn một đích đến bằng --target và xem trước một lần khôi phục bằng --dry-run. Tài liệu của nó cảnh báo rằng một lần khôi phục tại chỗ có thể để lại trạng thái dở dang nếu bị gián đoạn. Những khả năng này minh họa cho phương pháp; chúng không có nghĩa là Restic hay một dịch vụ sao lưu được quản lý đi kèm với một thuê bao Capordia.
Lần lượt kiểm tra bản sao, trạng thái và việc sử dụng
Trước tiên hãy kiểm tra rằng gói khớp với bản kiểm kê mong đợi và các tệp không bị thay đổi. Sau đó chuyển sang việc mở thực tế: quyền, đường dẫn tương đối, các phụ thuộc, đọc dữ liệu và tải trạng thái. Một gói có thể vượt qua kiểm tra toàn vẹn mà vẫn thiếu một tệp chưa từng có trong bản kiểm kê. Kiểm tra chức năng trả lời cho câu hỏi thứ hai này.
Cuối cùng, hãy chạy một thao tác có giới hạn trong một tiến trình mới, không có quyền truy cập ngầm vào thư mục gốc. Ghi lại những gì nó đọc, những gì nó tạo ra và điều gì cho phép chấp nhận nó. Đối với việc tiếp tục một lô, hãy kiểm tra rằng nó không công bố lại các tác vụ đã được xác nhận. Một bài kiểm tra trên vài đầu vào chỉ chứng minh cho phạm vi đó; nó không bảo đảm cho toàn bộ chiến dịch cũng như toàn bộ thời lượng của nó.
| Mức | Câu hỏi | Yếu tố cần giữ lại |
|---|---|---|
| Toàn vẹn | Gói nhận được có khớp với gói dự kiến không? | Bản kiểm kê và kết quả kiểm tra |
| Trạng thái đã khôi phục | Các tệp và phụ thuộc có cho phép tải không? | Phiên bản, đường dẫn và các sai lệch ghi nhận được |
| Sử dụng | Một thao tác tiêu biểu có cho ra kết quả mong đợi không? | Đầu vào thử, đầu ra và quyết định |
Ví dụ đã giải: một tệp lưu trữ nguyên vẹn nhưng không tiếp tục được
Trường hợp hoàn toàn hư cấu: một chiến dịch gồm 240 hồ sơ. Tại điểm đã lưu, 180 hồ sơ được chấp nhận và 60 hồ sơ còn lại cần xử lý. Nhóm khôi phục bản lưu trữ trong một không gian riêng. Tất cả các tệp được liệt kê đều vượt qua kiểm tra tính toàn vẹn, nhưng ứng dụng không tìm thấy một bảng đối chiếu vốn được tải từ máy của một đồng nghiệp. Việc khôi phục bị từ chối: không thể tiếp tục trạng thái một cách tự chủ.
Nhóm thêm phiên bản chính xác của bảng này vào gói và ghi lại đường dẫn của nó. Nhóm thực hiện lại việc khôi phục tại một đích mới, rồi kiểm tra sổ đăng ký: 180 + 60 = 240 mã định danh, không trùng lặp. Trên mười hồ sơ thử nghiệm trong số sáu mươi hồ sơ còn lại, quá trình xử lý tạo ra hai mươi tệp như mong đợi, tức hai tệp mỗi hồ sơ. Nội dung của chúng được chấp nhận theo các tiêu chí đã đặt ra. Mười thử nghiệm này vẫn tách biệt với kết quả sản xuất; sổ đăng ký ban đầu không bị thay đổi bởi bài thử nghiệm.
Đo một khoảng thời gian trọn vẹn và biết nó chứng minh điều gì
Hãy bấm giờ từ khi bắt đầu công đoạn chuẩn bị cần thiết cho đến khi có kết quả được chấp nhận, phân biệt thời gian chờ, khôi phục, cấu hình và kiểm tra. Trong ví dụ hư cấu của chúng ta, các bước này lần lượt mất 15, 75, 20 và 25 phút: tổng cộng đạt 135 phút, tức 2 giờ 15 phút. Với một khung thời gian nội bộ ba giờ, thời gian dự trữ còn lại là 180 − 135 = 45 phút. Phép tính này không mô tả bất kỳ hiệu suất dịch vụ nào.
Hãy ghi lại các điều kiện giúp phép đo này có thể tái sử dụng: kích thước gói, đích, phiên bản, sự sẵn sàng của nhân sự và phạm vi kiểm tra. Độ tuổi của bản sao lưu trả lời một câu hỏi khác: công việc nào sau đó có thể phải làm lại? Việc khôi phục nhanh một trạng thái quá cũ vẫn có thể không được chấp nhận. Hãy xác định cả hai tiêu chí cùng người phụ trách dự án, mà không nhầm lẫn chúng.
| Bước | Thời gian |
|---|---|
| Chuẩn bị điểm đến | 15 phút |
| Khôi phục gói | 75 phút |
| Cấu hình ứng dụng | 20 phút |
| Chấp nhận kết quả dùng thử | 25 phút |
| Tổng / dự phòng trong 3 giờ | 135 phút / 45 phút |
Kết thúc đợt kiểm tra và giữ lại một bước tiếp theo rõ ràng
Biên bản gói gọn trong một trang: bản sao lưu đã chọn, mục tiêu, môi trường thử nghiệm, sai lệch, kết quả được chấp nhận và các giới hạn. Nếu thiếu một mục nào, hãy chỉ định người khắc phục rồi chạy lại phép kiểm tra liên quan. Đừng thay thế một thất bại bằng câu chung chung như “có bản lưu trữ”. Sau đợt kiểm tra, xác định các đầu ra thử nghiệm và xóa chúng theo quy trình của bạn, mà không đụng đến các bản sao được giữ lại để lưu trữ.
Hãy làm lại thử nghiệm khi định dạng sao lưu, phần mềm hoặc một phụ thuộc quan trọng thay đổi, và trước một mốc thời gian có thể khiến việc khôi phục trở nên khó khăn. Nhịp độ tùy thuộc vào dự án; đây không phải là cam kết tự động của dịch vụ thuê. Trong khoảng 3, 7 hoặc 30 ngày, hãy dành một khung thời gian để kiểm tra việc khôi phục và chuyển kết quả cho người sẽ tiếp tục vận hành.
Câu hỏi để quyết định
Một mã kiểm tra đúng có đủ để chấp nhận một bản sao lưu không?
Nó chỉ xác minh sự khớp của các tệp liên quan, chứ không phải tính đầy đủ của dự án hay khả năng khởi động lại. Hãy thêm một lần tải trong không gian riêng biệt và một thao tác đại diện. Báo cáo nêu rõ phạm vi của từng kiểm tra này.
Có cần tái tạo toàn bộ hoạt động cho mỗi lần thử không?
Không nhất thiết. Hãy chọn một phạm vi bao quát các phụ thuộc và tiêu chí thiết yếu, rồi nêu rõ giới hạn của nó. Một thử nghiệm nhỏ hữu ích để phát hiện một tệp bị thiếu; nó không đo lường khả năng khôi phục một khối lượng lớn hơn nhiều.
Phải làm gì nếu thử nghiệm chỉ thành công khi thư mục cũ vẫn truy cập được?
Hãy tìm phụ thuộc ngầm: cấu hình, dữ liệu, thư viện hay đường dẫn bên ngoài. Thêm nó vào gói hoặc ghi lại cách tìm lại, rồi thử lại mà không dùng đường tắt đó. Chừng nào nhu cầu này còn chưa rõ, việc khôi phục vẫn phụ thuộc vào môi trường gốc.