Как составить проект восстановления

Отказы и сбои IT-инфраструктуры нельзя исключить полностью. После катастрофы работу сервисов нужно восстановить как можно быстрее — тогда убытки бизнеса будут минимальны. Чтобы сотрудники знали, как действовать, и нужные меры были приняты вовремя, разрабатывают план аварийного восстановления (DRP): выбирают технологии Disaster Recovery с учетом потребностей бизнеса и бюджета, назначают ответственных, прописывают порядок действий для предупреждения катастрофы и устранения ее последствий.

Мы составили руководство по разработке плана аварийного восстановления с общими рекомендациями по восстановлению IT-инфраструктуры.

Что такое план аварийного восстановления

План аварийного восстановления — документ, который содержит шаги по устранению последствий аварии и восстановлению данных; список ответственных сотрудников, их роли и обязанности; последовательность действий по защите и восстановлению IT-инфраструктуры.

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

• восстановить IT-инфраструктуру бизнеса после аварии в приемлемые сроки;
• обеспечить работу критически важных функций IT-инфраструктуры во время простоя основного ЦОД;
• сохранить данные компании в нужном объеме.

Для реализации плана аварийного восстановления нужна параллельная IT-инфраструктура — она может использоваться для хранения данных и шаблонов виртуальных машин либо быть второй боевой системой, которая возьмет на себя рабочие задачи на время катастрофы.

Чтобы обеспечить катастрофоустойчивость бизнеса и непрерывность его работы, компания может дублировать IT-сервисы в собственный дата-центр или использовать облачные сервисы, когда Disaster Recovery предоставляется провайдером как услуга.

Что должно быть в плане аварийного восстановления (Disaster Recovery Plan)

Цели плана аварийного восстановления

В качестве целей DRP могут быть указаны:

1. Обучение сотрудников, чтобы они четко понимали порядок действий для быстрого восстановления IT-инфраструктуры — это ключевая цель DRP.
2. Восстановление работы IT-инфраструктуры в нужное время, максимальное сохранение данных.
3. Необходимость соблюдения корпоративных стандартов организации в ходе мероприятий DR.
4. Необходимость финансового контроля, чтобы все принятые меры были рентабельными.
5. Взаимодействие с ключевыми клиентами и прессой в момент катастрофы.

Конкретные цели зависят от целей компании и утверждаются лицами, принимающими решения, то есть руководящим составом.

Факторы риска

В DRP прописывают основные факторы риска для IT-инфраструктуры и те угрозы, что могут возникнуть в процессе аварийного восстановления. Также планируют мероприятия, которые помогут минимизировать риски или исключить их полностью.

Такие мероприятия, как правило, проводят регулярно для оценки состояния IT-инфраструктуры и ее готовности к процедурам аварийного восстановления в случае катастрофы. Это могут быть:

• проверка корректности создания резервных копий;
• проверка качества работы каналов резервной связи;
• контроль наличия нужного оборудования;
• периодическая проверка DRP на соответствие реальному положению дел;
• тестирование резервных инфраструктур.

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

Так может выглядеть список потенциальных угроз для IT-инфраструктуры в DRP

Список критически важных сервисов

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

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

Чем критичнее для бизнеса приложение или сервис, тем раньше должно быть начато аварийное восстановление его работы.

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

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

Система реагирования на сбои

Чтобы работы по аварийному восстановлению системы были начаты вовремя, нужно быстро обнаружить сбой в работе IT-инфраструктуры. Должны быть разработаны процедуры проверки работы пользовательских сервисов. В план может быть внесена периодическая диагностика систем и мониторинг точек отказа важных сервисов и приложений, сообщающий о проблеме раньше пользователей.

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

Распределение ролей и обязанностей между сотрудниками

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

Для всех сотрудников, которые имеют отношение к работе IT-инфраструктуры, должны быть назначены роли и определены обязанности. Выбирают ответственных, чтобы сотрудники знали, к кому обращаться в момент катастрофы. Также назначают заместителей ответственных на случай, если нужные люди не доступны. Важно прописать в плане конкретные данные конкретных людей, а не только названия должностей.

Процесс реализации плана и реагирования на технический сбой

