RTO и RPO. часть 5

В прошлой статье серии я рассматривал связь бизнеса (читай – денег) и ИТ сервисов. В этой части хочу сделать шаг в сторону практической реализации того, о чем писал в прошлых частях рассказа про 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
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html 

“If you fail to plan, you are planning to fail!”

                                                                  Б.Франклин

Или перефразирую известную песенку:

«Ни минуты простоя,
ни секунды простоя…
лишь бы не было сбоя…»

Помните я во второй части приводил такую картинку:

Да, все информационные системы разные, с разными стоимостями простоев и потерь данных. Как нам выбрать наиболее подходящее для всех, унифицированное решение? Ниже приведу один из способов решения этой задачи.

Для начала общие рекомендации.

• Рекомендую выбирать общее решение для одной категории сервисов (вернее сказать – информационных систем, предоставляющих эти сервисы).
  Как правило, business- и mission-critical системы при их правильном проектировании уже имеют встроенное решение по обеспечению высокой доступности. Так что даже если там не предусмотрено решение по резервному копированию, то целевые RTO/RPO для высокой доступности уже должны быть определены, и обеспечиваться соответствующим решением по высокой доступности (в рамках проекта этих систем). Однако…
• Решения по кластеризации не решают всех возможных проблем, не спасают от всех возможных сбоев. Потому, для критичных систем необходимо создавать многоуровневую защиту: и кластеры, и резервное копирование, и другие способы обеспечения доступности. Я об этом уже говорил в третьей части серии.
  Даже само решение по резервному копированию, в некоторых случаях, строится многоуровневым для закрытия разных рисков. Например, резервное копирование виртуальных машин в сочетании с дополнительным резервированием данных внутри ВМ (например, транзакционных логов баз данных).

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

Этап 1. Аудит. Выявляем требования по каждой информационной системе

Как проводить данный аудит по каждой системе – на самом деле тема отдельного большого разговора, и вытекает из области risk management – управление рисками. Здесь я опишу простой способ, при уже определенных возможных сбоях, от которых необходимо защитить информационные системы.
Работа должна вестись с непосредственными бизнес-заказчиками каждой из систем.

Кто такие бизнес-заказчики?

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

В подразделении бизнес-заказчика сервиса должны быть выделены ответственные за сервис люди, и они должны знать насколько данный сервис важен и нужен. Именно с ними вам необходимо подписывать SLA, и именно они должны с вас требовать, чтобы сервис работал должным образом.
Если у сервиса нет бизнес-заказчика (и ответственного лица), то можете смело такой сервис отключать и уничтожать. Шутка! Хотя такое действие быстро поспособствует нахождению бизнес-заказчика ;).

На этапе аудита проводится самая сложная работа из всего процесса. Вам придется включить всё ваше обаяние, чтобы объяснить для чего это нужно, и заручиться помощью и поддержкой в решении этой задачи. Кстати, угрозы и шантаж, как действенное средство, никто не отменял. Снова шучу ;) !

Вам необходимо собрать с каждого бизнес-заказчика расчеты по финансовым потерям в случае простоя сервиса и потери данных. Примерно по таким шаблонам:

Время простоя Сервиса (RTO)	15 минут	1 час	8 часов	24 часа
Информационная система #	$	$	$$	$$$$

Время потери данных (RPO)	1 час	8 часов	24 часа	72 часа
Информационная система #	$	$	$	$$$

Собирать нужно именно табличные данные, и обязательно с указанием финансовых потерь. Чем больше пунктов-столбцов, тем лучше, но не переусердствуйте ;). Если вы просто спросите: какое RTO/RPO (предварительно объяснив значения терминов) устроит заказчика ИС, вы гарантированно получите ответ: «ноль!». В таблице же будет прослеживаться тенденция роста финансовых потерь. И если в будущем будет вставать вопрос о пересмотре стоимости решения, вам не нужно будет повторять заново всю процедуру.

Для критичных сервисов, как я говорил уже, возможно построение одновременно несколько решений по системам защиты. Потому здесь важно собирать данные по требованиям к различным решениям. Строим либо несколько таблиц по каждому из решений: FT, кластер HA, система резервного копирования (СРК). Либо, что предпочтительнее, удлиняем таблицу за счет добавления временных точек. Например, если для СРК достаточно шкалы RTO: 1 час, 8 часов, 24 часа; то для HA+СРК шкалу стоит брать: 1 мин, 5 минут, 10 минут, 30 минут, 1 час, 8 часов, 24 часа. 

