Полный FAQ по работе системного аналитика
Формат: короткие, практичные ответы. Внутри — примеры, артефакты, «риски и как их гасить». Группы: роль → процессы → требования → API/интеграции → данные/SQL → NFR/наблюдаемость → безопасность → тестирование/UAT → Agile/управление → изменения/версии → карьера/интервью → инструменты → риски/шпаргалки.
Профессия и роль
Q1. Чем системный аналитик (SA) отличается от бизнес-аналитика (BA)?
A. BA отвечает за «зачем/что» (ценность/правила бизнеса), SA — за «как это будет работать в системе»: процессы (BPMN), правила (DMN), данные (ER), контракты API/событий, NFR, трассируемость и приемка.
Q2. Где проходит граница между SA и архитектором?
Архитектор определяет принципы/стили/некоторые ключевые решения, SA — оформляет и доводит фичу (контракты, схемы данных, процессы, NFR) до релиза, ведёт CCB и трассируемость.
Q3. Что главное продаёт SA?
Не «умею BPMN/SQL», а способность превратить цель в пакет артефактов (SRS→BPMN/DMN→ER→OpenAPI/Events→NFR→RTM→AC/BDD→UAT→C4) и довести до релиза без регрессий.
Процессы и взаимодействие
Q4. Какую матрицу RACI вести?
На фичу: Owner, BA/PO, SA, Dev, QA, Архитектор, Сторонние интеграторы. Риск: «все консультанты, никто не Responsible» → Назначьте одного R, одного A.
Q5. Что положить в Definition of Ready (DoR)?
Сформулированная цель, Scope/Out-of-scope, черновой BPMN/DMN, черновой OpenAPI, первичный ER, NFR-скелет, согласованные допущения, список рисков, план проверки.
Q6. Как вести backlog с точки зрения SA?
Эпики → фичи → стори. В каждой стори — артефакты/ссылки и AC. Держите связи в RTM.
Требования и артефакты
Q7. Какая минимальная структура SRS?
Цель/границы → глоссарий → акторы/контексты → FR/NFR → модели (BPMN/DMN/ER) → контракты (OpenAPI/Events) → правила ошибок → безопасность → RTM/AC → критерии приемки/UAT.
Q8. Как писать требования, чтобы они были проверяемыми?
Формула: shall + метрика + метод проверки + условия. «POST /payments shall return 202 при таймауте PSP; событие payment.pending.v1 ≤2 сек p95; проверка: e2e+SLI.»
Q9. Как организовать RTM?
Таблица: REQ → AC → Tests → API/Events → NFR → UAT. Каждая запись с идентификаторами и статусом.
BPMN/DMN (процессы и правила)
Q10. Основные ошибки в BPMN?
«Ковер», нет End, нет таймеров/ошибок, смешение уровней. Лечение: ≤12 элементов на уровень, Event-based gateway, Boundary timer/error, подпроцессы.
Q11. Когда DMN вместо «if-else» в тексте?
Когда правила меняются часто, есть табличное ядро (скидки, лимиты, SLA). Добавьте hit policy и примерный набор тестов.
API/интеграции/события
Q12. Что обязательно должно быть в OpenAPI?
Ресурсы/операции, 201/202/409/422/429, идемпотентность (Idempotency-Key), cursor-пагинация, фильтры, каталог ошибок в RFC 7807-формате, безопасность (OAuth2/JWT), семантическая версия.
Q13. Когда возвращать 202 вместо 200/201?
Если работа асинхронная (PSP/доставка/большая обработка). Возвращайте 202 + endpoint статуса и/или событие.
Q14. Как сделать create-операции идемпотентными?
Заголовок Idempotency-Key + реестр ключей с TTL; при повторе — 409/предыдущий результат. Логика не должна повторно создавать ресурсы.
Q15. Cursor vs offset пагинация?
Cursor (keyset) устойчив к изменениям, обязателен на больших данных. Offset приводит к дублям/пропускам.
Q16. Как проектировать события домена?
Имя (order.created.v1), schema, ключ партиционирования, eventId, occurredAt, без PII. Версионирование — semver, deprecation-окно, dual-run при миграциях.
Q17. Outbox/Inbox — зачем?
Для гарантированной доставки (at-least-once) между транзакционной БД и брокером. Плюс дедуп по eventId.
Данные и SQL
Q18. Как описать доменные данные?
ER (сущности/связи/кардинальности), словарь атрибутов (тип/домены/валидация), DQ-правила (validity/completeness/uniqueness/timeliness/consistency).
Q19. Что проверить в модели денег?
Только DECIMAL, валюта/курс, округления, денормализованные суммы указать явно, ключи/уникальность.
Q20. Мини-набор SQL, который должен уметь SA?
JOIN, агрегаты, оконные (ROW_NUMBER/LAG/LEAD), MERGE (идемпотентные загрузки), проверки DQ (uniqueness/nullability/ranges).
Q21. Когда CDC/SCD2?
CDC — когда важна свежесть транзакций; SCD2 — для историзации измерений (не в OLTP).
НФР и наблюдаемость
Q22. Как формулировать SLO?
«В окне X, при условиях Y, показатель Z». «p95 ≤ 900 мс 08–23 CET, месяц». Укажите метод проверки (нагрузочный/SLI).
Q23. Что положить в Observability?
Логи JSON (структура, masking PII), RED-метрики, трассировки (traceId/correlationId), алерты по SLO/ошибкам/queue lag.
Q24. Как проверять NFR до релиза?
Нагрузочный профиль (RPS/latency), хаос/фичефлаги, сценарии деградации, план capacity.
Безопасность/комплаенс
Q25. Базовые требования к безопасности API?
OAuth2/OIDC, JWT (подпись/ttl/скоупы), RBAC/ABAC, rate limits, Problem Details для ошибок, минимизация PII, политика логов (маскирование).
Q26. Что такое «зелёный аудит»?
Все артефакты безопасности/журналирования/доступов соответствуют стандарту (внутреннему/OWASP ASVS), проверены чек-листом, замечаний нет.
Тестирование/UAT
Q27. Как связать AC и тесты?
AC в формате Given–When–Then, тест-кейсы/BDD → ссылка в RTM. Негативные сценарии обязательны (422/409/401/403/429).
Q28. Что входит в план UAT?
Роли/окружение, вход (RC, данные), сценарии/критерии, фиксация дефектов, выход (sign-off).
Agile/оценка/планирование
Q29. Story points vs time?
SP — относительная сложность; time — календарный план. Для релизного плана используйте критический путь и буферы.
Q30. Как декомпозировать эпик в стори?
Схема: потоки (BPMN) → контракты (OpenAPI/Events) → данные (ER/DQ) → NFR/Obs → приемка (AC/UAT). Каждая стори — часть этой цепочки.
Управление изменениями/версии
Q31. Что такое CCB и как её вести?
Change Control Board — форум решений по изменениям. Ведите ADR/DR, ChangeLog, semver, deprecation policy, dual-run, матрицу воздействия (impact).
Q32. Когда MAJOR, MINOR, PATCH?
Breaking — MAJOR; обратная совместимость — MINOR; баг-фикс/док — PATCH. Документируйте в ChangeLog.
Карьера/зарплата/форматы работы
Q33. Чем отличается junior/middle/senior SA?
- Jr: аккуратные артефакты, проектная папка на учебном/простом кейсе.
- Mid: автономные интеграции, NFR/Obs, RTM, события.
- Sr/Lead: эволюция контрактов/данных, CCB/dep policy, фасилитация.
Q34. Как влиять на зп?
Покажите эффект: –дефекты требований, –MTTR, +on-time, +конверсия; расширяйте зону ответственности; фиксируйте результаты в Raise-Memo и согласуйте KPI на 3–6 мес.
Q35. Можно ли стартовать без опыта?
Да: портфолио docs-as-code, shadow-роль 4–8 недель, стажировка, микро-фриланс (фикс-пакеты артефактов).
Интервью/тестовые/портфолио
Q36. Что покажет «готовность» на интервью?
Один сквозной кейс с полным пакетом (Vision→…→C4), объяснение trade-off (ADR), знание идемпотентности/202/Problem Details/ cursor и BPMN с таймерами/ошибками.
Q37. Типовые тестовые?
OpenAPI (идемпотентность/ошибки/безопасность), BPMN/DMN, ER/глоссарий, NFR+Obs, иногда SQL-проверки.
Инструменты/среда
Q38. Чем собирать модели и контракты?
BPMN/DMN: Camunda Modeler/bpmn.io; ER/UML/C4: PlantUML/Mermaid; API: Swagger Editor/Redocly; RTM: CSV/таблица; Docs-as-code: Git + Markdown.
Q39. Как версионировать документацию?
Git-репозиторий, ветки/PR, semver/теги, CHANGELOG, папки contracts/, processes/, data/, quality/, rtm/, adr/.
Частые риски и «как гасить»
Q40. «Ковер» из BPMN.
Декомпозируйте; используйте Event-based и Boundary; убирайте лишнее из одного уровня.
Q41. Offset-пагинация на больших данных.
Перейдите на cursor; стабилизируйте сортировку (например, (createdAt, id)).
Q42. Дубли/висяки при ретраях.
Включите идемпотентность; держите реестр ключей; dedup по eventId.
Q43. Падения интеграторов после релиза.
Semver+deprecation policy; dual-run; обратная совместимость; уведомления.
Q44. «Быстро/надёжно» вместо NFR.
Перепишите на SLO с окном/методом проверки.
Q45. PII в логах/событиях.
Маскирование/минимизация; политика логов.
Мини-шпаргалка ответов «на лету»
- Почему 202? Асинхронная обработка; возвращаем job/status или публикуем событие; предотвращаем таймауты.
- Как проверяете идемпотентность? Повтор запроса с тем же Idempotency-Key → 409/предыдущий ответ; в БД — индекс/реестр ключей.
- Что в NFR по платежам? p95/p99, SLA доступности, таймауты PSP, наблюдаемость (RED/трейсы), Security (OAuth2/JWT, masking).
- Как решите конфликт требований? Протокол → опции/риски → DMN/BPMN разные варианты → решение CCB/ADR.
Для джуна: «минимум-выпуск» (что принести на собес/стажировку)
- OpenAPI: 5 ручек, 201/202/409/422/429, Idempotency-Key, error-catalog (RFC 7807), OAuth2/JWT, cursor.
- BPMN: Collaboration, Event-based gateway, Boundary timer/error, компенсации.
- DMN: скидки/SLA (hit policy + примеры).
- ER/глоссарий: 6–8 сущностей, ключи/кардинальности, DQ-правила.
- NFR/Obs: 5 SLO, RED-метрики, схема логов/трейсов.
- RTM: полное покрытие; UAT: чек-лист.
- C4: L1–L2 контекст/контейнеры.
Фриланс/подработка: SOW-шаблон в одном ответе
Scope: BPMN To-Be (1 процесс), OpenAPI v1 (5 ручек, идемпотентность/ошибки/безопасность/версия), ER+словарь (6–8 сущностей)+3 DQ, NFR/Obs (SLO/RED/логи/трейсы), RTM.csv, UAT-чек-лист.
Приёмка: 2 ревью/нед + финальный sign-off, правки ≤20%. Вне Scope: разработка/нагрузочное.
Домены: где «дорогие» компетенции
- Финтех/платежи: идемпотентность, 202/вебхуки, антифрод/KYC/AML, аудит/журналы.
- E-commerce/логистика: SLA/DMN, OMS, трекинг/webhooks, возвраты.
- ERP/1C: обмен документами, справочники/MDM, бухгалтерские проводки.
- DWH/BI: CDC/SCD2, витрины/семантика, SLA свежести, экспорт-API.
Мини-формулы, которые экономят часы
- SLO: «в окне М (08–23) p95 ≤ 900мс; метод — нагрузочный + SLI».
- Ошибка: RFC 7807 {type,title,status,code,detail,instance,correlationId}.
- Идемпотентность: Idempotency-Key ≤128, TTL 24h, 409 при коллизии, реестр ключей.
- Cursor: ?cursor=base64(createdAt,id)&limit=100 + консистентная сортировка.
- Event: *.v1, eventId, occurredAt, schema/semver, без PII.
- RTM: REQ→AC→Tests→API/Events→NFR→UAT (статусы и ссылки).
