Что я делал и что из этого вышло.Что я делал, что из этого вышло и как я работаю.
Здравствуйте! Я Владимир Савкин, системный архитектор и технический руководитель. Девять лет проектирую высоконагруженные распределённые системы: связь, страхование, авиаперевозки, промышленное производство.
По образованию математик-программист. Там, где считаются деньги, цена ошибки измеряется в миллионах, поэтому я не полагаюсь только на тесты: правила обращения с деньгами доказываю формально, ещё на этапе проектирования.
Омский государственный технический университет. Магистр по направлению «Математическое обеспечение и администрирование информационных систем» (2017) и магистр факультета элитного образования по фундаментальной информатике (2019). Английский — B2 (продолжаю практиковать).
Пришёл старшим разработчиком, через три месяца стал системным архитектором и техническим руководителем. SaaS-агрегатор eSIM: платформа подключает провайдеров связи, забирает их тарифы и поток трафика, а партнёры перепродают eSIM под своим брендом. Наценка каскадно начисляется по иерархии в четыре уровня поверх тарифа провайдера, трафик тарифицируется почти в реальном времени. Деньги считаются на каждом уровне, и ошибка в копейку разрастается по всей цепочке.
Каскадное начисление: тарифы наследуются по иерархии и версионируются, балансы обновляются атомарно в целочисленных микроединицах, покрытие счетов — по очереди FIFO. Конвейер трафика работает по принципу «хотя бы раз»: пакет пишется одной транзакцией, списание выводится только из вставленных строк реестра — баланс и реестр не расходятся ни при каком повторе; испорченная запись не блокирует волну, падение пакета деградирует в поштучную обработку.
Кредитный лимит, которого раньше не было: прогноз исчерпания и блокировка на нулевом остатке. Без него перерасход между обнулением баланса и остановкой трафика оплачивала бы платформа.
Классы ошибок, которые не могут возникнуть по построению: расхождения балансов, гонки при одновременных операциях в иерархии, утечки данных между ветками партнёров, дубли счетов, порча подписанных документов. Права не зашиваются в токен, а вычисляются на каждом запросе — отзыв действует немедленно.
У ключевых сущностей явная машина состояний: какие статусы есть, какие переходы допустимы и почему. Система сама говорит, что с ней можно сделать; интерфейс правила не дублирует. Одно действие пользователя — одна прослеживаемая цепочка через все сервисы; аудит фиксирует инициатора, а не процесс.
Двенадцать архитектурных решений записаны с контекстом, отброшенными вариантами и ценой, включая негативные последствия. Формальные модели покрывают каскадные тарифы, покрытие счетов, неизменяемость снимка счёта, кредитный мониторинг, видимость профилей по ролям; код и тесты писались один к одному по спецификациям.
Контракт API генерируется из кода на обеих ветках и сравнивается: ломающее изменение валит проверку, отчёт по релизу уходит в документацию, по нему тестировщик строит регресс. Сборка и тесты — на каждом изменении, входящие коммиты сканируются на секреты.
Спринты с явной ёмкостью, задачи не длиннее рабочего дня, ревью архитектуры до кода. Риски приносил владельцам письменно, заранее и с вариантами решения; ввёл таксономию дефектов с явной границей между гарантийным исправлением и новыми требованиями.
Архитектура — это решения, которые дорого менять потом. Отсюда правила:
.NET 8 и C# как основной стек, Go — там, где нужен поток данных. PostgreSQL, ClickHouse, RabbitMQ, Docker, Kubernetes. Формальная верификация — Z3 и SMT-LIB.
На последнем проекте выстроил процесс, в котором агент пишет код в рамках принятой архитектуры. Для этого написал собственный набор из полутора десятков навыков: как заводить сущность, репозиторий, контроллер, доменное событие; как писать тесты; как проводить ревью по решениям проекта; какой паттерн выбирать и когда не выбирать никакой. Отдельный навык задаёт дисциплину длинной работы: план с состояниями и критериями завершения, проверка каждого этапа сразу, а не в конце. Результат агента проходит тесты и ручное ревью — он ускоряет написание, но не заменяет проверку.
Тем же способом написаны SMT-спецификации и код по ним. Спецификация и реализация шли из одного источника, совпадение проверялось тестами и вручную — поэтому они не разъехались за время разработки.
Дообучение моделей и оркестрация процессов — отдельный интерес, в рабочих задачах применяю по мере необходимости.
Доменные события не теряются при откате и не публикуются до фиксации — трёхфазный конвейер через перехватчики EF Core. Два сервиса не сядут на одну схему PostgreSQL — страж схемы забирает её при старте и падает при конфликте. Инициатор операции не теряется на границах — проходит сквозь HTTP, шину и фоновые задания. Двойная аутентификация для людей и машин. Сервис не поднимется с неверной конфигурацией. Интеграционные тесты идут на настоящем составе сервисов, а не на заглушках.
Архитектура, техническое руководство, сложные предметные области. Напишите о задаче и я вам обязательно отвечу.