Илья Овсенев

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

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

Личный кабинет, админка, таблица с фильтрами и выгрузкой, форма со сложной логикой. К своему же сервису делаю и клиентскую часть — на React или Vue с TypeScript, с типами, сгенерированными из описания API, чтобы контракт между сервером и клиентом не расходился.

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

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

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

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

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

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

Нахожу, где именно теряется время и память, и переписываю это место — без переделки всей системы. Замеряю до и после на реальных объёмах, а не на тестовой базе: только так видно разницу.

Ключевая страница системы — большая выдача результатов подбора с фильтрами — на реальных объёмах занимала до 2 ГБ оперативной памяти. Это не абстрактная цифра из профайлера: страница ощутимо тормозила у пользователей, а сервер держал заметно меньше одновременных сеансов, чем должен был. Простое «добавить памяти на сервер» откладывало проблему, но не решало её — расход рос вместе с объёмом данных у клиента.

Разобрал, из чего складывается этот объём, и нашёл три источника. Первый — в выдачу попадали поля, которые интерфейсу не нужны вовсе; пересмотрел состав возвращаемых данных. Второй — одни и те же вложенные объекты дублировались в JSON десятки раз для каждой строки выдачи; перевёл формат ответа на ссылки вместо повторяющихся копий. Третий — запросы к базе тянули лишнее и делали это чаще, чем нужно; переписал их и убрал избыточные обращения к внешним системам в том же сценарии.

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

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

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

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

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

Внедрил кэширующий слой на Redis — до этого его в системе не было вообще. Разобрал, какие данные меняются редко, а какие в реальном времени, и покрыл кэшем справочники, пользователей и заявки. Инвалидация смешанная: справочные данные живут по сроку и протухают сами, оперативные — сбрасываются из кода в момент изменения сущности, чтобы пользователь не видел устаревшую заявку сразу после правки. Слой сделал общим для всех сервисов, чтобы при дальнейшем разделении монолита кэш не пришлось поднимать в каждом заново.

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

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

Разобрал, из чего складывается прогрев и что именно лежит в памяти. Пересобрал загрузку так, чтобы данные читались меньшим числом обращений, и пересмотрел состав того, что вообще держится в кэше.

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

Настройки жили внутри монолита. Монолит режется на сервисы по одному, и настройки — один из вынесенных кусков: им нужно было своё место, откуда остальные сервисы забирают их по общему контракту.

Спроектировал и написал сервис с нуля на .NET 8 и ASP.NET Core Web API: модель данных, контракты gRPC для остальных сервисов, валидация, загрузка документов, настройки печати отчётов. Связал его с сервисом личного кабинета — первым потребителем.

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

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

Перевёл четыре core-сервиса с Ninject на встроенный DI .NET, привёл загрузку конфигурации к единой модели, пересобрал структуру проектов и убрал лишние зависимости. Добавил эндпоинты проверки доступности, чтобы состояние сервиса было видно снаружи, а не только по логам.

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

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

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

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

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

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

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

Тесты блокируют сборку и развёртывание: если они падают, до сервера ничего не доезжает.