Модуль 5. Нефункциональные требования, интеграции, безопасность, мониторинг, эксплуатация, SLA/SLO, RPO/RTO
Цель модуля
Научить участников фиксировать, оцифровывать и проверять нефункциональные требования (НФТ) в ТЗ для проектов по данным, описывать интеграции и требования к безопасности/конфиденциальности, формировать SLA/SLO/SLI, RPO/RTO, а также регламенты мониторинга, поддержки и эксплуатации.
Что в итоге должен уметь участник
- Переводить «нам нужно быстро/надёжно/безопасно» в конкретные измеримые требования.
- Описывать интеграции с учётом идемпотентности, версионирования схем, ретраев, backpressure и др.
- Фиксировать SLA/SLO/SLI, RPO/RTO, строить error budget и правила эскалации.
- Формулировать требования по RBAC/ABAC, RLS/CLS, маскированию, шифрованию, журналированию, аудиту.
- Задавать требования к наблюдаемости: метрики, логи, трейсинг, DQ-мониторинг.
- Задавать режимы эксплуатации, on-call, runbooks, CI/CD, управление изменениями, документация.
Где это лежит в структуре ТЗ (напоминание)
В «скелете» ТЗ (Модуль 3) эти требования обычно попадают в разделы:
- Нефункциональные требования (NFR) — производительность, масштабируемость, доступность, отказоустойчивость, безопасность, аудит, мониторинг, эксплуатация.
- Интеграции — схемы обмена, контракты, SLA по интерфейсам, правила версионирования и эволюции схем, ретраи, идемпотентность.
- Эксплуатация/сопровождение — мониторинг, инцидент-менеджмент, on-call, runbooks, CI/CD, миграции, документация.
Классификация НФТ и матрица измеримости
Главное правило: каждая НФТ‑формулировка должна быть измеримой, проверяемой и трассируемой (к бизнес-целям, рискам, SLA).
Типовые группы НФТ для проектов по данным:
-
Производительность (Performance)
- throughput ingestion (строк/сек, сообщений/сек);
- response time (P50/P95/P99) на BI/SQL запросы;
- batch windows (окна ETL/ELT);
- SLAs для вычислительных задач (Spark/Trino/ClickHouse и др.).
- Масштабируемость (Scalability)
- горизонтальная/вертикальная, elastic/auto-scaling;
- тестируемые сценарии масштабирования (рост x10 данных).
- SLA по API/витринам;
- RPO/RTO, DR-план, активный/пассивный, multi-AZ/region.
- RBAC/ABAC, RLS/CLS, шифрование в движении/на хранении, управление ключами;
- токенизация/маскирование/анонимизация, DPIA/PIA (privacy impact assessment), SoD.
- метрики, логи, трассировка, алерты, error budgets;
- SRE-практики, on-call, runbooks, postmortem’ы.
- MTTR/MTTD, процедуры hotfix/release, технический долг, versioning ETL/dbt;
- документация, глоссарий, lineage, обучение команд.
- IaC, декларативные пайплайны, контейнеризация, поддержка разных СУБД/облаков;
- стандартизация форматов данных (Parquet/Delta/Iceberg/Avro/JSON).
- Доступность/Надёжность (Availability/Reliability)
- Безопасность и приватность (Security & Privacy)
- Наблюдаемость и эксплуатация (Observability & Operations)
- Поддерживаемость и сопровождаемость (Maintainability/Supportability)
- Переносимость и совместимость (Portability/Interoperability)
Матрица измеримости (пример):
|
Группа |
Показатель (SLI) |
Цель (SLO) |
SLA (в договоре) |
Метрика измерения |
Где меряем |
|---|---|---|---|---|---|
|
Performance |
P95 ответа BI-запроса |
≤ 7 сек |
≤ 10 сек |
Время выполнения запроса |
BI / semantic layer gateway |
|
Availability |
Аптайм API /metrics |
99.9% |
99.5% |
Uptime (по минутам) |
Status page / Prometheus |
|
Reliability |
RPO |
≤ 15 мин |
≤ 30 мин |
Разница между последней транзакцией в OLTP и появлением в DWH |
DQ мониторинг |
|
Security |
Время отзыва доступа |
≤ 4 часа |
≤ 8 часов |
Среднее время по тикетам IAM |
ITSM |
|
Observability |
MTTR |
≤ 45 мин |
≤ 2 часа |
Среднее время восстановления |
Incident tool |
Производительность и масштабирование
Что должно быть в ТЗ
-
Целевые показатели:
- Throughput ingestion: «не менее 50K строк/сек при загрузке из Kafka».
- BI response time: «P95 ≤ 7 секунд на запрос уровня витрины».
- Batch окна: «ежедневная загрузка sales должна укладываться в 1 час».
- Сценарии тестирования:
- Load test (номинальная нагрузка),
- Stress test (перегруз),
- Soak test (длительные прогонки),
- Failover test (доступность при отказах).
- Стратегии масштабирования: auto-scaling вычислительных кластеров (Spark/Trino), шардирование/репликация, вертикальное масштабирование для RDBMS, MPP/MPP-аналитики.
- Ограничения на запросы: лимиты на concurrency, resource groups (например, Trino/ClickHouse), «тяжёлые» запросы только в off-peak.
Пример формулировки (BI/DWH)
«Витрины dm_sales_daily, dm_profit должны обеспечивать P95 времени ответа ≤ 7 секунд при нагрузке до 300 одновременных пользователей (10 запросов/мин каждый) на выборку по диапазону дат в 1 год. При превышении нагрузки применяется resource group policy: тяжёлые запросы приостанавливаются, пользователю возвращается сообщение с предложением сузить выборку. Ежедневная загрузка слоя ODS из 1С должна укладываться в 60 минут при стартовых объёмах 150 млн строк и приросте 250 тыс строк/сутки.»
Доступность, отказоустойчивость, RPO/RTO, DR
Определения
- RPO (Recovery Point Objective) — допустимая потеря данных во времени.
- RTO (Recovery Time Objective) — допустимое время восстановления системы.
- SLA — договорной параметр доступности (например, 99.8%).
- SLO — целевой уровень, обычно строже SLA (например, 99.9%).
- Error budget — 1 - SLO: бюджет «ошибок»/простоя за период.
Что фиксировать в ТЗ
- Цели RPO/RTO по компонентам (ETL-оркестрация, DWH, BI, каталоги, MDM).
- DR-архитектура: актив-актив / актив-пассив, cold/warm/hot standby.
- Процедуры тестирования DR: частота, сценарии, критерии успеха.
- Бэкапы и ретеншн: периодичность, тип (full/incremental), хранение (offsite), шифрование.
- Failover/Fallback: кто запускает, как переключаемся, как откатываемся.
Пример таблицы RPO/RTO
|
Компонент |
RPO |
RTO |
Комментарий |
|---|---|---|---|
|
Хранилище DWH (факт/витрины) |
15 минут |
2 часа |
Логи CDC + snapshot каждые 6 часов |
|
Семантический слой BI |
0 минут |
30 минут |
Конфигурация в Git, восстановление из артефактов |
|
Оркестратор ETL |
0 минут |
1 час |
Стейт хранится в БД с синхронной репликацией |
|
Каталог данных + Lineage |
24 часа |
8 часов |
Периодические бэкапы + экспорт метаданных |
Безопасность: доступы, шифрование, аудит
Обязательные аспекты
-
Управление доступом
- RBAC/ABAC, RLS/CLS (строчные/покомпонентные ограничения), SoD (разделение обязанностей).
- Процедуры выдачи/изменения/отзыва прав (SLA по IAM).
- Категории ролей (L1-L3, Admin, Steward, Analyst, Viewer и др.).
- Классификация и защита данных
- PII/PHI/PCI и др.; уровни: Public/Internal/Confidential/Restricted.
- Маскирование, токенизация, анонимизация (k-anonymity, l-diversity), differential privacy (по необходимости).
- В движении (TLS 1.2+), на хранении (TDE/KMS/Envelope Encryption).
- Управление ключами (KMS, ротация, HSM, доступы).
- Кто что прочитал/изменил, какие запросы выполнялись, кто дал доступ кому.
- Хранение логов (ретеншн), неизменяемые storage (WORM/S3 Object Lock).
- Где храним (Vault/Secrets Manager/K8s Secrets), ротация, audit trail.
- Шифрование
- Журналирование и аудит
- Секреты
Таблица ролей и прав (пример)
|
Роль |
Доступ к данным |
Доступ к метаданным |
Запуск пайплайнов |
Управление доступами |
|---|---|---|---|---|
|
Data Steward Sales |
R/W к витринам продаж |
R/W |
R |
Нет |
|
BI Analyst |
R к витринам, RLS по филиалам |
R |
Нет |
Нет |
|
ETL Dev |
R/W в dev/test, R в prod |
R/W |
R/W |
Нет |
|
IAM Admin |
Нет |
Нет |
Нет |
Да |
Пример формулировки в ТЗ
«Все соединения между системами должны быть защищены TLS 1.2+. Данные в DWH (включая staging/ODS/DWH/DM) шифруются на уровне хранилища (TDE). Ключи хранятся в KMS, ротация ключей — раз в 90 дней. Доступ к PII полям (CustomerInn, PassportNumber) осуществляется только через BI с RLS и маскированием; прямой SQL-доступ к этим полям запрещён. Все запросы к PII логируются и доступны для аудита в течение 2 лет. SLA отзыва доступа — не более 4 часов с момента запроса.»
Конфиденциальность и соответствие (GDPR/152-ФЗ и др.)
Что зафиксировать
- Классификация полей: какие являются персональными, чувствительными.
- Правовые основания обработки (consent/contract/legal obligation, и т. п.).
- Сроки хранения, ретеншн и удаление (право на забвение/анонимизацию).
- Data minimization: хранить только то, что нужно.
- DPIA/PIA: проводить ли, кто ответственный.
- Локализация данных (data residency), трансграничная передача, зеркалирование.
Пример требования
«Для всех таблиц, содержащих PII, должен быть определён срок ретенции в соответствии с 152-ФЗ и внутренней политикой компании. По истечении срока данные анонимизируются или удаляются автоматически (процедура описана в оркестраторе и покрыта интеграционным тестом). Для каждого поля PII в каталоге данных фиксируется правовое основание обработки и ответственный за актуальность.»
Интеграции: шаблоны, контракт, устойчивость
Типовые паттерны
- Batch API / File-based (SFTP/S3)
- Streaming / Event-driven (Kafka/Pulsar/Kinesis)
- CDC / Log-based
- Reverse ETL (из DWH в операционные системы)
- Data Sharing (Lakehouse/Delta Sharing/External Tables)
- Semantic Layer API (dbt metrics, BI semantic models)
Что обязательно описать
- Контракт: схема, типы, версии, nullable/not-null, обязательность полей.
- Версионирование и эволюция схем: backward/forward compatible, deprecation policy.
- Идемпотентность, детерминированность (особенно для write-интерфейсов).
- Retries, backoff, circuit breaker, dead letter queues.
- Гарантии доставки: at-most-once / at-least-once / exactly-once (и на каком уровне обеспечивается).
- Наблюдаемость API: SLI/SLO, трассировка (correlation id), rate limits.
- Безопасность: OAuth2/JWT/mTLS, подпись сообщений, шифрование пэйлоада.
Пример формулировки для CDC- и API-интеграции
«Интеграция с CRM реализуется через Debezium CDC (at-least-once). Для каждого события в топике crm.customers присутствует event_id (UUID, idempotent), event_type (INSERT/UPDATE/DELETE), payload и schema_version. При недоступности потребителя события складываются в DLQ с ретеншном 7 дней. Схема сообщений версионируется: текущая версия v2, backward-compatible с v1. Отказ внедрять breaking changes без grace-периода 90 дней. Все события подписываются сервисным ключом, валидируются на стороне консьюмера. SLO: задержка доставки (P95) ≤ 2 минуты, SLA доступности брокера — 99.95%.»
Наблюдаемость, мониторинг, алертинг, SRE‑практики
Набор артефактов для ТЗ
- SLI/SLО/SLА и error budgets (по подсистемам).
-
Метрики:
- инфраструктурные (CPU, RAM, IO, network),
- приложенческие (время ETL, лаги CDC, число сообщений/сек),
- данные качества (DQ): пропуски, дубли, проценты NULL, расхождения сумм.
- Логи: формат (JSON), централизованный сбор (ELK/CloudWatch), ретеншн.
- Трейсинг: OpenTelemetry/Jaeger/Zipkin.
- Алерты: каналы (Slack/Teams/Email/PagerDuty), правила эскалации, шаблоны сообщений.
- Runbooks: для каждого критичного алерта — чёткие шаги диагностики и восстановления.
- Postmortem: без обвинений, с выводами и action items.
Пример SLO и error budget
«SLO доступности оркестратора (Prod): 99.9% в месяц → error budget: 43 мин/месяц. При выработке 50% бюджета вводится заморозка релизов, при 100% — релизы блокируются до восстановления уровня доступности в течение следующего отчётного периода.»
CI/CD, миграции схем, среды, IaC
Что зафиксировать
- Среды: dev/test/stage/prod (+ data sandbox’ы для дата-сайентистов).
- Контроль версий: Git (ветвление, code review, protected branches).
- Сборка и деплой: GitLab CI/GitHub Actions/ArgoCD/Jenkins.
- Схемы БД: миграции (Liquibase/Flyway/dbt), versioned DDL, rollbacks.
- Тестирование: unit (SQL/dbt tests), интеграционные, контрактные тесты API, DQ-тесты.
- Quality gates: линтеры SQL, покрытие тестами, проверка SLO в пайплайне.
- IaC: Terraform/Ansible/Helm/Kustomize для инфраструктуры и конфигураций.
- Секреты: Secret Manager/Vault, запрет хранения в Git.
Пример
«Все изменения в схемах DWH и витринах реализуются с помощью dbt и хранятся в Git. Перед деплоем в prod запускаются dbt tests (schema/data), а также интеграционные тесты пайплайнов. Семантический слой (BI) версионируется: конфигурация хранится в Git, деплой автоматизирован. Выпуск новой версии происходит через GitOps (ArgoCD). Секреты (пароли, токены) хранятся в Hashicorp Vault, доступ предоставляется по ролям через short-lived tokens.»
Журналирование, аудит и ретеншн
- Журналирование доступа к данным (кто/когда/что скачал/посмотрел).
- Журналирование административных операций (выдача прав, создание источников, изменение пайплайнов).
- Ретеншн логов (например, 2 года для действий с PII).
- Невозможность изменения журналов (WORM, append-only).
- Подготовка отчётов для ИБ/аудита (квартально/по требованию).
Управление изменениями и релизами
- Процесс RFC/CR: кто подаёт, кто согласует, критерии влияния (данные, SLA, безопасность).
- Change calendar: чёткий график, окна, freeze-периоды (например, закрытие месяца/квартала).
- Rollback plan: на каждый релиз.
- Коммуникации: кому и как сообщаем об изменениях (release notes, рассылки, Confluence).
Документация, обучение, приёмка в сопровождение
- Где живёт документация (Confluence/Git Wiki/Notion, single source of truth).
- Что именно документируется: архитектура, витрины/KPI, lineage, DQ-правила, SLA/SLO, глоссарий.
- Хэндоверы: чек-лист передачи в сопровождение (оператору/Службе поддержки).
- Обучение: кто обучается (бизнес/ИТ), форматы (видео, воркшопы), материалы.
- Критерии приёмки: наличие полной доки, тестов, мониторинга, runbooks, закрытых рисков из реестра.
Практическое задание
Задача: На основе своего кейса (или учебного) подготовьте раздел ТЗ с НФТ, интеграциями, безопасностью и эксплуатацией:
- Матрица НФТ (SLI/SLO/SLA) для ключевых подсистем (ETL-оркестратор, DWH/даталейк, BI/semantic layer, MDM, каталог данных/lineage).
- RPO/RTO-таблица + краткое описание DR-архитектуры и процедуры тестирования.
- Политика доступа и безопасность: роли/права (RBAC/ABAC), RLS/CLS, шифрование, аудит, журналирование.
- Интеграции: минимум 2 паттерна (например, CDC + Streaming/API). Для каждого — контракт, схема версионирования, идемпотентность, retries/backoff, DLQ, SLO.
- Наблюдаемость: список метрик, логов, трейсинга; правила алертинга + пример runbook.
- CI/CD: описание пайплайна, миграций, тестов, quality gates, управления секретами.
- Управление изменениями: RFC-процесс, календарь релизов, rollback-политика.
- Документация и приёмка: список обязательных артефактов и критерии готовности к prod.
Рубрика оценки (макс. 30 баллов)
|
Критерий |
0 баллов |
1 балл |
2 балла |
3 балла |
|---|---|---|---|---|
|
Матрица НФТ (SLI/SLO/SLA) |
Отсутствует |
Есть общие слова |
Есть метрики, но без измеримости/инструментов |
Полная, измеримая, привязана к инструментам и целям |
|
Производительность и масштабирование |
Нет |
Есть частично |
Есть цели, но без тестов |
Есть цели, тест-план и стратегия масштабирования |
|
RPO/RTO, DR |
Нет |
Указано одно из двух |
Есть оба, но без процедур тестирования |
Полный набор + процедуры тестирования и ретеншн бэкапов |
|
Безопасность (RBAC/ABAC, RLS/CLS, шифрование) |
Нет |
Частично |
Политики есть, но без SLA/аудита |
Полная модель, SLA IAM, аудит, ретеншн логов |
|
Интеграции (контракты, версионирование, устойчивость) |
Нет |
Частично |
Есть контракты, но слабые SLO/ретраи |
Полные контракты, SLO, retries, DLQ, идемпотентность |
|
Наблюдаемость (метрики/логи/трейсинг, алерты) |
Нет |
Частично |
Есть метрики и алерты |
Плюс error budgets, runbooks, postmortems |
|
CI/CD и миграции |
Нет |
Частично |
Есть процессы, но без quality gates |
Полный GitOps-подход, тесты, quality gates, секреты |
|
Управление изменениями и релизами |
Нет |
Частично |
Есть RFC/CR, но без календаря и rollback |
Полный процесс, календарь, rollback-планы |
|
Документация и приёмка |
Нет |
Частично |
Есть список артефактов |
Есть чек-лист приёмки, обучение, хэндовер |
Чек‑листы для автора ТЗ
NFR измеримость
- У каждого требования есть метрика, цель, способ измерения, инструмент.
- SLA/SLO/SLI различаются и согласованы.
- Есть error budget и правила, что делаем при его исчерпании.
Безопасность
- Роли и права определены, RLS/CLS зафиксированы.
- Шифрование на хранении и в движении описано.
- Секреты не хранятся в Git, есть политика ротации.
- Аудит: что, где, сколько хранится, как защищено.
Интеграции
- Контракты версионируются, есть policy на breaking changes.
- Есть политики retries/backoff/DLQ.
- Идемпотентность и гарантии доставки определены.
Эксплуатация
- Метрики, логи, трейсинг, алерты — определены и автоматизированы.
- Есть runbooks и postmortem-процесс.
- CI/CD покрывает схемы, тесты, quality gates.
- DR и бэкапы документированы и тестируются.
