[IT-инфраструктура, Восстановление данных, Облачные сервисы, Резервное копирование] Пусть хоть потоп, но 1С должна работать! Договариваемся с бизнесом о DR

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
17-Сен-2020 13:39

Цитировать

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

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

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

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

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

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

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

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

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

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

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

После обсуждения мы поймем, как расставить приоритеты для точек отказа.
Как сильно защищаем: 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.

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

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

Проблема с доступностью сервисов решилась после переезда в облако. Плюс к этому удалось оптимизировать нагрузку на базы данных за счет балансировки трафика между узлами.
Переехать в катастрофоустойчивое облако
Если нужно, чтобы работе не помешало даже стихийное бедствие на основной площадке, можно выбрать катастрофоустойчивое облако В этом варианте провайдер разносит кластер виртуализации уже на 2 дата-центра. Между дата-центрами происходит постоянная синхронная репликация, один-в-один. Каналы между ЦОДами зарезервированы и идут по разным трассам, так что такому кластеру не страшны проблемы с сетью.
RTO: стремится к 0.
Стоимость: самый дорогой вариант в облаке.
От чего не защитит: Не поможет от порчи данных, а также от человеческого фактора, поэтому параллельно рекомендуется делать бэкапы.
Из практики: Один из наших клиентов разработал комплексный план послеаварийного восстановления. Вот какую стратегию он выбрал:
- Катастрофоустойчивое облако защищает приложение от сбоев на уровне инфраструктуры.
- Двухуровневый бэкап обеспечивает защиту на случай человеческого фактора. Резервные копии делают двух видов: «холодные» и «горячие». «Холодный» бэкап находится в выключенном состоянии, на его развертывание требуется время. «Горячий» бэкап уже готов к работе и восстанавливается быстрее. Его хранят на специально выделенной СХД. Третью копию записывают на ленту и хранят в другом помещении.
Раз в неделю клиент тестирует защиту и проверяет работоспособность всех бэкапов, в том числе с ленты. Ежегодно в компании проводят тестирование всего катастрофоустойчивого облака.
Организовать репликацию на другую площадку
Еще один вариант, как можно избежать глобальных проблем на основной площадке: обеспечить георезервирование. Другими словами, создать резервные виртуальные машины на площадке в другом городе. Для этого подойдут специальные решения для 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 на минималках уже готов.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_vosstanovlenie_dannyh (Восстановление данных), #_oblachnye_servisy (Облачные сервисы), #_rezervnoe_kopirovanie (Резервное копирование), #_dr, #_disaster_recovery, #_disaster_recovery_planning, #_draas, #_rezervnoe_kopirovanie (резервное копирование), #_bekap (бэкап), #_blog_kompanii_dataline (
Блог компании DataLine
), #_itinfrastruktura (
IT-инфраструктура
), #_vosstanovlenie_dannyh (
Восстановление данных
), #_oblachnye_servisy (
Облачные сервисы
), #_rezervnoe_kopirovanie (
Резервное копирование
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 13:16
Часовой пояс: UTC + 5