Как принимать заявки на VPS, если облачная CRM недоступна?

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

Как очередь на VPS помогает сохранить заявку?

При прямой отправке сайт зависит от ответа CRM: клиент нажал кнопку, запрос ушёл, но соединение оборвалось. Без отдельной записи трудно понять, приняла ли CRM обращение. Очередь создаёт промежуточную точку, где система фиксирует заявку до попытки передачи. Необходимость такого буфера и повторных отправок описывает B2Bsite в материале о передаче заказов через вебхуки и очереди.

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

Рабочая последовательность выглядит так:

1. Сайт передаёт обращение приёмнику на VPS.
2. Приёмник проверяет формат полей и записывает заявку в очередь.
3. Сайт показывает подтверждение только после успешной записи.
4. Отдельный процесс отправляет заявку в CRM и фиксирует результат.
5. При временном сбое процесс оставляет заявку в очереди до следующей попытки.

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

Общий принцип разделения каналов приёма и системы продаж разобран в статье на marketology.by. Для схемы с VPS главный практический вопрос — где останется обращение, если следующий сервис не ответит.

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

Присвойте заявке идентификатор при её первом приёме и сохраняйте его при каждой повторной отправке. CRM или промежуточный обработчик должны распознавать этот ключ и возвращать результат прежней операции вместо создания новой записи. Такой принцип называют идемпотентностью; его применение для защиты от дублей описывает «Пятый фактор».

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

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

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

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

Как выбрать VPS и резервный канал для заявок?

Начните с требований к восстановлению: сколько обращений система должна удержать при сбое CRM и кто будет разбирать очередь. Затем выбирайте ресурсы сервера. Объём диска зависит от размера заявки и срока ожидания, а нагрузка на процессор — от проверок и частоты отправки. Без этих вводных сравнение тарифов по памяти почти ничего не говорит о пригодности VPS.

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

Дублирование на почту или в таблицу помогает организовать ручной резерв; такой подход описан в материале «Как настроить прием заявок на почту/CRM без разработчика» на vc.ru. Но резервный канал тоже требует проверки доставки. Если почта, очередь и сайт зависят от одного сервера, его отказ затронет их одновременно.

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

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

Как проверить, что заявки действительно доходят?

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

Следите за количеством ожидающих заявок и возрастом самой старой записи. Накопление очереди показывает задержку доставки. Отсутствие новых событий тоже заслуживает проверки, если обычно обращения поступают регулярно, хотя само по себе ещё не доказывает сбой. Контроль очереди и сигнал ответственному рекомендует «Пятый фактор».

Проверку перед запуском проведите по следующему сценарию:

1. Отправьте тестовую заявку и найдите соответствующую запись в CRM.
2. Временно отключите передачу в CRM и убедитесь, что новая заявка остаётся в очереди.
3. Восстановите передачу и проверьте доставку ожидающей заявки.
4. Повторите отправку с тем же идентификатором и проверьте отсутствие второго лида.
5. Перезапустите обработчик при непустой очереди и проверьте продолжение отправки.

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

Типичные ошибки при запуске приёма заявок

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

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

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