Поддержка Telegram-бота 24/7: SLA и регламент

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

Режимы поддержки: 8/5, 8/7, 24/5, 24/7

«Поддержка 24/7» — модный маркетинговый слоган, но в большинстве проектов реально не нужна. Прежде чем платить за круглосуточное дежурство, разберитесь, какой режим закрывает вашу задачу.

Если у вас бот для записи к врачу — он должен работать в субботу вечером, иначе пациент уйдёт к конкурентам. Если это бот для согласования отпусков сотрудников — 8/5 более чем достаточно, и платить за on-call ночью просто негде.

Когда 24/7 действительно нужно

Круглосуточная поддержка оправдана там, где простой напрямую конвертируется в убытки или репутационный урон.

• E-commerce. Каждый час ночного простоя в выходные — это десятки потерянных заказов. Пиковые продажи часто идут вечером и ночью.
• Fintech. Платежи, переводы, кошельки. Клиент, не получивший деньги, идёт в банк или в соцсети.
• Медицина и экстренные сервисы. Запись, телемедицина, помощь — недоступность опасна для здоровья.
• Прод-критичные внутренние сервисы. Боты для on-call инженеров, мониторинг, алертинг.
• Боты с международной аудиторией. Если 30% пользователей в других часовых поясах — ваше «ночь» это их «утро».

И наоборот, 24/7 избыточно для: внутренних HR-ботов, корпоративных справочников, ботов рассылки контента, MVP с десятком пользователей в день, B2B-сервисов с регламентным расписанием работы клиентов.

Что такое SLA

SLA — соглашение об уровне обслуживания. Фиксирует:

• Доступность сервиса (uptime). Например, 99.5% в месяц = до 3.6 часов простоя.
• Время реакции на инцидент (Time to Respond, TTR).
• Время решения инцидента (Time to Resolve).
• Часы поддержки. 24/7, 8/5, 16/7 — выбирается под продукт.
• RPO/RTO для данных. RPO — допустимая потеря данных в минутах, RTO — допустимое время восстановления.
• Санкции за нарушение — штраф за каждый час простоя сверх SLA или процент возврата абонентской платы.

Без SLA любая поддержка превращается в «когда сможем». С SLA есть понятные ожидания, метрики и санкции.

Целевые показатели SLA

Реалистичные цифры для коммерческого Telegram-бота среднего размера.

99.99% (4.3 минуты простоя в месяц) для бота — почти всегда маркетинг. На таком уровне приходится платить за multi-region, активный failover и команду SRE — это дороже самого бота.

Уровни инцидентов

Стандартная градация позволяет дежурному не будить команду в 3 ночи из-за опечатки в кнопке.

• P0 (критический). Бот лежит, не принимает платежи, основной сценарий полностью сломан. Реакция — минуты, эскалация моментальная.
• P1 (высокий). Ключевой функционал не работает (например, не отправляются уведомления, отвалился один платёжный метод из трёх). Реакция — час, решение в течение суток.
• P2 (средний). Некритичный баг (кривая верстка в Mini App, неточный текст в редком сценарии). Реакция — рабочий день, решение в плановом релизе.
• P3 (низкий). Косметика, опечатки, мелкие улучшения. В бэклог, без срочности.

Уровни поддержки L1, L2, L3

Поддержка делится по типу работы и квалификации, а не только по часам.

• L1 — пользовательская. Принимает обращения от конечных пользователей в боте: «не пришла оплата», «не приходит код». Решает 60–80% типовых проблем по runbook (отправить чек повторно, проверить статус заказа), остальное эскалирует.
• L2 — инженерная. Дежурный разработчик. Дебажит код, смотрит логи, перезапускает сервисы, делает hot-fix. Большинство P0/P1 закрывается на этом уровне.
• L3 — архитектурная. Тимлид, архитектор, основной автор системы. Подключается к сложным инцидентам, постмортемам, рефакторингу под нагрузку.

Если вы не можете позволить себе три уровня — соберите хотя бы L1 на стороне заказчика (саппорт-менеджер) и L2 на стороне разработчика. L3 может быть «по запросу».

On-call ротация и каналы алертов

24/7 невозможно одним человеком — выгорание гарантированно. Минимум для устойчивой ротации — 3 инженера, оптимально 4–5. Стандартные модели:

• Follow-the-sun. Команда распределена по часовым поясам (например, Калининград + Москва + Владивосток). Каждый дежурит в своё рабочее время.
• Сменный график. Три 8-часовые смены или две 12-часовые. Подходит для крупных операционных команд.
• Недельная ротация on-call. Один инженер в неделю основной, второй — резервный. Самая популярная модель в студиях.

Инструменты ротации:

• PagerDuty — отраслевой стандарт, дорогой, заблокирован для оплаты из РФ без обходов.
• OpsGenie (Atlassian) — аналогично, требует обходных платежей.
• Grafana OnCall — open-source, бесплатно, ставится на свой сервер. Поддерживает звонки, SMS через Twilio, Telegram.
• Кастом-бот для дежурного — самая частая практика в РФ. Свой Telegram-бот рассылает алерты в личку текущему дежурному, эскалирует в группу при отсутствии acknowledge за N минут.

Каналы алертов выстраиваются по приоритетам:

• P0 — звонок на телефон + push в кастом-бот + дублирование SMS, если acknowledge не пришёл за 5 минут.
• P1 — push в Telegram, эскалация на звонок через 15 минут.
• P2/P3 — обычное сообщение в дежурный чат, без эскалации.

Без телефонного канала ночные алерты теряются — спящий человек не услышит мессенджер на беззвучном телефоне.

Мониторинг и health-checks

Без автоматического мониторинга 24/7 не работает — дежурный физически не сидит и не смотрит на логи.

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

• Prometheus — сбор метрик (RPS, latency, ошибки, активные пользователи, успешные платежи).
• Alertmanager — правила алертинга, дедупликация, маршрутизация по уровням.
• Grafana — дашборды для дежурного и для разбора инцидентов задним числом.
• Loki или ELK — централизованные логи с поиском.
• Синтетические проверки — внешний пинг с реальными сценариями: Yandex Cloud Monitoring, UptimeRobot, Pingdom.

Health-check эндпойнт /healthz отдаёт JSON со статусом по компонентам:

{
  "status": "ok",
  "checks": {
    "db": "ok",
    "redis": "ok",
    "telegram_api": "ok",
    "payment_provider": "degraded"
  },
  "uptime_sec": 184320,
  "version": "1.42.3"
}

Минимум проверяется: соединение с БД, Redis, доступность Telegram Bot API (getMe), доступность критичных внешних сервисов (платежи, SMS, CRM). Синтетический мониторинг дёргает /healthz каждые 30–60 секунд и алертит при двух подряд неудачах.

Отдельно полезно дёргать getWebhookInfo через минуту — поле pending_update_count больше нескольких сотен означает, что бот не успевает обрабатывать обновления.

Runbook: типовые аварии

Runbook — пошаговая инструкция дежурного для типовой аварии. Цель — чтобы новый человек на смене закрыл инцидент без эскалации.

Пример runbook «Бот не отвечает пользователям»:

1. Открыть Grafana → дашборд «Bot health».
2. Проверить getWebhookInfo: если last_error_message не пустой — Telegram не может достучаться до webhook. Проверить TLS-сертификат, доступность домена.
3. Если webhook ок — проверить логи приложения за последние 10 минут: ошибки, паники, рестарты.
4. Проверить метрики CPU/Memory — если упёрлись в потолок, сделать вертикальный скейл.
5. Проверить очередь на Redis: если pending_updates > 1000 — бот не успевает, нужен горизонтальный скейл.
6. Если ничего из этого — рестарт сервиса (docker compose restart bot). Дать 60 секунд на стабилизацию.
7. Если не помогло за 15 минут — эскалация на L3.

На каждую типовую аварию должен быть свой runbook: «не приходят платежи», «сломалась рассылка», «упала БД», «отвалилась учётная система». Без runbook каждый инцидент превращается в детектив.

Постмортемы (blameless)

После каждого P0 и значимого P1 пишется постмортем — разбор причин и план предотвращения. Главное правило — blameless: ищем системную причину, а не виноватого.

Минимальная структура:

• Что произошло. Хронология с точностью до минут.
• Влияние. Сколько пользователей пострадало, на какую сумму, как долго.
• Корневая причина. Не «забыл проверить», а «нет автоматического теста на эту регрессию».
• Что сработало. Что в системе/процессе помогло быстро локализовать проблему.
• Что не сработало. Где потеряли время, чего не хватило.
• План действий. Конкретные тикеты с дедлайнами и ответственными.

Постмортем без action items — потерянное время. Если тот же инцидент повторился — действия из предыдущего постмортема либо не сделаны, либо сделаны не так.

Каналы обращения от пользователей

Откуда инциденты вообще приходят:

• Автоматический мониторинг. Самый ценный — ловит проблемы до пользователей.
• Сами пользователи в боте. Команда /help или кнопка «Связаться с поддержкой» создаёт тикет.
• Менеджеры заказчика. Выделенный Telegram/Slack-чат с командой разработки.
• Соцсети и отзывы. Нужен мониторинг бренда (Brand Analytics, IQBuzz).
• Чарджбеки от банка. Отдельный канал, если есть платежи.

Все обращения сводятся в одну тикет-систему — иначе они теряются в чатах.

Тикет-системы и user-facing support

Когда обращений становится много, чат уже не справляется. Нужна CRM для тикетов с интеграцией в Telegram.

Архитектурно: бот эскалирует пользователя на «живого оператора» через специальную команду, тикет-система получает обращение через webhook, оператор отвечает из своего интерфейса, ответ возвращается пользователю в тот же бот. Пользователь не видит границы между ботом и оператором.

Внутренний саппорт vs аутсорс vs студия

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

А что про SaaS-конструкторы

SaaS-конструкторы (Salebot, BotHelp, ChatForma и т.п.) поддержку организуют по своей модели:

• Часы — обычно 9:00–21:00 МСК, будни. Иногда суббота.
• SLA — рекламируется, но юридически не зафиксирован для тарифов до Enterprise.
• Реакция на тикет — от 30 минут до суток в зависимости от тарифа.
• Дебаг сценариев самим клиентом — через документацию и комьюнити.
• Аварии платформы (упал общий сервис) — общий канал статуса, без персональных гарантий.

Это нормально для тестов и микропроектов. Для коммерческого бота с оборотом — недостаточно: нет персонального дежурного, нет ответственности за ваш конкретный сценарий, нет доступа к логам своего бота на достаточной глубине.

Регламент инцидентов: пошаговый поток

1. Получение алерта или обращения. Тикет заводится автоматически или дежурным.
2. Классификация P0–P3. Дежурный ставит уровень в течение 5 минут.
3. Acknowledge. Дежурный подтверждает, что взял в работу — алерт перестаёт эскалироваться.
4. Уведомление команды и заказчика. Для P0 — сразу, для P3 — на следующий рабочий день. Шаблон сообщения: «P0, бот не принимает платежи, начали диагностику, ETA через 30 минут».
5. Расследование. Логи, метрики, недавние релизы, runbook.
6. Митигация. Откат релиза, временный воркэраунд, hot-fix, отключение проблемной фичи через feature flag.
7. Резолюция. Постоянное исправление с тестом на регрессию.
8. Коммуникация заказчику об устранении с краткой выжимкой произошедшего.
9. Постмортем для P0/P1 в течение 3 рабочих дней.

Если шаг 4 пропустить, заказчик узнает об аварии из соцсетей — это худший сценарий.

Стоимость поддержки

Реальные цены на поддержку Telegram-бота на российском рынке.

Из чего складывается цена 24/7:

• Дежурный инженер. При ставке 3000–5000 ₽ за смену и 30 сменах в месяц — 90–150 тр на одного человека. Минимум 3 человека в ротации, итого 270–450 тр на ФОТ дежурных.
• Инфраструктура мониторинга. Prometheus + Grafana + Loki на отдельной VM — 5–15 тр/мес. Внешние синтетические проверки — 1–5 тр/мес.
• Тикет-система. 2–4 оператора по 1500 ₽ — 3–6 тр/мес.
• Резерв на инциденты. Часы L3 при необходимости.
• Маржа студии. Обычно 20–30% сверху.

При ставке выше или больше параллельных проектов в портфеле дежурного цена шкалируется в обе стороны.

SLA в договоре: ответственность за нарушение

