Рекрутёр потерял базу кандидатов вместе с подпиской: своя ATS на сервере

MAATRIX

Классическая история: рекрутёр или небольшое кадровое агентство несколько лет ведёт всех кандидатов в облачном ATS-сервисе по подписке — карточки, резюме, история звонков, комментарии по итогам собеседований. Потом случается пауза — закончился проект, сменился бюджет, просто забыли продлить оплату — и доступ к аккаунту блокируется вместе со всей накопленной базой. Ниже разбираем, как вместо аренды доступа к чужой базе развернуть собственную ATS на своём сервере, где база кандидатов принадлежит вам постоянно, а не до следующего платежа.

Что на самом деле происходит, когда подписка заканчивается

ATS (Applicant Tracking System, система управления подбором персонала) — это не просто таблица с именами. За годы работы туда стекается вся история отношений с рынком труда: резюме и сопроводительные письма, пометки после звонков и собеседований, статусы по каждой вакансии, теги по навыкам, которые вы сами придумали и годами уточняли, переписка с кандидатами, у которых на этот раз не сложилось, но которые идеально подойдут под вакансию через полгода.

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

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

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

Что должна уметь ATS рекрутёра — и что ей точно не нужно

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

Минимально нужны:

• карточка кандидата: контакты, резюме (файл и/или текст), навыки и теги, желаемая позиция, зарплатные ожидания, источник (где нашли — сайт, реферал, соцсеть);
• карточка вакансии со стадиями воронки: новый отклик → скрининг → собеседование с заказчиком → оффер → закрыта/отказ;
• связь «кандидат — вакансия»: один и тот же человек может быть в воронке по нескольким позициям одновременно, и это должно быть видно на одной карточке;
• журнал контактов: звонок, письмо, встреча — с датой, кратким итогом и следующим шагом;
• полнотекстовый поиск по резюме и тегам — чтобы за секунды найти всех, кто подходит под новую вакансию, среди уже отсмотренных ранее кандидатов;
• хранилище файлов резюме с версионностью, если кандидат присылает обновлённый вариант.

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

Почему подписка на облачную ATS — это системный риск, а не просто расход

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

Оплата привязана к активности, а не к объёму накопленных данных. Пока вы активно ведёте вакансии, стоимость подписки выглядит оправданной. Но база кандидатов ценна и в паузах между проектами — именно тогда, когда платить за неё труднее всего обосновать, а доступ уже нужен как архив для будущей работы.

Экспорт почти никогда не бывает полным. Даже добросовестные вендоры обычно дают выгрузку в CSV или похожем формате с базовыми полями, но история активности, вложения и связи между сущностями (кандидат — вакансия — интервью) переносятся с потерями или не переносятся вовсе. Проверить это заранее сложно — тестовый экспорт с одним кандидатом не покажет проблем, которые вылезают при выгрузке базы на несколько тысяч записей с многолетней историей.

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

И последнее — вопрос ответственности за чужие персональные данные. Формально ответственность оператора персональных данных перед кандидатом никуда не переходит на вендора ATS только потому, что вы платите ему за хранение. Куда законно можно помещать сервер с такими данными — отдельная тема, разобранная в статье про законное размещение сервера с персональными данными.

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

Два пути: готовая ATS с открытым кодом или своя схема на конструкторе

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

Путь первый — развернуть готовую open source ATS. На рынке есть отдельный класс систем управления рекрутингом с открытым исходным кодом, изначально спроектированных именно под задачу ATS: карточка кандидата, воронка по вакансиям, парсинг резюме, история переписки — всё уже собрано и протестировано разработчиками именно под эту задачу. Такую систему нужно развернуть на сервере (обычно это связка веб-сервера, PHP или Node.js окружения и базы данных вроде MySQL или PostgreSQL), настроить учётные записи для команды и импортировать текущую базу, если она у вас уже есть в виде экспорта из старого сервиса. Плюс подхода — готовая логика ATS из коробки, вам не нужно проектировать структуру данных самому. Минус — придётся разбираться в чужом коде, если понадобится нестандартная доработка, и обновления такой системы вы обслуживаете сами.

