Khắc phục hậu quả sau thảm họa cho các doanh nghiệp vừa và nhỏ: Năm vấn đề chính cần xem xét

Cùng xem xét các cân nhắc chính về khôi phục sau thảm họa đối với các doanh nghiệp vừa và nhỏ, bao gồm lý do tại sao chỉ sao lưu thôi là không đủ, cách tạo kế hoạch khôi phục sau thảm họa, kinh nghiệm thực hiện DR Testing và DR như một dịch vụ.

Trong vòng 18 tháng qua, các doanh nghiệp thuộc mọi quy mô đã học cách sống chung với sự gián đoạn. Khi các đợt phong tỏa, giãnu cách buộc các văn phòng phải đóng cửa, các công ty đã phải chuyển sang làm việc từ xa sau đó.

Đối với một số công ty, đây là một điều hoàn toàn mới. Đối với những công ty khác, đó là một phần của kế hoạch phục hồi sau thảm họa (Disaster Recovery) đã có sẵn để phục vụ cho nền tảng kinh doanh liên tục. Nhân viên làm việc từ máy tính xách tay với dữ liệu trong đám mây là một cách thiết lập để đối phó với sự cố có thể dao động từ sự cố mất điện đến thiên tai.

Các kế hoạch khắc phục hậu quả thiên tai từ lâu đã trở nên phổ biến đối với các doanh nghiệp và các cơ quan lớn trong khu vực công, nhưng chúng cũng quan trọng không kém đối với các tổ chức nhỏ hơn. Nếu một doanh nghiệp quy mô vừa và nhỏ (SME) cung cấp cho các doanh nghiệp lớn hoặc chính phủ, một kế hoạch khôi phục sau thảm họa thì thường là được uỷ quyền.

Nhưng nhiều nguyên tắc đằng sau việc lập kế hoạch phục hồi sau thảm họa được áp dụng bất kể quy mô của doanh nghiệp. Và công nghệ, đặc biệt là các dịch vụ dựa trên đám mây, đang làm cho việc khắc phục thảm họa trở nên dễ tiếp cận hơn đối với các doanh nghiệp vừa và nhỏ.

Khôi phục sau thảm họa, hay Sao lưu và Phục hồi?

Khôi phục sau thảm họa thường được xem như một bài tập kỹ thuật thuần túy, tập trung vào việc sao lưu và khôi phục dữ liệu. Mặc dù bảo vệ dữ liệu vẫn là một phần quan trọng của bất kỳ quá trình khôi phục thảm họa nào – không tổ chức nào sẽ tồn tại nếu không thể khôi phục dữ liệu của mình – DR còn rộng hơn thế.

Một kế hoạch DR cần phải xem xét cách dữ liệu được bảo vệ. Điều này rất quan trọng để đối phó với những hỏng hóc tiềm ẩn do sự cố phần mềm hoặc phần cứng, cũng như các sự cố môi trường, chẳng hạn như lũ lụt hay hỏa hoạn.

Các nhà hoạch định cần xem xét việc kinh doanh sẽ hoạt động như thế nào và ở đâu trong tình trạng phục hồi. Điều này bao gồm cơ sở vật chất, bao gồm không gian làm việc chuyển đổi dự phòng hoặc khôi phục và khả năng làm việc tại nhà của nhân viên.

Doanh nghiệp cũng sẽ cần xem xét thiết bị thay thế, trong trường hợp phần cứng hiện có bị hư hỏng, phá hủy hoặc không thể truy cập được. Điều này bao gồm máy tính xách tay, máy tính bảng và các thiết bị điểm cuối khác, cũng như thiết bị truyền thông và mạng, máy chủ và lưu trữ cho các hệ thống tại chỗ.

Hầu hết các doanh nghiệp vừa và nhỏ sẽ không đủ khả năng trang bị các trung tâm dữ liệu hoặc máy chủ dự phòng hoặc chờ sẵn. Trong một số trường hợp, các tổ chức có thể chuyển đổi dự phòng sang đám mây hoặc tạm thời sử dụng đám mây. Đối với những công ty khác, chiến lược khôi phục sẽ là lấy và thiết lập phần cứng mới để khôi phục các ứng dụng và dữ liệu.

