Боевой набор ДИТа: SLA, TCO, RTO. Как говорить на одном языке с бизнесом и выигрывать бюджеты

Бизнес часто спорит с ИТ. В большинстве случаев потому, что ИТ говорит про инструменты и технологии, а бизнес думает про деньги и риски. 

Типичный разговор владельца бюджета и директора по ИТ: ДИТ просит деньги на резервирование или вторую площадку. На это ему отвечают: «У нас же есть бэкапы. В договоре с подрядчиком прописан SLA. Зачем тратить ещё?»

Чтобы выиграть этот спор, нужен переключатель: перестать говорить «Нам нужна репликация», а объяснять —  «Вот сколько стоит час простоя и вот сколько стоит его не допустить». 

Для этого нужен «боевой набор» ДИТа — метрики, которые:

• сшивают договор SLA с реальностью ИТ-инфраструктуры;
• делают план аварийного восстановления (DR) измеримым в минутах и гигабайтах;
• позволяют посчитать цену риска. 

В статье — как говорить на одном языке с бизнесом с помощью метрик и выигрывать бюджеты.

Набор ДИТа: что значит каждая метрика и какой вопрос она закрывает

Хорошая метрика отвечает на конкретный вопрос и у неё всего есть владелец. Если нет ни того ни другого, то это просто цифры  в отчётах, которые не влияют на реальность.

TCO — финансовая оболочка всех решений

TCO (Total Cost of Ownership) — совокупная стоимость владения инфраструктурой или сервисом за период (обычно 3–5 лет). TCO включает CAPEX (капитальные затраты) и OPEX (операционные затраты). 

CAPEX – единовременные расходы на серверы, СХД, сетевое оборудование, лицензии, монтаж и т.п. OPEX – регулярные затраты на поддержку: зарплаты администраторов, электричество, ремонт, страхование, каналы связи, места в ЦОД и т.д.

Также при расчёте ТСО необходимо учитывать сроки эксплуатации оборудования. 

Для бизнеса TCO — это «столько стоит конечный результат». Сюда зашиты железо, люди, поддержка, электричество и — что самое главное — стоимость возможных простоев, ошибок и рисков. Именно поэтому TCO — естественный партнёр к метрикам SLA, RTO и RPO. ИТ-архитектура устроена жестоко: вы всегда платите. Либо за предотвращение аварий и их быстрое устранение, либо за катастрофические последствия.

SLA, SLO, SLI — измеряем уровень доступности сервиса

• SLA (Service Level Agreement) — соглашение об уровне обслуживания, контрактное обязательство подрядчика перед клиентом. В этом документе прописывают, какую услугу предоставляют, по каким показателям измеряют её качество и какие финансовые санкции последуют за нарушение обязательств.
• SLO (Service Level Objective) — внутренняя инженерная цель. Она всегда строже, чем официальный SLA, чтобы у ИТ-команды был запас прочности. Например: «99,95% клиентских запросов обрабатываем без сбоев в течение 30 дней».
• SLI (Service Level Indicator) — то, что вы реально измеряете: доля успешных запросов, время отклика, процент доступности.
• Error Budget («бюджет ошибок») — допустимая доля сбоев, которую «можно потратить» и всё ещё оставаться в SLO.

RPO и RTO — сколько можем потерять?

Когда случается инцидент — отключение питания, атака, сбой оборудования — у бизнеса возникает два вопроса к ДИТу. Первый: сколько данных потеряем? И когда вернёмся в строй? Именно на них отвечают RPO и RTO.

• RPO (Recovery Point Objective) — cколько данных можем потерять. Если бэкап делается раз в сутки, RPO = 24 часа. Авария случилась в 23:50 — теряете почти день работы. Для интернет-магазина это тысячи заказов и разбирательства с клиентами. Для банка — неприемлемо в принципе.
• RTO (Recovery Time Objective) — за сколько времени обязаны восстановиться. Это потолок: после этого момента бизнес несёт неприемлемый ущерб.
• MTD (Maximum Tolerable Downtime) — точка невозврата, после этой отметки ущерб становится катастрофическим: потеря лицензии, штрафы регулятора, уход ключевых клиентов. MTD задаёт рамки для RTO.
• MTTR (Mean Time to Recover) — среднее время от момента сбоя до восстановления. Хотите выдержать SLA при высокой доступности? Либо делайте отказоустойчивую архитектуру, либо умейте чинить очень быстро. На практике нужно и то и другое.
• MTBF (Mean Time Between Failures) — как часто вообще что-то ломается. Растёт MTBF — значит, команда лучше работает или инфраструктура стала надёжнее. Полезный индикатор зрелости эксплуатации.

