150 вопросов с ответами

Основные техники выявления требований: интервью, анкетирование, наблюдение за работой пользователей (shadowing), воркшопы и мозговые штурмы, анализ документации и существующих систем, анализ интерфейсов, прототипирование, фокус-группы, анализ логов и обращений в поддержку. Выбор зависит от доступности стейкхолдеров и типа задачи: для новой функциональности хорошо работают интервью и прототипы, для доработки legacy — анализ документации, кода и данных. На практике чаще всего сочетают интервью с ключевыми пользователями, анализ существующей системы и демонстрацию прототипа для подтверждения понимания.

Стейкхолдер (заинтересованное лицо) — человек или группа, которые влияют на систему или на которых влияет её создание: заказчик, конечные пользователи, владелец продукта, разработчики, тестировщики, архитекторы, служба безопасности, поддержка, регуляторы, смежные команды. Для системного аналитика ключевые стейкхолдеры — бизнес-заказчик и продакт (дают цели), пользователи (дают сценарии), а также разработка, QA и архитектор (потребители постановок). Сама команда разработки тоже может быть источником требований: например, требования к логированию, мониторингу, обратной совместимости API или ограничения по производительности — это нормальная практика.

По Вигерсу выделяют уровни: бизнес-требования (зачем: «сократить время обработки заявки на 30%»), пользовательские (что пользователь хочет сделать: «как менеджер, я хочу видеть список заявок»), функциональные (что делает система: «система должна фильтровать заявки по статусу»), нефункциональные (как хорошо: «список загружается не дольше 2 секунд»), а также бизнес-правила, ограничения, требования к интерфейсам и данным. Отдельно выделяют транзитные требования. Системный аналитик чаще всего работает с функциональными, нефункциональными, требованиями к интеграциям и данным, опираясь на бизнес- и пользовательские требования.

Популярные классификации — FURPS+ (Functionality, Usability, Reliability, Performance, Supportability + ограничения) и модель качества ISO/IEC 25010 (функциональная пригодность, производительность, совместимость, удобство использования, надёжность, безопасность, сопровождаемость, переносимость). На практике чаще всего описывают производительность (время ответа, RPS), доступность (SLA 99,9%), безопасность (аутентификация, роли, шифрование), масштабируемость, требования к логированию и аудиту, ограничения по технологиям. Пример: «API поиска клиентов должен отвечать за 300 мс для 95% запросов при нагрузке до 200 RPS».

Функциональные требования описывают, что система делает: функции, реакции на действия пользователя, обработку данных («система отправляет SMS с кодом подтверждения»). Нефункциональные описывают, как система это делает и в каких рамках: качество, ограничения, характеристики («SMS доставляется не позже 30 секунд», «код действителен 5 минут»). Функциональные проверяются сценарными тестами, нефункциональные — нагрузочными, тестами безопасности, замерами. Если нарушено функциональное требование, функции нет; если нефункциональное — функция есть, но работает неприемлемо.

Транзитные требования описывают, что нужно для перехода из текущего состояния в целевое, и после внедрения теряют актуальность. Это миграция данных из старой системы, период параллельной работы двух систем, обучение пользователей, конвертация форматов, временные интеграции. Пример: «До отключения старой CRM все созданные в ней клиенты должны ежедневно переноситься в новую систему». Их часто забывают, поэтому стоит явно выделять их в отдельный раздел.

User story — короткое описание потребности пользователя с его точки зрения, применяется в Agile. Классический шаблон: «Как <роль>, я хочу <действие>, чтобы <ценность>». Пример: «Как покупатель, я хочу сохранить товар в избранное, чтобы вернуться к нему позже». История дополняется критериями приёмки, часто в формате Given/When/Then: «Дано: пользователь авторизован; Когда: он нажимает на сердечко; Тогда: товар появляется в разделе Избранное». Сама история — это повод для обсуждения, а детали системный аналитик дописывает в постановке (API, данные, ошибки).

User story map — двумерная карта историй: по горизонтали идут шаги пользовательского пути (активности, например «найти товар — положить в корзину — оплатить — получить»), по вертикали под каждым шагом — истории, упорядоченные по приоритету. Карта помогает увидеть продукт целиком, а не плоским бэклогом, найти пропущенные шаги и нарезать релизы горизонтальными срезами: первый срез — MVP, проходящий весь путь пользователя в минимальном виде. Техника предложена Джеффом Паттоном и удобна на старте продукта или крупной фичи.

User story фокусирует команду на ценности для пользователя, а не на технической реализации. Истории короткие, их легко обсуждать, приоритизировать, оценивать и переставлять в бэклоге. Они хорошо подходят для итеративной разработки: можно быстро выпустить небольшой инкремент и получить обратную связь. Также они стимулируют живое общение с бизнесом вместо объёмных документов. Минус — истории не заменяют детальной спецификации для сложной логики и интеграций.

Для проверки используют критерии INVEST: Independent (независимая), Negotiable (обсуждаемая), Valuable (ценная), Estimable (оцениваемая), Small (небольшая, помещается в спринт), Testable (проверяемая). У хорошей истории есть понятная роль, конкретное действие, явная ценность и критерии приёмки. Плохо: «Как пользователь, я хочу, чтобы система работала быстро». Хорошо: «Как оператор колл-центра, я хочу найти клиента по номеру телефона, чтобы не тратить время на уточнение ФИО», с критериями: поиск по полному номеру в любом формате, результат за 1 секунду, при отсутствии клиента — сообщение «Клиент не найден».

Use case (вариант использования) — описание взаимодействия актора с системой для достижения конкретной цели, включая основной и альтернативные сценарии. Типичная структура (по Коберну): название, актор, предусловия, триггер, основной поток, альтернативные потоки и исключения, постусловия.

UC-05 Оформление заказа
Актор: Покупатель
Предусловие: в корзине есть товары, пользователь авторизован
Основной сценарий:
1. Покупатель нажимает «Оформить заказ».
2. Система показывает форму доставки.
3. Покупатель заполняет адрес и выбирает способ оплаты.
4. Система создаёт заказ в статусе «Новый» и показывает его номер.
Альтернатива 3а: адрес вне зоны доставки — система показывает сообщение и предлагает самовывоз.
Постусловие: заказ сохранён, корзина очищена.

Use cases удобны для сложных сценариев с множеством ветвлений и для систем, где важна полнота описания.

User story — короткая формулировка потребности и ценности, она намеренно неполная и служит поводом для обсуждения; детали появляются в критериях приёмки. Use case — подробное описание взаимодействия актора с системой по шагам, с альтернативными и исключительными потоками. Истории удобнее для планирования и приоритизации в Agile, юзкейсы — для полной спецификации поведения. Часто их совмещают: история в бэклоге, а сложный сценарий детализирован юзкейсом в Confluence.

Это российские комплексы стандартов на документацию. ГОСТ 19 (ЕСПД, Единая система программной документации) регламентирует документы на программы: техническое задание на программу (ГОСТ 19.201), описание программы, руководство оператора, программу и методику испытаний. ГОСТ 34 регламентирует создание автоматизированных систем: стадии и этапы (34.601), состав документации (34.201), техническое задание на АС (ГОСТ 34.602, в 2020 году заменён на ГОСТ Р 34.602-2020). Они нужны прежде всего в госзаказе и крупных корпорациях, где документация — часть договора и приёмки.

ГОСТ 19 описывает документацию на программу (программный продукт) и фокусируется на самой программе: её функциях, входных и выходных данных. ГОСТ 34 описывает создание автоматизированной системы целиком — это программы плюс оборудование, персонал, процессы, организационное обеспечение, и охватывает весь жизненный цикл: от обследования до ввода в эксплуатацию. Соответственно, ТЗ по ГОСТ 34 шире: включает требования к персоналу, надёжности, безопасности, видам обеспечения, порядку приёмки. Выбор стандарта обычно определяет заказчик.

Классические критерии (IEEE 830, Вигерс) для отдельного требования: корректность, однозначность, полнота, атомарность, проверяемость (тестируемость), реализуемость, необходимость, приоритизированность, трассируемость. Для набора требований — непротиворечивость, полнота и модифицируемость. Простой тест: тестировщик может написать по требованию тест-кейс, а разработчик — реализовать без вопросов. Плохо: «система должна быстро отображать отчёт». Хорошо: «отчёт за месяц формируется не более чем за 5 секунд».

Артефакты — любые результаты работы аналитика, которые используют другие участники. Типичные: ТЗ или SRS, постановки задач, user stories с критериями приёмки, use cases, модели процессов (BPMN), UML-диаграммы (sequence, activity, state), модели данных (ER-диаграммы), спецификации API (OpenAPI/Swagger, JSON Schema), маппинги полей, прототипы и макеты, глоссарий, матрица трассировки, протоколы встреч. Набор зависит от проекта: в продуктовой команде это чаще постановки в Confluence и Jira, в госпроектах — документы по ГОСТ.

Разработчики (реализуют по постановкам и спецификациям API), тестировщики (пишут тест-кейсы по требованиям и критериям приёмки), архитекторы (проверяют соответствие решениям), заказчик и продакт (согласовывают и принимают), дизайнеры (получают сценарии), техписатели (готовят пользовательскую документацию), поддержка и сопровождение (разбираются в логике системы), смежные команды (интегрируются по контрактам). Важно учитывать аудиторию: бизнесу нужен язык процессов и ценности, разработке — точные данные, форматы и правила.

Типичный шаблон постановки задачи:

• цель и контекст (зачем делаем, ссылка на бизнес-требование или историю);
• глоссарий и затрагиваемые системы;
• описание сценариев (основной и альтернативные), часто с диаграммой последовательности;
• изменения в UI (макеты, поля, валидации);
• изменения в API и интеграциях (методы, запросы, ответы, коды ошибок);
• изменения в модели данных;
• бизнес-правила и расчёты;
• нефункциональные требования, права доступа, логирование;
• критерии приёмки и открытые вопросы.

Хорошая постановка позволяет разработчику и тестировщику работать без постоянных уточнений.

Ссылку на макет, перечень экранных форм и элементов, для каждого поля — название, тип, обязательность, формат и маску, значение по умолчанию, источник данных, правила валидации и тексты ошибок. Также поведение кнопок и переходы между экранами, состояния (загрузка, пустой список, ошибка), права доступа к элементам, сортировки, фильтры и пагинацию. Пример строки таблицы полей: «Телефон — строка, обязательное, маска +7 (XXX) XXX-XX-XX, при ошибке: "Введите номер в формате +7…"; кнопка "Сохранить" неактивна, пока не заполнены обязательные поля; по нажатию вызывается PATCH /clients/{id}».

