Запуск бота — это не финал, а начало эксплуатации. Поддержка нужна с первого дня: интеграции ломаются, библиотеки обновляются, аудитория растёт, MAX выпускает изменения API. Разберём, как устроен SLA на поддержку и что реально стоит закладывать.
Уровни поддержки
Стандартное деление:
- L1 — первый эшелон: отвечает на типовые вопросы пользователей через бот, ловит явные сбои.
- L2 — техническая поддержка: разбирается в логах, перезапускает сервисы, диагностирует инциденты.
- L3 — разработка: чинит баги в коде, делает изменения, релизит обновления.
L1 чаще остаётся у бизнеса (это его клиенты), L2 и L3 — у студии или внутренней команды. В некоторых проектах студия закрывает все три уровня.
Время реакции и приоритеты
В SLA задаются категории инцидентов и время реакции на каждую:
- P1 — критический: бот не работает совсем, недоступны платежи, утечка данных. Реакция — 30 минут, восстановление — до 4 часов.
- P2 — важный: часть функций недоступна, ошибки в значимых сценариях. Реакция — 4 часа, восстановление — до 1 рабочего дня.
- P3 — обычный: косметические баги, неудобства, не блокирующие работу. Реакция — 1 рабочий день, плановая правка.
- P4 — улучшения и развитие: фичи, оптимизации. Идут в спринт развития.
Реальная реакция 24/7 на P1 стоит дороже, чем «в рабочие часы» — содержание дежурного инженера с пейджером. Закладывайте это сразу.
Что включает мониторинг
Без мониторинга поддержка реактивна — узнаём об инцидентах от клиентов. Минимум, что должно быть:
- Метрики webhook: 5xx, latency p95, RPS.
- Метрики приложения: ошибки в коде, размер очередей, время выполнения задач.
- Метрики инфраструктуры: CPU, RAM, диск, сеть на VPS.
- Метрики бизнеса: количество новых пользователей, оплат, заявок в день.
- Алерты: по триггерам в чат поддержки (Telegram/MAX) с указанием серьёзности.
Стек обычно — Prometheus + Grafana + Alertmanager. Дешевле и проще — Yandex Monitoring, если бот в YC.
Бэкапы и восстановление
Поддержка — это не только реакция на инциденты, но и подготовка к ним. Что должно быть:
- Ежедневный бэкап Postgres на отдельное хранилище (S3, Object Storage).
- Ротация бэкапов: 7 дней — ежедневные, 4 недели — еженедельные, 12 месяцев — ежемесячные.
- Тестовое восстановление раз в месяц — на стейджинг, чтобы убедиться, что бэкапы рабочие.
- План аварийного восстановления (DRP): что делать, если упадёт VPS, как поднять с нуля за час.
Бэкап без проверки восстановления — это иллюзия защиты. На реальных проектах находили, что 30% «бэкапов» битые.
Окна работ и обновления
Регулярные технические работы планируются заранее:
- Окно обслуживания — например, ночь воскресенья, когда нагрузка минимальная.
- Уведомление пользователей заранее, если ожидается простой более 5 минут.
- Релиз-ноуты — что меняется, какие могут быть последствия.
- Откат: каждый релиз должен иметь возможность отката за 5 минут (предыдущий Docker-образ всегда под рукой).
Срочные правки идут вне окна, но с минимальным набором изменений.
Что НЕ входит в стандартный SLA
Чтобы избежать недопонимания, в договоре чётко прописывается:
- Не входит: новые сценарии, новые интеграции, доработка дизайна. Это идёт через отдельные часы развития.
- Не входит: проблемы на стороне клиента — недоступность его CRM, ошибки в его бизнес-логике, не связанные с ботом.
- Не входит: проблемы платформы MAX, которые не на нашей стороне — мы фиксируем и эскалируем, но повлиять не можем.
- Не входит: восстановление данных, утерянных по вине клиента (удалил админ).
Эти границы обязательно проговариваются с клиентом до подписания SLA.
Стоимость поддержки
Грубые ориентиры:
- Базовая поддержка (L2/L3, рабочие часы, 5 часов в месяц): 8–15 тыс. ₽/мес.
- Расширенная (L2/L3 в рабочие часы, до 20 часов в месяц, мониторинг 24/7): 20–40 тыс. ₽/мес.
- Premium (24/7 на P1, дежурный инженер, до 40 часов в месяц): 50–100 тыс. ₽/мес.
Поддержка дешевле, чем держать своего инженера на проекте, и быстрее — у студии уже есть инструменты и опыт.
Итого
Поддержка бота MAX — это связка мониторинга, регламента инцидентов с временем реакции по P1–P4, бэкапов с тестовым восстановлением, окон работ и чётких границ между поддержкой и развитием. Базовый SLA закрывает большинство потребностей за 8–15 тыс. ₽/мес; критичные сервисы — 50–100 тыс. ₽/мес с дежурными инженерами. Без поддержки бот теряет рабочесть за 3–6 месяцев — закладывайте её в первый же контракт.
Частые вопросы
Какие уровни поддержки бывают для бота MAX?
Стандартное деление. L1 — первый эшелон: отвечает на типовые вопросы пользователей через бот, ловит явные сбои. L2 — техническая поддержка: разбирается в логах, перезапускает сервисы, диагностирует инциденты. L3 — разработка: чинит баги в коде, делает изменения, релизит обновления. L1 чаще остаётся у бизнеса (это его клиенты), L2 и L3 — у студии или внутренней команды разработки. В некоторых проектах студия закрывает все три уровня — это удобнее для клиента, но дороже из-за нагрузки на команду.
Какие приоритеты инцидентов задают в SLA на бота MAX?
Четыре категории по серьёзности. P1 — критический: бот не работает совсем, недоступны платежи, утечка данных. Реакция 30 минут, восстановление до 4 часов. P2 — важный: часть функций недоступна, ошибки в значимых сценариях. Реакция 4 часа, восстановление до 1 рабочего дня. P3 — обычный: косметические баги, неудобства, не блокирующие работу. Реакция 1 рабочий день, плановая правка. P4 — улучшения и развитие: фичи, оптимизации, идут в спринт развития. Реальная реакция 24/7 на P1 стоит дороже, чем «в рабочие часы» — содержание дежурного с пейджером.
Что должно быть в мониторинге бота MAX?
Минимум пять блоков. Метрики webhook: 5xx, latency p95, RPS. Метрики приложения: ошибки в коде, размер очередей, время выполнения задач. Метрики инфраструктуры: CPU, RAM, диск, сеть на VPS. Метрики бизнеса: количество новых пользователей, оплат, заявок в день. Алерты по триггерам в чат поддержки (Telegram/MAX) с указанием серьёзности. Стек обычно — Prometheus + Grafana + Alertmanager. Дешевле и проще — Yandex Monitoring, если бот в Yandex Cloud. Без мониторинга поддержка реактивна — узнаёте об инцидентах от клиентов.
Как организовать бэкапы и восстановление в SLA бота?
Через ежедневный бэкап и тестовое восстановление. Ежедневный бэкап PostgreSQL на отдельное хранилище (S3, Object Storage). Ротация бэкапов: 7 дней — ежедневные, 4 недели — еженедельные, 12 месяцев — ежемесячные. Тестовое восстановление раз в месяц на стейджинг — чтобы убедиться, что бэкапы рабочие. План аварийного восстановления (DRP): что делать, если упадёт VPS, как поднять с нуля за час. Бэкап без проверки восстановления — это иллюзия защиты. На реальных проектах находили, что 30% «бэкапов» битые.
Что не входит в стандартный SLA на поддержку бота?
Чтобы избежать недопонимания, в договоре прописывается. Не входит: новые сценарии, новые интеграции, доработка дизайна — это идёт через отдельные часы развития. Проблемы на стороне клиента — недоступность его CRM, ошибки в его бизнес-логике. Проблемы платформы MAX, которые не на нашей стороне — фиксируем и эскалируем, но повлиять не можем. Восстановление данных, утерянных по вине клиента (удалил админ). Эти границы обязательно проговариваются с клиентом до подписания SLA, иначе ожидания с двух сторон расходятся.
Сколько стоит поддержка бота MAX в месяц?
Грубые ориентиры по уровням. Базовая поддержка (L2/L3, рабочие часы, 5 часов в месяц): 8–15 тыс. ₽/мес — для малого бота с типовой нагрузкой. Расширенная (L2/L3 в рабочие часы, до 20 часов в месяц, мониторинг 24/7): 20–40 тыс. ₽/мес — для среднего проекта с интеграциями. Premium (24/7 на P1, дежурный инженер, до 40 часов в месяц): 50–100 тыс. ₽/мес — для критичных сервисов, где простой стоит больше зарплаты дежурного. Поддержка дешевле, чем держать своего инженера на проекте, и быстрее — у студии уже есть инструменты.