Senior Data Platform Engineer (GCP) — аудит і доведення до релізу платформи даних HeadData
Проєктна робота · Remote
Шукаємо інженера платформного рівня, який спочатку дасть незалежну оцінку поточної архітектури і збірки, погодить напрям робіт із CTO, а потім разом із нашим інженером доведе платформу даних до релізу.
Про продукт
HeadData — платформа маркетингової аналітики. Дані з рекламних кабінетів (TikTok, Meta, Google Ads) і CRM клієнтів збираються, нормалізуються та передаються у застосунок, де з ними працює користувач.
Контекст задачі
Ми випускаємо першу версію платформи, готову до використання клієнтами. Платформа побудована як контрактна система з шарами Bronze → Silver → UDM → Gold, реєстрами контрактів і шлюзом, який приймає лише те, що підтверджене реєстром (fail-closed). Є докладна документація в Confluence: канон і патерни, близько 24 Terraform-модулів із парними сторінками реєстрації, специфікації сервісів. Пайплайни переносимо з Cloud Composer на Cloud Data Fusion.
Чого немає — незалежної відповіді на питання, наскільки поточна архітектура і збірка коректні під задачу. Документація ще жодного разу не була повністю звірена з живою системою. Частина написаного ще не розгорнута в продакшені, частина інструментів шлюзу не реалізована. Нам потрібна людина, яка подивиться на це ззовні, дасть оцінку і потім допоможе довести до релізу.
Що треба зробити
Аудит. Розібратись в архітектурі за документацією і живою системою (Terraform-стан, ревізії Cloud Run, схеми BigQuery, шлюз). Дати висновок: що коректно, а що ні, де документ розходиться із системою, які ризики, який напрям рекомендуєте — доводити як є, коригувати або перебудовувати окремі частини.
Погодження напряму. Захистити висновок перед CTO, домовитись про план і межі змін.
Доведення до релізу. Разом із поточним інженером довести платформу до стану, коли Runbook повністю виконується на живій системі без ручних обхідних кроків: застосувати написане, але не застосоване; реалізувати відсутні інструменти шлюзу; усунути розбіжності контрактів між компонентами; розгорнути модулі, що ще не в продакшені; провести першого тенанта через повний цикл.
Звірка. Кожен закритий крок фіксується як «документ = система» або як розбіжність, передана автору документації. Без окремого рішення ні документ не підганяється під систему, ні система під документ.
Кого шукаємо
Від 5 років у data engineering, з них щонайменше 2 — на платформному рівні: не тільки пайплайни, а інфраструктура, на якій вони живуть.
GCP як основне середовище: Terraform у продакшені (state, дрейф), Cloud Run / Cloud Run Jobs, BigQuery включно з DDL і міграціями схем, GCS, IAM і сервісні акаунти. Досвід роботи з lakehouse-форматами (Iceberg / Delta / Hudi) і Medallion-архітектурою.
Python на рівні сервісів, а не скриптів: можете розібратися в чужому сервісі (наприклад, provisioning consumer) і написати сусідній інструмент у тому ж стилі.
Досвід аудиту архітектури чужих систем: за кілька тижнів розбираєтесь у незнайомій платформі й даєте аргументований висновок із пріоритетами.
Інженерна дисципліна: Git і code review, невеликі регулярні коміти, прозорий статус задач.
Уміння працювати в парі з автором системи: аргументувати рішення письмово і конструктивно, без конфронтації.
Буде Важливим плюсом
Cloud Data Fusion, Composer / Airflow, зокрема досвід міграції з Composer на Data Fusion; Dataflow / Beam.
Досвід роботи з MCP або іншими інструментами, через які з платформою працюють LLM-агенти.
Робота з API рекламних платформ (Meta, TikTok, Google Ads).
Data contracts, schema registry, multi-tenant платформи даних.
Звичка вести документацію в Confluence у процесі роботи, а не після.
Умови
Проєктна робота. Обсяг, графік і тривалість — за домовленістю після першої розмови; орієнтир для аудиту — кілька тижнів, далі план визначає сам аудит.
Задачі ведемо в ClickUp, код — у Git, документацію — в Confluence.
Після завершення проєкту — можливий перехід у штат або продовження part-time, залежно від резу
