Итак, план действий на случай катастрофы составлен и доведен до сотрудников. Вы включили в него все необходимые положения: сформировали группу лиц, ответственных за восстановление после аварии, назначили координатора, разработали детальные процедуры и инструкции по восстановлению, а также построили схему вызовов служащих и поставщиков. Не забыты и такие аспекты, как планирование и долгосрочные средства резервного копирования. И что же, теперь остается только поудобнее устроиться в кресле и ждать, когда произойдет сбой и станет ясно, насколько хорошо подготовлена к нему система?
Не будем торопиться. Да, проделана самая трудная часть работы — составлен план восстановления. Но все ли вы предусмотрели? Ответить на этот вопрос можно, проведя тщательное тестирование плана до того, как придется обращаться к нему в реальных условиях.
Конечно, время от времени нужно проверять резервные ленты. Раз в год следует запускать резервный электрогенератор. Но этого недостаточно. Тщательное тестирование плана мероприятий на случай бедствия предполагает испытание всех систем и процессов на предмет их готовности и отказоустойчивости; такое тестирование поможет найти недоработки в плане (а они есть всегда). Кроме того, тестирование позволяет удостовериться в том, что информация, заложенная в план, верна, и совершенствовать план с течением времени так, что он будет оставаться рабочим, действующим документом, а не просто папкой, собирающей пыль на полке.
С чего же начать? Давайте рассмотрим различные уровни программ тестирования плана действий в случае аварии и соответствующий процесс, следование которому в ходе тестирования даст возможность получить максимальную отдачу от испытаний.
Способы тестирования плана восстановления
Существует множество типов катастроф (природные, являющиеся следствием деятельности человека, наиболее типичные и наиболее вероятные, выражающиеся в отказе аппаратных или программных средств). Соответственно существует множество типов и уровней планов мероприятий на случай сбоя — от простых до более сложных (и, как правило, более дорогостоящих). Если вам не доводилось вплотную заниматься проблемами планирования мероприятий по восстановлению после аварийного сбоя, можете начать с простых методов и постепенно усложнять задачу. В итоге вы сможете подготовить рассчитанный на несколько лет процесс, предусматривающий ежегодное проведение полностью интегрированных испытаний плана действий в случае бедствия.
Схема контрольного испытания мероприятий по восстановлению после сбоя. Составьте простой контрольный перечень вопросов и подробно проанализируйте его, дабы удостовериться, что в этот перечень включены все необходимые мероприятия. Список будет чем-то напоминать перечни мероприятий по проверке готовности к ураганам, по которым ежегодно в сезон тропических циклонов сверяют свои действия те, кто живет на побережье Мексиканского залива.
Ваш список может содержать такие, например, элементы: «Генератор работает — проверить», «Топливо для генератора хранится в безопасном месте или доставляется по контракту — проверить», «Ленты для резервного копирования хранятся за пределами рабочей территории — проверить». Это простой процесс, и реализовать его можно с минимальными затратами времени и сил. Данные мероприятия необходимо выполнять вне зависимости от обстоятельств.
Сквозной анализ плана восстановления. Соберите подчиненных и пройдите вместе с ними по всем этапам плана. Это поднимет процедуру проверки на целую ступень. Присутствовать на данном этапе должны все основные действующие лица. Организуйте простое групповое чтение плана — все присутствующие должны иметь представление о его элементах. Кроме того, при такой постановке служащие получают возможность задавать вопросы и комментировать те или иные аспекты плана.
Казалось бы, все просто, но во многих компаниях подобное базовое тестирование не проводится. А между тем важно, чтобы каждый знал, что именно ему делать в аварийном случае. Анализ списков вызова дает возможность убедиться, что они построены логично. Списки поставщиков и другую информацию нужно перепроверять, чтобы в них содержались только актуальные сведения.
Штабные тренировки по плану восстановления после сбоя. Это испытание расширяет границы аналитического теста. Участникам предлагаются ступенчатые сценарии, позволяющие судить о том, как план будет осуществляться в типичных ситуациях. Когда вашим сотрудникам предлагается обсудить, что именно они будут делать в тех или иных обстоятельствах, достоинства и недостатки плана проявляются особенно явно.
Предоставляя сотрудникам такие вводные, вы можете увидеть, как ваш план вписывается в те или иные обстоятельства и насколько он применим в непредвиденных ситуациях. Тренировочные сценарии могут быть простыми, а могут моделировать фактические ситуации. Не стоит разглашать сценарии заранее, ваши подчиненные должны оказываться в неожиданной ситуации. Именно так обрушиваются на нас реальные бедствия.
Посмотрите, что произойдет, когда события будут нарушать ваши планы. В ходе проведения штабных тренировок в некоторых группах я предлагал сотрудникам тянуть жребий: кто-то из них становится жертвой эпидемии и теряет трудоспособность. Так мы выясняли, каким образом воздействует на план неожиданное отсутствие тех или иных специалистов.
Когда сотрудник, прекрасно ориентирующийся в обстановке, внезапно выбывает из строя (что часто происходит в реальности), кто встанет на его место? Имеет ли этот человек доступ ко всем необходимым ресурсам? Ответить на эти вопросы поможет «учебная тревога».
Тестирование технических аспектов плана восстановления после катастрофы. На данном этапе тестирования начинаются интересные вещи. Совещания в конференц-залах отменяются — вы испытываете реальные системы в реальных условиях эксплуатации. Испытания могут принимать самые разнообразные формы: от простого тестирования носителей, на которые производится резервное копирование, до «горячих» переключений рабочих сайтов.
Именно в этот момент выясняется, какие системы могут быть успешно восстановлены в соответствии с зафиксированным на бумаге планом. Техническое тестирование в том или ином объеме проводится почти во всех компаниях, но многие из них могли бы уделять ему гораздо больше внимания. Давайте рассмотрим вопрос о техническом тестировании более подробно и обсудим некоторые рекомендации.
Техническое тестирование плана восстановления после сбоя
Существует два уровня технического тестирования: параллельное тестирование и тестирование с использованием производственной системы. В первом случае резервируется и восстанавливается система, функционирующая параллельно с производственной системой; при этом производственные процессы никоим образом не затрагиваются. Это самый безопасный метод тестирования технических систем.
Однако для его использования требуется, чтобы в организации имелись избыточные серверы или чтобы администрация была готова вкладывать средства в дополнительные серверы. Кроме того, параллельное тестирование не дает стопроцентной гарантии того, что вы сможете восстановить производственную систему.
Тестирование производственной системы предусматривает остановку основной системы с последующей попыткой ее восстановления. Этот тип тестирования известен также под названием «тестирование с полной остановкой». Он дает точное представление о восстанавливаемости системы. Однако данный метод предполагает большие затраты в связи с простоем и к тому же сопряжен с риском: что, если восстановление производственной системы закончится неудачей?
В некоторых ситуациях тестирование производственной системы невозможно, ибо сбой будет равнозначен реальному бедствию и подвергнет опасности чью-то жизнь. Так, некоторые системы, обслуживающие учреждения здравоохранения, государственные органы и оборонные объекты (например, авиадиспетчерские службы) нельзя тестировать «с полной остановкой» из соображений безопасности или в связи с указаниями регулирующих органов.
Подвергать техническому тестированию в рамках проверки плана действий по восстановлению после катастрофы можно многие системы, хотя, как правило, все системы одновременно не испытываются: это слишком рискованно и сложно. В большинстве компаний различные технические тесты проводятся на основе ротации; одно испытание осуществляется раз в квартал или раз в полгода, так что полный цикл испытаний всех технических систем занимает от года до двух. Ниже перечисляется ряд базовых типов тестирования, которые рекомендуется включать в программу технического тестирования плана мероприятий по восстановлению после катастрофы.
Восстановление носителей, на которых производится резервное копирование. Существует два основных способа испытания механизмов резервного копирования и восстановления. Первый предполагает восстановление произвольно выбранных элементов данных — скажем, восстановление нескольких файлов из заданных папок с файлами. При этом проверяется целостность носителей, на которые производится резервное копирование. Такие процедуры нужно выполнять более-менее регулярно, не дожидаясь, когда придет время выполнять реальный тест восстановления после сбоя. Наверняка вам уже доводилось делать это в рамках выполнения своих ежедневных задач, исправляя ошибку незадачливого служащего, который нечаянно удалил с диска тот или иной объект. Однако не ждите, пока представится такая возможность; планируйте эту процедуру в рамках выполняемых еженедельно или ежемесячно просмотров журналов.
Второй тип тестирования предполагает фактическое восстановление целого сервера. В этом случае приходится резервировать все, что вам нужно, и делать это определенным образом. Иногда сервер приходится восстанавливать в заданном порядке (сначала операционная система, потом база данных и далее прикладная программа). Часто сложные программы, такие как SQL Server или Exchange Server, плохо переносят миграцию на новые аппаратные средства или в новую операционную систему.
Восстановление сервера можно осуществлять на двух уровнях сложности: восстановление на существующем аналогичном сервере или «на голом железе», то есть восстановление с чистого листа — с использованием только носителей, на которые производилось резервное копирование. Этот процесс можно несколько упростить посредством дублирования или с помощью программных средств формирования дисковых образов.
Для реализации каждого из упомянутых методов восстановления сервера требуется та или иная программа резервного копирования и серверы резервного копирования. При этом оба упомянутых компонента обнаружат все недостатки вашего плана резервного копирования и выявят дополнительные осложнения при восстановлении. Все эти вещи необходимо распознавать в ходе тестирования, а не после возгорания здания, где располагаются ваши серверы.
Переход на другой ресурс и восстановление размещения. Если вы работаете в среде с избыточностью или в среде с высоким коэффициентом готовности, следует регулярно проверять эту функцию, инициируя операцию переключения на другой ресурс. Позаботьтесь о том, чтобы ваша система не только переключалась на свою резервную копию, но и допускала обратное переключение на основную производственную систему после ликвидации сбоя.
Испытание резервных источников питания (генератор/ИБП). Ни от одной резервной копии и ни от одного избыточного сервера не будет никакого проку, если ваш компьютерный центр не обеспечен электропитанием. Почти все организации оснащены хорошими системами бесперебойного питания, которые представляют собой первую линию обороны, и генераторами для долгосрочного обеспечения питанием на время отключения электросети.
Проверьте, допускают ли имеющиеся системы бесперебойного питания работу с нагрузкой. Аккумуляторы в таких системах обычно рассчитаны на несколько лет эксплуатации. Кроме того, высока вероятность того, что вы постоянно монтируете в стойках дополнительные аппаратные компоненты.
Удостоверьтесь, что ваши системы бесперебойного питания соответствуют требованиям. Они должны обеспечивать работу всего компьютерного центра до тех пор, пока не будут запущены генераторы, или — если у вас нет генератора — пока компьютеры не будут безопасно отключены.
Самый простой способ выполнить этот тест в относительно небольшом компьютерном центре — отключить питание и посмотреть, что будет дальше (но прежде всего заблаговременно подготовиться к простою). В более крупных сетях полезно использовать программные средства мониторинга и тестирования.
Генераторы необходимо регулярно запускать и обслуживать. Опять-таки некоторые относительно крупные системы можно запрограммировать таким образом, чтобы эти операции выполнялись автоматически. Но может быть, вы сочтете нужным форсировать вопрос — отключите питание в здании и посмотрите, насколько быстро генератор примет на себя нагрузку.
Возможно, генератор не следует выключать в течение длительного периода (сутки или больше), дабы проконтролировать расход топлива, рассеяние тепла и выхлопных газов — удостовериться в том, что генератор будет работать в течение долгого времени. После того как на Хьюстон обрушился ураган «Айк», многим местным компаниям на протяжении недель приходилось питать свои системы от генераторов. Наконец, подготовьте достаточный запас топлива для генераторов. Если в критический момент вы не сможете связаться со своим поставщиком горючего, пенять придется только на себя.
«Горячий»/«теплый» узел. Если вы заключили контракт с внешней компанией или планируете задействовать собственные средства для организации восстановления с использованием «горячего» или «теплого» узла, следует регулярно испытывать эти средства. Предоставляющие подобные услуги компании, как правило, позволяют клиентам проводить такие испытания и, по всей вероятности, пойдут вам навстречу, хотя, возможно, возьмут за подобную услугу какую-то плату. Если же внешняя компания возражает против проведения вами испытаний, у вас будут все основания усомниться в том, что она сможет предоставить требуемую услугу.
Стандартное тестирование службы предполагает переключение на узел восстановления и привлечение персонала для обработки комплекта тестовых транзакций. Чем ближе будет тестовая нагрузка к показателям обычных объемов работы, тем большую пользу вы извлечете из испытания.
Не забывайте о кадровой составляющей всех этих планов. Во время выполнения тестов персонал должен быть на месте. Проследите за тем, чтобы каждый сотрудник понимал свою задачу и чтобы члены команды в достаточной степени владели смежными профессиями.
Эксплуатационные испытания. Лучший способ проведения технических испытаний плана восстановления после аварийного сбоя предполагает подключение реальных пользователей, решающих производственные задачи. По возможности к техническим испытаниям должны быть привлечены не только сотрудники ИТ-подразделения. Если программа ограничивается запуском сервера и успешной регистрацией на нем администратора, это еще нельзя назвать настоящим испытанием. Пусть с ним поработают реальные пользователи, и тогда станет ясно, сможет ли сервер взаимодействовать с ними без осложнений.
К числу типичных проблем относятся недостаточная полоса пропускания и мощность процессоров резервных серверов, аутентификация и права пользователей, а также возможности подключения к внешним ресурсам. Если вы — единственный администратор, участвующий в тестировании, некоторые ошибки ускользнут от вашего внимания. Уже то обстоятельство, что вы будете локальным администратором по отношению к серверу (на консоли), лишит вас возможности проанализировать подавляющую часть вопросов, связанных с сетевыми соединениями.
В некоторых сетях подобный риск простоя считается неприемлемым, поэтому вам, возможно, придется собирать группу испытателей-пользователей и готовить набор тестовых данных. Позаботьтесь о том, чтобы группа пользователей была достаточно разнородной (сотрудники отдела продаж, отдела бухгалтерского учета, работники на местах) и ее участники подключались из различных уголков сети, а также чтобы они пользовались различными наборами функций.
Методика тестирования
Определившись с тем, какие именно испытания вы будете проводить и когда, приступайте к планированию тестирования. Плохо спланированные испытания мероприятий по восстановлению в случае аварии сами могут провоцировать катастрофу в ситуации спешки, когда потерявшую работоспособность систему никак не удается вернуть в строй. Отдача от тестирования будет намного выше, если при проведении испытаний вы включите в свою программу следующие этапы.
План. Продумайте, где ваш замысел может дать сбой. Иными словами, подготовьте план мероприятий восстановления после катастрофы для тестирования вашего плана действий в случае восстановления после катастрофы; это в первую очередь относится к жизненно важным приложениям.
Зафиксируйте план на бумаге. Примите во внимание все возможные срывы и отметьте, что именно требуется получить в результате тестирования. Укажите, при каких обстоятельствах вы будете считать испытание успешным и при каких — неудачным. Обычно приходится учитывать целый ряд категорий, и тест нельзя считать просто удачным или неудачным без дальнейшей детализации.
Кроме того, обязательно составьте план возвращения в нормальный режим эксплуатации. Если вы перешли на использование резервного сервера, как и когда вы будете возвращаться к производственному серверу?
Оповещение. Всех пользователей, на работе которых могут отразиться предстоящие испытания, обязательно нужно известить о том, какая система будет испытываться, и как это может повлиять на производительность. Как правило, тестирование выполняется в выходные или поздно ночью — таким образом, простои сводятся к минимуму. Еще одно достоинство такого подхода: в случае отказа какого-либо из компонентов у вас остается время для исправления положения еще до того, как основная масса сотрудников займет свои рабочие места.
Разумеется, в некоторых организациях (таких, как больницы) невозможно выбрать «удобное» время для простоя. Кроме того, в определенных ситуациях тестирование приходится проводить в середине недели, когда представители поставщиков находятся на рабочих местах или когда может возникнуть необходимость в обращении в службу технической поддержки. Если тестирование занимает больше времени, чем предполагалось, или возникают проблемы, затрудняющие работу пользователей, обязательно держите их в курсе хода работ и извещайте о предполагаемом времени возвращения к нормальному режиму эксплуатации.
Выполнение. Выполняйте тестирование в соответствии с планом и при восстановлении систем пользуйтесь его письменной версией. Проходит ли восстановление в соответствии с планом? Имеются ли в этом процессе стадии, не включенные в план или недостаточно хорошо документированные? Вот где добываются и фиксируются базовые знания, которыми может воспользоваться каждый. Здесь мы подходим к следующему этапу.
Запись. Обязательно определите сотрудников, ответственных за запись испытания и его результатов. По возможности подготовьте формат отчета для фиксирования результатов; ситуация, когда по завершении испытаний вам представляют маловразумительные заметки, должна быть исключена.
Документирование тестирования шагов по восстановлению после катастрофы — это один из участков работы, где большинство компаний терпит неудачу. Но если вы не имеете записей о том, что произошло, как вы потом будете учиться на ошибках? И здесь мы переходим к следующему разделу — «разбор полетов».
Разбор и совершенствование. Наступило время тщательно проанализировать испытание и разобраться с тем, что было сделано правильно, где были допущены ошибки и как в дальнейшем добиться более высоких показателей. Тщательный анализ результатов тестирования — самый верный путь к тому, чтобы испытания приносили пользу в будущем.
Обязательно формулируйте вопросы для принятия решения, затем анализируйте эти вопросы и снимайте их. Все это нужно делать по горячим следам, пока в памяти участников еще свежи детали тестирования. Цикл «анализ — совершенствование» и является финальным этапом испытаний; это залог того, что с течением времени ваш план восстановления после сбоя будет становиться все лучше.
Тестирование и еще раз тестирование
Понятно, что при использовании различных конфигураций, систем, приложений, эксплуатируемых к тому же в организациях различных типов, в методику тестирования могут вноситься изменения, которым, что называется, несть числа. Но в конечном итоге общая концепция остается неизменной: тестируйте, еще раз тестируйте, а потом тестируйте снова.
Чем больше испытаний вы проводите, тем выше вероятность того, что в момент настоящей катастрофы вы будете к ней готовы. Ведь, как нам прекрасно известно, вопрос не в том, случится она или не случится, а в том, когда на нас обрушится ураган, когда выйдет из строя важнейшая система или когда судьба нанесет иной удар по вашей организации.
Тони Хаулетт (thowlett@netsecuritysvcs.com) — президент сетевой консалтинговой фирмы Network Security Services. Имеет сертификаты CISSP и CSNA