Модуль 7. Нефункциональные требования и архитектурные ограничения
Зачем NFR и чем они отличаются от «хотелок»
Функциональные требования отвечают «что система делает», NFR — «как хорошо, стабильно и безопасно она это делает». Если NFR не формализованы, проект почти всегда «падает» в эксплуатации: отчеты открываются 20 секунд, данные приходят не вовремя, роли доступа ломают суммы, а аудит не может ответить «кто и что менял».
Задача BA: превратить общие слова («быстро», «надежно», «безопасно») в тестируемые цели с числом, метрикой, источником измерения и планом проверки.
Карта NFR для BI/DWH: что обязательно закрыть
Производительность (Performance)
- Время отклика (BI): первая отрисовка страницы ≤ 5 сек на 95-м перцентиле при горизонте данных 12 мес и активных фильтрах «Регион/Канал/Категория».
- Фоновые вычисления: перерасчет витрины GM (месячной) ≤ 25 мин; агрегации недельных продаж ≤ 10 мин.
- Конкурентная нагрузка: 50 одновременных пользователей на ключевой дашборд с деградацией не более +20% к времени отклика.
- Профиль данных: расчет бюджета на объём (строки/день, размер строк, кардинальность измерений), тип партиционирования, используемые индексы/проекции/материализованные представления.
Доступность (Availability) и восстановление
- Доступность BI: ≥ 99.5% в рабочее время (пн–пт 08:00–20:00), окно обслуживания вс 01:00–03:00.
- RTO/RPO (DWH/ETL): RTO ≤ 2 часа, RPO ≤ 15 минут для витрин «оперативные продажи»; для финансовой отчётности допускается RPO = D-1.
- Failover: автоматический для BI/DB (актив-пассив/актив-актив), тесты переключения раз в квартал (документальный акт).
Свежесть данных и латентность (Latency/Freshness)
- SLA свежести: данные продаж D-1 доступны к 10:00, KPI «Freshness ≥ 98%»; логистика D+2 → режим «черновик» до прихода данных.
- Micro-batch: OOS/запасы обновляются каждые 30–60 мин; допустимый лаг по филиалам ±15 мин.
- Реакция на срыв: баннер «черновик», блок экспорта, алерт владельцам и в канал инцидентов.
Безопасность (Security) и доступы
- Аутентификация: корпоративный SSO (SAML/OIDC), MFA для админ-ролей.
- Авторизация (RLS): разграничение по Региону/Бренду, проверено тестами ролей; принцип наименьших привилегий.
- Шифрование: in transit (TLS 1.2+), at rest (KMS/Transparent Data Encryption); ключи — с ротацией не реже 180 дней.
- PII/коммерческая тайна: маскирование/псевдонимизация, доступ по заявке с согласованием владельца данных; запрет выгрузок с ПДн «в лоб».
- Секреты: только в секрет-хранилище (Vault/KMS), без хранения в скриптах/конфигурациях.
Аудит и наблюдаемость (Audit/Observability)
- Аудит действий: кто/когда открыл/выгрузил/изменил методологию, админ-операции (создание ролей, выдача доступов).
- Логи ETL/BI: централизованно (SIEM), корреляция по trace-id; хранения не менее 180 дней (операционные) и 1 год (безопасность).
- Метрики SLI/алерты: Freshness, Success Rate, Latency p95/p99, Error Rate, Cache Hit, Query Time; пороги и ответственные определены.
Интеграции и протоколы
- CDC/Batch/API: что используем, лимиты rate limit/pagination, гарантия доставки (at least once), дедупликация, повторная обработка (idempotency).
- Окна интеграции: batch-окна, когда источники «закрыты», а также «тихие часы» для тяжёлых перерасчетов.
- Контракты данных: схема, типы, частота, SLA, владелец источника; политика версионирования (breaking changes по согласованию).
Лицензии и экономика
- Модель лицензирования: BI (named/concurrent/core), СУБД (ядра/узлы), ETL-оркестратор (агенты/коннекторы).
- Пиковая нагрузка vs лицензии: расчёт нужного пула concurrent-сессий; план «burst» на события (месячное закрытие, распродажи).
- TCO: капитальные/операционные затраты, рост объёма и пользователей на 12–24 мес.
Как приоритизировать NFR: Utility Tree + ATAM-логика
Utility Tree (дерево полезности): наверху — качество (Performance/Availability/Security/…); ниже — Quality Attribute Scenarios (QAS): «Кто, что делает, при каких условиях, ожидаемое поведение и метрика».
Пример QAS:
«Пользователь открывает дашборд GM% при 12 мес данных и 50 одновременных сессиях → отрисовка ≤ 5 сек p95; источник измерения — APM/BI telemetry; непройдено, если >5 сек».
ATAM-подход (вкратце): выявляем драйверы бизнеса, риски архитектуры, точки компромиссов (например, скорость vs стоимость, гибкость vs единый смысл метрик), проводим сессию «тактических компромиссов» с владельцами.
Делать NFR тестируемыми: из фразы в сценарий
Шаблон QAS:
- Источник стимула: «Конкурентная нагрузка 50 пользователей».
- Стимул: «Открытие страницы / фильтрация».
- Контекст: «Рабочее время, 12 мес истории, кэш холодный».
- Артефакт: «Дашборд GM%».
- Ответ системы: «p95 ≤ 5 сек; Error Rate <1%».
- Метрика/измерение: «APM/BI usage telemetry, нагрузочный стенд N».
- Критерий приёмки: «Pass/Fail».
Пример превращения требования:
«Быстро» → «Время первого ответа ≤ 3 сек p90 и ≤ 5 сек p95 на странице Sales_Overview при 12 мес истории и 20 одновременных пользователях; измеряем APM-метриками 10-минутными окнами».
Архитектурные ограничения: с чем живём
- Хранилище: тип СУБД (MPP/колоночная/OLAP-движок), лимиты на ширину строк, партиционирование по дате/региону, компрессия.
- BI-движок: поддержка RLS, уровень семантики (меры/иерархии), кэш-экстракты, лимиты выгрузок/строк, сервер рендера.
- Интеграция: наличие CDC/журналов, лимит API, «грязное окно» (время, когда данные нестабильны).
- Сеть: пропускная способность между ЦОД/облаком и филиалами, прокси/файрволы.
- Оркестрация: очереди, ретраи, идемпотентность, dead-letter-очереди.
BA фиксирует эти ограничения в SRS/NFR, чтобы бизнес понимал стоимость «сверх» и компромиссы.
Производительность: планирование и бюджет
Бюджет времени (пример для BI-страницы)
- Источник (скан/аггр) ≤ 2.0 сек
- Семантический слой/калькуляции ≤ 1.0 сек
- Передача данных/сеть ≤ 0.5 сек
-
Рендер UI ≤ 1.5 сек
Итого p95 ≤ 5 сек. Если один из сегментов «съедает» бюджет — оптимизируем: агрегаты, предфильтры по умолчанию, индексы, материализованные витрины.
Объёмы и кардинальности
BA совместно с ИТ оценивает:
- Строк/день, средний размер строки, уникальные значений в измерениях (SKU/клиенты/магазины).
- Горизонт хранения (12/24/36 мес) → объём витрин.
- Партиционирование (по дате/региону), клёстеры/зоны.
- Прогоны «тяжёлых» запросов: выборка worst-case (топ-N, детализация до SKU-дня).
Little’s Law (очень грубо для очередей ETL)
WIP ≈ Throughput × Cycle Time. Если хотим закрыть перерасчет за 30 мин при 60 задачах, throughput должен быть ~2 задачи/мин → планируем параллелизм и ресурсы.
Свежесть и режимы «черновик»
Если хотя бы одна критичная DQ-проверка или SLA свежести «красная», включаем режим черновика:
- В BI — баннер в шапке «Данные не полные (логистика)», отключён экспорт, подсказка «обновление ожидается к 09:30».
- В журналах — событие «SLA-breach», инцидент в канал поддержки.
- После догрузки — автоматическое снятие баннера и пересчёт, release-note на дашборде (методология/данные обновлены).
Безопасность: практический минимум для BA
- RLS-матрица: роль → область видимости (Region/Brand/Customer-segment). Тест-кейсы: пользователь «Регион X» видит только X; суммы инвариантны.
- ПДн/чувствительные поля: перечень столбцов, маскирование/псевдонимизация в витринах, запрет выгрузок «сырых» ПДн.
- Секреты и сервис-аккаунты: только через секрет-хранилище, ротация ключей, запрет локального хранения.
- Логи безопасности: аутентификация, выдача ролей, создание/удаление пользователей, попытки неуспешного входа.
Аудит и наблюдаемость: чтобы не «искать в пальцах»
- SLI/алерты (минимум): Freshness (в процентах), Latency p95/p99, Failure Rate, Query Time, Cache Hit Ratio, Uptime.
- Дашборд здоровья: отдельный «тех» дашборд в BI для ИТ и BA, доступен всем участникам релиза.
- Trace-id: прокидываем ID инцидента/загрузки из ETL до BI для быстрого расследования.
- Хранение логов: операционные 180 дней, безопасность 1 год (или по политике компании).
Интеграции: «острые углы»
- API лимиты: фиксируйте rate limit (запросы/мин), пагинацию, back-off.
- CDC: гарантия доставки (at least once), борьба с дубликатами (dedupe ключом), порядок событий по ключу (event time).
- Batch-окна: не дергать источники в часы закрытия/инвентаризации; планировать «тихие» часы для тяжёлых job’ов.
- Data Contracts: схема/типы/частота; процесс согласования изменений. Каждое «breaking change» = change-request.
Лицензии: чтобы «не выключилось в конец месяца»
- BI (concurrent): размер пула на пиковые события (месячное закрытие, отчётность по промо). Планируйте +20–30% запас.
- DB (cores/nodes): расчёт по профилю нагрузки: ETL-окно vs BI-окно; риск «съедания» BI перегрузом ETL.
- Оркестратор/коннекторы: платные адаптеры? Стоимость агента на узел?
- Мониторинг использования: регулярный отчёт «использование лицензий vs пиковая нагрузка», план роста.
Практика: раздел NFR к вашему SRS (шаблон + пример)
Шаблон (вставьте в SRS, §NFR):
- Производительность
- BI p95 ≤ __ сек при __; конкуренция __ пользователей; эталонные запросы: [ссылка].
- Свежесть
- D-1 к :; Freshness ≥ __%; fallback-режим: баннер/блок экспорта.
- Доступность и DR
- Uptime ≥ __%; RTO/RPO; схема failover; график тестов.
- Безопасность
- SSO/MFA, RLS-матрица, шифрование, список ПДн/маскирование, политика выгрузок.
- Аудит/Наблюдаемость
- Логи/метрики, пороги алертов, хранение, доступы.
- Интеграции
- Протоколы, rate limit, контракт данных, окна.
- Лицензии/TCO
- Модель, расчёт пиков, план роста 12–24 мес.
- Тестируемость
- QAS-таблица, стенд, сценарии нагрузочных/перф/фейловер-тестов, критерии pass/fail.
Фрагмент (пример «GM%-дашборд»):
- BI: p95 ≤ 5 сек (12 мес, 20 одновременных); ошибки <1%.
- Freshness: D-1 к 10:00, Freshness ≥ 98%; при <98% — баннер «черновик», блок экспорта.
- RTO/RPO: RTO ≤ 2ч, RPO ≤ 15мин; квартальные тренировки failover.
- Security: SSO, MFA для админов; RLS: Region/Channel; TLS 1.2+, TDE; ПДн отсутствуют.
- Audit/Obs: Latency p95/p99, Error Rate, Freshness; логи в SIEM 180/365; trace-id от ETL до BI.
- Integrations: ERP batch D-1 06:00; логистика D+2 08:00; API промо rate limit 100 rps, пагинация 1000.
- Licenses: BI concurrent 60 (+30% запас), DB 16 cores; отчёт «использование» ежемесячно.
- Testability: стенд PERF-UAT ~ прод, 200ГБ; 10 эталонных сценариев; критерий «пас» — p95 ≤ 5 сек, Freshness ≥ 98%.
Практика: риск-реестр (шаблон + примеры)
Шаблон записи:
- Риск: (кратко)
- Причина:
- Проявление/симптом:
- Вероятность / Влияние / Приоритет:
- Митигирующие меры (ex ante):
- План реагирования (ex post):
- Владелец:
- Статус/дата пересмотра:
Примеры:
-
Срыв SLA 10:00
Причина: отставание логистики D+2.
Симптом: Freshness < 98%.
Вер-ть/Влияние: Средняя/Высокое.
Меры: «черновик»-режим, алерты, совместный план с источником, мониторинг «ранние индикаторы».
Реакция: инцидент P2, коммуникация бизнесу, post-mortem 24ч.
Владелец: DataOps Lead. -
Падение производительности BI
Причина: рост объёма, тяжёлые фильтры.
Симптом: p95 > 5 сек.
Меры: агрегаты, пред-выборки, ограничение дефолтного горизонта, индексы.
Реакция: временно ограничить произвольные фильтры, план оптимизации. -
RLS ломает суммы
Причина: агрегации без учёта RLS.
Симптом: разные итоги у разных ролей.
Меры: тест-набор ролей, эталонные суммы, статические витрины «итогов» под RLS.
Реакция: откат релиза, исправление семантики. -
Breaking change в API
Причина: обновление поставщика.
Симптом: падение интеграций.
Меры: Data Contract, предварительный сэндбокс, мониторинг схемы.
Реакция: feature-флаг, быстрый адаптер, комм-план.
Тест-план NFR (как принимать)
- Стенд: PERF-UAT со схемой данных ~прод, копия семантики, отключённый кэш для «холодных» измерений.
- Нагрузочные сценарии: 20/50/100 одновременных; «худшие» фильтры; последовательность действий (открыть, переключить, drill-down).
- Метрики: p50/p95/p99, Throughput, Error Rate, CPU/IO/сеть, Cache Hit.
- Сбор фактов: APM/телеметрия BI, лог запросов DB; идентичный seed данных.
- Критерии Pass/Fail: чётко в QAS; один «красный» пункт = Fail.
- Chaos/DR-drill: плановая проверка failover, RTO/RPO, сценарии деградации (отключение источника, падение узла БД).
- Отчет: скриншоты, CSV-метрики, заключение «готов/не готов», список рекомендаций.
Вопрос–ответ (FAQ)
Q: У нас «всё быстро» на тесте, почему на проде медленно?
A: Непохожая нагрузка/объём, горячий кэш, другой профиль пользователей. Делайте PERF-UAT ~прод, прогревайте кэш отдельно, тестируйте «холодный старт» и пиковые окна.
Q: Где считать метрики — в БД или в BI — с точки зрения производительности?
A: Базовые KPI и тяжёлые агрегации — в витринах/материализованных представлениях. В BI — лёгкие производные. Так вы стабилизируете p95 и удержите единый смысл.
Q: Как формально «провалить» дашборд на приемке?
A: Есть QAS: если p95 > 5 сек или Freshness < 98% — Fail. BA обязан зафиксировать это в протоколе UAT, а не «на глазок».
Q: Реально ли 99.9% доступности?
A: Для BI в офисное время чаще достаточно 99.5%. 99.9% резко удорожает (двойная инфраструктура, 24×7). Обосновывайте цифры пользой.
Q: Как доказать безопасность без «бумажной магии»?
A: Показать матрицу RLS-тестов, журналы доступа, политику маскирования, отчёт SIEM по последним 90 дням, результаты «failover-drill».
Q: Что делать, если бизнес требует realtime «потому что красиво»?
A: Переведите в решение и риск: какую управленческую реакцию меняем? Если нет решения «в минутах», часовые/получасовые обновления дадут 90% выгоды за 10% стоимости.
Чек-листы готовности
NFR-секция SRS
- Производительность с цифрами и контекстом
- Свежесть/SLA и режим «черновик»
- Uptime/RTO/RPO и план DR-тестов
- Security: SSO/MFA, RLS, шифрование, ПДн-политика
- Audit/Observability: метрики, алерты, retention
- Интеграции: протоколы, лимиты, контракты, окна
- Лицензии/TCO: текущий/пиковый/рост
- Testability: QAS, стенд, критерии
Риск-реестр
- Топ-10 рисков с владельцами
- Митигирующие меры и планы реагирования
- График пересмотра (раз в спринт/месяц)
Приёмка NFR
- Нагрузочные протоколы p95/p99
- DR-drill акт
- RLS-тесты пройдены
- DQ/Freshness-дашборд зеленый
- Паспорт дашборда: версия методологии/свежесть/владельцы
Вы превращаете эксплуатационные «риски на потом» в измеримые обязательства с тестами: производительность, свежесть, доступность, безопасность, аудит, интеграции и лицензии. Такой NFR-пакет экономит месяцы переделок и делает BI/DWH управляемыми.
