Нет. Это sandbox/demo-платформа с production-подходами. Цель - быстро проверять архитектурные и бизнес-гипотезы, не подменяя полноценный enterprise-контур.
Потому что есть воспроизводимый E2E-поток (ingestion -> DWH -> витрины), наблюдаемость и базовые quality checks. Уровень доверия ограничен рамками стенда и явно отражён в gaps/roadmap.
Сокращение времени от бизнес-вопроса до проверяемого ответа через стандартизированные витрины, мониторинг и повторяемые сценарии use cases.
Закрыть P0/P1 gaps: формализовать SLO и ownership, усилить release-gates и incident process, закрепить security/access governance.
- Общая картина: PROJECT_SUMMARY.md
- Структура репозитория: ARCHITECTURE.md
- Диаграммы: diagrams/README.md
Smoke ingress + health ключевых сервисов + dbt DQ + проверка свежести витрин + rollback-checklist. Детали: QUALITY_AND_MONITORING.md.
Базовый маршрут: runbook/AIRFLOW_DAG_TROUBLESHOOTING.md, затем метрики/логи из OBSERVABILITY_AND_LOGGING.md.
Если DAG зелёный, но метрики/витрины неверные - начинать с DQ и dbt-тестов. Если DAG падает/запаздывает - сначала оркестрация, dependency chain и инфраструктурные метрики.
Это вспомогательный слой для стенда, не замена governed BI. Для production-режима нужны policy guardrails (read-only, whitelist, audit, limits) и governance.
Есть owner, baseline KPI, целевой KPI и acceptance criteria; сценарий встроен в roadmap и связан с источниками/витриной/мониторингом.