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

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

Что такое Disaster Recovery Plan и кому он нужен

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

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

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

Почему бизнес не закладывает риски

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

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

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

«В разработке системы DRP важно использовать принцип Парето: какие 20% усилий нужно приложить, чтобы система работала на 80%, включая все критические функции, в случае плана Б»

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

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

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

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

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

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

«Около 80% разработок не нуждаются в планах Б»

Рассмотрим пример

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

1. База данных клиентов: чувствительная информация о платежах, хранении данных, транзакциях, персональных данных.
2. Процесс продажи: обеспечение непрерывности покупок.

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

1. Зеркало сайта: для обеспечения доступности в случае падения основного сайта.
2. Грамотная проработка облачной инфраструктуры на которой располагается сам сайт.
3. Страница заглушки с телефонным номером, по которому клиенты могут позвонить бесплатно и оформить заказ если все‑таки сайт упал.

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

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

• если ответ “да”, то необходимо описать функционал, который должен остаться доступным. Это позволит IT‑команде на этапе оценки и исполнения задач внедрить его как решение и поддерживать;
• если ответ «нет”, то план Б для этого функционала не требуется. Важно, чтобы не только бизнес ставил перед IT задачу, но и IT‑специалисты сами предусматривали решения для восстановления работоспособности, которые касаются инфраструктурной части.

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

Резюме

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