Chia sẻ qua

Khuyến nghị cho việc thiết kế chiến lược phục hồi thảm họa

Áp dụng cho khuyến nghị về danh sách kiểm tra độ tin cậy được thiết kế tốt này: Power Platform

TRẢ LỜI:07 Triển khai các kế hoạch phục hồi sau thảm họa và duy trì hoạt động kinh doanh (BCDR) có cấu trúc, được thử nghiệm và ghi chép lại phù hợp với các mục tiêu phục hồi. Kế hoạch phải bao gồm tất cả các thành phần và toàn bộ hệ thống.

Hướng dẫn này mô tả các khuyến nghị để thiết kế chiến lược phục hồi thảm họa đáng tin cậy cho khối lượng công việc. Để đáp ứng các mục tiêu cấp độ dịch vụ nội bộ (SLO) hoặc thậm chí là thỏa thuận cấp độ dịch vụ (SLA) mà bạn đã đảm bảo cho khách hàng, bạn phải có chiến lược phục hồi thảm họa mạnh mẽ và đáng tin cậy. Có thể xảy ra lỗi và các vấn đề lớn khác. Sự chuẩn bị của bạn để giải quyết những sự cố này quyết định mức độ tin tưởng của khách hàng vào khả năng cung cấp dịch vụ đáng tin cậy của doanh nghiệp bạn. Chiến lược phục hồi sau thảm họa là nền tảng cho việc chuẩn bị ứng phó với các sự cố lớn.

Định nghĩa

Thuật ngữ Định nghĩa
Chuyển đổi dự phòng Việc chuyển dịch tự động và/hoặc thủ công lưu lượng khối lượng công việc sản xuất từ vùng không khả dụng sang vùng không bị ảnh hưởng.
Dự phòng Việc chuyển đổi tự động và/hoặc thủ công lưu lượng khối lượng công việc sản xuất từ vùng dự phòng trở lại vùng chính.

Các chiến lược thiết kế chính

Hướng dẫn này giả định rằng bạn đã thực hiện các nhiệm vụ sau đây như một phần trong kế hoạch đảm bảo độ tin cậy của mình:

Kiến trúc khối lượng công việc đáng tin cậy là cơ sở cho chiến lược phục hồi thảm họa (DR) đáng tin cậy. Hãy cân nhắc độ tin cậy ở mọi giai đoạn tạo khối lượng công việc để đảm bảo rằng bạn có đủ các thành phần cần thiết cho quá trình phục hồi hiệu quả trước khi bắt đầu lập kế hoạch cho chiến lược DR. Nền tảng này đảm bảo rằng các mục tiêu về độ tin cậy của khối lượng công việc của bạn, chẳng hạn như mục tiêu thời gian phục hồi (RTO) và mục tiêu điểm phục hồi (RPO), là thực tế và có thể đạt được.

Duy trì kế hoạch phục hồi thảm họa

Chìa khóa cho chiến lược DR đáng tin cậy cho khối lượng công việc chính là kế hoạch DR . Kế hoạch của bạn phải là một văn bản sống được sửa đổi và cập nhật thường xuyên khi môi trường thay đổi. Chia sẻ kế hoạch với các nhóm liên quan (hoạt động, lãnh đạo công nghệ và các bên liên quan trong doanh nghiệp) thường xuyên (ví dụ: sáu tháng một lần). Lưu trữ dữ liệu trong kho lưu trữ dữ liệu an toàn và có tính khả dụng cao như OneDrive.

