Сопровождение ERPNext: что входит в 40 000 ₽ в год и как устроена поддержка

Сопровождение ERPNext у нас стоит 40 000 ₽ в год или 6 500 ₽ в месяц: сервер, обновления, резервные копии и поддержка пользователей. Лицензии при этом 0 ₽. Ниже расписано, что делает инженер, как проходит обращение и что в сумму не входит.

Зачем нужно сопровождение ERPNext, если лицензия бесплатна

Лицензия ERPNext стоит 0 ₽: система открытая, лицензия GPLv3. Но работающая система — это сервер, на котором она живёт, обновления, резервные копии, учётные записи людей и кто-то, кому звонят, когда у снабженца не открывается заявка. Если сказать сухо: лицензия бесплатна, но совокупная стоимость владения включает сервер, администрирование, бэкапы и обновления. Эти работы не исчезают от того, что программа бесплатная. Они просто переезжают к вам, если вы не договорились с исполнителем.

Мы в АйТи-Фреш берём это на себя. По странице продукта ERPNext под ключ внедрение для команды из 5–6 человек стоит 65 000 ₽ разово, а дальше сопровождение — 40 000 ₽ в год или 6 500 ₽ в месяц: сервер, обновления, бэкапы и поддержка. Если вы платите помесячно, за год выходит 78 000 ₽, то есть на 38 000 ₽ больше. Помесячная схема нужна тем, кто пока не уверен, что останется в системе, и не хочет фиксировать год.

Чего в этих деньгах нет, лучше сказать сразу. Новые DocType, отчёты и печатные формы, интеграция с новым источником данных и обучение нового отдела оцениваются отдельно. Сервер в тариф входит, если система живёт в нашем ЦОД в России; если ERPNext стоит на вашем оборудовании, условия сопровождения считаем отдельно, так и написано на странице продукта. Мы не обещаем процентов доступности вроде «99,9 %» и конкретных сроков реакции в публичных материалах: такие показатели зависят от площадки и состава работ, поэтому мы фиксируем их в договоре и регламенте, а не в статье.

Обновления: что делает инженер и почему нельзя «просто нажать update»

Команда bench update делает много: подтягивает изменения в bench и во все приложения, применяет патчи, собирает JS и CSS и выполняет миграцию базы. На учебном стенде это одна строка. На боевой системе с вашими кастомизациями это операция, после которой у людей могут пропасть поля, поломаться отчёты и перестать работать печатные формы. Больше всего рискуют именно они: кастомные печатные формы, коннекторы с 1С и самописные отчёты. Поэтому инженер сначала делает полную резервную копию, затем разворачивает копию на тестовом стенде, обновляет там и только потом переходит на боевую.

Мажорное обновление, например с линии v15 на v16, планируется отдельно. Порядок такой: проверить требования новой линии к версиям Python и Node.js, переключить ветки приложений, затем выполнить миграцию и сборку. Конкретные версии зависят от релиза, поэтому я не привожу их цифрами: смотрите требования в документации выбранной версии. Два правила неизменны. Версии frappe и erpnext должны совпадать по линии. Версию базы данных назад не откатить: если что-то пошло не так, вы восстанавливаете из копии.

Свои доработки мы храним в отдельном приложении и в fixtures, а не правим код ядра. Тогда обновление ядра не затирает ваши настройки, а сами доработки можно версионировать и проверять на стенде. Если вы однажды правили файл прямо в ядре, при следующем обновлении изменение либо потеряется, либо вызовет конфликт, и это одна из самых частых причин «систему страшно обновлять».

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

bench --site example.com backup --with-files
bench update

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

Бэкапы: создание, хранение и проверка восстановления

Резервная копия — это не файл, а процедура. Команда bench backup создаёт дамп базы и по умолчанию складывает его в каталог private/backups внутри папки сайта; с ключом --with-files в копию попадают и файлы, а с --compress файлы упаковываются в tgz. Если копия не создалась, документация говорит, что файлы удаляются, чтобы не занимать диск. Значит, наличие файла говорит об успехе, а его отсутствие — о проблеме, и именно за этим надо следить.

Ключевой пункт: копия на том же диске, что и система, — не копия. Мы выносим копии на отдельный сервер или хранилище и держим несколько поколений. Обычно это резервный VPS или хранилище, куда копии уезжают по расписанию. На больших базах логический бэкап заметно нагружает процессор, и в рабочее время его лучше не запускать. И одна ловушка, которую я проверил по исходникам v15: раз в час фоновая задача удаляет из private/backups всё сверх числа, заданного в System Settings → Number of Backups (по умолчанию 3). Если вы рассчитываете на месячную глубину прямо на сервере, её там не будет: длинную историю держите во внешнем хранилище со своим сроком хранения.

Про проверку. Бэкап, который ни разу не восстанавливали, мы считаем неподтверждённым. Раз в квартал инженер разворачивает свежую копию на тестовом сервере командой bench restore, открывает сайт и находит документ, который перед этим намеренно создали или удалили. Если при восстановлении всплывает ошибка отсутствующей таблицы, помогают проверка прав на каталог и флаг --force, но применять его нужно осознанно. Подробнее о схемах резервного копирования у нас есть материал про автоматизацию бэкапов и мониторинг и разбор неудачного бэкапа.

