DNS и SPF/DKIM для рассылок: базовая настройка, без которой письма летят в спам

Для почтовой рассылки нужен не «просто домен», а предсказуемая DNS-зона. Минимум: MX для входящей почты, SPF для списка разрешённых отправителей, DKIM для подписи письма и DMARC для политики проверки. Если домен чистый, начните с отдельного поддомена под рассылки: так проще изолировать репутацию и отлаживать ошибки.

SPF держите коротким. Не складывайте туда все сервисы подряд, иначе упираетесь в лимит DNS-запросов и получаете permerror. Пример логики: один include для платформы рассылки, один для своего SMTP, остальное — убрать. В конце всегда проверяйте, что запись одна, без дубликатов и без лишних пробелов.

DKIM должен совпадать между DNS и MTA. Ключ храните отдельно для каждого домена или поддомена, selector делайте понятным: default, mail, newsletter — не важно, лишь бы без хаоса. После публикации проверьте, что письмо реально подписывается, а не только запись лежит в зоне. Успешная подпись — это не наличие TXT, а совпадение public key, selector и заголовков письма.

DMARC ставьте сначала в режиме мониторинга, потом ужесточайте политику. Смотрите на alignment: домен в From должен совпадать с доменом SPF/DKIM. Если нет — часть писем будет проходить технически, но ломать репутацию. И не забудьте про PTR, rDNS, TLS и корректный HELO: DNS и SPF/DKIM не спасают, если сервер выглядит как случайный хост.

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

CI/CD для деплоя: как убрать ручной шаг и не сломать прод

Ручной деплой почти всегда заканчивается одинаково: забыли переменную, залили не тот конфиг, пропустили миграцию. CI/CD пайплайн нужен не ради моды, а чтобы каждый релиз проходил один и тот же маршрут: сборка, тесты, проверка артефакта, деплой, healthcheck.

База пайплайна простая:
— сборка в изолированной среде;
— секреты только через vault/secret store, не в репозитории;
— отдельные шаги для тестов и упаковки;
— деплой по SSH-ключу или через агент с ограниченными правами;
— откат по последнему стабильному артефакту, а не «соберём заново на месте».

Если деплой идёт на несколько серверов, ставьте последовательность и блокировку. Иначе два параллельных запуска могут перетереть конфиг или миграцию. Перед выкладкой проверьте доступность порта, наличие места на диске, права пользователя и состояние сервиса. После выкладки — не «надеемся», а вызываем health endpoint и смотрим код ответа, логи и время старта. 🔧

Отдельно держите в пайплайне проверку конфигурации: nginx -t, systemctl status, docker compose config, миграции базы в отдельном job. Стабильность — это отсутствие магии, только предсказуемая конфигурация.

Разворачиваем, проверяем, мониторим.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

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

В арбитраже денег нет 💵

Кэш ускоряет сайт только тогда, когда ему заданы границы, а не надежды

Кэширование — это не «включил плагин и забыл». Для маркетингового сайта важны три слоя: браузерный кэш для статики, серверный кэш для HTML и отдельный кэш для тяжелых запросов к базе. Если смешать их в одну корзину, получите либо лишнюю нагрузку, либо устаревшие страницы.

Рабочая схема простая:
— статике ставим долгий Cache-Control и версионируем файлы;
— HTML кэшируем коротко, с быстрым сбросом после изменения контента;
— динамические блоки, формы и личные кабинеты исключаем из кэша;
— для CDN и reverse proxy настраиваем bypass по cookies, query string и заголовкам авторизации.

Проверять нужно не «скорость по ощущениям», а TTFB, hit ratio и количество запросов к бэкенду. Если после включения кэша TTFB не упал, значит вы кэшируете не то. Если hit ratio высокий, а пользователи видят старый контент, значит нет нормальной инвалидации.

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

Как не уронить инфраструктуру, когда трафик растёт в 5 раз за час

Резкий всплеск ломает не только CPU. Обычно первой сдаётся очередь: БД, Redis, email-рассылки, вебхуки, фоновые джобы. Если всё крутится на одном узле, любой пик превращается в каскадный отказ.

Что держать заранее:
— CDN для статики и медиа
— балансировщик с health-check
— автоскейлинг по RPS, очереди и latency
— отдельные воркеры под тяжёлые задачи
— лимиты на rate limit и timeout, чтобы не копить мусор

Перед включением масштабирования проверьте узкие места. Если база не держит write IOPS, добавление веб-серверов не поможет. Если сессии лежат локально, после перераспределения трафика пользователи начнут вылетать. Если логи пишутся синхронно на диск, под нагрузкой вы получите задержки без видимой причины.

Рабочая схема простая: статический контент отдаёт CDN, приложение — горизонтально масштабируемые инстансы, состояние — во внешнем хранилище, тяжёлые операции — через очередь. Сначала тестируйте не пик, а переход: 10%, 30%, 70%, 100% нагрузки с замером p95 latency, ошибок 5xx и длины очереди. Разворачиваем, проверяем, мониторим.

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