Обращения клиентов растворяются в чате
Заявка уходит в общий чат вместе с обсуждением релиза: непонятно, кто взял её в работу, какой срок и что уже сделано. Клиент пишет повторно, а иногда уходит.
Выделенная поддержка
Команда поддержки знает ваш продукт не по документации
Берём продукт на сопровождение с фиксированными цифрами: реакция от 15 минут на критичный инцидент, дежурство в нерабочее время, план доработок на месяц и отчёт по каждому обращению.
Или сразу: +7 (962) 368-39-51 Telegram
15 мин
реакция на критичный инцидент
24/7
дежурства и эскалация
1 команда
те же инженеры, что писали код
99,9%
целевая доступность сервиса
Что происходит, когда продукт остался без поддержки
Знакомые ситуации из проектов, которые приходили к нам на сопровождение после паузы в работе с подрядчиком или после ухода внутреннего разработчика.
Ушёл единственный, кто знал архитектуру
Разработчик, который писал продукт три года, больше не отвечает. Доступы к панелям, схема интеграций и порядок деплоя восстанавливаются по памяти коллег.
Хотфикс уезжает в прод без регрессии
Правку в пятницу вечером выкладывают «по-быстрому» одним файлом: ломается оформление заказа, и узнают об этом из звонков, а не из мониторинга.
Бюджет поддержки непредсказуем
Часы нигде не учитываются, счёт приходит «по факту», а состав работ обсуждается задним числом. Планировать расходы на квартал невозможно.
Доработки копятся, а приоритет неясен
Список пожеланий живёт в переписке: бизнес просит одно, клиенты другое, техдолг третье. В итоге делается то, о чём громче попросили в последний раз.
Ночной инцидент некому поднять
В три часа ночи упал обмен с 1С или платёжный шлюз, и реагировать некому: телефона дежурного нет, регламент эскалации не написан, утром разбор начинается с нуля.
Как устроено сопровождение
Четыре блока, из которых собирается договор поддержки. Состав и уровни сервиса согласуем до подписания.
Уровни сервиса
Разделяем время реакции и время решения для разных приоритетов: это разные обязательства, и путать их нельзя.
- Критичный инцидент: реакция 15 минут, работы до восстановления — круглосуточно
- Высокий приоритет: реакция 2 рабочих часа, решение в течение рабочего дня
- Обычная задача: реакция в течение рабочего дня, планирование в ближайший спринт
- Отчёт раз в месяц: обращения, часы, соблюдение SLA по каждому пункту
Дежурства и эскалация
Работаем по графику дежурных инженеров, а не по принципу «кто первым увидел письмо».
- График дежурств на неделю вперёд с известными вам именами
- Алерт из мониторинга идёт в дежурный канал, а не на общий ящик
- Эскалация на ведущего инженера и техдира, если инцидент не закрыт в срок
- Разбор инцидента с причинами и мерами, чтобы он не повторился
Бэклог и развитие продукта
Поддержка — это не только тушение пожаров: собираем задачи бизнеса и клиентов в один приоритизированный список.
- Груминг бэклога вместе с владельцем продукта раз в две недели
- Оценка задачи в часах до начала работ, а не после
- Релизный цикл раз в одну-две недели с возможностью внепланового хотфикса
- Демонстрация результата и приёмка по согласованному чек-листу
Передача знаний
Поддержка не должна зависеть от одного человека — ни от вашего, ни от нашего.
- Актуальная схема архитектуры, список сервисов и внешних интеграций
- Runbook по типовым операциям: деплой, откат, восстановление, ротация ключей
- Реестр доступов с владельцами и сроками пересмотра
- Ввод нового инженера в проект за несколько дней, а не за месяцы
Как начинается сопровождение
Первый месяц — самый важный: за него мы приводим систему в состояние, которое можно поддерживать по регламенту.
-
01 5–10 дней
Приёмка и аудит
Получаем доступы, восстанавливаем схему архитектуры, проверяем мониторинг, бэкапы и состояние зависимостей. Фиксируем риски на входе.
-
02 3–5 дней
Соглашение об уровне сервиса
Определяем приоритеты обращений, время реакции и решения, календарь дежурств, каналы связи и порядок эскалации.
-
03 первый месяц
Приведение в порядок
Закрываем критичный техдолг, обновляем зависимости, настраиваем логирование и алерты, делаем деплой предсказуемым.
-
04 ежемесячно
Регулярный цикл
Работаем спринтами: инциденты, доработки, плановые работы. В конце месяца — отчёт по часам и планирование следующего.
Что входит в договор сопровождения
Договор состоит из трёх частей: реакция на инциденты, плановое обслуживание и доработки. Реакция — это гарантированное время до начала разбора, плановое обслуживание — обновления, бэкапы, мониторинг и профилактика, доработки — согласованный пул часов на задачи развития. Разделение важно: инциденты не должны вытеснять плановые работы, иначе система постепенно деградирует.
В месячный отчёт попадают все обращения с приоритетом, временем реакции и временем решения, а также список выполненных плановых работ и остаток часов. Такой отчёт позволяет владельцу продукта видеть, на что уходит бюджет поддержки, и при необходимости менять баланс между стабильностью и развитием.
Сколько стоит выделенная поддержка
Стоимость складывается из двух величин: гарантированного пула часов и требований к уровню сервиса. Пул часов определяет объём работ в месяц — от минимального сопровождения с реакцией в рабочее время до полноценной команды с дежурством 24/7, выделенным ведущим инженером и участием в планировании релизов.
Дежурство в нерабочие часы и время реакции менее часа заметно влияют на цену, потому что требуют резерва людей, а не только часов. Поэтому мы обычно предлагаем начать с реакции в рабочее время и включать круглосуточный режим только для сервисов, простой которых действительно стоит денег, — например, для платежей и оформления заказов.
Что считается критичным инцидентом
Критичный инцидент — это полная или частичная недоступность ключевого сценария: не оформляется заказ, не проходит оплата, не работает вход в личный кабинет, остановился обмен с 1С. Второй критерий критичности — потеря или искажение данных, а также подозрение на компрометацию.
Мы описываем критерии вместе с вами до начала работ и привязываем к ним конкретные сценарии вашего продукта, а не абстрактные формулировки. Это снимает главный спор в поддержке: заказчик считает критичным всё, исполнитель — ничего. Если сценарий перечислен в согласованном списке, он получает время реакции 15 минут автоматически.
Частые вопросы
Разовые обращения не дают гарантий: сроки зависят от загрузки, знания о продукте накапливаются медленно, а ответственность за простой не зафиксирована. Договор с SLA задаёт время реакции и решения по каждому приоритету, закрепляет дежурства и эскалацию, а также включает плановые работы — обновления, бэкапы и мониторинг, — которые при разовой модели просто не делаются.
Да, для работы с инцидентами доступ к продакшену необходим, но он оформляется по правилам: отдельные учётные записи для каждого инженера, второй фактор, права по принципу минимально необходимых, журналирование действий. Личные аккаунты и общие пароли не используются. При прекращении работ доступы отзываются в тот же день, а список выданных доступов вы видите в реестре.
Да, это типовой сценарий. Первый этап — приёмка: мы восстанавливаем схему архитектуры, читаем код, проверяем состояние мониторинга, бэкапов и зависимостей. Обычно приёмка занимает от пяти до десяти рабочих дней, после чего мы называем реальный объём технического долга и предлагаем план его закрытия. Иногда выясняется, что часть системы придётся переписать — об этом мы говорим сразу, а не через полгода.
Работает эскалация: через согласованный интервал подключается ведущий инженер, затем технический директор, и вы получаете уведомление о смене уровня. Если время решения по критичному инциденту превышено, мы фиксируем это в отчёте, объясняем причину и компенсируем часы. Отдельно проводим разбор инцидента: что стало причиной, какие меры предотвратят повтор, и включаем их в план работ.
Поддержка и обслуживание: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Возьмём ваш продукт на сопровождение
Опишите текущее состояние и требования к времени реакции — предложим состав команды, уровни SLA и стоимость месяца.