SLA после запуска цифрового сервиса: чек-лист условий поддержки, сроков реакции и оплаты

Зачем SLA нужен после запуска цифрового сервиса

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

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

• Доступность сервиса (Uptime): например, 99,5% (допускается около 3,6 часов простоя в месяц) или 99,9% (не более 43 минут простоя в месяц);

• Сроки реакции на инциденты (Response Time): время, за которое инженер берет задачу в работу и подтверждает это заказчику;

• Сроки восстановления после сбоя (MTTR - Mean Time To Recovery): время до полного или частичного возобновления работы бизнес-функции;

• Каналы обращения: helpdesk-система (Jira, Redmine, Zendesk, Kaiten), выделенная почта, корпоративный мессенджер, дежурный телефон;

• Часы поддержки: 8/5 (рабочее время), 12/7 (расширенное время без ночей), 24/7 (круглосуточно);

• Что входит в ежемесячную оплату: мониторинг, бэкапы, мелкие багфиксы, обновление сертификатов;

• Что считается отдельной доработкой (Out of Scope): новые фичи, редизайн, смена логики;

• Ответственность сторон: штрафные санкции за нарушение метрик (например, снижение абонентской платы на 5-10% за каждый час простоя сверх нормы);

• Порядок отчетности и контроля качества: регулярность предоставления срезов по тикетам и затраченным часам.

В современных реалиях для цифровых продуктов особенно важно отдельно проверять поддержку интеграций, мобильных версий, платежей, облачной инфраструктуры и прав доступа. До 70% критических сбоев возникают не в самом интерфейсе или ядре системы, а на стыке вашего сервиса с внешними провайдерами: банком-эквайером, логистической CRM, складской учетной системой, картографическим сервисом или SMS-шлюзом.

Подробнее на эту тему — Как настроить автопродление подписки на SaaS-сервис без нео….

Критерии выбора SLA для цифрового сервиса

1. Критичность сервиса для бизнеса

Сначала определите, насколько простой сервиса влияет на прямую выручку, лояльность клиентов и внутренние операционные процессы компании.

Примеры оценки критичности:

• Интернет-магазин или маркетплейс: теряет заказы и деньги уже через 10–30 минут сбоя корзины или оплаты. Требует жесткого SLA с реакцией 24/7.

• Мобильное приложение доставки или такси: критично в часы пик (вечер, выходные). Простой ведет к мгновенному оттоку пользователей к конкурентам и репутационным потерям.

• Внутренний корпоративный портал (HR-система): обычно может выдержать восстановление в течение рабочего дня, так как не генерирует прямую выручку.

• Промостраница сезонной акции: часто не требует круглосуточной поддержки, если на ней нет оплат и сбора сложных персональных данных, но требует 100% доступности в момент запуска рекламного трафика.

Для критичных сервисов нужен SLA с быстрым реагированием: от 15 до 30 минут по аварийным инцидентам. Для некритичных — достаточно реакции в течение 4–8 рабочих часов.

2. Уровни приоритетов инцидентов

В SLA необходимо жестко разделить обращения по степени срочности. Без матрицы приоритетов любая косметическая правка (например, опечатка в футере) может конкурировать за время разработчика с реальной аварией (падение базы данных).

Пример рабочей классификации инцидентов:

Важно: реакция и устранение — это принципиально разные метрики. Реакция означает, что дежурная команда приняла обращение, классифицировала проблему, отписалась заказчику и начала технический разбор. Устранение (восстановление) — это фактическое возобновление работы бизнес-процесса или выпуск hotfix-обновления.

3. Часы поддержки и часовые пояса

Распространенные варианты покрытия:

• 8/5 (или 9/5): по рабочим дням, например с 10:00 до 18:00 по времени заказчика.

• 12/5 или 12/7: расширенный рабочий день (например, с 08:00 до 20:00), захватывающий выходные.

• 24/7: круглосуточно, включая все выходные и государственные праздники.

Для сервиса с онлайн-оплатой, платными подписками, доставкой еды, бронированием билетов или клиентским личным кабинетом поддержка формата 8/5 является фатальным риском. Если критический сбой случится в пятницу в 19:00, восстановление начнется только в понедельник утром. Бизнес потеряет выручку за все выходные.

4. Состав работ в поддержке (In Scope vs Out of Scope)

