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-шлюзом.

Подробнее на эту тему — Трансформация госуслуг: как работают цифровые сервисы для в….

Критерии выбора 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-сервере). Одно неверное движение — и работающий сервис ломается у всех клиентов.

Чек-лист перед принятием решения

Перед подписанием договора на SLA пройдитесь по этому списку, чтобы убедиться в безопасности сделки:

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

• Определены критичные бизнес-функции (вход, корзина, оплата, интеграция с 1С/CRM).
• Посчитана примерная стоимость одного часа простоя сервиса в рублях (для выбора тарифа).
• Обращения разделены на 3-4 уровня приоритета (от P1 до P4) с понятными примерами.

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

• В договоре четко прописаны штрафные санкции за нарушение Uptime и сроков реакции.
• Подписано соглашение о неразглашении (NDA) и защите персональных данных.
• Зафиксировано, что все права на написанный в рамках поддержки код принадлежат вашей компании.
• Указан срок гарантии на выполненные работы (минимум 30 дней на бесплатное исправление багов).

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

• У вас (как у владельца) есть полные административные доступы к регистратору домена, хостингу/серверам и репозиторию кода (Git).
• Настроен автоматический мониторинг доступности сервиса с алертами.
• Прописан регламент резервного копирования (как часто делаются бэкапы и где они хранятся).
• У подрядчика есть отдельный тестовый сервер (Staging) для проверки правок перед релизом.

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

• Выбран единый канал для постановки задач (Helpdesk-система, а не личные сообщения).
• Зафиксированы часы работы поддержки с указанием часового пояса (например, 10:00–19:00 МСК).
• Определены ответственные лица с обеих сторон (кто ставит задачи, кто принимает работу).
• Согласована стоимость часа работы сверх лимита (овертайм, работа в выходные).

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

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

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

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

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

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

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