Заказчику нужно было отправить письма 70 000 человек. На первый взгляд, достаточно загрузить таблицу в сервис рассылок и нажать кнопку.
Но клиентские данные нельзя было передавать внешней платформе. Каждое согласие на получение писем требовалось подтвердить. Если человек отказывался от рассылки, система должна была сразу исключить его из базы.
Обычная рассылка постепенно превратилась в разработку отдельной CRM.
Почему не подошел готовый сервис
С отправкой писем проблем не было. Это умеют десятки платформ.
Проблема возникала раньше, еще до нажатия кнопки:
- где хранится список получателей;
- кто может его изменить;
- как доказать, что человек согласился получать письма;
- что произойдет после отказа;
- можно ли восстановить историю изменений.
Готовый сервис оставлял часть этих процессов на своей стороне. Заказчику требовалось управлять ими внутри собственной инфраструктуры.
Поэтому команда решила создать CRM на Django.
У каждого контакта появилась история
В систему загружались контактные данные и текущий статус согласия. Каждому человеку назначался длинный уникальный идентификатор из 128 символов.
Он использовался при подтверждении и отказе от рассылки. Подобрать такой идентификатор случайно практически невозможно.
Любое важное действие записывалось в журнал. В нем можно было увидеть, когда контакт появился в базе, когда подтвердил согласие и когда отказался от сообщений.
Это было важно не только для проверок. Журнал помогал разбирать обычные спорные ситуации. Например, почему один человек получил письмо, а другой был исключен из отправки.
Отказ должен срабатывать сразу
Ручное управление списком быстро привело бы к ошибкам. Один сотрудник получил отказ, другой не обновил таблицу, третий загрузил старую версию базы.
Поэтому согласиями управляла сама CRM.
Человек нажимал кнопку подтверждения - статус обновлялся. Нажимал "Отказаться" - запись исключалась из следующих рассылок. Оба действия сохранялись в журнале.
Перед отправкой система формировала актуальную выборку. Сотруднику не требовалось сравнивать несколько файлов.
Письма тоже создавались внутри системы
В CRM добавили редактор шаблонов. Заказчик мог собрать письмо без отдельного сервиса.
В шаблон вставлялись специальные обозначения. Например, вместо имени стояло поле FIO. Перед отправкой система заменяла его данными конкретного получателя.
Там же можно было выбрать нужную группу контактов. Это избавляло от постоянных выгрузок и загрузок таблиц.
Как узнать, что письмо открыли
Готовые платформы показывают подробную статистику. Здесь подключать внешнюю аналитику было нельзя.
Для учета открытий использовали маленькое невидимое изображение размером 1×1 пиксель. Оно находилось внутри письма.
Когда почтовая программа загружала изображение, сервер видел запрос и отмечал открытие.
Метод не дает идеальной точности. Некоторые программы блокируют картинки, а некоторые загружают их заранее. Но для общей оценки рассылки этого хватало.
Почему нельзя сразу отправить все письма
Еще одна сложность появилась после разработки CRM.
Новый почтовый сервер, который внезапно рассылает десятки тысяч писем, выглядит подозрительно. Получающие системы могут отправить сообщения в спам или временно заблокировать источник.
Поэтому объем отправки увеличивали постепенно. Сервер должен был сформировать нормальную репутацию.
Дополнительно настроили SPF, DKIM и DMARC. Если говорить проще, эти записи помогают другим почтовым системам убедиться, что письмо действительно отправлено с разрешенного сервера и адрес отправителя не подменен.
После подготовки скорость приблизилась к 60 000 писем в час. Базу из 70 000 контактов можно было обработать в требуемый срок.
Почему не стали защищать все возможными способами
Систему разместили внутри защищенной инфраструктуры. Использовали РЕД ОС, антивирус Dr.Web и средство контроля доступа Secret Net Studio для Linux.
Можно было добавить еще несколько уровней защиты. Например, полностью зашифровать базу и развернуть отдельные серверы для удаленного подключения.
Каждая дополнительная мера усложняла работу системы и увеличивала расходы на сопровождение. Поэтому команда оценивала, какой конкретный риск она закрывает.
Часть решений не включили в итоговую архитектуру. Для данного сценария они создавали больше сложности, чем пользы.
Что получилось
Бэкенд разработали за 2 недели. Весь проект занял 3 недели без учета согласования дизайна.
Система работала с 70 000 контактами. Она самостоятельно обновляла согласия, исключала отказавшихся пользователей и хранила историю действий.
Перед важной рассылкой заказчик мог получить актуальную базу и запустить отправку внутри собственной инфраструктуры.
Почему простая задача оказалась сложной
Кнопка "Отправить всем" была самой понятной частью системы. Основная работа происходила вокруг нее.
Нужно было определить, откуда берутся данные, кто может ими пользоваться и что делать после отказа человека. Затем потребовалось настроить почтовые серверы и защитить инфраструктуру.
Поэтому объем подобного проекта нельзя оценивать только по числу экранов и функций. Иногда небольшой интерфейс управляет процессом, в котором ошибка затрагивает десятки тысяч людей.
Я занимаюсь системной интеграцией и управлением ИТ-проектами. В подобных задачах именно невидимая для пользователя часть обычно определяет сроки, стоимость и сложность разработки.
Здесь я обычно пишу про проекты, кейсы и ИТ-практику. А если хочется увидеть меня не только в рабочих текстах - приходите в мой тг https://t.me/alekseypostrigaylo. Там - сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.