В SLA надо исчерпывающе перечислить, что именно включено в фиксированную абонентскую плату. Например:

• круглосучный автоматический мониторинг доступности (Zabbix, Grafana, Prometheus);

• регулярная проверка логов на предмет скрытых ошибок;

• исправление багов, выявленных после релиза;

• минорное обновление зависимостей и библиотек (патчи безопасности);

• контроль сроков действия SSL-сертификатов и доменов;

• настройка и проверка резервного копирования (бэкапов);

• консультации администратора или менеджера продукта;

• поддержка работоспособности текущих API-интеграций;

• подготовка детализированного ежемесячного отчета.

Отдельно укажите, что НЕ входит (Out of Scope): разработка новых функций (фич), глобальный редизайн, изменение заложенной бизнес-логики, перенос проекта на другую серверную инфраструктуру, интеграция с новой внешней системой (например, переход с одной CRM на другую), срочный выпуск внеплановой версии приложения по инициативе маркетинга.

5. Цена и модель оплаты

Для цифровых сервисов на рынке устоялись несколько моделей оплаты SLA. Ориентиры могут отличаться в зависимости от региона, технологического стека (PHP/Laravel будет дешевле, чем микросервисы на Go/Kubernetes) и уровня SLA, но для планирования бюджета актуальны следующие диапазоны:

• Базовая поддержка небольшого сайта или лендинга: от 20 000 до 50 000 ₽ в месяц.

• Поддержка веб-сервиса с личным кабинетом и БД: от 60 000 до 150 000 ₽ в месяц.

• Поддержка мобильного приложения (iOS + Android) и backend-части: от 100 000 до 300 000 ₽ в месяц.

• SLA 24/7 для критичного продукта (Highload, FinTech, E-com): от 300 000 ₽ в месяц и выше (часто включает выделенную дежурную смену).

• Разовые срочные работы (Time & Material): тарифицируются по ставке 2 500–6 000 ₽ за час работы специалиста, часто с повышающим коэффициентом (x1.5 или x2) за работу в ночное время или выходные дни.

Если подрядчик предлагает подозрительно низкую цену (например, 15 000 ₽ за сложный портал), обязательно проверьте лимит часов. Такая сумма может покрывать всего 3–5 часов работы middle-разработчика в месяц, полное отсутствие реакции в выходные и отсутствие финансовой ответственности за простой.

Критерии проверки подрядчика

Перед выбором IT-партнера или конкретного SLA-пакета проверяйте условия не по красивой презентации, а по юридическим документам и измеримым техническим параметрам.

Сравнение вариантов SLA

Вариант 1. Базовая поддержка (Реактивная)

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

Обычно включает:

• реакцию в течение 1 рабочего дня (до 8 часов);

• поддержку исключительно по будням (8/5);

• 10–20 часов работ инженера в месяц;

• исправление мелких некритичных ошибок;

• консультации контент-менеджеров по админ-панели;

• базовый ping-мониторинг (жив/мертв).

Плюсы: низкая стоимость; достаточно для некритичных продуктов; легко запустить сразу после релиза.

Минусы: нет быстрой реакции на аварии; выходные и праздники не покрываются; любые срочные задачи оплачиваются по высокому тарифу.

Ориентир по бюджету: 20 000–60 000 ₽ в месяц.

Вариант 2. Расширенная поддержка (Проактивная)

Подходит для сервисов, где есть активные пользователи, заказы, личные кабинеты, интеграции с 1С/CRM, email-рассылками, эквайрингом или складскими остатками.

Обычно включает:

• реакцию по приоритету P1 в течение 30–60 минут в рабочее время;

• 40–80 часов работ в месяц (хватает на багфикс и мелкое развитие);

• глубокий мониторинг ошибок (Sentry, Kibana);

• работу с отвалившимися интеграциями;

• плановые обновления фреймворков;

• ежемесячный аналитический отчет;

• регулярное тестирование резервных копий.

Плюсы: хорошо закрывает риски после запуска; позволяет планировать мелкие улучшения (эволюция продукта); появляется регулярная аналитика инцидентов.

Минусы: дороже базового пакета; ночные аварии все еще могут не покрываться (если не докупить опцию дежурства).

Ориентир по бюджету: 80 000–180 000 ₽ в месяц.

