Troubleshooting Data Governance

Симптомы

• Студент использует термины Data Governance и Data Management как синонимы
• Вопросы квиза о различиях governance/management кажутся непонятными
• Нет ясности, где заканчивается governance и начинается management

Причина

Data Governance -- это набор политик, ролей и процессов, обеспечивающих правильное управление данными. Data Management -- это практическая реализация этих политик (ETL, хранение, бэкапы). Governance определяет правила, Management их выполняет. DMBOK2 чётко разделяет эти области.

Решение

1. Governance = ЧТО и ЗАЧЕМ (политики, стандарты, роли, метрики)
2. Management = КАК и КОГДА (инструменты, процессы, инфраструктура)
3. Пример: Governance решает "все PII данные должны быть зашифрованы", Management реализует шифрование в конкретной СУБД
4. Повторите урок 1 модуля M01 (Что такое Data Governance)

Связанные уроки:

Симптомы

• Студент не уверен в русском эквиваленте английского термина governance
• Конфликт между разными переводами одного термина в разных источниках
• Квизы используют термины, которые отличаются от привычных студенту

Причина

Курс использует DMBOK2 (русское издание, ISBN 978-5-9693-0404-8) как терминологический авторитет. Другие источники могут использовать иные переводы. Например: "Data Steward" = "Стюард данных" (не "Администратор данных"), "Data Lineage" = "Происхождение данных" (не "Линейность данных").

Решение

1. Все термины курса основаны на глоссарии DMBOK2 (русское издание)
2. При первом использовании термин всегда даётся в формате: Русский Термин (English Term)
3. Сверяйтесь с глоссарием курса через Cmd+K или страницу глоссария
4. Если в квизе встречается незнакомый термин -- ищите его в глоссарии курса

Связанные уроки:

Симптомы

• Студент неверно определяет уровень зрелости организации
• Путаница между Level 2 (Managed) и Level 3 (Defined)
• Scorer в код-челлендже CC-01 возвращает неожиданный результат

Причина

Модель зрелости использует 5 уровней: 1 (Initial/Ad-hoc), 2 (Managed), 3 (Defined), 4 (Quantitatively Managed), 5 (Optimizing). Общий уровень определяется средним арифметическим с округлением вниз (floor). Если хотя бы одно измерение ниже целевого -- общий уровень не может превышать среднее.

Решение

1. Уровень зрелости = floor(среднее всех измерений)
2. Проверьте каждое измерение: data quality, metadata, security, privacy, stewardship
3. Для Level 3 нужно: все измерения >= 2, среднее >= 3.0
4. Повторите урок 5 модуля M01 (Бизнес-кейс и зрелость)

Связанные уроки:

Симптомы

• Студент путает ответственности Data Steward и Data Owner
• Ошибки в RACI-матрице при определении ролей
• Неправильное назначение ролей в сценариях код-челленджей

Причина

Data Owner -- бизнес-руководитель, ответственный за данные домена (принимает решения). Data Steward -- операционный эксперт, обеспечивающий качество и соответствие стандартам (выполняет политики). Data Custodian -- технический специалист, управляющий инфраструктурой хранения (поддерживает системы).

Решение

1. Data Owner = ОТВЕЧАЕТ за данные (бизнес, стратегия, бюджет)
2. Data Steward = УПРАВЛЯЕТ качеством данных (стандарты, метаданные, профилирование)
3. Data Custodian = ОБСЛУЖИВАЕТ инфраструктуру (БД, бэкапы, доступы)
4. Мнемоника: Owner решает ЧТО, Steward контролирует КАК, Custodian обеспечивает ГДЕ
5. Повторите урок 3 модуля M01 (Организация governance)

Связанные уроки:

Симптомы

• Код-челлендж показывает "Execution timeout: 10s limit exceeded"
• Python-функция работает бесконечно или очень долго
• Статус: TIMEOUT вместо PASS/FAIL

Причина

Pyodide runner имеет жёсткий лимит 10 секунд на выполнение. Типичные причины: бесконечный цикл (while True без break), вложенные циклы O(n^3) на больших данных, рекурсия без базового случая, print() в цикле (вывод замедляет выполнение).

Решение

1. Проверьте циклы на наличие условия выхода
2. Замените вложенные циклы на словари/множества для O(1) поиска
3. Убедитесь, что рекурсия имеет базовый случай и глубина ограничена
4. Удалите отладочные print() из циклов перед отправкой
5. Все код-челленджи курса решаемы за < 2 секунды при правильном подходе