Участников (система-источник и система-приёмник), назначение и триггер обмена, способ взаимодействия (REST, SOAP, очередь, файл), синхронность, направление и частоту. Далее — контракт: эндпоинт или топик, метод, формат сообщения, описание полей с типами и обязательностью, пример запроса и ответа, маппинг полей между системами. Обязательно — обработка ошибок (коды, ретраи, таймауты, что делать при недоступности), идемпотентность, безопасность (аутентификация, сертификаты), нефункциональные параметры (объёмы, нагрузка) и логирование. Полезно приложить sequence-диаграмму.

SRS — спецификация требований к ПО или системе: документ с полным описанием функциональных и нефункциональных требований, внешних интерфейсов, ограничений и допущений. Классическая структура задана стандартом IEEE 830 (сейчас ISO/IEC/IEEE 29148): введение, общее описание, детальные требования. Применяется в водопадных и гибридных проектах, на аутсорсе и при фиксированном объёме работ, когда требования нужно согласовать до разработки. В Agile вместо единого SRS обычно ведут живую документацию в Confluence, но сама структура SRS остаётся полезной как чек-лист.

Верификация отвечает на вопрос «правильно ли мы описали требования?» — проверка качества самих требований: однозначность, полнота, непротиворечивость, соответствие шаблону и стандартам (ревью, инспекции). Валидация отвечает на вопрос «те ли требования мы описали?» — проверка, что требования действительно решают задачу бизнеса и пользователей (демонстрации, прототипы, согласование с заказчиком). Коротко: верификация — «делаем вещь правильно», валидация — «делаем правильную вещь».