В плане DRP нужно прописать действия команды для восстановления IT-инфраструктуры после катастрофы. Сотрудники должны заниматься восстановлением работы сервисов, оповестить о случившемся нужных членов команды, добиться запуска системы в нужное время.

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

Также в плане прописывают всю важную дополнительную информацию: где хранится документация; что происходит в случае обновления плана; куда обращаться в страховых случаях; кто и как общается с прессой; что делает юридическая группа компании и когда она подключается; когда нужна оценка финансовых рисков и другое.

Каждая задача должна быть максимально конкретной, то есть состоять из точных команд или действий. Например, не просто позвонить ответственному, а позвонить менеджеру Юлии по телефону 8-965-123-45-64 в течение трех минут.

Типовая схема действий после катастрофы

Проконсультироваться по плану аварийного восстановления и решениям для Disaster Recovery

Тестирование плана

Готовый план аварийного восстановления тестируют, чтобы выяснить, сработает он в реальной ситуации аварии или нет.

Существуют различные типы тестов:

1. Проработка действий с командой. Сотрудники устно проходят шаги, указанные в плане, выявляют пробелы и трудные места. Этот вид тестирования помогает команде ознакомиться с планом DR, но его недостаточно для проверки работоспособности плана.
2. Моделирование аварийного сбоя. Имитация катастрофы без прерывания работы IT-инфраструктуры. Включает тестирование оборудования и программного обеспечения, работы персонала, коммуникаций, процедур, резервных сервисов. Результаты анализируют, при необходимости план корректируют.
3. Тестирование в рабочем режиме. Полное прохождение процедур плана аварийного восстановления с отключением основной IT-инфраструктуры. Может быть дорогостоящим и представлять риск для текущих операций.

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

Проконсультироваться о выборе решения.

Планирование аварийного восстановления. Вторая часть

Готовимся к любым падениям

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

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

1. Готовимся быстро обнаруживать сбойные элементы – составляем процедуры локализации

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

• Создаем процедуры проверки работы пользовательских сервисов и точек отказа. В рамках схемы зависимости (статья 1), специалист техподдержки должен иметь возможность провести диагностику работы как пользовательского сервиса, так и точек отказа, от которых зависит его работа.
• Настраиваем мониторинг точек отказа. В некоторых ситуациях он раньше пользователей может сообщить о проблемах. В других – позволит исключить часть точек отказа из списка подозреваемых.
• Определяем правила эскалации. В случае выявления проблем, влияющих на бизнес, – немедленно сообщить дежурному системному администратору. Влияющих на подразделение – провести локализацию (не более 5 минут) и привлечь соответствующих специалистов для восстановления или сообщить дежурному системному администратору, если локализовать причину сбоя не удалось и т.д.
• Проводим обучение специалистов техподдержки, чтобы они понимали роль тех или иных инфраструктурных элементов в работе пользовательских сервисов, владели общими навыками диагностики точек отказа, а также понимали свои цели и задачи и не боялись в случае чего лишний раз побеспокоить старших товарищей.

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

2. Определяем необходимые ресурсы и условия для восстановления

В процессе аварийного восстановления можно выделить четыре этапа:

1. Пользовательский сервис не работает.
2. Пользовательский сервис работает с ограничениями (низкое качество или временное решение).
3. Пользовательский сервис восстановлен в полном объеме, но с деградацией одной или нескольких ИТ-систем и/или отсутствием необходимых резервов.
4. Все ИТ-системы восстановлены, необходимые резервы пополнены.

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

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

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

Записывайте все необходимые ресурсы, привязывайте их к точкам отказа и помечайте, какие из них уже есть у вас, а какие необходимо еще получить.

3. Определяем минимальное гарантируемое время восстановления пользовательского сервиса

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

Самую большую сложность на данном этапе составляет определение гарантированного времени восстановления точки отказа. В процедуре восстановления есть только один маршрут с предсказуемым сроком — когда после небольшого, но достаточного исследования причин сбоя проводится полное восстановление точки отказа. Да, в большинстве случаев исправить ошибку быстрее, чем проводить полное восстановление, но гарантировать какие-либо сроки можно только по второму сценарию и по этой причине ориентироваться мы можем только на него.

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

