Цифровые сервисы: гид

Как проверить поддержку цифрового сервиса после запуска: SLA, безопасность, обновления и оплата

Автор и проверка: Алексей Воронов, редакционный координатор ormobil.com · Факты, документы, риски и применимость · Обновлено: 04 сентября 2025 г.

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

Критерии выбора

После запуска цифровой сервис — сайт, личный кабинет, мобильное приложение, CRM-модуль, сервис записи, платформа для заказов или внутренний программный продукт — начинает зависеть не только от качества разработки, но и от поддержки. Ошибка в оплате хостинга, просроченный сертификат, неустановленное обновление или потерянный доступ администратора могут остановить продажи, записи, доставку или работу сотрудников.

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

Таблица проверки

| Что проверить | Нормальный вариант | Рискованный вариант |

|---|---|---|

| SLA | Есть документ с временем реакции и восстановления | Только устное обещание «ответим быстро» |

| Каналы связи | Почта, тикет-система, мессенджер для срочных случаев, телефон для аварий | Один личный чат с менеджером |

| Время реакции | Например, 15–60 минут для критических сбоев, 4–8 часов для обычных задач | Нет разделения по срочности |

| Резервные копии | Ежедневно или чаще, с тестом восстановления | «Бэкапы где-то есть», но никто не проверял |

| Безопасность | 2FA, журнал доступов, разграничение ролей, обновления | Один общий логин для всех |

| Обновления | Плановые окна, тестовый контур, откат версии | Обновления ставятся сразу на рабочий сервис |

| Оплата | Отдельно указаны поддержка, хостинг, лицензии, доработки, комиссии | Единая сумма без расшифровки |

| Права | В договоре прописано, кому принадлежат код, дизайн, база, документация | Подрядчик хранит всё у себя и не передает доступы |

| Документы | Договор, SLA, акт, регламент поддержки, техническое задание, смета | Работы идут по переписке без приложений |

1. SLA: что должно быть прописано

SLA — это не просто «гарантия поддержки», а соглашение об уровне сервиса. В нем нужно зафиксировать:

• категории инцидентов: критический, высокий, средний, низкий;

• время реакции;

• время восстановления;

• график поддержки: 5/2, 8/5, 12/7 или 24/7;

• каналы обращения;

• ответственность сторон;

• исключения: например, сбои у внешнего платежного провайдера или облачного сервиса;

• порядок компенсаций или перерасчета, если SLA не соблюден.

Пример рабочих ориентиров:

| Тип инцидента | Пример | Реакция | Восстановление |

|---|---|---:|---:|

| Критический | Не работает оплата, сервис недоступен | 15–30 минут | 2–4 часа |

| Высокий | Ошибка в личном кабинете, сбой авторизации | 1 час | 4–8 часов |

| Средний | Некорректный отчет, ошибка в уведомлениях | 4 часа | 1–2 рабочих дня |

| Низкий | Косметическая правка, текст, мелкая настройка | 1 рабочий день | 3–7 дней |

Если подрядчик обещает поддержку 24/7, уточните, что именно входит: только мониторинг сервера или полноценная работа разработчика, администратора и DevOps-инженера.

2. Каналы связи и порядок заявок

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

• тикет-система или сервис заявок;

• выделенная почта для поддержки;

• аварийный канал для критических сбоев;

• правила постановки задач;

• шаблон заявки: что сломалось, когда началось, какие пользователи затронуты, есть ли скриншоты или логи;

• номер договора или проекта;

• ответственный со стороны клиента.

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

3. Безопасность: доступы, роли и журналы

После запуска часто забывают удалить временные доступы, тестовые аккаунты и права бывших сотрудников. Это один из главных рисков для цифрового сервиса.

Проверьте:

• включена ли двухфакторная аутентификация для админ-панели, облака, репозитория, CRM, платежного кабинета;

• нет ли общих логинов вида admin/admin или одной учетной записи на всю команду;

• есть ли разделение ролей: владелец, администратор, оператор, бухгалтер, разработчик;

• ведется ли журнал входов и действий;

• кто имеет доступ к базе данных;

• где хранятся пароли: в менеджере паролей или в таблице/чате;

• кто может выгружать персональные данные клиентов;

