Послеаварийное восстановление работоспособности сети

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

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

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

В состав оперативного штаба, согласно рекомендациям NIST, входят:

начальники структурных подразделений организации;

начальник отдела защиты информации;

оперативный дежурный (секретарь).

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

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

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

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

мероприятия по анализу повреждений – оценка повреждений, подготовка прогноза восстановления и предложений по активизации Плана восстановления;

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

мероприятия по развертыванию системы по резервному варианту – развертывание аппаратно-программных средств системы с использованием резервных копий данных, находящихся в резервном центре;

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

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

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

План восстановления. Схема после аварийного восстановления сети

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

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

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

возможная причина инцидента;

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

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

примерное время на восстановление работоспособности системы;

предложения по активизации Плана восстановления.

На принятие решения накладываются некоторые серьезные ограничения. Так, решение координатором об активизации Плана восстановления должно быть принято в течение не более 30 минут с момента получения им информации об инциденте. Принятое решение не обсуждается.

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

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

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

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

Мероприятия по восстановлению работоспособности системы в резервном варианте размещения оборудования и персонала

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

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

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

Резервные копии программ хранятся как в центральном помещении организации, так и в резервном центре. Актуализация копий программ производится немедленно после их замены или модернизации в системе.

Возврат к нормальному функционированию системы

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

Решение о деактивации Плана восстановления принимается координатором на основании информации, полученной по результатам анализа ситуации. Принятое решение докладывается руководству организации.

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

Для этих целей, как правило, привлекается тот же персонал, что и для выполнения работ по активации Плана восстановления.

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

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

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

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

Быстрое восстановление работоспособности сетей в распределенных системах управления является весьма актуальной задачей. Ее успешное решение имеет непосредственное отношение к минимизации производственного ущерба, связанного с вынужденным простоем оборудования. Перечень и последовательность процедур, необходимых для восстановления нормального функционирования системы после наступления чрезвычайных обстоятельств, обычно устанавливает «План восстановления функционирования системы», который должен быть подготовлен заранее и утвержден руководством организации, эксплуатирующей любые ОСИС [1].

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

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

Все мероприятия по выполнению плана распределяются по трем этапам:

• этап уведомления/активации плана;
• собственно этап восстановления;
• этап воссоздания системы/деактивации плана.

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

Читайте также: Как отключить аппаратное ускорение в microsoft edge

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

Задачи, решаемые на этапе воссоздания системы/деактивации плана, — полное восстановление нормальной работы системы и деактивация плана восстановления, возврат к нормальному функционированию.

Пренебрежение к организационным и стратегическим решениями в области ИТ-безопасности дает немедленный отрицательный эффект: значительно (в разы) возрастает число компьютерных атак на корпоративные ИТ-системы и случаев взлома систем информационной безопасности компании. Целью хакерской атаки обычно является хищение коммерческой информации и финансовое мошенничество, однако в Москве, по опросам специалистов, эти позиции составляют лишь 3 и 6% от общего числа хакерских атак. Эксперты полагают, что масштабы проблемы намного существеннее, а низкий процент объясняется тем, что современные хакеры искусно скрывают следы. Только в Москве ущерб от электронных мошенников оценивается правоохранительными органами в 12—15 млн долл, в месяц.

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

При разработке плана восстановления, как правило, применяются следующие основные допущения и посылки:

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

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

1) при недоступности аппаратно-программных систем, расположенных в центральном офисе организации, более 6 ч должен быть организован резервный офис с соответствующими ресурсами для восстановления нормального функционирования системы по резервному варианту;
2) все пункты выполнения плана должны быть изложены в соответствующих инструкциях в отделах организации, привлекаемых к реализации плана, причем ревизия документов должна проводиться не реже одного раза в год и модифицироваться по мере необходимости;
3) персонал, ответственный за систему, должен быть заранее обучен выполнять процедуры плана восстановления;
4) все положения плана и практические возможности персонала по его реализации в части восстановления функционирования системы должны проверяться в ходе учений и тренировок не реже одного раза в год.

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

Определяем места, где стоит подстелить соломку

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

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

Читайте также: Как в экселе сделать корень 3 степени

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

1. Составляем список критичных пользовательских ИТ-сервисов

Цель планирования аварийного восстановления — обеспечить оперативное восстановление работы конечного сервиса, который получает пользователь, а не какой-то конкретной железки или программы. Пользователю не важно, работает или сломан его принтер – ему важно может он отпечатать документы или нет. Жаловаться пользователь будет не на то, что в сервере отказал жесткий диск, а на то, что у него не работает «1С-ка» или «почта».

По этой причине первое, что мы делаем – определяем список критичных пользовательских ИТ-сервисов, для которых будем планировать аварийное восстановление. Обычно это:

Электронная почта,
Телефонная связь,
Система управления предприятием,
Совместная работа с документами,
Печать документов,
Доступ в Интернет,
И так далее.

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

2. Определяем точки отказа пользовательских сервисов

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

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

Так, у сервиса «Электронная почта» могут быть следующие точки отказа (включая, но не ограничиваясь):

Серверная ОС,
Серверное почтовое приложение,
Коммутатор ядра,
Электроснабжение,
Внешняя зона DNS,
Попадание в «черные списки»,
Кондиционирование серверной.

Важно! Не надо исключать из точек отказа сверхнадежное оборудование, с которым «точно ничего не случится». Когда (именно когда, а не если) ваша сверхнадежная СХД потеряет все данные, продолжите ли вы смеяться в цирке или нет, будет зависеть только от вашей готовности к этой ситуации.

3. Определяем зависимости точек отказа

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

Для пользовательского сервиса «Электронная почта» зависимости точек отказа могут выглядеть так:

Схема 1. Зависимости точек отказа.

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

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