Лучшие планы восстановления после катастроф и обеспечения непрерывности бизнеса (disaster recovery and business continuity, DR/BC) охватывают как ИТ, так и бизнес. К сожалению, во многих из них делается упор на ИТ и игнорируются бизнес-операции, пишет президент консалтинговой компании Transworld Data Мэри Шеклет на портале InformationWeek.

Когда приходит большое бедствие, будь то ураган, землетрясение, война или пандемия, организации вспоминают о своих планах DR/BC. Что еще хуже, если бедствие действительно наступило, им приходится приступать к выполнению этих планов.

От DR/BC организации ожидают двух вещей:

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

Мало кто достигает обеих целей сразу. Это нормально, потому что в действительности никто и никогда не желает осуществлять DR/BC.

Однако у многих компаний вызывает озабоченность тот факт, что их DR/BC не актуальны и не всеобъемлющи.

В 2015 г. свыше половины компаний, насчитывающих до 300 сотрудников, полагали, что в плане DR нет необходимости, три четверти не имели страховки для обеспечения BC и только 37% считали обязательным наличие плана DR. Спустя три года, в 2018 г., 75% мелких компаний не имели плана DR. Крупные предприятия подготовлены лучше, но даже у них попытки поддерживать актуальность планов DR по мере изменения бизнеса и условий его ведения могут напоминать сражение.

Поддержание актуальности планов

Достаточно взглянуть на вызванный COVID-19 кризис, чтобы понять, как изменился бизнес.

Больше сотрудников стали работать удаленно. Это означает возросший спрос на Интернет, ресурсы корпоративных сетей и облаков с отказом от центральных офисов и ЦОДов. Мы видим также перенос большего объема ИТ-ресурсов и сервисов в облака и активности бизнеса в онлайновую торговлю.

Эти изменения в процессах ИТ и бизнеса требуют обновления планов DR/BC, чтобы синхронизировать их с потоками работ ИТ и бизнеса.

Усиление защиты и повышение надежности сетей

Переход к удаленным офисам и онлайновой торговле требует прочной безопасности и отказоустойчивости Интернета, сетей и ПО. Этим важнейшим объектам исторически не уделялось внимание в планах DR, которые предназначались для оборудования и ПО ЦОДов.

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

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

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

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

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

Замена сотрудников и проблемы с персоналом

В 2005 г. ураган «Катрина» накрыл Новый Орлеан. Многие компании потеряли все. Тем, кто сумел наладить беспроводную связь, удалось продолжить работу. Но ни одна компания не была готова к ранениям или гибели ключевых сотрудников.

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

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

Следует чем-то компенсировать далекую от оптимальной производительность труда. Как минимум, в плане DR необходимо предусмотреть психологическую помощь сотрудникам.

Координация процессов ИТ и бизнеса

Лучшие планы DR/BC охватывают как ИТ, так и бизнес. К сожалению, во многих компаниях делается акцент на ИТ-операциях. Это ошибка.

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

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

Координация коммуникаций

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

Один из банков, в котором такое случилось, тратил основную массу времени на то, чтобы успокоить прессу и клиентов. По-видимому, местные СМИ получили комментарий какого-то кассира о «вышедшей из строя системе». В результате клиенты устремились в банк снимать свои деньги.

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

Работа с поставщиками

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

Прежде чем приобретать продукт или сервис, следует проверить имеющийся у поставщика соответствующий план DR. Есть ли такой план? Как часто он тестируется? Сертифицирован ли он сторонним аудитором или агентством?

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

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