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

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

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

Разработайте стратегию DR, дополняющую план использования гибридного облака. В марте фирма 451 Research обследовала европейские компании и сообщила, что 80% из них пользуются услугами нескольких облачных провайдеров, но только 66% имеют оформленные планы использования гибридных вычислений. В другом исследовании, проведенном фирмой InvenioIT, дополнительно сообщается, что почти треть компаний не имеет планов DR, а треть компаний, у которых такие планы есть, тем не менее считает себя не готовыми к катастрофам.

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

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

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

Непрерывно обновляйте ваш план DR. ИТ постоянно меняются. Скорость изменений нарастает по мере переноса все большего числа приложений в облака. Перерабатывать план DR, чтобы идти в ногу с изменениями ИТ, нелегко. ИТ-менеджеры скажут вам, что DR имеет первостепенное значение. Но они уступят неотложным требованиям бизнеса и будут заниматься другими важнейшими проектами, так что DR окажется в конце очереди. В прошлом году Шеклетт спросила у руководителей ИТ-подразделений 10 компаний, как часто они изучают, пересматривают и тестируют планы DR. Только один сказал, что это делалось на протяжении последних 12 месяцев. CIO может рискнуть и надеяться, что не случится ничего серьезного. Но при переносе систем в облака задача усложняется.

Тестируйте DR вместе с провайдерами. Недостаточно заключить SLA. Договоры с провайдерами должны включать также ежегодное тестирование DR вместе с провайдером. Один из коллег сообщил Шеклетт, что такое тестирование закончилось неудачей. Речь шла о гибридной модели. Производственная ERP-система работала в ЦОДе компании. В случае ее отказа работа переносилась в облако. Тестирование DR провалилось, хотя в обоих случаях использовалось одинаковое оборудование. Выяснилось, что имелись небольшие различия в версиях ПО, и этого оказалось достаточно. Без тестирования проблема осталась бы не выявленной.

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

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

Поручите вашему ИТ-аудитору выявить уязвимости в плане DR. Аудиторская фирма проведет дополнительную проверку вашего плана DR и предложит вам предпринять какие-то действия совместно с облачными провайдерами.

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

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