Основные нотации: BPMN — бизнес-процессы; UML — поведение и структура ПО (sequence, activity, use case, class, state и др.); ER-диаграммы (нотации Чена, IDEF1X, Crow's Foot) — модели данных; IDEF0 — функциональное моделирование; EPC — процессы (ARIS); DFD — потоки данных; C4 — архитектура на уровнях контекста, контейнеров, компонентов. На практике системный аналитик чаще всего использует BPMN для процессов, sequence-диаграммы для интеграций, ER для данных и диаграммы состояний для жизненного цикла сущностей. Инструменты: draw.io, PlantUML, Camunda Modeler, Enterprise Architect.

Элементы BPMN 2.0 делятся на группы:

• потоковые объекты — события (круги), действия/задачи и подпроцессы (прямоугольники со скруглением), шлюзы (ромбы);
• соединяющие объекты — поток операций (сплошная стрелка), поток сообщений (пунктир между пулами), ассоциации;
• зоны ответственности — пулы (участники процесса) и дорожки (роли внутри участника);
• артефакты — объекты данных, хранилища данных, группы, текстовые аннотации.

Задачи бывают разных типов: пользовательская, сервисная, ручная, отправка/получение сообщения, скриптовая, бизнес-правило.

Эксклюзивный (XOR, ромб с крестом) — выбирается ровно один путь по условию. Параллельный (AND, ромб с плюсом) — запускаются все ветки одновременно, при слиянии ждём все. Неэксклюзивный (OR, ромб с кругом) — выполняется одна или несколько веток, условия которых истинны. Шлюз по событиям (ромб с пятиугольником в двойном круге) — путь выбирается по тому, какое событие наступит первым (например, пришёл ответ или истёк таймер). Также есть комплексный шлюз (ромб со звёздочкой) для нестандартных условий слияния.

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

UML 2.x содержит 14 диаграмм в двух группах. Структурные: классов, объектов, компонентов, развёртывания, пакетов, композитной структуры, профилей. Поведенческие: вариантов использования (use case), деятельности (activity), состояний (state machine) и диаграммы взаимодействия — последовательности (sequence), коммуникации, обзора взаимодействия, временная (timing). Системные аналитики чаще всего используют sequence (интеграции), activity (алгоритмы), state (статусная модель), use case и class/ER-подобные диаграммы для данных.

Комбинированные фрагменты (combined fragments) задают логику внутри диаграммы последовательности:

• alt — ветвление «если/иначе»;
• opt — необязательный блок, выполняется при условии;
• loop — цикл;
• par — параллельное выполнение;
• break — прерывание сценария (например, при ошибке);
• critical — атомарный участок;
• ref — ссылка на другую диаграмму;
• также neg, assert, strict, seq, ignore, consider.

На практике чаще всего используют alt, opt, loop, par и ref.

ER-диаграмма описывает модель данных: сущности, их атрибуты и связи с кардинальностью, и используется для проектирования базы данных. Диаграмма классов UML описывает объектную модель ПО: классы с атрибутами и методами, а также отношения — ассоциацию, агрегацию, композицию, наследование, зависимость, реализацию интерфейсов. Значит, диаграмма классов отражает не только данные, но и поведение и ООП-понятия, которых нет в реляционной модели. Проще: ER — «как хранить», class — «как устроен код».

Use case-диаграмма UML показывает, какие функции (варианты использования) система предоставляет каким пользователям, без детализации шагов. Элементы: актор (человечек — роль пользователя или внешняя система), вариант использования (овал), граница системы (прямоугольник), связи: ассоциация (актор — вариант использования), include (обязательное включение общего поведения), extend (необязательное расширение при условии), обобщение (наследование акторов или вариантов). Пример: актор «Клиент» связан с «Оформить заказ», который включает (include) «Авторизоваться» и расширяется (extend) «Применить промокод».

База данных — организованная совокупность структурированных данных, которые хранятся по определённым правилам и предназначены для удобного поиска, изменения и анализа. Данные в БД описываются схемой (структурой) и не зависят от конкретной прикладной программы. Пример — таблицы клиентов, заказов и товаров интернет-магазина. Важно различать саму БД (данные) и СУБД (программу, которая ими управляет).

СУБД (система управления базами данных) — программное обеспечение для создания, хранения, изменения и чтения данных в БД. Она обеспечивает язык запросов (например, SQL), контроль целостности, транзакции, параллельный доступ, права пользователей, резервное копирование и восстановление. Примеры реляционных СУБД: PostgreSQL, Oracle, MS SQL Server, MySQL; нереляционных: MongoDB, Redis, Cassandra, ClickHouse (колоночная), Neo4j.

По модели данных: реляционные (таблицы, SQL: PostgreSQL, Oracle), и нереляционные (NoSQL): документные (MongoDB), ключ–значение (Redis), колоночные/широкостолбцовые (Cassandra, ClickHouse), графовые (Neo4j), а также поисковые (Elasticsearch) и временных рядов (InfluxDB). Исторически были иерархические и сетевые. По назначению различают OLTP (транзакционные, много коротких операций) и OLAP (аналитические, хранилища данных). Типичный опыт аналитика — PostgreSQL или Oracle для основной системы и Redis или Elasticsearch как вспомогательные хранилища.

Название происходит от математического понятия «отношение» (relation), на котором Эдгар Кодд в 1970 году построил реляционную модель данных. Отношение — это таблица: множество кортежей (строк) с одинаковым набором атрибутов (столбцов). Распространённое заблуждение — что название от связей (relationships) между таблицами; связи через внешние ключи есть, но термин означает именно отношение-таблицу. Операции над данными описываются реляционной алгеброй, на которой основан SQL.

NoSQL-хранилища применяют там, где реляционная модель неудобна или не масштабируется: кэширование и сессии (Redis), хранение документов с гибкой или меняющейся структурой (MongoDB — каталоги товаров, профили), большие объёмы записей с горизонтальным масштабированием (Cassandra — логи, события, IoT), полнотекстовый поиск (Elasticsearch), аналитика по большим объёмам (ClickHouse), графы связей (Neo4j — соцсети, рекомендации, антифрод). Обычно жертвуют строгой согласованностью или сложными JOIN ради скорости и масштабируемости.

Реляционные хранят данные в таблицах со строгой схемой, связи — через внешние ключи, язык — SQL, поддерживают ACID-транзакции и сложные JOIN, масштабируются в основном вертикально. Нереляционные хранят данные иначе: документы JSON/BSON (MongoDB), пары ключ–значение (Redis), строки с динамическим набором колонок (Cassandra), узлы и рёбра графа (Neo4j). У них гибкая схема или её отсутствие, они проще масштабируются горизонтально, но часто предлагают eventual consistency и ограниченные транзакции (модель BASE). Выбор зависит от структуры данных, требований к согласованности и нагрузке.

Нормализация — процесс приведения структуры таблиц к нормальным формам, чтобы устранить избыточность данных и аномалии вставки, обновления и удаления. Данные разбиваются на несколько связанных таблиц так, чтобы каждый факт хранился в одном месте. Пример: вместо хранения адреса клиента в каждой строке заказа выносим клиентов в отдельную таблицу и ссылаемся на неё по client_id. Плата за нормализацию — больше JOIN при чтении.

• 1НФ — все атрибуты атомарны (в ячейке одно значение, нет списков и повторяющихся групп), у таблицы есть первичный ключ.
• 2НФ — таблица в 1НФ, и каждый неключевой атрибут полностью зависит от всего составного ключа, а не от его части. Например, в таблице (order_id, product_id, product_name, qty) название товара зависит только от product_id — его выносят в таблицу товаров.
• 3НФ — таблица во 2НФ и нет транзитивных зависимостей: неключевые атрибуты не зависят от других неключевых. Например, city_name зависит от city_id, а не от client_id — выносим в справочник городов.

Далее идут НФБК (нормальная форма Бойса–Кодда), 4НФ и 5НФ.

Денормализация — намеренное добавление избыточности (дублирование данных, хранение вычисленных значений, объединение таблиц) ради ускорения чтения. Используется, когда запросы с большим количеством JOIN становятся узким местом: в отчётах и аналитических хранилищах (схемы «звезда», «снежинка»), для часто читаемых агрегатов (например, поле total_amount в заказе), в кэшах и витринах данных. Плата — сложнее поддерживать согласованность при изменениях (триггеры, фоновые пересчёты), больше места на диске.

Один к одному (1:1) — одной записи соответствует не более одной записи другой таблицы (пользователь — паспорт), реализуется внешним ключом с ограничением уникальности. Один ко многим (1:N) — самый частый вид (клиент — заказы), внешний ключ хранится на стороне «многих». Многие ко многим (M:N) — студенты и курсы, реализуется через промежуточную таблицу. Также связи бывают обязательными и необязательными (NULL во внешнем ключе допустим или нет).

Через промежуточную (связующую, ассоциативную) таблицу, которая содержит внешние ключи на обе таблицы; обычно пара этих ключей образует составной первичный ключ. В связующей таблице можно хранить и атрибуты самой связи, например дату записи или оценку.

CREATE TABLE student_course (
  student_id INT REFERENCES student(id),
  course_id  INT REFERENCES course(id),
  enrolled_at DATE,
  PRIMARY KEY (student_id, course_id)
);

Первичный ключ (Primary Key) — столбец или набор столбцов, однозначно идентифицирующий каждую строку таблицы. Свойства: уникальность (нет двух одинаковых значений), NOT NULL (не может быть пустым), один на таблицу (хотя может быть составным), желательно — неизменяемость и минимальность. Обычно по нему автоматически строится уникальный индекс. Ключи бывают естественными (ИНН, номер паспорта) и суррогатными (автоинкрементный id, UUID); на практике чаще используют суррогатные, потому что естественные могут меняться.

Транзакция — логическая единица работы с БД: набор операций, который выполняется целиком или не выполняется вообще. Классический пример — перевод денег: списание с одного счёта и зачисление на другой должны пройти вместе; если одна операция упала, всё откатывается.

BEGIN;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT; -- при ошибке выполняется ROLLBACK

Транзакции обеспечивают свойства ACID.

• Atomicity (атомарность) — транзакция выполняется полностью или не выполняется вовсе.
• Consistency (согласованность) — после транзакции БД остаётся в корректном состоянии, все ограничения целостности соблюдены.
• Isolation (изолированность) — параллельные транзакции не влияют друг на друга (степень задаётся уровнем изоляции: Read Uncommitted, Read Committed, Repeatable Read, Serializable).
• Durability (долговечность) — результат зафиксированной транзакции сохраняется даже при сбое.

ACID характерен для реляционных СУБД; многие NoSQL-системы следуют более мягкой модели BASE.

Обычно в три этапа. Концептуальное проектирование: по требованиям выделяем сущности предметной области и связи между ними, без привязки к СУБД. Логическое: описываем атрибуты, ключи, кардинальность связей, проводим нормализацию (ER-диаграмма). Физическое: под конкретную СУБД выбираем типы данных, индексы, ограничения, партиционирование, пишем DDL-скрипты. После этого проверяем модель на реальных сценариях и запросах, оцениваем объёмы и нагрузку.

Создание подходящих индексов и удаление лишних; оптимизация запросов (анализ плана через EXPLAIN, отказ от SELECT *, правильные JOIN и фильтры); денормализация и материализованные представления для тяжёлых отчётов; партиционирование больших таблиц; кэширование (Redis); репликация для разгрузки чтения и шардирование для масштабирования записи; архивирование старых данных; пакетная обработка вместо построчной; пул соединений и настройка параметров СУБД; обслуживание (VACUUM, обновление статистики).

Партиционирование — разделение одной большой таблицы на части (партиции) внутри одного сервера БД, при этом для приложения таблица остаётся единой. Запросы с фильтром по ключу партиционирования читают только нужные партиции, а старые данные можно быстро удалить или заархивировать целой партицией. Принципы: по диапазону (range, например по месяцам даты создания), по списку (list, например по региону), по хешу (hash, равномерное распределение по id). Бывает также вертикальное партиционирование — разнесение столбцов по разным таблицам.

Репликация — копирование данных с одного сервера БД на другие (реплики) и поддержание копий в актуальном состоянии. Цели: отказоустойчивость (при падении основного сервера переключаемся на реплику), масштабирование чтения (запросы на чтение идут на реплики), резервирование и географическое распределение. Схемы: master–slave (leader–follower — запись в один узел, чтение с реплик) и master–master (запись в несколько узлов). Репликация бывает синхронной (надёжнее, медленнее) и асинхронной (быстрее, но возможно отставание реплик).

Шардирование — горизонтальное разделение данных между несколькими независимыми серверами (шардами): каждый шард хранит свою часть строк. Распределение идёт по ключу шардирования, например по хешу user_id или по региону. Это позволяет масштабировать и хранение, и запись сверх возможностей одного сервера. Сложности: запросы и транзакции между шардами, JOIN по данным с разных шардов, перебалансировка при добавлении узлов, правильный выбор ключа, чтобы не было «горячих» шардов.

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

Маппинг данных — описание соответствия полей между двумя структурами: источником и приёмником (две системы, API и БД, старая и новая модель при миграции). Для каждого поля указывают поле-источник, поле-приёмник, типы, обязательность, правила преобразования (форматы дат, справочники, конкатенация, значения по умолчанию). Пример строки: «CRM.client.birth_date (DD.MM.YYYY) → Billing.customer.birthDate (ISO 8601, YYYY-MM-DD), обязательное». Маппинг обычно оформляют таблицей и он является ключевым артефактом при описании интеграций и миграций.

В проектировании данных выделяют три уровня моделей. Концептуальная — основные сущности предметной области и связи между ними, понятна бизнесу, без технических деталей. Логическая — атрибуты, ключи, типы связей, нормализация, ещё не привязана к конкретной СУБД. Физическая — реализация в конкретной СУБД: таблицы, типы данных, индексы, ограничения, партиции. Также есть классическая трёхуровневая архитектура ANSI/SPARC: внешний уровень (представления для пользователей), концептуальный (общая схема) и внутренний (физическое хранение).

Индекс — дополнительная структура данных (чаще всего B-дерево, также хеш, GIN, bitmap), которая ускоряет поиск строк по значению столбцов, примерно как предметный указатель в книге. Без индекса СУБД сканирует всю таблицу. Индексы ускоряют WHERE, JOIN, ORDER BY, но замедляют вставку и обновление и занимают место, поэтому их создают под реальные частые запросы. Первичный ключ и UNIQUE индексируются автоматически.

CREATE INDEX idx_orders_client_date ON orders (client_id, created_at);

Грязное чтение (dirty read) — ситуация, когда транзакция читает данные, изменённые другой транзакцией, которая ещё не зафиксирована. Если вторая транзакция потом откатится, первая будет работать с данными, которых «никогда не было». Это возможно только на уровне изоляции Read Uncommitted; уже на Read Committed (уровень по умолчанию в PostgreSQL и Oracle) оно исключено. Другие аномалии параллельного доступа — неповторяющееся чтение, фантомное чтение и потерянное обновление.

Команды делятся на группы: DDL (CREATE, ALTER, DROP, TRUNCATE — структура), DML (SELECT, INSERT, UPDATE, DELETE, MERGE — данные; SELECT иногда выделяют в DQL), DCL (GRANT, REVOKE — права), TCL (BEGIN, COMMIT, ROLLBACK, SAVEPOINT — транзакции). Аналитику middle-уровня полезно уверенно писать запросы с несколькими JOIN, группировкой и HAVING, подзапросами, CTE (WITH), оконными функциями и CASE.

WITH paid AS (
  SELECT client_id, SUM(amount) AS total
  FROM orders
  WHERE status = 'PAID' AND created_at >= DATE '2025-01-01'
  GROUP BY client_id
)
SELECT c.name, p.total,
       RANK() OVER (ORDER BY p.total DESC) AS rnk
FROM paid p
JOIN client c ON c.id = p.client_id;

JOIN объединяет строки двух таблиц по условию связи. Виды:

• INNER JOIN — только строки, у которых есть пара в обеих таблицах;
• LEFT (OUTER) JOIN — все строки левой таблицы, из правой — совпадения или NULL;
• RIGHT (OUTER) JOIN — зеркально, все строки правой;
• FULL (OUTER) JOIN — все строки обеих таблиц, недостающие — NULL;
• CROSS JOIN — декартово произведение, каждая строка с каждой;
• SELF JOIN — соединение таблицы с самой собой (например, сотрудник и его руководитель).

SELECT c.name, o.id
FROM client c
LEFT JOIN orders o ON o.client_id = c.id;

DELETE — DML-команда: удаляет строки построчно, поддерживает WHERE, вызывает триггеры, каждое удаление пишется в журнал, её можно откатить в транзакции. TRUNCATE — DDL-команда: очищает таблицу целиком без условий, работает намного быстрее (освобождает страницы данных), обычно сбрасывает счётчики автоинкремента и не вызывает построчные триггеры. Откатить TRUNCATE можно не во всех СУБД (в PostgreSQL можно внутри транзакции, в Oracle нельзя). TRUNCATE может быть запрещён, если на таблицу ссылаются внешние ключи.

HAVING фильтрует результаты после группировки (GROUP BY), то есть накладывает условия на агрегированные значения — COUNT, SUM, AVG и т.п. Например, найти клиентов, у которых больше пяти заказов:

SELECT client_id, COUNT(*) AS cnt
FROM orders
GROUP BY client_id
HAVING COUNT(*) > 5;

WHERE фильтрует отдельные строки до группировки и не может содержать агрегатных функций. HAVING фильтрует группы после GROUP BY и работает с агрегатами. Логический порядок выполнения: FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT. Если условие можно поставить в WHERE, лучше так и сделать — меньше строк попадёт в группировку.

SELECT client_id, SUM(amount)
FROM orders
WHERE status = 'PAID'          -- фильтр строк
GROUP BY client_id
HAVING SUM(amount) > 10000;     -- фильтр групп

Основные способы (на примере клиентов без заказов):

-- 1. LEFT JOIN + IS NULL
SELECT c.* FROM client c
LEFT JOIN orders o ON o.client_id = c.id
WHERE o.client_id IS NULL;

-- 2. NOT EXISTS
SELECT c.* FROM client c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.client_id = c.id);

-- 3. NOT IN
SELECT c.* FROM client c
WHERE c.id NOT IN (SELECT o.client_id FROM orders o WHERE o.client_id IS NOT NULL);

-- 4. EXCEPT (в Oracle — MINUS), сравнивает целые строки
SELECT id FROM client
EXCEPT
SELECT client_id FROM orders;