• Сделать предварительные заготовки для ускорения восстановления.
• Сократить время на исследование инцидентов (увеличивая вероятность потери данных).
• Изменить архитектуру точек отказа для увеличения скорости восстановления.

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

4. Определяем факторы риска процедуры аварийного восстановления и планируем мероприятия по их контролю

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

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

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

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

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

5. Определяем ситуации, выходящие за рамки планирования

Самое сильное негативное влияние на бизнес оказывают не единичные (или последовательные) отказы, к которым технические специалисты готовы в той или иной мере, а форс-мажорные ситуации, приводящие к параллельному падению нескольких одинаковых систем. Пожары, сильные перепады напряжения, вирусные атаки и даже неправомерные действия третьих лиц могут не только нанести сильный урон, но и стать фатальными для бизнеса. В таких ситуациях сложно применять термин «оперативное восстановление», но есть ряд мероприятий, которые позволяют смягчить удар:

• Проработать вопрос резервного копирования данных на случай форс-мажорных обстоятельств. Местом хранения носителей с резервными копиями должен быть не только офис компании, но и, например, банковская ячейка. Если у компании есть несколько локаций – можно предусмотреть перекрестное резервное копирование.
• Определить приоритетность восстановления пользовательских сервисов. Всегда есть что-то единственное, без чего бизнес не выживет – все остальное подождет.
• Обезопасить резервы от влияния форс-мажорных факторов. Если резервы укомплектованы в полном объеме, то как минимум один сервис вы на них запустите.
• Подготовить (ну или хотя бы наметить) резервную площадку для развертывания. Хоть в квартире генерального директора – на войне все средства хороши.

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

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

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

Часть 1: habrahabr.ru/post/225719
Часть 3: habrahabr.ru/post/228115

Успехов!

Иван Кормачев
Компания «Департамент ИТ»
www.depit.ru

Автор: Сергей Драгун

Технический эксперт: Сергей Бондаренко

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

Disaster Recovery plan (DRP) — это системный подход, который последовательно описывает действия по восстановлению работоспособности IT-инфраструктуры организации в случае аварийной ситуации. 

Для составления плана в организации проводится анализ бизнес-процессов и формулируются цели Disaster Recovery.

Типы аварий 

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

Природные бедствия

• Пожары.

• Наводнения.

• Землетрясения.

• Пандемия.

Инфраструктурные катастрофы

• Отключение электричества. 

• Пожар или прорыв водопровода.

• Обрушение здания.

• Проникновение злоумышленников на объект и нанесение физического ущерба.

Технологические аварии

• Авария сервера.

• Сбой ПО на локальном сервере. 

• Сбой SaaS-приложения в облаке.

• Потеря данных из-за сбоя или вируса.

• Сбой сетевой инфраструктуры.

• Выход из строя инфраструктуры интернет-провайдера.

Стратегии DRP

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

Локальное восстановление

Так как приложения, системы и данные развернуты on-premise, стратегия восстановления должна предусматривать потерю одного или нескольких компонентов системы.

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

Аварийное восстановление в облаке провайдера 

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

Аварийное восстановление как услуга (DRaaS)

Облачные провайдеры предлагают Disaster Recovery как услугу. По сути, она является горячей резервной площадкой для аварийного восстановления ресурсов. DRaaS использует облако для предоставления пользователям копий приложений из  корпоративного дата-центра. За счет этого организации быстрее реагируют и восстанавливают критически важные приложения.

Аварийное восстановление за счет виртуализации ресурсов

Виртуализация позволяет быстро развернуть копию виртуальной машины из облака или резервного сервера. 

Что включить в Disaster Recovery Plan

Он должен содержать несколько разделов: 

• описание и цели DRP;

• периодичность тестирования на резервных ресурсах;

• процедуры восстановления и перечень персонала, ответственного за реализацию плана.

Цели и параметры плана аварийного восстановления

Цель DRP — свести к минимуму негативное влияние аварии на работу организации. План может предусматривать как восстановление только базовых параметров, так и полное восстановление работоспособности. 

Перед составлением плана оценивается потенциальное влияние аварии на бизнес. Исходя из этого, определяются приоритеты и задаются параметры для ключевых показателей аварийного восстановления: RTO и RPO. 

