Радиф Илалтдинов

Действие Спроектировал архитектуру БД и бэкенда, реализовал серверную часть веба и приложений. Стек выбрал полностью асинхронный (FastAPI, SQLAlchemy 2.0 async, asyncpg), схему БД — под версионные миграции Alembic, чтобы структура менялась без простоя и без ручных правок на проде. Написал скрипты загрузки и миграции данных.

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

Действие Построил систему массовых и индивидуальных push-уведомлений на Socket.IO с Redis в роли брокера — realtime масштабируется горизонтально, несколькими процессами за балансировщиком, а не одним «толстым» воркером. Онлайн-сессии и присутствие держу в Redis, доступ — по JWT с асимметричной RSA-подписью (приватный ключ не покидает эмитента, остальные сервисы проверяют токен публичным). Добавил отложенные рассылки по расписаниям и событиям, с генерацией текста по шаблонам и учётом таймзон.

Действие Сделал оценку занятий (рейтинги и отзывы), хранение и показ истории действий студента в его профиле, а также инструменты отчётности, рейтингов и контроля для сотрудников управляющей компании, партнёров и школ.

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

Действие Покрытие тестами на старте отсутствовало — тестовую инфраструктуру на обоих проектах выстроил с нуля и встроил написание тестов в сам процесс: по скиллу тестовой дисциплины агент пишет тесты вместе с кодом задачи, а гейт покрытия нового кода в CI и в предкоммитной проверке не пропустит изменение, если новые и изменённые строки покрыты меньше чем на 90 %. Стек — pytest + pytest-asyncio на бэкенде и httpx для QA-прогонов по живому API, vitest на фронтенде и Playwright для сквозных сценариев в двух браузерных профилях, десктопном и мобильном: проходы по ролям, мобильные раскладки и smoke на вход и аналитику; прогон направляется на любой поднятый стенд через переменную окружения, UI-компоненты вынесены в Storybook. Взял на себя CI/CD в GitLab. У бэкенда и фронтенда свои независимые пайплайны: у бэкенда девять стадий и 22 джоба — сборка образов → линтеры → тесты → очистка раннера → выкладка на удалённые хосты через Docker-контексты → миграции → деплой → уборка → уведомление; у фронтенда восемь стадий и 20 джобов, без стадии миграций. Каждый пайплайн разведён на три контура — тестовый стенд и два прода, GRAFIKA и ArtTech, — поэтому стадий и джобов на проекте вдвое больше, чем в одном пайплайне. Свои пайплайны есть и у репозитория моделей и миграций, и у конфигурации балансировщика, и у Telegram-бота с его собственными тремя контурами (dev, stage, prod). Базы у брендов при этом раздельные и живут на своих серверах: общими остаются модели и схема, данные у каждого свои, а бэкенд бренда и его Telegram-бот работают с одной базой. Релизы перевёл на SemVer-теги от main, чтобы каждая версия на проде была однозначно сопоставима с коммитом.

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

Действие Разобрал инцидент: пайплайн был зелёным, но ручной джоб остался ненажатым — прод молча не обновился, а глазами это не поймали. Написал два гейта. Первый сверяет статусы всех джобов пайплайна по каждому контуру: статус «manual» означает «не нажат» и считается провалом, скрипт сразу печатает готовую команду запуска. Второй проверяет работоспособность стендов — шесть адресов, фронтенд и бэкенд каждого из трёх контуров. Предеплойный гейт собрал в одну команду: корневой preflight, flake8 и pytest на бэкенде, ESLint, Stylelint, сборка типов и vitest на фронтенде, по флагу — прогон Playwright по поднятому стенду. Сам порядок релиза зафиксировал runbook’ом: строго database → backend → frontend, теги создаются до деплоя, а после деплоя обязательны обе проверки плюс функциональный проход по интерфейсу — e2e-прогон Playwright направляется переменной окружения на уже задеплоенный контур, а не на локальную сборку, и прод проверяется на обоих брендах.

