Резюме — Илья Овсенев, .NET / React

Илья Овсенев

Fullstack-разработчик: .NET на бэкенде, React и Vue на фронте

Удалённо — по всей России. Гибрид или офис — Санкт-Петербург. Полная занятость и проектная работа.

Более 3 лет

в коммерческой разработке

.NET · React · Vue

бэкенд и фронтенд в одних руках

4× меньше

памяти после оптимизации ключевой страницы

2 платформы

собственные проекты, целиком от базы до экрана

Коротко обо мне

В разработку я пришёл из строительства: с 2014 по 2025 год прошёл путь от мастера строительных работ до проектировщика. Отсюда привычка сначала выяснить, зачем задача нужна заказчику, и только потом обсуждать, как её делать.

На объектах — сроки, подрядчики, приёмка и ответственность за то, что переделать в следующем спринте не получится. Последние два года совмещал стройку с коммерческой разработкой, с июля 2025 года занимаюсь только ей.

Оттуда же вторая привычка, которая в разработке оказалась полезнее любого фреймворка: доводить работу до сдачи, а не до «у меня локально работает».

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

Опыт работы

Июль 2025 — настоящее время

Инженер-программист

Нагруженная корпоративная система с многолетней историей кодовой базы и распределённой командой разработки. База данных крупнейшего клиента — десятки гигабайт, кэши службы поиска занимают порядка 20 ГБ оперативной памяти.

Снизил потребление памяти ключевой страницы с 2 ГБ до 500 МБ; соседнюю страницу, которая на больших объёмах не открывалась вовсе, вернул в строй — 22 МБ передаваемых данных.
Переписал запрос выгрузки за период: с 3 минут и падения по таймауту до стабильных 30–40 секунд на полном объёме данных.
Ускорил загрузку кэшей службы поиска на 40 % и снизил их потребление памяти на 20 %.
Участвую в дроблении монолита: сервисы выносятся из него по одному, на .NET 8. Сервис централизованных настроек спроектировал и написал с нуля — контракты gRPC, валидация, загрузка документов, настройки печати отчётов.
Рефакторю проекты: пересобираю структуру, убираю лишние зависимости. Перевёл четыре core-сервиса с Ninject на встроенный DI .NET, привёл конфигурацию к единой модели загрузки, добавил health checks.
Внедрил сквозную наблюдаемость: общая библиотека телеметрии на OpenTelemetry для всех core-сервисов, экспорт в Prometheus, Loki, Jaeger, дашборды в Grafana.
Поддерживаю и модернизирую унаследованный контур: перевод с .NET Framework на .NET 8, доработка OWIN middleware аутентификации за балансировщиком нагрузки.
Разрабатываю клиентскую часть одного из модулей на Vue.js. Требования собираю напрямую у заказчика внутри компании, без аналитика-посредника.

C#, .NET 8, .NET Framework, ASP.NET Core Web API, gRPC, EF6, ADO.NET, MS SQL Server, OpenTelemetry, Serilog, Prometheus, Grafana, Loki, Jaeger, Docker, Vue.js

Декабрь 2023 — июнь 2025

Backend-разработчик (.NET) · проектная работа

Внутренняя система строительной компании: сквозной учёт заявок от объектов строительства через производственно-технический отдел до снабжения. 20–30 пользователей, команда разработки 3–4 человека. Система развивалась от монолита к набору микросервисов.

Внедрил Redis-кэширование с нуля — до этого все обращения шли напрямую в базу; убрал прямые обращения к PostgreSQL на всех 30+ эндпоинтах.
Участвовал в декомпозиции монолита на микросервисы: выделение сервисов, межсервисное взаимодействие, общий кэш.
Разработал REST API внутренних сервисов — 30+ эндпоинтов, CQRS как основной паттерн работы с запросами.
Разрабатывал и поддерживал вынесенный из монолита сервер аутентификации на IdentityServer4: JWT, OAuth 2.0, единая точка входа для всех сервисов.
Подключил RabbitMQ для асинхронных уведомлений; реализовал систему уведомлений и внутренний чат на SignalR.
Настраивал Docker, Nginx и Linux-серверы, CI/CD; писал unit- и интеграционные тесты на xUnit и Moq.

C#, .NET 6–8, ASP.NET Core, EF Core, PostgreSQL, Redis, RabbitMQ, IdentityServer4, SignalR, Docker, Nginx, Linux, React, Next.js

Сентябрь 2023 — ноябрь 2023

Младший специалист по разработке ПО · проектная работа

