SLA на инфраструктуру: где заканчивается ответственность подрядчика

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

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

Разбираем, что такое SLA, где на самом деле заканчивается ответственность подрядчика и на что обращать внимание при заключении договора.

Что измеряет SLA и где границы ответственности 

«Обязательство, чтобы у клиента всё работало» — это не SLA. 

SLA — это договорное обязательство по уровню сервиса, которое опирается на измеримые показатели и конкретные последствия за их нарушение. 

SLA ≠ RTO и ≠ RPO.

• RTO — за сколько времени обязаны восстановиться после сбоя.
• RPO — сколько данных допустимо потерять.

Это другой набор метрик, другой разговор и часто другой бюджет. Если в договоре написано «доступность 99,95%», но не определены RTO, RPO и DR-контур — при аварии можно получить формально соблюдённый SLA и при этом неприемлемый ущерб для бизнеса.

«Девятки» полезно переводить в человеческие часы:

• 99,9% — 8,76 часа допустимого простоя в год;
• 99,95% — 4,38 часа;
• 99,99% — 52,6 минуты.

К этим целям должны быть привязаны архитектура, регламенты и процессы восстановления.
Зарубежные провайдеры формулируют границы ответственности так: данные, учётные записи и доступы — всегда за клиентом, независимо от модели развёртывания. На стороне провайдера — физический ЦОД, сеть, хосты и гипервизор.

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

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

Четыре модели сопровождения: в чём разница

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

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

Модель 1. Сервис на оборудовании подрядчика 
SLA включает мониторинг 24/7, устранение инцидентов, обновления, масштабирование, модернизацию и ремонт оборудования, администрирование СХД. Это полноценный управляемый инфраструктурный сервис с понятным контуром ответственности.

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

Модель 3. ПНР с передачей ключей
Клиент закупает серверы, СХД, лицензии, приглашает внешнюю команду на проектирование, развёртывание, миграцию и приёмочные испытания. После завершения проекта подрядчик отдаёт административные доступы и выходит из ежедневной эксплуатации. Внутри компании это часто всё равно воспринимают как «они внедряли — они и отвечают», хотя на деле это не так.

Модель 4. Техподдержка, которая превращается в удалённое внедрение
Самая опасная зона для клиента. В договоре — только консультации, эскалация и помощь по продукту. На практике инженеры подрядчика начинают проектировать сеть, разбираться с Linux, проверять VLAN, собирать кластерный транспорт и чинить чужие коммутаторы. Клиент считает подрядчика ответственным за всё, но в SLA эта работа не зафиксирована, а значит, не защищена ни одна из сторон.

Два сценария из реальной практики

Сценарий 1. Матрица совместимости — необходимое, но не достаточное условие отказоустойчивости

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

Матрица совместимости обязательна, но она не отменяет предварительных стендов, пилотов и готовности к сюрпризам на уровне прошивок и BIOS. Формально это легко выпадает из зоны SLA подрядчика, если железо выбрал и закупил сам заказчик. Зрелый подрядчик обычно помогает — но считать такую помощь обязанностью не стоит.

Сценарий 2. Изменения убивают стабильность

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

Реальный пример: при сборке кластерного транспорта хосты начали уходить в ребут — рабочим решением стало изменение watchdog timeout по рекомендации вендора. 

Другой пример: обновление прошивки сетевой карты привело к нетривиальной деградации — часть VLAN просто перестала проходить.

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

Как подготовить SLA, который выдержит аварию

1. Начните с определения объекта услуги. Не «облако», не «поддержка инфраструктуры» — конкретная точка измерения: доступность кластера гипервизора, доступность API платформы, реакция на инцидент, время восстановления управляемого сервиса. Пока объект не назван, обсуждать ответственность бессмысленно.
2. Пропишите матрицу ответственности по слоям. Отдельной строкой: питание, стойка, каналы, серверы, СХД, fabric, гипервизор, бэкап-инфраструктура, гостевые ОС, AD, приложение, CI/CD, IAM, пользовательские устройства, интеграции.
3. Зафиксируйте регламент изменений. Большинство конфликтов по SLA возникает после изменений: «мы только драйвер обновили», «мы просто права поменяли», «мы только добавили LUN». Введите правило: всё, что меняется вне согласованного регламента, выводится из SLA до повторной валидации.
4. Не смешивайте SLA с DR. Отдельным приложением должны жить RTO, RPO, перечень критичных систем, порядок тестовых восстановлений, схема резервной площадки и параметры каналов. Бэкап не равно доступность. Требуемая пропускная способность для восстановления считается через объём данных и окно восстановления: 150 ТБ критичных данных при целевом восстановлении за 8 часов математически требуют около 40 Гбит/с, а с учётом накладных расходов — ближе к 85 Гбит/с. SLA не перекроет отсутствие такого расчёта.
5. Считайте деньги до аварии, а не после. 
   Простая формула:
   Стоимость простоя = потерянная выручка + простой людей + штрафы по SLA + затраты на восстановление + репутационный ущерб. 
   Для среднего интернет-магазина час простоя составляет порядка 900 тыс. рублей.
6. Опишите финансовые санкции честно. Сервисный кредит, штраф, исключения, форс-мажоры, зависимость от внешних телеком-провайдеров, вендорские дефекты без обходного решения, действия заказчика и его подрядчиков — всё это нужно проговорить заранее.

Как выбирать подрядчика

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

Первый критерий зрелости подрядчика в 2026 году — с каким объёмом ответственности он реально готов работать и может ли это подтвердить. Например, наши метрики: 

• менее 20 минут на взятие обращения в работу,
• 90% тикетов, решённых в первые 6 часов,
• менее 0,2% обращений с задержкой. 

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

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

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

Поэтому правильный первый вопрос при выборе модели сопровождения звучит не «какой у вас SLA?». Он звучит так:

«Где у вас заканчивается зона ответственности, чем это подтверждено в договоре и в каких реальных кейсах вы уже так работали?»

ITSM (IT Service Management, управление ИТ-услугами) даёт измеримый результат, когда границы ответственности прописаны честно.

• В проекте для «Новосибирскэнергосбыта» переход на управляемую гибридную инфраструктуру дал 59% выгоды по TCO в сравнении с модернизацией собственных ЦОД, рост доступности сервисов с 96,15% до 99,982% в год и перевод 100% клиентов в онлайн.
• В проекте с «СИБИНТЕРФАРМ» полная стоимость владения сократилась в 12 раз в первый год обслуживания, ROI вырос на 32% на трёхлетнем горизонте.

Зрелая сервисная эксплуатация означает, что бизнес перестаёт зависеть от отпуска, больничного или ухода одного ключевого администратора — контур ответственности, роли и регламенты спроектированы так, чтобы не держаться на одном человеке.

Другие подрядчики предлагали нам общую поддержку через чат или почту, а индивидуальных консультаций у инженера не было. Работа с CORTEL строится по другому. Когда в 4 часа ночи у нас вышел из строя сервер, инженеры CORTEL в течении 30 мин устранили инцидент, обеспечив прямое взаимодействие инженерных команд. Удобно работать, когда за поддержкой можно обратиться в любое время и оперативно ее получить

— Чингис Юндунов, ИТ-директор ООО “СИБИНТЕРФАРМ”

Подробнее о том, как работает техподдержка CORTEL — здесь.

Реальные цифры и примеры устраненных инцидентов — здесь.