Пусть хоть потоп, но 1С должна работать! Договариваемся с бизнесом о DR

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

Описанная история не фантазия, а собирательное описание пары событий 2020 года. В крупных компаниях на этот случай всегда под рукой план послеаварийного восстановления, или disaster recovery plan (DRP). В корпорациях за него отвечают специалисты по непрерывности бизнеса. Но в средних и небольших компаниях решение таких задач ложится на ИТ-службы. Нужно самому разобраться в бизнес-логике, понять, что и где может упасть, придумать защиту и внедрить.

Здорово, если ИТ-специалисту удается провести переговоры с бизнесом и обсудить необходимость защиты. Но я не раз наблюдал, как компания экономила на решении для disaster recovery (DR), так как считала его избыточным. Когда наступала авария, долгое восстановление грозило убытками, а бизнес оказывался не готов. Можно сколько угодно повторять: А я же говорил, восстанавливать сервисы все равно предстоит ИТ-службе.



С позиции архитектора расскажу, как избежать этой ситуации. В первой части статьи покажу подготовительную работу: как обсуждать с заказчиком три вопроса для выбора инструментов защиты:

• Что защищаем?
  
• От чего защищаем?
  
• Как сильно защищаем?
  

Во второй части поговорим о вариантах ответа на вопрос: чем защищаться. Приведу примеры кейсов, как разные заказчики строят свою защиту.

Что защищаем: выясняем критические бизнес-функции

Лучше начинать подготовку с обсуждения плана послеаварийных действий c бизнес-заказчиком. Тут главная сложность найти общий язык. Заказчика обычно не волнует, как ИТ-решение работает. Его волнует, может ли сервис выполнять бизнес-функции и приносить деньги. Например: если сайт работает, а платежная система лежит, поступлений от клиентов нет, а крайние все равно ИТ-специалисты.

ИТ-специалист может испытывать сложности в таких переговорах по нескольким причинам:

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

Я бы построил разговор так:

1. Объясняем бизнесу, что аварии случаются со всеми, а на восстановление требуется время. Лучше всего продемонстрировать ситуации, как это происходит и какие последствия возможны.
   
2. Показываем, что от ИТ-службы зависит не все, но вы готовы помочь с планом действий в зоне вашей ответственности.
   
3. Просим бизнес-заказчика ответить: если случится апокалипсис, какой процесс нужно восстановить первым? Кто и как в нем участвует?
   
   От бизнеса необходим простой ответ, например: нужно, чтобы колл-центр продолжил регистрировать заявки 24/7.
   
4. Просим одного-двух пользователей системы подробно описать этот процесс.
   Лучше привлечь на помощь аналитика, если в вашей компании такой есть.
   
   Для начала описание может выглядеть так: колл-центр получает заявки по телефону, по почте и через сообщения с сайта. Потом заводит их в 1С через веб-интерфейс, оттуда их забирает производство вот таким способом.
   
5. Затем смотрим, какие аппаратные и программные решения поддерживают процесс. Для комплексной защиты учитываем три уровня:
   
   • приложения и системы внутри площадки (программный уровень),
     
   • саму площадку, где крутятся системы (инфраструктурный уровень),
     
   • сеть (про нее вообще часто забывают).
   
   
6. Выясняем возможные точки отказа: узлы системы, от которых зависит работоспособность сервиса. Отдельно отмечаем узлы, которые поддерживают другие компании: операторы связи, хостинг-провайдеры, дата-центры и так далее.С этим можно возвращаться к бизнес-заказчику для следующего шага.
   

От чего защищаем: риски

Дальше выясняем у бизнес-заказчика, от каких рисков мы защищаемся в первую очередь. Все риски условно поделим на две группы:

• потеря времени из-за простоя сервисов;
  
• потеря данных из-за физических воздействий, человеческого фактора и т.д.
  

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

• Можем ли мы оценить для этого процесса, сколько в деньгах стоит потеря данных и потеря времени?
  
• Какие данные мы не можем потерять?
  
• Где не можем допустить простоя?
  
• Какие события наиболее вероятны и сильнее нам угрожают?
  

После обсуждения мы поймем, как расставить приоритеты для точек отказа.

