Перейти к содержимому
ZEVSLAB

Бэкенд и интеграции

Серверная часть, которая переживает нагрузку, отказы внешних сервисов и смену команды

Стабилизируем серверную часть, интеграции и унаследованные проекты, в которых отказ внешнего сервиса останавливает приложение, фоновые задачи теряются, а каждое изменение приносит новые ошибки. Стек — PHP и Laravel.

  • PHP
  • Laravel
  • PostgreSQL
  • MySQL
  • Redis
  • RabbitMQ
  • REST API
  • Docker
  • Очереди и планировщики
  • Мониторинг и логирование
  • 1С и CommerceML
  • Kaspi API
  • Bitrix24 и amoCRM

01Симптомы

С чем обычно приходят

Ниже — типичные ситуации, с которых начинается предметный разговор.

  • Внешний сервис отвечает медленно или падает, и вместе с ним ложится ваше приложение
  • Фоновые задачи теряются, дублируются или зависают без следов в логах
  • Любая доработка требует непропорционально много времени и приносит регрессии
  • Разработчик, писавший систему, ушёл, и никто не знает, как она устроена
  • Ответы API замедляются с ростом данных, узкое место не локализовано
  • Интеграция с CRM или учётной системой работает «почти всегда»
  • Заказы, остатки и оплаты вручную сверяются между сайтом, Kaspi, 1С и CRM
  • Нет разделения между бизнес-логикой и деталями конкретного внешнего провайдера

02Охват

Когда это полезно

  • Проект достался по наследству, и нужно понять, что с ним делать
  • Нагрузка выросла, и текущая архитектура перестала справляться
  • Нужен API для мобильного приложения или партнёра, и его нужно спроектировать один раз
  • Интеграция с внешней системой ведёт себя непредсказуемо
  • Нужен контролируемый обмен с 1С, Kaspi, Bitrix24, amoCRM или мессенджерами
  • Команда сильна во фронтенде, но серверная часть — слабое место

Примеры задач

  • Проектирование REST API: контракты, версионирование, обработка ошибок
  • Очереди и фоновые задачи с контролем доставки и защитой от повторной обработки
  • Интеграции с внешними сервисами: таймауты, ограниченные повторы, временное отключение недоступной интеграции и резервные сценарии
  • Обмен с 1С, Kaspi, Bitrix24 и amoCRM через доступные API, вебхуки, CommerceML или согласованный файловый формат
  • Профилирование и устранение узких мест в запросах и коде
  • Рефакторинг унаследованного кода без остановки разработки продукта
  • Восстановление проектов после ухода прежней команды
  • Настройка логирования и наблюдаемости, чтобы отказы были видны сразу
  • Миграции схемы данных на живой системе

03Результат

Что может войти в результат

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

Карта системы

Что из чего состоит, кто с кем разговаривает, где границы ответственности и какие места опасны при изменении.

Реализация и рефакторинг

Код в вашем репозитории. Изменения разбиты на шаги, каждый из которых можно выкатить и откатить отдельно.

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

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

План технического долга

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

04Ход работы

Что происходит внутри проекта

  1. 01

    Разбор текущей системы

    Код, схема данных, логи, точки интеграции. Без гипотез — сначала факты о том, как система работает сейчас.

  2. 02

    Локализация проблемы

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

  3. 03

    Границы и контракты

    Внешние сервисы прячутся за интерфейсами. Бизнес-логика перестаёт зависеть от формата чужого JSON.

  4. 04

    Устойчивость к отказам

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

  5. 05

    Передача

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

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

05Разборы

Как это выглядит на практике

Ход рассуждения, архитектурные решения и нештатные ситуации по этому направлению.

  • Архитектурный разборТорговые и дистрибьюторские команды

    Отчёты из 1С в Telegram с разграничением доступа по ролям

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

    • 1С:Предприятие 8.3
    • HTTP-сервисы 1С
    • Telegram Bot API
    • Python
    • +2

06Форматы

Как можно начать

Конкретный объём и стоимость определяем после знакомства с системой. Первый этап можно заказать отдельно и использовать без продолжения работы с нами.

Технический аудит

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

Проектная работа

Конкретная подсистема или интеграция от проектирования до запуска в рабочей системе.

Усиление команды

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

07Вопросы

Что обычно спрашивают

Возьмётесь ли за старый проект без документации?

Да, это типовая ситуация. Работа начинается с чтения кода и восстановления картины. На этом этапе мы не обещаем сроков по доработкам — сначала нужно понять, с чем имеем дело. Оценку даём после диагностики.

Вы предложите всё переписать?

Как правило, нет. Полное переписывание — самый дорогой и самый рискованный вариант, и он оправдан редко. Чаще работает поэтапная замена частей при работающей системе. Если переписывание всё-таки единственный разумный путь, мы объясним, почему, и покажем стоимость альтернатив.

Работаете только с Laravel?

Основная глубина — в PHP и Laravel. С другими стеками работаем, когда задача лежит в области архитектуры и интеграций, а не в тонкостях конкретного фреймворка. Если стек нам незнаком, говорим об этом до начала работ.

Интегрируете с 1С и Kaspi?

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

Как оцениваете сроки?

После диагностики. Оценка до чтения кода в унаследованном проекте — это угадывание, а не оценка. Диагностика оформляется как отдельный небольшой этап с фиксированным объёмом.

Что происходит после завершения проекта?

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

Обсудить задачу

Опишите текущее состояние системы и желаемый результат. Определим, относится ли задача к направлению «Бэкенд и интеграции» и с какого шага разумно начать.