ВладимирИванов

По условиям задачи нужно было организовать рассылку рыночных данных с низкими задержками нескольким получателям. Я разбил работу на несколько этапов.

• Спроектировал оркестрацию воспроизводимого стенда в AWS EC2 через Terraform и SSM с синхронизацией часов ENA PHC/chrony, чтобы AI-агент имел надёжный feedback loop для итераций оптимизаций.
• Сконфигурировал систему для уменьшения джиттера: CPU pinning и isolation, IRQ affinity, tickless cores, вынос RCU callbacks и hugepages.
• Оптимизировал lock-free SPSC кольцевой буфер в разделяемой памяти. Сократил задержку передачи на сотни наносекунд за счёт изоляции кэш-линий и zero-copy.
• Построил основной пайплайн передачи на C++23 с UDP unicast и DPDK kernel bypass. Спроектировал компактный самодостаточный сетевой формат без потери информации, оптимизированный под ограничения ENA LLQ/Wide LLQ. Добавил адаптивное объединение событий с учётом MTU, балансируя задержку и пропускную способность, а также применил другие техники, позволившие выжать дополнительные доли микросекунд.
• Провёл контролируемые A/B-прогоны финального варианта и подготовил подробный отчёт с графиками распределений, точек насыщения и т. д.

Проектное разделение данных было родовой травмой 2ГИС. Пользователю были доступны сценарии только в рамках одного города, даже когда города находились рядом, как, например, Самара и Тольятти. Нельзя было построить маршрут из одного в другой, нельзя было искать результаты на границе и видеть их на общей карте. Для решения этой проблемы потребовалось полностью переосмыслить всю архитектуру не только приложения, но и потоков данных, питавших его. Нужно было переработать почти каждый модуль ядра, начиная от системы обновлений и заканчивая модулями карты, справочника и другими.

Я отвечал за доставку этой задачи не только в рамках нашей команды, но в рамках всего департамента. Декомпозировал работы, выявлял кросс-командные зависимости, составлял и актуализировал роадмап, проводил регулярные синки со смежными командами, прорабатывал архитектуру и лично участвовал в имплементации не одного сложного компонента.

Вторая родовая травма 2ГИС — офлайн-модель продукта, выросшего из CD-дисков для ПК. В 2020-х требовать после установки скачать сотни мегабайт, чтобы просто начать пользоваться приложением, было слишком большим барьером. Пользователи уходили на экране загрузки баз, и это мешало всерьёз вложиться в рекламу: заметная часть бюджета улетела бы в трубу ещё до знакомства людей с продуктом.

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

В середине разработки я понял, что выбранная схема взаимодействия с бэкендом не оправдывает ожиданий, и разработал новую, совместившую быстрое время ответа и консистентность данных, критичную для продукта и особенностей устройства ядра.

За несколько месяцев до срока стало очевидно, что текущими силами нам не справиться, поэтому эскалировал вопрос о привлечении дополнительных инженеров из смежных команд и в очередной раз с продакт-менеджером пересмотрел скоуп must-have задач первого релиза. Пересборка плана, ежедневная координация, понятные контрольные точки и последовательная стабилизация помогли довести задачу до выпуска.

Онлайн-режим вышел вовремя, снизив уровень оттока пользователей сразу после установки с 22,3% до 7,3%.

Новый 3D-движок Zenith разрабатывался около 7 лет и был призван принести в продукт фундаментальные изменения: бесшовную карту, онлайн-режим и гибкую стилизацию. При этом он использовал совершенно новый формат хранения данных, несовместимый с предыдущим, а также предоставлял другой API. Эти обстоятельства делали задачу его интеграции чрезвычайно сложной и не оставляющей обходных путей. Я взялся за неё и шаг за шагом проработал различные аспекты.

Для начала собрал прототип, позволивший прощупать весь путь от обращений к API движка через новые интерфейсы в ядре и до отрисовки кадров внутри Qt/QML-приложения.

Затем спроектировал механизм рантайм- и компайлтайм-флагов для изоляции новой интеграции. Это было важно, чтобы вести долгую разработку в основной ветке, но не влиять на боевой код до релиза.