Важно: NOT IN ведёт себя неожиданно, если подзапрос возвращает NULL, — результат будет пустым, поэтому NULL нужно отфильтровать или использовать NOT EXISTS.

Оба оператора объединяют результаты двух запросов с одинаковым количеством и совместимыми типами столбцов. UNION удаляет дубликаты строк (для этого выполняет сортировку или хеширование, поэтому медленнее). UNION ALL возвращает все строки как есть, включая повторы, и работает быстрее. Если дубликатов быть не может или они нужны, следует использовать UNION ALL.

SELECT email FROM client
UNION ALL
SELECT email FROM partner;

При синхронном взаимодействии клиент отправляет запрос и ждёт ответа, прежде чем продолжить работу (типичный REST-вызов, gRPC unary). При асинхронном клиент отправляет сообщение и продолжает работу, не дожидаясь результата; ответ, если он нужен, приходит позже — через очередь, callback, webhook или опрос статуса. Синхронный способ проще и даёт немедленный результат, но создаёт жёсткую связанность: если сервер медленный или недоступен, клиент тоже страдает. Асинхронный повышает устойчивость и позволяет сглаживать пики нагрузки, но усложняет отслеживание состояния, обработку ошибок и отладку.

В синхронном взаимодействии ответ есть всегда — хотя бы технический: код состояния, ошибка или таймаут, иначе клиент будет ждать бесконечно. В асинхронном бизнес-ответ не обязателен: многие сценарии работают по принципу fire-and-forget (отправили событие в Kafka и забыли). При этом часто есть техническое подтверждение (ack от брокера или HTTP 202 Accepted), а результат обработки, если он нужен, приходит отдельным сообщением или через callback. Нужен ли ответ, аналитик фиксирует в описании интеграции.

Типичный пример — проверка данных, без результата которой нельзя продолжить пользовательский сценарий. Скажем, при оформлении заказа фронтенд синхронно вызывает сервис расчёта стоимости доставки (GET /delivery/price?city=…&weight=…) и сразу показывает цену; ждать асинхронного ответа здесь бессмысленно. Другие примеры: авторизация пользователя, проверка остатка на счёте перед списанием, поиск клиента по номеру телефона в CRM, получение справочника. В таких постановках важно описать таймаут и поведение при недоступности сервиса.

Очередь (брокер сообщений) развязывает отправителя и получателя во времени: отправитель кладёт сообщение и не зависит от доступности получателя. Очередь буферизует нагрузку при пиках (получатель обрабатывает в своём темпе), гарантирует доставку (сообщения хранятся до подтверждения обработки), позволяет масштабировать обработку несколькими потребителями и делать повторы при ошибках (retry, dead letter queue). Также через очереди одно событие легко доставить нескольким подписчикам.

Обычно синхронный: клиент вызывает процедуру и ждёт результата выполнения (данных, кода возврата или ошибки), соединение заблокировано до окончания вызова. Асинхронной работа с БД становится, только если это специально организовано: например, процедура лишь ставит задание в таблицу-очередь или запускает фоновую задачу (job), а результат забирают позже. Также асинхронные драйверы на стороне приложения не блокируют поток, но с точки зрения протокола это всё равно запрос–ответ.

API (Application Programming Interface) — программный интерфейс, набор правил и контрактов, по которым одна программа может обращаться к другой: какие операции доступны, какие данные передать и что вернётся в ответ. API скрывает внутреннюю реализацию и даёт стабильную точку интеграции. Применяется для взаимодействия фронтенда и бэкенда, интеграции систем внутри компании и с партнёрами (платёжные шлюзы, службы доставки), построения микросервисов, предоставления данных внешним разработчикам. Виды: REST, SOAP, GraphQL, gRPC, а также API библиотек и операционной системы.

REST (Representational State Transfer) — архитектурный стиль взаимодействия распределённых систем, описанный Роем Филдингом в 2000 году. Это не протокол и не стандарт, а набор ограничений: клиент-серверная архитектура, отсутствие состояния (stateless), кэшируемость, единообразный интерфейс, многоуровневая система, код по требованию (необязательно). На практике REST реализуется поверх HTTP: данные представлены как ресурсы с URL, операции — HTTP-методы, формат чаще всего JSON.

GET /api/v1/orders/123
200 OK
{"id": 123, "status": "PAID", "amount": 1500}

RESTful-приложение (сервис) — это приложение, API которого соответствует ограничениям REST: ресурсы адресуются через URI (/clients/42/orders), операции выражены стандартными методами HTTP, сервер не хранит состояние клиента между запросами, ответы помечаются как кэшируемые или нет, используются корректные коды состояния. Высшая ступень по модели зрелости Ричардсона — HATEOAS, когда ответ содержит ссылки на возможные следующие действия. На практике многие API называют REST-ом, хотя они соответствуют стилю лишь частично.

Stateless означает, что сервер не хранит контекст клиента (сессию) между запросами: каждый запрос самодостаточен и содержит всё необходимое — токен авторизации, параметры, идентификаторы. Точнее говорить, что это сервер освобождён от хранения состояния клиента. Это нужно для масштабируемости: любой экземпляр сервиса может обработать любой запрос, балансировщик распределяет нагрузку свободно, падение одного узла не теряет сессии. Также упрощается кэширование и отладка. Состояние приложения при этом хранится у клиента или в общей БД/кэше, а не в памяти конкретного сервера.

Кэширование — сохранение результатов запросов или вычислений во временном быстром хранилище, чтобы при повторном обращении отдавать их без повторной обработки. Цели: уменьшить время ответа, снизить нагрузку на сервер и БД, сократить трафик. Примеры: кэш справочников в Redis, кэш статических файлов в браузере и CDN, HTTP-кэширование по заголовкам. Главная сложность — инвалидация: нужно решить, сколько данные живут в кэше (TTL) и как обновлять их при изменении, чтобы не показывать устаревшую информацию.

И там, и там, а также посередине. На клиенте — кэш браузера или мобильного приложения, управляемый HTTP-заголовками Cache-Control, ETag, Last-Modified. На промежуточных узлах — CDN, reverse proxy (Nginx), API Gateway. На сервере — кэш в памяти приложения, распределённый кэш (Redis, Memcached), кэш запросов и буферы в СУБД. Выбор уровня зависит от данных: статику и редко меняющиеся справочники кэшируют ближе к клиенту, персональные и часто меняющиеся данные — на сервере или не кэшируют совсем.

• GET — получение ресурса или списка (GET /orders?status=NEW);
• POST — создание ресурса или выполнение действия (POST /orders);
• PUT — полная замена ресурса (PUT /orders/1);
• PATCH — частичное изменение (PATCH /orders/1 {"status":"CANCELLED"});
• DELETE — удаление (DELETE /orders/1);
• HEAD — как GET, но только заголовки (проверить существование, размер);
• OPTIONS — какие методы поддерживает ресурс (используется в CORS preflight).

Строго говоря, это методы HTTP, которые REST использует для операций над ресурсами.

• Path-параметры — часть URL, идентифицируют ресурс: /clients/42;
• Query-параметры — после знака вопроса, для фильтрации, сортировки, пагинации: /orders?status=NEW&page=2;
• Тело запроса (body) — JSON, XML, form-data для POST, PUT, PATCH;
• Заголовки (headers) — служебная информация: Authorization, Content-Type, Accept-Language, Idempotency-Key;
• Cookies — реже, например для сессий в браузере.

Конфиденциальные данные не передают в query, так как URL попадает в логи и историю браузера.