Как сильно защищаем: RPO и RTO

Когда понятны критические точки отказа, рассчитываем показатели RTO и RPO.

Напомню, что RTO (recovery time objective) это допустимое время с момента аварии и до полного восстановления сервиса. На языке бизнеса это допустимое время простоя. Если мы знаем, сколько денег приносил процесс, то сможем посчитать убытки от каждой минуты простоя и вычислить допустимый убыток.

RPO (recovery point objective) допустимая точка восстановления данных. Она определяет время, за которое мы можем потерять данные. С точки зрения бизнеса, потеря данных может грозить, например, штрафами. Такие потери тоже можно перевести в деньги.



Время восстановления нужно рассчитывать для конечного пользователя: в какой срок он сможет войти в систему. Так что сначала складываем время восстановления всех звеньев цепи. Здесь часто делают ошибку: берут RTO провайдера из SLA, а про остальные слагаемые забывают.

Посмотрим на конкретном примере. Пользователь заходит в 1С, система открывается с ошибкой базы данных. Он обращается к системному администратору. База находится в облаке, сисадмин сообщает о проблеме сервис-провайдеру. Допустим, на все коммуникации уходит 15 минут. В облаке база такого объема восстановится из бэкапа за час, следовательно, RTO на стороне сервис-провайдера час. Но это не окончательный срок, для пользователя к нему прибавились 15 минут на обнаружение проблемы.

Дальше системному администратору надо проверить, что база корректная, подключить ее к 1С и запустить сервисы. На это необходим еще час, значит, RTO на стороне администратора уже 2 часа 15 минут. Пользователю нужно еще 15 минут: залогиниться, проверить, что нужные транзакции появились. 2 часа 30 минут общее время восстановления сервис в этом примере.

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

Чем защищаем: выбираем инструменты для разных рисков

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

Начнем с первой группы рисков: потерь из-за простоев сервиса. Варианты решения для этой задачи должны обеспечивать хороший RTO.

1. Разместить приложение в облаке
   
   Для начала можно просто переехать в облако там вопросы высокой доступности уже продумал провайдер. Хосты виртуализации собраны в кластер, электропитание и сеть зарезервированы, данные хранятся на отказоустойчивых СХД, а сервис-провайдер несет финансовую ответственность за простои.
   
   Например, можно разместить в облаке виртуальную машину с базой данных. Приложение подключится к базе данных снаружи по установленному каналу или из этого же облака. Если возникнут проблемы с одним из серверов кластера, то ВМ перезапустится на соседнем сервере меньше чем за 2 минуты. После этого в ней поднимется СУБД, и через несколько минут база данных станет доступна.
   
   RTO: измеряется в минутах. Прописать эти сроки можно в соглашении с провайдером.
   Стоимость: считаем стоимость ресурсов облака под ваше приложение.
   От чего не защитит: от массовых сбоев на площадке провайдера, например, из-за аварий на уровне города.
   
2. Кластеризовать приложение
   
   Если хочется улучшить RTO, предыдущий вариант можно усилить и сразу разместить в облаке кластеризованное приложение.
   
   Реализовать кластер можно в режиме active-passive или active-active. Создаем несколько ВМ, исходя из требований вендора. Для большей надежности разносим их по разным серверам и СХД. При отказе сервера с одной из БД, резервная нода принимает на себя нагрузку за несколько секунд.
   
   RTO: измеряется в секундах.
   Стоимость: чуть дороже обычного облака, потребуются дополнительные ресурсы для кластеризации.
   От чего не защитит: по-прежнему не защитит от массовых сбоев на площадке. Но локальные сбои будут не такими продолжительными.
   

   Из практики: У компании-ритейлера было несколько информационных систем и сайтов. Все базы данных располагались локально в офисе компании. Ни о каком DR не задумывались, пока офис не остался без электричества несколько раз подряд. Клиенты были недовольны сбоями на сайтах.
   
   Проблема с доступностью сервисов решилась после переезда в облако. Плюс к этому удалось оптимизировать нагрузку на базы данных за счет балансировки трафика между узлами.

3. Переехать в катастрофоустойчивое облако
   
   Если нужно, чтобы работе не помешало даже стихийное бедствие на основной площадке, можно выбрать катастрофоустойчивое облако В этом варианте провайдер разносит кластер виртуализации уже на 2 дата-центра. Между дата-центрами происходит постоянная синхронная репликация, один-в-один. Каналы между ЦОДами зарезервированы и идут по разным трассам, так что такому кластеру не страшны проблемы с сетью.
   
   RTO: стремится к 0.
   Стоимость: самый дорогой вариант в облаке.
   От чего не защитит: Не поможет от порчи данных, а также от человеческого фактора, поэтому параллельно рекомендуется делать бэкапы.
   

   Из практики: Один из наших клиентов разработал комплексный план послеаварийного восстановления. Вот какую стратегию он выбрал:
   
   

   • Катастрофоустойчивое облако защищает приложение от сбоев на уровне инфраструктуры.
     
   • Двухуровневый бэкап обеспечивает защиту на случай человеческого фактора. Резервные копии делают двух видов: холодные и горячие. Холодный бэкап находится в выключенном состоянии, на его развертывание требуется время. Горячий бэкап уже готов к работе и восстанавливается быстрее. Его хранят на специально выделенной СХД. Третью копию записывают на ленту и хранят в другом помещении.
     

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

4. Организовать репликацию на другую площадку
   
   Еще один вариант, как можно избежать глобальных проблем на основной площадке: обеспечить георезервирование. Другими словами, создать резервные виртуальные машины на площадке в другом городе. Для этого подойдут специальные решения для DR: мы в компании используем VMware vCloud Availability (vCAV). С его помощью можно настроить защиту между несколькими площадками облачного провайдера или восстановиться в облако с on-premise площадки. Подробнее о схеме работы с vCAV я уже рассказывал тут.
   
   RPO и RTO: от 5 минут.
   
   Стоимость: дороже первого варианта, но дешевле, чем аппаратная репликация в катастрофоустойчивом облаке. Цена складывается из стоимости лицензии vCAV, платы за администрирование, стоимости ресурсов облака и ресурсов под резерв по модели PAYG (10% от стоимости работающих ресурсов за выключенные ВМ).
   

   Из практики: Клиент держал в нашем облаке в Москве 6 виртуальных машин с разными базами данных. Сначала защиту обеспечивал бэкап: часть резервных копий хранили в облаке в Москве, часть на нашей петербургской площадке. Со временем базы данных выросли в объеме, и восстановление из бэкапа стало требовать больше времени.
   
   К бэкапам добавили репликацию на базе VMware vCloud Availability. Реплики виртуальных машин хранятся на резервной площадке в Санкт-Петербурге и обновляются каждые 5 минут. Если на основной площадке происходит сбой, сотрудники самостоятельно переключаются на реплику виртуальной машины в Санкт-Петербурге и продолжают работу с ней.

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

5. Не забыть про резервное копирование

Все знают, что нужно делать бэкапы, даже если у вас самое крутое катастрофоустойчивое решение. Так что лишь коротко напомню несколько моментов.

Строго говоря, бэкап это не DR. И вот почему:

• Это долго. Если данные измеряются в терабайтах, на восстановление потребуется не один час. Нужно восстановить, назначить сеть, проверить, что включится, посмотреть, что данные в порядке. Так что обеспечить хороший RTO можно, только если данных мало.
  
• Данные могут восстановиться не с первого раза, и нужно заложить время на повторное действие. Например, бывают случаи, когда мы точно не знаем время потери данных. Допустим, потерю заметили в 15.00, а копии делаются каждый час. С 15.00 мы смотрим все точки восстановления: 14:00, 13:00 и так далее. Если система важная, мы стараемся минимизировать возраст точки восстановления. Но если в свежем бэкапе не нашлось нужных данных, берем следующую точку это дополнительное время.
  

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

В итоговом плане послеаварийного восстановления должно быть минимум 2 инструмента:

• Один из вариантов 1-4, который защитит системы от сбоев и падений.
  
• Резервное копирование для защиты данных от потерь.
  

Также стоит позаботиться о резервном канале связи на случай падения основного интернет-провайдера. И вуаля! DR на минималках уже готов.