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

Programmatic работает на той же инфраструктуре. Bid request, ставки, показы и статистика проходят через серверы, которые стоят в конкретных дата-центрах и часто в конкретных облаках. Когда одна площадка выпадает, последствия чувствуют все участники цепочки. Но сильнее всего — DSP, которая отвечает перед рекламодателем за открутку кампаний.

Разберём, что происходит с закупками в момент сбоя, почему одна точка отказа опаснее, чем кажется, и что DSP может сделать заранее.

Что происходит в programmatic, когда падает площадка

Programmatic-аукцион рассчитан на то, что все участники отвечают быстро и предсказуемо. Сбой ломает это сразу в нескольких местах.

Первое, что происходит, — таймауты. Если у SSP или у самой DSP пропала часть серверов, запросы либо не доходят, либо приходят с большой задержкой. DSP не успевает ответить в отведённое время, и аукцион проходит без неё. Если упала сторона SSP, запросов просто становится меньше, и часть инвентаря исчезает из закупки.

Затем трафик перераспределяется. Пользователи никуда не делись: они открывают сайты и приложения, просто запросы идут другими путями. У других SSP и у резервных серверов резко растёт QPS, и если лимиты не настроены, в узкое место превращаются уже они.

Одновременно дорожает доступный инвентарь. Рекламодатели и DSP продолжают выкупать бюджеты, а предложения на рынке становится меньше. Конкуренция за оставшиеся показы растёт, вместе с ней растут ставки и CPM. Если значительная часть закупки шла через один источник, кампании не добирают показы. Особенно болезненно это для кампаний с жёсткими сроками и для видео, где инвентарь и так ограничен.

Последствия видны и после восстановления. Во время сбоя часть событий теряется: win notice, трекинговые пиксели, события видео. Цифры DSP, SSP и рекламодателя начинают расходиться, и приходится разбираться, какие показы были на самом деле.

Сбой инфраструктуры редко ломает закупки целиком. Гораздо чаще он тихо съедает часть показов, а заметно это становится только в отчёте.

Почему сильнее всех страдает DSP

SSP при сбое теряет часть выручки, паблишер — часть показов. DSP оказывается между рекламодателем, который ждёт открутку по плану, и источниками трафика, которые работают нестабильно.

В OpenRTB-запросе есть поле tmax — максимальное время, за которое DSP должна прислать ответ. Обычно это десятки или сотни миллисекунд. При сбое растут сетевые задержки, и ответ, который в обычный день укладывался в лимит, перестаёт успевать. Ставка формально сделана, но в аукционе не участвует. Подробнее о том, как устроены запрос и ответ, — в статье Что такое OpenRTB.

Если источник отвечает с ошибками, DSP продолжает тратить ресурсы на обработку запросов, которые не превратятся в показы. Нагрузка растёт, а результата нет.

Сбивается и пейсинг. Алгоритмы равномерного расхода бюджета рассчитаны на привычный объём трафика. Когда трафик пропадает, кампания отстаёт от графика. Когда он возвращается, система пытается догнать план и может потратить бюджет слишком быстро и слишком дорого.

В итоге объяснять разницу между планом и фактом приходится DSP. Для рекламодателя неважно, где именно произошёл сбой: кампания открутилась не так, как обещали.

Единая точка отказа

Главный урок любого крупного сбоя: опасна не сама авария, а зависимость от одного элемента. В programmatic таких элементов несколько.

Самый очевидный — один крупный источник трафика. Если большая доля закупки идёт через одну SSP, её недоступность сразу превращается в недокрут. Не менее опасно держать всё в одном облаке или регионе: если серверы DSP, базы данных и сервисы статистики стоят в одной зоне доступности, её сбой останавливает всё сразу. А если трекинг и отчёты зависят от одного сервиса, при его падении теряются данные даже по тем показам, которые прошли успешно.

Есть и неочевидные зависимости: DNS, сертификаты, CDN для креативов, сервисы верификации. Каждый из них может стать узким местом, даже если основная инфраструктура работает.

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

Как защититься

Полностью исключить сбои нельзя. Но можно сделать так, чтобы выпадение одного элемента снижало объём закупки, а не останавливало её.

Основа отказоустойчивых закупок — несколько независимых источников трафика. Важно, чтобы SSP были действительно независимыми: работали на разной инфраструктуре и имели собственные прямые подключения к площадкам. При выборе стоит смотреть и на прозрачность цепочки поставки, об этом мы писали в статье про невалидный трафик.

