Неизвестно, когда и в какой форме произойдет следующая авария, но можно быть уверенным, что нам придется столкнуться с этим наверняка. В любой ситуации очень важен цикл обслуживания, связанный с аварийным восстановлением. Компании могут использовать традиционные продукты и процессы аварийного восстановления, аварийное восстановление как службу (DRaaS) или комбинацию различных способов, опыт в любом случае ценен.
Основные поставщики знаний здесь — системные архитекторы, а также профессиональные специалисты по DRaaS. Один из них — мой коллега Дуг Тейс из компании Expedient, отвечающий в нашей лаборатории за размещение многочисленного оборудования. Многие советы, приведенные в данной статье, основаны на опыте, полученном Тейсом при решении проблем клиентов.
1. Авария не считается устраненной, пока не пройдет 10 недель после восстановления
Есть предупреждение, событие переменной продолжительности, последствия и восстановление. А есть подлинное восстановление, которое представляет собой возвращение к нормальному состоянию, каким бы оно ни было. Например, наводнение может уничтожить оборудование, но вместе с ним и дома сотрудников. Цепи поставок нарушаются и восстанавливаются медленно и неравномерно. Даже если работают энергоснабжение и водопровод, возможна нехватка пищи и других ресурсов, пока не возобновятся поставки. В планах необходимо учитывать не только само событие аварии, но и локальное восстановление цепей поставок и логистики. Для этого могут потребоваться недели и месяцы. Важно понимать, что нормальное состояние восстанавливается не сразу после отъезда скорой помощи и спасателей МЧС, а спустя недели.
2. Нормативные акты и требования соответствия никто не отменял
Авторы отчетов и аудиторы могут проявлять снисходительность, но действие нормативных актов распространяется на вас и до, и во время, и после аварии. Может возникнуть соблазн уклониться от строгого исполнения требований в период восстановления после аварии, но на самом деле «нормативных каникул» не существует.
3. Тестирование обязательно
Даже хорошо продуманные планы нуждаются в тестировании. Для тестирования аварийного восстановления требуются время и деньги, но невозможно доказать ценность ресурсов и планирования, не выполнив настоящей проверки. Записи о том, какие меры работают, а какие нет и почему, позволят разобраться во многих вопросах, от которых зависит непрерывность бизнеса. Каждая проверка — новая возможность сгладить последствия будущих аварий.
4. В планирование должны быть вовлечены все подразделения компании
Шансы компаний на выживание после катастрофы повышаются, если каждый сотрудник любого подразделения знает, что необходимо делать до, во время и после события. К сожалению, во многих организациях лишь узкий круг специалистов осведомлен о планах аварийного восстановления, и знание исчезает, когда сотрудник меняет роль или увольняется из компании. Позаботьтесь о полном документировании, целенаправленном распространении (с подтверждением получения) и регулярном обновлении планов восстановления. Этот процесс также требует регулярного обновления ресурсов аварийного восстановления, причем обязательно двойного, в том числе во вспомогательной среде. Выполнение этих процедур в компании должно быть доведено до автоматизма.
5. Аварийное восстановление — все или ничего
Дублирование ресурсов не дает мгновенной защиты. Важнее, что ИТ — лишь один элемент обеспечения непрерывности бизнеса, и планирование аварийного восстановления — задача не только ИТ-специалистов. В действительности если не привлечь все подразделения компании, то в плане неизбежно будут изъяны.
Это объясняется сложностью структуры любой организации, независимо от размера. Если планировщики не составят сценария аварийного восстановления, охватывающего всех сотрудников, процессы, цепи поставок, логистику и продукты, то, скорее всего, когда план будет приведен в действие, в нем обнаружатся пробелы. ИТ-специалисты часто возглавляют аварийное планирование, но все заинтересованные лица должны участвовать в обеспечении непрерывности бизнеса, а ИТ-подразделение — согласовывать мероприятия. Подчеркну, что речь идет не просто о непрерывности ИТ-операций, а всего бизнеса в целом.
6. Восстановление развертывания часто сложнее отработки отказа
Если план не протестирован полностью, то у большинства компаний не будет четкого представления об усилиях, необходимых для восстановления. Тейс отмечает: «Даже если тестирование проведено, сотрудники не всегда понимают, как много времени займет восстановление. Каковы критические точки? Где находится ИТ-персонал, обладающий квалификацией? Обычным моделям аварийного восстановления не уделяют должного внимания. Часто их не тестируют полностью. Их приоритет ниже, чем у других 40 текущих проектов. Такие мероприятия бесполезны».
Когда восстановление развертывания не полностью протестировано или изучено, аварийное восстановление часто требует героических усилий. «Вы действительно хотите выполнять отработку отказа в два часа ночи? Ваша голова ясно работает в это время суток? Вы осознаете все последствия?», — спрашивает Тейс.
Критически важно моделировать реальные циклы, особенно потому, что восстановление развертывания часто бывает сложнее отработки отказа.
7. Синхронизация = успех
Если в компании приложения не синхронизированы, то нередко это обнаруживается в самый неудачный момент. В ходе каждой тренировки по восстановлению развертывания и отработке отказа компаниям следует убедиться, что синхронизация является исчерпывающей и не нарушает транзакций, так что деловая активность не прерывается. Без синхронизации не будут работать ни восстановление развертывания, ни отработка отказа, поскольку нарушено условие работоспособной ИТ-инфраструктуры.
8. Планы обеспечения непрерывности бизнеса не вечны
В компаниях, где предусмотрены собственные процессы аварийного восстановления, возраст планов непрерывности часто достигает пяти лет, и они «пылятся на полке» в дальнем офисе. В наш век стремительно развивающихся технологий и бизнес-требований, не говоря уже о слияниях, поглощениях и прочем, планы необходимо регулярно обновлять, неизменно документируя изменения.
9. Планы определяют зависимости
ИТ-системы большинства компаний делятся на две категории — верхнего уровня и прочие. Учитывать это обстоятельство очень важно при разработке, тестировании и выполнении плана аварийного восстановления. Но многие забывают, из каких элементов состоят эти категории и которая из них верхняя. Очень важно понимать зависимости внутри каждого уровня. Подготовительная работа по выявлению этих зависимостей трудна, но крайне необходима для того, чтобы организовать восстановление размещения и отработку отказа способом, приемлемым для бизнеса и соответствующим плану аварийного восстановления.
10. Человеческий фактор
Обучение персонала и составление доступных планов — критически важные шаги при планировании аварийного восстановления. То же можно сказать и о человеческом факторе. Например, людей, испытывающих трудности при передвижении, возможно, не удастся задействовать в процессе аварийного восстановления. Те, кто сможет участвовать, нуждаются в инструкциях. Сотрудники, сами попавшие в аварийную ситуацию, также нуждаются в сочувствии: им придется работать в условиях стресса. Проявляйте понимание и чуткость друг к другу.