Go инженер (реконсиляция и расчёты)

Что предстоит делать

<h3>Описание роли</h3><p>Инженер, который отвечает за всё, что происходит после операций в реальном времени. Уведомления поступают с биржи вещателя в три этапа. Показатель аудитории пересматривается дважды, и биржа сообщает сумму к оплате, с которой должны сходиться наши записи. Ничего из этого сейчас не существует: клиент подтвердил на созвоне, что процесс сверки будет построен с нуля.</p><p>Модель подсчёта — это продукт на данной позиции. Оценочная аудитория поступает вместе с рекламной возможностью. Уведомление о показе следует сразу после эфира. Предварительные подсчёты показов и сумма к оплате поступают вскоре после этого и выводятся из внешней системы измерения рейтингов просмотра. Подтверждённые цифры поступают на следующий рабочий день. Три числа описывают один рекламный ролик, и ни одно из них не может перезаписывать другие.</p><p>У клиента уже развёрнута аналитическая инфраструктура, и он намерен, чтобы эта система подключалась к ней, а не заменяла её: их словами, нам просто нужно подключиться к этой существующей аналитической инфраструктуре, чтобы мы могли легко создавать эти возможности для отчётности и биллинга. Документация по интерфейсу была запрошена и не поступила, поэтому установление того, чем на самом деле является этот интерфейс, составляет часть первых недель работы.</p><p>Полная занятость с первого этапа до передачи в промышленную эксплуатацию. Подчиняется нашему solution-архитектору и работает бок о бок с C++ инженерами над путём обработки запросов.</p><h3>О проекте</h3><p><strong>Клиент:</strong> устоявшаяся supply-side платформа, работающая в масштабе. Вовлечение — это полностью аутсорсинговая разработка. Клиент предоставляет продакт-менеджера для требований и объёма работ, архитектора в режиме ревью и надзора, и специалиста по инфраструктуре для сред UAT и продакшена. Мы владеем поставкой, архитектурой и всем, что до UAT.</p><p><strong>Продукт:</strong> рекламный мост, соединяющий клиента с программной линейной платформой японского вещателя, построенный отдельно от основного RTB-стека клиента. Он работает как слой трансляции и как облегчённая supply-side платформа, проводящая аукцион. Три стороны определяют его границы:</p><ul><li>Биржа вещателя является источником рекламных возможностей, доступ к которому осуществляется через спецификацию подключения, которую определяет вещатель, а мы реализуем под неё, не имея возможности её изменить.</li><li>Внешняя система измерения рейтингов просмотра определяет, сколько людей увидело каждый рекламный ролик. Мы никогда не вызываем её напрямую. Биржа получает подсчёты показов из этих рейтингов и сообщает их дважды: предварительно вскоре после эфира и подтверждённо на следующий рабочий день.</li><li>Поверхность конфигурации клиента поставляет спрос в виде активированных прямых сделок. Опциональная вторая фаза добавляет сторонние demand-side платформы через oRTB.</li></ul><p>Этапы: обязательная первая фаза полностью работает в нативном протоколе вещателя и не требует конвертации протоколов. Опциональная вторая фаза добавляет конвертацию oRTB и прямое взаимодействие с demand-side платформами. Внутренняя модель выровнена по oRTB с первой фазы, поэтому вторая становится задачей сопоставления границ.</p><p>Текущее положение: greenfield. Ничего не построено. Спецификация подключения вещателя существует и версионируется, хотя история её ревизий показывает постоянные правки. Документ с требованиями пока не существует.</p><p><strong>Стек:</strong> Go на стороне расчётов, сверки и справочных данных, с C++ на пути обработки запросов. Клиент назвал Go для независимых инструментов и задач, а также предложил перенести оценку сделок в Go-сервис ради конкурентности; эта граница открыта, и данная позиция помогает её определить. Система разворачивается в собственных дата-центрах клиента и должна быть построена с готовностью к облаку.</p><h3>Ключевые обязанности</h3><p><strong>Уведомления и расчёты</strong></p><ul><li>Создать приёмник уведомлений: идемпотентный при повторах, поскольку биржа повторяет запросы при 429 и 5xx с экспоненциальной задержкой, изначально пять попыток, и устойчивый к дубликатам и позднему прибытию.</li><li>Обрабатывать уведомления, которые биржа отправляет за временные окна, в которых ничего не выходило в эфир, не позволяя им регистрироваться как показы.</li><li>Фиксировать прогнозируемые, предварительные и подтверждённые показатели показов и биллинга бок о бок как append-only запись с пересмотром, чтобы ни одна цифра не перезаписывала предыдущую.</li><li>Сверять наши цифры с суммой к оплате, которую сообщает биржа, и выводить расхождение как полноценный результат, а не как повод для расследования.</li><li>Относиться к задержке расчётов как к нормальному трафику. У источника рейтингов есть плановые окна технического обслуживания, и спецификация гласит, что более поздние уведомления могут быть задержаны.</li></ul><p><strong>Справочные данные</strong></p><ul><li>Создать сервис синхронизации для трёх справочных интерфейсов биржи: статус креативов и материалов, базовые расписания программ и ежедневные расписания программ.</li><li>Обрабатывать идентификаторы, которые не уникальны для разных вещательных станций, и корректировки расписаний, которые вещатель регистрирует после эфира.</li></ul><p><strong>Аналитика и отчётность</strong></p><ul><li>Подключить конвейер к существующей аналитической инфраструктуре клиента, а не разворачивать параллельную, и определить этот интерфейс вместе с клиентом там, где он не документирован.</li><li>Удерживать единицу подсчёта постоянной от захвата события через агрегацию до отчёта покупателя, пока число под ней меняется.</li><li>Сделать настоящий ноль отличимым от сбоя интеграции внутри конвейера, прежде чем кто-либо прочитает отчёт.</li><li>Обеспечить аудируемый след от любой выставленной суммы обратно до аукциона, который её породил.</li></ul><p><strong>Сервисы, выделенные из пути обработки запросов</strong></p><ul><li>Создавать независимые Go-сервисы там, где архитектор и клиент согласны, что им там место. Клиент назвал оценку сделок кандидатом по причинам конкурентности, и это решение ещё не принято.</li></ul><h3>Требуемая квалификация</h3><p><strong>Опыт</strong></p><ul><li>5+ лет продакшен-разработки на Go, включая сервисы и пакетные конвейеры, а не что-то одно.</li><li>Создавал конвейер данных, чей источник истины был внешним и подвержен пересмотру, а не отчётный конвейер над данными, которые система производила сама.</li><li>Создавал идемпотентный приёмник для колбэков третьей стороны при доставке at-least-once и сталкивался с дубликатами в продакшене.</li><li>Интегрировался в аналитическую или data-платформу, принадлежащую другой команде, через интерфейс, который не проектировал и не мог изменить.</li></ul><p><strong>Техническая грамотность</strong></p><ul><li>Go для сервисов и конвейеров, с примитивами конкурентности, выбранными осознанно, а не используемыми по привычке.</li><li>Идемпотентность и дедупликация при доставке at-least-once: повторы с задержкой, дубликаты, нарушение порядка и позднее прибытие.</li><li>Append-only моделирование событий с пересмотром, где заменённая цифра сохраняется, а не замещается.</li><li>Проектирование сверки, которое локализует расхождение, а не просто обнаруживает его.</li><li>Синхронизация справочных данных с ретроактивными правками, где идентификаторы не уникальны между источниками.</li><li>Аналитическое моделирование данных для отчётности и уверенное владение колоночным или масштабируемым аналитическим хранилищем. Клиент назвал осведомлённость о больших данных одной из трёх ключевых областей навыков.</li><li>Проектирование HTTP-клиента и сервера под спецификацию, которой владеет контрагент.</li></ul><p><strong>Суждения и мягкие навыки</strong></p><ul><li>Относится к выставленной сумме как к коммерческому требованию и не выпустит число, чей вывод не сможет проследить в обратном направлении.</li><li>Понимает, что число, пересмотренное дважды, — это три числа, и что отбрасывание первых двух — это путь к тому, что биллинговый спор станет безответным.</li><li>Спокойно относится к тому, что интерфейс к аналитической платформе клиента не определён на первый день, и считает его определение частью работы, а не блокером.</li><li>Различает, что спецификация утверждает, и что она подразумевает, и помечает разницу как открытый вопрос.</li><li>Поднимает риск зависимости с названным ответственным и датой, а не как общее опасение.</li></ul><h3>Знание домена — обязательно</h3><p>Человек, решающий, что считать доставленным показом, решает, что будет выставлено покупателю, и ошибка там порождает уверенные, неверные числа, которые переживают ревью, потому что ничто не выглядит сломанным.</p><p>Требуется и переносится между adtech-платформами:</p><ul><li>Учёт показов, где одно доставленное объявление достигает более чем одного человека и где цифра аудитории поставляется или моделируется, а не подсчитывается на устройстве.</li><li>Семантика уведомлений и колбэков: уведомления о победе и биллинге, подстановка макросов, дубликаты и поздняя доставка, а также аналог доказательства показа.</li><li>Сверка биллинга между сторонами: забронировано против доставленного против того, что контрагент сообщает как свой долг, и обнаружение расхождений, когда слои не согласуются.</li><li>Механика программных аукционов со стороны продавца, достаточная, чтобы понимать, что выигранная ставка — это не доставленный показ.</li><li>Гранулярность отчётности и разница между оценкой, предварительной цифрой и урегулированной цифрой в отчёте покупателя.</li></ul><p>Специфично для данного проекта и ожидается, что будет освоено, а не уже имеется:</p><ul><li>Спецификация уведомлений вещателя и её трёхэтапное урегулирование.</li><li>Измерение рейтингов просмотра третьей стороной как источник количества показов для биллинга.</li></ul><p>Ожидается глубина в adtech-биллинге, сверке доходов или измерении медиа.</p><h3>Будет плюсом</h3><ul><li>Adtech-биллинг, сверка доходов или выплаты издателям.</li><li>Расчётные или финансовые системы вне рекламы, где пересмотр и аудируемые следы являются обычными требованиями.</li><li>Колоночные аналитические хранилища на масштабе отчётности, включая проектирование схем для агрегации во время запроса.</li><li>C++ на уровне чтения, поскольку путь обработки запросов написан на нём, и граница между двумя языками может сместиться.</li><li>Предыдущий опыт работы с данными измерений на основе панелей или опросов, где цифра является оценкой с привязанной уверенностью.</li><li>Предыдущий опыт работы с технической документацией в переводе.</li></ul>