Вариант 3. Критичный SLA 24/7 (High Availability)

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

Обычно включает:

• круглосуточный мониторинг инфраструктуры и бизнес-метрик;

• реакцию по P1 за 15 минут в любое время суток;

• выделенную дежурную команду (L1, L2, L3 линии поддержки);

• жесткий регламент эскалации (вплоть до звонка CTO посреди ночи);

• отдельный аварийный канал связи (красная кнопка);

• геораспределенное резервное копирование и план аварийного восстановления (Disaster Recovery Plan);

• проведение Post-mortem (постинцидентный разбор причин аварии).

Плюсы: минимизирует время простоя до предела; абсолютно прозрачная зона ответственности; есть четкий план действий при любых катастрофах.

Минусы: очень высокая стоимость; избыточно для малого бизнеса; требует высокой технической дисциплины со стороны самого заказчика.

Ориентир по бюджету: от 300 000 ₽ в месяц, для сложных enterprise-продуктов — от 1 000 000 ₽ и выше.

Что обязательно включить в SLA после запуска

Документы и регламенты

Минимальный юридический и технический комплект:

1. Основной договор на техническое сопровождение ПО.

2. Приложение SLA с матрицей приоритетов и уровнями сервиса.

3. Техническое задание или актуальная документация текущей версии продукта.

4. Смета или выбранный тарифный план с указанием часов.

5. Регламент обработки заявок (как заводить тикет, кто имеет право это делать).

6. NDA (Соглашение о неразглашении) и DPA (Соглашение об обработке персональных данных).

7. Регламент передачи доступов и управления исходным кодом (Git).

8. План резервного копирования (частота бэкапов и срок их хранения).

9. Архитектурная схема и перечень всех внешних интеграций.

10. Матрица эскалации (контакты руководителей с обеих сторон для решения критических споров).

*Совет:* Если цифровой сервис уже запущен другой командой, обязательно проведите независимый технический аудит перед подписанием SLA с новым подрядчиком. Новый исполнитель должен понимать реальное состояние legacy-кода, инфраструктуры и технического долга. Иначе он заложит огромный риск в цену или откажется подписываться под жесткими сроками восстановления.

Измеримые метрики

В SLA не должно быть формулировок «в кратчайшие сроки» или «по мере возможности». Только цифры:

• Uptime за месяц: например, не ниже 99,8%;

• Время реакции: 15 мин (P1), 2 часа (P2), 8 часов (P3);

• Процент заявок, закрытых в срок (SLA Compliance): например, 95%;

• Допустимое время плановых технических работ (Maintenance window): например, строго с 02:00 до 05:00 в ночь с субботы на воскресенье;

• Срок уведомления о плановых работах: за 48–72 часа;

• Срок хранения резервных копий: ежедневные — 7 дней, еженедельные — 1 месяц.

Ответственные лица (Матрица коммуникаций)

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

• кто со стороны заказчика имеет право ставить задачи и подтверждать приоритет P1;

• кто финансово согласует оплату срочных овертайм-работ;

• кто принимает выполненные задачи (UAT - User Acceptance Testing);

• кто дежурит со стороны подрядчика и кому звонить при эскалации конфликта.

Когда SLA не подходит или нужен другой формат

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

• у сервиса полностью отсутствует техническая документация;

• исходный код не передан заказчику (находится на серверах старой студии);

• продукт написан на устаревшем стеке (legacy), который никто не хочет поддерживать;

• продукт постоянно и хаотично меняется без тестирования (нет CI/CD);

• заказчик ожидает масштабную разработку новых функций в рамках дешевой поддержки;

• накоплен критический технический долг (система падает каждый день из-за архитектурных ошибок).

В таких случаях сначала инициируется этап стабилизации (или рефакторинга). Например, если мобильное приложение постоянно крашится из-за устаревших библиотек, простое SLA на 20 часов не поможет. Потребуется отдельный мини-проект: обновление зависимостей, переписывание проблемных модулей, полное регрессионное тестирование и публикация новой стабильной сборки. Только после этого продукт берется на SLA.

Что может пойти не так: главные риски

• Размытые сроки и устные правки. Заявки теряются в личных чатах, невозможно доказать объем выполненных работ и предъявить претензии за срыв сроков.