Tuy nhiên, chìa khóa của bất kỳ cách tiếp cận nào là phải lập kế hoạch.

Lập kế hoạch DR: Không phải Nếu, mà là Khi nào

Trong vài năm qua, các tổ chức đã chuyển từ làm việc dựa trên cơ sở rằng thảm họa có thể xảy ra, sang nhận thức rằng thảm họa sẽ xảy ra. Một phần, điều này được thúc đẩy bởi sự gia tăng tội phạm mạng, đặc biệt là ransomware. Trong khi đó, đại dịch đã đẩy việc khắc phục hậu quả thảm họa lên chương trình hành động của công ty.

Bất kể quy mô như thế nào, các công ty cần bắt đầu với một kế hoạch khôi phục sau thảm họa đặt ra những việc cần làm trong trường hợp xảy ra thảm họa và quan trọng nhất là ai sẽ làm việc đó.

Kế hoạch cần được nhìn toàn diện, được xem xét và thực hành. Các CIO cần hiểu dữ liệu và các hệ thống quan trọng của họ ở đâu, chúng được sao lưu như thế nào và nên khôi phục chúng như thế nào. Với các tổ chức đang vận hành ngày càng nhiều hệ thống CNTT, họ cũng có thể cần ưu tiên khôi phục theo giai đoạn. Nó sẽ không thể quay tất cả các hệ thống cùng một lúc.

Disaster Recovery Plan Template - Evolve IP

Sau khi CIO hoặc nhóm dự án đã đồng ý kế hoạch, nó cần được thông báo trong toàn tổ chức.

Tony Lock từ hãng phân tích Freeform Dynamics cho biết, các tổ chức thường thất bại vì thiếu sự chuẩn bị. Ông chỉ ra: “DR không chỉ là phục hồi hệ thống CNTT ở cấp độ kỹ thuật và dữ liệu.

“Ngoài công nghệ và dữ liệu, điều cần thiết là phải đảm bảo rằng các quy trình khôi phục được hiểu rõ, bao gồm cả ai sẽ chịu trách nhiệm bắt đầu khôi phục và chi trả mọi chi phí phát sinh. Nhân viên có biết phải đi đâu, liên hệ như thế nào và các quy trình phục hồi có được viết rõ ràng và dễ tìm trong trường hợp khẩn cấp không? ”

Các tổ chức cũng cần xem xét chuỗi cung ứng của họ và cách họ phụ thuộc vào những người khác để cung cấp hàng hóa, dịch vụ và thậm chí cả dữ liệu.

Adam Stringer, một chuyên gia về khả năng phục hồi kinh doanh tại PA Consulting, cho biết: “Các công ty thường không cân nhắc đến sự phụ thuộc của bên thứ ba và hiếm khi kiểm tra các thỏa thuận giữa các công ty, nhưng trong một thảm họa, các ưu tiên của họ không chắc đã hợp lý với doanh nghiệp của bạn”. Ông cho biết thêm, một kế hoạch rõ ràng sẽ giúp xác định những yếu tố phụ thuộc này và tổ chức sẽ hoạt động như thế nào nếu một nhà cung cấp quan trọng trở nên thất bại.

Rủi ro và khoảng thời gian phục hồi

Để lập kế hoạch, các CIO và các nhà quản lý khả năng phục hồi kinh doanh cần hiểu các rủi ro và các yêu cầu để doanh nghiệp trở lại hoạt động bình thường.

Các chỉ số chính được sử dụng trong khắc phục thảm họa – bất kể quy mô doanh nghiệp – là Recovery Point Objective (RPO) và Recovery Time Objective (RTO). RTO là dữ liệu cần được phục hồi và truy cập nhanh đến mức nào. Đối với một số hệ thống, điều này sẽ được đo bằng giây; ở những nơi khác, nó có thể là vài giờ hoặc thậm chí vài ngày.

RPO là lượng dữ liệu mà tổ chức có thể bị mất. Một lần nữa, một số tổ chức sẽ có khả năng mất dữ liệu rất thấp.

Disaster recovery - Wikipedia

