Backend разработчик
Назад

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

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

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

Паспорт регламента

Код
EXAMPLE-REG-BACKEND
Версия
2.0
Статус
Пример регламента для адаптации
Владелец
Backend Lead / технический руководитель
Утверждает
Уполномоченное лицо организации после внутреннего согласования
Юрисдикция
Республика Беларусь
Пересмотр
Не реже одного раза в год, а также после существенного изменения законодательства, процессов или технологий
Актуализирован
5 августа 2026 года

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

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

Применение в Республике Беларусь

  • Работа выполняется в пределах трудовой функции, полномочий, локальных правовых актов и договоренностей конкретной организации. Обязательства перед клиентом принимает только уполномоченное лицо.
  • При обработке персональных данных применяются принципы Закона Республики Беларусь от 7 мая 2021 г. № 99-З: законная цель и основание, соразмерность состава данных, ограничение срока хранения, прозрачность и защита прав субъекта.
  • До привлечения внешнего сервиса или подрядчика определяется роль организации и контрагента как оператора либо уполномоченного лица, перечень данных, операции, меры защиты, возврат и удаление данных.
  • Трансграничная передача персональных данных и использование зарубежных SaaS согласуются с ответственным за внутренний контроль обработки персональных данных до загрузки реальных данных.
  • Юридически значимые решения, согласования и документы оформляются в форме, предусмотренной договором и законодательством. Сообщение в чате или отметка в трекере не приравниваются автоматически к электронному документу с ЭЦП.
  • Коммерческая тайна, сведения клиента, исходный код, учетные данные и внутренние документы передаются только лицам с рабочей необходимостью через одобренные компанией системы.
  • При дистанционной или комбинированной работе соблюдаются условия трудового договора, локальный порядок взаимодействия, режим рабочего времени и требования по безопасному использованию предоставленного оборудования.
  • Для каждой обработки персональных данных в архитектуре фиксируются цель, основание, категории субъектов и данных, получатели, сроки хранения, удаление и трансграничная передача.
  • Информационные системы с персональными данными классифицируются и защищаются в порядке, применимом к организации; требования уточняются с ответственным за информационную безопасность и персональные данные.

Что проверить до начала работы

  • Названы заказчик результата, владелец решения, исполнители, согласующие лица и канал эскалации.
  • Зафиксированы цель, ожидаемый результат, границы задачи, срок, приоритет, зависимости и критерии приемки.
  • Определена классификация информации: публичная, внутренняя, конфиденциальная, коммерческая тайна или персональные данные.
  • Подтверждено, что специалист имеет необходимые доступы и полномочия, а лишние права не выдаются.
  • Понятно, где хранится актуальная версия результата и какие записи подтверждают выполненную работу.
  • Согласованы data flow, роли оператора и уполномоченных лиц, модель угроз, требования к журналированию и сроки хранения.
  • Определены требования к локализации, внешним API, облакам, резервным копиям и удалению данных из реплик и архивов.

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

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

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

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

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

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

Контрольные вопросы специалиста

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

  1. Какая бизнес-операция и какое правовое основание требуют хранения каждого поля?
  2. Можно ли уменьшить состав данных, срок хранения или заменить идентификатор псевдонимом?
  3. Кто может читать, создавать, изменять, экспортировать и удалять данные?
  4. Как запрос субъекта на доступ, исправление или удаление пройдет через сервисы и резервные копии?
  5. Какие внешние системы получают данные и разрешена ли такая передача?
  6. Как обеспечены идемпотентность, транзакционность, аудит и защита от повторной обработки?
  7. Не содержит ли API избыточные поля, предсказуемые идентификаторы или подробные внутренние ошибки?
  8. Как выполняются безопасная миграция, совместимость версий и rollback без потери данных?
  9. Какими логами и метриками инцидент диагностируется без раскрытия содержимого данных?

Персональные данные и безопасность

  • Использовать корпоративные учетные записи, MFA, менеджер секретов и принцип минимально необходимых прав; не передавать пароли в чатах, документах и задачах.
  • Не копировать рабочие материалы в личную почту, личные облака, публичные AI-сервисы или неутвержденные инструменты без письменного разрешения владельца информации.
  • Не использовать реальные персональные данные в разработке, тестировании, демонстрациях и обучении, если цель может быть достигнута синтетическими или обезличенными данными.
  • В логах, снимках экрана, отчетах и bug report скрывать токены, пароли, номера документов, платежные данные и иные избыточные идентификаторы.
  • При ошибочной отправке, утрате доступа, подозрении на утечку или несанкционированную обработку немедленно прекратить распространение и уведомить руководителя и ответственного за персональные данные; внешние уведомления выполняют уполномоченные лица в установленные сроки.
  • Доступы пересматриваются при смене роли, завершении проекта и увольнении; данные и носители возвращаются или удаляются по подтвержденной процедуре.
  • Секреты хранить во внешнем secret store; персональные данные шифровать при передаче и, когда требуется моделью риска, при хранении.
  • Административные операции и массовые выгрузки должны быть авторизованы, журналироваться и иметь защиту от случайного запуска.

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

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

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

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