Второй элемент — автоматическое отключение проблемного источника. Если доля таймаутов или ошибок превышает порог, DSP временно перестаёт отправлять на него ставки или снижает объём обрабатываемых запросов. Когда показатели возвращаются к норме, трафик постепенно включается обратно. Это защищает и от лишней нагрузки, и от трат на запросы, которые не дадут показов.

DSP также должна знать, сколько запросов в секунду она способна обработать, и согласовать лимиты QPS с каждой SSP. Тогда при перераспределении трафика партнёр не перегрузит её сверх возможностей.

Для мониторинга достаточно небольшого набора показателей в разрезе источников: объём запросов, доля ответов со ставкой, доля таймаутов, задержка ответа, win rate, fill rate. Резкое изменение любого из них — сигнал проверить источник раньше, чем проблема дойдёт до рекламодателя.

Критичные сервисы DSP — приём запросов, принятие решения о ставке, сбор статистики — стоит разносить по разным дата-центрам. Резерв должен быть проверен на практике: только регулярные учения с переключением трафика показывают, сработает ли он в реальный сбой. А ограничения на скорость догоняющего расхода бюджета не дадут кампании потратить всё за час после восстановления трафика.

Что согласовать с партнёрами заранее

Технические меры работают лучше, если правила игры зафиксированы с партнёрами до сбоя, а не обсуждаются в его разгаре. Стоит заранее договориться о нескольких вещах:

• SLA: какой уровень доступности обещает партнёр, как он измеряется и что происходит, если обещание не выполнено;
• форс-мажор: какие события к нему относятся и как распределяется ответственность;
• уведомления о сбоях: как и в какие сроки партнёр сообщает о проблемах и кто контактное лицо с каждой стороны;
• сверка статистики: чьи данные считаются основными и что происходит с событиями, которые потерялись;
• восстановление: возвращается ли трафик сразу целиком или постепенно, чтобы не перегрузить ни одну из сторон.

Формулировки про форс-мажор стоит перечитать уже сейчас: многие договоры писались, когда массовые отказы инфраструктуры казались маловероятными.

Чек-лист для DSP

Источники трафика:

• закупка распределена между несколькими SSP, ни одна не даёт критичную долю объёма;
• известно, на какой инфраструктуре работают ключевые партнёры;
• для каждой SSP согласованы лимиты QPS и значение tmax.

Собственная инфраструктура:

• приём запросов, логика ставок и сбор статистики разнесены по разным зонам доступности;
• переключение на резерв проверялось на практике;
• внешние зависимости (DNS, CDN, верификация) учтены в плане восстановления.

Мониторинг:

• метрики в разрезе источников: запросы, ставки, таймауты, задержка, win rate;
• настроены алерты на резкие изменения;
• есть автоматическое отключение источника по порогу ошибок.

Договорённости с партнёрами:

• SLA и условия форс-мажора зафиксированы и актуальны;
• известен порядок уведомления о сбоях и контакты;
• согласованы правила сверки статистики за период сбоя.

О том, какие ещё параметры важно проверить у технологических партнёров, читайте в статье Как выбрать DSP-платформу.

Как Adtec может быть полезен

Adtec — SSP с собственной командой разработки. Мы работаем с крупными DSP по OpenRTB и VAST. Подключаем рекламный спрос к инвентарю сайтов.

Для DSP, которые хотят снизить зависимость от одного источника трафика, Adtec может стать дополнительным независимым источником supply. При подключении мы используем индивидуальный подход: согласовываем лимиты QPS, таймауты и формат запросов, а также обсуждаем порядок связи и сверки статистики на случай нештатных ситуаций.

Если вы DSP и ищите дополнительные источники трафика, расскажите о своих требованиях — обсудим, как выстроить интеграцию.

Главное

• Сбой одного дата-центра или облака бьёт по всей programmatic-цепочке: таймауты, всплески нагрузки, рост цен, недокрут, расхождения в отчётах.
• Сильнее всех страдает DSP: задержки съедают tmax, сбивается пейсинг, отвечать перед рекламодателем приходится ей.
• Главный риск — единая точка отказа: один источник трафика, одно облако, один сервис статистики.
• Защита строится из нескольких независимых SSP, автоотключения проблемных источников, лимитов QPS, мониторинга и проверенного резерва.
• SLA, форс-мажор, уведомления и правила сверки лучше согласовать с партнёрами до сбоя.