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

Введение: когда система готова, но доставляемость под вопросом

Напомним вводные: мы разработали и внедрили CRM-систему, ключевой функцией которой стал собственный рассылочный контур для работы с базой в 70 тысяч адресов. Целевая скорость — вся база за час. Система готова, кнопка Отправить уже подмигивает и манит. Однако именно потому, что мы создавали решение под себя, а не брали готовое с полки, просто нажать на кнопку было нельзя.

Можно неделями шлифовать тексты с юристами и маркетологами, довести до блеска соблюдение требований ФЗ-152 и ФСТЭК. Только вот без правильно подготовленной почтовой инфраструктуры все эти усилия команды тратятся впустую, а письма остаются невидимыми для получателей, улетая прямиком в спам-фильтры.

Почтовые гиганты вроде Google, Mail.ru и Яндекса со своими антиспам-алгоритмами — ребята строгие, но справедливые. Они видят поток писем с нового, холодного сервера и по умолчанию считают его подозрительным. Доверие нужно заслужить. Так в нашем проекте появилась обязательная задача — прогрев почтовых серверов.

Почему почтовый сервер нужно прогревать

Вся система работает на репутации. Представьте, что новый сервер — это человек без кредитной истории, который приходит в банк и с порога просит самый большой кредит. Банк, конечно, посмотрит на него с большим подозрением. Так и почтовые провайдеры смотрят на холодный IP-адрес и безызвестное доменное имя отправителя. И когда этот незнакомец вдруг пытается одним махом разослать 70 000 писем, срабатывает сигнализация. Сначала все послания летят в Спам, а если продолжать в том же духе, сервер просто блокируют. Это не злой умысел почтовиков — их системы автоматически блокируют массовые рассылки с нового IP для защиты пользователей от реального мусора.

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

Естественно, до начала прогрева мы готовим техническую базу: настраиваем записи SPF, DKIM и DMARC. Это своего рода цифровой паспорт, который подтверждает подлинность отправителя и отделяет нас от почтовых мошенников. Грамотная настройка этих параметров — гигиенический минимум, база для любой легитимной рассылки. Пропустить этот этап — значит поставить крест на всей затее.

Фактор времени: почему запас всегда кстати

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

Пришлось достать калькулятор. Вводные для расчета были такие: база на 70 тысяч пользователей, каждому нужно отправить минимум по три письма для повышения конверсии. Итого — 210 тысяч писем. Времени у нас было 20 рабочих дней. Дополнительные ограничения тоже были понятны: интервал в 3-4 дня между повторными письмами одному и тому же адресату и классическое правило прогрева — наращивать суточный объем отправки не более чем на 10-15%.

Простая арифметика показала: чтобы по всем правилам прогреть один сервер до наших объемов, нужно 38 рабочих дней. А в нашем распоряжении было всего 20. И вишенка на торте: времени на тренировочные рассылки уже не было. Пришлось прогреваться сразу боевыми письмами — теми самыми, для сбора согласий на обработку персональных данных. Такой расклад превращал команду в саперов: без права на ошибку, каждое письмо с первого дня должно было дойти до адресата.

Решение: распараллелить процесс

Втиснуть расчетные 38 дней работы в 20-дневный спринт было невозможно — любая команда это почувствовала бы сразу. Решение вырисовывалось такое: мы развернули два почтовых сервера вместо одного, разделили нагрузку и прогревали их параллельно. Так снизили риск блокировок, ускорили рассылку и уложились в дедлайн заказчика.

Для наших DevOps-инженеров это означало удвоение работы по настройке и запуску инфраструктуры. Они развернули, настроили и взяли на сопровождение два идентичных, но независимых почтовых сервера. Всю базу пользователей мы разделили пополам и закрепили каждую часть за своим сервером. Каждый из них таким образом выстраивал репутацию постепенно и предсказуемо.

Процесс шел синхронно. Мы начали с минимальных объемов, отправляя боевые письма о сборе согласий, а дальше ежедневно и методично наращивали лимиты отправки, не превышая планку прироста в 10-15%. При этом непрерывно контролировали ключевые технические параметры: лимиты отправки в час и в сутки, а также процент возвратов, чтобы немедленно реагировать на любые признаки блокировок. По сути, мы вели две параллельные, крайне осторожные рассылочные кампании.

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

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

Вывод: считаем цену промедления

Эти процессы дали нам повод перевести разговор в плоскость денег, чтобы выводы стали более осязаемыми. Сразу оговоримся: для расчетов возьмем средние по рынку цифры. В конкретном проекте они могут отличаться, но порядок сумм и, главное, выводы останутся теми же.

Дано:

• Стоимость часа DevOps-инженера: 5 000 руб.
• Стоимость часа системного администратора на поддержку: 3 000 руб.
• Настройка одного сервера: 50 часов.
• Сопровождение одного сервера: 40 часов в месяц.
• Аренда одного сервера: 35 000 руб. в месяц.
• Стоимость серверного окружения (ОС, антивирусы и т.д.): 60 000 руб.
  
  

Сценарий 1: Плановый (2 месяца на подготовку)

Мы спокойно готовим один сервер.

• Аренда сервера: 35 000 × 2 мес. = 70 000 руб.
• Серверное окружение: 60 000 руб.
• Настройка: 50 ч × 5 000 руб. = 250 000 руб.
• Сопровождение: 40 ч/мес. × 2 мес. × 3 000 руб. = 240 000 руб.
  
  

Итого: 620 000 руб.

Сценарий 2: Авральный (1 месяц на подготовку)

Нам нужно два сервера, чтобы уложиться в сроки.

• Аренда серверов: 35 000 × 2 шт. = 70 000 руб.
• Серверное окружение: 60 000 × 2 шт. = 120 000 руб.
• Настройка: 50 ч × 2 сервера × 5 000 руб. = 500 000 руб.
• Сопровождение: 40 ч/мес. × 2 сервера × 3 000 руб. = 240 000 руб.
  
  

Итого: 930 000 руб.

Разница в стоимости — 310 000 рублей для данного примера, но сумма здесь не показательна. Гораздо показательнее другая цифра — рост затрат почти в полтора раза. Это цена одного месяца промедления. Экономия могла бы быть еще больше. Например, когда у вас цейтнот, вы берете те серверы, которые есть в наличии прямо сейчас, потому что не можете ждать 2-3 дня и искать более интересное предложение. Добавим сюда еще и нефинансовые потери: выгоревшая команда, потраченные нервы, избыточные риски — в смете этого не увидишь.

Еще один момент: 70 тысяч адресов — небольшой объем для корпоративных рассылок. А если база в 3 раза больше, то есть 210 тысяч адресов, а сроки те же? Затраты и, соответственно, потенциальная экономия растут кратно. В нашем примере упущенная выгода составила бы уже более 930 000 рублей. Так, на первый взгляд, копейки складываются в очень внушительные суммы.

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

Поэтому, когда в следующий раз на совещании кто-то скажет: давайте еще немного подумаем над темой письма, достаточно показать простую формулу:
1 месяц раздумий = 1 дополнительный сервер в смете.

P.S. Эту CRM для безопасных рассылок мы превратили в один из наших готовых продуктов. Он доступен компаниям, которым важно управлять безопасностью хранения ПДн при организации рассылок в своем защищенном контуре.