Лучшее, что может случиться, — это если результаты того, что я делаю, никогда и никому не пригодятся.

Можно сказать, что я профессиональный параноик: моя задача — разрабатывать планы действий на случай чрезвычайных ситуаций и обучать людей грамотно реагировать в таких случаях. Зачем это нужно? Довольно просто — чтобы в случае непредвиденных ситуаций всегда была страховка.

Вот, например, знаете что будет, если землетрясение уничтожит основной московский ЦОД?

1. Сработает автоматика и перебросит часть сервисов на другие ЦОДы. Всё то, что было active-active, продолжит работу (это базовые функции сети, вроде звонков и SMS).
2. Затем включается базовый сценарий реакции. Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта. Например, из инженера на смене, охранника, системного администратора и так далее. Они бросают все свои текущие дела и занимаются только восстановлением.
3. В течение первых 10 минут «бронзовая» команда восстановления анализирует ситуацию. На 11-й минуте руководитель команды докладывает команде более высокого уровня («серебряной», как правило, не присутствующей на объекте), например, главному инженеру и руководителю подразделения.
4. «Серебряная» команда принимает решение на своём уровне. В нашем случае проблема явно особенно важная, поэтому команда связывается с «золотой» командой — руководителями самого высокого уровня. На принятие решения о том, что ситуация является чрезвычайной, уходит ещё 10 минут (это очень быстро). В течение ещё 5 минут активируются составленные нами планы аварийного восстановления.
5. Руководители «бронзовых» команд собирают людей и идут восстанавливать, что могут, на месте. Параллельно собирается кризисный комитет, включающий известных специалистов, описанных в плане на этот случай.
6. Далее кризисный комитет взаимодействует с HR, PR, безопасниками и другими службами. В частности, совершенно точно PR к этому моменту будет остро нуждаться в информации — абоненты уже полчаса без мобильного интернета, нужно выступить с данными о сроках восстановления.
7. Разворачивается резервная точка. В течение 20-30 минут восстанавливается инфраструктурный слой. Затем идет восстановление СУБД и там, где надо, восстановление из архива с ленты. Далее — восстановление приложений (от получаса до дня).
8. Параллельно в течение первого часа проверяется, как всё переехало.
9. Затем появляются детальные отчёты. План аварийного восстановления заканчивается, и мы снова «засыпаем» до следующей ситуации.

Риски, планы, резервирование

Есть базовые риски (например, остановка дата-центра или пожар в главном офисе), есть известные риски от руководства, есть наш анализ критичности технических систем. Этот список рисков постоянно обновляется, и каждая из угроз должна быть закрыта.

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

Важно понять, что мы не строим отдельные планы на каждый случай. Наши планы нацелены на устранение самой плохой ситуации. В документах есть указания на все стороны участников, просто в зависимости от ситуаций некоторые ветви планов могут быть не использованы. Это значит, что мы не делаем специальный план на случай прилёта агрессивных пришельцев, но команды восстановления смогут работать по веткам «повреждение ЦОДа» и так далее.

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

Кроме того, что мы строим всевозможные планы по восстановлению и резервированию систем, ещё мы же делаем предварительную работу, в частности, инициируем внутри компании проекты по резервированию систем.

Подходы к резервированию

• Load balancing — это географически разнесённые active-active сервисы, если одна точка отключается, вторая продолжает работать. В примере выше балансировка просто перенесла основной функционал сети в другой ЦОД. Это так называемые непрерывные решения.
• Full, Enhanced и Basic DR — это приложения высокой доступности. Класс Basic — это восстановление из бекапа (занимает несколько минут), Enhanced — это уже не бекап, а синхронная репликация, а Full — это репликация на полностью готовую систему, на которую можно переключиться за считанные секунды.
• Best Endeavours — класс, предполагающий наличие выбранного и предустановленного оборудования.

Таблица ниже иллюстрирует процесс присвоения ИТ-приложениям класса восстановления и технических решений по резервированию, в соответствии с RTO (допустимым временем восстановления) и RPO (допустимой точкой возврата).

Распределение классов восстановления и технических решений по резервированию не точно совпадает с приведенной выше таблицей. Эта таблица служит только для пояснения в рамках топика.

Срок жизни плана

Не бывает такого, чтобы мы написали документ, а он лёг «в стол». Планы постоянно меняются, поскольку меняется ситуация. Люди приходят и уходят. Постоянно меняется аппаратная и программная часть системы или услуги. Меняются технологии. Меняется критичность услуги, соответственно, меняются требования ко времени восстановления, и приходится менять техническое решение. То есть, это живой организм.

Пример аварии

Сотрудники уже давно спокойно воспринимают, что мы постоянно проводим как «бумажные» тестирования, вроде «что ты будешь делать, если», так и имитации, когда аварийные ситуации обыгрываются на месте.

Из последних крупных примеров реальных ситуаций: в 2010 году, летом, во время аномальной жары, в основном ЦОД стали отказывать кондиционеры и останавливаться один за другим. Температура внутри ЦОД стала опасно расти.

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

Показательно, что сейчас уже никто не боится внеплановых отключений электропитания и жары в летнее время года. Да, некое «проседание» сервиса будет, но он очень быстро будет «поднят».

Как всё начиналось

На первых этапах к нам относились только как к параноикам.

В 2003-2004 годах тема аварийного восстановления в IT была абсолютно не известна в России (а уж про аварийное восстановление бизнеса как таковое вообще никто не слышал). Развитие пошло от безопасников: инициативные люди в подразделении информбезопасности начали продвигать эту идею. Показывали кучу презентаций, взяли в помощники консультанта, который помогал рисовать и убеждать. Ключевым моментом был пожар у одного из интеграторов, который тогда плотно работал с «ВымпелКомом». После того, как у них сгорел ЦОД, руководство всерьез задумалось. Позвали из Англии специалистов, которые разработали первые политики и стратегии, плюс дали векторы движения.

Одним из первых шагов было введение тотального бекапа. Идея простая: вся информация подлежит резервному копированию. Даже бумажные документы сканируются и также складываются на ленту. Есть схема cross site backup, когда все, что подлежит резервному копированию, также дублируется в резервный ЦОД и там хранится по тем же политикам.

Мы регулярно проводим обучение и проверки работы команд восстановления сервисов — это как учебные тревоги. Проводим курсы, сертифицируем, даём практику. Готовых специалистов на рынке просто нет.

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

Автор: lucas_409

Источник