Девять лет в распределённых системах

Что я делал и что из этого вышло.

Здравствуйте! Я Владимир Савкин, системный архитектор и технический руководитель. Девять лет проектирую высоконагруженные распределённые системы: связь, страхование, авиаперевозки, промышленное производство.

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

Образование

Омский государственный технический университет. Магистр по направлению «Математическое обеспечение и администрирование информационных систем» (2017) и магистр факультета элитного образования по фундаментальной информатике (2019). Английский — B2 (продолжаю практиковать).

Работа

White-label платформа дистрибуции eSIM · 2025–2026

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

  • Отказался от развития старой системы в пользу новой архитектуры. Прежняя версия держала не больше трёх партнёров одновременно; новая рассчитана на миллионы профилей и выдерживает пиковые выгрузки провайдера без потери данных.
  • Пересобрал объём контракта на ядро и приращения: приёмка началась раньше готовности всего объёма. Дополнительные работы по безопасности и целостности данных уместились в исходный бюджет, потому что были заложены при проектировании.
  • Спроектировал и вёл шесть сервисов на .NET 8 плюс сервис обработки трафика на Go. Четыре из них написал в одиночку.
  • Конвейер тарификации: с ~100 до ~2 860 сообщений в секунду. Потолок в 5–7 млн профилей посчитан по реальному потоку, момент апгрейда определён заранее.
  • 302 формально доказанных утверждения о работе платформы в 16 моделях на SMT-решателе. 2943 автотеста на каждом изменении за четыре минуты — в прежней версии тестов не было.
  • Выкладка на прод: с 50 минут с простоями до 3–5 минут без простоя.
  • Выстроил процесс поставки с нуля, провёл найм тестировщика, вывел фронтенд-разработчика из замороженного проекта. После ухода технического директора вёл проект целиком.
Что именно закрыто на уровне архитектуры

Каскадное начисление: тарифы наследуются по иерархии и версионируются, балансы обновляются атомарно в целочисленных микроединицах, покрытие счетов — по очереди FIFO. Конвейер трафика работает по принципу «хотя бы раз»: пакет пишется одной транзакцией, списание выводится только из вставленных строк реестра — баланс и реестр не расходятся ни при каком повторе; испорченная запись не блокирует волну, падение пакета деградирует в поштучную обработку.

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

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

У ключевых сущностей явная машина состояний: какие статусы есть, какие переходы допустимы и почему. Система сама говорит, что с ней можно сделать; интерфейс правила не дублирует. Одно действие пользователя — одна прослеживаемая цепочка через все сервисы; аудит фиксирует инициатора, а не процесс.

Качество и процесс

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

Контракт API генерируется из кода на обеих ветках и сравнивается: ломающее изменение валит проверку, отчёт по релизу уходит в документацию, по нему тестировщик строит регресс. Сборка и тесты — на каждом изменении, входящие коммиты сканируются на секреты.

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

Раньше

Проекты для S7 Airlines и Ингосстраха · 2021–2024

  • Платформа закупок S7: авиакомпания публикует потребности, поставщики отвечают предложениями. MVP с нуля за полгода. Ответы китайских поставщиков приходили письмами и вносились вручную по полчаса каждое — стали разбираться автоматически.
  • Учёт трудозатрат S7 показывал данные двенадцатичасовой давности — стал показывать их сразу, без изменения устройства системы.
  • Ингосстрах: обнаружил, что пуш-уведомления в мобильном приложении не работали около года и никто об этом не знал. Восстановил, переписал, рассчитал под пиковые рассылки. Внедрил вход через Госуслуги.
  • Наставлял начинающих разработчиков на каждом проекте, проводил собеседования, замещал руководителя команды.