Действие Вынес конфигурацию nginx балансировщика в отдельный репозиторий и подключил его в моно-репо — 17 site-конфигов под версионным контролем. CI применяет их сам: бэкап текущих конфигов → копирование новых → nginx -t → и только при успешной валидации reload; провалилась проверка — перезагрузки нет. Там же починил проксирование WebSocket на всех контурах: Socket.IO работал локально, а на стендах отдавал 400, потому что в конфигах не было proxy_http_version 1.1 и заголовков Upgrade/Connection.

Действие Развернул инфраструктуру с нуля в Selectel в два этапа. Первые сутки — аварийный подъём: минимальный рабочий контур, на котором платформа обоих брендов снова заработала, и пользователи вернулись к приложению. Дальше, в пределах четырёх дней, — полноценная инфраструктура взамен потерянной, с бэкапами, мониторингом и runbook’ом. Сеть и серверы: пять серверов вместо прежних шести — балансировщик с SSH-бастионом, два прода (GRAFIKA и ArtTech), тестовый контур и GitLab, — разнесённых по зонам доступности, приватная сеть с отказоустойчивым облачным роутером, группы безопасности; прод-серверы и базы данных не имеют публичных адресов и доступны только из приватной сети через бастион, вход по SSH-ключам, пользователи и алиасы доступа заведены под каждую роль. Сервисы: все приложения в Docker-контейнерах, nginx на балансировщике со всеми доменами и TLS Let's Encrypt, восстановил прод из последнего уцелевшего дампа и сверил данные по контрольным счётчикам. GitLab: вместо управляемого — свой современный GitLab CE с Container Registry: перенёс семь репозиториев со всеми ветками и тегами, раннеры, CI-переменные по трём контурам, защищённые ветки без force-push. DNS, файлы, почта: перевёл зоны обоих брендов к регистратору, перенёс объектное хранилище — файлы приложения, архивы и сайты документации со сверкой по объёму, — переписал публичные ссылки; отдельную почтовую ВМ заменил SMTP-релеем с настроенными SPF, DKIM и DMARC. Observability: ELK-стек (Elasticsearch, Logstash, Kibana) прежний DevOps отключал ради экономии ресурсов, и ошибки на проде было негде смотреть — поднял экономный self-hosted GlitchTip (~330 МБ памяти): отдельные проекты на каждый бренд, окружения prod / art-prod / test, логи и ошибки бэкенда и фронтенда в одном интерфейсе. Бэкапы в три уровня: ночные снимки дисков всех пяти серверов; свои скрипты ежедневных дампов обоих продов и GitLab вместе с его секретами — с проверкой целостности архива и минимального размера, ротацией и алертом на почту — в объектное хранилище в другом регионе и параллельно ко второму провайдеру; отдельный сторож каждое утро проверяет свежесть копий в обоих хранилищах. Восстановление из внешней копии проверил на практике — база поднимается за десятки секунд. Весь порядок развёртывания с нуля, карту серверов и грабли переезда описал runbook’ом в репозитории.

Действие Перенёс подсистему аналитики с внешнего Node.js-дашборда на стороннем хостинге в свой FastAPI-бэкенд. Источников несколько, и они разной природы: Битрикс24 — лиды и сделки по REST с OAuth 2.0 и выборкой батчами; Яндекс.Директ — расход по кампаниям из асинхронных отчётов; VK Ads — расход и баланс агентских клиентов; ещё два канала (Rispromo, Flocktory) API не дают вовсе, поэтому их расход считается по числу лидов и стоимости лида для конкретной школы, а сами лиды опознаются по идентификатору источника и UTM-метке. На этом собраны юнит-экономика, план/факт, сводка для управляющей компании и UTM-дерево с бюджетами по кампаниям. Обновление данных построил по модели stale-while-revalidate: ответ формируется из своей базы сразу, фоновая догрузка стартует только если данные старше TTL, а её завершение уходит клиенту push-уведомлением по Socket.IO — вместо того чтобы держать интерфейс в ожидании и постоянно опрашивать чужие API. Частоту обращений держит распределённый rate-limiter в Redis: не чаще одного запроса в 2 секунды на портал целиком, общая пауза для всех процессов при перегрузке; выборка идёт батчами до 50 команд в одном HTTP-запросе, а длинный первичный проход по истории сделал возобновляемым по курсору. OAuth-токены хранятся зашифрованными (Fernet).

