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

Сейчас работаю в Wildberries & Russ как системный архитектор в направлении платформенной занятости. Курирую финансовый контур: списания, штрафы, оспаривания, контроль потерь.

Параллельно развиваю практики архитектурного надзора, системной аналитики и бизнес-аналитики. Фокусируюсь на автоматизации этих процессов и внедрении AI-инструментов в работу команд.

До этого - IPONWEB (позже приобретена Criteo), где прошел путь от Perl/Lua разработчика до системного архитектора Commerce Grid.

За эти годы выработал простой алгоритм - три вопроса перед любой задачей:

• Цель: что я хочу получить?
• Реальность: что я знаю и не знаю?
• Действие: что я сделаю прямо сейчас?

Опыт

WBJob - Архитектура - Wildberries & Russ

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

Главный челлендж: встроить три этапа (бизнес-аналитика, системная аналитика, архитектурный надзор) в процесс разработки, не увеличив time-to-market.

Внутренний контроль и аудит - логистика ШК - Wildberries & Russ

Накопленная стоимость ШК:

Архитектурное сопровождение системы расчёта накопленной стоимости обслуживания единицы товара (ШК) через всю логистическую цепочку Wildberries: приёмка на воротах -> склад -> транспортная логистика -> ПВЗ. Каждый большой этап состоит из множества процессов, каждый добавляет стоимость операции. Понимание этой картины даёт базу для оптимизации - от отдельной операции до крупных процессов (сортировка, приёмка, последняя миля).

Тарификация складских операций:

Архитектурное сопровождение системы тарификации. Специфика: все операции (склад + транспорт) тарифицируются и оплачиваются - почасовые, за операцию, разные схемы выработки. Огромное количество правил, нюансов и legacy. Главный constraint: склад должен работать всегда, простой неприемлем.

HRTech - цифровая трансформация - Wildberries

Присоединился к Wildberries как системный архитектор и выстроил HR Tech как управляемую инженерную систему: практика системной аналитики, архитектура как код, прозрачные интеграции и качество поставки - вместо “договорились словами и поехали”.

Что сделал как организационно-архитектурную базу:

• Построил с нуля отдел системной аналитики: собрал команду, выстроил практику и встроил системную аналитику в процесс разработки (проработка требований, контракты, согласование интеграций, критерии приёмки).
• Внедрил подход “Architecture as Code”: описали сервисы и их ответственность, зафиксировали ключевые решения через ADR, собрали карту сервисов и зависимостей как поддерживаемый артефакт, а не “знание в головах”.
• Навёл порядок в интеграциях: консолидировал хаотичные “словесные” интеграции и ручную выдачу токенов в формализованный подход - с единым интеграционным сервисом, правилами, автоматизацией и трассируемостью.
• Внедрил культуру тестирования: запустил практику тестов там, где их не было, встроил проверки в CI/CD pipeline, повысил предсказуемость релизов и качество изменений.
• Доводил крупные инициативы до результата: брал большие изменения, драйвил их сквозь команды и зависимых стейкхолдеров, закрывал “хвосты”, а не оставлял как вечные концепты.

Ключевые продуктовые контуры:

• HR Platform (HRPortal) - единый источник истины по сотрудникам (склад + офис/IT).
• ATS (Applicant Tracking System) - рекрутинг и онбординг, снижение зависимости от внешнего провайдера (HeadFlow).
• Team Management (WBTeam) - управление командами: заявки на вакансии, уведомления, согласования.
• Compensation & Benefits (C&B) - автоматизация расчётов, тарификация и контроль финансовых рисков.

Commerce Grid - архитектура платформы - Criteo

После того как IPONWEB была приобретена Criteo, я присоединился как системный архитектор для работы над Commerce Grid - платформой retail media.

Ключевые достижения:

• Создал начальную архитектурную модель C-Grid и внедрил практики совместной работы над архитектурой
• Руководил миграцией на Kubernetes для критических сервисов с минимальным даунтаймом
• Построил среду интеграционного тестирования на базе Docker для локальной разработки и CI
• Внедрил service mesh, мониторинг и observability решения
• Установил процессы архитектурного ревью и кросс-командного взаимодействия

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

DevOps & SRE - погружение в мир operations - Criteo

Работая разработчиком, часто слышал от девопсов: “это долго делать”. Стало интересно - что ж там долго? Погрузился в DevOps на полтора года, полностью занимался инфраструктурными задачами. Потом от SRE услышал то же самое - “сложно, долго”. Ушёл в SRE ещё на год.

Разобрался как это всё работает изнутри: Google Cloud, AWS, Terraform, CI/CD pipelines. Теперь понимаю обе стороны - и разработку, и operations.

BidCast - разработка Load Balancer - IPONWEB

Один из самых сложных проектов. Две задачи: разнести монолит BidSwitch и проверить гипотезу - можем ли написать свой load balancer дешевле Google/AWS.

Первая версия показала: наш load balancer дешевле в обслуживании. Дальше начали переносить логику из BidSwitch в BidCast - всё, что не связано со стейтом и базой данных, разгружая тяжёлый код.

