Что такое rpo допустимая точка восстановления
Пусть хоть потоп, но 1С должна работать! Договариваемся с бизнесом о DR
Как обсудить с бизнесом защиту информационных систем от аварий.
Представьте себе: вы обслуживаете ИТ-инфраструктуру крупного торгового центра. В городе начинается ливень. Потоки дождя прорывают крышу, вода заполняет торговые помещения по щиколотку. Надеемся, что ваша серверная не в подвале, иначе проблем не избежать.
Описанная история — не фантазия, а собирательное описание пары событий 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.
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. И вот почему:
При этом расписание резервного копирования может обеспечить нужный RPO. Для бэкапов важно предусмотреть георезервирование на случай проблем с основной площадкой. Часть резервных копий рекомендуется хранить отдельно.
В итоговом плане послеаварийного восстановления должно быть минимум 2 инструмента:
Также стоит позаботиться о резервном канале связи на случай падения основного интернет-провайдера. И — вуаля! — DR на минималках уже готов.
Облачные сервисы для самостоятельного восстановления вашей ИТ-инфраструктуры после глобальных сбоев и форс-мажоров.
Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA
Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных и\или аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:
Начнем «от печки», то есть с прямой линии вдоль оси времени, где:
Ясно, что все системы в компании работают не просто так, а для различных нужд/целей. Сама же компания зарабатывает (и тратит) деньги. В случае сбоя системы компания, очевидно, деньги теряет. Показатели RTO и RPO – то, что говорит о приемлемых размерах этих потерь.
Из такого графика уже видно, что стоимость простоя сервиса растет со временем: чем дольше не работает система, тем больше денег теряет компания.
Тоже самое и со стоимостью потерь данных: чем больше мы их (в исторической перспективе) теряем, тем дороже такая потеря обойдется компании. И да, эти графики в живой природе не симметричны.
Как правило, эти стоимости меняются не линейно, что отражено на картинке. Чаще всего наступает момент, когда стоимость потери начинает резко возрастать – отсюда и те самые печальные истории, когда компании теряли так много от сбоя системы, что некоторые даже не смогли вернуться в бизнес.
Чтобы защититься от таких проблем, необходимо внедрить систему, которая будет обеспечивать защиту от потерь данных и восстановление после сбоев. Такие системы имеют свои стоимости, и, значит, их тоже можно отразить на графике (нарисуем их синим):
Как видно из графика, чем меньше показатели RPO и RTO при потере данных, чем меньшее время простоя сервиса обеспечивает решение по защите, тем дороже такая защита стоит.
Определим точки безубыточности решения по защите
И тут мы наблюдаем пересечение кривых на графике – я отметил эти точки зелеными стрелками. Это так называемые точки безубыточности для системы защиты и для защищаемой информационной системы. Отдаляясь от данной точки, мы получаем дорогую систему защиты, стоимость которой превышает стоимость потери/простоя, либо наоборот – дешевую систему защиты, но не обеспечивающую приемлемый уровень потерь.
Как кажется, вывод напрашивается сам собой: именно ориентируясь на точки безубыточности, и надо подбирать системы, которые обеспечат нам необходимую защиту.
На самом деле, если мы построим такие графики, ориентируясь на данные из реальной жизни, то получим несколько иную картину. В частности, график стоимости решения по защите будет иметь вид не сплошной линии, а множества точек. Различные защитные решения не выстраиваются вплотную друг за другом вдоль графика, а представляют собой отдельные точки, ведь каждое имеет свои «координаты»: стоимость (обозначенная вендором-производителем данного решения) и время обеспечения этим решением соответствующих потерь данных (RPO) и скорости восстановления работоспособности (RTO).
К тому же, как правило, ищется решение по защите не одной конкретной информационной системы (ИС), а группы (или вообще всех) инфосистем компании (то есть всей инфраструктуры). При этом каждое такое решение, скорее всего, будет иметь свои графики зависимостей стоимости простоя/потери данных от времени.
Получается, что наши точки безубыточности – уже не точки, а области:
Если мы рассмотрим нашу инфраструктуру более пристально и начнем строить графики для каждой ИС, то мы увидим интересную тенденцию — системы группируются со схожими. Об этом ниже.
Рассматриваем различные классы решений
Обратите внимание, до сего момента я говорил про «защиту», но не оговаривал, что это за защита конкретно: резервное копирование, кластер, какие-то еще виды защиты? Тут стоит сказать, что системы защиты бывают разные, и их можно классифицировать.
На схеме ниже видно, какой примерно класс решения в зависимости от целевых RTO/RPO рекомендуется выбирать.
Конечно, на картинке всё изображено достаточно схематично. На самом деле нет четких границ между типами решений, как и точных значений в виде точек.
Например, сейчас многие решения по резервному копированию используют технологию запуска сервиса из резервной копии. Время обеспечения доступности при использовании такой технологии — в среднем
2-5 минут на одну ВМ. И такие показатели находятся в рамках RTO для реплик или даже кластеров.
Немного о кластерах
Кластеры, как и DR-решения (и вообще практически все решения по защите от потерь данных или восстановлению работоспособности) имеют свои значения по скорости восстановления данных и объемам данных, которые теряются. Потому они также связаны со своими показателями RTO/RPO.
Говоря, например, про HA-кластер (HA – High Availability), имеем в виду, что его RTO равно времени переключения. Допустим, MSCS для двух нод переключает СУБД за 30 секунд. Значит, целевое RTO, которое можно обеспечить этим видом кластера — от 30 секунд.
А если рассмотреть VMware HA, которое отработает за 2 минуты (с учетом старта виртуальной машины, ее гостевой ОС и приложений)? Значит, такое решение подходит для приложений с целевым значением RTO от 2 минут.
Где же потери для HA-кластера (и соответственно, обеспечение RPO), спросите вы? Когда сервис поднимается, есть вероятность небольших потерь данных. Например, если СУБД проверит состояние базы данных и может откатить своё состояние на некорректно проведенную транзакцию. Или если файловая система вернется к некорректно сохраненной версии файла, и т.д., и т.п.
Вывод: не всегда стоит строить одинаковые решения одно поверх другого, например, HA над HA. Это только излишне усложнит инфраструктуру, усложнит (и удорожает) поддержку работы таких систем.
К предыдущим примерам двух HA. Определите, какое реальное значение RTO необходимо обеспечить для приложения? Для значений больше 2 минут нет смысла стоить еще и HA-кластер для сервисов внутри ВМ.
Обратим внимание еще на ряд факторов:
К примеру, резервное копирование почтового сервера не исключает, но дополняет использование кластера HA для почтовых серверов. Кластер защищает от выхода из строя физического сервера и обеспечивает быстрое переключение на резервный сервер. Но кластер не защищает от потери данных (нежелательного удаленных данных, невозможности запуска ВМ после сбоя оборудования и т.п.). Для этого необходимо применение резервного копирования.
Что при этом дает совместное использование VMware vSphere HA? Быстрое восстановление уровня защиты. Если просто выключился один сервер с одной нодой MS Exchange, то вначале отработает DAG, переключив сервисы на другую ноду, а затем HA VMware загрузит сбойный сервер на другом плече своего кластера. И система готова к работе. (Хотя в этом примере я бы рассматривал применение виртуализации не только для одной функции только кластера, но и для всех остальных преимуществ самой платформы).
Говорим и пишем правильно! Или еще раз про RTO и RPO
Хочу сделать на этом акцент, поскольку я сам периодически совершаю ошибку, потому и остерегаю от этого вас:
RTO ≠ скорость восстановления!
RPO ≠ количество потерянных данных!
RTO и RPO – это целевые значения для информационных систем (ИС), максимальные рамки, в которые мы должны уложиться. И эти целевые значения нам, ИТ-специалистам, сообщает бизнес, точнее, бизнес-владельцы соответствующей ИС, но не наоборот.
То есть:
Нельзя сказать, что RTO функции Instant Recovery – 2 минуты.
Нельзя считать, что резервное копирование раз в сутки и есть RPO 24 часа.
Всё идет в обратную сторону, то есть от бизнеса, и конкретно для RTO будет озвучиваться так:
Для определенного сервиса, в случае сбоя обслуживающей этот сервис системы, необходимо обеспечить восстановление, не допустив простоя в работе этого сервиса более 5 минут (RTO – 5 минут). Значит, подойдет решение, которое позволит сделать систему доступной за срок менее 5 минут.
Для базы данных, в случае сбоя СУБД, нужно обеспечить восстановление с допустимой потерей данных сроком не более 24 часов от момента сбоя. Значит, подойдет решение, которое обеспечит гарантированное восстановление базы из точек восстановления, производимых чаще, чем 1 раз в сутки. При этом отмечу, что резервное копирование раз в час, создающее 24 точки восстановления, дает больше гарантий восстановления, чем копирование раз в сутки, делающее только 1 точку.
А вот и практический пример
Казалось бы, можно рассуждать так:
«Применение функции Instant Recovery обеспечит технический процесс восстановления в 2 минуты. »
Но! При этом надо понимать еще несколько моментов:
Поэтому рассуждаем дальше:
«У меня настроен мониторинг для этого сервиса, и оповещение сработает и будет замечено за минуту-две (телефон с полученной СМС надо из кармана достать, или почтовый клиент с новым письмом надо открыть). Я сяду за компьютер, пингану сервис, попытаюсь открыть на нем консоль, посмотрю, что там с гипервизором и железом. Проведу первичную реанимацию (попробую перегрузить машину). На все это я потрачу порядка 15 минут. Если не помогут действия по быстрой реанимации — восстановлюсь из резервной копии. Но так как копироваться из бэкапа данные будут еще минут 15-20, то я воспользуюсь Instant VM Recovery за 2 минуты, а затем запущу онлайн перенос данных машины в продакшен.»
Как видим, в 5 минут мы вряд ли укладываемся.
Теперь подумаем, возможно, нужен HA-кластер со временем восстановления 2 минуты? Но и он не обеспечит нам защиту от всех типов сбоев: рестарт машины в BSoD вполне вероятен, диск ВМ — тоже точка отказа, и т.п. Следовательно нужна дополнительная защита. Значит, продолжаем наши рассуждения:
«В случае кластера я восстановлюсь за 2 минуты. А в дополнение я потрачу, как уже прикинул(а), 15+2 минут при восстановлении из резервной копии, всего 2+15+2=19 минут, и 11 минут ещё остаются в запасе.»
В итоге, ваш ответ бизнес-владельцу ИС будет таким:
«ОК. Я обеспечу RTO в 30 минут. Я включу этот сервис в кластер — для обеспечения 5 минутного RTO, и настрою резервное копирование — для защиты от сбоев с более серьёзными последствиями.»
Очень важно! Самый главный совет: после того, как вы согласовали с владельцем ИС конкретные целевые показатели, договорились – обязательно фиксируйте ваши договоренности с ним в письменном виде, подписывайте с ним соглашение об уровне обслуживания (SLA).
Почему мы называем это «концепцией доступности»?
Заметили, что я пишу постоянно «восстановление данных и восстановление работоспособности сервиса»? Чаще всего пишу вместе, в одном предложении. Это две связанные между собой вещи, которые почти всегда не могу жить друг без друга.
Мы восстановили работу сервиса, но при этом потеряли все его данные – это неприемлемо. Мы восстановили БД, но СУБД не запускается, прочитать данные не могут – это неприемлемо. Именно поэтому мы говорим о доступности и данных, и сервисов. Важны и RPO, и RTO – в совокупности они обеспечивают доступность и того, и другого.
Через 15 минут после сбоя восстановлен доступ к сервису с данными за весь предыдущий период работы (до 1 часа включительно) – это всё про общую доступность.
Вот такой вот дуализм 😉 Вместе дуальная пара RTO и RPO является важным показателем в том самом соглашении об уровне обслуживания (Service Level Agreement, или SLA) для конкретной ИС в части обеспечения доступности её сервисов и данных в случае возникновения сбоя. А подписывается соответствующее соглашение, как я говорил выше, между владельцем ИС (заказчиком услуги), и вами, ИТ-отделом (поставщиком услуги).
RPO и RTO: Различия в показателях резервного копирования
Показатели точки восстановления (RPO — Recovery Point Objective) и времени восстановления (RTO — Recovery Time Objective) позволяют организации узнать, какой объем данных она может потерять и как долго её сервисы могут быть недоступны — это ключевые элементы плана резервного копирования и плана аварийного восстановления.
Важно рассмотреть каждый показатель, их роль, способы их вычисления и финансовые последствия, а также способы их включения в различные планы обеспечения устойчивости.
Что такое RTO?
Показатель времени восстановления (RTO) определяет количество времени с момента наступления разрушительного события до момента, когда затронутые ресурсы должны быть полностью работоспособны и готовы поддерживать цели организации.
Когда ресурс выходит из строя, может потребоваться несколько действий, например, замена поврежденных компонентов, перепрограммирование и тестирование, прежде чем ресурс будет снова введен в эксплуатацию и начнется обычный режим работы. Существует обратная зависимость между временем восстановления и затратами, необходимыми для поддержки восстановления. В частности, чем короче RTO по времени, тем больше затраты на восстановление, и наоборот. Поэтому очень важно, чтобы при определении значений RTO участвовали руководители бизнес-подразделений. Они могут захотеть, например, чтобы целевое время восстановления составляло 30 минут, но затраты на достижение этой цели могут оказаться непомерно высокими.
Что такое RPO?
Показатель точки восстановления (RPO) особенно важен, когда речь идет о резервном копировании и восстановлении данных. Организациям — например, банкам, компаниям выпускающим кредитные карты — которые проводят много операций в течение дня, вероятно, потребуется более частое резервное копирование, почти в режиме реального времени, чтобы иметь в наличии самые актуальные критические данные для своих конкретных нужд, доступные для будущих операций. Это означает, что данные не должны сильно устареть с момента последнего резервного копирования, то есть данные должны быть как можно более актуальными. В этом и есть суть RPO, чтобы резервные копии данных были как можно более актуальными.
И здесь мы видим обратную зависимость между значением RPO и затратами на его достижение. Очень короткое RPO, например, от 10 до 30 секунд, означает, что резервное копирование данных должно выполняться очень часто, что требует использования высокоскоростных технологий резервного копирования, таких как зеркалирование или репликация данных, особенно если резервные копии хранятся вне площадки в облаке или другом месте. Добавьте к этому пропускную способность сети, необходимую для передачи больших объемов данных, и затраты могут быть значительными для достижения требуемой доступности данных.
Основные сходства и различия
Оба показателя являются важными элементами, используемыми в планах резервного копирования и восстановления данных. В идеале оба показателя должны быть ключевыми элементами резервного копирования и восстановления, чтобы обеспечить доступность критически важных данных и систем в случае необходимости, особенно после разрушительного события.
Кроме случаев их использования в планах восстановления, на практике они совершенно разные. RTO назначаются после наступления события. RPO используются до наступления события. Впрочем, когда эти два показателя связаны между собой, короткий RTO обычно требует столь же короткого RPO, особенно если речь идет о защите данных. Если мы рассматриваем только резервное копирование и восстановление систем, значения RTO может быть достаточно для определения того, как будет происходить восстановление. Однако если восстанавливаемая система также работает с критическими данными, то обе метрики должны быть согласованы.
Расчет RPO и RTO
Анализ воздействия на бизнес проводится для определения соответствующих значений RTO и RPO. Анализ рисков выявляет критически важные бизнес-процессы и определяет технологии, людей и объекты, необходимые для обеспечения непрерывности бизнеса. Он также может определить финансовые последствия — например, потерю доходов, наложение штрафов — вызванные сбоем.
На основе данных, полученных от руководителей бизнес-подразделений и высшего руководства, определяются числовые значения, которые представляют собой наилучшие сценарии восстановления после сбоев с точки зрения бизнеса. В настоящее время для расчета значений RTO/RPO не существует математических формул. Это исключительно числовые значения времени. Например, RTO для файлов транзакций с менее критическими данными может составлять 24 часа, а также может поддерживать использование оборудования для хранения резервных копий на магнитной ленте.
Как упоминалось ранее, по мере уменьшения численных значений RTO/RPO, затраты на достижение этих показателей, скорее всего, возрастут. Единственный способ определить истинную стоимость — это сначала определить желаемые значения RTO/RPO, а затем провести исследование, чтобы определить, что необходимо для достижения этих показателей, если произойдет сбой. Затем может потребоваться проинформировать руководителей бизнес-подразделений и высшее руководство о дополнительных инвестициях.
Именно здесь могут возникнуть потенциальные конфликты, поскольку если руководство не хочет тратить дополнительные средства для достижения указанных им желаемых показателей, оно должно понимать, что такое решение может повлечь за собой дополнительные риски в случае возникновения сбоев. В идеале, руководство должно быть осведомлено о потенциальных финансовых проблемах и других последствиях события — например, ущерб репутации — до того, как оно примет решение.