Инженер по сборке и инфраструктуре (C++/Go)

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

<h3>Описание роли</h3><p>Инженер, который владеет всем, что нужно команде разработки для сборки, тестирования и поставки, вплоть до момента, когда система попадает в собственные окружения клиента.</p><p>Клиент зафиксировал эту границу в письменном виде: они владеют настройкой инфраструктуры в своих дата-центрах для UAT и продакшена, а на этапе разработки, до UAT, мы занимаемся этим на нашей стороне.</p><p>Таким образом, область ответственности ограничена, но внутри этих границ это вся работа целиком. Среды разработки и тестирования, непрерывная интеграция для смешанной кодовой базы на C++ и Go, управление сборкой и зависимостями, создание артефактов и наблюдаемость, необходимая команде в процессе разработки. Всё заканчивается передачей через организационную границу в дата-центры, с которыми эта роль никогда не работает.</p><p>Клиент выделит одного инфраструктурного специалиста для работы с командой, и их заявленное намерение состоит в том, чтобы этот человек понимал архитектуру с самого начала, а не знакомился с ней на этапе UAT. Наладить это сотрудничество на раннем этапе — часть работы. Поздняя передача блокирует путь к продакшену, а за этим стоит дата готовности в ноябре.</p><p>Полная занятость, с наибольшей нагрузкой в начале, пока настраиваются пайплайн и окружения.</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><strong>Фазирование:</strong> обязательная первая фаза полностью работает в нативном протоколе вещателя и не требует конвертации протоколов. Опциональная вторая фаза добавляет конвертацию oRTB и прямую связь с demand-side платформами. Внутренняя модель выровнена по oRTB с первой фазы, поэтому вторая становится задачей маппинга на границах.</p><p><strong>Текущее положение:</strong> greenfield. Ничего не построено. Спецификация подключения вещателя существует и версионируется, хотя история её ревизий показывает продолжающиеся правки. Документ с требованиями пока не существует.</p><p><strong>Стек:</strong> C++ на пути обработки запросов, Go на стороне расчётов. Система разворачивается в частных дата-центрах клиента и должна быть построена cloud-ready, по словам клиента, чтобы перенос в облако позже не был отдельным проектом. Структура репозитория, инструменты непрерывной интеграции, стек наблюдаемости и топология окружений не обсуждались с клиентом и открыты для установления этой позицией.</p><h3>Ключевые обязанности</h3><p><strong>Сборка и непрерывная интеграция</strong></p><ul><li>Настроить сборку для смешанной кодовой базы на C++ и Go, включая управление зависимостями и линковку с библиотеками, которые предоставляет существующая платформа клиента.</li><li>Построить пайплайн: компиляция, выполнение тестов, создание и версионирование артефактов, с воспроизводимыми результатами.</li><li>Поддерживать время сборки достаточно коротким, чтобы инженеры, работающие с путём запросов, не ждали его.</li></ul><p><strong>Окружения до UAT</strong></p><ul><li>Предоставлять и поддерживать среды разработки и тестирования для всей команды, поскольку клиенту ничего не принадлежит до UAT.</li><li>Предоставить инфраструктуру, на которой будет работать автоматизация тестирования, после согласования формы этой автоматизации. Инструменты тестирования никогда не обсуждались с клиентом и по умолчанию ложатся на нас.</li><li>Сделать систему воспроизводимой и разворачиваемой, чтобы передача в окружения клиента была упражнением по конфигурации, а не по исследованию.</li></ul><p><strong>Пакетирование и наблюдаемость</strong></p><ul><li>Упаковать и задокументировать развёртывание, чтобы инфраструктурный специалист клиента мог поднять UAT и продакшен на его основе.</li><li>Настроить наблюдаемость во время разработки, которая сохранится в операционном окружении клиента, а не будет пересоздаваться там.</li><li>Управлять учётными данными через организационную границу. Интерфейс биржи использует отдельные API-ключи в каждом направлении, выпущенные разными сторонами.</li></ul><p><strong>Работа через границу</strong></p><ul><li>Взаимодействовать с инфраструктурным специалистом клиента с самого начала, как они и просили, а не на этапе передачи.</li><li>Отслеживать передачу UAT и продакшена как зависимость с датой и поднимать вопрос в момент, когда срок срывается.</li><li>Согласовать с клиентом структуру репозитория, инструменты пайплайна, наблюдаемость и топологию окружений, поскольку ничего из этого не обсуждалось.</li></ul><h3>Требуемые квалификации</h3><p><strong>Опыт</strong></p><ul><li>5+ лет в инженерии сборки, релизов и инфраструктуры, с как минимум одним проектом, доведённым от нуля до работающего пайплайна.</li><li>Владение непрерывной интеграцией для кодовой базы на компилируемом языке, конкретно C++ или близком эквиваленте, где время сборки и управление зависимостями были реальными проблемами, а не второстепенными мыслями.</li><li>Опыт поставки системы в инфраструктуру, которой управляет другая организация, и проведение этой передачи, а не наблюдение за ней.</li><li>Опыт работы с целевой средой on-premises или частным облаком, а не только с публичным облачным аккаунтом, которым управлял от начала до конца.</li></ul><p><strong>Техническая компетентность</strong></p><ul><li>Непрерывная интеграция для C++ и Go: тулчейны, кэширование сборки, воспроизводимые сборки, версионирование артефактов.</li><li>Контейнеризация и оркестрация, с пониманием того, что частный дата-центр реально примет.</li><li>Инфраструктура как код и управление конфигурацией, применённые к окружениям, которые переживут человека, создавшего их.</li><li>Наблюдаемость, встроенная во время разработки: метрики, логи и трейсы как задача времени сборки, а не доработка на продакшене.</li><li>Обработка секретов и учётных данных, где ключи выпускаются двумя организациями и ротируются по их графику, а не нашему.</li><li>Паритет окружений и режимы отказа, когда разработка и целевая среда расходятся.</li><li>Cloud-agnostic</li></ul><p><strong>Суждения и мягкие навыки</strong></p><ul><li>Ограничивает собственную область ответственности. Эта позиция заканчивается на UAT, и клиент владеет тем, что за ней. Тот, кто не может удержать эту линию, либо делает работу клиента бесплатно, либо оставляет пробел, который никто не закрывает.</li><li>Строит с прицелом на передачу с первой недели, потому что человек, который будет управлять этой системой на продакшене, работает на кого-то другого.</li><li>Относится к коллеге из другой компании как к партнёру, а не как к очереди тикетов, и получает необходимое, спрашивая заранее.</li><li>Поднимает зависимостный риск с указанием ответственного и даты.</li><li>Всё записывает. У клиента нет задокументированных ожиданий по инструментам, поэтому всё, что решит эта позиция, по умолчанию становится стандартом.</li></ul>