Контрольные точки

  • До реализации согласованы границы сервиса, API-контракт, модель данных, ошибки и нефункциональные требования.
  • Перед merge проверены тесты, миграции, индексы, права доступа, обработка ошибок и обратная совместимость API.
  • Перед релизом описаны env-переменные, очереди, cron, миграции, rollback и мониторинг критичных сценариев.
  • После релиза проверены логи, метрики, очереди, ошибки 5xx, slow queries и ключевой пользовательский сценарий.

Антипаттерны

  • Менять API-контракт без согласования с frontend, QA и владельцем продукта.
  • Хранить бизнес-логику в случайных местах без тестов и понятной ответственности.
  • Выкатывать тяжелые миграции без анализа блокировок, объема данных и плана отката.
  • Логировать ошибку без контекста, идентификаторов запроса и возможности быстро найти причину.

Рабочий ритм и периодический контроль

  • По рабочим дням: обновить статус задач, зафиксировать блокеры и решения, требующие участия других ролей.
  • Еженедельно: сверить приоритеты, риски, качество артефактов, просрочки и необходимость эскалации.
  • Перед релизом или передачей результата: провести проверку по критериям приемки, безопасности, персональным данным и эксплуатационным рискам.
  • После релиза: проверить фактический результат и зарегистрировать дефекты, отклонения, уроки и последующие действия.
  • Ежеквартально: пересмотреть доступы, устаревшие документы, ручные операции, технический долг и соответствие регламенту.
  • На архитектурном review: пересматривать data flow, внешних получателей, retention, права и сценарии удаления.

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

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

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

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

Матрица обязательной эскалации

  • Немедленно: утечка или подозрение на утечку данных, компрометация учетной записи, критическая уязвимость, недоступность ключевого сервиса или риск необратимой потери данных.
  • В течение рабочего дня: нарушение договорного срока, блокирующее противоречие требований, несанкционированное изменение production, юридический или репутационный риск.
  • До продолжения работы: отсутствует владелец решения, правовое основание обработки данных, согласованный критерий приемки либо полномочие на действие.
  • Эскалация содержит факты, влияние, затронутые системы и данные, уже выполненные безопасные действия, варианты решения и время следующего обновления.
  • Немедленно эскалировать нарушение изоляции клиентов, несанкционированную выгрузку, потерю ключей, невозможность восстановить данные и критичную уязвимость зависимости.

Когда работа считается завершенной

  • Результат проверен по всем критериям приемки, а непроверенные области и остаточные риски перечислены явно.
  • Артефакты, решения, версии, ссылки и доказательства проверки сохранены в согласованном корпоративном источнике.
  • Заинтересованные роли уведомлены об изменении, ограничениях, действиях после релиза и владельце дальнейшего сопровождения.
  • Временные доступы, файлы, тестовые данные, feature flags и обходные решения удалены либо имеют владельца и срок закрытия.
  • Результат принят владельцем решения или имеется письменное решение о принятии остаточного риска уполномоченным лицом.
  • Backend-изменение готово после тестов, review миграций и прав, обновления API/ADR/runbook, проверки наблюдаемости и подтвержденного post-deploy smoke test.

Документирование и хранение записей

  • Рабочие решения и согласования фиксируются в трекере, базе знаний, репозитории или системе электронного документооборота, принятой в компании.
  • Срок хранения определяется номенклатурой дел, договором, целью обработки и требованиями законодательства; персональные данные не хранятся “на всякий случай”.
  • Удаление или архивирование должно быть контролируемым: сохраняются необходимые версии, авторство, дата решения и связь с проектом или релизом.
  • Экспорт данных и локальные копии допускаются только на срок рабочей необходимости и удаляются после подтвержденной загрузки результата в корпоративную систему.
  • Хранить ADR, OpenAPI, схему и классификацию данных, миграционный план, журнал изменений и подтверждения restore/rollback.

Нормативная основа и официальные материалы

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