Целевая точка восстановления (RPO) и целевое время восстановления (RTO) дают организациям возможность определять допустимые потери данных и диапазон времени простоя систем. Эти метрики являются основными при разработке планов по хранению данных, резервному копированию и аварийному восстановлению, обеспечению эксплуатационной устойчивости, а также непрерывности бизнеса.
RPO
Целевая точка восстановления, или RPO, обычно выражается в минутах или часах. Для примера давайте возьмём 24-часовой период и представим, что работаем в компании по спасению животных, вроде передержки, которая работает 24/7/365. Там животные проходят первичные ветеринарные осмотры, данные которых хранятся в локальных системах, к которым надо постоянно обращаться в течение дня. Однажды, скажем, в 02:00 у нас произошёл сбой сервера. Предположим, что этот сервер единственный, на нём хранятся все данные организации, и нет избыточности. Это ужасная ситуация, но она слишком распространена среди организаций, испытывающих нехватку средств.
RPO является метрикой того, как много данных организация готова потерять в случае катастрофы или аварии. Она обычно выражается во времени. Если в компании метрика равна 6 часам, значит, нельзя допустить более шести часов потери данных при восстановлении после сбоя сервера.
Различные организации определяют разные значения RPO. Логично, что банки практически не допустят потери данных, поскольку они имеют дело с деньгами клиентов, тогда как интернет-магазины могут допустить некоторую потерю, поскольку, теоретически, они могут воссоздать заказы другими способами.
Давайте рассмотрим такой сценарий всё на том же примере приюта для животных: каждые 6 часов, начиная с 15:00 первого дня, проводятся полные резервные копирования (в 15:00, 21:00, 03:00 и 09:00). Итого 4 копии в течение одних суток. Чтобы восстановить данные с вышедшего из строя сервера нам необходимо восстановить резервную копию. В идеале, если у нас нет сбоев, она будет из последнего бэкапа. Каждая успешная резервная копия представляет собой точку восстановления.
Если используются полные и инкрементные бэкапы, то возможно, что для восстановления одной инкрементной резервной копии (для использования одной точки восстановления) понадобится последний бэкап, и каждая инкрементная копия между полной и последней нормальной инкрементной резервной копией. То есть не исключено, что для точки восстановления понадобится более одной резервной копии.
В сценарии, где сбой сервера произошёл в 02:00, потеря данных будет происходить между 02:00 и самой последней точкой восстановления (в 21:00 предыдущего дня). Это означает пять часов потери данных. Если бы сбой случился сразу после бэкапа в 21:00, потерь практически не было бы. Если бы сбой случился на час позже, в 03:00, потеря данных составила бы 6 часов. Максимальная потеря для этого типа сценария — это время между двумя успешными резервными копиями. В нашем случае, поскольку резервное копирование происходит каждые 6 часов, потеря данных может составлять минимум 0 или максимум 6 часов.
Поэтому, когда организация устанавливает метрику RPO равную 6 часам, в случае технологического сбоя она может допустить потерю данных только в течение максимум 6 часов. Тогда надо убедиться, что резервное копирование происходит минимум каждые 6 часов. Но чтобы справиться со случайным сбоем резервного копирования, нужно, чтобы оно выполнялось чаще, чем требуется. В приведённом примере это может быть раз в 3 часа, или даже каждый час.
Более низкие значения RPO обычно требуют более частого резервного копирования, что приводит к высоким затратам как с точки зрения носителей, так и с точки зрения лицензирования, накладных расходов на управление и других связанных процессов.
Разные организации будут иметь разные RPO, а иногда и RPO разных систем в одной организации будут отличаться друг от друга. У банка может быть очень низкий показатель RPO для своих финансовых систем, но он может терпеть более высокий показатель RPO для своего веб-сайта. Если данные меняются реже, если система менее важна, то бизнесу легче переносить высокие RPO.
Расчёт RPO
Нужно учесть следующее:
масштаб операционных и финансовых потерь в случае аварии;
вероятность аварии;
сколько приложений используют набор данных;
во сколько обойдётся компании стратегия с RPO;
какие уже существуют и работают правила хранения данных.
RTO
Для объяснения, что же означает RTO, обратимся к предыдущему примеру 24-часового периода. На этот раз сбой сервера у нас произошёл в 22:00, а последний бэкап завершился в 21:00, то есть за 1 час до сбоя. Как вы теперь знаете, это означает, что если бэкап успешен, то есть является допустимой точкой восстановления, потеря данных составит 1 час (время между резервным копированием в 21:00 и сбоем сервера в 22:00).
RTO, или целевое время восстановления, — временной диапазон допустимого простоя системы ввиду случившейся катастрофы или аварийного сбоя.
Как и в случае с RPO, у различных компаний будут разные RTO. У банка будет гораздо более низкая метрика для своих банковских систем, чем у кафе для своего веб-сайта. Организация, как правило, будет иметь разные RTO для своих различных систем. Критические системы будут иметь низкие значения RTO, а менее важные — высокие значения.
Если бы у компании по спасению животных RTO составляло 13 часов, это означало бы, что в случае сбоя сервера, произошедшего в 22:00, у ИТ-команды было бы времени максимум до 11 часов следующего дня для полного восстановления работоспособности системы.
Важно! Время восстановления системы начинается в момент сбоя, именно тогда начинается отсчёт времени. И заканчивается он не тогда, когда проблема устранена, а когда система возвращается бизнесу в полностью протестированном состоянии.
Итак, в нашем примере отсчёт времени начинается в 22:00, и чтобы обеспечить RTO в 13 часов, сервер должен снова запуститься на полную мощность в 11:00 следующего дня. Почему это так важно? Дело в том, что RTO — это не только дело техники. Наибольшее влияние на RTO оказывают вещи, которые техническому специалисту не всегда удаётся определить.
Хотя восстановление системы, по идее, начинается в момент её сбоя, в действительности же это происходит только тогда, когда ИТ-команда узнаёт о сбое. Для этого необходима надёжная система мониторинга и контроля, которая своевременно оповестит о возникшей проблеме. Важно также, чтобы команда не проигнорировала уведомление о сбое.
Это настоящая отправная точка любого аварийного восстановления, и здесь часто возникает задержка начала процесса. Даже у основных веб-приложений нередко случаются сбои в их работе, затем проходит ещё 15-30 минут, после чего вендор начинает активно узнавать и расследовать неисправность. Не стоит недооценивать важность эффективных систем мониторинга и уведомлений.
Кроме того, следует убедиться в правильном планировании и настройках всех процессов. Например, бесполезно будить младшего ИТ-специалиста, который не способен принимать решения и не имеет возможности будить старших сотрудников.
Теперь давайте двинемся дальше и предположим, что в команде есть всё же кто-то, кто может начать процесс аварийного восстановления. Первым шагом будет исследование проблемы. Может быть, что-то можно быстро исправить, или сервер буквально горит? Кому-то понадобится время на принятие окончательного решения о выполнении восстановления, если оно потребуется, и, опять же, это тоже займёт некоторое время.
Если мы предполагаем, что собираемся восстанавливать, то нужно сосредоточиться на системе резервного копирования. Какие типы резервных копий у нас есть? Из некоторых из них восстанавливаться придётся дольше. Если это система резервного копирования на ленту, то где сами ленты? Где стример или загрузчик? Существует ли задокументированный процесс и доступен ли человек, который может выполнить восстановление?
Ответы на подобные вопросы имеют решающее значение, и всё это требует времени. Плохо задокументированный процесс восстановления серверов или медленная система уведомлений могут добавить дополнительные часы, а необходимость заказа нового серверного оборудования может увеличить время восстановления на несколько дней.
Наконец, если все идёт хорошо и процесс завершён, а команда считает, что система восстановлена и работает, то тогда необходимо выделить время на тестирование и окончательную передачу, что тоже требует времени. Напомним, что восстановление включает в себя выявление неисправностей, непосредственно восстановление, окончательное тестирование и передачу. Поэтому, если у бизнеса есть 13-часовой RTO, то необходимо убедиться, что весь процесс укладывается в этот период времени.
Расчёт RTO
Нужно учесть следующее:
какой ущерб будет нанесён организации, если система будет разрушена;
насколько критичен простой системы, как дорого он обойдётся;
насколько долгим может быть предполагаемый простой;
какие уязвимости системы существуют на данный момент;
какие мероприятия уже проводятся для защиты активов компании;
какие существуют потенциальные угрозы, реальные для конкретной организации.
Отличия RPO от RTO
RPO имеет отношение к частоте бэкапов. RTO же определяет, сколько времени у нас есть, чтобы восстановить рабочие нагрузки и запустить их после аварии.
RPO нацелена на бэкап данных в течение предопределённого срока. Этот подход прост, поскольку его можно автоматизировать.
RTO стремится предоставить организациям достаточно времени для восстановления после аварийного сбоя. Таким образом, цель RTO более абстрактна и не поддерживает автоматизацию, все ИТ-функции можно восстановить только вручную.
В результате придётся сбалансировать оба варианта и определить, какие типы данных и какие системы требуют дополнительных инвестиций.
Заключение
В идеале, лучше разработать эффективную стратегию аварийного восстановления, которая включает в себя как RTO, так и RPO. Эти две метрики помогают компаниям определить ограничения своего бизнеса до того, как произойдёт авария. Вы будете иметь хорошее представление о том, как бизнес выдержит инцидент. Но здесь нет готового решения. Каждый бизнес отличается, и план аварийного восстановления также будет отличаться, но в любом случае, восстановление после сбоя без RPO и RTO окажется неэффективным во время активного инцидента.