Симптомы

• Ошибка "no such table: ..." при выполнении SQL запроса
• SELECT возвращает пустой результат вместо ожидаемых данных
• Код-челлендж не инициализирует тестовые данные

Причина

SQL код-челленджи используют sql.js (SQLite в браузере). Тестовые таблицы создаются автоматически из раздела setup в конфигурации челленджа. Ошибка возникает при обращении к таблице с неверным именем или при использовании синтаксиса, несовместимого с SQLite.

Решение

1. Проверьте имена таблиц в описании челленджа (раздел "Доступные таблицы")
2. SQLite не поддерживает: FULL OUTER JOIN, RIGHT JOIN, некоторые оконные функции
3. Используйте одинарные кавычки для строк, двойные -- для идентификаторов
4. Если нужен ILIKE -- используйте LIKE с функцией LOWER(): WHERE LOWER(col) LIKE '%text%'

Симптомы

• Ошибка "JSON does not match expected schema"
• Тесты показывают FAIL с сообщением о недостающих полях
• JSON синтаксически корректен, но не проходит валидацию

Причина

JSON-validator проверяет структуру строго: все обязательные поля должны присутствовать, типы значений должны совпадать (строка vs число), массивы должны содержать минимальное количество элементов. Лишние поля обычно допускаются, но пропущенные -- нет.

Решение

1. Внимательно прочитайте описание ожидаемой структуры в задании
2. Проверьте, что все обязательные поля указаны (required fields)
3. Убедитесь, что типы данных совпадают: числа без кавычек, строки в кавычках
4. Массивы: проверьте минимальное количество элементов ("rules" обычно >= 3)
5. Для отладки: используйте JSON.parse() в консоли браузера для проверки синтаксиса

Симптомы

• Ошибка "bad indentation" или "mapping values are not allowed here"
• YAML выглядит правильно, но не проходит парсинг
• Вложенные элементы не распознаются корректно

Причина

YAML-validator чувствителен к отступам. Типичные ошибки: смешивание табов и пробелов (YAML допускает только пробелы), непоследовательные отступы (2 vs 4 пробела в одном файле), пропущенный пробел после двоеточия, неправильная вложенность списков.

Решение

1. Используйте ТОЛЬКО пробелы (не табы) для отступов
2. Выберите один размер отступа (2 пробела рекомендуется) и соблюдайте везде
3. После каждого ":" должен быть пробел: "key: value", не "key:value"
4. Элементы списка ("-") должны иметь тот же отступ, что и ключ родителя + 2 пробела
5. Строки со спецсимволами оборачивайте в кавычки: "value: with colon"

Симптомы

• JavaScript код-челлендж показывает FAIL, хотя console.log выводит правильный результат
• Тесты ожидают возврат значения, но получают undefined
• Функция выполняется без ошибок, но результат не захватывается

Причина

js-sandbox runner захватывает возвращаемое значение функции (return), а не вывод в console. console.log() выводит в лог для отладки, но не является результатом выполнения. Тесты проверяют именно return value.

Решение

1. Убедитесь, что функция завершается оператором return с нужным значением
2. console.log() можно использовать для отладки, но результат -- только через return
3. Если нужно вернуть объект: return { key: value }, не console.log({ key: value })
4. Проверьте, что return находится внутри функции, а не на верхнем уровне

Симптомы

• Урок отображается, но секция код-челленджа отсутствует
• Квиз отображается, но без интерактивного редактора кода
• Код-челлендж виден в JSON файле, но не рендерится на странице

Причина

Несоответствие поля lessonSlug в JSON-файле квиза и фактического пути MDX-файла урока. Квиз привязывается к уроку через lessonSlug, и если путь не совпадает -- квиз не находится и не отображается.

Решение

1. Проверьте lessonSlug в JSON файле квиза (без расширения .mdx)
2. Формат lessonSlug: "module-dir/lesson-file" (например: "01-foundations/03-governance-organization")
3. Убедитесь, что MDX файл существует по указанному пути в src/content/course/
4. Перезапустите dev-сервер после изменений в JSON файлах квизов

Симптомы

• Функция подсчёта качества возвращает неверный процент
• Измерения полноты (completeness) или точности (accuracy) не совпадают с ожидаемыми
• Тесты код-челленджа CC-13 или CC-14 не проходят

Причина

Quality dimensions имеют строгие формулы. Completeness = (non-null values / total values) * 100. Accuracy проверяется по reference dataset. Freshness -- разница между current_timestamp и last_updated. Ошибки возникают при неправильном округлении, игнорировании пустых строк ("" vs NULL), или неверной обработке граничных случаев.

