Retention і політики зберігання

1) Принципи

1. Purpose & Minimization. Зберігаємо рівно те і рівно стільки, скільки потрібно цілям обробки.
2. Policy as Code. Ретеншен - це виконувана політика, а не PDF.
3. Defense in Depth. TTL/ILM + шифрування + аудити + Legal Hold.
4. Reversibility & Proof. Видалення перевіряється: логи дій, крипто-шреддінг, звіт про дотримання.
5. Cost & Carbon Aware. Ретеншен враховує $/ГБ-міс і вуглецевий слід зберігання/egress.

2) Класифікація даних і «карта ретеншену»

• Операційні (OLTP): замовлення, платежі, сесії.
• Аналітичні (DWH/дати): події, лог-факти, зрізи.
• Персональні (PII/фінанси/здоров'я): вимагають спеціальних термінів і прав суб'єктів.
• Технічні: логи, метрики, трейси, артефакти CI.
• Документи/медіа: WORM/архів/легасі.

Для кожного класу задайте: власник, мета, правова база, терміни, рівень захисту, поточні та цільові сховища.

3) ILM: життєвий цикл даних

1. Ingest (hot) → NVMe/SSD, висока частота запитів.

2. Warm → рідше читається, компресія, колонкові формати.

3. Cold/Archive → об'єктне/стрічкове, довгий доступ.

4. Purge/Delete → гарантоване видалення (вкл. репліки/бекапи).

yaml dataset: events_main owner: analytics purpose: "product analytics"
classification: "pseudonymized"
lifecycle:
- phase: hot; duration: 7d; storage: nvme; format: row
- phase: warm; duration: 90d; storage: ssd; format: parquet; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d privacy:
pii: false dp_delete_window: 30d # SLA on personal deletions if ligaments appear

4) Політики як код (корисні скетчі)

4. 1 Admission-політика (обов'язкові теги/TTL)

yaml policy: require-retention-tags deny_if_missing: [owner, purpose, classification, retention]
default_retention:
logs:  "30d"
traces: "7d"
metrics:"90d"

4. 2 Gate в CI/CD (Rego) - заборона деплоя без ретеншену

rego package policy. retention deny[msg] {
some d input. datasets[d].retention == ""
msg:= sprintf("Retention missing for dataset %s", [d])
}

4. 3 S3/об'єктне (фрагмент lifecycle)

yaml
Rules:
- ID: logs-ttl
Filter: { Prefix: "logs/" }
Transitions:
- { Days: 7, StorageClass: STANDARD_IA }
- { Days: 30, StorageClass: GLACIER }
Expiration: { Days: 180 }
NoncurrentVersionExpiration: { NoncurrentDays: 30 }

5) Retention в потоках і чергах

• `retention. ms`/`retention. bytes'- віконний ретеншен.
• Compaction (`cleanup. policy = compact') - зберігаємо останнє значення ключа.
• Tiered Storage - відводимо «хвіст» в холодний тир.
• DLQ - окремий ретеншен і TTL.

properties cleanup. policy=delete,compact retention. ms = 604800000 # 7d for tail removal
min. cleanable. dirty. ratio=0. 5 segment. ms=86400000

• Визначте ретеншен ключових топіків ≈ бізнес-вікно реплея/перерахунку.
• Для подій білінг/аудит - окремий довгий ретеншен або WORM.

6) Бази даних і ретеншен

• Партіонування за датою/діапазоном, detach & drop старих партій.
• Поля з датою - індекси для TTL-запитів.
• Темпоральні таблиці (system-versioned) + полісі purge старих версій.

sql
-- Monthly instalments
CREATE TABLE audit_events (id bigserial, occurred_at timestamptz, payload jsonb) PARTITION BY RANGE (occurred_at);
-- Cleaning over 365 days
DELETE FROM audit_events WHERE occurred_at < now() - interval '365 days';
VACUUM (FULL, ANALYZE) audit_events;

• TTL на рівні ключів (MongoDB TTL index, Redis'EXPIRE', Cassandra TTL).
• Downsampling для метрик (сирі 7д → аггрегати 90д → довгі 365д).
• Політики retention в TSDB (Influx/ClickHouse Materialized Views з дедуп/агрегацією).

7) Логи, метрики, трейси

Логи: обмежити поля, маскувати ПД, TTL 7-30д, архів 90-180д.
Метрики: сирі високочастотні - 7-14д; downsample (5m/1h) — 90–365д.
Трейси: tail-sampling і зберігання «цікавих» (помилки/хвости) довше.

yaml observability:
logs:  { ttl: "30d", archive: "90d", pii_mask: true }
metrics: { raw: "14d", rollup_5m: "90d", rollup_1h: "365d" }
traces: { sample: "tail-10%", ttl: "7d", error_ttl: "30d" }

8) Видалення: типи і гарантії

Логічне (soft-delete): позначка запису; зручно для відновлення, не підходить під «право на видалення».
Фізичне (hard-delete): фактичне видалення даних/версій/реплік.
Криптографічне (crypto-erasure): видалення/заміна ключів шифрування, після чого дані не відновлюються.
Каскадне: наскрізне видалення деривацій (кеші, індекси, аналітика).

