Tháng trước, tôi đã ngồi trong một cuộc gọi với một người lãnh đạo CNTT mệt mỏi. Bạn biết loại nào rồi đấy. Giọng nói bình tĩnh, quầng thâm, quá nhiều tab mở. Anh ấy nói, “Sao lưu thì ổn.” Rồi anh ấy dừng lại. Dừng lâu. “Nhưng tôi không tin chúng. Không thực sự.”
Dòng đó dính. Bởi vì trong các công ty lớn, sao lưu không phải là một “điều tốt để có.” Đó là điều mà bạn cầu nguyện rằng bạn sẽ không bao giờ cần… cho đến ngày bạn cần. Và vào ngày đó, không ai quan tâm đến việc lưu trữ rẻ như thế nào. Họ chỉ quan tâm đến một điều. Chúng ta có thể phục hồi, nhanh chóng, và sạch sẽ, và chứng minh điều gì đã xảy ra?
Vậy Walrus (WAL) phù hợp ở đâu trong điều gọi là sao lưu không mấy hấp dẫn đó?
Walrus là một hệ thống lưu trữ dữ liệu được xây dựng cho các khối dữ liệu lớn, như tệp, nhật ký, hình ảnh và các bản sao lưu. Mọi người gọi chúng là "blobs," đó là một từ hài hước, nhưng nó chỉ có nghĩa là "một khối tệp lớn." Walrus phân tán những khối đó trên nhiều nút lưu trữ.
Nó làm điều này theo cách có thể sống sót qua một số nút đi offline. Hãy nghĩ về nó như việc xé một bức ảnh thành nhiều mảnh ghép, sau đó giữ các mảnh bổ sung trong các ngăn kéo khác nhau. Nếu một ngăn kéo bị cháy, bạn vẫn có thể tái tạo lại bức ảnh từ những gì còn lại. Mẹo tái tạo đó thường được gọi là "mã hóa xóa," nhưng trong từ ngữ đơn giản có nghĩa là: chia nhỏ dữ liệu, thêm các mảnh an toàn và lưu trữ nó rộng rãi để bạn có thể phục hồi.
Bây giờ, nếu bạn là một doanh nghiệp, bạn có thể nghe điều đó và nói, "Ngầu… nhưng tôi làm thế nào để sử dụng nó mà không làm hỏng toàn bộ thiết lập của mình?" Công bằng. Bạn không xé bỏ các công cụ cũ của mình. Bạn không đặt cược công việc của mình vào một ngăn xếp mới trong một tuần. Bạn di chuyển từng bước, như việc băng qua một con sông trên những viên đá.
Viên đá đầu tiên rất đơn giản: coi Walrus như một bản sao thứ hai, không phải bản đầu tiên. Giữ các bản sao lưu chính của bạn ở nơi chúng đã sống. Tại chỗ, đám mây, bất cứ điều gì bạn tin tưởng hôm nay. Sau đó thêm Walrus như một lớp bổ sung cho các bản sao lưu bạn đã thực hiện. Không phải tất cả chúng. Bắt đầu với các bản sao lưu mà bạn có thể đủ khả năng để thử nghiệm. Như các bộ lưu trữ hàng tuần, nhật ký cũ hoặc dữ liệu lạnh mà bạn giữ "chỉ trong trường hợp." Đó là lối đi ít rủi ro.
Và bạn chọn một đội. Một ứng dụng. Một thùng dữ liệu. Nếu bạn cố gắng "mở rộng toàn doanh nghiệp" ngay từ ngày đầu tiên, bạn sẽ nhận được các cuộc họp, sự sợ hãi và sự chậm trễ. Một thí điểm cần có một mục tiêu chặt chẽ. Ví dụ: "Chúng tôi sẽ lưu trữ 30 ngày các bản sao lưu cơ sở dữ liệu cùng với khôi phục một bản sao lưu đầy đủ mỗi tuần từ Walrus." Chỉ vậy thôi. Một mục tiêu rõ ràng. Một điều bạn có thể đo lường. Tốc độ khôi phục. Kiểm tra dữ liệu. Nỗi đau của con người.
Viên đá thứ hai đang đảm bảo rằng Walrus phù hợp với quy tắc của bạn, không phải theo cách khác. Sao lưu không chỉ là lưu trữ. Đó là khóa, quyền truy cập, bằng chứng và thời gian.
Các khóa rất quan trọng vì nếu bạn mất khóa, bạn sẽ mất dữ liệu. Đơn giản là như vậy. Vì vậy, bạn quyết định sớm ai giữ khóa và cách chúng xoay vòng. Nói một cách đơn giản, xoay vòng có nghĩa là bạn thay đổi khóa theo một lịch trình để một lỗ hổng không kéo dài mãi mãi. Bạn cũng quyết định cách truy cập hoạt động cho các khôi phục. Bạn không muốn mỗi nhà phát triển có thể kéo một bản sao lưu đầy đủ vào lúc 2 giờ sáng mà không có ghi chép. Đó là cách rắc rối bắt đầu.
Sau đó là tính toàn vẹn. Từ đó nghe có vẻ lớn, nhưng nó có nghĩa là "tệp này có phải là tệp mà chúng tôi đã viết không?" Các bản sao lưu thất bại theo cách âm thầm. Một bit bị lật. Một tệp bị cắt. Một quy trình nói dối. Vì vậy, bản thiết kế của bạn cần có các kiểm tra. Hash là phổ biến ở đây. Một hash giống như một dấu vân tay ngắn của một tệp. Nếu dấu vân tay thay đổi, tệp đã thay đổi. Bạn lưu trữ dấu vân tay đó ở một nơi an toàn và so sánh nó khi khôi phục.
Và thời gian là ông chủ thực sự. Các doanh nghiệp sống theo hai đồng hồ. Chúng ta có thể mất bao nhiêu dữ liệu, và chúng ta phải phục hồi nhanh đến mức nào? Mọi người gọi đó là RPO và RTO, nhưng tôi sẽ không ném chữ cái vào bạn. Chỉ cần nhớ: "Chúng ta có thể ngã bao xa?" và "Chúng ta có thể đứng dậy nhanh đến mức nào?" Walrus có thể giúp với phần "đứng dậy" nếu con đường phục hồi của bạn được lên kế hoạch. Nếu bạn không lên kế hoạch phục hồi, bạn không có sao lưu. Bạn có lưu trữ. Sự khác biệt lớn.
Viên đá thứ ba là phần mà hầu hết các đội bỏ qua, vì nó nhàm chán. Các bài tập khôi phục. Vâng, các bài tập. Giống như các bài tập cứu hỏa, nhưng cho dữ liệu. Bạn lên lịch cho chúng. Bạn thực hiện chúng ngay cả khi mọi thứ đang yên tĩnh. Bạn chọn các bộ sao lưu ngẫu nhiên và khôi phục chúng vào một không gian thử nghiệm. Bạn xác minh ứng dụng khởi động. Bạn xác minh người dùng có thể đăng nhập. Bạn xác minh dữ liệu trông đúng. Sau đó, bạn viết xuống những gì bị hỏng và sửa chữa nó. Đây là cách sao lưu trở nên thực tế.
Và bạn theo dõi chi phí theo một cách đơn giản. Không phải "nói chuyện token." Chỉ cần chi phí cho mỗi bản sao lưu đã lưu trữ, chi phí cho mỗi lần khôi phục và chi phí của thời gian nhân viên. Nếu quy trình tiết kiệm được nhiều giờ, đó là giá trị. Nếu nó thêm giờ, đó là nợ. WAL token có thể là một phần của thiết kế hệ thống, nhưng bản thiết kế doanh nghiệp gợi ý về một sự thật sâu sắc hơn: việc áp dụng được giành chiến thắng bởi các đội vận hành, không phải bởi các biểu đồ.
Một điều nữa, và đây là ý kiến của tôi. Cách thuyết phục tốt nhất với một doanh nghiệp không phải là "công nghệ mới." Mà là "ít hoảng loạn." Walrus nên được coi như một lớp bình tĩnh. Một mạng lưới an toàn rộng lớn cho các bản sao lưu mà bạn đã tin tưởng. Một cách để giảm rủi ro từ nhà cung cấp đơn lẻ. Một cách để thêm một cửa thoát hiểm nữa.
Nếu bạn muốn thử điều này, hãy thực hiện một thí điểm nhỏ trong tuần này. Chọn một tập dữ liệu. Định nghĩa một bài kiểm tra khôi phục. Chạy nó. Sau đó cho tôi biết điều gì thất bại đầu tiên: việc tải lên, việc xử lý khóa, hay tốc độ khôi phục?
\u003cm-43/\u003e\u003ct-44/\u003e\u003cc-45/\u003e\u003ct-46/\u003e\u003ct-47/\u003e
