Как один месяц согласований увеличил стоимость проекта в 1,5 раза

Привет, Хабр! Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора «Энсайн». Больше 20 лет я занимаюсь системной интеграцией и управлением проектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти процессы дали мне, как руководителю, повод к некоторым размышлениям. 

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

Дано:

• Стоимость часа DevOps-инженера: 5 000 руб.

• Стоимость часа системного администратора на поддержку: 3000 руб

• Настройка одного сервера: 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 для безопасных рассылок мы превратили в один из наших готовых продуктов. Он доступен компаний, которым важно управлять безопасностью хранения ПДн при организации рассылок в своем защищенном контуре.