URL состоит из частей: схема (протокол: https), хост (домен или IP: api.shop.ru), порт (необязательно, :443), путь к ресурсу (/api/v1/clients/42/orders), query-параметры (?status=NEW&limit=20) и иногда фрагмент (#section, на сервер не передаётся). В REST путь обычно включает версию API и иерархию ресурсов, названных существительными во множественном числе.

https://api.shop.ru:443/api/v1/clients/42/orders?status=NEW&limit=20

Заголовки ответа содержат метаданные: Content-Type (формат тела, application/json; charset=utf-8), Content-Length (размер), Cache-Control, ETag, Last-Modified (кэширование), Location (адрес созданного ресурса при 201 или редиректе), Set-Cookie, WWW-Authenticate (при 401), Retry-After (при 429/503), заголовки CORS (Access-Control-Allow-Origin), Date, Server, а также кастомные — например X-Request-Id для трассировки или X-RateLimit-Remaining. Код состояния передаётся в строке статуса, а не в заголовке.

Оба кода — не ошибки, а успешные ответы группы 2xx. 200 OK — запрос успешно обработан, результат в теле ответа (типично для GET, PUT, PATCH). 201 Created — в результате запроса создан новый ресурс (типично для POST); хорошая практика — вернуть в заголовке Location адрес нового ресурса, а в теле — сам ресурс или его id. Для полноты: 202 Accepted — запрос принят на асинхронную обработку, 204 No Content — успех без тела (часто для DELETE).

GET предназначен для получения данных: параметры передаются в URL, тела обычно нет, метод безопасный (не меняет состояние) и идемпотентный, ответ можно кэшировать, URL можно сохранить в закладки. POST предназначен для создания ресурсов или выполнения действий: данные передаются в теле запроса, метод не идемпотентный (повтор может создать дубликат), по умолчанию не кэшируется. Длина URL ограничена, поэтому объёмные или конфиденциальные данные передают через POST.

PUT заменяет ресурс целиком: клиент передаёт полное представление, и поля, которые не переданы, могут быть очищены или сброшены. PATCH изменяет ресурс частично: передаются только изменяемые поля. PUT по спецификации идемпотентен; PATCH в общем случае не обязан быть идемпотентным (например, операция «увеличить счётчик на 1»), хотя часто реализуется так.

PUT /clients/42   {"name": "Иван", "phone": "+79001234567", "email": "i@mail.ru"}
PATCH /clients/42 {"phone": "+79007654321"}

POST обычно используется для создания ресурса в коллекции, когда идентификатор назначает сервер (POST /orders → 201 и id=123), и не идемпотентен: два одинаковых запроса создадут два заказа. PUT отправляется на конкретный URI ресурса и создаёт или полностью заменяет его (PUT /orders/123); он идемпотентен — повтор даёт тот же результат. PUT можно использовать для создания, если идентификатор знает клиент (например, UUID, сгенерированный на клиенте).

Идемпотентная операция — такая, повторное выполнение которой с теми же параметрами даёт тот же результат на сервере, что и однократное. В HTTP идемпотентны GET, HEAD, OPTIONS, PUT, DELETE; POST и в общем случае PATCH — нет. Это важно для надёжности интеграций: в сети бывают таймауты и обрывы, и клиент не знает, дошёл ли запрос. Если операция идемпотентна, её можно безопасно повторить (retry), не опасаясь двойного списания денег или дубля заказа. Поэтому в постановках на интеграции аналитик явно описывает поведение при повторной отправке.

Да. После первого DELETE /orders/1 ресурс удалён, и последующие такие же запросы не меняют состояние сервера — ресурса как не было, так и нет. При этом коды ответов могут отличаться: первый вызов вернёт 200 или 204, повторный — 404 Not Found, и это не нарушает идемпотентность, так как она определяется эффектом на сервере, а не ответом. Некоторые API для удобства клиентов и на повтор возвращают 204.

Самый распространённый способ — ключ идемпотентности: клиент генерирует уникальный идентификатор операции (UUID) и передаёт его в заголовке, например Idempotency-Key. Сервер сохраняет ключ вместе с результатом; при повторе с тем же ключом он не выполняет операцию заново, а возвращает сохранённый ответ. Альтернативы — проверка уникальности по бизнес-ключу (номер внешнего заказа с уникальным ограничением в БД) или создание ресурса через PUT с идентификатором, сгенерированным клиентом.

POST /payments
Idempotency-Key: 6f1c2a9e-4b7d-4e1a-9c3f-2d5e8a7b1c00
Content-Type: application/json

{"orderId": 123, "amount": 1500}

Технически можно, и на практике так делают: когда параметры поиска слишком сложные или объёмные для query-строки (длинные списки id, вложенные фильтры), когда параметры конфиденциальны и не должны попадать в URL и логи, а также в RPC-подобных API, GraphQL и SOAP, где всё идёт через POST. Например, POST /orders/search с фильтром в теле. Минусы: теряется семантика REST, ответ по умолчанию не кэшируется, запрос формально не идемпотентный. Поэтому для обычного чтения правильно использовать GET.

Обратная совместимость — когда существующие клиенты продолжают работать после изменения API. Совместимые изменения: добавление необязательных полей в запрос, новых полей в ответ, новых методов и эндпоинтов, новых необязательных параметров. Клиенты при этом должны игнорировать незнакомые поля. Новая версия нужна при ломающих изменениях: удаление или переименование полей, смена типа или формата, новое обязательное поле в запросе, изменение смысла поля или кодов ответов. Версию указывают в URL (/api/v2/…), в заголовке или параметре; старую версию поддерживают параллельно и выводят из эксплуатации по графику, предупредив клиентов.

JSON Schema — стандарт описания структуры JSON-документа: какие поля есть, их типы, обязательность, форматы, ограничения (длина, диапазон, шаблон, перечисление). Используется для валидации запросов и ответов, документирования контрактов API, генерации кода и тестов; на ней основано описание моделей в OpenAPI. Пример:

{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id":     {"type": "integer"},
    "email":  {"type": "string", "format": "email"},
    "status": {"type": "string", "enum": ["NEW", "ACTIVE", "BLOCKED"]}
  },
  "additionalProperties": false
}

HTML — язык разметки для отображения веб-страниц: набор тегов фиксирован (<p>, <div>, <table>), он описывает, как показать содержимое, и браузер прощает многие ошибки (незакрытые теги). XML — расширяемый язык разметки для хранения и передачи данных: теги придумывает автор под предметную область (<order>, <client>), он описывает смысл и структуру данных, а синтаксис строгий — документ должен быть правильно сформирован (well-formed), иначе парсер выдаст ошибку. XML чувствителен к регистру и может проверяться по схеме XSD.

XML-документ содержит: необязательный пролог (объявление версии и кодировки), ровно один корневой элемент, вложенные элементы с открывающими и закрывающими тегами, атрибуты элементов, текстовое содержимое, а также могут быть комментарии, секции CDATA, инструкции обработки, объявления пространств имён и ссылки на сущности (&lt; и т.п.).

<?xml version="1.0" encoding="UTF-8"?>
<order id="123" xmlns="http://shop.ru/order">
  <!-- комментарий -->
  <client>Иванов</client>
  <amount currency="RUB">1500.00</amount>
</order>

XSD (XML Schema Definition) — язык описания структуры XML-документа, сам записанный в XML. Схема определяет допустимые элементы и атрибуты, их порядок и количество (minOccurs, maxOccurs), типы данных (string, int, date, decimal), ограничения (длина, шаблон, перечисление) и пространство имён. По XSD проверяют, что входящее сообщение корректно, и генерируют классы; XSD входит в WSDL SOAP-сервиса. Фрагмент:

<xs:element name="order">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="client" type="xs:string"/>
      <xs:element name="amount" type="xs:decimal" minOccurs="1"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:int" use="required"/>
  </xs:complexType>
</xs:element>

Пространство имён (namespace) — механизм, позволяющий избежать конфликтов одинаковых имён элементов из разных словарей. Оно задаётся уникальным URI через атрибут xmlns, обычно с префиксом: xmlns:ord="http://shop.ru/order". Тогда <ord:id> и <cl:id> — разные элементы, хотя оба называются id. URI — это просто идентификатор, по нему не обязательно что-то открывается. В SOAP пространства имён используются постоянно: для конверта (soap:Envelope) и для элементов бизнес-сообщения.

Для просмотра и редактирования — любые редакторы с подсветкой: VS Code, Notepad++ (с плагином XML Tools), IntelliJ IDEA, специализированные XMLSpy и Oxygen XML Editor (умеют валидировать по XSD, строить схемы, XPath, XSLT). Для тестирования SOAP-сервисов — SoapUI и Postman. Браузеры отображают XML-дерево. Для обработки в коде — библиотеки парсинга (DOM, SAX), XPath для поиска и XSLT для преобразований; также онлайн-валидаторы и форматтеры.

SOAP (Simple Object Access Protocol) — протокол обмена структурированными сообщениями в формате XML, стандартизированный W3C. Контракт сервиса строго описан в WSDL, сообщения проверяются по XSD. Обычно работает поверх HTTP (метод POST), но может и поверх SMTP, JMS. Имеет расширения стандартов WS-* (WS-Security для подписи и шифрования, WS-ReliableMessaging и др.). Встречается в банках, госсистемах (СМЭВ), страховании, корпоративных интеграциях и legacy-системах, где важны строгий контракт и безопасность.

SOAP-сообщение — XML-документ с элементами: Envelope (конверт, обязательный корневой элемент), Header (необязательный заголовок — метаданные, безопасность, идентификаторы транзакций), Body (обязательное тело с данными запроса или ответа), Fault (внутри Body, если произошла ошибка: код, описание, детали).

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header/>
  <soap:Body>
    <getClient xmlns="http://crm.ru/ws">
      <clientId>42</clientId>
    </getClient>
  </soap:Body>
</soap:Envelope>

WSDL (Web Services Description Language) — XML-документ, описывающий контракт SOAP-сервиса: какие операции он поддерживает, какие сообщения принимает и возвращает, по какому протоколу и адресу доступен. Основные разделы (WSDL 1.1): types (типы данных, обычно XSD), message (сообщения), portType (операции), binding (протокол и формат), service (адрес эндпоинта). По WSDL можно автоматически сгенерировать клиентский код или тестовый проект в SoapUI.

SOAP — протокол со строгими правилами, REST — архитектурный стиль. SOAP использует только XML и формальный контракт WSDL; REST допускает любой формат (чаще JSON), а контракт описывается опционально (OpenAPI). SOAP обычно работает через POST на один эндпоинт с операциями в теле, REST использует разные HTTP-методы и URL ресурсов. SOAP тяжелее и медленнее, но имеет встроенные стандарты безопасности и надёжности (WS-*); REST проще, легче, лучше кэшируется и подходит для веба и мобильных клиентов. SOAP выбирают в корпоративных и государственных интеграциях со строгими требованиями, REST — в большинстве современных сервисов.

Очереди нужны, когда: получатель может быть недоступен или медленнее отправителя; нужна гарантированная доставка; одно событие должны получить несколько систем (публикация событий «заказ создан»); нужно сгладить пиковую нагрузку; операция долгая и пользователь не должен её ждать (генерация отчёта, отправка писем); нужна слабая связанность микросервисов. Популярные брокеры — Apache Kafka, RabbitMQ, ActiveMQ, IBM MQ, облачные (Amazon SQS, Yandex Message Queue).

RabbitMQ — классический брокер сообщений (протокол AMQP): гибкая маршрутизация через exchange (direct, topic, fanout, headers), сообщение после подтверждения обработки удаляется из очереди, брокер сам «проталкивает» сообщения потребителям. Хорош для задач, команд, сложной маршрутизации. Kafka — распределённый журнал событий: сообщения записываются в партиции топика и хранятся заданное время независимо от прочтения, потребители сами читают (pull) и отслеживают смещение (offset), можно перечитывать историю. Kafka рассчитана на очень высокую пропускную способность и потоковую обработку, гарантирует порядок внутри партиции. Коротко: RabbitMQ — «умный брокер, простой потребитель», Kafka — «простой брокер, умный потребитель».

Механизмы: подтверждения от брокера отправителю (publisher confirms в RabbitMQ, acks=all в Kafka) и от потребителя брокеру (ack после обработки; без ack сообщение будет доставлено повторно); персистентность — запись сообщений на диск; репликация между узлами кластера; повторные попытки и dead letter queue для сообщений, которые не удалось обработать. Различают семантики доставки: at-most-once (не больше одного раза, возможна потеря), at-least-once (минимум один раз, возможны дубли — нужна идемпотентность потребителя) и exactly-once (ровно один раз, сложнее и дороже, в Kafka — через транзакции).

В Kafka сообщения не удаляются после прочтения, а потребитель сам управляет позицией чтения — offset. Чтобы перечитать два последних сообщения, нужно сдвинуть offset назад на 2 в нужной партиции: в коде — вызвать seek(partition, currentOffset - 2), или для группы потребителей сбросить смещение командой kafka-consumer-groups с параметром --reset-offsets --shift-by -2 (группа при этом должна быть остановлена). Также можно не коммитить offset после чтения — тогда после перезапуска потребитель прочитает их снова. Это возможно, пока сообщения не удалены по политике хранения (retention).

kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group my-group --topic orders --reset-offsets --shift-by -2 --execute

Очередь (модель point-to-point) — каждое сообщение получает и обрабатывает только один потребитель из подключённых; после обработки сообщение удаляется. Так распределяют задачи между обработчиками. Топик (модель publish/subscribe) — сообщение получают все подписчики, каждый свою копию; так рассылают события нескольким системам. В Kafka топик хранит сообщения в журнале, и разные группы потребителей читают его независимо, а внутри одной группы партиции делятся между потребителями — получается поведение очереди.

Корпоративная сервисная шина (ESB, Enterprise Service Bus) — промежуточный слой интеграции, через который взаимодействуют системы предприятия вместо прямых связей «каждый с каждым». Шина выполняет маршрутизацию сообщений, преобразование форматов и протоколов (например, SOAP в REST, XML в JSON), оркестрацию вызовов, гарантированную доставку, мониторинг, логирование и безопасность. Примеры: IBM Integration Bus (App Connect), MuleSoft, Apache ServiceMix, WSO2, TIBCO, Oracle Service Bus. ESB — ключевой элемент SOA; минус — шина становится центральной точкой сложности и отказа.

Очередь (брокер сообщений) — транспорт: она надёжно хранит и передаёт сообщения от отправителя получателю, но обычно не меняет их содержимое и не знает бизнес-логики. Шина — более широкая интеграционная платформа: помимо транспорта (часто внутри неё и работают очереди) она маршрутизирует сообщения по правилам, трансформирует форматы, адаптирует протоколы, оркестрирует цепочки вызовов, обеспечивает мониторинг и безопасность. Можно сказать, что очередь — один из компонентов, на которых строится шина.

ESB предназначена для обмена сообщениями между приложениями в режиме, близком к реальному времени: отдельные транзакции и события (создан заказ, изменился клиент), синхронные и асинхронные вызовы сервисов. ETL (Extract, Transform, Load) предназначен для пакетного перемещения больших объёмов данных: извлечь из источников, преобразовать, очистить и загрузить, как правило, в хранилище данных для аналитики, обычно по расписанию. Примеры ETL: Informatica, Apache NiFi, Airflow (оркестрация), Pentaho, SSIS. Коротко: шина — интеграция процессов и сервисов, ETL — интеграция данных.

Это ломающее изменение контракта. Нужно понять, где появились поля. Если во входящем запросе сервиса, то все потребители, отправляющие запросы через шину, начнут получать ошибки валидации, пока не начнут передавать эти поля. Значит, нужно: обновить контракт (WSDL/XSD или OpenAPI) на шине, обновить маппинг и трансформации, определить источник данных для новых полей (передают системы-потребители или шина обогащает значениями по умолчанию или из справочника), согласовать изменения и сроки с командами-потребителями, протестировать. Чтобы не ломать клиентов, обычно выпускают новую версию сервиса и какое-то время поддерживают старую либо на шине подставляют значения по умолчанию. Если же поля добавились в ответ, то для потребителей, игнорирующих незнакомые поля, ничего не сломается, но при строгой XSD-валидации на стороне потребителя и здесь потребуется обновить схему.

GraphQL — язык запросов к API и среда выполнения, разработанные в Facebook. Сервер описывает строго типизированную схему данных, а клиент в одном запросе указывает, какие именно поля и связанные объекты ему нужны, и получает ровно их. Обычно один эндпоинт (POST /graphql) и три типа операций: query (чтение), mutation (изменение), subscription (подписка на события).

query {
  client(id: 42) {
    name
    orders(last: 3) { id amount status }
  }
}

GraphQL применяют, когда у разных клиентов (веб, мобильное приложение) разные потребности в данных, когда для одного экрана нужно собрать данные из многих ресурсов или сервисов (часто как слой BFF или шлюз над микросервисами), когда модель данных сильно связана. Плюсы относительно REST: нет избыточной (over-fetching) и недостаточной (under-fetching) выборки — клиент получает ровно нужные поля за один запрос; строгая схема с самодокументированием и интроспекцией; проще развивать API без версий — новые поля добавляются, старые помечаются deprecated. Минусы: сложнее кэширование на уровне HTTP, риск тяжёлых запросов (нужны ограничения глубины и сложности), сложнее мониторинг и обработка ошибок (часто всё возвращается с кодом 200).

WebSocket — протокол постоянного двунаправленного соединения между клиентом и сервером поверх TCP. Соединение открывается через HTTP-запрос с заголовком Upgrade, после чего обе стороны в любой момент могут отправлять сообщения без новых запросов (full-duplex), с минимальными накладными расходами. Применяется там, где нужны обновления в реальном времени: чаты и мессенджеры, уведомления, биржевые котировки, онлайн-игры, совместное редактирование, трекинг курьера на карте. Если сервер должен лишь изредка отправлять события клиенту, альтернатива попроще — Server-Sent Events или long polling.

gRPC — фреймворк удалённого вызова процедур от Google, работающий поверх HTTP/2. Контракт описывается в .proto-файлах (Protocol Buffers), сообщения передаются в компактном бинарном формате, клиентский и серверный код генерируются автоматически. Поддерживает обычные вызовы и потоковую передачу (серверный, клиентский и двунаправленный стриминг). Применяется для внутреннего взаимодействия микросервисов с высокой нагрузкой и требованиями к задержкам, в полиглотных системах, для стриминга. Для публичных и браузерных API используется реже, так как браузеры не поддерживают его напрямую (нужен gRPC-Web), а бинарные сообщения сложнее отлаживать.

service ClientService {
  rpc GetClient (GetClientRequest) returns (Client);
}
message GetClientRequest { int64 id = 1; }

Webhook — механизм обратного вызова: система-источник при наступлении события сама отправляет HTTP-запрос (обычно POST с JSON) на заранее зарегистрированный URL системы-получателя. Это «обратный API»: вместо того чтобы получатель постоянно опрашивал источник («есть ли новые платежи?»), источник сам уведомляет его. Применяется для уведомлений о событиях во внешних сервисах: смена статуса платежа в платёжном шлюзе, новый коммит в GitHub, сообщение в Telegram-боте, изменение заказа у службы доставки.

POST https://shop.ru/webhooks/payment
{"event": "payment.succeeded", "paymentId": "p_789", "orderId": 123}

Плюсы: события доставляются почти в реальном времени; нет лишней нагрузки от постоянного опроса (polling); просто реализовать — нужен лишь HTTP-эндпоинт. Минусы: получатель должен иметь публично доступный URL и быть доступен в момент отправки; при сбое события могут потеряться, если источник не делает повторов; возможны дубли и нарушение порядка, поэтому обработчик должен быть идемпотентным; нужно защищать эндпоинт (проверка подписи HMAC, секретный токен, белый список IP); сложнее отлаживать. Хорошая практика — быстро отвечать 200 и обрабатывать событие асинхронно, а также иметь возможность сверки через обычный API.

Файловый обмен — интеграция, при которой одна система выгружает данные в файл (CSV, XML, JSON, Excel, фиксированный формат), а другая его забирает и загружает — через общую сетевую папку, FTP/SFTP, объектное хранилище S3 или электронную почту. Обычно работает по расписанию пакетами. Применяется, когда нужно передать большие объёмы данных разом (выгрузки, реестры платежей, прайс-листы), когда одна из систем устаревшая и не имеет API, для обмена с банками и госорганами по регламентированным форматам, для ночных загрузок в хранилище данных и когда актуальность в реальном времени не требуется.

Плюсы: простота и универсальность (почти любая система умеет читать и писать файлы), эффективность для больших объёмов, слабая связанность систем (не нужно, чтобы обе были доступны одновременно), файл легко сохранить для аудита и повторной загрузки. Минусы: данные устаревают между выгрузками (нет реального времени), сложная обработка ошибок (частично загруженный файл, ошибка в одной строке), нужен контроль формата, кодировок и разделителей, контроль повторной загрузки одного файла, вопросы безопасности при хранении и передаче, сложнее мониторинг. Для надёжности используют контрольные суммы, файлы-маркеры готовности и уникальные имена с датой.

Клиент-серверная архитектура — модель, в которой функции разделены между клиентами, инициирующими запросы, и серверами, которые эти запросы обрабатывают и предоставляют ресурсы или услуги. Клиент (браузер, мобильное приложение) отвечает за интерфейс и отправку запросов, сервер — за бизнес-логику, хранение данных и безопасность. Варианты: двухзвенная (клиент — сервер БД) и трёхзвенная (клиент — сервер приложений — сервер БД), а также многозвенная. Плюсы — централизованное управление данными и логикой, минусы — сервер становится узким местом и точкой отказа, если его не масштабировать.

Архитектурные стили и паттерны: монолитная (в том числе модульный монолит), многослойная (presentation — business — data), клиент-серверная, сервис-ориентированная (SOA), микросервисная, событийно-ориентированная (EDA), бессерверная (serverless), гексагональная (порты и адаптеры) и «чистая архитектура», пространственная (space-based), peer-to-peer. На реальных проектах обычно встречается комбинация: например, микросервисы на REST и Kafka с API Gateway, рядом legacy-монолит, а интеграция с внешними системами идёт через ESB. На собеседовании полезно уметь нарисовать схему своего проекта и объяснить, почему он так устроен.

Обе строятся из сервисов, но различаются масштабом и способом взаимодействия. В SOA сервисы обычно крупные, ориентированы на переиспользование в масштабах всего предприятия, часто разделяют общую БД и общаются через центральную корпоративную шину (ESB), где сосредоточены маршрутизация и трансформации («умная шина»). Микросервисы мельче, построены вокруг конкретной бизнес-возможности, каждый владеет своей базой данных, разворачивается и масштабируется независимо, взаимодействуют через лёгкие протоколы (REST, gRPC, брокеры сообщений) по принципу «умные конечные точки, глупые каналы». Микросервисы можно считать эволюцией идей SOA.

• По бизнес-возможностям (business capability) — сервис на каждую функцию бизнеса: заказы, платежи, доставка, каталог;
• По поддоменам DDD (bounded context) — границы сервисов совпадают с ограниченными контекстами предметной области, у каждого свой язык и модель;
• По бизнес-процессам или сценариям (use case);
• По ресурсам или сущностям — сервис клиентов, сервис товаров (рискует дать слишком мелкие и связанные сервисы);
• По командам (закон Конвея) — сервис принадлежит одной команде;
• Strangler fig — постепенное выделение сервисов из монолита.