RTO (целевое время восстановления) задает период, в течение которого система недоступна после аварии. Он указывается в минутах, часах или сутках. RTO относится к допустимому времени простоя от сбоя до восстановления. Например, организация должна вернуться к работе в течение 4 часов, чтобы избежать ущерба. 

Для определения RTO нужно ответить на вопрос: «Сколько времени займет восстановление после сообщения о сбое бизнес-процесса?»

RPO (целевая точка восстановления) определяет максимальный период, за который данные могут быть утеряны. Например, RPO допускает потерю данных в пределах одного часа. Для достижения этой цели резервное копирование должно выполняться не реже одного раза в час.

Для определения RPO нужно ответить на вопрос: «Какой объем данных может быть потерян без существенного негативного влияния на бизнес организации?»

Затем разрабатываются стратегии восстановления приложений и данных.

Персонал

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

IT-оборудование

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

Кроме того, все прошлые аварии необходимо задокументировать и описать, как они устранялись. 

Процедуры резервного копирования и восстановления

В DRP указывается, как создается резервная копия каждого ресурса данных — где именно, на каких устройствах и в каких папках, а также как IT-отдел должен восстанавливать их из резервных копий.

Размещение ресурсов для аварийного восстановления

Надежный план Disaster Recovery должен предусматривать горячую площадку для аварийного восстановления. По сути, это резервный ЦОД, хранящий копии всех критически важных систем.  Организация переключается на него после отказа основного ЦОДа.

Тестирование плана

Мало составить план — его надо протестировать, чтобы подтвердить соответствие заданным параметрам RTO и RPO, выявить и исправить возможные недостатки. Тестирование необходимо проводить с определенной периодичностью. 

Существуют следующие типы тестирования:

• кабинетные учения;

• проверка отказоустойчивости приложений;

• проверка отказоустойчивости инфраструктуры;

• симуляция нарушения работы в тестовой среде;

• симуляция нарушения работы в среде продакшн.

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

Решения «Корп Софт» для аварийного восстановления

«Корп Софт» предлагает услугу DRaaS — аварийное восстановление как сервис.

В нее входит составление плана аварийного восстановления и его тестирование. Клиент получает резервную инфраструктуру в облаке с настройкой репликации виртуальных серверов и круглосуточной техподдержкой. Кроме DRaaS, «Корп Софт» предоставляет клиентам площадку с вычислительными ресурсами для Disaster Recovery.

Возобновляем работу важнейших служб после катастрофы

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

1. Пересмотр стратегии резервного копирования

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

Администраторам Microsoft Exchange Server или Microsoft SQL Server полезно каждый час делать резервные копии журналов транзакций, чтобы иметь возможность восстановить состояние системы в пределах одного часа до сбоя. Одноэтапные решения копирования полезны, но необходимо уметь вручную реанимировать сервер, если придется восстанавливать данные на другой серверной платформе. Следует еженедельно сохранять по крайней мере одну ленту в удаленном хранилище, а на месте эксплуатации поместить ленты в противопожарный сейф, пригодный для хранения данных. Необходим запасной стример для чтения резервных магнитных лент, иначе можно остаться без накопителей, совместимых с лентой устаревшего формата. В процессе восстановления и подготовки к повторному запуску серверов целесообразно задействовать встроенные возможности Windows Server 2003 и Windows 2000 Server — такие как Microsoft Remote Installation Services (RIS), автономные (offline) папки, Microsoft Volume Shadow Copy Service (VSS) и Windows Server Update Services (WSUS).

2. Подробные списки

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

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

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

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

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

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

3. Схема сети

С помощью такого пакета, как Microsoft Office Visio 2003, следует построить детальные диаграммы всех сетей в организации, в том числе локальной сети и территориальнораспределенных сетей (WAN).

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

Диаграмма WAN. Если в компании есть WAN, то на схеме должны быть показаны все места расположения узлов сети, как в диаграмме на рис. 2. Если используется VPN, то на диаграмме нужно указать IP-адрес, модель, серийный номер и версию программного обеспечения для брандмауэров; выбираемый по умолчанию шлюз WAN; политики VPN; локальную IP-подсеть. Также следует документировать конфигурацию (конфигурации) брандмауэра как в электронном, так и в бумажном виде. Если в компании используется ретрансляция пакетов, то обязательно документировать все конфигурации маршрутизатора в электронной и бумажной форме. Следует записать все идентификаторы Data Link Connection Identifier (DLCI) и информацию о каналах. На диаграмме также указывается информация об операторе услуг связи, в том числе название, номер телефона службы технической поддержки, номер договора и ID канала связи.

