Лучшие практики или ресурсы для разработки плана аварийного восстановления? [закрыто]

Мне было поручено возглавить проект по обновлению старого и несколько одностороннего плана аварийного восстановления. На данный момент мы просто пытаемся разобраться в ИТ-аспектах DR. В последний раз, когда они это сделали, они установили масштаб, создав одну катастрофу (центр данных затоплен) и спланировав ее, исключая все другие типы катастроф. Я хотел бы использовать более округлый подход. Я знаю, что это решенная проблема, другие организации написали планы DR.

Наш план состоит в том, чтобы взять наш план ИТ-DR и продолжить его и сказать: «Эй, это то, что мы хотим в плане DR для ИТ, совпадает ли это с тем, что делает остальная часть университета? хотели бы поменять? У нас есть довольно хорошая идея, какова остальная часть плана, и мы ожидаем, что это пройдет хорошо.

То, что я ищу, - это руководство о том, как составить план аварийного восстановления и о каких вопросах я должен думать. Есть ли у вас любимые ресурсы, книги, тренинги, связанные с разработкой плана аварийного восстановления?

Отличным источником информации является журнал аварийного восстановления ( о ).

К доступным ресурсам сообщества относится текущий проект документа « Общепринятые практики» (GAP) , в котором содержится отличная схема процесса и результатов, которые составляют надежный план и процесс обеспечения непрерывности бизнеса. Также доступно несколько технических документов, посвященных различным темам DR / BC.

Процесс кажется пугающим, но если подходить систематически с четким описанием того, где вы хотели бы оказаться (например, документ DRJ GAP), вы можете быть уверены, что оптимизируете затраченное время и максимизируете ценность конечного продукта.

Я нахожу их ежеквартальные публикации интересными и информативными ( подписка ).

Убедитесь, что у вас есть список экстренных контактов. иначе список отзыва

Оно должно выглядеть как дерево и показывать, кто с кем связывается. В конце ветки последний человек должен позвонить первому и сообщить о любом, с кем нельзя связаться.

(Это может быть скоординировано через HR, и использовано для любого типа бедствия)

Если мы добавим наши идеи, мы сможем создать хорошую вики из этого поста, как только все добавят свои идеи. Я понимаю, что есть много, чтобы следовать, но у некоторых из нас есть определенные приоритеты, когда дело доходит до восстановления. Для начала вот мой:

Убедитесь, что у вас есть автономная / удаленная документация вашей сети

С DR основные вещи - это ваши RTO (целевые показатели времени восстановления) и RPO (целевые точки восстановления), которые примерно переводятся как «сколько времени приемлемо тратить, чтобы вернуть его, и сколько данных мы можем позволить себе потерять». В идеальном мире ответом будет «никто и ничего», но сценарий DR - исключительное обстоятельство. Этим действительно должны руководствоваться ваши клиенты, но, поскольку вы начинаете с позиции ИТ-специалистов, вы можете делать наилучшие предположения, но будьте готовы скорректировать их по мере необходимости. Хорошая цель - приблизиться к «нет и нет», насколько вы можете разумно получить, но вы должны быть в состоянии распознать, когда наступает точка убывающей отдачи.

Эти два фактора могут быть разными в разное время года и разными в разных системах.

Мне нравится более всесторонний подход; заманчиво перечислить события, которые могут привести к сценарию аварийного восстановления, но на самом деле они больше относятся к анализу риска / снижению риска. С DR инцидент уже произошел, и особенности того, чем он был, менее значимы (за исключением, возможно, с точки зрения влияния на доступность средств DR). Если вы потеряете сервер, вам нужно будет вернуть его обратно, независимо от того, был ли он поражен молнией, случайно отформатирован или что-то еще. Подход, сфокусированный на масштабе и распространении катастрофы, с большей вероятностью даст результаты.

Один из подходов к работе с клиентами, если вы обнаружите, что они не хотят участвовать, - это задать им вопросы DR с точки зрения не-ИТ. Вопрос о том, каковы их планы, если все их бумажные файлы сгорят в огне, является примером здесь. Это может помочь вовлечь их в более широкую область DR, и может добавить полезную информацию в ваши собственные планы.

Наконец, регулярное тестирование вашего плана имеет решающее значение для успеха. Нехорошо иметь красивый план аварийного восстановления, который отлично выглядит на бумаге, но не соответствует его целям.

