RTO и RPO

UPDATE! Теперь это серия статей по теме RTO/RPO

Список статей:
Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html

Решил статью про одно написать, а углубился в другое... :)
Публикую в качестве ликбеза.


При разработки технических решений по защите данных и сервисов бизнес-задач предприятия обычно оперируют двумя основными понятиями:
  • время восстановления (recovery time objective (RTO)) - допустимое время простоя сервиса в случае сбоя.
  • точка возврата (recovery point objective (RPO)) - допустимый объем возможных потерь данных в случае сбоя.
Эти значения диктует сам бизнес. Например, если у вас просто обычная не автоматизированная автостоянка, то недоступность электронной почты не критично (это про RTO), а потеря статистики в пасьянсе за год, максимум может сказаться на настроении охранника стоянки (это RPO).

Если вы, допустим, социальная сеть, то простой пару часов - плохо: люди уже начнут смотреть на конкурентов - но еще не критично - тут свою роль играет раскрутка ресурса, и насколько подсажены на этот ресурс пользователи. (RTO)
Но если вы банк, и потеряете данные по платежам... вы можете попрощаться со своим бизнесом - и финансовый и репутационный риски его похоронят со свистом гильотины. (RPO)

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


Отмечу, что значения RTO и RPO - это экстремумы - максимальные значения. Т.е. сколько нам максимум времени нам бизнес позволяет на простой, или сколько максимум данных (по времени) мы можем потерять.
Пример. RPO = 1 сутки. Значит копированием производим, по-старинке, раз в день (ночью). Если у нас резервное копирование запускается в 1:00, а у нас произошел сбой в 0:59, то мы и потеряли как раз сутки. Если сбой произошел сразу по успешному завершению резервного копирования - то вы ничего не потеряли.
Важно! Для RPO, если бизнес поставил значение, резервное копирование должно производится не реже этого значения!
То же касается и RTO. Если указано значение, а вы восстановили доступность сервиса/данных раньше - хорошо, соблюли бизнес-требование. Если потратили больше - не хорошо.

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


Продолжение...

6 комментариев:

  1. Анонимный11.10.2011, 17:24

    Спасибо.
    Коротко. Просто. С юмором.

    ОтветитьУдалить
  2. Анонимный14.10.2011, 12:28

    неверное утверждение: где уменьшение любой из граней или пары приводит к увеличению третьей.

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

    ОтветитьУдалить
  3. Да, правильно. Я вообще хотел эту фразу удалить, так как нелинейно стоимость меняется. Ценообразование - это отдельный философско-экономический вопрос :)

    ОтветитьУдалить
  4. Анонимный05.11.2013, 15:14

    Неплохая статья для "начинающих", но ... последняя мысль про треугольник полностью дискредитирует автора.

    ОтветитьУдалить
  5. Учитывая популярность в прочтении этой темы - я убрал про "треугольник" (это на самом деле была наметка на отдельный пост), и слегка поправил/дополнил текст.

    ОтветитьУдалить