SLA в ИТ: как правильно формулировать метрики и избегать штрафов

Представьте ситуацию: ваш интернет-магазин лежит на сутки. Клиенты уходят к конкурентам, поддержка завалена звонками, а менеджер по закупкам говорит: «Ну, они же чинят». Звучит знакомо? Проблема часто кроется не в самом сбое, а в том, что SLA (Service Level Agreement) - соглашение об уровне сервиса, фиксирующее обязательства сторон по качеству работы, было написано размыто. Если в договоре нет четких цифр, вы спорите о вкусах. Если есть цифры, но они нереалистичны, вы платите за воздух или получаете плохой сервис.

Почему абстрактные обещания не работают

Многие компании начинают писать SLA со слов вроде «максимальная доступность» или «быстрая реакция». Это ловушка. Для разработчика «быстро» - это 10 минут, для бизнес-аналитика - 5 секунд. Чтобы соглашение работало как инструмент управления, а не источник конфликтов, каждая метрика должна быть измеримой.

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

Базовые метрики, которые нужно включить в документ

Есть четыре столпа, без которых SLA выглядит неполноценным. Давайте разберем каждый с конкретными значениями, которые считаются рыночными стандартами для B2B-сервисов.

• Доступность (Availability). Процент времени, когда сервис работает штатно. Формула: (Общее время - Время простоя) / Общее время * 100%. Стандарт «99.9%» означает до 43 минут простоя в месяц. Для критичных систем берут «99.99%» (до 4 минут). Не путайте доступность с производительностью: сайт может открываться за 5 секунд, но считаться недоступным, если он виснет.
• Время реакции (Response Time). Скорость, с которой команда начинает работать после тикета. Важно отличать от времени решения. Реакция - это подтверждение получения заявки. Типичное значение: 15-30 минут для критических инцидентов.
• Время восстановления (Resolution Time). Полное время до устранения бага или сбоя. Здесь сложнее всего согласовать цифры. Для P1 (критический сбой) часто ставят 4-8 часов. Для P3 (косметический дефект) - до 5 рабочих дней.
• Производительность (Performance). Конкретные лимиты скорости. Например, API должен отвечать менее чем за 200 мс в 95-м перцентиле. Без этого пункта «медленный» сервис будет считаться нормальным, пока не упадет совсем.

Как считать простой: нюансы, которые спасают бюджет

Здесь чаще всего возникают споры. Кто считает время простоя? По логам сервера или по ощущению пользователей? Всегда фиксируйте источник истины. Обычно это мониторинговая система (например, Zabbix, Prometheus или облачные аналоги), которая пингует сервис каждые 30-60 секунд.

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

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

Штрафы и бонусы: стимулы вместо палок

Штрафная часть SLA - это не способ наказать, а способ мотивировать. Слишком высокие штрафы приводят к тому, что подрядчик закладывает риски в цену, и вы платите больше. Слишком низкие - и им проще заплатить штраф, чем чинить систему ночью.

Оптимальная модель - симметричная. Помимо штрафов за срыв сроков, пропишите бонусы за перевыполнение. Например, если средняя доступность за квартал составила 99.99% при норме 99.9%, заказчик получает скидку 5% на следующий месяц. Это выравнивает интересы: подрядчику выгодно держать систему стабильной, а не просто «чинить по требованию».

Частые ошибки при составлении документа

Даже опытные юристы иногда допускают технические ляпы в IT-договорах. Вот три самых распространенных:

1. Отсутствие дефиниций. Слова «сбой», «проблема», «устранение» должны иметь строгие определения. Устранение - это когда пользователь снова может совершить действие, а не когда разработчик закрыл тикет.
2. Игнорирование зависимостей. Если ваш сервис зависит от внешнего API банка, чья ответственность за его падение? Нужно прописать исключения из SLA для внешних факторов, иначе вы будете нести убытки из-за чужих проблем.
3. Статичность документа. Система меняется. То, что было критичным полгода назад, теперь может быть второстепенным. SLA нужно пересматривать ежеквартально вместе с командой разработки и бизнеса.

Практический чек-лист перед подписанием

Прежде чем ставить подпись, пройдитесь по этому списку. Он поможет избежать 80% будущих споров:

• Проверьте, что все метрики имеют числовые значения и единицы измерения.
• Убедитесь, что определено, кто и как измеряет эти метрики (какой инструмент используется).
• Уточните порядок уведомления о сбоях: кому звонят, куда пишут, в какое время суток.
• Зафиксируйте максимальный размер штрафов (cap), чтобы не получить счет на всю сумму контракта за один день простоя.
• Добавьте пункт о праве на односторонний выход из договора при систематическом нарушении SLA (например, 3 месяца подряд ниже нормы).

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