YetiForce в эксплуатации: обновления, бэкапы и безопасность self-hosted CRM, за которую отвечаете вы сами

Модель ответственности self-hosted: что вы подписали, отказавшись от облака

Меня зовут Семёнов Евгений Сергеевич, я технический директор ITfresh. Мы пятнадцать лет обслуживаем IT юридических лиц до пятидесяти рабочих мест, держим собственные серверы в дата-центре МТС и знаем цену каждой минуты простоя чужого бизнеса. Про YetiForce я пишу не как евангелист бесплатного софта, а как человек, который в три часа ночи поднимает эту CRM из бэкапа, когда у клиента «всё пропало». Поэтому разговор будет честный и приземлённый.

Когда компания выбирает облачную CRM по подписке, вместе с ежемесячным счётом она покупает чужую ответственность. Аптайм, ночные бэкапы, накат патчей безопасности, отражение атак на периметр — это головная боль вендора, прописанная в его договоре. Вы платите и спите спокойно. Как только вы разворачиваете YetiForce на своём сервере, вы разрываете этот договор с самим собой: теперь всё перечисленное — ваша работа. Никто ночью не накатит security-патч за вас, и никто, кроме вас, не заметит, что диск заполнился на девяносто восемь процентов.

Плюсы у self-hosted огромные: данные лежат внутри вашего контура, лицензия YetiForce Public License 7 не требует платежей за пользователей, а функциональность на уровне коммерческих продуктов. Но за эти плюсы платят не деньгами, а дисциплиной эксплуатации. Давайте честно разложим, кто за что теперь отвечает.

Практический вывод, который я всегда проговариваю на входе: назначьте себе минимальный SLA письменно, даже если вы сами себе и заказчик, и подрядчик. Для CRM небольшой компании разумная планка — доступность в рабочие часы не ниже 99%, точка восстановления (RPO) не глубже суток, время восстановления (RTO) до четырёх часов. Эти три цифры определяют всю дальнейшую эксплуатацию: как часто снимать дампы, как быстро реагировать на алерт, сколько держать резервных копий.

Бэкапы: схема 3-2-1 для CRM

Бэкап CRM — это не про «когда-нибудь пригодится», а про единственный сценарий, в котором вы вернёте бизнес к жизни после шифровальщика, отказа диска или чьей-то ошибки с массовым удалением. Классическая и до сих пор непобеждённая формула — три копии данных, на двух разных носителях, одна из них за пределами площадки. Ниже разберу её применительно именно к YetiForce.

Что бэкапим

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

• Дамп MariaDB — вся структурированная информация: контакты, сделки, тикеты, письма, права, настройки. Снимаем консистентную копию с флагом --single-transaction, чтобы получить целостный снимок на движке InnoDB без блокировки таблиц и без остановки работы пользователей.
• Каталоги storage и config — файловые вложения, документы, сгенерированные PDF, а также конфигурация экземпляра и ключи. В базе лежат только ссылки на файлы; сами файлы физически хранятся в storage. Восстановите одну базу без storage — получите CRM с битыми ссылками на все вложения. Восстановите файлы без config — экземпляр не поднимется.

# Консистентный дамп базы YetiForce (InnoDB, без остановки работы)
mysqldump --single-transaction --quick --routines --triggers \
  --default-character-set=utf8mb4 \
  -u backup_ro -p'СЕКРЕТ' yetiforce \
  | gzip -9 > /var/backups/yf/db-$(date +%F).sql.gz

# Файловая часть: вложения и конфигурация экземпляра
tar czf /var/backups/yf/files-$(date +%F).tar.gz \
  -C /var/www/yetiforce storage config

Обратите внимание на отдельного пользователя MariaDB backup_ro с правами только на чтение и дамп — не гоняйте бэкапы под учёткой приложения и тем более не под root.

Куда и как часто

Мой рабочий стандарт для CRM небольшой компании: полный ночной дамп базы и файлов раз в сутки, в самое тихое время. Локальная копия остаётся на сервере для быстрого отката, а вторая немедленно уезжает за пределы площадки — в S3-совместимое объектное хранилище или на FTP в другом дата-центре. Глубина хранения — тридцать дней с ротацией: этого достаточно, чтобы отловить порчу данных, которую заметили не сразу. Задание вешаем в cron под отдельным сервисным пользователем.

# crontab: ночной бэкап 03:15 + выгрузка в другой ЦОД 03:40
15 3 * * * /opt/yf/backup.sh >> /var/log/yf-backup.log 2>&1
40 3 * * * rclone copy /var/backups/yf remote-dc2:crm-backups \
             --max-age 24h --log-file=/var/log/yf-offsite.log
# еженедельная чистка копий старше 30 дней
30 4 * * 0 find /var/backups/yf -type f -mtime +30 -delete

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

Главное правило

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

Обновления YetiForce без простоя

YetiForce развивается активно: ветка 7.x получает релизы регулярно, актуальный на момент написания — 7.1.1 от 22 мая 2026 года, и патчи в том числе закрывают уязвимости. Игнорировать обновления в self-hosted нельзя: непропатченная CRM, доступная из интернета, рано или поздно станет чьей-то добычей. Но и накатывать релиз «в лоб» на боевую в разгар рабочего дня — прямой путь к простою. Между этими крайностями лежит нормальный инженерный процесс.