Действие Разобрался в чужих сервисах с нуля и собрал связки заново — через Albato и роботов Битрикс24. Лиды из квизов Marquiz, форм Tilda, RIS.Promo, ВКонтакте и eLama попадают в CRM и проходят многостадийную обработку на роботах; в момент перехода сделки в «продано» хук уходит через Albato в GetCourse и запускает написанные мной бизнес-процессы: пользователь создаётся автоматически, попадает в группы по указанному в сделке абонементу и получает регистрационное письмо. Отдельной задачей довёл заявки из CRM до Яндекс.Метрики как офлайн-конверсии: Marquiz и Tilda → Albato → Битрикс24 → коннектор B242YA → Метрика. Всего прошёл 88 связок с маппингом под каждый источник — из них 49 под офлайн-конверсии Marquiz и Tilda, остальные по ВКонтакте, eLama, RIS.Promo и GetCourse, — и настроил сам коннектор на стороне Битрикс24. Где стандартных инструментов конструктора не хватало, внедрял в Tilda свой код — точечная автоматизация под задачи, которые иначе не собрать.

Действие Научил детальные эндпоинты аналитики отвечать за соседний контур: по параметру бренда запрос проксируется во второй контур внутренним маршрутом с сервисным токеном, право на это есть только у двух ролей. На фронтенде — экраны с бейджем бренда и человекочитаемыми сообщениями вместо кодов 404, 403 и 502.

Действие Оставил один бэкенд и один фронтенд-бандл на обе сети: бренд определяется доменом и флагом сборки, а различия в логике, правах и оформлении вынесены в конфигурацию, а не в форк. Фронтенд организовал по Feature-Sliced Design (слои app / pages / widgets / features / entities / shared) — границы между доменами явные, и правка одного модуля не тянет за собой соседние.

Действие Внедрил собственный процесс ИИ-ассистированной разработки: единый свод правил для всех агентов (один источник истины плюс 11 скиллов-дисциплин — git, тесты, асинхронный код, отладка, документация, подготовка и ревью MR, релизы, автоматизация), доску со спринтами, этапами и задачами, Definition of Ready и Done, ритуал коммитов, обязательные тесты и линтеры до коммита, синхронную документацию. Моно-репо с оркестратором сам маршрутизирует запрос в нужный проект и задаёт агенту порядок чтения документов. Механику вынес в скрипты-гейты: синхронность доски с файлами спринтов, валидность ссылок в документации, перевод статусов задач — одной командой; весь ритуал проверок до коммита прогоняет единый preflight. Вторым контуром завёл журналы вне-спринтовых правок (maintenance) — придумал их под то, что не стоит открытия спринта: хотфикс на проде, правка CI, конфига или документации. Такая задача идёт коротким путём — коммит прямо в ветку разработки, без feature-ветки и без ожидания конца итерации, — но обязательно с записью в журнал: дата, тип (hotfix / chore / docs), затронутые файлы, пройденные гейты и первопричина. Журналов три: корневой на общие файлы моно-репо и по одному на бэкенд и фронтенд; правка, относящаяся к задаче спринта, уходит в файл спринта, а не в журнал, — граница зафиксирована в правилах. Сокращается только процедура, а не контроль: preflight, линтеры и тесты обязательны и здесь. Любой агент (Cursor, Windsurf, Devin, Claude Code, GitHub Copilot, JetBrains AI) читает одни и те же документы и пишет код единообразно. В ежедневной работе совмещаю несколько ассистентов и под задачу выбираю подходящий. Архитектуру, ревью и финальные решения держу за собой — агенты ускоряют рутину, а не заменяют инженера.