Вы, конечно, можете, решить все сделать сами, но тогда не ждите, что заказчик подпишется под выставленный SLA.

В заполненных таблицах бизнес-заказчик ИС выбирает границу – максимальное значение финансовых потерь, которые он принимает в качестве приемлемых (для наглядности в таблицах выше я расцветил в зеленый приемлемые потери, в красный – неприемлемые). В случае, когда оценочная шкала потерь построена для нескольких типов решений по защите, нужно оценить несколько позиций RTO/RPO для каждого типа. К примеру, HA_RTO = 1 минута, СРК_RTO = 1 час, HA_RPO = 1 минута, СРК_RPO = 8 часов. Соответственно в дальнейшем для каждого типа систем защиты также придется отдельно производить расчеты.

Значения приемлемых финансовых потерь для RTO и RPO должны быть максимально близкими по значению. Иначе это странно выглядит, если при простое системы для нас нормально потерять $$ денег, но потеря данных при той же стоимости потерь нам уже не приемлема. Совет: в случае такой неразберихи – всегда пересматривайте результаты, попробуйте изменить шкалы временных значений. 

Итогом должны стать конкретные цифры для RTO и RPO, которые нужно, «пока горячо», прописать в SLA (Соглашение об Уровне Обслуживания) для данного сервиса, и (самое главное!) заполучить под этим SLA подпись представителя бизнес-заказчика инфосистемы. В Соглашении обязательно должно быть зафиксировано не только значение RTO/RPO, но и перечислены сами сбои, для которых вы это рассчитали, все остальные типы сбоев тогда будут считаться форс-мажором.

Для примера:

Инфосистема ХХ.

Для сбоев: выход из строя аппаратной платформы, при возможности успешного перезапуска сервера (причины: отказ оборудования, отключение электропитания). RTO = 5 минут, RPO = 30 секунд от момента сбоя. Ориентировочная стоимость потерь – до $.

Для сбоев: отказ системы на программном уровне без возможности перезапуска сервера (причины: некорректное изменение данных, вирусная атака на сервер с уничтожением данных, крах системы после обновления). RTO = 1 час, RPO = 1 час от момента принятия решения о восстановлении. Ориентировочная стоимость потерь – до $$.

Что мы на этапе аудита получаем:

1. У нас есть конкретные значения RTO/RPO для каждой из систем.
2. У нас есть принимаемая стоимость потерь для каждой из систем.
3. На этапе аудита могут быть выявлены системы, которые раньше оказались «не в той категории»: важные системы, для которых не придавалось значение их доступности.
   Это полезно для компании.
4. Самое главное – составленный SLA. Это ваша личная безопасность, и снижение уровня вашей головной боли ;).
   
   a. Во-первых, дальше, когда вы выберете конкретное решение, вам будет проще обосновать требуемое финансирование. Обычная проблема большинства ИТ-сотрудников, что они не могут конкретно и внятно донести до держателей бюджетов компании необходимость финансовых трат. Теперь же у вас есть конкретные цифры потерь, которые сами обоснуют требования к затратам на строящуюся систему защиты.
   
   b. Во-вторых, SLA c подписью заказчика ИС – снятие с вас ответственности за «неправильные» цифры.
   Например, когда произойдет сбой, если вы восстановите за срок, больший, чем прописан в SLA – вина полностью ваша (и тут не важно: вы просто прошляпили время; или выбрали неправильное решение; или вам не дали денег на необходимую систему, и выбрали «на что хватило»; или не учли возможность такого сбоя, а в SLA не прописали список сбоев – это полностью ваша вина).
   Но в другом случае, если вы за меньшее время, чем указано в SLA, восстановите доступ к сервису, но потери будут очень велики, а бизнес-заказчик сервиса будет пытаться взвалить вину на вас, вы будете защищены перед владельцами бизнеса. Вы исполнили SLA!

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

