Назад

Регламент Ariol · Backend разработчик

Регламент работы Backend-разработчика

Правила серверной разработки в Ariol: границы сервиса, API, данные, безопасность, производительность, наблюдаемость и эксплуатационная готовность.

Цель регламента

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

Зона ответственности

  • Архитектура серверной логики, API, интеграции, базы данных, очереди, кеширование, безопасность, логи, метрики и миграции.
  • Backend отвечает не только за “работает локально”, но и за корректное поведение под нагрузкой, отказами и реальными данными.

Обязанности специалиста

  • Фиксировать границы ответственности сервиса, контракты API и зависимости.
  • Проектировать данные и миграции с учетом обратимости, совместимости и безопасного деплоя.
  • Обрабатывать ошибки явно: коды ответа, сообщения, retry-логика, логирование и алерты.
  • Проверять безопасность: доступы, валидация, секреты, права, защита от типовых уязвимостей.
  • Оставлять наблюдаемость: структурные логи, ключевые метрики и понятные точки диагностики.

Рабочий порядок

  1. Разобрать требование и определить границы: бизнес-правила, данные, внешние системы, ограничения.
  2. Согласовать API-контракт, модель данных, ошибки и сценарии совместимости.
  3. Реализовать код с тестами на основную логику, edge cases и интеграции.
  4. Проверить миграции, индексы, транзакции, очереди, кеш и поведение при ошибках.
  5. Подготовить релизные заметки: миграции, env, флаги, rollback, мониторинг.
  6. После релиза проверить логи, метрики, ошибки и пользовательские сценарии.

Обязательные артефакты

  • API contract.
  • ADR или краткое архитектурное решение.
  • Миграции и схема данных.
  • Тесты и factory/fixtures.
  • Runbook для эксплуатации.
  • Release notes для backend-изменений.

Критерии качества

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

Метрики контроля

Ошибки 5xxLatencyThroughputОчереди и retriesDB slow queriesПокрытие тестами критичной логикиИнциденты после релиза

Коммуникации и эскалация

  • Любые изменения API-контракта согласуются с frontend, QA и PM до реализации.
  • Риски миграций, интеграций и производительности фиксируются до релиза.
  • При инциденте backend дает короткий technical summary: причина, влияние, исправление, профилактика.