Действие Развёл работу на два контура. Плановый: спринт, feature-ветка, MR, релизный тег. Срочный: правка вне спринта — запись в журнал, коммит в ветку разработки и, если ждать полный цикл дороже, чем чинить, «быстрый деплой прода» в обход тестового стенда. Что при этом не сокращается: предеплойный гейт, линтеры, тесты, тест, воспроизводящий сам баг, и обе постдеплойные проверки — сверка джобов и работоспособность стендов. Уровни доступа описал таблицей в правилах: какая формулировка задачи разрешает агенту push, merge, тег и запуск ручных джобов, а какая оставляет это за мной.

Действие Исправил баги, отрефакторил код под PEP-8 и GitFlow, добавил аннотации типов, документацию и Docstrings, ввёл Code Review и трекинг задач в Yandex Tracker, перевёл данные с SQLite на PostgreSQL.

Действие Разделил frontend и backend (Django REST framework и Vue.js), перевёл систему на микросервисную архитектуру, добавил логирование сервисов с веб-интерфейсом, брокеры сообщений (MQTT, RabbitMQ) и Docker Compose.

Действие Собрал локальную среду разработки (любой разработчик запускает backend, frontend, монолиты и микросервисы вендинга, магазина, админки и ЛК у себя на ПК) и удалённую предпродакшн-среду на отдельной системе.

Действие Программировал сами аппараты на одноплатных ПК (Repka Pi, Orange Pi): управление контроллером по Modbus TCP, платёжный терминал Vendista по serial-порту, манипулятор соусов — напрямую через GPIO и I²C, интерфейс киоска в Chromium и Firefox Kiosk с автозапуском через systemd. Живое состояние заказа гоняю в интерфейс по WebSocket (Django Channels + Redis), обмен с облаком — через MQTT-брокер и RabbitMQ. Подключил онлайн-оплату и фискальные чеки, мультиязычность каталога, автогенерацию OpenAPI. Отдельным микросервисом сделал контроль связи с аппаратами: если аппарат перестал отвечать — алерт уходит в Telegram. Доступ к аппаратам и БД закрыл VPN (L2TP/IPsec).

Действие Большую часть проверок реализовал прямо в Zabbix. Для остальных — там, где нужна сложная авторизация (в том числе по сертификату) или разбор нетривиальных структур ответа — написал промежуточные сервисы на Django REST framework и отдал их в Zabbix как обычные метрики. Среди источников — реестры Росфинмониторинга (перечень ФРОМУ, список МВК, перечень террористов и экстремистов) и сервисы проверки данных по базам МВД. Проверки идут по расписанию Celery, асинхронно и параллельно (AsyncIO, httpx, aiohttp), состояние сервисов держится в Redis. Токены доступа сервис перевыпускает сам — за час до истечения, а не после отказа. Статус трёхуровневый: UP / PREFAIL / DOWN, где PREFAIL — предупреждение «источник ещё работает, но квота или баланс подходят к концу». Запуск и логи любой проверки вывел кнопками в админку. Линтер поставил гейтом на деплой: не прошёл flake8 — контейнер не поднимается.

Действие Реализовал сервис асинхронной перезагрузки шлюзов: десятки устройств перезагружаются параллельно (AsyncIO с uvloop, асинхронный HTTP-клиент, точка входа на FastAPI), а не по очереди. Сделал приложение распределения звонков с контролем состояний и переключением сим-карт (десятки шлюзов, сотни SIM-карт), включая автоматическую привязку SIM к слотам. Написал Selenium-парсеры личных кабинетов бизнес-аккаунтов операторов (каждый — в своём изолированном контейнере с браузером), парсеры статусов портов шлюзов с отправкой в RabbitMQ и парсер маршрутизатора сим-карт. Запуск по расписанию организовал через Celery — десяток регулярных задач.

Действие Провёл research чужого проекта на PHP, переработал и оптимизировал его взаимодействие с нашим сервисом на Python.

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

Действие Делал дизайн-вёрстку (Pixel Perfect по макетам и без), фронтенд на JS, бэкенд на Python и PHP. Здесь же работал с PHP, Composer и Yii2-Advanced. Деплоил вручную на чистый Linux VPS без виртуального хостинга, поднимал контейнеры Docker Compose с общей сетью, получал сертификаты Let's Encrypt и подключал HTTPS через Nginx.