IT AS IS: 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 час от момента принятия решения о восстановлении. Ориентировочная стоимость потерь – до $$.

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

У нас есть конкретные значения RTO/RPO для каждой из систем.
У нас есть принимаемая стоимость потерь для каждой из систем.
На этапе аудита могут быть выявлены системы, которые раньше оказались «не в той категории»: важные системы, для которых не придавалось значение их доступности.
Это полезно для компании.
Самое главное – составленный SLA. Это ваша личная безопасность, и снижение уровня вашей головной боли ;).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RTO и RPO. часть 5