Это карта терминов справочника: каждый — одна фраза по сути и ссылка на полную запись. Пользуйтесь как настольным словарём: встретили незнакомое слово в чужой спеке или на созвоне — нашли здесь за десять секунд, при необходимости провалились в подробный разбор. Термины — основа языка, на котором аналитик разговаривает с разработчиками, архитекторами и продактом.
Половина недопониманий в команде — это не разные мнения, а разные значения одного слова. Один говорит «идемпотентность», подразумевая ретраи; другой слышит «кеширование». Этот глоссарий — чтобы все читали одно и то же. Он намеренно краткий: одна строка ловит суть, ссылка ведёт за глубиной.
Термины А–Я и латиница
| Термин | Коротко | |
|---|---|---|
| Батч / файловая интеграция | Обмен большими файлами по расписанию (SFTP, manifest, reconciliation); альтернатива real-time API для легаси и объёмов. | → |
| Вебхук | Сервис сам стучится тебе по HTTP, когда наступило событие. | → |
| Выявление требований | Вытащить настоящую потребность: интервью, воркшоп, наблюдение. | → |
| Дискавери / деливери | Выяснить что и зачем делать vs делать выбранное. | → |
| Идемпотентность | Повтор операции даёт тот же результат — повтор запроса не дублирует платёж. | → |
| Инвалидация кэша | Понять, что копия в кэше устарела, и вовремя её обновить. | → |
| Клиент-сервер | Клиент показывает и просит, сервер хранит и считает. | → |
| Контейнер / Docker | Приложение со всем окружением в коробке, одинаково едет везде. | → |
| Микросервисы / монолит | Много мелких сервисов по сети vs одно приложение с одной базой. | → |
| Миграция / бэкфилл | Менять схему БД и заполнять новые поля без даунтайма (expand/contract). | → |
| Модель данных | Концептуальная → логическая → физическая; плюс глоссарий предметной области. | → |
| Нормализация | Каждый факт хранится ровно в одном месте, чтобы данные не разъезжались. | → |
| НФТ / FR | Что система делает (функц.) vs насколько хорошо (нефункц., с числом). | → |
| Ошибки API | Коды и тело ошибок — часть контракта; что ретраить, что показать. | → |
| Оценка / story points | Относительная оценка диапазоном; конус неопределённости. | → |
| Синхрон / асинхрон | Ждать ответ сейчас vs отправить и идти дальше (очередь). | → |
| Система | Элементы + связи + граница + цель; интерфейс прячет внутренности. | → |
| Стейкхолдеры / RACI | Кто влияет на продукт и кто за что отвечает. | → |
| Тестирование | Пирамида тестов; критерий приёмки vs тест-кейс; границы. | → |
| Транзакция | Группа операций «всё или ничего». | → |
| ТЗ | Документ, фиксирующий смысл так, чтобы нельзя было понять неправильно. | → |
| A/B-тест | Сравнение двух версий на живых пользователях по одной метрике. | → |
| ACID | Гарантии транзакции БД: всё-или-ничего, согласованность, изоляция, надёжность. | → |
| ADR | Журнал архитектурных решений: почему выбрали именно так, контекст и последствия. | → |
| BPMN | Нотация бизнес-процессов: кто что делает, в каком порядке, где развилки. | → |
| Breaking change | Изменение API, ломающее старых клиентов (удалить/переименовать поле). | → |
| C4 model | Архитектура на 4 уровнях масштаба: контекст, контейнеры, компоненты, код. | → |
| Canary / blue-green | Стратегии безопасной выкатки: пустить новую версию на часть трафика (canary) или держать два окружения и переключить разом (blue-green). | → |
| CAP-теорема | При разрыве сети выбираешь между согласованностью и доступностью. | → |
| CI/CD | Автосборка+тесты на каждый коммит и автоматическая выкатка. | → |
| DoR / DoD | Готовность задачи к работе (вход) и готовность результата (выход). | → |
| Error budget | Допустимый простой по SLO, который можно «потратить» на риск. | → |
| Eventual consistency | Согласованность наступает не мгновенно, а спустя время. | → |
| Feature flag | Рубильник, который включает фичу без новой выкатки: код уже на проде, но спрятан за флагом. | → |
| GraphQL | Один эндпоинт, клиент сам выбирает нужные поля в запросе. | → |
| gRPC | Вызов удалённой функции как локальной; бинарь, строгий контракт .proto. | → |
| HLD / LLD | Высокоуровневый (архитектура) и низкоуровневый (детали) дизайн. | → |
| Idempotency-key | Уникальный ключ запроса в заголовке: сервер по нему распознаёт повтор и не выполняет операцию дважды. | → |
| Kubernetes | Оркестратор: запускает, лечит и масштабирует множество контейнеров. | → |
| LLM / ИИ | Вероятностный компонент: недетерминирован, может галлюцинировать. | → |
| MVP | Минимальная рабочая версия, проверяющая гипотезу, — не «сырая». | → |
| NoSQL-моделирование | Проектирование данных под паттерн доступа, а не под нормализацию: агрегаты, embedding/referencing, денормализация. | → |
| OAuth2 / JWT | Доступ без пароля через токен; JWT — самодостаточный токен. | → |
| Observability | Понять, что внутри системы, по логам, метрикам и трейсам. | → |
| OpenAPI / Swagger | Машиночитаемое описание контракта REST API. | → |
| PII | Персональные данные; хранить — юридический риск (152-ФЗ, GDPR). | → |
| Postmortem | Разбор инцидента после починки; в хорошей культуре — blameless, без поиска виноватых. | → |
| RAG | Retrieval-Augmented Generation: перед ответом LLM подмешивают найденные в базе фрагменты, чтобы отвечала по фактам, а не по памяти. | → |
| Rate limiting | Лимиты на число запросов; код 429 при превышении. | → |
| RBAC / ABAC | Модели авторизации: права через роли (RBAC) или через атрибуты (ABAC); плюс row-level — доступ к конкретным строкам. | → |
| REST | Ресурсы с URL, действия — HTTP-методами; ответ с кодом. | → |
| RICE / MoSCoW | Методы приоритизации: балл из 4 факторов / 4 корзины. | → |
| Saga | Распределённая транзакция через компенсирующие операции. | → |
| Sequence-диаграмма | UML-диаграмма обмена сообщениями между участниками во времени; главный инструмент для интеграционного сценария. | → |
| SLA / SLO / SLI | Обещание клиенту / внутренняя цель / измеряемый показатель надёжности. | → |
| SRS | Спецификация требований к ПО: структурированный документ «что делаем». | → |
| State machine | Состояния сущности и разрешённые переходы (заказ: создан→оплачен→…). | → |
| Use case | Пошаговый сценарий взаимодействия актора с системой со всеми ветками. | → |
| User story | Короткая потребность: «Как роль, я хочу цель, чтобы ценность». | → |
Как пользоваться
Не пытайтесь выучить глоссарий — держите его открытым. Реальный навык не в том, чтобы помнить определение «идемпотентности», а в том, чтобы вовремя вспомнить, что такое слово есть, и за минуту восстановить смысл. Эта таблица для этого и сделана: узнавание важнее запоминания.
Частые вопросы
Зачем аналитику глоссарий терминов?
Половина недопониманий в команде — это не разные мнения, а разные значения одного слова: один под «идемпотентностью» имеет в виду ретраи, другой слышит кеш. Единый глоссарий выравнивает язык, на котором аналитик говорит с разработчиками, архитекторами и продактом. Плюс это быстрая точка входа: встретил незнакомый термин — нашёл суть за секунды и при необходимости провалился в подробный разбор.
Эти термины нужно знать наизусть?
Нет. Полезнее узнавание, а не запоминание: достаточно помнить, что такое слово существует, и уметь быстро восстановить смысл. Глоссарий для того и держат открытым. Глубину учат на практике и по подробным записям, на которые ведут ссылки, а словарь экономит время в моменте — на созвоне или при чтении чужой спеки.
С чего начать изучение, если терминов слишком много?
Идите по оглавлению справочника сверху вниз: контекст и роли → основы → требования → документы → процесс и продукт → API → интеграции → данные → эксплуатация → инструменты. Глоссарий — не маршрут обучения, а словарь для быстрой справки; учиться лучше по порядку записей, а сюда возвращаться за конкретным словом.