Далее каждый потребитель движка нужно было либо продублировать, сделав интеграцию через новый API и используя его возможности по максимуму, либо временно переключить на адаптер ради скорости интеграции.

Отдельной задачей стал вопрос миграции. Мы не могли позволить пользователям со старыми данными одномоментно потерять возможность пользоваться приложением, поэтому я предложил механизм рантаймового выбора движка в зависимости от формата доступных данных с пересозданием всей сессии ядра в случае переключения между несовместимыми датасетами. Это позволило пользователям плавно перейти на новую версию без негативных эффектов.

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

Я предложил альтернативный подход с полной переработкой всей системы при сопоставимых усилиях. В центр решения поставил нашу компактную проприетарную read-only kv-базу, обеспечивающую высокую степень сжатия и быстрые выборки. Для удовлетворения EAV-модели данных со сложными критериями фильтрации добавил к ней hash-индексы, по одному на каждый уникальный фильтр в продукте.

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

Перед принятием решения о таком большом рефакторинге я доказал на дешёвых прототипах соответствие целевым метрикам по скорости работы и размеру данных, что позволило инвестировать в него без риска неопределённости успеха.

На заре своего развития CI в команде ядра 2ГИС был минимальным набором задач на Jenkins с постпроверками master-ветки, сконфигурированных разработчиками. Под моим началом он превратился в выделенное направление со своими целями, приоритетами и роадмапом, а инфраструктура приобрела очертания зрелого решения.

• Радикально уменьшил время сборок, внедрив кэши компиляторов и оптимизировав работу с Git.
• Расследовал и устранил проблему со спорадическими падениями MSBuild, с которой никто не мог разобраться.
• Подготовил туллинг и организовал процесс перехода к обязательным прогонам в PR с автоматизированным вливанием согласованных изменений в нескольких репозиториях.
• Настроил отчёты покрытия тестами.
• Стал идеологом перехода к подходу Infrastructure as Code в команде. Мигрировал Jenkins с Hyper-V виртуалки в OpenStack, описал конфигурацию в Heat Templates и Ansible, настроил ежедневные бэкапы через burp с LVM-снапшотов.
• Нанял помощника, которому постепенно передал направление.

Так как основным инструментом взаимодействия наших пользователей с кластером была TS-библиотека, мы решили перевести и наш CLI с Go на неё, чтобы не держать две реализации с периодически отличающимся поведением.

Go задавал высокую планку переносимости для исполняемого файла CLI, поэтому и новое решение мы хотели видеть одним статически слинкованным бинарём.

Это оказалось непростой задачей. Наша сборочная система была построена на Nix, и теоретически он позволял собрать пакеты из своего каталога статически. Но на практике всё оказалось не так радужно. Пришлось обойти множество ошибок сборки, последовательно добавляя патчи и флаги к конфигурации. Часть проблем оказалась специфической для macOS, например, с codesign в герметичном сборочном окружении Nix.

Следующие неприятности возникли при попытке запаковать наш CLI на oclif в SEA (Single Executable Application — экспериментальная возможность Node.js для однофайловой поставки). Пришлось фактически реализовать маленькую VFS, пропатчив require.

В статически собранном Node.js нельзя было пользоваться динамической загрузкой библиотек, поэтому пришлось переопределять некоторые зависимости на WASM-реализации вместо нативных.

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

Создал сервис карт желаний от идеи до работающего продукта с реальными пользователями и платежами.

Занимался проектом от и до: принимал продуктовые решения, проектировал архитектуру, разрабатывал, тестировал и эксплуатировал сервис в Google Cloud.

• Организовал разработку с AI-агентами по SDD: постановка задачи, подробная вычитка плана, реализация, ревью и доработка по результатам тестов. Около 95% кода сгенерировано AI. TDD и E2E-тесты на Playwright/pytest давали быструю обратную связь.
• Сделал автономное окружение разработки и тестирования: локальные реализации хранилищ и эмулятор успешных и неуспешных платежей. Приложение и E2E-тесты работают без интернета, включая полный сценарий покупки.