Главное достижение - модуль AdTXT: разработал свой формат хранения данных, который позволял загружать 5-6 ГБ в память процесса за ~1 секунду и осуществлять поиск за 10 наносекунд. Это позволило вытащить функционал из BidSwitch и сэкономить десятки тысяч долларов в месяц. При этом BidCast по производительности даже не заметил новый модуль.

BidSwitch - декомпозиция монолита на микросервисы - IPONWEB

Микросервисы тогда были на пике популярности. Руководил разбиением монолита BidSwitch на микросервисы - создали около 7 сервисов за API Gateway.

Чем закончилось: закрыли инициативу. Поддержка микросервисов оказалась дороже монолита - нужно растить команды, больше людей. С монолитом одна команда пилит фичи, пусть медленнее, но стабильно.

Что получил: много практик, набитые шишки, глубокое понимание трейдоффов. Главный бенефит микросервисов - возможность полностью переписать сервис за 1-2 недели. С монолитом такое не прокатывает.

uWorkflow - Django монолит - IPONWEB

Django-монолит, спроектированный как конструктор LEGO - очень много маленьких компонентов. Система конфигурировала себя на лету по заданной схеме. Configuration driven development: управление объектами и связями через OpenAPI-совместимые схемы. Схема была сердцем системы.

Результат:

• Ускорили доставку проектов
• Весь код в одном репозитории
• Маленькая команда поддерживала много проектов

Стали экспертами в Python, Django и DRF.

YouZoo - соцсеть для питомцев - 2 года в ЮВА

Два года путешествий по Мьянме, Таиланду, Лаосу, Вьетнаму, Камбодже, Малайзии, Индонезии, Филиппинам, Непалу, Индии и Шри-Ланке.

В это время фокусировался на глубоком самообучении:

• Выучил Python и создал соцсеть для владельцев питомцев
• Изучил PostgreSQL - моделирование и запросы к структурированным данным
• Полностью перешёл на Emacs, выстроил свои продуктивные workflows
• Научился слепой печати на английском - чтобы кодить и писать быстрее
• Развил ясность мышления, фокус и способность учиться самостоятельно - навыки, на которые опираюсь каждый день в архитектуре и инженерии

Это путешествие сформировало не только как я живу, но и как я думаю.

Рассылки - email marketing - Mail.Ru

30-40 миллионов персонализированных писем в день. Две главные задачи: Mail sender и Targeting machine.

Mail sender на Perl с event loop. Время хардкора: демоны, межпроцессное взаимодействие, сокеты, синхронизация.

Targeting machine - первый опыт с AdTech. Персонализированный таргетинг для каждого письма. Разработал структуру данных с кастомной хэш-функцией: проверка всех вариантов за O(1). AdCache был огромным, но работал супер быстро.

На этом проекте изучил TDD - с тех пор пишу тесты для всего кода.

Миссия

Помогать компаниям превращать сложные системы в управляемую архитектуру с понятными границами, надёжными интеграциями и предсказуемой эволюцией.

Это не про красивые диаграммы или модные фреймворки. Это про то, чтобы:

• Разработчики понимали, где заканчивается их зона ответственности
• Изменения в одном сервисе не ломали десять других
• Новые люди в команде могли разобраться в системе за дни, а не месяцы
• Бизнес мог планировать развитие, зная реальную стоимость изменений

Сложность неизбежна. Хаос - нет.

Ценности

Явные границы ответственности

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

Контракты вместо устных договорённостей

Если интеграция не описана формально, её не существует. API контракты, схемы данных, SLA - всё должно быть зафиксировано. “Мы так договорились на созвоне” - не контракт.

Измеримость результата

Если нельзя измерить, нельзя улучшить. Метрики архитектуры, покрытие тестами, время отклика, coupling между модулями - всё должно быть числом, а не ощущением.

Надёжность по умолчанию

Система должна работать предсказуемо, а не “обычно работает”. Graceful degradation, retry policies, circuit breakers - не опции, а базовые требования.

Простота и эволюционность

Сложность растёт только когда это действительно необходимо. Каждая абстракция должна оправдать своё существование. Три похожие строки кода лучше преждевременной абстракции.

Философия

70/30 подход

Консервативно-риск-ориентированный баланс. 70% решений - проверенные, надёжные подходы. 30% - контролируемые эксперименты с новыми технологиями и методами.

Работаю только с управляемыми рисками. Это значит:

• Чёткие критерии успеха и провала
• План отката до начала изменений
• Изоляция экспериментов от критичных путей

Контекст важнее шаблонов

Хорошая архитектура начинается с понимания контекста, а не с применения готовых решений. Каждая система уникальна и требует своего подхода.

“Best practices” - это чужой опыт в чужом контексте. Полезно знать, опасно копировать слепо.

Явные границы ответственности

Не только в коде, но и в процессах. Кто принимает решение? Кто несёт ответственность за последствия? Кто имеет право вето?

Размытые границы - источник конфликтов и паралича принятия решений.

Места, где я был

Вспомнить все места, где я побывал - очень сложная задача, и только моя жена способна помочь мне с этим. Спасибо дорогая, я люблю тебя!