Đối với RPO và RTO, không phải tất cả các hệ thống sẽ như nhau. Một số, chẳng hạn như các ứng dụng dành cho khách hàng hoặc những ứng dụng có dữ liệu được quản lý, sẽ có thời gian khôi phục nhanh và ngưỡng mất dữ liệu thấp. Những chỗ khác sẽ ít quan trọng hơn hoặc được cập nhật ít thường xuyên hơn. Điều quan trọng là các nhà lập kế hoạch làm việc với doanh nghiệp để hiểu các mức độ ưu tiên và thời gian.

Stephen Young, giám đốc DR và công ty sao lưu đám mây AssureStor cho biết, các nhà lập kế hoạch cũng cần xem xét RPO và RTO về các mối đe dọa. Ông xác định chính xác các rủi ro về đánh cắp dữ liệu và mất dữ liệu là những yếu tố cần cân nhắc chính, cùng với RPO và RTO.

Kiểm tra và thử nghiệm nhiều lần

Tuy nhiên, việc lập kế hoạch khắc phục hậu quả thiên tai sẽ chưa hoàn thành dù đã lên xong kế hoạch. Các tổ chức cần truyền đạt kế hoạch – và kiểm tra nó.

“Các công ty có thể có các kế hoạch và quy trình bằng văn bản, nhưng chúng có thể không thực tế hoặc không được biết đến rộng rãi và sau đó không thực sự được áp dụng trong một cuộc khủng hoảng,” Stringer của PA Consulting nói.

“Họ cần một cấu trúc ra quyết định rõ ràng và các playbook đã được thống nhất và hoàn thiện thông qua thực hành và thử nghiệm, cộng với các cách tiếp cận dễ hiểu như cấu trúc lệnh vàng, bạc và đồng. Đây là những công dụng thiết thực hơn đối với các công ty trong thời kỳ thiên tai hơn là một cuốn sách hướng dẫn chi tiết 100 trang ”.

Các tổ chức cũng cần xem xét ai sẽ quản lý phản ứng với khủng hoảng. Đây có thể không phải lúc nào cũng là MD hoặc CEO; đó có thể là trưởng phòng tài chính hoặc giám đốc công nghệ thông tin. Điều quan trọng là đảm bảo mọi người biết ai sẽ chịu trách nhiệm và họ sẽ giao tiếp như thế nào.

Ông Tony Lock nói thêm: “Việc kiểm tra sẽ tiêu tốn thời gian và ngân sách, nhưng nếu không có nó, khả năng cao là quá trình phục hồi sẽ không hoàn thành hoặc chậm chạp. “Tệ nhất, hoặc nó sẽ không hoạt động, sẽ mất quá nhiều thời gian cho doanh nghiệp hoặc có thể mất thông tin quan trọng.”

Kiểm tra nên thường xuyên, với các chuyên gia DR đề nghị mỗi năm một lần là mức tối thiểu. Các hệ thống quan trọng có thể cần kiểm tra ít nhất hàng tháng.

Khôi phục thảm họa dưới dạng dịch vụ và SaaS

Tuy nhiên, các công ty nhỏ hơn sẽ không có quyền truy cập vào các nhóm CNTT lớn có thể xây dựng các hệ thống CNTT trùng lặp.

May mắn thay, đám mây cung cấp các tùy chọn khác nhau, từ phục hồi thảm họa chuyên dụng dưới dạng nhà cung cấp dịch vụ (DRaaS) đến các ứng dụng kinh doanh như Microsoft Office 365.

Office 365, Google Workspace và các ứng dụng doanh nghiệp dựa trên đám mây cho phép doanh nghiệp khôi phục phần lớn hoạt động của mình miễn là nhân viên của họ có quyền truy cập vào trình duyệt web. Lưu trữ đám mây cũng có thể là một cứu cánh.

Nhưng có những lưu ý. Lưu trữ đám mây cấp người tiêu dùng làm nảy sinh các vấn đề về tuân thủ và các nhà cung cấp SaaS chỉ cung cấp các bảo đảm có giới hạn cho dữ liệu của khách hàng. Các CIO nên kiểm tra các điều khoản và điều kiện, đồng thời xem xét các DRaaS chuyên dụng ngay cả khi hầu hết các ứng dụng và dữ liệu của họ đã ở trên đám mây.

____
Bài viết liên quan
Góp ý / Liên hệ tác giả