На самом деле, модель развития «единичного инцидента» - хорошая идея, как первый шаг. Одна из причин заключается в том, что это делает планирование более реалистичным и целенаправленным. Планируйте потоп, все пути. Затем предположим, что произошел другой инцидент (скажем, длительное отключение электроэнергии), примените этот план к нему и исправьте неисправности. После нескольких итераций план должен быть относительно устойчивым.

Одни мысли ... - обязательно учтите недоступных людей. Если есть наводнение, вы не можете предполагать, что весь соответствующий персонал доступен. Кто-то может быть в отпуске, или ранен, или имеет дело со своей семьей.
- планировать проблемы и недостатки общения. Есть несколько номеров и несколько режимов.
- план DR нуждается в цепи командования. Знание того, кто принимает решения, имеет решающее значение.
- план должен быть широко распространен, в том числе вне офиса и вне сети. Он должен быть доступен во время катастрофы!

Там, где я работаю, я принимал участие в проведении масштабного теста DR на каждом из последних двух лет. Мы обнаружили, что тестирование наших сервисов, людей и процессов в «реалистичных» ситуациях было полезным. Некоторые извлеченные уроки (возможно, очевидные), в надежде, что вы найдете их полезными:

• Непроверенные службы, несмотря на то, что они написали в своей документации по DR, обычно имеют неявные, вызывающие катастрофы зависимости. Встряхнуть их с помощью реалистичного теста или двух - это полезный и измеримый результат процесса подготовки DR.
• Непроверенные люди склонны думать, что с их системами все в порядке, и они будут «знать, что делать» в чрезвычайной ситуации. Встряхивания их до реалистичного теста или два велико.
• Непроверенные процессы быстро распадаются в реальных аварийных ситуациях. В частности, сложные процессы эскалации были направлены в основном на информирование руководителей высшего звена захватывающими способами. Легкие процессы, ориентированные на потребности оперативного персонала и других служб реагирования, центральные источники информации о разворачивающейся аварийной ситуации, явной передаче ответственности и «повседневных» процедурах аварийного реагирования работают лучше всего.

Полагаю, я понимаю, что вы должны стараться не делать теоретически все, что связано с процессом планирования аварийного восстановления. Стремитесь к разрешению, чтобы фактически сломать вещи и таким образом получить точные данные о готовности вашей организации. Конечно, это потребует серьезной поддержки со стороны руководства, но может оказаться, что бизнес может потратить пару дней, на самом деле репетируя худшее.

Киан

Существует несколько стандартов из Британского института стандартов (BSi), которые сосредоточены на управлении непрерывностью и аварийном восстановлении.

• BS 25999-1: 2006 Управление непрерывностью бизнеса, часть 1: Свод практических правил
• BS 25999-2: 2007 Управление непрерывностью бизнеса. Спецификация
• BS 25777: 2008 Управление непрерывностью информационных и коммуникационных технологий. Процессуальный кодекс

Это может показаться очевидным, но, следуя вышеприведенной документации, убедитесь, что у вас есть резервные копии (желательно вне региона). Это может быть онлайн-хранилище или место, куда можно записать ленты.

Я говорю предпочтительно из этого региона, потому что я родом из района, где у нас не так много стихийных бедствий ежегодно, но, если / когда у нас они есть, это в региональном масштабе с массовым разрушением (землетрясения, вулканы). Хорошо, чтобы ваша резервная копия находилась в банковском сейфе в банке, пока ваш банк не окажется под жидкой горячей магмой (/ Dr. Evil Voice).

Кое-что из того, о чем я читал, - это то, что агентства распределяют расходы на поддержание популярного сайта, когда большой. Они вводят планы восстановления миссии обеих компаний, критически важных для горячей площадки, с использованием виртуализации и тому подобного, а затем распределяют штат сотрудников на уровне «убедитесь, что все огни мигают». Просто мысль.

Для книг есть « Планирование аварийного восстановления » Джона Уильяма Тойго, которое уже вышло в 3-м издании, а на горизонте - блок 4-го издания (блог + книга).

Лора,

Вот ссылка из SQLServerPedia, которая раскрывает основы DR.

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

Также читайте "Непрерывность бизнеса"