Решение

1. Completeness: считайте NULL и пустые строки ('') как missing values
2. Accuracy: сравнивайте с reference dataset case-insensitive (lower())
3. Freshness: используйте единый формат дат (ISO 8601), учитывайте timezone
4. Округляйте до 2 десятичных знаков: round(value, 2)
5. Повторите урок 1 модуля M04 (Измерения качества данных)

Связанные уроки:

Симптомы

• YAML код-челлендж для dbt тестов не проходит валидацию
• Ошибка "expected block end" или "did not find expected key"
• dbt тесты не распознают custom test конфигурацию

Причина

dbt использует специфическую YAML структуру для тестов. Частые ошибки: неправильная вложенность columns внутри models, пропуск обязательного поля name, неверный синтаксис custom test (config: severity: warn вместо правильного формата).

Решение

1. Структура: models -> [name, columns -> [name, tests -> [...]]]
2. Каждый test -- это либо строка ("not_null"), либо объект ({accepted_values: {values: [...]}})
3. Проверьте вложенность: columns на 2 уровня глубже, чем models
4. severity указывается внутри config: {config: {severity: warn}}
5. Повторите урок 5 модуля M04 (dbt quality tests)

Связанные уроки:

Симптомы

• Код-челлендж CC-18 (GE suite) возвращает unexpected results
• Expectation suite проходит на одних данных и падает на других
• Непонятно, как указать порог (threshold) для expectation

Причина

Great Expectations использует декларативный подход: каждый expectation определяет ожидаемое свойство данных. Ошибки возникают при неправильных параметрах (mostly vs. strict), неверных пороговых значениях, или непонимании разницы между column-level и table-level expectations.

Решение

1. mostly=0.95 означает "минимум 95% значений должны соответствовать"
2. Без mostly -- проверка strict (100%)
3. expect_column_values_to_not_be_null != expect_column_to_exist
4. Для JSON-структуры suite: meta, expectations[], expectation_type, kwargs
5. Повторите урок 6 модуля M04 (Great Expectations)

Связанные уроки:

Симптомы

• Функция классификации PII не находит все поля с персональными данными
• Классификатор помечает нерелевантные поля как PII
• Код-челлендж CC-20 выдаёт неверное количество PII-полей

Причина

PII-классификация в курсе использует rule-based подход (фиксированные паттерны, не ML). Ошибки: неполный набор паттернов (пропущены email, phone, passport), нечувствительность к регистру (Email vs email), ложноположительные из-за слишком широких паттернов (любое слово "name" помечается как PII).

Решение

1. Проверьте полный список PII-паттернов: email, phone, ssn/inn, passport, address, birth_date, full_name
2. Используйте case-insensitive matching: column_name.lower()
3. Различайте: "product_name" (не PII) vs "customer_name" (PII) -- контекст важен
4. Проверяйте и имя колонки, и содержимое (если доступно)
5. Повторите урок 2 модуля M05 (Обнаружение PII)

Связанные уроки:

Симптомы

• Валидатор согласия не обрабатывает случай частичного consent
• Отзыв (revocation) согласия не меняет статус обработки
• Код-челлендж CC-21 не учитывает expiration date согласия

Причина

Consent management имеет несколько граничных случаев: согласие может быть partial (на одни цели дано, на другие нет), может быть отозвано (revoked -- дата отзыва позже даты согласия), может истечь (expired -- превышен срок действия). Все три случая должны обрабатываться отдельно.

Решение

1. Проверяйте каждую цель (purpose) отдельно: marketing, analytics, third_party
2. Статус consent: active (дано, не истекло, не отозвано), revoked, expired
3. Приоритет: revoked > expired > active (отзыв перекрывает всё)
4. Дата сравнения: consent_date < current_date < expiry_date для active
5. Повторите урок 3 модуля M05 (Управление согласиями)

Связанные уроки:

Симптомы

• Маскированные данные имеют другую длину или формат
• Email после маскирования не содержит @ и домен
• Телефон маскирован полностью вместо сохранения последних 4 цифр

Причина

Format-preserving masking должен сохранять структуру оригинальных данных. Email: j***@example.com (первая буква + маска + домен). Телефон: ***-***-1234 (маска + последние 4 цифры). ИНН: ********12 (маска + последние 2). Нарушение формата делает данные непригодными для тестирования.

Решение