request → locate subject data (index by subject_id) → revoke tokens & unsubscribe jobs → delete in OLTP → purge caches → enqueue erasure in DWH/lakes → crypto-shred keys (per-tenant/per-dataset) → emit audit proof (receipt)

9) Право на видалення, Legal Hold і eDiscovery

Право на видалення/виправлення: SLA виконання (наприклад, ≤30 днів), трасовані дії, квитанції.
Legal Hold: при юридичному запиті - заморожування видалення для зазначених наборів/ключів; політика пріоритету над TTL.
eDiscovery: каталог даних, повнотекстовий/атрибутивний пошук за артефактами, експорт в узгоджених форматах.

yaml legal_hold:
dataset: payments scope: ["txn_id:123", "user:42"]
from: "2025-10-31"
until: "2026-03-31"
reason: "regulatory investigation"

10) Бекапи vs архіви vs WORM

Бекапи - для відновлення від втрати/псування; короткий ретеншен, швидкий RTO.
Архіви - довгострокове зберігання для аудиту/аналітики, дешеві, довгий доступ.
WORM - незмінні носії для комплаєнсу (фінанси/звітність); політики «write-once, read-many».

• Не розраховуйте бекап як «архів на століття».
• Репетиції відновлення (DR-дні), звіт про час і повноту.
• Каталог бекапів з ретеншеном, шифруванням і ключами окремо від сховища.

11) Приватність і анонімізація

Псевдонімізація: відкладена прив'язка PII через таблицю ключів (дозволяє crypto-erasure по ключу).
Анонімізація: незворотні техніки (k-анонімність, шум, узагальнення); документуйте метод, ризик реідентифікації та термін придатності.

12) Моніторинг відповідності та звітність

Контрольні панелі: частка датасетів з валідним ретеншеном, обсяги за фазами ILM, помилки видалення.
Алерти: перевищення цільового обсягу в гарячому тирі, «підвислі» видалення, що закінчуються Legal Hold.
Звіти: місячний аудит видалення (кількість запитів, середній термін, невдачі), роздруківка крипто-шреддингу.

13) Інтеграція в процеси: гейти і рев'ю

Design-gate: новий датасет не проходить рев'ю без'owner/purpose/retention'.
Release-gate: міграції, що збільшують ретеншен без власника/обґрунтування - блокуються.
Cost-gate: обсяг в hot/warm перевищує бюджет - тригер на ILM-посилення.
Security-gate: заборона включення ПД в логи/трейси без маскування і TTL.

14) Анти-патерни

«Зберігаємо все назавжди - раптом стане в нагоді».
Жорстко кодовані TTL в додатках, не винесені в політики.
ПД в логах і трейсах без маскування/TTL/видалення.
Неповне видалення (залишили в кеші/DWH/бекапах).
Відсутність Legal Hold - стирання даних під розслідуванням.
Один загальний ключ шифрування на все - неможливо точково «крипто-стерти».
Нульова спостережуваність: «віримо, що видалили», але доказів немає.

15) Чек-лист архітектора

1. Для кожного датасета є owner, purpose, classification, retention, storage tier?
2. Політики ILM/TTL задекларовані як код і застосовуються автоматично?
3. ПД маскуються в логах/трейсах; заборонені поза «білими» наборами?
4. Є процеси персональних видалень (SLA, аудит, квитанції)?
5. Crypto-erasure можливий (пер-тенант/пер-датасет ключі, KMS/rotation)?
6. Бекапи: розклад, шифрування, тести відновлення, окремі ключі?
7. Legal Hold/eDiscovery: підтримуються, превалюють над TTL, журнали дій ведуться?
8. Kafka/черги: заданий ретеншен/compaction/тiering, DLQ має окремі політики?
9. Метрики та алерти на дотримання ретеншену та обсяги за тирами налаштовані?
10. Рев'ю і гейти в SDLC блокують артефакти без ретеншену?

16) Міні-рецепти

16. 1 ClickHouse: «відсікти хвіст» старше 180 днів

sql
ALTER TABLE events DELETE WHERE event_date < today() - 180;
OPTIMIZE TABLE events FINAL;

16. 2 Redis: TTL и lazy-purge

bash
SET session:123 value EX 3600
CONFIG SET maxmemory-policy allkeys-lru

16. 3 Tail-sampling для трас

yaml tail_sampling:
policies:
- name: keep-errors-and-slow latency_threshold_ms: 500 status_codes: ["5xx"]
rate_limit_per_min: 5000 default_ttl: "7d"

16. 4 Crypto-erasure (ідея)

keys:
dataset: users_pii key_id: kms://pii/users/tenant-42 erase(user_id=42):
rotate_or_destroy (key_id) # inability to restore former purge_indexes blocks ("user _ id = 42")
audit("crypto-erasure", user_id)

Висновок

Політики зберігання - це «скелет» вашої платформи даних: вони описують, скільки живуть різні класи даних, де вони знаходяться в кожен момент, як дешевшають з часом і коли зникають без сліду - законно, прозоро і перевіряється. Зробіть ретеншен політикою як код, з'єднайте ILM з безпекою і вартістю, включіть спостережуваність і гейти - і ви отримаєте систему, яка одночасно ефективна, комплаєнтна і готова до зростання.