7 мая 2026 г.·2 мин чтения

Architecture Decision Records на собеседовании системного аналитика

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Содержание:

Зачем спрашивают на собесе SA

ADR — стандарт документирования архитектурных решений. На собесе SA: «как ты документируешь decisions», «зачем ADR».

Что такое ADR

Architecture Decision Record. Документ, фиксирующий значимое архитектурное решение с context, alternatives, consequences.

Идея — через год / при смене команды можно понять «почему мы сделали X, а не Y».

Формат

Стандартный template (Michael Nygard):

# ADR-001: Использовать Postgres для основной БД

## Status
Accepted

## Context
Нам нужна OLTP БД для нового сервиса. Альтернативы — Postgres, MySQL, MongoDB.

## Decision
Используем Postgres 16 как primary БД.

## Consequences

### Positive
- Богатая поддержка JSON.
- Отличный optimizer.
- Команда уже знает.
- ACID гарантии.

### Negative
- Higher operational overhead vs managed cloud DB.
- Меньше horizontal scale из коробки.

## Alternatives considered

### MySQL
- Хорошо для простых OLTP, но менее богатый SQL.
- Хуже JSON поддержка.

### MongoDB
- Schema flexibility.
- Но без транзакций — для финансовых данных риск.
Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Lifecycle status

  • Proposed. Обсуждается.
  • Accepted. Команда согласилась.
  • Rejected. Не принято.
  • Deprecated. Устарело, но не заменено.
  • Superseded by ADR-XX. Заменено новым решением.

ADR — immutable. Если решение поменялось — новый ADR, старый получает status «Superseded».

Применение

Где хранить:

  • В git вместе с кодом (docs/adr/).
  • В Confluence / Notion с links.
  • ADR-tools (CLI tool для управления).

Когда писать:

  • Major tech choices (DB, framework, cloud).
  • Pattern decisions (CQRS, event-driven).
  • Trade-off decisions (consistency vs availability).

Не писать:

  • Тривиальные things (имя переменной, library version bump).

Кто пишет: обычно architect / tech lead. SA может для cross-team / business-architecture decisions.

Review. ADR обсуждается на architecture review. Once accepted — followed.

Связанные темы

FAQ

Сколько ADR на проект?

10-50 на медиум проект. На крупном — 100+. Главное — quality, not quantity.

Это официальная информация?

Нет. Статья основана на работах Michael Nygard, ADR community.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме