SLA без юристов, но с мозгами: как собрать ответственность в B2B так, чтобы сделки шли быстрее, а споры заканчивались раньше

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

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

1) Сначала не SLA, а карта сервиса

Команда, которая хочет продать SLA быстро, начинает не со сроков реакции, а с ответа на неприятный вопрос: что именно является сервисом.

Сервис в B2B редко равен продукту целиком. У него есть границы:

1. публичный API или веб-интерфейс
2. фоновые джобы и очереди
3. интеграции с третьими сторонами
4. клиентская часть на стороне заказчика
5. сеть и устройства заказчика
6. админка, доступная только в рабочие часы

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

Технический прием: нарисовать ASCII-схему прямо в тексте, без диаграмм и пафоса. Например, так, словами: Клиентское приложение заказчика обращается к публичному API. Далее запрос проходит через балансировщик, слой авторизации, сервис бизнес-логики и базу данных. Отдельно работает очередь задач и воркеры. Внешний провайдер отправляет SMS и email.

2) Потом SLI, SLO и только затем SLA

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

1. SLI — индикатор качества, то что реально измеряется
2. SLO — целевой уровень этого показателя
3. SLA — внешнее обещание с последствиями

Если все три штуки смешать, документ становится рыхлым. Поэтому сначала выбирают 2–5 ключевых SLI, которые действительно описывают ценность сервиса.

Типовые SLI для B2B:

1. доступность API или веба
2. задержка на ключевых операциях, например создание заказа
3. успешность обработки событий, например доля сообщений без ошибок
4. время восстановления после инцидента
5. точность данных, если сервис про расчеты и отчеты

Формула доступности обычно простая: availability = (T минус downtime) / T

И вот тут начинается та самая техническая сложность, за которую SLA реально уважают: определение downtime. Если сервис отвечает 200, но возвращает пустой результат, клиенту хуже, чем от 500. Значит downtime — это не только не отвечает, но и отвечает неправильно на контрольных запросах.

3) Окна обслуживания и честная математика времени

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

Поэтому вводят:

1. плановые окна обслуживания, например раз в неделю ночью по времени заказчика
2. правило уведомления, например минимум за 48 часов
3. условие, что в это время доступность не считается

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

4) Классификация инцидентов без театра

Вместо длинных определений удобно сделать уровни серьезности.

Пример логики:

1. критический инцидент: сервис недоступен для большинства запросов или ключевая операция не выполняется
2. высокий: сервис доступен, но ключевые операции деградируют по времени или ошибкам выше порога
3. средний: сбоит неключевая функция, есть обходной путь
4. низкий: косметика, запрос на улучшение

Для каждого уровня задают:

1. время первого ответа, это про коммуникацию
2. время начала работ
3. целевое время восстановления, это уже про инженерию

Важно не перепутать ответ и восстановление. Ответить можно за 10 минут, а починить за 6 часов. И это нормально, если так договорились.

5) Ответственность двусторонняя, иначе SLA будет фальшивкой

Самое токсичное место в SLA — ожидания, что поставщик отвечает за все. В реальности у заказчика тоже есть обязанности. Если их не назвать, конфликт почти гарантирован.

Обычно фиксируют со стороны заказчика:

1. предоставляет корректные данные, доступы, тестовые аккаунты
2. назначает контактных лиц для эскалаций
3. соблюдает лимиты и рекомендации, например по частоте запросов к API
4. сообщает об инциденте через определенный канал

Со стороны поставщика:

1. мониторит сервис 24/7 или в заявленные часы
2. ведет журнал инцидентов
3. делает postmortem для критических случаев с причинами и мерами

6) Доказательная база: кто и чем меряет

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

Рабочий компромисс:

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

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

7) Последствия: сервис-кредиты вместо штрафного цирка

Когда SLA пишут без юристов, часто хочется либо вообще ничего не обещать, либо включить карательные санкции. Второе пугает продавцов и делает переговоры долгими. Первое не устраивает заказчика.

В B2B чаще всего нормально работают сервис-кредиты:

1. если доступность ниже порога, заказчик получает процент скидки на следующий период
2. размер скидки ограничен, например не больше определенного процента от ежемесячного платежа

8) Два коротких примера из жизни, где логика решает

Пример 1: SaaS для обработки заказов и интеграция с 1С

У поставщика было 99.9% на API. Клиент жаловался на простои, потому что ночью интеграция падала. Разбор показал: API был жив, но у клиента истекал токен, и интеграция начинала долбить авторизацию, получая 401, а затем падала по лимитам.

После этого в SLA внесли:

1. отдельный SLI на авторизацию и лимиты
2. обязанность заказчика обновлять токены по документации
3. канал для ранних предупреждений, когда доля 401 растет

Пример 2: B2B платформа с внешними платежами

Заказчик требовал SLA на прохождение платежа. Поставщик не мог отвечать за банк и платежный шлюз. Решили так:

1. SLA на доступность собственного платежного эндпойнта
2. SLO на время обработки до отправки в шлюз
3. отдельный отчетный показатель на долю платежей, завершенных успешно, но без обещания компенсации

9) Шаблон логики в одном списке, чтобы не потеряться

Чтобы собрать SLA без юридической машины, команда обычно проходит по такому чек-листу:

1. определить границы сервиса и исключения
2. выбрать 2–5 SLI, определить метод измерения
3. задать SLO на окно, описать downtime и шаг измерения
4. описать окна обслуживания и уведомления
5. ввести уровни инцидентов и цели по ответу и восстановлению
6. зафиксировать обязанности заказчика и поставщика
7. прописать доказательную базу и процесс сверки
8. определить последствия через сервис-кредиты и лимиты
9. описать эскалации и контакты
10. договориться о postmortem для критических случаев

Вывод

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

Самый неожиданный эффект: грамотно собранный SLA часто снижает нагрузку на поддержку. Люди реже пишут в стиле все горит, если знают, что будет понятная реакция, понятная эскалация и понятный разбор. А это уже почти счастье, особенно в B2B, где каждый инцидент обычно связан с чьими-то деньгами и чьим-то недосыпом.