Thực hiện theo các khuyến nghị sau để xây dựng kế hoạch DR của bạn:

  • Xác định rõ ràng những gì cấu thành nên thảm họa và yêu cầu kích hoạt kế hoạch DR.

    Thảm họa là vấn đề có quy mô lớn. Chúng có thể là sự cố mất điện cục bộ, sự cố mất điện của các dịch vụ như ID hoặc Azure DNS hoặc các cuộc tấn công độc hại nghiêm trọng như tấn công bằng phần mềm tống tiền hoặc tấn công DDoS. Microsoft Entra

    Bao gồm các ví dụ về chế độ lỗi không được coi là thảm họa, chẳng hạn như không khả dụng hoặc lỗi của một nguồn lực duy nhất, trong kế hoạch DR của bạn để người vận hành không vô tình kích hoạt các biện pháp leo thang DR.

  • Xây dựng kế hoạch DR dựa trên tài liệu FMA của bạn. Đảm bảo rằng kế hoạch DR của bạn nắm bắt được các chế độ lỗi và chiến lược giảm thiểu sự cố mất điện được xác định là thảm họa. Nếu cần cập nhật, hãy cập nhật cả kế hoạch DR và tài liệu FMA cùng lúc để chúng chính xác khi môi trường thay đổi hoặc khi thử nghiệm phát hiện ra những hành vi không mong muốn.

  • Xác định rõ ràng các vai trò và trách nhiệm trong nhóm khối lượng công việc và hiểu rõ mọi vai trò bên ngoài có liên quan trong tổ chức của bạn. Nếu thảm họa xảy ra do sự cố ngừng hoạt động của một dịch vụ bên ngoài, chẳng hạn như Microsoft Entra ID, hãy đảm bảo rằng bạn đã xác định vai trò chịu trách nhiệm liên lạc với bên ngoài và có thể chia sẻ các bản cập nhật với nhóm khối lượng công việc. Các vai trò cần bao gồm:

    • Bên chịu trách nhiệm tuyên bố thảm họa
    • Bên chịu trách nhiệm tuyên bố kết thúc sự cố
    • Vai trò hoạt động
    • Vai trò kiểm tra và xác nhận
    • Vai trò truyền thông nội bộ và bên ngoài
    • Vai trò dẫn đầu của phân tích hồi cứu và nguyên nhân gốc rễ (RCA)

  • Xác định các đường dẫn leo thang mà nhóm khối lượng công việc phải tuân theo để đảm bảo trạng thái phục hồi được truyền đạt tới các bên liên quan.

  • Bao gồm thứ tự quy định trong đó các thành phần của khối lượng công việc cần được phục hồi để gây ra tác động ít nhất. Ví dụ: khôi phục cơ sở dữ liệu và khởi động lại luồng dữ liệu đám mây trước khi bạn khôi phục ứng dụng.

    • Trình bày chi tiết quy trình phục hồi của từng thành phần theo hướng dẫn từng bước. Nếu có thể, hãy bao gồm ảnh chụp màn hình và các điều kiện tiên quyết để chạy quy trình. Ví dụ, liệt kê các tập lệnh hoặc thông tin xác thực cần phải thu thập.

    • Xác định trách nhiệm của nhóm bạn so với trách nhiệm của nhà cung cấp dịch vụ lưu trữ đám mây. Ví dụ, Microsoft chịu trách nhiệm khôi phục PaaS (nền tảng dưới dạng dịch vụ), nhưng bạn chịu trách nhiệm khôi phục dữ liệu và áp dụng cấu hình của mình vào dịch vụ.

    • Xác định nguyên nhân gốc rễ của sự cố và thực hiện biện pháp giảm thiểu trước khi bắt đầu khôi phục. Ví dụ, nếu nguyên nhân của sự cố là do vấn đề bảo mật, hãy khắc phục vấn đề đó trước khi khôi phục các hệ thống bị ảnh hưởng trong môi trường dự phòng của bạn.

  • Nếu bạn cần triển khai lại ứng dụng của mình trong môi trường dự phòng, hãy sử dụng công cụ để tự động hóa quy trình triển khai càng nhiều càng tốt. Đảm bảo rằng Azure Pipelines của bạn được triển khai trước và cấu hình đúng trong môi trường dự phòng để bạn có thể bắt đầu triển khai ngay lập tức. Sử dụng triển khai tự động toàn diện, với các cổng phê duyệt thủ công khi cần thiết, để đảm bảo quy trình triển khai nhất quán và hiệu quả. Khi một giai đoạn nào đó của quy trình triển khai đòi hỏi phải can thiệp thủ công, hãy ghi lại các bước thủ công đó. Xác định rõ ràng vai trò và trách nhiệm.

  • Tự động hóa càng nhiều quy trình càng tốt. Sử dụng logic thử lại để tránh lãng phí thời gian vào các tập lệnh bị kẹt ở một tác vụ bị hỏng. Vì bạn chỉ chạy các tập lệnh này trong trường hợp khẩn cấp nên bạn không muốn các tập lệnh được phát triển không đúng cách gây ra nhiều thiệt hại hơn hoặc làm chậm quá trình phục hồi của bạn.

Lưu ý