Та же система, начало работы в ней.

C#, ASP.NET Core, EF Core, PostgreSQL, Redis

Стек

Языки и платформа

C#
.NET 8–10
.NET Framework
TypeScript
SQL

Backend

ASP.NET Core
Web API
REST
gRPC
SignalR
EF Core
EF6
ADO.NET
LINQ

Базы, кэш, очереди

PostgreSQL
MS SQL Server
оптимизация запросов
большие объёмы
Redis
RabbitMQ

Наблюдаемость

OpenTelemetry
Prometheus
Grafana
Loki
Jaeger
Serilog

Инфраструктура

Docker
Nginx
Linux
CI/CD
GitHub Actions
Gitea Actions

Архитектура и тесты

микросервисы
модульный монолит
CQRS
SOLID
Clean Architecture
xUnit
Moq

Frontend

React
Next.js
Vue.js
TypeScript
Vite
Mantine
TanStack Query

Решённые задачи

2 ГБ → 500 МБ

памяти на том же объёме данных

Память страницы — вчетверо меньше

Нагруженная корпоративная система с многолетней историей кодовой базы и распределённой командой разработки.

2 ГБ → 500 МБ — вчетверо меньше памяти на том же объёме данных. Соседняя страница того же контура, которая при больших объёмах просто не открывалась, после такой же переработки выдачи заработала стабильно: 22 МБ передаваемых данных вместо отказа. Контракт сервиса при этом не менялся: те же адреса, те же объекты в ответе — изменился способ их сериализации и ушли поля, которые интерфейс всё равно не запрашивал. Переписывать клиентскую часть не пришлось.

3 мин → 30 сек

вместо падения по таймауту

Выгрузка вместо таймаута

Та же система; отчётная выгрузка данных за произвольный период.

3 минуты с падением по таймауту → стабильные 30–40 секунд на полном объёме данных. Выгрузка за период стала рабочей функцией, а не тем, что делают вручную по кускам. Контракт не тронут вообще: переписан один запрос за тем же эндпоинтом, снаружи это та же выгрузка с теми же параметрами — на стороне клиента менять было нечего.

От 50 % быстрее

средний запрос; где ответ шёл из кэша целиком — 300 → 40 мс

База перестала быть узким местом

Внутренняя система строительной компании — сквозной учёт заявок от объекта строительства через производственно-технический отдел до снабжения.

Отклик сократился минимум наполовину: средний запрос шёл 150–300 мс, стал 100–150, а там, где ответ отдавался из кэша целиком, — 40 мс вместо 300. Прямые обращения к PostgreSQL убраны на всех 30+ эндпоинтах, нагрузка на базу перестала расти линейно вместе с числом пользователей и объектов. Redis остался в архитектуре и после декомпозиции монолита — как общий кэш для выделенных сервисов.

40 % / −20 %

быстрее загрузка кэшей, меньше памяти под них

Кэши поиска — быстрее и легче

Та же нагруженная корпоративная система; служба поиска, кэши которой занимают порядка 20 ГБ оперативной памяти.

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

С нуля

проектирование, контракты gRPC, выкатка

Настройки вынесены в отдельный сервис

Та же система; сервис централизованных настроек.

Настройки контура живут в одном месте и раздаются по gRPC. Сервис делался не «до первого запуска»: с описанными контрактами, проверкой доступности и телеметрией с самого начала, чтобы его можно было передать другому разработчику.

4 сервиса

переведены на встроенный DI и единую конфигурацию

Порядок в унаследованных сервисах

Та же система; сервисы настроек, личного кабинета, платежей и почтовых рассылок.

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

Собственные разработки

Микросервисная платформа сбора данных

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

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

.NET 10, gRPC, EF Core 10, PostgreSQL, Polly, OpenTelemetry, Serilog, Loki, xUnit, Moq, GitHub Actions. Фронтенд — Next.js, React, TypeScript.

Платформа заявок с настраиваемым доступом

Helpdesk-система для B2B: заявки, задачи, комментарии, вложения, полная история изменений.

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

.NET 10, EF Core 10, PostgreSQL, JWT на RSA, OpenAPI, OpenTelemetry, Docker Compose, Gitea Actions (поднят самостоятельно). Фронтенд — React, TypeScript, Vite, Mantine, TanStack Query.

Как со мной связаться

Пишите в Telegram — отвечаю быстрее всего. Если удобнее почта, адрес рядом.

Расскажите в двух словах, что за задача, — отвечу, берусь ли и сколько это примерно займёт.