Нельзя честно назвать единую ежемесячную цену, пока не определено, кто и за что отвечает. Стоимость зависит от состояния системы, технологий, инфраструктуры, количества важных процессов и интеграций, необходимого мониторинга, правил резервного копирования и развертывания, числа обращений и согласованных часов реакции.
Для сравнения предложений лучше разделить расходы на четыре группы: инфраструктура и внешние сервисы, постоянная готовность команды, фактически выполненные работы и крупное развитие. Только после этого можно понять, действительно ли два предложения относятся к одному объему ответственности.
Хостинг является только частью расходов
Сервер, домен и сертификат позволяют приложению работать, но сами его не сопровождают. Хостинг не проверит автоматически, что задача отправки счетов остановилась, интеграция перестала получать заказы или резервную копию базы невозможно восстановить. Он также не обновит код и не исправит ошибку после изменения внешнего API, если это не было отдельно согласовано.
Наличие файла резервной копии тоже не гарантирует, что в нем есть все нужные данные и из него можно восстановить рабочую систему. В предложении должны быть описаны состав копии, частота создания, срок хранения, место размещения и порядок проверки восстановления.
Из чего складывается стоимость сопровождения?
| Группа расходов | Что может входить | За что фактически платит компания |
|---|---|---|
| Инфраструктура и внешние сервисы | сервер или облако, домен, почта, SMS, платежи, хранение файлов, мониторинг и внешние API | ресурсы и доступ к сервисам, необходимым приложению |
| Постоянная поддержка и готовность | прием уведомлений и обращений, проверка копий, планирование обновлений и ответственность в согласованные часы | доступность специалиста, который знает согласованный объем и может начать работу с проблемой |
| Работы в системе | диагностика, исправления, обновления, развертывания, настройка и небольшие изменения | конкретные работы в рамках абонентской платы, лимита или отдельного заказа |
| Крупное развитие | новые модули, миграции, модернизация, перестройка инфраструктуры или восстановление после серьезного инцидента | отдельный проект, который не следует скрывать за общим словом «сопровождение» |
Одно предложение может включать только сервер и реакцию на обращение. Другое дополнительно предусматривает мониторинг важных процессов, проверку резервных копий, регулярные обновления и согласованный объем работ. Поэтому сравнение только ежемесячных сумм часто приводит к неверным выводам.
Что сильнее всего влияет на расчет?
Значение системы для компании
Информационный сайт и система, принимающая заказы, бронирования или данные для ежедневной работы сотрудников, требуют разного подхода. Чем серьезнее последствия остановки процесса, тем важнее мониторинг, понятный канал обращений и заранее согласованный порядок реакции.
Состояние кода и технологий
Расходы растут, если проект использует неподдерживаемые версии PHP, фреймворка или библиотек, не имеет тестов либо развертывается вручную без безопасного возврата. PHP публикует сроки поддержки веток, а Laravel применяет собственную политику исправлений и обновлений безопасности. Версии технологий нужно контролировать в течение всей работы приложения, а не только в день запуска.
Количество процессов и интеграций
Проверка главной страницы не обнаружит все проблемы. Отдельного контроля могут требовать очереди, плановые задачи, платежи, отправка сообщений, импорт, экспорт и связи с другими системами. Каждый процесс создает собственные сценарии ошибок и зависимость от внешнего поставщика.
Документация и доступы
Репозиторий, описание инфраструктуры, список сервисов, процедура развертывания и сведения о резервных копиях ускоряют диагностику. Если предыдущий подрядчик не передал эти материалы, первым этапом может стать упорядочение доступов и проверка состояния системы. В этом помогает чек-лист приема приложения, но он не заменяет анализ кода и сервера.
Часы поддержки и время реакции
Готовность имеет стоимость даже в месяце без аварий. Короткое время первой реакции требует зарезервированной доступности и знания конкретной системы. Нужно также различать начало обработки и завершение ремонта. Срок полного решения часто можно определить только после диагностики.
Когда достаточно разовой работы?
Не каждому приложению нужна ежемесячная поддержка. Разовый заказ может быть достаточным, если система не обслуживает критический процесс, компания принимает плановый срок и ей требуется конкретное обновление, настройка или исправление. При этом мониторинг, копии и связь с хостингом должны иметь другого ответственного.
Постоянное сопровождение полезнее, когда приложение используется каждый день, регулярно меняется, имеет интеграции или фоновые задачи. Оно также оправдано, если компания хочет поручить одной стороне ответственность за уведомления, контроль копий, план обновлений и управляемые развертывания.
В Domin Software можно согласовать разовые работы, регулярную поддержку или отдельно рассчитанный вариант со временем реакции. Подходящая модель зависит от системы и последствий ее недоступности.
Почему SLA влияет на стоимость?
SLA не должно быть расплывчатым обещанием быстрой помощи. В нем указываются приложения и среды, дни и часы обслуживания, каналы обращений, уровни важности, время первой реакции и обязанности обеих сторон.
Domin Software не публикует единое SLA для всех клиентов и не обещает поддержку 24/7. Стандартно мы обрабатываем обращения с воскресенья по пятницу, с 8:00 до 17:00 по времени Europe/Warsaw. По субботам поддержка не предоставляется. В польские государственные праздники мы можем реагировать только на заранее согласованные критические события. Точные условия действуют после их включения в предложение или договор.
Круглосуточный мониторинг не означает круглосуточную реакцию специалиста. Он может обнаружить проблему и сохранить уведомление, но срок обработки зависит от согласованного дежурства.
Как сравнить два предложения?
| Вопрос | Что должно быть указано |
|---|---|
| Что входит в объем? | приложения, среды, сервер, интеграции и важные процессы |
| Что контролируется? | конкретные адреса, задачи, очереди, интеграции и получатели уведомлений |
| Как проверяются копии? | состав, частота, срок хранения, место и тест восстановления |
| Когда обрабатываются обращения? | дни, часы, часовой пояс, каналы и правила эскалации |
| Что означает время реакции? | подтверждение, первичная оценка и начало обработки, а не автоматическое завершение ремонта |
| Как вносятся изменения? | тестирование, утверждение, развертывание и возможность отката |
| Что входит в постоянную плату? | готовность, названные обязанности и возможный лимит работ |
| Что оплачивается отдельно? | крупное развитие, миграции, аудиты, восстановление после атаки и работы вне объема |
| Кому принадлежат учетные записи? | клиент должен сохранять контроль над хостингом, доменом, данными и платежами |
Если предложение не отвечает на эти вопросы, объем стоит уточнить до сравнения цены. Самая низкая сумма может означать минимальную ответственность. Более высокая цена также не доказывает лучшую защиту. Важны письменный объем и способ проверки услуги.
Что подготовить для оценки?
На первом этапе достаточно описать назначение приложения и ключевые процессы. Также полезны:
- технологии и версии, если они известны;
- список сред, интеграций, фоновых задач и внешних сервисов;
- сведения о репозитории, документации, тестах и развертывании;
- текущий объем мониторинга и резервных копий;
- последствия сбоя и приемлемые часы поддержки;
- типичные обращения и ожидаемый объем небольших изменений;
- информация о владельцах учетных записей и утверждении развертываний.
Не отправляйте через форму пароли, ключи, базы данных или данные клиентов. На первом этапе нам нужно описание ситуации, а не доступ к рабочей среде.
План сопровождения приложения помогает собрать сведения и создать рабочее резюме. Результат не является автоматической оценкой или договором SLA.
Что показывают наши прежние проекты?
Развитие системы 44Islands не закончилось первым запуском. Следующие этапы расширяли управление бронированиями, роли пользователей и прямые продажи. Этот пример показывает, что сопровождение работающего приложения может включать поддержку существующего объема и отдельно согласованное развитие.
Историческая поддержка трех магазинов PrestaShop 1.6 включала настройку VPS и среды, доменов, Apache и PHP, установку модулей, повышение производительности и доработку шаблонов. Она продолжалась около года. Эти магазины больше не используются в рабочей среде, поэтому пример подтверждает вид выполненных работ, а не их текущее состояние или цену новой услуги.
В обоих случаях объем определялся конкретной системой. Прежние проекты не являются готовым прайс-листом для следующего клиента.
Частые вопросы
Включает ли хостинг сопровождение приложения?
Нет, если предложение прямо не объединяет обе услуги и не описывает ответственность. Хостинг предоставляет ресурсы, а сопровождение может включать мониторинг процессов, копии, обновления, диагностику, развертывания и обработку обращений.
Всегда ли постоянная поддержка включает определенное число часов разработчика?
Не обязательно. Плата может покрывать готовность и конкретные обязанности, а также дополнительный лимит работ. В договоре следует указать, что происходит после исчерпания лимита и какие задачи считаются отдельным проектом.
Достаточно ли создать резервную копию?
Нет. Нужно знать, что входит в копию, где и сколько она хранится и можно ли из нее восстановить рабочую систему. Для теста восстановления следует согласовать объем и частоту.
Можно ли определить стоимость без доступа к коду?
Без доступа можно предварительно определить модель сотрудничества и необходимые сведения. Точная ответственность за существующую систему может потребовать платного анализа кода, инфраструктуры, версий и процедуры развертывания.
Означает ли мониторинг реакцию 24/7?
Нет. Мониторинг может работать постоянно, но уведомления обрабатываются в часы, указанные в договоре. Дежурство вне стандартного времени согласуется отдельно.
Входит ли разработка новых функций в сопровождение?
Небольшие изменения могут входить в согласованный лимит. Крупные модули, миграции и модернизация должны иметь отдельный объем, критерии приемки и оценку.
Выберите следующий шаг
Если сначала нужно упорядочить требования, используйте план сопровождения приложения. Он собирает информацию о системе, копиях, мониторинге, обращениях и ожидаемой модели сотрудничества, но не отправляет данные автоматически и не создает оценку.
Если объем уже понятен, ознакомьтесь с услугой сопровождения приложений и интернет-магазинов. Опишите назначение системы, важные процессы, последствия сбоя и ожидаемые часы поддержки. На этой основе мы определим, достаточно ли разового заказа, нужна ли регулярная поддержка или отдельно согласованный вариант SLA.
Источники
- PHP Supported Versions, доступ проверен 28.10.2026.
- Laravel Release Notes and Support Policy, доступ проверен 28.10.2026.
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, доступ проверен 28.10.2026.
- OWASP A06:2021, Vulnerable and Outdated Components, доступ проверен 28.10.2026.