• Скрытая стоимость инфраструктуры. Подрядчик выставляет дешевый SLA, но потом вы получаете огромные счета за аренду серверов, платные лицензии, SMS-шлюзы, push-уведомления и SSL-сертификаты, которые не были включены в договор.

• Vendor Lock-in (Зависимость от подрядчика). У вас нет административных доступов к серверам, домену и репозиторию с кодом. При попытке сменить подрядчика вы рискуете потерять весь продукт.

• Bus Factor (Фактор автобуса). Ваш проект на стороне подрядчика поддерживает только один конкретный программист. Если он уходит в отпуск или увольняется, поддержка вашего бизнеса останавливается.

• Отсутствие тестового контура (Staging). Исправления вносятся программистами прямо «на живую» (на production-сервере). Одно неверное движение — и работающий сервис ломается у всех клиентов.

Продукт и критичность

• [ ] Определены критичные бизнес-функции (вход, корзина, оплата, интеграция с 1С/CRM).

• [ ] Посчитана примерная стоимость одного часа простоя сервиса в рублях (для выбора тарифа).

• [ ] Обращения разделены на 3-4 уровня приоритета (от P1 до P4) с понятными примерами.

Договор и юридическая часть

• [ ] В договоре четко прописаны штрафные санкции за нарушение Uptime и сроков реакции.

• [ ] Подписано соглашение о неразглашении (NDA) и защите персональных данных.

• [ ] Зафиксировано, что все права на написанный в рамках поддержки код принадлежат вашей компании.

• [ ] Указан срок гарантии на выполненные работы (минимум 30 дней на бесплатное исправление багов).

Техника и доступы

• [ ] У вас (как у владельца) есть полные административные доступы к регистратору домена, хостингу/серверам и репозиторию кода (Git).

• [ ] Настроен автоматический мониторинг доступности сервиса с алертами.

• [ ] Прописан регламент резервного копирования (как часто делаются бэкапы и где они хранятся).

• [ ] У подрядчика есть отдельный тестовый сервер (Staging) для проверки правок перед релизом.

Процессы и коммуникация

• [ ] Выбран единый канал для постановки задач (Helpdesk-система, а не личные сообщения).

• [ ] Зафиксированы часы работы поддержки с указанием часового пояса (например, 10:00–19:00 МСК).

• [ ] Определены ответственные лица с обеих сторон (кто ставит задачи, кто принимает работу).

• [ ] Согласована стоимость часа работы сверх лимита (овертайм, работа в выходные).

В чем разница между гарантийной поддержкой и SLA?

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

Можно ли менять уровень SLA в процессе работы?

Да, это нормальная практика. Часто после запуска (первые 1-2 месяца) берут расширенный SLA 24/7 для оперативного тушения «пожаров» и отлова скрытых багов. Когда сервис стабилизируется, переходят на более дешевый тариф 8/5. Главное — прописать возможность смены тарифа в договоре с уведомлением за 15–30 дней.

Как объективно измеряется Uptime?

Uptime не измеряется «на глаз». Для этого используются независимые сервисы мониторинга (например, Pingdom, UptimeRobot, Яндекс.Метрика), которые каждую минуту отправляют запрос к вашему сервису. В конце месяца система автоматически генерирует отчет с процентом доступности. Именно этот отчет является основанием для применения штрафных санкций.

Что делать, если подрядчик регулярно нарушает сроки реакции?

Если SLA нарушается систематически, штрафы (снижение абонентской платы) перестают компенсировать ваши бизнес-потери. В этом случае необходимо инициировать процедуру эскалации (встреча на уровне руководителей), запросить план исправления ситуации (Service Improvement Plan) или начать поиск нового подрядчика, параллельно готовя текущую инфраструктуру к безопасной передаче.

Что делать дальше (Выводы)

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

Ваши следующие шаги:

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

2. Оцените риски: посчитайте, сколько денег или клиентов вы потеряете, если сервис будет недоступен 4 часа в пятницу вечером.

3. Сформулируйте требования: составьте список критичных функций и желаемое время реакции.

4. Запросите проект договора: обратитесь к текущему или потенциальному IT-партнеру за драфтом SLA, сверьте его с чек-листом из этой статьи и обязательно обсудите матрицу приоритетов до подписания бумаг.