четверг, 13 мая 2010 г.

Тестирование мер ОНиВД


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

  1. С одной стороны у инициаторов нет склонности к гигантомании в том смысле, что рамки учений охватывают не всю организацию.
  2. С другой стороны учения были достаточно масштабными. Они охватывали около 30 ИТ-сервисов.

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

  • Не оказалось ключей для работы с ПО на резервном рабочем месте;
  • У ряда пользователей на резервных рабочих местах оказалось недостаточно прав доступа для работы с некоторыми директориями;
  • Неверными оказались выданные пользователям пароли для работы на резервных местах.

Какие полезные для всех выводы можно сделать?

  1. При проведении тестирования не стоит рассчитывать, что сразу все пройдет гладко. Предусмотрите время для исправления обнаруженных проблем или поиска обходных путей.
  2. Более того, чем больше недочетов и проблем будет выявлено в ходе тестирования, тем успешнее следует считать тестирование, и тем выше вероятность того, что в случае реальной ЧС восстановиться удастся в установленные сроки.
  3. В первый раз не стоит тестировать сразу все. И во второй раз тоже. И даже в третий раз тестировать восстановление деятельности всей организации не кажется разумной идеей даже если у вас написаны все планы. Лучше двигаться медленно, постепенно включая в рамки тестирования все новые сервисы, процессы и подразделения.


P.S. Следующее тестирование в этой организации намечено через 4 месяца…

Комментариев нет:

Отправить комментарий