Как подготовить IT-инфраструктуру к чрезвычайным ситуациям

Статья про сотрудничество между бизнес-подразделениями и IT-отделом, и о том, как строить план на случай чрезвычайных ситуаций и как разработать и реализовать Disaster Recovery Plan (DRP) для бизнеса.

Disaster Recovery Plan (DRP) — это план Б на случай, если что-то в бизнесе пойдет не так. План заранее подготовленный, проработанный с точки зрения как бизнес процессов, так и технологических решений.

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

Важно, чтобы бизнес в равной степени понимал актуальность разработки плана на случай ЧС наравне с IT отделом. Ключевым моментом является диалог и согласованность между этими функциями. Без единого подхода в работе у компании с очень маленькой вероятностью получится выстроить процессы и создать нужные решения в области Disaster Recovery Plan (DRP).

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

При создании бизнеса, нужно понимать, что произойдет, если часть модели сломается. Необходимо иметь план Б. Такой подход нужен как для заказчиков (бизнес-функции, коммерческие отделы), так и для исполнителей (IT-отделы разработки и поддержки).

Так мы сужаем количество вариантов и перестаем фокусироваться на неконтролируемых внешних факторах и начинаем работать над тем, что можем контролировать.

Фокусировка решений в IT-инфраструктуре должна быть направлена на эти критические процессы.

Не нужно создавать план Б для всего, это дорого и неэффективно. Важно понимать, что изменение бизнес-модели требует адаптации решений в IT-инфраструктуре. Это дорогостоящий и долгий процесс, если не фокусироваться на самом критическом участке.

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

Самая большая проблема — это обсуждения DRP решений после возникновения критической ситуации. Это бессмысленно, так как не хватит времени на разработку самого решения, особенно в случае IT-инфраструктуры.

То же самое должно быть и в бизнесе при разработке решений: не просто план Б, за который отвечает IT-команда. Это план, который внедряется на этапе постановки задачи и проработки критериев приемки, когда бизнес совместно с IT решает, нужен ли для конкретного функционала план Б и как он будет выглядеть.

Готов ли бизнес пожертвовать этой сущностью, если случится обвал инфраструктуры?

Важные аспекты:

Возможные элементы DRP решения с разной степенью сложности и стоимости:

Важно начать с самых критичных аспектов бизнеса и самых простых вариантов DRP решений, чтобы у вас был хоть какой-то план Б как можно скорее.

Дополнительные решения могут быть реализованы по мере возможности. Когда заказчик приходит к команде разработки с просьбой внедрить новый функционал, на этапе постановки задачи стоит добавить вопрос: «Является ли этот функционал критичным в случае катастрофы?»

Перейдем к выводам.

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