Мне было поручено возглавить проект по обновлению старого и несколько одностороннего плана аварийного восстановления. На данный момент мы просто пытаемся разобраться с ИТ-стороной аварийного восстановления. В последний раз, когда они сделали это, они определили свой объем, создав единственную аварию (центр обработки данных затоплен) и спланировав ее, исключив все другие типы аварий. Я хотел бы использовать более разносторонний подход. Я знаю, что это решенная проблема, другие организации написали планы аварийного восстановления.
Наш план состоит в том, чтобы взять наш план аварийного восстановления ИТ и продолжить его, сказав: «Эй, это то, что мы хотим от плана аварийного восстановления ИТ, согласовывается ли он с тем, что делает остальная часть университета? Есть ли у вас восстановленные приоритеты обслуживания? хочешь изменить? " У нас есть довольно хорошее представление о том, каков остальной план, и мы ожидаем, что он пройдет успешно.
Я ищу руководство о том, как определить масштаб плана аварийного восстановления и над какими вопросами мне следует подумать. Есть ли у вас любимые ресурсы, книги, тренинги, связанные с разработкой плана аварийного восстановления?
Отличный источник информации - Журнал аварийного восстановления (около).
Доступные ресурсы сообщества включают текущий проект их Общепринятые практики (GAP) документ, в котором подробно описан процесс и результаты, составляющие надежный план и процесс обеспечения непрерывности бизнеса. Также доступны несколько белые бумаги охватывающие различные темы DR / BC.
Этот процесс кажется пугающим, но если к нему систематически подходить с хорошим планом того, где вы хотели бы закончить (например, документ DRJ GAP), вы можете быть уверены, что оптимизируете затраченное время и максимизируете ценность конечного продукта.
Я считаю их ежеквартальные публикации интересными и информативными (подписываться).
Убедитесь, что у вас есть список контактов на случай чрезвычайных ситуаций. он же реестр отзыва
Оно должно выглядеть как дерево и показывать, кто с кем контактирует. В конце ветки последний человек должен позвонить первому и сообщить обо всех, с кем не удалось связаться.
(Это может быть скоординировано через HR и использоваться для любого типа бедствия)
Если мы добавим наши идеи, мы сможем создать красивую вики из этого поста, как только каждый добавит свои собственные идеи. Я понимаю, что впереди еще много людей, но у некоторых из нас есть определенные приоритеты, когда дело доходит до выздоровления. Для начала вот мой:
При аварийном восстановлении основными вещами являются ваши RTO (целевые значения времени восстановления) и RPO (целевые значения точки восстановления), которые примерно переводятся как «сколько времени можно потратить на их восстановление и сколько данных мы можем позволить себе потерять». В идеальном мире ответом будет «нет и нет», но сценарий аварийного восстановления - исключительное обстоятельство. Им действительно должны руководствоваться ваши клиенты, но, поскольку вы начинаете с точки зрения ИТ, вы можете делать лучшие предположения, но будьте готовы к корректировке вверх или вниз по мере необходимости. Стремление к достижению как можно более близкого к разумному уровню «ни одного и ни одного» - это хорошо, но вы должны уметь распознавать момент, когда наступает момент уменьшения отдачи.
Эти два фактора могут быть разными в разное время года и разными в разных системах.
Мне нравится более разносторонний подход; Заманчиво перечислить события, которые могут привести к сценарию аварийного восстановления, но на самом деле они больше относятся к анализу / снижению рисков. С аварийным восстановлением инцидент уже произошел, и детали того, чем он был, менее актуальны (за исключением, возможно, влияния на доступность средств аварийного восстановления). Если вы потеряете сервер, вам необходимо вернуть его, независимо от того, был ли он поражен молнией, случайно отформатирован или что-то еще. Подход, ориентированный на масштаб и распространение бедствия, с большей вероятностью даст результаты.
Один из подходов, который можно использовать для клиентов, если вы обнаружите, что они не хотят участвовать, - это задать им вопросы аварийного восстановления не с точки зрения ИТ. Например, спросить, каковы их планы, если все их бумажные файлы сгорят. Это может помочь вовлечь их в более широкую работу по аварийному восстановлению и внести полезную информацию в ваши собственные планы.
Наконец, решающее значение для успеха имеет регулярное тестирование вашего плана. Плохо иметь красивый план аварийного восстановления, который отлично выглядит на бумаге, но не соответствует его целям.
Собственно, модель развития «единичный инцидент» - хорошая идея в качестве первого шага. Одна из причин заключается в том, что это делает процесс планирования более реалистичным и целенаправленным. Планируйте наводнение полностью. Затем представьте себе другой инцидент (например, длительное отключение электроэнергии), примените к нему этот план и устраните неисправность. После нескольких итераций план должен стать относительно надежным.
Некоторые мысли ... - обязательно учитывать недоступных людей. В случае наводнения нельзя предполагать, что весь соответствующий персонал доступен. Кто-то может быть в отпуске, травмирован или имеет дело со своей семьей.
- план коммуникативных проблем и слабостей. Есть несколько номеров и несколько режимов.
- план аварийного восстановления нуждается в подчинении. Очень важно знать, кто принимает решения.
- план должен быть широко распространен, в том числе вне сети и вне сети. Он должен быть доступен во время бедствия!
Где я работаю, я участвовал в проведении крупномасштабных тестов аварийного восстановления каждый из последних двух лет. Мы обнаружили, что тестирование наших сервисов, людей и процессов в «реальных» ситуациях было полезным. Некоторые извлеченные уроки (возможно, очевидные) в надежде, что они будут вам полезны:
Я думаю, что я имею в виду, что вы не должны делать все, что касается процесса планирования аварийного восстановления, теоретически. Требуйте разрешения, чтобы действительно что-то сломать и таким образом получить достоверные данные о готовности вашей организации. Это, конечно, потребует серьезной поддержки со стороны руководства, но для бизнеса может быть замечательно сосредоточено на том, чтобы потратить пару дней на настоящие репетиции к худшему.
Циан
Есть несколько стандартов из Британский институт стандартов (BSi), которые сосредоточены на управлении непрерывностью и аварийном восстановлении.
Это может показаться очевидным, но, чтобы согласиться с приведенной выше внешней документацией, убедитесь, что у вас есть резервные копии (желательно за пределами региона). Это может быть онлайн-хранилище или место для хранения кассет.
Я говорю, что желательно за пределами региона, потому что я приехал из района, где у нас не так много стихийных бедствий ежегодно, но, если / когда они у нас есть, это будет в региональном масштабе с массовыми разрушениями (землетрясения, вулканы). Хорошо иметь резервную копию в сейфе в банке, пока ваш банк не окажется под жидкой горячей магмой (/ Dr. Evil Voice).
Что-то, о чем я читал, - это то, что агентства разделяют расходы на поддержание популярного сайта на тот случай, когда большой действительно ударит. Они вводят в действие планы по восстановлению критически важных для обеих компаний задач с помощью виртуализации и тому подобного, а затем делятся кадрами на уровне «убедитесь, что все светятся». Просто мысль.
Для книг есть Планирование аварийного восстановления Джон Уильям Тойго, теперь в его третьем издании, с 4-е издание blook (блог + книга) на горизонте.
Лаура,
Вот ссылка из SQLServerPedia, которая дает основы DR.
http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/
Также прочтите «Непрерывность бизнеса»