Tự động hóa gây ra rủi ro. Người vận hành được đào tạo cần theo dõi chặt chẽ các quy trình tự động và can thiệp nếu bất kỳ quy trình nào gặp sự cố. Để giảm thiểu rủi ro tự động phản ứng với các kết quả dương tính giả, hãy thực hiện các bài tập DR một cách kỹ lưỡng. Kiểm tra tất cả các giai đoạn của kế hoạch. Mô phỏng phát hiện để tạo cảnh báo, sau đó thực hiện toàn bộ quy trình phục hồi.

Tiến hành diễn tập phục hồi thảm họa

Thực hành thử nghiệm DR là điều cần thiết để có một kế hoạch DR tốt. Nhiều ngành công nghiệp có khuôn khổ tuân thủ yêu cầu diễn tập DR thường xuyên. Bất kể bạn làm trong ngành nào, việc thực hành DR thường xuyên đều rất quan trọng cho sự thành công của bạn.

Thực hiện theo các khuyến nghị sau để thực hiện bài tập DR thành công:

  • Thực hiện ít nhất một cuộc khoan DR sản xuất mỗi năm. Các cuộc diễn tập thử hoặc diễn tập ngoài sản xuất giúp đảm bảo rằng các bên liên quan đều nắm rõ vai trò và trách nhiệm của mình. Các cuộc tập trận này cũng giúp người vận hành làm quen với quy trình phục hồi. Nhưng chỉ có các cuộc diễn tập sản xuất mới thực sự kiểm tra được tính hợp lệ của kế hoạch DR và các số liệu RTO và RPO. Sử dụng các bài tập sản xuất để tính thời gian phục hồi cho các thành phần và luồng sản xuất nhằm đảm bảo các mục tiêu RTO và RPO đã xác định cho khối lượng công việc của bạn có thể đạt được. Đối với các chức năng nằm ngoài tầm kiểm soát của bạn, như Microsoft Entra Sự cố ID, hãy đảm bảo rằng các mục tiêu RTO và RPO cho các luồng liên quan đến các chức năng đó có tính đến các sự chậm trễ có thể xảy ra ngoài tầm kiểm soát của bạn.

  • Sử dụng các cuộc diễn tập thử để hướng dẫn người vận hành mới về quy trình và thủ tục DR. Các nhà điều hành cấp cao nên dành thời gian để các nhà điều hành mới thực hiện vai trò của họ và nên chú ý đến các cơ hội cải thiện. Nếu người vận hành mới còn do dự hoặc bối rối ở một bước nào đó trong quy trình, hãy xem lại quy trình đó để đảm bảo rằng nó được viết rõ ràng.

Điểm cần lưu ý

Thực hiện khoan DR trong sản xuất có thể gây ra những sự cố thảm khốc không mong muốn. Hãy chắc chắn kiểm tra các quy trình phục hồi trong môi trường không phải môi trường sản xuất trong lần triển khai ban đầu của bạn.

Hãy dành cho nhóm của bạn nhiều thời gian bảo trì nhất có thể trong quá trình tập luyện. Khi lập kế hoạch cho thời gian bảo trì, hãy sử dụng các số liệu phục hồi mà bạn thu thập được trong quá trình thử nghiệm như thời gian tối thiểu cần thiết phân bổ.

Khi bạn đã thành thạo kỹ thuật khoan DR, bạn sẽ biết được quy trình nào có thể chạy song song và quy trình nào phải chạy theo trình tự. Khi mới bắt đầu luyện tập, hãy cho rằng mọi quy trình phải được thực hiện theo trình tự và bạn cần thêm thời gian ở mỗi bước để xử lý các vấn đề không lường trước.

Khả năng chuyển đổi dự phòng

Microsoft Business Applications cung cấp khả năng duy trì hoạt động kinh doanh và phục hồi sau thảm họa (BCDR) cho tất cả các môi trường sản xuất trong Dynamics 365 và các ứng dụng phần mềm dưới dạng dịch vụ (SAAS). Power Platform Tìm hiểu cách Microsoft đảm bảo dữ liệu sản xuất của bạn có khả năng phục hồi trong thời gian ngừng hoạt động theo khu vực.

Danh sách kiểm tra độ tin cậy

Tham khảo bộ khuyến nghị đầy đủ.

Danh sách kiểm tra độ tin cậy