Kế hoạch khắc phục thảm họa phát triển tốt nhất hay nguồn lực? [đóng cửa]

Tôi đã được giao nhiệm vụ lãnh đạo một dự án liên quan đến việc cập nhật một kế hoạch khắc phục thảm họa cũ và có phần hơi khó hiểu. Bây giờ chúng tôi chỉ xem xét việc sắp xếp phía IT của DR. Lần cuối cùng họ làm điều này, họ đã đặt phạm vi của mình bằng cách tạo ra một thảm họa duy nhất (trung tâm dữ liệu bị ngập) và lập kế hoạch cho nó để loại trừ tất cả các loại thảm họa khác. Tôi muốn có một cách tiếp cận tròn trịa hơn. Tôi biết đây là một vấn đề được giải quyết, các tổ chức khác đã viết kế hoạch DR.

Kế hoạch của chúng tôi là lên kế hoạch cho DR DR của chúng tôi và tiếp tục với nó và nói "Này, đây là những gì chúng tôi muốn trong kế hoạch DR cho CNTT, nó có phù hợp với những gì phần còn lại của Đại học đang làm không? Bạn có muốn thay đổi không? " Chúng tôi có một ý tưởng khá hay về phần còn lại của kế hoạch là gì và chúng tôi hy vọng điều này sẽ kết thúc tốt đẹp.

Những gì tôi đang tìm kiếm là hướng dẫn về cách phạm vi một kế hoạch DR và ​​những câu hỏi tôi nên suy nghĩ về. Bạn có tài nguyên yêu thích, sách, đào tạo có liên quan đến phát triển kế hoạch DR không?

Một nguồn thông tin tuyệt vời là Tạp chí phục hồi thảm họa ( về ).

Các nguồn lực cộng đồng có sẵn bao gồm dự thảo hiện tại của tài liệu Thực hành được chấp nhận chung (GAP) của họ , trong đó cung cấp một phác thảo tuyệt vời về quy trình và các sản phẩm cung cấp tạo thành một kế hoạch và quy trình kinh doanh vững chắc. Cũng có sẵn là một số trang trắng bao gồm các chủ đề DR / BC khác nhau.

Quá trình này có vẻ khó khăn, nhưng nếu được tiếp cận một cách có hệ thống với một phác thảo tốt về nơi bạn muốn kết thúc (như tài liệu DRJ GAP), bạn có thể đảm bảo rằng bạn tối ưu hóa thời gian đầu tư và tối đa hóa giá trị của sản phẩm cuối cùng.

Tôi thấy ấn phẩm hàng quý của họ cũng thú vị và nhiều thông tin ( đăng ký ).

Hãy chắc chắn rằng bạn có một danh sách liên lạc khẩn cấp. aka một danh sách thu hồi

Nó sẽ trông giống như một cái cây, và cho biết ai liên lạc với ai. Ở cuối một chi nhánh, người cuối cùng nên gọi cho người đầu tiên và báo cáo bất cứ ai không thể liên lạc được.

(Điều này có thể được phối hợp thông qua HR, và được sử dụng cho bất kỳ loại thảm họa nào)

Nếu chúng tôi thêm ý tưởng của mình, chúng tôi có thể tạo một wiki đẹp từ bài đăng này khi mọi người đã thêm ý tưởng của riêng mình. Tôi hiểu rằng có rất nhiều thứ để làm theo, nhưng một số người trong chúng ta có những ưu tiên cụ thể khi nói đến sự phục hồi. Để bắt đầu, đây là của tôi:

Đảm bảo rằng bạn có tài liệu ngoại tuyến / từ xa của mạng của bạn