Реальный SLA в договоре включает не только метрики, но и санкции.

• Штраф за час простоя сверх SLA. Обычно 5–15% от месячной стоимости поддержки за каждый час сверх плана, потолок — 100% месячной стоимости.
• Возврат части абонентской платы при недостижении uptime: например, при 99.0% вместо 99.5% возврат 25%, при 98% и ниже — 50%.
• Отказ от штрафа при форс-мажоре: авария у Telegram, авария у хостинг-провайдера, действия третьих лиц, изменения регулирования.
• Право расторжения заказчиком без штрафа при 3 нарушениях SLA подряд.

Без санкций SLA — бумажка. С санкциями — реальный финансовый стимул не сваливаться.

Что НЕ входит в поддержку

Чтобы избежать конфликтов, в договоре чётко перечисляется, чего поддержка не делает.

• Разработка нового функционала (это отдельный бюджет).
• Изменения, требующие более N часов работы — выносятся в проект.
• Сторонние сервисы (платежи, Telegram, SMS-провайдер) — мы реагируем, но не отвечаем за их аптайм.
• Архитектурный рефакторинг под новые требования.
• Миграция на новые версии платформ.
• Обучение сотрудников заказчика работе с админкой.

Метрики поддержки

Что измеряем ежемесячно и куда смотрим, если цифра ползёт не туда.

• MTTD (Mean Time To Detect) — от факта аварии до алерта. Если растёт — провисает мониторинг.
• MTTA (Mean Time To Acknowledge) — от алерта до взятия в работу. Если растёт — проблемы с ротацией или каналами уведомлений.
• MTTR (Mean Time To Resolve) — от взятия в работу до устранения. Если растёт — нужны runbook и тренировки.
• MTBF (Mean Time Between Failures) — между сбоями. Если падает — нестабильная архитектура, время на рефакторинг.
• % инцидентов в SLA. Цель — выше 95%.
• Доступность по факту vs SLA.
• Количество инцидентов по уровням за месяц.
• CSAT (опрос после закрытия тикета).

Если P0-инцидентов больше 1–2 в месяц — это не операционная проблема, а архитектурная. Время не в дежурного вкладывать, а в код.

База знаний и автозамены

Часть обращений повторяется. Хорошая база знаний снимает 30–50% нагрузки.

• Внутренний wiki (Notion, Confluence, YouTrack KB) с типичными проблемами и решениями.
• Шаблоны ответов пользователям в тикет-системе.
• Скрипты для частых операций (выгрузка логов, рестарт сервиса, отправка чека повторно).
• FAQ в самом боте — закрывает топ-10 вопросов до того, как они придут в саппорт.

Итого

24/7-поддержка Telegram-бота строится на трёх элементах: автоматический мониторинг с алертами, чёткий регламент инцидентов с классификацией P0–P3 и runbook, ротация дежурных с эскалацией. Реалистичные SLA: 99.5% доступности, 15 минут реакции на P0 в премиум-пакете, 4 часа на решение. Стоимость — от 30 тр за базовую 8/5-поддержку до 500 тр за полное 24/7 с штрафами в договоре. SaaS-конструкторы дают 9–21 будни без персонального SLA — для коммерческого бота с оборотом этого мало. Студия с retainer-моделью обычно оптимальна для среднего и небольшого проекта: те же люди пишут и поддерживают, фикс-цена, готовая ротация. Без поддержки коммерческий бот деградирует — это самая частая причина «бот умер через год после запуска».

Частые вопросы

Что такое SLA для Telegram-бота и зачем он нужен?+

SLA — соглашение об уровне обслуживания. Фиксирует доступность сервиса (uptime), например 99.5% в месяц = до 3.6 часов простоя; время реакции на инцидент (TTR), например 15 минут на критичные; время решения инцидента, например 4 часа на критичные, 24 часа на средние; часы поддержки (24/7, 8/5, 16/7); RPO/RTO для данных; санкции за нарушение — штраф за каждый час простоя сверх SLA или процент возврата абонентской платы. Без SLA любая поддержка превращается в «когда сможем». С SLA есть понятные ожидания, метрики и санкции.

Чем отличаются режимы 8/5, 8/7, 24/5 и 24/7 и какой выбрать?+