4. Беспроводная сеть

Если в результате аварии предприятие лишается возможности работать в обычном месте, то беспроводное оборудование поможет быстро восстановить сеть. Следует приобретать оборудование, совместимое со стандартом безопасности Wi-Fi Protected Access (WPA2), так как на новом месте развертывания, скорее всего, не будет инфраструктуры для полноценной аутентификации по методу Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).

5. Назначение администратора, ответственного за послеаварийное восстановление

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

6. Организация групп

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

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

Группа офисного помещения/логистики — помогает администратору восстановления в поисках временного офисного помещения в случае катастрофы четвертого уровня. Члены группы отвечают за транспортировку других сотрудников и оборудования во временный офис и имеют право заключать договоры с транспортными компаниями и рабочими при необходимости переезда на временную территорию.

Группа сотрудников — контролирует деятельность сотрудников, в частности планирование рабочего времени, оплату труда и перемещение сотрудников.

Технологическая группа — заказывает оборудование для замены испорченного и восстанавливает компьютерные системы; восстанавливает телефонную связь, соединения Internet и VPN.

Группа связи с общественностью — сообщает партнерам о предполагаемом времени возобновления нормальной работы предприятия и изменяет расписание частных встреч.

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

Группа офисного снабжения — заказывает новую мебель, офисные материалы и формы, необходимые для возобновления нормальной работы.

7. Построение Web-узла на время восстановления

Целесообразно создать Web-узел, на котором сотрудники, поставщики и потребители смогут получить своевременную информацию о компании после катастрофы. Зеркальную копию этого Web-узла следует разместить в географически удаленной точке. Группа восстановления должна публиковать на Web-узле оценки ущерба для производственных площадок, данные о состоянии каждой площадки и время и место выхода сотрудников на работу. На Web-узле нужно предусмотреть интерфейс, через который администратор восстановления сможет публиковать сообщения с временными метками о ходе восстановительных работ. Часть этой информации может быть общедоступной, но доступ к большинству страниц следует защитить процедурой регистрации с сертификатом Secure Sockets Layer (SSL). Сайт должен содержать самый свежий экземпляр плана восстановления в формате PDF.

8. Тестирование плана восстановления

Большинство ИТ-специалистов регулярно сталкивается с авариями первого и второго уровня и умеют быстро реагировать на такие события. В случае катастроф третьего и четвертого уровня в плане восстановления необходимо тщательно организовать и распределить любые доступные ресурсы. Составленный план восстановления требуется регулярно тестировать и модернизировать по мере необходимости. В ходе тестирования нужно моделировать различные ситуации, соответствующие катастрофам с первого по четвертый уровень. Полезно обсудить план с другими ИТ-специалистами, чтобы выяснить, какие меры были эффективными или неэффективными в их планах. Практический опыт ИТ-специалиста, которому пришлось применить свой план спасения компании во время урагана «Чарли», описан в статье «Как пережить ураган», опубликованной в Windows IT Pro/RE № 2 за 2005 год.

9. План восстановления после атаки хакеров

План восстановления должен предусматривать и атаки взломщиков. Некоторые особенности подготовки плана восстановления с учетом атак хакеров приведены во врезке «Готовимся к атаке хакеров».

10. План не должен быть «мертвым» документом

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

Алан Сугано — Президент компании ADS Consulting Group, специализирующейся на сетевых технологиях, программировании, проектировании на базе Microsoft .NET и SQL Server. asugano@adscon.com

«Моментальный снимок» проекта: что делать?

1. Пересмотреть стратегию резервного копирования, чтобы иметь данные для восстановления после катастрофы.
2. Документировать деловые процедуры, оборудование, контакты и приложения.
3. Подготовить схему сетей.
4. Назначить администратора восстановления.
5. Распределить сотрудников по группам восстановления.
6. Регулярно тестировать и обновлять план.