Наш конвейер обновления состоит из пяти обязательных шагов, и порядок здесь важнее скорости:

1. Снапшот виртуальной машины. Перед любыми действиями снимаем моментальный снимок ВМ целиком. Это страховка уровня «откатить всё за минуту», если что-то пойдёт совсем не так.
2. Копия на staging. Разворачиваем свежую копию боевой базы и файлов на отдельном тестовом стенде, максимально похожем на прод по версиям ОС, PHP и MariaDB.
3. Накат встроенным апдейтером. Обновляем именно staging-копию через штатный механизм обновления YetiForce. Смотрим на весь процесс, читаем логи миграции, а не жмём «далее» вслепую.
4. Смок-тесты по чек-листу. Это тот шаг, который чаще всего пропускают и потом жалеют. Проверяем: вход в систему; отправку и приём почты; работу API-интеграций; генерацию PDF по шаблонам; отработку задач планировщика (cron). Если хоть один пункт красный — на прод не идём.
5. Выкат на прод в нерабочее время. Только после чистого прогона на staging повторяем обновление на боевой — вечером или в выходной, когда пользователей нет.

Что чаще всего ломается

За годы эксплуатации закономерность железная: минорный апдейт почти никогда не ломает «ванильную» установку. Ломаются доработки. Главные источники боли — кастомные workflow (бизнес-процессы) и правленые вручную шаблоны, особенно PDF и почтовые. При обновлении апдейтер накатывает новую логику ядра, а ваши правки, сделанные «поверх», либо конфликтуют с ней, либо молча перестают работать.

Отсюда правило, которое мы вбиваем в голову каждому, кто трогает YetiForce: доработки ведём переопределениями, а не правкой ядра. Не редактируйте файлы платформы напрямую — используйте механизмы расширения, отдельные пользовательские шаблоны и настраиваемые процессы. Тогда апдейтер обновит ядро, не затронув вашу кастомизацию, и смок-тест пройдёт с первого раза. Каждая правка в файле ядра — это мина, которая взорвётся при ближайшем релизе, и найти её потом в три часа ночи очень тяжело.

Харденинг доступа: пароль — это не защита

CRM хранит самое ценное, что есть у компании после денег, — клиентскую базу и историю сделок. Поэтому доступ к ней надо защищать так же серьёзно, как доступ к бухгалтерии. Приятная особенность YetiForce, редкая для open-source-мира: безопасность встроена в продукт, а не прикручена сбоку.

• Обязательная 2FA (TOTP) для администраторов. YetiForce умеет двухфакторную аутентификацию по одноразовым кодам из штатного приложения-аутентификатора. Для всех, у кого есть админские права, 2FA CRM должна быть не опцией, а требованием. Украденный или подобранный пароль без второго фактора становится бесполезным.
• Парольная политика и время жизни сессий. В настройках задаём минимальную длину и сложность пароля, а также разумный таймаут сессии, чтобы забытый открытым сеанс на общем компьютере не жил вечно.
• Ограничение админки по IP или через VPN. Наша практика — панель администрирования доступна только из корпоративного туннеля, снаружи её просто нет. Это отсекает целый класс атак: перебор паролей, эксплуатацию свежих уязвимостей до накатки патча, случайную индексацию.
• fail2ban на логи неудачных входов. Настраиваем блокировку IP после серии проваленных попыток аутентификации. Автоматический бан отбивает брутфорс без вашего участия.
• Разнесение прав по ролям. Менеджер должен видеть своих клиентов и свои сделки, а не всю базу и уж точно не иметь права выгрузить её целиком. Ролевая модель настраивается тонко — потратьте на неё время на старте.

Экспорт данных как главный инсайдерский риск

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

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

Харденинг платформы: закрываем всё лишнее

Приложение можно вылизать по безопасности, но если под ним дырявая платформа, толку не будет. Проходим по слоям стека — ОС, PHP, MariaDB, nginx — и закрываем всё, что не нужно снаружи. Напомню наш рекомендуемый прод-стек: Debian 12 или Ubuntu 24.04, nginx, PHP 8.3, MariaDB 10.6+ либо 10.11.

• Автоматические обновления безопасности ОС. Ставим и настраиваем unattended-upgrades — критические патчи Debian/Ubuntu будут прилетать сами, без ожидания, пока у вас дойдут руки.
• Только поддерживаемые версии PHP. PHP, вышедший из поддержки, перестаёт получать патчи безопасности и становится незакрываемой дырой. Держим 8.3 и планово мигрируем на следующую поддерживаемую ветку, не дожидаясь EOL.
• MariaDB слушает только localhost. База данных не должна быть видна из сети вообще. Привязываем её к 127.0.0.1 — приложение ходит к ней локально, а снаружи порт закрыт наглухо.
• Deny на служебные каталоги в nginx. Каталоги конфигурации, кэша, логов и внутренних библиотек не должны отдаваться по HTTP. Явно запрещаем к ним доступ.
• Заголовки безопасности. Добавляем HSTS, защиту от кликджекинга, запрет угадывания MIME-типов и разумную политику источников.