Что мы настраиваем по расписанию: | Что | Как часто | Критерий готовности | |---|---|---| | Автоматическая копия базы и файлов | ежедневно | файл создан, размер не нулевой | | Контроль создания копии | ежедневно | при сбое приходит уведомление | | Проверка логов и очередей | еженедельно | нет зависших фоновых задач | | Пробное восстановление | раз в квартал | документ найден на тестовом сервере | | Обновление версии | по необходимости | сначала на копии |

Мониторинг, безопасность и права пользователей

В сопровождении у нас три постоянных задачи кроме копий: следить за состоянием сервера, закрывать уязвимости и вести права. Для диагностики фоновых воркеров в Frappe есть команда bench doctor: она показывает состояние рабочих процессов и очередей. Если письма не уходят и импорт стоит, первая проверка — запущены ли воркеры и планировщик. Следить за диском, памятью и базой нужно независимо, и для этого у нас есть мониторинг на Zabbix.

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

Отдельно о том, что именно мы смотрим на сервере. Свободное место на диске, потому что копии и файлы растут быстрее, чем ожидают. Память и своп: MariaDB, Redis и воркеры вместе дают заметную нагрузку, и на слишком маленьком сервере система начинает «подвисать» по вечерам. Срок действия сертификата HTTPS, потому что просроченный сертификат пользователь воспринимает как «система сломалась». Наконец, время последней успешной копии. Все четыре пункта легко проверить скриптом, и ни один из них не требует вмешательства, пока всё в норме; именно поэтому их хорошо делать автоматически и получать уведомление только при отклонении.

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

«Гранит-Старт»: как проходит обращение и что считается инцидентом

Условный пример. Строительная компания «Гранит-Старт», 7 рабочих мест, работает на ERPNext с сопровождением по годовому тарифу. Цифры и сроки ниже — иллюстрация процесса, а не обещание. Прораб пишет, что заявка на арматуру не сохраняется: «красная ошибка». Обращение приходит инженеру, тот определяет приоритет: если не работают заявки для всех, это инцидент, и его берут сразу, если у одного человека не открывается отчёт — плановое обращение.

Диагностика идёт в таком порядке: смотрим журнал ошибок, состояние фоновых очередей, права пользователя, недавние изменения (обновление, правка поля, новая доработка). В примере причиной оказалось недавно добавленное обязательное поле: у части прорабов не хватало прав его заполнить. Инженер воспроизвёл ошибку на копии, поправил права и подтвердил, что заявка сохраняется. Пользователь проверил у себя и закрыл обращение. Вся цепочка заняла один рабочий день.

Если выяснилось, что нужно изменить логику — например, добавить новый отчёт по перерасходу, — это уходит в отдельную оценку по ТЗ и в годовой платёж не входит. Различие простое: сопровождение чинит и поддерживает то, что есть, а доработка создаёт новое. Это же правило избавляет от споров, потому что заказчик заранее видит, где проходит граница.

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

Годовой или помесячный платёж и что в него не входит

Выбор между 40 000 ₽ в год и 6 500 ₽ в месяц — вопрос горизонта. Если вы подключаетесь на срок меньше шести месяцев, помесячная схема дешевле: шесть месяцев по 6 500 ₽ дают 39 000 ₽. Дольше шести месяцев годовой платёж выгоднее. За год помесячная схема стоит 78 000 ₽, но не фиксирует срок. Другие суммы и условия зависят от объёма и фиксируются в договоре; общий ориентир по стоимости владения мы разбираем отдельно, а условия продукта указаны на его странице.

Что входит в сопровождение: сервер в нашем ЦОД, обслуживание приложения, обновления, ежедневные резервные копии и проверка восстановления, мониторинг, управление пользователями и правами, диагностика ошибок и консультации по работе в системе. Что обычно считается отдельно: | Входит | Оценивается отдельно | |---|---| | Обновления и миграции | Новые DocType и отчёты | | Копии и проверка восстановления | Нормативные печатные формы (УПД, КС-2, КС-3) | | Права и новые пользователи | Интеграция с новым источником данных | | Диагностика ошибок | Обучение нового отдела | | Консультации по работе | Сопровождение на вашем сервере (условия отдельно) | | Мониторинг сервера в нашем ЦОД | Доработки сверх согласованного ТЗ |

Ограничения, о которых мы предупреждаем. Сопровождение не заменяет вашего ответственного внутри компании: кто-то должен принимать решения по процессу и обучать новичков. Мы не даём гарантий доступности в процентах и сроков реакции в этой статье. Для общего понимания, как выглядит договор с исполнителем, полезен материал про SLA в договоре с IT-аутсорсером, а общий формат нашей работы описан на странице IT-аутсорсинга. Показать, как выглядит система, можно на демостенде erp-demo.itfresh.ru по запросу.

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