Поскольку информационные системы и приложения рассеяны по предприятиям и облакам, руководителям ИТ-подразделений приходится пересматривать планы восстановления после катастроф, пишет на портале InformationWeek Мэри Шеклет, президент консалтинговой фирмы Transworld Data.

На протяжении многих лет в обязанности ИТ-подразделений входило составление планов восстановления после катастроф (disaster recovery, DR). Но теперь эти планы должны быть переработаны с учетом возможности выхода из строя периферийных (edge) и облачных сред. Что появилось нового, и как организации пересматривают свои планы?

1. ИТ-подразделения не контролируют периферию

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

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

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

2. Облачные приложения — это дополнительная нагрузка

В 2018 г. компания Rightscale опросила почти 1 тыс. ИТ-специалистов и обнаружила, что в среднем каждая компания использует 4,8 облака.

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

Отсюда вывод: следует включать в план DR каждого облачного провайдера, услугами которого вы пользуетесь. Каковы условия соглашений об уровне обслуживания, касающиеся резервного копирования и восстановления данных? Имеется ли у вас (или вашего провайдера) план на случай выхода облака из строя? Заключили ли вы с провайдером соглашение о ежегодном тестировании приложений, которые вы используете в облаке для аварийного переключения в случае DR?

3. Важность физической безопасности

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

4. В случае катастрофы необходимо сохранить устойчивый обмен информацией

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

Один из клиентов поинтересовался у кассирши, что случилось. А та возьми и ответь: «Все наши компьютеры вышли из строя». Эта информация со скоростью лесного пожара распространилась среди клиентов и была растиражирована в СМИ. В результате многие клиенты поспешили закрыть свои счета.

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

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

5. План DR должен охватывать различные географические точки

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

6. Методику тестирования плана DR следует пересмотреть

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

7. Руководство должно поддерживать план DR не только на словах

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

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

8. Следует обеспечить вовлеченность поставщиков периферийных ИТ и облачных провайдеров в осуществление плана DR

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

9. Избыточность сетей имеет огромное значение

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