RTO и RPO. часть 2

К международному дню резервного копирования (или, как еще его называют День Бэкапа).

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

Список статей:
Часть 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
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html


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



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

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

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


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

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

Именно в точках безубыточности надо подбирать системы, которые обеспечат нам необходимую защиту.



Но если бы все было так просто. В графиках можно легко найти изъяны.
Если мы на практике построим такие графики, то получим несколько иное представление. Стоимость решения по защите - это не график, а множества точек. Различные защитные решения не выстраиваются друг за другом в едином графике, а каждое имеет свои координаты: стоимость, подчиненная и обозначенная вендором-производителем данного решения и времена обеспечения этим решением соответствующих потерь данных и скорости восстановления работоспособности.
К тому же, как правило выбирается решение по защите не одной конкретной информационной системы (ИС), а группы (а зачастую всей инфраструктуры - то есть всех инфосистем компании). При этом каждая такая система скорее всего будет иметь свои графики зависимостей стоимости простоя/потери данных от времени:
Таким образом, наши точки безубыточности - уже не точки, а области:
Как из этой ситуации выйти, и перейти к практике расчета, я расскажу как-нибудь в другой раз.


А пока в качестве итога этой статьи.
Если мы рассмотрим нашу инфраструктуру и начнем строить графики для каждой ИС, то мы увидим тенденции, что системы группируются со схожими. Что это означает?
Обратите внимание, до сего момента я говорил про "защиту", но не оговаривал, что это за защита конкретно: резервное копирование, кластер, какие-то еще виды защиты? Тут стоит сказать, что системы защиты бывают разные, и их можно классифицировать.
На схеме ниже видно какой примерно класс решения в зависимости от целевых RTO/RPO необходимо выбирать.



Комментариев нет:

Отправить комментарий