1. Email: сохраняйте первый символ, @, и домен: masking("[email protected]") = "j***@mail.com"
2. Телефон: сохраняйте последние 4 цифры: masking("89161234567") = "*******4567"
3. ИНН/SSN: маскируйте всё кроме последних 2-4 символов
4. Общее правило: длина результата = длина оригинала
5. Повторите урок 4 модуля M05 (Маскирование данных)

Связанные уроки:

Симптомы

• Политика доступа разрешает и запрещает одно действие одновременно
• Код-челлендж CC-29 возвращает неверное решение доступа
• Непонятно, какое правило имеет приоритет при конфликте

Причина

В RBAC/ABAC при конфликте правил (одно разрешает, другое запрещает) применяется принцип deny-overrides: запрет всегда побеждает. Ошибки возникают при неправильной оценке порядка правил или непонимании наследования ролей (роль с deny на уровне группы перекрывает allow на уровне пользователя).

Решение

1. Принцип: deny ВСЕГДА перекрывает allow (deny-overrides)
2. Порядок оценки: 1) собрать все applicable rules, 2) если есть хотя бы один deny -- запретить
3. RBAC: проверяйте все роли пользователя (прямые + наследованные)
4. ABAC: оценивайте все атрибуты (subject, resource, action, environment)
5. Повторите уроки 2-3 модуля M06 (RBAC и ABAC)

Связанные уроки:

Симптомы

• Место диаграммы пустое или показывает ошибку рендеринга
• Компонент загрузился, но данные не отображаются
• Консоль браузера показывает "Hydration mismatch" или React ошибку

Причина

Governance-диаграммы (OrgChart, MaturityModel, ClassificationTree и др.) -- это React-компоненты, требующие client:load для гидрации в Astro. Если пропущена директива client:load, компонент рендерится только на сервере и не интерактивен. Другие причины: неправильный формат props (nodes вместо tree), пропущенные обязательные поля.

Решение

1. Убедитесь, что в MDX-файле компонент использует client:load:
2. Проверьте props: каждый компонент имеет специфические обязательные поля
3. ClassificationTree: tree (не nodes!), OrgChart: nodes + connections
4. Очистите кэш браузера и перезагрузите страницу
5. В dev-режиме: перезапустите dev-сервер после изменений в MDX

Симптомы

• Текст RegulationRef подчёркнут, но popover не показывается
• Popover появляется за пределами видимой области
• На мобильном устройстве RegulationRef не работает

Причина

RegulationRef использует createPortal для span-based popover (не div, чтобы не ломать inline HTML в MDX). Popover появляется при hover (desktop) или touch (mobile). Проблемы: z-index конфликт с другими элементами, overflow:hidden на родительском контейнере, или отсутствие client:load на компоненте.

Решение

1. Проверьте, что RegulationRef импортирован и имеет client:load
2. RegulationRef работает inline (внутри

   ) -- не оборачивайте в div

3. Если popover обрезается: проверьте overflow CSS на родительских элементах
4. На мобильных: используйте tap вместо hover

Связанные уроки:

Симптомы

• Урок загружается, но квиз внизу страницы отсутствует
• Счётчик прогресса не обновляется после прочтения урока
• В навигации нет индикатора квиза для конкретного урока

Причина

Квиз привязывается к уроку через lessonSlug в JSON-файле. Если lessonSlug не совпадает с путём MDX-файла, квиз не будет отображён. Также возможно: JSON-файл содержит ошибку валидации (Zod schema), или квиз пуст (0 вопросов).

Решение

1. Проверьте lessonSlug в JSON: должен совпадать с путём MDX (без расширения)
2. Пример: для урока course/01-foundations/03-governance-organization.mdx slug = "01-foundations/03-governance-organization"
3. Убедитесь, что JSON валиден: node -e "require('./path/to/quiz.json')"
4. Проверьте, что массив questions не пуст (min 1 вопрос требуется Zod-схемой)

Симптомы

• Квиз пройден успешно, но progress bar не изменился
• Dashboard показывает старые данные
• Модуль не помечается как завершённый после прохождения всех квизов

Причина

Прогресс сохраняется в localStorage браузера. Если localStorage переполнен, отключён, или используется приватный режим -- прогресс не сохраняется. Также: разные URL (с www и без) имеют разные localStorage хранилища.

Решение

1. Проверьте localStorage: DevTools -> Application -> Local Storage
2. Убедитесь, что браузер не в приватном режиме
3. Используйте один и тот же URL (с или без www) для всех занятий
4. Для сброса: очистите localStorage данного домена и пройдите квизы заново