Чаще всего на практике сочетают декомпозицию по бизнес-возможностям и по DDD.

Независимость означает, что каждый микросервис можно разрабатывать, тестировать, развёртывать, масштабировать и выводить из строя, не затрагивая остальные. Это обеспечивается собственной базой данных (никто не лезет в чужие таблицы), общением только через публичные контракты API и события, отдельным циклом релизов и CI/CD, свободой выбора технологий, владением сервисом одной командой. Также важна изоляция отказов: падение одного сервиса не должно ронять всю систему (таймауты, circuit breaker, асинхронность). Если для изменения одного сервиса нужно одновременно релизить три других — это «распределённый монолит».

Монолит — единое приложение с общей кодовой базой и обычно одной БД, разворачивается целиком. Плюсы: проще разработка, тестирование, отладка и развёртывание, нет сетевых задержек между модулями, простые транзакции. Минусы: со временем растёт связанность, долгие сборки и релизы, масштабировать можно только целиком, одна ошибка может уронить всё. Микросервисы — набор независимых сервисов. Плюсы: независимые релизы и масштабирование, изоляция отказов, параллельная работа многих команд, разные технологии. Минусы: сложность распределённой системы (сеть, согласованность данных, распределённые транзакции), сложнее мониторинг и тестирование, нужна зрелая DevOps-инфраструктура. Монолит лучше выбрать для стартапа и MVP, небольшой команды, простой или ещё не устоявшейся предметной области, когда важна скорость выхода на рынок.

Хореография — способ координации распределённого процесса между сервисами без центрального управляющего: каждый сервис сам реагирует на события и публикует свои. Например, сервис заказов публикует «Заказ создан», сервис платежей его слушает и после списания публикует «Оплата прошла», на это реагирует склад и т.д. Используется в событийно-ориентированных архитектурах и микросервисах для слабой связанности, в том числе для реализации паттерна Saga (распределённые транзакции с компенсирующими действиями) в хореографическом варианте.

Плюсы: слабая связанность — сервисы не знают друг о друге, только о событиях; нет единой точки отказа и узкого места; легко добавить нового участника, просто подписав его на событие; хорошая масштабируемость. Минусы: процесс целиком нигде не описан и его трудно увидеть, понять и изменить; сложно отследить, на каком шаге находится конкретный экземпляр процесса, и отладить ошибки; риск циклических зависимостей между событиями; сложнее реализовать компенсации и таймауты. Хореография хороша для простых процессов из небольшого числа шагов.

Оркестрация — способ координации, при котором центральный компонент (оркестратор) управляет процессом: сам вызывает сервисы в нужном порядке, ждёт ответов, принимает решения о следующем шаге и запускает компенсации при ошибке. Оркестратором может быть отдельный сервис или BPM/workflow-движок (Camunda, Temporal, Zeebe), а также ESB. Используется для сложных бизнес-процессов с ветвлениями, таймаутами и участием людей, для паттерна Saga в оркестрируемом варианте, когда нужно видеть и контролировать состояние каждого экземпляра процесса.

Плюсы: логика процесса описана в одном месте и её легко понять, изменить и визуализировать (например, в BPMN); прозрачно видно состояние каждого экземпляра; проще обрабатывать ошибки, таймауты, ретраи и компенсации; удобно для сложных процессов. Минусы: оркестратор становится центральной точкой отказа и потенциальным узким местом; сервисы сильнее связаны с ним; есть риск, что в оркестратор перетечёт бизнес-логика сервисов; при большой нагрузке его нужно масштабировать.

AJAX (Asynchronous JavaScript and XML) — подход, при котором JavaScript на веб-странице асинхронно обменивается данными с сервером в фоне и обновляет только часть страницы без полной перезагрузки. Исторически использовался объект XMLHttpRequest и формат XML, сейчас — fetch API и обычно JSON. Применяется для подгрузки данных при прокрутке, автодополнения в поиске, проверки полей формы на лету, отправки форм без перезагрузки, обновления счётчиков и уведомлений. На этом принципе построены современные одностраничные приложения (SPA).

fetch('/api/v1/cities?query=Мос')
  .then(r => r.json())
  .then(data => showSuggestions(data));

CAP-теорема (Эрик Брюер) утверждает, что распределённая система не может одновременно гарантировать все три свойства: Consistency (согласованность — все узлы видят одинаковые данные в один момент), Availability (доступность — каждый запрос получает ответ) и Partition tolerance (устойчивость к разделению — система работает при потере связи между узлами). Поскольку сетевые сбои в распределённой системе неизбежны, P по сути обязательно, и при разделении приходится выбирать между C и A: CP-системы (например, ZooKeeper, HBase) отказывают в ответе ради согласованности, AP-системы (Cassandra, DynamoDB) отвечают, допуская временно устаревшие данные (eventual consistency). Поэтому система, полностью удовлетворяющая всем трём свойствам, невозможна; на практике выбирают баланс для каждого сценария (например, платежи — CP, лента новостей — AP), а теорему PACELC дополняют выбором между задержкой и согласованностью в нормальном режиме.

API Gateway — единая точка входа для внешних клиентов в систему из множества сервисов. Он принимает запросы и маршрутизирует их к нужным сервисам, а также берёт на себя сквозные функции: аутентификацию и авторизацию (проверка токенов), ограничение частоты запросов (rate limiting), SSL-терминацию, кэширование, логирование и мониторинг, преобразование протоколов и форматов, агрегацию ответов нескольких сервисов. Это скрывает внутреннюю структуру системы от клиентов. Примеры: Kong, Nginx, Apigee, AWS API Gateway, Spring Cloud Gateway. Разновидность — BFF (Backend for Frontend), отдельный шлюз под каждый тип клиента.

Балансировщик нагрузки (load balancer) — компонент, который распределяет входящие запросы между несколькими экземплярами сервиса. Цели: горизонтальное масштабирование, отказоустойчивость (балансировщик проверяет здоровье узлов через health check и не отправляет запросы на упавшие), равномерная загрузка. Алгоритмы: round robin (по кругу), weighted round robin, least connections (на наименее загруженный), IP hash (клиент всегда на один узел — sticky sessions). Работают на уровне L4 (TCP/UDP) или L7 (HTTP, с маршрутизацией по URL и заголовкам). Примеры: Nginx, HAProxy, облачные балансировщики, Kubernetes Service и Ingress.

Event Sourcing — паттерн хранения данных, при котором сохраняется не текущее состояние объекта, а последовательность всех событий, которые с ним произошли (журнал только на добавление). Текущее состояние получается «проигрыванием» событий. Например, вместо поля balance хранятся события «Счёт открыт», «Зачислено 1000», «Списано 300» — баланс равен 700. Плюсы: полная история и аудит, возможность восстановить состояние на любой момент, перепроиграть события для новых представлений. Минусы: сложность, рост объёма (решается снимками — snapshots), сложные запросы к текущему состоянию, поэтому часто комбинируется с CQRS (отдельные модели для записи и чтения).

Классический жизненный цикл разработки ПО (SDLC): сбор и анализ требований, проектирование (архитектура, модель данных, интерфейсы, интеграции), реализация (написание кода), тестирование, развёртывание (внедрение), сопровождение и развитие. Часто добавляют предварительный этап — инициацию и планирование (цели, бюджет, сроки, оценка осуществимости). В водопаде этапы идут последовательно один раз, в Agile они повторяются в каждой итерации небольшими порциями.

Системный аналитик — связующее звено между бизнесом и разработкой. Он выявляет и уточняет требования, переводит бизнес-задачи в технические постановки, проектирует решение на логическом уровне: процессы, модели данных, интеграции и API, поведение интерфейсов. Аналитик документирует требования, согласует их со стейкхолдерами, консультирует разработчиков и тестировщиков, участвует в оценке и приёмке, следит за целостностью требований и их изменениями. Его цель — чтобы команда построила именно то, что нужно бизнесу, без лишних переделок.

Основной игрок — на этапах анализа и сбора требований, а также проектирования (постановки, модели, спецификации API, согласование решения). Активное, но не ведущее участие — в реализации (ответы на вопросы разработчиков, уточнение и изменение требований) и тестировании (помощь в составлении тест-кейсов, разбор дефектов, приёмка). Опционально или эпизодически — на этапах развёртывания и сопровождения: участие в демо и приёмке, подготовке пользовательской документации, обучении пользователей, разборе инцидентов и сборе требований на доработки. Распределение может отличаться в зависимости от компании и наличия бизнес-аналитика.

Аналитик проводит для тестировщиков разбор (демо) требований и постановок, приглашает их на ревью требований ещё до разработки — тестировщики хорошо находят неоднозначности и пропущенные сценарии. Он совместно с ними формирует критерии приёмки и тестовые сценарии, помогает подготовить тестовые данные, отвечает на вопросы по ожидаемому поведению, помогает определить, является ли найденное поведение дефектом или неописанным требованием. Также полезна матрица трассировки требований к тест-кейсам, чтобы видеть покрытие. Раннее вовлечение QA (shift-left) сильно снижает число ошибок.

Декомпозиция — разбиение крупной задачи на небольшие, понятные и оцениваемые части: эпик → фичи → пользовательские истории → технические задачи (фронт, бэк, БД, интеграции, тесты). Хорошо делить по вертикали — каждая история даёт законченную ценность, а не «сделать таблицу» отдельно от «сделать экран». Можно декомпозировать по сценариям, ролям, бизнес-правилам, операциям CRUD, вариантам данных. Затем каждую часть оценивает команда — экспертно, в часах или стори-пойнтах, часто через Planning Poker; итоговая оценка складывается с учётом рисков и неопределённости. Для крупных проектов используют WBS (иерархическую структуру работ).

• DoR (Definition of Ready) — критерии готовности задачи к взятию в работу: описание понятно, есть критерии приёмки, макеты и контракты API, зависимости сняты, задача оценена и помещается в спринт.
• DoD (Definition of Done) — общие для команды критерии завершённости любой задачи: код написан и прошёл ревью, покрыт тестами, протестирован, документация обновлена, задача развёрнута на стенде.
• AC (Acceptance Criteria) — критерии приёмки конкретной истории: условия, при которых заказчик считает её выполненной. Например: «При вводе неверного пароля 5 раз подряд учётная запись блокируется на 15 минут».