Подробнее
  • Платформа закупок. Мои сервисы: слой, приводящий предложения разных поставщиков к единой модели; справочники; почта; часть сервиса запросов. Парсер писем — с проверкой данных и уведомлением об ошибке.
  • Учёт трудозатрат. Коллектор собирал данные из Service Desk и JIRA, превращал их в бизнес-объекты через цепочку промежуточных таблиц, отдельный сервис показывал отчёты. Ввёл оркестратор заданий в коллекторе и перевёл всю цепочку в потоковый режим: коллектор публикует изменения, презентация пересчитывает проекции по событию. Фильтрация в отчётах — по проекциям вместо запросов по сырым данным.
  • Пуши Ингосстраха. Причины: пропущенный переход Apple на новый протокол и ошибки на Android. Переписал сервис на прямую работу с Apple и Google. От перехода на Firebase отговорил с обоснованием — позже санкции закрыли его для России, а прямая интеграция продолжила работать. По входу через Госуслуги вёл серверную часть и курировал мобильную: разбирал для команды последовательность шагов протокола.

Измерительное оборудование · 2019–2021

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

Проект для Газпром нефти · 2017–2019

  • Система планирования производства: оптимизировал математическую модель на симплекс-методе и внёс в неё ограничения, которые до этого обходились эвристиками.
  • Написал модуль работы с временными интервалами — ядро планирования: расписания, окна доступности оборудования.

Как работаю

Архитектура — это решения, которые дорого менять потом. Отсюда правила:

  • Каждое значимое решение записываю: контекст, варианты, выбор, последствия — включая негативные. Через год документ отвечает на вопрос «почему так» без моего участия.
  • Сначала модель, потом код. Перед чтением чужой системы моделирую, как она должна работать: какие операции есть, какая у каждой обратная, кто что теряет, если операция пойдёт не так. Потом читаю код и ищу расхождения.
  • Машина состояний — это спецификация. Читаю её как бизнес-требования: есть ли тупики, копятся ли сущности без пути назад, есть ли статус, который открывает всё.
  • Проверка описывается до прогона: ожидание пишется раньше факта, иначе факт подгоняется под ожидание. Один этап работы — один этап проверки, сразу.
  • Задачи режу на куски не длиннее рабочего дня. Так видно движение, и не копится незавершённое.
  • Риски приношу заказчику письменно, заранее и с вариантами решения — до того, как они станут срывом.

Инструменты

.NET 8 и C# как основной стек, Go — там, где нужен поток данных. PostgreSQL, ClickHouse, RabbitMQ, Docker, Kubernetes. Формальная верификация — Z3 и SMT-LIB.

Разработка с ИИ-агентом

На последнем проекте выстроил процесс, в котором агент пишет код в рамках принятой архитектуры. Для этого написал собственный набор из полутора десятков навыков: как заводить сущность, репозиторий, контроллер, доменное событие; как писать тесты; как проводить ревью по решениям проекта; какой паттерн выбирать и когда не выбирать никакой. Отдельный навык задаёт дисциплину длинной работы: план с состояниями и критериями завершения, проверка каждого этапа сразу, а не в конце. Результат агента проходит тесты и ручное ревью — он ускоряет написание, но не заменяет проверку.

Тем же способом написаны SMT-спецификации и код по ним. Спецификация и реализация шли из одного источника, совпадение проверялось тестами и вручную — поэтому они не разъехались за время разработки.

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

Открытый код

  • Web Holy Grail — мой флагманский продукт: фундамент для собственных сайтов на Next.js 15 и Payload CMS 3. Сайт растёт от визитки до портала внутри одного репозитория, без переезда на другой стек. Публичная документация с обоснованием выбора стека. Лицензия MIT. На нём работает и эта страница.
  • DotNetSolutionKit — шаблон солюшена микросервисной системы на .NET 8, лицензия MIT. Первый прогон разворачивает каркас, каждый следующий добавляет сервис. На нём построена платформа, о которой сказано выше: инфраструктуру развернули за сутки, дальше команда писала бизнес-логику.
Что DotNetSolutionKit закрывает на уровне каркаса

Доменные события не теряются при откате и не публикуются до фиксации — трёхфазный конвейер через перехватчики EF Core. Два сервиса не сядут на одну схему PostgreSQL — страж схемы забирает её при старте и падает при конфликте. Инициатор операции не теряется на границах — проходит сквозь HTTP, шину и фоновые задания. Двойная аутентификация для людей и машин. Сервис не поднимется с неверной конфигурацией. Интеграционные тесты идут на настоящем составе сервисов, а не на заглушках.

Открыт для сотрудничества

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