Этап 2. Анализ. Определяем требования к решению по обеспечению доступности при сбоях.

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

	RTO	Стоимость потерь
Информационная система #	t	$
…	…	…
Информационная система ##	t	$$

	RPO	Стоимость потерь
Информационная система #	t	$
…	…	…
Информационная система ##	tt	$

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

По каждой таблице производим сортировку два раза:

1. Первый раз по значению показателя (RTO и RPO) от меньшего времени к большему.
2. Второй раз по стоимости потерь от меньшего значения к большему.

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

1. Оставить как есть. Посмотрите на решения по обеспечению доступности. Возможно выбранное в дальнейшем вами решение удовлетворит потребности самой требовательной ИС, и всех менее требовательных также.
   Пример. У первой в списке ИС значение RTO – 30 минут, а у последующих – от 8 часов. Выбрав решение, обеспечивающее восстановление за 15 минут вы закрываете все потребности (при условии, что решение не превышает выбранную стоимость потерь).
2. Пересмотреть значения для данного сервиса. Заново обсудить с бизнес-заказчиком, возможно требования к обеспечению доступности оказались завышены.
3. Перевести сервис в категорию критичных, и рассматривать для него отдельное решение (возможно совместно с другими такими же критичными системами).

На этапе анализа получаем требования к системе обеспечения восстановления в случае сбоя:

1. Минимальное значение RPO.
2. Минимальное значение RTO.
3. Минимальную стоимость потерь.

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

Страшно? Оставим только необходимые минимальные значения, и уберем лишние графики:

Расцвеченная зелёная зона и есть результат второго этапа: искомые требования по обеспечению доступности информационных систем. Этот график поможет нам выбрать необходимое решение по обеспечению доступности данных и сервисов.

Этап 3. Выбор решения. Определяем подходящую систему.

Система, которая восстанавливает данные и работоспособность сервиса, обладает свойствами, определенными нами в вышеуказанных требованиях: минимальный уровень обеспечения доступности данных, минимальный уровень обеспечения доступности сервиса, и стоимость решения (стоимость общая и для доступности данных, и для доступности сервиса).

На графике решения будут выглядеть как «гантели». Например, так:

Поясню график. Мы нашли 4 решения по СРК. Продукт D – бесплатный (я не учитываю, что бесплатных решений не бывает вообще – трудозатраты на внедрение есть всегда, это как минимум), но он нам не подходит, потому как не сможет обеспечить нужные уровни RTO/RPO. Решение C не обеспечивает нужное время восстановления. Решения A и B подходят, так как позволяют перекрыть необходимые нам требования по уровням защиты. Но решение A само по себе дороже потерь, которые понесет бизнес в случае сбоя систем.

Таким образом нам подходит решение B.

На самом деле я описал ОЧЕНЬ упрощенный подход (по тексту выше не скажешь, что это «в двух словах»). Это отправная точка, чтобы вы получили представление о том, как рассчитывать и выбирать решение.

Какие вопросы необходимо решить для правильного расчета?

Начнем с конца. Со стоимости сравниваемых решений.

Что с финансовой точки зрения представляет собой указанная стоимость решения? Представленная продавцом конечная стоимость ПО? Но есть еще стоимость внедрения – это же тоже расходы. Тогда для полноты стоимости нужно по каждой системе указывать все капитальные затраты (CapEx). Но в дальнейшем, когда внедрённое решение будет работать, её работу нужно поддерживать – операционные расходы (OpEx). Эти расходы для каждого решения разные, и это нужно учесть.

Таким образом выбирая решение необходимо по каждой системе рассчитывать TCO (Total Cost of Ownership – совокупная стоимость владения), которая будет учитывать общую стоимость решения с учетом капитальных затрат на закупку и внедрение и последующее обслуживание её работы.

TCO рассчитывается на определенный период времени (желательно сроком на 3-5 лет), но тогда нельзя сравнивать динамическое значение TCO со статической стоимостью единичного сбоя.

Значит нужно что-то сделать с расчетами сбоев тоже. Если у нас есть статистика наших сбоев, мы можем использовать её. Если нет – необходимо найти нужную аналитику с величинами средней стоимости потерь, вероятности и частоты сбоев. Тут мы снова возвращаемся к риск менеджменту.

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

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