# nginx: запрет служебных каталогов и security-заголовки
location ~* ^/(config|cache|app_data|vendor|install|backup)/ {
    deny all;
    return 404;
}
location ~ /\.(?!well-known) { deny all; }

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Штатная панель «Безопасность»

Отдельно похвалю встроенную панель «Безопасность» YetiForce — она даёт список конкретных рекомендаций по вашей инсталляции и подсвечивает, что настроено небезопасно. После установки и после каждого крупного обновления мы просто проходим по её пунктам сверху вниз и доводим каждый до зелёного состояния. Это бесплатный аудит от самих разработчиков, глупо им не пользоваться.

Мониторинг: узнать о проблеме раньше пользователей

Худший способ узнать об аварии — звонок клиента «у нас ничего не работает». Задача мониторинга в том, чтобы вы увидели проблему за час до того, как её заметят пользователи, и спокойно починили. Для YetiForce есть несколько точек, за которыми надо следить постоянно.

• Планировщик cron. Это сердце CRM. Через cron.php уходят письма, срабатывают уведомления и бизнес-процессы. Зависший планировщик превращает систему в «молчащую CRM»: интерфейс работает, а письма и напоминания молча не отправляются, и это замечают не сразу. В админке есть контроль cron-задач — следим за временем последнего успешного запуска.
• Свободное место на диске. Вложения растут быстрее любых прогнозов. Диск, заполненный под завязку, роняет и базу, и веб-сервер. Порог тревоги — 80% занятости, критический — 90%.
• Медленные запросы MariaDB. Включаем slow query log и периодически прогоняем его через pt-query-digest — так видно, какие запросы деградируют по мере роста базы. Это профилактика, а не пожаротушение: мониторинг MariaDB предупреждает о проблеме до того, как система встанет.
• Доступность по HTTP извне. Внешняя проверка, которая раз в минуту дёргает страницу логина и меряет код ответа и время. Если сайт лёг, вы узнаёте об этом мгновенно, а не от бухгалтера.

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

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

Производительность под нагрузкой 30-50 пользователей

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

Три главные точки торможения YetiForce я расставляю по приоритету так:

1. Маленький innodb_buffer_pool_size. По умолчанию MariaDB отводит под кэш данных и индексов InnoDB смешные объёмы. На выделенном под CRM сервере этот параметр — первое, что мы правим. Ориентир — 50-70% доступной оперативной памяти. Эффект самый заметный: горячие данные перестают читаться с диска и живут в памяти.
2. Отсутствие тюнинга OPcache. Без прогретого кэша байт-кода PHP перекомпилирует скрипты на каждый запрос. Включённый и правильно настроенный OPcache снимает заметную часть нагрузки с процессора.
3. Разросшиеся журналы изменений. Таблицы истории и аудита (ChangesReviewedOn и подобная история изменений) со временем распухают и тормозят операции. Их нужно периодически чистить по регламенту хранения — держать историю ровно столько, сколько реально нужно бизнесу.

# /etc/mysql/mariadb.conf.d/50-server.cnf — базовый тюнинг под 30-50 юзеров
[mysqld]
innodb_buffer_pool_size      = 4G      # 50-70% RAM выделенного сервера
innodb_log_file_size         = 512M
innodb_flush_log_at_trx_commit = 2
slow_query_log               = 1
slow_query_log_file          = /var/log/mysql/slow.log
long_query_time              = 2
bind-address                 = 127.0.0.1

Что править первым и какого эффекта ждать: начинаем с innodb_buffer_pool_size — это даёт самый большой прирост отзывчивости. Затем включаем и настраиваем OPcache. Затем чистим журналы изменений. В большинстве случаев этого хватает, чтобы вернуть CRM бодрость без апгрейда железа.

Когда пора на сервер пожирнее? Если после тюнинга буфер стабильно упирается в потолок памяти, процессор в рабочие часы держится под 80%, а диск — узкое место по вводу-выводу, значит, вы выросли из текущей конфигурации. Тогда добавляем оперативную память (под больший буфер InnoDB), переходим на NVMe-накопители и при необходимости выносим базу на отдельный сервер. Но делать это стоит по данным мониторинга, а не по ощущениям «что-то тормозит».

Регламент сопровождения одним списком

Соберу всё сказанное в один рабочий регламент. Именно по такому графику мы ведём self-hosted CRM клиентов: без него эксплуатация превращается в хаотичное реагирование на аварии, а с ним — в предсказуемую рутину. Трудозатраты даю вилкой для типовой инсталляции YetiForce на 30-50 пользователей; конкретные цифры зависят от числа интеграций и кастомизаций.

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

Заведите этот график в таск-трекер с напоминаниями и ответственным по каждой строке. Эксплуатация self-hosted CRM — это не героизм в ночь аварии, а скучная дисциплина в спокойные дни. Именно она делает так, что ночей аварий становится сильно меньше.