Сколько стоить снизить риски?

В TCO обязательно нужно учитывать четыре корзины расходов.

• CAPEX.
• OPEX. Тоже обычно считают, но часто занижают.
• DR-инфраструктура. Каналы под выполнение RTO, площадка, репозитории, автоматизация, регулярные обучения.
• Стоимость риска. Ожидаемые потери от простоев × вероятность инцидента. Это то, что вы платите, если ничего не делаете.

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

Когда это число появляется в презентации,  разговор меняется. Бизнес перестаёт спрашивать «зачем нам второй ЦОД» и начинает спрашивать «сколько нужно, чтобы описанный сценарий не случился».

Дорожная карта: что делать прямо сейчас

По итогам этой работы у ИТ и бизнеса должно получиться два честных ответа на вопросы:

• «Сколько мы теряем, если ничего не делать?»
• «Сколько стоит снизить риск до приемлемого уровня и за счёт каких решений?» 

Рабочая последовательность действий для наведения порядка и прозрачности выглядит так:

1. Проведите инвентаризацию сервисов и зависимостей. Определите, что действительно критично для бизнеса, где хранятся данные, от каких внешних интеграций зависит работоспособность, каковы узкие места в инфраструктуре и регламентах доступа.
2. Посчитайте стоимость часа простоя для топ-3 систем. Определите MTD, RTO и RPO вместе с владельцами процессов.
3. Проведите тест восстановления «как есть» и проверьте, сколько времени займёт подъём инфраструктуры в случае аварии.
4. Соберите архитектуру и инфраструктурную модель под цели по разным системам с пониманием принципа «скорость = стоимость» по критерию: «что выдерживает нужный RTO в рамках приемлемого TCO».
5. Определите точки измерения (SLI), внутренние цели (SLO) и правила управления Error Budget, а затем закрепите внешние обязательства как SLA.
6. Посчитайте TCO и бюджет, сравнив сценарии «как есть» и «как нужно» на горизонте 3–5 лет. Здесь же стоит рассчитать, как бизнесу будет выгоднее реализовать стратегию — on-prem, с облаком или частной инфраструктурой.

Возможно, что по результатам этой работы бизнес поймёт, что ему выгоднее обратиться к поставщику ИТ-услуг для разработки стратегии восстановления, администрирования систем и т. д. Ниже – чек-лист по проверке такого подрядчика.

Чек-лист по SLA: что проверить до подписи и что контролировать после

Пройдитесь по этому списку перед каждым крупным изменением инфраструктуры и перед подписью нового SLA с подрядчиком.

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

К этому можно добавить несколько пунктов:

• Что измеряем (доступность инфраструктуры? VM? платформы? приложения?) и по каким SLI.
• Как считается период: месяц/год/согласованное время работоспособности, есть ли окна плановых работ и что считается «форс‑мажором».
• Время реакции и скорость решения: отдельные метрики для разных приоритетов инцидентов.
• Кто владеет мониторингом, данными измерений и как решаются споры по фактам.

Чек-лист по TCO: чтобы сравнение сценариев было честным

Если вы сравниваете on‑prem, частное облако и гибрид, то сравнивайте «одинаковую отказоустойчивость». Иначе на одной стороне будет резерв и доступность под SLA, а на другой — «серверная без резерва». 

Проверьте, что в расчёте есть:

• CAPEX и OPEX (с ФОТ, поддержкой, энергией, связью);
• стоимость каналов и инфраструктуры под выполнение RTO (вплоть до расчётов пропускной способности);
• стоимость эксплуатации SLA (дежурства, мониторинг, процессы релизов, ограничения Error Budget);
• стоимость риска (ожидаемые потери от простоев хотя бы диапазоном), подкреплённая внутренними цифрами «час простоя». 

И финальный тест: может ли бизнес, глядя на ваш документ, ответить на два вопроса —

1. «Сколько мы теряем, если ничего не делать?»
2. «Сколько стоит снизить риск до приемлемого уровня и за счёт каких решений?»

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