Недавно принимал участие в учениях, которые проводила одна крупная (с числом сотрудников более 1000 человек) организация. Это упражнение проводилось уже не первый раз. Надо отдать должное этой компании — они подходят к такому важному мероприятию в высшей степени правильно. Что я подразумеваю под этими словами?
- С одной стороны у инициаторов нет склонности к гигантомании в том смысле, что рамки учений охватывают не всю организацию.
- С другой стороны учения были достаточно масштабными. Они охватывали около 30 ИТ-сервисов.
Если оглянуться назад, то сложится следующая картина. Подготовка ИТ-инфраструктуры заняла около года. Еще около трех месяцев ушло на то, чтобы написать планы аварийного восстановления (DR планы), что завершилось первым масштабным тестированием. Обращаю внимание читателей на то, что в первый раз тестировалась лишь слаженность технического восстановления, т.е. о непрерывности бизнеса речь не шла. В ходе учений был выявлен ряд недостатков. Причем именно благодаря тому, что эти недочеты были выявлены, прошедшее тестирование следует считать успешным. И лишь спустя еще полгода было проведено тестирование с участием бизнес-подразделений. Как и следовало ожидать, результаты тестирования ИТ-инфраструктуры в этот раз были значительно лучше, чем в предыдущий, и с большим запасом перекрыли установленные бизнесом нормативы. Что же касается тестирования бизнес-процесса, то при его восстановлении возник ряд проблем. Например:
- Не оказалось ключей для работы с ПО на резервном рабочем месте;
- У ряда пользователей на резервных рабочих местах оказалось недостаточно прав доступа для работы с некоторыми директориями;
- Неверными оказались выданные пользователям пароли для работы на резервных местах.
Какие полезные для всех выводы можно сделать?
- При проведении тестирования не стоит рассчитывать, что сразу все пройдет гладко. Предусмотрите время для исправления обнаруженных проблем или поиска обходных путей.
- Более того, чем больше недочетов и проблем будет выявлено в ходе тестирования, тем успешнее следует считать тестирование, и тем выше вероятность того, что в случае реальной ЧС восстановиться удастся в установленные сроки.
- В первый раз не стоит тестировать сразу все. И во второй раз тоже. И даже в третий раз тестировать восстановление деятельности всей организации не кажется разумной идеей даже если у вас написаны все планы. Лучше двигаться медленно, постепенно включая в рамки тестирования все новые сервисы, процессы и подразделения.
P.S. Следующее тестирование в этой организации намечено через 4 месяца…
Комментариев нет:
Отправить комментарий