
Описание Задача. Заказчику требовалась собственная система управления проектами и задачами на своей
Описание
Задача. Заказчику требовалась собственная система управления проектами и задачами на своей инфраструктуре, без привязки к внешним SaaS. Проекты содержат задачи, задачи декомпозируются на подзадачи, по ним считается процент выполнения. Отдельным требованием шло быстрое развёртывание: система должна разворачиваться на чистом сервере под новую площадку без ручной настройки.
Решение
Архитектура: тонкий API, логика в базе. Сознательно выбранное разделение — API принимает запрос, валидирует его и передаёт в СУБД, обработка данных выполняется на уровне PostgreSQL.
API на Go в Docker-контейнере: маршрутизация, middleware, валидация, работа с файлами, интеграция с Firebase Cloud Messaging для push-уведомлений. Конфигурация через yml с приоритетом переменных окружения — один образ работает в любом окружении.
PostgreSQL: вся бизнес-логика в хранимых процедурах на PL/pgSQL, принимающих и возвращающих jsonb, с единым шаблоном обработки исключений и кодами ошибок. Объекты разбиты по схемам согласно бизнес-доменам (пользователи, задачи, системные данные), выполнение процедур выдаётся отдельному пользователю приложения через GRANT EXECUTE — API не имеет прямого доступа к таблицам.
Единый контракт API: любой ответ — объект {status, data, errors} с массивом ошибок и числовыми кодами, что упрощает разработку клиентов.
Единый сквозной идентификатор запроса, генерируемый на nginx и далее передаваемый до БД для фильтрации по логам.
Документация API в Swagger/OpenAPI

АТОиР — учёт оборудования с QR-маркировкой и заявки на обслуживание с цепочками подрядчиков
Описание
Задача. Автоматизировать учёт оборудования и заявок на его техническое обслуживание и ремонт в схеме, где в процессе участвует несколько независимых организаций. Владелец оборудования подаёт заявку, но выполняет её подрядчик — который, в свою очередь, может передать работу субподрядчику, и такие цепочки бывают многоуровневыми. До внедрения парк оборудования вёлся в таблицах, а переписка по заявкам — в мессенджерах: владелец не видел, кто фактически выполняет работу и на каком этапе она находится, а при подаче заявки приходилось вручную искать нужную единицу оборудования в списке.
Решение
Что сделано. Реализовал проект целиком — от проектирования модели данных и API до интерфейсов и развёртывания:
Бэкенд на Go — REST API, аутентификация, ролевая модель в разрезе организаций, реестр оборудования, генерация QR-кодов, жизненный цикл заявки (создание → назначение исполнителя → передача субподрядчику → выполнение → приёмка → закрытие), логирование всех переходов, уведомления участникам.
Telegram Mini App для инженеров-исполнителей — сканирование QR-кода оборудования, создание заявок, работа с назначенными заявками, смена статусов и отчёт о выполненных работах прямо с объекта, без установки отдельного приложения.
Серверная часть — настройка окружения, деплой, CI/CD.
Стек: php, Go, PostgreSQL, Telegram Bot API / Mini Apps, AppStack, Docker, GitLab CI/CD, nginx.

Оптимизация сервера для сайта на Битркик
Описание
Клиент обратился с проблемой - очень тормозит сайт.
Проверили без кэша страница генерировалась 6 секунд из них почти все время выполнение запросов в БД.
Решение
Проведена комплексная диагностика высокой нагрузки на сервер базы данных сайта. Основной задачей было выявление наиболее ресурсоемких и часто выполняемых запросов, их оптимизация средствами MySQL и определение запросов, требующих доработки программной логики Битрикс.
Результат
Получены следующие подтвержденные результаты:
- поиск разделов по свойствам ускорен примерно с 4 секунд до 0,03 секунды;
- полная выборка свойств элементов ускорена с 2,18–2,46 до 0,49–0,65 секунды;
- при поиске по артикулу устранено чтение примерно 55 тысяч строк — план перешел к точечному поиску;
- запросы к журналу Яндекс.Маркета сократили среднее число обрабатываемых строк примерно с 11,6 тысячи до 146;
- фильтры дисков ускорены примерно с 50–65 до 10–20 миллисекунд;
- время отдельных фасетных запросов сократилось примерно с 0,9 до 0,20–0,27 секунды.
Для 12 шаблонов достигнут предел оптимизации средствами индексов, они переданы разработчикам Битрикса для улучшения с рекомендациями.