• как отключаются доступы у уволенных сотрудников и подрядчиков.

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

4. Резервные копии и восстановление

Резервная копия ценна только тогда, когда ее можно восстановить. Поэтому недостаточно услышать «бэкапы настроены».

Минимальный набор вопросов:

• как часто создаются копии: раз в сутки, каждые 6 часов, каждый час;

• что копируется: база, файлы, настройки, медиа, конфигурации сервера;

• где хранятся копии: на том же сервере или отдельно;

• сколько дней хранится архив: 7, 14, 30, 90 дней;

• кто отвечает за восстановление;

• сколько времени занимает восстановление;

• когда последний раз проверяли восстановление на тестовом контуре.

Полезные метрики:

• RPO — сколько данных можно потерять при аварии. Например, RPO 1 час означает, что при сбое можно потерять данные максимум за последний час.

• RTO — за сколько времени сервис должен вернуться в работу. Например, RTO 4 часа означает, что восстановление должно занять не больше четырех часов.

Если сервис принимает заказы, оплаты или заявки, ежедневного бэкапа может быть мало. Для активных проектов лучше рассмотреть копирование каждые 1–6 часов.

5. Обновления и совместимость

Цифровой сервис не остается неизменным после запуска. Обновляются операционные системы, фреймворки, SDK, платежные модули, API банков, push-сервисы, карты, аналитика, мобильные платформы.

Уточните:

• кто отслеживает критические обновления;

• как быстро закрываются уязвимости;

• есть ли тестовый контур;

• кто проверяет сервис после обновления;

• можно ли откатиться на предыдущую версию;

• как согласуются обновления, влияющие на интерфейс или бизнес-логику;

• входит ли обновление мобильного приложения в стоимость поддержки;

• кто оплачивает публикацию, сборку и проверку в магазинах приложений.

Практический ориентир: плановые обновления лучше проводить в заранее согласованные окна — например, ночью или в период минимальной нагрузки. Для B2B-сервиса это может быть вечер пятницы или выходной, для e-commerce — наоборот, не время распродаж и пиковых заказов.

6. Оплата поддержки и скрытые расходы

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

Частые модели оплаты:

| Модель | Когда подходит | Что проверить |

|---|---|---|

| Абонентская поддержка | Сервис работает постоянно, есть регулярные обращения | Сколько часов входит, что считается переработкой |

| Почасовая оплата | Задачи возникают редко | Минимальный счет, ставка, сроки реакции |

| Пакет часов | Есть понятный объем мелких задач | Сгорают ли часы, можно ли переносить остаток |

| SLA 24/7 | Критичный сервис: заказы, оплаты, логистика, медицина, финтех | Есть ли дежурная команда, а не только автоответчик |

| Разовая гарантия после запуска | Небольшой проект, короткий период проверки | Что считается гарантийной ошибкой |

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

• базовая поддержка небольшого сервиса: от 15 000–40 000 ₽ в месяц;

• поддержка с регулярными доработками: 50 000–150 000 ₽ в месяц;

• критичный сервис с SLA и дежурством: от 150 000 ₽ в месяц и выше;

• почасовая ставка специалиста: часто 1 500–5 000 ₽/час в зависимости от роли и стека;

• срочные аварийные работы могут иметь коэффициент 1,5–2 к обычной ставке.

Отдельно проверьте расходы, которые часто не входят в поддержку:

• домен;

• хостинг или облачная инфраструктура;

• SSL-сертификаты, если используются платные;

• SMS, email-рассылки, push-уведомления;

• платежный шлюз и комиссии;

• лицензии CMS, CRM, карт, аналитики, чатов;

• хранение файлов и резервных копий;

• публикация и сопровождение мобильных приложений;

• внешние API и интеграции.

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

7. Документы, которые нужно запросить

До передачи сервиса в эксплуатацию запросите не только акт выполненных работ, но и комплект эксплуатационных документов.

Минимальный набор:

• договор на разработку или сопровождение;

• SLA или регламент поддержки;

• техническое задание;

• смета с расшифровкой работ;

• акт запуска или акт приемки;

• инструкция администратора;

• список доступов и владельцев учетных записей;

• схема инфраструктуры;

• описание резервного копирования;

• регламент обновлений;

