Сбор аналитики на своём железе: где ломается схема и как собрать её без сюрпризов

Если вся аналитика крутится у вас, узкие места обычно одни и те же: DNS, диск, сеть, права на запись. Сначала отделите приём событий от обработки: один endpoint для инжеста, отдельная очередь или буфер, отдельно хранилище и отчётный слой. Иначе любая задержка в отчётах начнёт тормозить приём данных.

Минимальный набор проверок:
— HTTP endpoint только за reverse proxy с TLS и лимитом на размер тела.
— Очередь между приёмом и записью: Redis, Kafka или хотя бы локальный буфер.
— Диск под сырые события — SSD, под архив — отдельный том; не смешивайте с системным разделом.
— Логи и метрики: latency, error rate, queue lag, disk I/O, свободное место.

На сервере сразу режьте доступ: SSH по ключам, закрытые порты через firewall, отдельный пользователь для сервиса, права на каталог данных — только ему. Схема «всё под root» работает до первого сбоя. Для отказоустойчивости держите минимум два узла инжеста и один независимый бэкап каталога с сырыми событиями.

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

Meta ограничивает расходы на токены для сотрудников

Meta ввела внутренние лимиты на использование ИИ из-за резкого роста расходов: в 2026 году только на сотрудников заложены миллиарды долларов, а общий бюджет на ИИ-инфраструктуру оценивается в 130–145 млрд. Вывод простой: даже у Big Tech ИИ перестал быть бесплатной игрушкой и требует жёсткого контроля затрат.

➡️ Читайте на сайте: https://aff.top/blog/meta-ogranichivaet-raskhody-na-tokeny-dlia-sotrudnikov

🧠 Ещё больше инсайтов → в канале AFF.top

Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

🧠 Ещё больше инсайтов → в канале AFF.top

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

🧠 Ещё больше инсайтов → в канале AFF.top

SPF и DKIM ломают доставку чаще, чем контент письма

Если рассылка уходит в спам или режется на приёме, сначала проверяйте DNS, а не шаблон письма. Базовый набор такой:
— SPF: одна TXT-запись на домен отправителя, без дублирующих политик
— DKIM: отдельный селектор, ключ не короче 1024 бит
— DMARC: хотя бы p=none для наблюдения за ошибками

Главная ошибка — несколько SPF-записей на один домен. Должна быть одна, собранная через include и ip4/ip6. Вторая проблема — забытый выравненный домен: письмо подписано одним доменом, а From указывает на другой. Для фильтров это уже повод ухудшить репутацию.

DKIM проверяется просто: отправили тест, открыли заголовки, нашли DKIM-Signature, потом сверили, что подпись проходит по тому же селектору, который лежит в DNS. Если ключи меняли — старый селектор не удаляйте сразу, пока все сервисы не переедут. Иначе получите плавающий брак на части трафика.

Отдельно смотрите на обратные записи и HELO/EHLO: если сервер представляется одним именем, а PTR ведёт в другое, часть почтовиков снижает доверие. Стабильность — это отсутствие магии, только предсказуемая конфигурация.

Проблема не в сервере, проблема в его настройке. Разворачиваем, проверяем, мониторим.

Логи сервера показывают, где сливается бюджет, если смотреть не на CTR, а на ошибки доставки

Проблема обычно не в «плохом трафике», а в том, что часть запросов не доходит до трекера или падает на уровне инфраструктуры. В логах это видно быстро: 4xx, 5xx, таймауты, редиректы по кругу, пустые ответы от upstream. Если в отчёте конверсии есть, а в access/error-логах растут отказы, деньги уходят в пустоту.

Смотрите не только на код ответа, но и на связку:
• всплеск 499/504 — клиент не дождался ответа, теряете сессии
• 301/302 в цепочке из 3+ переходов — лишняя задержка и обрыв атрибуции
• 200 с пустым телом или битым JS — трекинг не сработал, лид не засчитан
• рост 5xx на одном роуте — проблема в backend, а не в креативах

Дальше нужны кореляции по времени. Сверяйте логи веб-сервера, прокси, приложений и трекера в одном таймлайне. Если ошибки идут пачкой после роста RPS, значит сервер не выдерживает нагрузку и начинает резать заявки. Если ошибки локальны по одному IP, подсеть или ASN можно сразу уводить в отдельную проверку.

Минимальный порядок работы: включить раздельные логи по виртуальным хостам, хранить request_id, поднять alert на аномальный рост 4xx/5xx и раз в день смотреть топ URL по ошибкам. Стабильность — это отсутствие магии, только предсказуемая конфигурация. Разворачиваем, проверяем, мониторим.

Nginx для лендинга: 5 настроек, которые убирают лишнюю нагрузку

Если лендинг ловит всплески трафика, Nginx должен отдавать статику и резать лишнюю работу, а не «помогать» PHP пережимом CPU. Базовый набор: worker_processes auto; worker_connections 4096; use epoll; multi_accept on; — это снижает шанс упереться в лимит соединений раньше, чем в железо.

Включите keepalive_timeout 15; keepalive_requests 1000; и отдавайте css, js, картинки с долгим cache-control. Для статики: sendfile on; tcp_nopush on; tcp_nodelay on; — это убирает лишние копирования и сокращает задержку на мелких ответах. Сжатие держите умеренным: gzip on; gzip_types text/plain text/css application/javascript application/json; иначе CPU начнёт работать на упаковку мусора.

Если лендинг генерируется приложением, кэшируйте HTML на уровне Nginx через proxy_cache или fastcgi_cache. Даже короткий TTL снимает пиковую нагрузку на upstream и делает поведение предсказуемым. Для защиты от «медленных» клиентов ставьте client_body_timeout 10s; client_header_timeout 10s; send_timeout 15s; — это отсекает соединения, которые только занимают сокеты.

Проверьте лимиты ОС: somaxconn, file-max, ulimit -n, а также backlog в listen. Без этого Nginx можно настроить правильно, но упрётся в ядро. Стабильность — это отсутствие магии, только предсказуемая конфигурация. Разворачиваем, проверяем, мониторим.