Политики и стандарты governance
Введение
Политики — это формальное выражение governance-решений. Без политик governance остаётся набором устных договорённостей, которые забываются, интерпретируются по-разному и не переживают смену команды. В этом уроке мы разберём иерархию governance-документов, научимся писать эффективные политики и рассмотрим, как обеспечить их реальное соблюдение.
Иерархия governance-документов
Governance-документы организованы в иерархию по уровню абстракции:
Различия уровней
| Уровень | Вопрос | Пример | Кто утверждает | Частота обновления |
|---|---|---|---|---|
| Data Principles (принципы данных) | Почему? | ”Данные — актив организации” | CEO / Board | Раз в 3-5 лет |
| Data Policy (политика данных) | Что? | ”PII хранится не дольше 3 лет” | Data Council | Раз в год |
| Data Standards (стандарты данных) | Как? | “snake_case для всех таблиц” | CDO / Stewards | По необходимости |
| Процедуры | Шаг за шагом | ”Откройте JIRA, выберите тип ‘Data Access Request‘“ | Stewards | По необходимости |
Анатомия governance-политики
Каждая Data Policy (политика данных) должна содержать обязательные разделы:
Требования к качественной политике
- Конкретность — “все данные с PII — конфиденциальные” лучше, чем “данные должны быть защищены”
- Измеримость — “классифицировать в течение 30 дней” лучше, чем “классифицировать своевременно”
- Enforcement — каждая политика должна содержать раздел о механизме контроля
- Исключения — явно указать, что НЕ покрывает политика
- Владелец — конкретное лицо, ответственное за политику
Жизненный цикл политики
Политики не статичны — они проходят через жизненный цикл:
Типичные ошибки
| Ошибка | Последствие | Решение |
|---|---|---|
| Слишком абстрактная политика | Невозможно проверить соблюдение | Конкретные правила с числовыми критериями |
| Нет enforcement | Политика “на бумаге” | Раздел enforcement с автоматизацией |
| Нет владельца | Никто не обновляет | Конкретное лицо + дата пересмотра |
| Слишком много политик | Никто не читает | 5-7 ключевых политик на Level 2-3 |
| Нет исключений | Бюрократическая нагрузка | Явные исключения с условиями |
Сценарий: DataTech формулирует первые политики
Сценарий: DataTech Solutions (ДатаТех Солюшенз)
Data Council DataTech определил 5 приоритетных политик для первого года:
- Data Classification Policy — классификация данных по уровням (см. шаблон выше)
- Data Access Policy — кто и как получает доступ к данным
- Data Retention Policy — сроки хранения по категориям
- Data Quality Policy — стандарты качества и мониторинг
- Naming Convention Standard — правила именования таблиц и столбцов
Почему 5, а не 47 (как у FinSecure)? На Level 1-2 лучше иметь 5 реально работающих политик, чем 47 декларативных.
Практика: валидация политики
В этом модуле вы встретите код-челлендж CC-03 (Governance Policy Template Validator): JSON-задание, в котором нужно создать валидный governance-документ со всеми обязательными разделами (policy_id, title, version, effective_date, owner, scope, definitions, rules, enforcement, review_schedule).
Отслеживание соответствия политикам
Как убедиться, что политики соблюдаются? Для каждой политики ведётся compliance checklist:
- 01Все датасеты в PostgreSQL классифицированы0 из 200+ таблиц классифицированы✗Не соответствует
- 02Все датасеты в ClickHouse классифицированыdbt-модели без метаданных классификации✗Не соответствует
- 03PII-данные помечены как Confidential/RestrictedНет инвентаризации PII✗Не соответствует
- 04Steward проводит ежемесячный обзорSteward назначен, обзор не проводился~Частично
- 05Автоматические проверки в каталогеКаталог ещё не развёрнут—Неприменимо
Текущий статус DataTech показывает типичную картину для Level 1: политика утверждена, но compliance = 0%. Это нормально — enforcement приходит на этапах 4-5 жизненного цикла, после внедрения инструментов.
Для сравнения: ФинСекьюр Банк
FinSecure (Level 3) имеет 47 политик, но enforcement проверяется только на годовом аудите. Результат: compliance 85% для core banking (автоматизированные проверки) и 45% для микросервисов (ручные проверки). Урок для DataTech: лучше 5 политик с автоматическим enforcement, чем 47 с ежегодным аудитом.
Стандарты как реализация политик
Data Standards (стандарты данных) — это конкретные технические правила, реализующие политики:
Политика: "Все таблицы должны именоваться единообразно"
↓
Стандарт: "Используйте snake_case для имён таблиц и столбцов"
↓
Пример: customer_addresses (верно), customerAddresses (нарушение)Примеры стандартов для DataTech:
| Стандарт | Правило | Проверка |
|---|---|---|
| Naming | snake_case для таблиц и столбцов | Автоматизируемо |
| Даты | ISO 8601 (2024-01-15T10:30:00Z) | Автоматизируемо |
| Null | NOT NULL по умолчанию, NULL — осознанное решение | Автоматизируемо |
| PII | Столбцы с PII маркируются комментарием -- PII | Автоматизируемо |
| Documentation | Каждая таблица имеет описание в каталоге | Автоматизируемо |
Ключевое правило: стандарт должен быть автоматизируемо проверяем. Если стандарт нельзя проверить автоматически, его соблюдение невозможно масштабировать.
Итоги
- Governance-документы имеют иерархию: принципы -> политики -> стандарты -> процедуры
- Качественная Data Policy (политика данных) конкретна, измерима, имеет enforcement и владельца
- Жизненный цикл: черновик -> обсуждение -> утверждение -> внедрение -> мониторинг -> пересмотр
- На Level 1-2 лучше 5 реально работающих политик, чем 47 декларативных
- Стандарты должны быть автоматизируемо проверяемыми
- Compliance checklist отслеживает реальное соблюдение каждой политики
Политики определяют правила, но некоторые типы данных требуют специализированных governance-процессов. Master Data (мастер-данные) — клиенты, продукты, поставщики — пересекают все домены и все политики. Дубликаты мастер-данных (DataTech обнаружила 15% дубликатов клиентов) подрывают quality, compliance и analytics одновременно. В следующем уроке мы изучим Master Data Management (MDM) — системный подход к управлению мастер-данными, включая архитектурные паттерны, golden record и правила выживания данных.