SLA и регламент поддержки сайта и приложения после запуска в 2026 году

Запуск сайта или приложения — это только 20% работы. Дальше начинается поддержка, и если нет внятного регламента, то любой сбой превращается в «а почему у нас всё лежит?» и поиск виноватых. SLA — это документ, который описывает, как быстро и за чей счёт решаются проблемы. В 2026 году это уже не формальность, а обязательный пункт договора для любого серьёзного проекта.

\n\n

Зачем нужен SLA в 2026 году

\n

SLA (Service Level Agreement) — это не просто список обязательств подрядчика. Это инструмент, который защищает и вас, и исполнителя. Для бизнеса он даёт:

\n

\n
• прогнозируемое время реакции на инциденты;
\n
• ответственность за простой — через штрафы или бонусы;
\n
• прозрачность бюджета: ежемесячный платёж фиксирован или привязан к объёму работ;
\n
• критерии приёмки доработок и релизов.
\n

\n

Без SLA вы остаётесь один на один с «багами», которые могут тянуться месяцами. Особенно это критично для мобильных приложений, где каждый день простоя — это потерянные заявки и негативные оценки в сторах. Поддержка и доработка после запуска — отдельная услуга, и мы в App72.ru всегда фиксируем её в отдельном регламенте.

\n\n

Состав регламента поддержки: что должно быть внутри

\n

Классический SLA для сайта или приложения состоит из шести блоков. Если подрядчик не готов подписать такой документ — это повод задуматься.

\n

1. Категории инцидентов и время реакции

\n

В 2026 году стандартная классификация выглядит так:

\n\n\n\n\n\n\n\n\n\n\n

Критичность	Пример	Время реакции	Время решения
Критический	Сайт или приложение полностью недоступно	15 минут	4 часа
Высокий	Ошибка оформления заявки, потеря данных	1 час	8 часов
Средний	Некорректное отображение в одном браузере	4 часа	2 рабочих дня
Низкий	Мелкие баги, обновление текстов	8 часов	в рамках спринта

\n

Для приложений время реакции может быть короче, потому что сбой в мобильной версии сразу бьёт по удержанию. Например, падение Crashlytics выше допустимого порога — это «высокий» инцидент, а не «средний».

\n

2. Метрики и KPI

\n

Укажите, что считается успешной поддержкой:

\n

\n
• Uptime сайта — не менее 99.9% в месяц (для приложения — 99.5% с учётом модерации сторов);
\n
• соблюдение времени реакции — 95% обращений в рамках норматива;
\n
• отсутствие регрессий после обновлений;
\n
• закрытие инцидентов без повторного возникновения в течение 30 дней.
\n

\n

3. Регламент обновлений и релизов

\n

Опишите, как выходят новые версии: каждый понедельник — это стандарт. Для критических фиксов — отдельный внеплановый релиз. В 2026 году нельзя выкатывать обновление без автоматических тестов и отката. Если подрядчик предлагает «пушим в прод без проверки» — это красный флаг.

\n

4. Состав и объём поддержки

\n

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

\n

5. Процедура эскалации

\n

Определите, кто отвечает за инцидент, кто — менеджер проекта, и как происходит подмена при отпуске. Пропишите каналы связи: Telegram, тикет-система, телефон для критических. Ответ «мы не в офисе — завтра посмотрим» после аварии недопустим.

\n

6. Штрафы и ответственность

\n

Без штрафов SLA — бумажка. Стандартная практика: за превышение времени реакции — скидка 5–10% от месячного абонемента. За критический простой более 4 часов — дополнительная компенсация. В 2026 году суды приравнивают SLA к приложению к договору, так что пункты должны быть реалистичными. Если подрядчик обещает «круглосуточный мониторинг за 5 000 ₽ в месяц» — это либо некомпетентность, либо развод.

\n\n

Как адаптировать SLA под свой проект

\n

Для корпоративного сайта или лендинга со стандартными CMS (Bitrix, WordPress) достаточно пакета «базовый»: 10 часов работы, реакция в рабочие часы. Если у вас сайт + приложение + AI-бот в связке с CRM, SLA должно учитывать три фронта. В таких проектах мы рекомендуем «бизнес-пакет» с фиксированным временем реакции и приоритетом по вашим задачам.

\n

Когда делаете регламент, не копируйте чужой текст из интернета. В 2026 году типовые формы уже устарели: добавились требования по кибербезопасности (регулярные обновления библиотек, сканирование уязвимостей) и интеграция с AI-сервисами. Убедитесь, что подрядчик берёт на себя ответственность за безопасность кода, а не только за «функциональность».

\n\n

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

\n

\n
• Указаны ли категории инцидентов и время реакции в рабочих или календарных часах?
\n
• Есть ли определение «критического» сбоя для вашего конкретного проекта?
\n
• Какой реальный uptime гарантируется и как это фиксируется (мониторинг, отчёты)?
\n
• Включено ли обновление CMS, плагинов, SDK и системных библиотек?
\n
• Прописаны ли сроки на доработки в рамках абонемента? Например, «новая интеграция — не более 2

  Нужна оценка проекта? Напишите в Telegram или оставьте заявку на сайте — подготовим ТЗ и прототип.

  Telegram · Обсудить проект