8/5 — будни 09:00–18:00, 30–80 тр/мес, подходит для внутренних B2B-ботов и low-traffic. 8/7 — каждый день в рабочие часы, 60–120 тр, подходит для контентных ботов с вечерней активностью. 24/5 — будни круглосуточно, 100–180 тр, для B2B со сменной работой клиентов. 24/7 — без перерывов, 200–500 тр, оправдано для e-commerce, fintech, медицины и прод-критики. Если у вас бот для записи к врачу — нужен 24/7, если бот для согласования отпусков сотрудников — 8/5 более чем достаточно.

Как классифицировать инциденты Telegram-бота по P0–P3?+

P0 (критический) — бот лежит, не принимает платежи, основной сценарий полностью сломан. Реакция минуты, эскалация моментальная. P1 (высокий) — ключевой функционал не работает (например, не отправляются уведомления, отвалился один платёжный метод). Реакция час, решение в течение суток. P2 (средний) — некритичный баг (кривая верстка в Mini App, неточный текст в редком сценарии). Решение в плановом релизе. P3 (низкий) — косметика, опечатки. В бэклог. Чёткая классификация позволяет дежурному не будить команду в 3 ночи из-за опечатки в кнопке.

Какие уровни поддержки L1, L2, L3 и кто чем занимается?+

L1 — пользовательская: принимает обращения от конечных пользователей в боте, решает 60–80% типовых проблем по runbook (отправить чек повторно, проверить статус заказа), остальное эскалирует. L2 — инженерная: дежурный разработчик, дебажит код, смотрит логи, перезапускает сервисы, делает hot-fix; большинство P0/P1 закрывается на этом уровне. L3 — архитектурная: тимлид, архитектор, основной автор системы; подключается к сложным инцидентам, постмортемам, рефакторингу под нагрузку. Если три уровня не по бюджету — соберите хотя бы L1 на стороне заказчика и L2 на стороне разработчика.

Как организовать дежурные смены и on-call ротацию?+

Минимум для устойчивой ротации — 3 инженера, оптимально 4–5. Модели: follow-the-sun (команда распределена по часовым поясам), сменный график (три 8-часовые смены или две 12-часовые), недельная ротация on-call (один основной, второй резервный — самая популярная). Инструменты: PagerDuty и OpsGenie (заблокированы для оплаты из РФ без обходов), Grafana OnCall (open-source, бесплатно), кастом-бот для дежурного (самая частая практика в РФ — рассылает алерты в личку и эскалирует в группу при отсутствии acknowledge за N минут). P0 — звонок на телефон + push, P1 — push с эскалацией на звонок через 15 минут, без телефонного канала ночные алерты теряются.

Какой мониторинг и health-checks нужны для поддержки 24/7?+

Минимальный стек — Prometheus (метрики), Alertmanager (алерты), Grafana (дашборды), Loki или ELK (логи), синтетические проверки извне (Yandex Cloud Monitoring, UptimeRobot, Pingdom). Health-check эндпойнт /healthz отдаёт JSON со статусом по компонентам — БД, Redis, Telegram Bot API через getMe, критичные внешние сервисы. Синтетика дёргает /healthz каждые 30–60 секунд и алертит при двух подряд неудачах. Полезно дёргать getWebhookInfo — поле pending_update_count больше нескольких сотен означает, что бот не успевает обрабатывать обновления, нужен скейл.

Сколько стоит поддержка Telegram-бота 24/7 и из чего складывается цена?+

Lite (8/5, TTR 4 часа): 30–80 тр. Standard (8/7, TTR 1 час): 80–160 тр. Pro (16/7, TTR 30 минут): 160–250 тр. Enterprise (24/7, TTR 15 минут, SLA с штрафами): 250–500 тр. Из чего складывается 24/7: дежурный инженер при ставке 3–5 тр за смену и 30 сменах — 90–150 тр на человека, минимум 3 в ротации, итого 270–450 тр на ФОТ; инфраструктура мониторинга 5–15 тр; внешние синтетические проверки 1–5 тр; тикет-система 3–6 тр; резерв на L3 при необходимости; маржа студии 20–30%. SaaS-конструкторы (Salebot и т.п.) дают 9–21 будни без персонального SLA — для коммерческого бота с оборотом этого мало.