Абсолютные оценки — в часах или днях (экспертная оценка, оценка по аналогии, по декомпозиции). Относительные — в стори-пойнтах (обычно по ряду Фибоначчи 1, 2, 3, 5, 8, 13), в размерах футболок (T-shirt: XS, S, M, L, XL). Техники командной оценки: Planning Poker, метод аффинитивной оценки (сортировка задач по сложности на доске), PERT — трёхточечная оценка (оптимистичная, наиболее вероятная, пессимистичная: (O + 4M + P) / 6). Для собственных задач аналитики чаще всего оценивают в часах или днях, а в Scrum-команде участвуют в общей оценке в стори-пойнтах.

Оценка в часах — абсолютная: прогноз конкретного времени работы, понятна бизнесу, удобна для планирования бюджета, но часто неточна и зависит от исполнителя. Стори-пойнты — относительная оценка сложности, объёма работы и неопределённости по сравнению с эталонной задачей; они не привязаны к конкретному человеку и времени. Сроки по стори-пойнтам вычисляются через скорость команды (velocity) — сколько пойнтов команда в среднем закрывает за спринт. Стори-пойнты лучше работают для стабильных команд, часы — для фиксированных контрактов и небольших задач.

Аналитик декомпозирует задачу на свою часть работ: изучение текущей системы, встречи со стейкхолдерами, сбор и согласование требований, проектирование, написание постановки, ревью, поддержка разработки и тестирования. Для каждого шага делает оценку, опираясь на опыт и похожие задачи; при высокой неопределённости использует трёхточечную оценку (PERT) или закладывает буфер на риски, например на ожидание ответов от смежных команд и согласования. Оценку разработки и тестирования аналитик не делает сам, а собирает у команды. Итоговый срок учитывает зависимости, загрузку людей и параллельность работ. Если неопределённость большая, честнее сначала оценить исследовательскую задачу (spike), а затем — основную.

Основные модели и методологии: Waterfall (каскадная, последовательные этапы), V-модель (каскад с тестированием на каждом уровне), итеративная и спиральная модели, а также гибкие (Agile) подходы: Scrum, Kanban, Scrumban, XP (экстремальное программирование), Lean, для масштабирования — SAFe, LeSS. Часто встречаются гибридные подходы: водопад для рамок проекта и бюджета, Scrum внутри разработки. Ответ про личный опыт должен быть честным и аргументированным: например, Scrum хорош для продуктовой разработки с меняющимися требованиями, Kanban — для потока задач поддержки и развития.

Scrum подходит для разработки продуктов в условиях неопределённости и меняющихся требований, когда можно поставлять ценность небольшими инкрементами и регулярно получать обратную связь от заказчика, а команда небольшая (до 10 человек), кросс-функциональная и стабильная. Плохо подходит для проектов с жёстко фиксированными требованиями, сроками и бюджетом по договору (госзаказ по ГОСТ), для потока непредсказуемых срочных задач (поддержка, инциденты — здесь лучше Kanban), для очень маленьких или разовых задач, когда заказчик не готов регулярно участвовать, а также в областях, где ошибка недопустима и требуется полная предварительная спецификация и сертификация.

Согласно Scrum Guide: Спринт — контейнер для всех событий, итерация фиксированной длины до месяца (обычно 2 недели); Планирование спринта — команда определяет цель спринта и выбирает задачи из бэклога; Daily Scrum (ежедневный стендап, 15 минут) — синхронизация прогресса к цели спринта; Обзор спринта (Sprint Review) — демонстрация результата стейкхолдерам и сбор обратной связи; Ретроспектива — команда обсуждает, что улучшить в процессе. Также регулярно проводится груминг (уточнение бэклога, Product Backlog Refinement), который в текущем Scrum Guide считается постоянной активностью, а не формальным событием.

Kanban — метод управления потоком работ, пришедший из производственной системы Toyota. Работа визуализируется на доске с колонками-этапами (например, «Бэклог — Анализ — Разработка — Тест — Готово»), задачи движутся по ним непрерывно, без итераций. Три основных правила (практики): визуализировать рабочий процесс; ограничивать незавершённую работу (WIP-лимиты — максимум задач в колонке); управлять потоком — измерять и оптимизировать время прохождения задач (lead time, cycle time) и устранять узкие места. В расширенной версии добавляют явные правила процесса, петли обратной связи и постоянное улучшение.

Scrum работает итерациями фиксированной длины (спринтами) с обязательствами на спринт, Kanban — непрерывным потоком без итераций. В Scrum есть фиксированные роли (Product Owner, Scrum Master, Developers) и события, в Kanban обязательных ролей и встреч нет. Scrum ограничивает объём работы через объём спринта, Kanban — через WIP-лимиты в колонках. В Scrum менять состав спринта нежелательно, в Kanban приоритеты можно менять в любой момент. Метрики: в Scrum — velocity, в Kanban — lead time, cycle time, пропускная способность. Kanban проще внедрить поверх текущего процесса, он хорош для поддержки; Scrum — для продуктовой разработки.

Хороший аналитик понимает бизнес-цель задачи и предлагает решение, а не просто записывает пожелания. Он задаёт правильные вопросы и докапывается до реальной потребности, видит систему целиком и учитывает последствия изменений для смежных модулей и интеграций. Его требования однозначны, полны и проверяемы, их понимают и бизнес, и разработчики. Он хорошо коммуницирует, умеет договариваться и отстаивать позицию, разбирается в технической стороне (SQL, API, архитектура) настолько, чтобы говорить с командой на одном языке, берёт на себя ответственность и доводит задачу до результата.

Джун выполняет понятные, хорошо поставленные задачи под руководством более опытных коллег: описывает требования по шаблону, рисует диаграммы, уточняет детали; ему нужна проверка результата. Мидл самостоятельно ведёт задачи от сбора требований до приёмки, сам проектирует интеграции и модели данных, работает с неопределённостью в рамках своей области. Сеньор работает с самыми сложными и неопределёнными задачами, проектирует решения на уровне нескольких систем, видит риски и альтернативы, влияет на архитектуру и процессы, ведёт переговоры со стейкхолдерами, менторит младших и выстраивает практики анализа в команде. Главное отличие — масштаб ответственности и степень самостоятельности.

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

Системный аналитик выявляет, анализирует и документирует требования к информационной системе, переводя бизнес-потребности в технические спецификации. Он проектирует решение: моделирует процессы и данные, описывает логику, интерфейсы и интеграции (API, очереди, маппинги), формулирует нефункциональные требования. Он согласует решение с бизнесом, архитекторами и разработчиками, сопровождает реализацию — отвечает на вопросы, участвует в тестировании и приёмке, управляет изменениями требований. Также поддерживает документацию системы в актуальном состоянии и анализирует существующие системы и данные (в том числе SQL-запросами) для поиска проблем и решений.

Протокол — набор правил и форматов, по которым устройства или программы обмениваются данными: как устанавливается соединение, в каком формате передаются сообщения, как обрабатываются ошибки. Протоколы работают на разных уровнях модели OSI/TCP-IP:

• прикладной: HTTP/HTTPS, FTP/SFTP, SMTP, IMAP, POP3 (почта), DNS, SSH, WebSocket, AMQP, MQTT;
• транспортный: TCP (надёжная доставка с установкой соединения), UDP (быстрая, без гарантий);
• сетевой: IP, ICMP;
• безопасности: TLS/SSL.

HTTPS — это HTTP поверх защищённого протокола TLS. В HTTP данные передаются открытым текстом, их можно перехватить или подменить по пути (атака «человек посередине»). В HTTPS трафик шифруется, проверяется целостность данных, а подлинность сервера подтверждается SSL/TLS-сертификатом, выданным удостоверяющим центром. По умолчанию HTTP использует порт 80, HTTPS — порт 443. Сейчас HTTPS — стандарт для любых сайтов и API, особенно при передаче персональных данных, паролей и платёжной информации.

Идентификация — пользователь называет себя (вводит логин). Аутентификация — проверка, что он действительно тот, за кого себя выдаёт: пароль, код из SMS, биометрия, сертификат; при нескольких факторах — двухфакторная (2FA). Авторизация — проверка и выдача прав: что аутентифицированному пользователю разрешено делать (роли, ролевая модель RBAC, права доступа). Порядок всегда такой: сначала аутентификация, потом авторизация. В HTTP: 401 Unauthorized фактически означает «не аутентифицирован», 403 Forbidden — «аутентифицирован, но нет прав». Типичные технологии: OAuth 2.0 (делегирование доступа), OpenID Connect (аутентификация поверх OAuth), JWT-токены, Keycloak как сервер авторизации.

• Браузер разбирает URL и проверяет кэш (в том числе HSTS и кэш DNS).
• DNS-запрос: доменное имя преобразуется в IP-адрес (кэш браузера и ОС, затем DNS-резолвер).
• Устанавливается TCP-соединение с сервером (трёхстороннее рукопожатие SYN, SYN-ACK, ACK).
• Для HTTPS — TLS-рукопожатие: проверка сертификата и согласование ключей шифрования.
• Браузер отправляет HTTP-запрос (GET /path, заголовки, cookies).
• Запрос проходит через балансировщики и прокси, сервер обрабатывает его (бизнес-логика, обращения к БД) и возвращает ответ с кодом, заголовками и HTML.
• Браузер разбирает HTML, строит DOM, загружает CSS, JavaScript и изображения дополнительными запросами, выполняет скрипты и отрисовывает страницу.

Шифрование — преобразование данных в нечитаемый вид с помощью алгоритма и ключа, чтобы прочитать их мог только обладатель нужного ключа. Симметричное шифрование использует один ключ для шифрования и расшифровки (AES, ГОСТ «Кузнечик»): быстрое, но ключ нужно безопасно передать. Асимметричное использует пару ключей — открытый для шифрования и закрытый для расшифровки (RSA, ECC): решает задачу обмена ключами, лежит в основе электронной подписи и TLS, но медленнее. На практике их комбинируют: в HTTPS асимметрично согласуется сессионный ключ, а данные шифруются симметрично. Различают шифрование при передаче (in transit, TLS) и при хранении (at rest, шифрование дисков и полей БД). Хеширование (SHA-256, bcrypt для паролей) — не шифрование, так как оно необратимо.