Путь второй — собрать лёгкую ATS на конструкторе баз данных. Если готовая система избыточна или её механику неудобно подстраивать под вашу воронку, разумная альтернатива — взять инструмент вроде NocoDB, который берёт обычные таблицы PostgreSQL и строит вокруг них веб-интерфейс с фильтрами, канбан-досками по стадиям воронки и формами — без написания кода. Этот путь медленнее выйти на полную функциональность (парсинг резюме и часть автоматизаций придётся заменить ручными шагами), зато структура данных полностью ваша с первого дня, а сама платформа простая и предсказуемая в поддержке. Подробный разбор установки — в статье про установку NocoDB на VPS; похожим образом уже собирают лёгкую CRM для другой профессии — разбор с готовым docker-compose есть в статье про свою CRM риелтора на сервере, логика переносится на ATS почти один в один, меняются только поля карточек и стадии воронки.

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

Разворачиваем базу кандидатов: минимальный рабочий стек

Дальше — практическая часть на примере пути с NocoDB, как более быстрого старта для одного рекрутёра или небольшой команды.

Понадобится VPS с 2 vCPU и 4 ГБ RAM — для базы на несколько тысяч кандидатов и активных вакансий этого достаточно с запасом; диск стоит сразу брать от 40–60 ГБ, если резюме и сопроводительные файлы планируете хранить локально на том же сервере, а не во внешнем облачном хранилище. На Ubuntu 24.04 ставим Docker и Docker Compose, дальше — минимальный docker-compose.yml:

version: "3.8"
services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: nocodb
      POSTGRES_USER: nocodb
      POSTGRES_PASSWORD: замените_на_свой_пароль
    volumes:
      - ./pgdata:/var/lib/postgresql/data

  nocodb:
    image: nocodb/nocodb:latest
    restart: unless-stopped
    depends_on:
      - db
    environment:
      NC_DB: "pg://db:5432?u=nocodb&p=замените_на_свой_пароль&d=nocodb"
    ports:
      - "8080:8080"
    volumes:
      - ./ncdata:/usr/app/data

После docker compose up -d интерфейс доступен на порту 8080 — дальше его стоит спрятать за обратный прокси с TLS и доступом по паролю или, лучше, по VPN, а не выставлять напрямую наружу. Дальше создаём структуру таблиц под задачу рекрутёра:

• таблица Кандидаты — ФИО, контакты, файл резюме (поле типа attachment), навыки и теги (поле типа multi-select — заполняется по мере просмотра резюме), зарплатные ожидания, источник;
• таблица Вакансии — название позиции, заказчик, статус (открыта/закрыта/на паузе), требования;
• связующая таблица Отклики — кандидат, вакансия, стадия воронки (select-поле: скрининг, интервью, оффер, отказ, найм), дата последнего контакта;
• таблица Контакты — привязана к отклику, короткая запись по каждому звонку или письму.

На таблице «Отклики» включаем представление канбан по полю стадии — это и есть визуальная воронка подбора по каждой вакансии, привычная тем, кто раньше работал в готовой ATS. Полнотекстовый поиск по резюме NocoDB из коробки не делает — если это критично, резюме стоит хранить не только как вложение, но и продублировать текстом в отдельном поле (скопировать текст резюме при добавлении кандидата), тогда обычный фильтр по тексту находит нужных людей за секунды.

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

Резюме, персональные данные и бэкапы — не откладывайте на потом

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

Три вещи стоит настроить сразу, а не «когда будет время»:

• резервное копирование — не реже раза в сутки, желательно с копией вне самого сервера (другой сервер, объектное хранилище), потому что бэкап, лежащий рядом с боевой базой на том же диске, не спасает при отказе диска целиком;
• ограничение доступа — интерфейс NocoDB не должен быть открыт всему интернету; доступ по VPN или как минимум за обратным прокси с базовой аутентификацией и HTTPS — это буквально несколько строк конфигурации, но именно их пропускают чаще всего;
• политика хранения — определите для себя срок, после которого карточка кандидата, с которым отношения не сложились и который явно не в вашей нише, удаляется или анонимизируется, а не копится бессрочно «на всякий случай».

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

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