Với DR, những điều cơ bản là RTO của bạn (Mục tiêu thời gian phục hồi) và RPO (Mục tiêu điểm khôi phục), tạm dịch là "phải mất bao nhiêu thời gian để lấy lại và chúng tôi có thể mất bao nhiêu dữ liệu". Trong một thế giới lý tưởng, câu trả lời sẽ là "không và không", nhưng kịch bản DR là một tình huống đặc biệt. Những điều này thực sự nên được điều khiển bởi khách hàng của bạn, nhưng vì bạn bắt đầu từ góc độ CNTT, bạn có thể đoán đúng nhất, nhưng hãy chuẩn bị để điều chỉnh tăng hoặc giảm theo yêu cầu. Nhằm mục đích gần với "không và không" như bạn có thể nhận được một cách hợp lý là tốt, nhưng bạn sẽ cần có thể nhận ra khi điểm lợi nhuận giảm dần đi vào.

Hai yếu tố này có thể khác nhau vào các thời điểm khác nhau trong năm và khác nhau trên các hệ thống khác nhau.

Tôi thích cách tiếp cận tròn trịa hơn; thật là hấp dẫn khi liệt kê ra các sự kiện có thể dẫn đến một kịch bản DR, nhưng những điều này thực sự thuộc về một bài tập giảm thiểu rủi ro / ananlysis. Với DR, sự cố đã xảy ra và thông tin cụ thể về những gì ít liên quan (ngoại trừ có lẽ ảnh hưởng đến tính khả dụng của các cơ sở DR). Nếu bạn mất một máy chủ, bạn cần lấy lại nó, bất kể nó bị sét đánh, vô tình được định dạng hay bất cứ thứ gì. Một cách tiếp cận tập trung vào quy mô và sự lan rộng của thảm họa có nhiều khả năng mang lại kết quả.

Một cách tiếp cận để sử dụng cho khách hàng, nếu bạn thấy rằng họ không muốn tham gia, là hỏi họ câu hỏi DR từ góc độ không CNTT. Hỏi kế hoạch của họ là gì nếu tất cả các tập tin giấy của họ bốc cháy là một ví dụ ở đây. Điều này có thể giúp họ tham gia nhiều hơn vào điều DR rộng hơn và có thể cung cấp thông tin hữu ích vào các kế hoạch của riêng bạn.

Cuối cùng kiểm tra kế hoạch của bạn thường xuyên là rất quan trọng để thành công. Thật không tốt khi có một kế hoạch DR đẹp mắt trông tuyệt vời trên giấy nhưng điều đó không đáp ứng mục tiêu của nó.

Trên thực tế, mô hình phát triển "sự cố đơn lẻ" là một ý tưởng tốt, là bước đầu tiên. Một lý do là điều đó làm cho bài tập kế hoạch trở nên thực tế và tập trung hơn. Lập kế hoạch cho lũ, tất cả các cách. Sau đó, giả sử một sự cố khác (giả sử, mất điện dài hạn), áp dụng kế hoạch đó cho nó và khắc phục những sự cố. Sau một vài lần lặp lại, kế hoạch sẽ tương đối mạnh mẽ.

Một số suy nghĩ ... - hãy chắc chắn tài khoản cho những người không có sẵn. Nếu có lũ lụt, bạn không thể cho rằng tất cả nhân viên có liên quan đều có sẵn. Ai đó có thể đang đi nghỉ, hoặc bị thương hoặc đối phó với gia đình của họ.
- kế hoạch cho các vấn đề và điểm yếu giao tiếp. Có nhiều số và nhiều chế độ.
- kế hoạch DR cần một chuỗi lệnh. Biết ai đưa ra quyết định là rất quan trọng.
- kế hoạch cần được phân phối rộng rãi, bao gồm cả bên ngoài và ngoài lưới. Nó cần phải được truy cập trong thảm họa!

Ở nơi tôi làm việc, tôi đã tham gia vào việc chạy thử DR quy mô lớn trong mỗi hai năm qua. Chúng tôi đã phát hiện ra rằng thử nghiệm các dịch vụ, con người và quy trình của chúng tôi trong các tình huống "thực tế" là hữu ích. Một số bài học kinh nghiệm (có lẽ rõ ràng), với hy vọng bạn thấy chúng hữu ích:

• Các dịch vụ chưa được kiểm tra, mặc dù những gì họ đã viết trong tài liệu DR của họ, thường có các phụ thuộc ngầm, gây ra thảm họa. Lắc chúng ra bằng một hoặc hai thử nghiệm thực tế là một đầu ra hữu ích và có thể đo lường được của quá trình chuẩn bị DR.
• Những người chưa được kiểm tra có xu hướng nghĩ rằng hệ thống của họ vẫn ổn và họ sẽ "biết phải làm gì" trong tình huống thảm họa. Lắc chúng lên với một hoặc hai bài kiểm tra thực tế là rất tốt.
• Các quy trình chưa được kiểm tra rơi ra nhanh chóng trong các tình huống khẩn cấp thực tế. Cụ thể, các quy trình leo thang phức tạp tập trung chủ yếu vào việc thông báo phá vỡ quản lý cấp trên theo những cách ngoạn mục. Các quy trình nhẹ tập trung vào nhu cầu của nhân viên vận hành và những người phản hồi khác, các nguồn thông tin trung tâm về tình huống khẩn cấp đang diễn ra, chuyển giao trách nhiệm rõ ràng và quy trình ứng phó khẩn cấp 'hàng ngày' hoạt động tốt nhất.

Tôi đoán những gì tôi nhận được là bạn nên cố gắng không biến mọi thứ về quy trình lập kế hoạch DR của bạn thành lý thuyết. Đẩy cho phép để thực sự phá vỡ mọi thứ và do đó có được dữ liệu cứng về sự chuẩn bị của tổ chức của bạn. Điều đó sẽ đòi hỏi một số hỗ trợ nghiêm túc từ quản lý, tất nhiên, nhưng nó có thể tập trung tuyệt vời cho doanh nghiệp để dành một vài ngày thực sự diễn tập cho điều tồi tệ nhất.

Cian

Có một số tiêu chuẩn từ Viện Tiêu chuẩn Anh (BSi) tập trung vào quản lý liên tục và khắc phục thảm họa.

• BS 25999-1: 2006 Quản lý liên tục kinh doanh, Phần 1: Quy tắc thực hành
• BS 25999-2: 2007 Quản lý liên tục kinh doanh. Đặc điểm kỹ thuật
• BS 25777: 2008 Quản lý liên tục công nghệ thông tin và truyền thông. Quy tắc thực hành

Điều này có vẻ hiển nhiên, nhưng để đi cùng với tài liệu ngoại vi ở trên, hãy đảm bảo bạn có các bản sao lưu ngoại vi (tốt nhất là ngoài khu vực). Đây có thể là một dịch vụ lưu trữ trực tuyến hoặc một nơi để lấy băng từ.

Tôi nói tốt nhất là ra khỏi khu vực bởi vì tôi đến từ một khu vực mà chúng ta không có nhiều thiên tai hàng năm, nhưng, nếu / khi chúng ta có một, nó ở quy mô khu vực với sự hủy diệt hàng loạt (động đất, núi lửa). Thật tốt khi có bản sao lưu của bạn trong một hộp ký gửi an toàn tại ngân hàng, cho đến khi ngân hàng của bạn ở dưới dạng magma nóng (/ Tiến sĩ Evil Voice).

Một cái gì đó mà tôi đã đọc là các cơ quan chia sẻ chi phí duy trì một trang web nóng khi trang web lớn xảy ra. Họ ban hành kế hoạch khôi phục nhiệm vụ quan trọng của cả hai công ty đối với trang web nóng bằng cách sử dụng ảo hóa và sau đó chia sẻ nhân sự ở mức độ chắc chắn tất cả các đèn đang nhấp nháy. Chỉ là một ý nghĩ.

Đối với sách có Kế hoạch khắc phục thảm họa của Jon William Toigo, giờ đây là phiên bản thứ 3, với phiên bản thứ 4 (blog + sách) ở đường chân trời.

Laura,

Đây là một liên kết từ SQLServerPedia đưa ra những điều cơ bản về DR.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Cũng đọc lên "Liên tục kinh doanh"