Готовимся к атаке хакеров

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

1. Отключить внешние линии связи. Если есть подозрение, что взломщик проник в сеть, следует отключить все внешние входящие соединения WAN. Если атака исходит из Internet, то отключение внешних линий затруднит хакеру захват других машин и, возможно, помешает завладеть удаленными системами.
2. Проверить беспроводную сеть. Взломщику довольно просто установить беспроводной узел доступа (Access Point — AP) и предпринимать атаки с соседней автостоянки. С помощью беспроводного анализатора, например Airscanner Mobile Sniffer, AirSnort, Airosniff, ApSniff или NetStumbler, можно обнаружить узлы доступа в непосредственной близости от офиса. Анализатор следует заранее установить на портативном компьютере или другом мобильном устройстве и убедиться, что он функционирует успешно. Анализатор должен работать с сетевым адаптером, совместимым со всеми современными беспроводными стандартами (802.11a, 802.11b и 802.11g).
3. Отыскать пораженные системы. Атака может поразить множество компьютеров. Следует обязательно проверить каждую систему, которая потенциально могла подвергнуться нападению. Например, с помощью утилиты Autoruns компании Sysinternals (http://www.sysinternals.com/ntw2k/ freeware/autoruns.shtml) можно обнаружить неизвестные программы, настроенные на автоматический запуск. Кроме того, следует проверить компьютеры на предмет наличия утилит сокрытия вторжения (root kit) и других инструментов взломщиков.
4. Блокировать и удалить учетные записи несанкционированных пользователей. Нужно просмотреть Active Directory (AD) в поисках учетных записей неавторизованных пользователей, чтобы блокировать или удалить их в зависимости от обстановки.
5. Изменить пароли. Необходимо изменить все пароли для каждой учетной записи в сети. Особенно это относится к учетной записи Administrator и учетным записям, используемым для служб на сервере. В целях безопасности стоит использовать 15-символьные парольные фразы.
6. Сохранить данные. Если возможно, стоит приобрести новые жесткие диски для пораженных компьютеров, чтобы сохранить следы взлома на системах. После восстановления сети можно изучить собранные сведения и извлечь ценную информацию об атаке.
7. Идентифицировать и устранить уязвимое место. Часто дать такую рекомендацию легче, чем выполнить ее. В первую очередь следует выяснить, как взломщик проник в сеть. Если брешь не заделана, нападение может повториться.
8. Восстановить систему. Пораженную систему почти невозможно полностью очистить от инструментов взлома; хакеру нужно лишь проникнуть в компьютер. Единственный способ наверняка очистить систему — отформатировать жесткие диски и восстановить ее с нуля. Восстанавливая данные на компьютере, необходимо проявлять осмотрительность, чтобы не восстановить ранее установленные инструменты хакера. Не следует восстанавливать реестр, любые файлы операционной системы или программы с ленты. Все приложения нужно разворачивать вручную, но не с магнитной ленты.
9. Восстановить работу сети. Подключить линии WAN и тщательно контролировать их. Следует убедиться, что ликвидированы все уязвимые места в сети, чтобы взломщик не мог вернуться.
10. Провести криминалистический анализ жестких дисков. После того как сеть вновь начнет работать, полезно установить пораженные диски на автономном компьютере для сбора дополнительной информации о нападении. Взломщики часто подделывают свои IP-адреса, но тем не менее IP-адрес — хорошая отправная точка для поиска источника нападения. Список назначений IP-адресов можно получить из Internet Assigned Numbers Authority (IANA) по адресу http://www.iana.org. Следует документировать все инструменты взлома, обнаруженные в компьютере. Уличить хакеров очень трудно, особенно если они скрывают следы. Часто хакера требуется захватить во время нападения. Задачу выслеживания взломщиков можно поручить специализированным организациям.
11. Известить правоохранительные органы. В большинстве правоохранительных органов имеются группы расследования компьютерных преступлений. Никто не любит признаваться, что подвергся нападению, но известить компетентные органы — первый шаг к тому, чтобы помешать взломщику причинить дальнейший вред. Чем больше будет собрано информации об атаке, тем выше вероятность, что соответствующие органы поймают преступника.

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