• порядок обработки персональных данных;

• перечень внешних сервисов и платежей;

• гарантийные условия;

• порядок передачи прав на код, дизайн, базу данных, документацию.

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

Когда поддержка не подходит и что может пойти не так

Даже дорогая поддержка может быть неподходящей, если она не соответствует вашему режиму работы.

Поддержка не подходит, если:

• сервис работает 24/7, а подрядчик отвечает только по будням с 10:00 до 18:00;

• бизнес зависит от оплат, но платежные сбои не выделены как критические;

• нет ответственного за серверы и облако;

• нет тестового контура;

• доработки оплачиваются отдельно, но граница между ошибкой и новой задачей не прописана;

• подрядчик не передает доступы и документацию;

• мобильное приложение есть, но поддержка публикаций и обновлений не включена;

• команда не работает с вашим стеком технологий;

• нет процедуры экстренного восстановления.

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки. В цифровых сервисах к этому добавляются устаревшие библиотеки, зависимость от одного разработчика, неподконтрольный хостинг, неоформленные права на код и отсутствие резервных копий.

Что может случиться на практике:

• сервис перестает принимать оплату после изменения API банка;

• мобильное приложение не проходит обновление из-за устаревшего SDK;

• администратор случайно удаляет данные, а рабочей резервной копии нет;

• подрядчик уходит, а доступ к репозиторию оформлен на его личную почту;

• стоимость поддержки резко растет, потому что в договоре не указаны тарифы на доработки;

• исправление небольшой ошибки занимает неделю, потому что SLA не различает критичные и обычные задачи;

• пользовательские данные выгружаются без контроля ролей.

Сравнение вариантов

Вариант 1. Поддержка у разработчика, который запускал сервис

Это часто самый удобный вариант: команда знает архитектуру, историю решений, интеграции и слабые места.

Плюсы:

• быстрее разбираются в ошибках;

• меньше времени на ввод в проект;

• проще исправлять гарантийные дефекты;

• уже есть доступ к коду и инфраструктуре.

Минусы:

• может быть зависимость от одного подрядчика;

• стоимость доработок не всегда прозрачна;

• подрядчик может не иметь сильной DevOps- или security-команды;

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

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

Вариант 2. Отдельная команда технической поддержки

Подходит для растущих сервисов, где нужно постоянное сопровождение, мониторинг, регламенты и понятная отчетность.

Плюсы:

• формальный процесс заявок;

• регулярные отчеты;

• контроль SLA;

• возможна поддержка 12/7 или 24/7;

• легче разделить эксплуатацию и разработку новых функций.

Минусы:

• потребуется передача знаний;

• нужен аудит кода и инфраструктуры перед стартом;

• часть ошибок может быть сложно исправить без участия исходного разработчика;

• старт поддержки может занять 1–4 недели.

Перед переходом запросите аудит: код, серверы, базы, бэкапы, интеграции, документацию, права и задолженности по лицензиям.

Вариант 3. Внутренняя команда

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

Плюсы:

• максимальный контроль;

• знания остаются внутри компании;

• быстрее принимаются продуктовые решения;

• проще управлять безопасностью и доступами.

Минусы:

• высокая стоимость найма;

• нужны разные роли: backend, frontend, mobile, DevOps, QA, аналитик;

• отпуск, болезнь или увольнение сотрудника создают риски;

• требуется управление процессами.

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

Вариант 4. Минимальная гарантия без абонентской поддержки

Такой вариант возможен для небольшого лендинга, простого сайта-визитки или сервиса без критичных операций.

Плюсы:

• низкая стоимость;

• не нужно платить ежемесячно;

• подходит для редких изменений.

Минусы:

• нет гарантированного времени реакции;

• обновления и безопасность могут выпасть из контроля;

• аварии решаются «когда будет свободный специалист»;

• нет постоянного мониторинга.

Не подходит для сервисов, где простой даже на 2–4 часа приводит к потере заявок, оплат, записей или репутации.

SLA и ответственность

• [ ] Есть отдельный документ SLA или регламент поддержки.

• [ ] Указаны категории инцидентов.

• [ ] Прописано время реакции и восстановления.

• [ ] Указан график поддержки: 5/2, 8/5, 12/7 или 24/7.

