ООО «Творческое Образование» — Старший разработчик, системный аналитик
Август 2024 — настоящее времяКраснодар, удалённо. Федеральные сети онлайн и офлайн школ. Главный разработчик на проектах. grafika-art-school.ru/franchise (GRAFIKA) и arttech-school.ru/franchise (ArtTech)
Рост внутри компании
- 2024 — пришёл бэкенд-разработчиком: архитектура БД и серверная часть платформы, которую делали с нуля.
- 2025 — повышен до старшего разработчика и закрыл выпавшую роль системного аналитика. С этого момента совмещаю две штатные должности — старший разработчик и системный аналитик, каждая со своей зарплатой.
- 2026 — зона ответственности расширена на backend, frontend, DevOps, QA, архитектуру и системную аналитику, включая поддержку проектов смежных отделов на других языках.
Платформу для студентов, преподавателей, менеджеров, руководителей и партнёров делаем с нуля: веб-версия, приложения для Android и iPhone, Telegram-бот. По сути это CRM/ERP сети школ: расписания и залы, абонементы и финансы, роли и права, отчётность — девять ролей пользователей со своими правами и интерфейсами. В команде backend- и frontend-разработчики, DevOps, системные аналитики, PM и QA. Я проектирую архитектуру БД и бэкенда, пишу серверную часть, помогаю аналитикам с ТЗ, а фронтендерам с отладкой и оптимизацией запросов.
Цель Запустить платформу для федеральной сети школ и довести её до продакшна.
Действие Спроектировал архитектуру БД и бэкенда, реализовал серверную часть веба и приложений. Стек выбрал полностью асинхронный (FastAPI, SQLAlchemy 2.0 async, asyncpg), схему БД — под версионные миграции Alembic, чтобы структура менялась без простоя и без ручных правок на проде. Написал скрипты загрузки и миграции данных.
Результат Вывели продукт в продакшн. Через мои скрипты в систему заведено около 5 000 студентов, которые активно пользуются приложением.
Цель Поддержать сложную логику абонементов и расписаний для разных городов и таймзон.
Действие Сделал конструктор абонементов (направления со своими лимитами или безлимитом), запись и отмену занятий, заморозки, приостановки, трансферы, присутствие студента сразу в нескольких школах, учёт десятков городов в разных таймзонах.
Результат Бэкенд сам корректно отрабатывает эти случаи, ручных операций стало заметно меньше.
Цель Дать живую связь с пользователями.
Действие Построил систему массовых и индивидуальных push-уведомлений на Socket.IO с Redis в роли брокера — realtime масштабируется горизонтально, несколькими процессами за балансировщиком, а не одним «толстым» воркером. Онлайн-сессии и присутствие держу в Redis, доступ — по JWT с асимметричной RSA-подписью (приватный ключ не покидает эмитента, остальные сервисы проверяют токен публичным). Добавил отложенные рассылки по расписаниям и событиям, с генерацией текста по шаблонам и учётом таймзон.
Результат Школы разных городов получают уведомления вовремя, история сообщений сохраняется.
Цель Дать прозрачность обучения и обратную связь, упростить контроль для управляющей компании и партнёров.
Действие Сделал оценку занятий (рейтинги и отзывы), хранение и показ истории действий студента в его профиле, а также инструменты отчётности, рейтингов и контроля для сотрудников управляющей компании, партнёров и школ.
Результат Активность и качество занятий видны в одном месте — решения принимаются по данным, а не на глаз.
Цель Масштабировать продукт на две федеральные сети (GRAFIKA и ArtTech) и подготовить выход за рубеж.
Действие Перестроил архитектуру, расширил и местами переписал логику, структуры моделей и таблиц с сохранением данных тысяч пользователей из множества связанных таблиц. Заложил особенности дизайна и логики под каждую компанию.
Результат Одно приложение работает на две федеральные сети (GRAFIKA и ArtTech) в РФ, начата подготовка к запуску в других странах.
2026. Принял на себя backend, frontend, DevOps, QA, архитектуру и системную аналитику, в том числе поддержку проектов на других языках из смежных отделов. Отдельно взял на себя CI/CD и инфраструктуру: пайплайны четырёх репозиториев, конфигурацию nginx-балансировщика, предеплойные и постдеплойные гейты. Теперь отвечаю практически за всё, что связано с разработкой ПО в компании — от схемы БД до выкладки на прод и процесса, по которому работает команда.
Цель Сделать качество проверяемым, а выкладку — предсказуемой, когда за разработку отвечает один человек.
Действие Выстроил тестовую инфраструктуру на обоих проектах: pytest + pytest-asyncio + httpx на бэкенде (193 теста), vitest на фронтенде (92 unit-теста) и Playwright для сквозных сценариев — 55 e2e-кейсов: проходы по ролям, отдельные прогоны в мобильных раскладках и smoke на вход и аналитику; прогон направляется на любой поднятый стенд через переменную окружения, UI-компоненты вынесены в Storybook. Взял на себя CI/CD в GitLab: девять стадий — сборка образов → линтеры → тесты → очистка раннера → выкладка на удалённые хосты через Docker-контексты → миграции → деплой → уборка → уведомление. Развёл три контура (тестовый стенд и два прода — GRAFIKA и ArtTech) и перевёл релизы на SemVer-теги от main, чтобы каждая версия на проде была однозначно сопоставима с коммитом.
Результат Выкладка стала операцией, а не ритуалом: пайплайн сам не пустит на прод код, не прошедший линтеры и тесты, а откат — это возврат на предыдущий тег.
Цель Исключить релиз, который выглядит успешным, но до стенда не доехал.
Действие Разобрал инцидент: пайплайн был зелёным, но ручной джоб остался ненажатым — прод молча не обновился, а глазами это не поймали. Написал два гейта. Первый сверяет статусы всех джобов пайплайна по каждому контуру: статус «manual» означает «не нажат» и считается провалом, скрипт сразу печатает готовую команду запуска. Второй проверяет работоспособность стендов — шесть адресов, фронтенд и бэкенд каждого из трёх контуров. Предеплойный гейт собрал в одну команду: корневой preflight, flake8 и pytest на бэкенде, ESLint, Stylelint, сборка типов и vitest на фронтенде, по флагу — прогон Playwright по поднятому стенду. Сам порядок релиза зафиксировал runbook’ом: строго database → backend → frontend, теги создаются до деплоя, после деплоя — обязательная функциональная проверка через интерфейс и на обоих прод-брендах.
Результат «Задеплоил» больше не означает «надеюсь, доехало»: ненажатый джоб и неотвечающий стенд ловит скрипт, а не человек. Из этого вырос принцип, который я вписал в правила проекта: проверять результат, а не намерение.
Цель Убрать ручную правку конфигов балансировщика на живом сервере.
Действие Вынес конфигурацию nginx балансировщика в отдельный репозиторий и подключил его в моно-репо — 17 site-конфигов под версионным контролем. CI применяет их сам: бэкап текущих конфигов → копирование новых → nginx -t → и только при успешной валидации reload; провалилась проверка — перезагрузки нет. Там же починил проксирование WebSocket на всех контурах: Socket.IO работал локально, а на стендах отдавал 400, потому что в конфигах не было proxy_http_version 1.1 и заголовков Upgrade/Connection.
Результат Опечатка в конфиге больше не может уронить балансировщик, realtime одинаково работает на тесте и обоих продах, а история изменений инфраструктуры лежит в git, а не в памяти администратора.
Цель Забрать маркетинговую аналитику со стороннего сервера и перестать выжигать лимиты внешних сервисов.
Действие Перенёс подсистему аналитики с внешнего Node.js-дашборда на стороннем хостинге в свой FastAPI-бэкенд: сбор данных из Битрикс24, Яндекс.Директ и VK Ads, расчёт юнит-экономики, план/факт, сводка для управляющей компании, UTM-дерево с бюджетами по кампаниям. Обновление данных построил по модели stale-while-revalidate: ответ формируется из своей базы сразу, фоновая догрузка стартует только если данные старше TTL, а её завершение уходит клиенту push-уведомлением по Socket.IO — вместо того чтобы держать интерфейс в ожидании и постоянно опрашивать чужие API. Частоту обращений держит распределённый rate-limiter в Redis: не чаще одного запроса в 2 секунды на портал целиком, общая пауза для всех процессов при перегрузке; выборка идёт батчами до 50 команд в одном HTTP-запросе, а длинный первичный проход по истории сделал возобновляемым по курсору. OAuth-токены хранятся зашифрованными (Fernet).
Результат Когда аналитику никто не смотрит, обращений к внешнему порталу нет вовсе — риск попасть под ограничения со стороны чужого сервиса снят, а CRM, которой пользуется вся компания, не страдает от нашей синхронизации. Сторонний сервер выведен из эксплуатации: данные, токены и расходы на инфраструктуру вернулись в наш контур.
Цель Дать управляющей компании единую картину по двум брендам, у которых нет общей базы.
Действие Научил детальные эндпоинты аналитики отвечать за соседний контур: по параметру бренда запрос проксируется во второй контур внутренним маршрутом с сервисным токеном, право на это есть только у двух ролей. На фронтенде — экраны с бейджем бренда и человекочитаемыми сообщениями вместо кодов 404, 403 и 502.
Результат Руководство видит оба бренда в одном интерфейсе, а контуры остаются изолированными: общей базы нет, у каждого свои данные, права и цикл релизов.
Цель Не дать двум брендам разъехаться в две несовместимые кодовые базы.
Действие Оставил один бэкенд и один фронтенд-бандл на обе сети: бренд определяется доменом и флагом сборки, а различия в логике, правах и оформлении вынесены в конфигурацию, а не в форк. Фронтенд организовал по Feature-Sliced Design (слои app / pages / widgets / features / entities / shared) — границы между доменами явные, и правка одного модуля не тянет за собой соседние.
Результат Новая фича выходит сразу на обе сети, а не пишется дважды; расхождения между брендами остаются на уровне настроек.
Цель Ускорить разработку и держать единое качество кода, когда над проектом работают разные ИИ-ассистенты и агенты.
Действие Внедрил собственный процесс ИИ-ассистированной разработки: единый свод правил для всех агентов (один источник истины плюс 11 скиллов-дисциплин — git, тесты, асинхронный код, отладка, документация, подготовка и ревью MR, релизы, автоматизация), доску со спринтами, этапами и задачами, Definition of Ready и Done, ритуал коммитов, обязательные тесты и линтеры до коммита, синхронную документацию. Моно-репо с оркестратором сам маршрутизирует запрос в нужный проект и задаёт агенту порядок чтения документов. Механику вынес в скрипты-гейты: синхронность доски с файлами спринтов, валидность ссылок в документации, перевод статусов задач — одной командой; весь ритуал проверок до коммита прогоняет единый preflight. Любой агент (Cursor, Windsurf, Devin, Claude Code, GitHub Copilot, JetBrains AI) читает одни и те же документы и пишет код единообразно. В ежедневной работе совмещаю несколько ассистентов и под задачу выбираю подходящий. Архитектуру, ревью и финальные решения держу за собой — агенты ускоряют рутину, а не заменяют инженера.
Результат — в темпе итераций, а не в ощущениях. С августа 2024 проект шёл двухнедельными спринтами силами команды, доска велась в Jira и Confluence: порядка 46 итераций за первые почти два года, около двух в месяц. В мае 2026 я перевёл цикл на свою схему с доской прямо в репозитории — так историю проекта подхватывает не только человек, но и ИИ-агент. На моей новой схеме с середины мая 2026 года закрыто 20 спринтов и 241 задача — средняя итерация сжалась с двух недель до примерно пяти дней, и это при сократившемся составе. Качество при ускорении держат гейты, а не надежда: код приходит с тестами и пройденными линтерами, документация не отстаёт от кода, ни одного изменения в обход доски. Процесс существует в артефактах, а не на словах: 11 скиллов-дисциплин и 34 документа живой спецификации бэкенда и фронтенда.
Сами мульти-агентные системы, локальные LLM, RAG и дообучение моделей — мой полигон: на нём учусь, проверяю идеи и оттачиваю этот процесс. Методику выложил в открытом виде во флагманском проекте ai-multi-agent-system — открыто лежат AGENTS.md, _board, _docs и .agents. Другие открытые наработки: local-rag-mcp, fine-tuning, ai-tg-bot. Помог маркетингу с интеграциями и автоматизацией: Битрикс24, GetCourse, Tilda, Albato, eLama, RIS.Promo, Марквиз, ВКонтакте. Среди принятых проектов смежных отделов есть сервис не на моём основном стеке — Laravel 11 на PHP 8.2, узел сбора и маршрутизации лидов. Он принимает вебхуки от семи внешних источников лидогенерации (лендинги и формы, квизы, рассылки, партнёрские агентства, отдельный поток с разбивкой по городам) и дополнительно по расписанию забирает лиды из рекламных кабинетов ВКонтакте. Каждый лид нормализуется и уходит в Битрикс24 нужного франчайзи по его городу, одновременно дублируясь в портал управляющей компании: продажи на местах и УК видят одну и ту же заявку. Плюс сквозное логирование и уведомления в Telegram. Разобрался в чужой кодовой базе на другом языке и веду её дальше — PHP у меня тоже подтверждён независимой оценкой Минцифры.