• [ ] Есть порядок эскалации аварий.

• [ ] Понятно, кто отвечает за внешние сервисы: хостинг, платежи, SMS, email, карты.

Заявки и коммуникация

• [ ] Есть тикет-система или другой фиксируемый канал.

• [ ] Указаны контактные лица с обеих сторон.

• [ ] Срочные обращения не теряются в личных чатах.

• [ ] Есть шаблон постановки задачи.

• [ ] Все правки фиксируются письменно.

Безопасность

• [ ] Включена двухфакторная аутентификация.

• [ ] Нет общих логинов.

• [ ] Разделены роли пользователей.

• [ ] Ведется журнал действий.

• [ ] Доступы бывших сотрудников и временных подрядчиков отключены.

• [ ] Пароли хранятся в защищенном менеджере.

• [ ] Есть порядок работы с персональными данными.

Резервные копии

• [ ] Известна частота бэкапов.

• [ ] Копируются база, файлы и настройки.

• [ ] Бэкапы хранятся отдельно от основного сервера.

• [ ] Указан срок хранения копий.

• [ ] Проверено восстановление.

• [ ] Зафиксированы RPO и RTO.

Обновления

• [ ] Есть тестовый контур.

• [ ] Обновления проходят проверку перед продакшеном.

• [ ] Есть план отката.

• [ ] Указаны окна обновлений.

• [ ] Критические уязвимости закрываются по отдельному регламенту.

• [ ] Для мобильных приложений прописан порядок сборки и публикации.

Оплата

• [ ] Смета разделяет поддержку, развитие и внешние расходы.

• [ ] Указана стоимость часа или пакета часов.

• [ ] Понятно, сгорают ли неиспользованные часы.

• [ ] Срочные работы имеют заранее известный коэффициент.

• [ ] Отдельно указаны домены, хостинг, лицензии, SMS, платежные комиссии.

• [ ] Есть условия перерасчета при нарушении SLA.

Права и передача

• [ ] Указано, кому принадлежат код, дизайн, база данных и документация.

• [ ] Репозиторий оформлен на компанию, а не на личный аккаунт подрядчика.

• [ ] Доступы передаются владельцу бизнеса.

• [ ] Есть инструкция администратора.

• [ ] Есть схема инфраструктуры.

• [ ] Подписан акт приемки с перечнем переданных материалов.

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

Что важнее после запуска: SLA или гарантия?

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

Какой срок гарантии считать нормальным?

Для небольших цифровых проектов часто встречается гарантия 14–30 дней после приемки. Для более сложных сервисов можно согласовать 60–90 дней на исправление дефектов, выявленных после запуска. Но гарантия не должна заменять поддержку, обновления и резервное копирование.

Что должно входить в ежемесячную поддержку?

Обычно входят консультации, исправление ошибок, мониторинг, мелкие настройки, проверка доступности, контроль резервных копий, установка критических обновлений и ограниченный объем работ в часах. Новые функции, редизайн, крупные интеграции и изменение бизнес-логики чаще оплачиваются отдельно.

Как понять, что подрядчик завышает стоимость поддержки?

Сравните три сметы: базовую, оптимальную и срочную. В каждой должны быть часы, роли специалистов, SLA, перечень работ, стоимость доработок, внешние расходы и условия гарантии. Если цена высокая, но нет реакции по времени, отчетности, бэкапов, безопасности и понятного состава команды, смета требует уточнения.

Нужно ли платить за поддержку, если сервис работает нормально?

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

Кто должен владеть доступами: заказчик или подрядчик?

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

Как часто нужно делать резервные копии?

Для простого сайта может хватить ежедневного копирования. Для сервиса с заказами, оплатами, записями или личными кабинетами лучше рассматривать копии каждые 1–6 часов. Главное — не только частота, но и проверка восстановления.

Что спросить у подрядчика перед подписанием поддержки?

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

Когда стоит менять подрядчика поддержки?

Если подрядчик не соблюдает сроки, не фиксирует задачи, не передает доступы, не показывает бэкапы, избегает документов, не объясняет стоимость или не может восстановить сервис после сбоя. Перед сменой подрядчика проведите технический аудит и заранее заберите все права, доступы и документацию.