Retention va saqlash siyosati

1) Qonunning

1. Purpose & Minimization. Ishlov berish maqsadlari uchun kerakli miqdorda saqlaymiz.
2. Policy as Code. Retenshen - bu PDF emas, balki amalga oshiriladigan siyosat.
3. Defense in Depth. TTL/ILM + shifrlash + auditlar + Legal Hold.
4. Reversibility & Proof. O’chirish tekshiriladi: harakatlar daftarlari, kripto-shredding, rioya qilish to’g "risidagi hisobot.
5. Cost & Carbon Aware. Retenshen $/GB-oy va uglerod saqlash/egress izini hisobga oladi.

2) Ma’lumotlarni tasniflash va «retenshen xaritasi»

• Operatsion (OLTP): buyurtmalar, to’lovlar, sessiyalar.
• Tahliliy (DWH/sanalar): voqealar, log-faktlar, kesrlar.
• Shaxsiy (PII/moliya/salomatlik): sub’ektlarning maxsus muddatlari va huquqlarini talab qiladi.
• Texnik: loglar, metriklar, treyslar, CI artefaktlari.
• Hujjatlar/media: WORM/arxiv/legasi.

Har bir sinf uchun: egasi, maqsadi, huquqiy bazasi, muddati, himoyalanish darajasi, joriy va maqsadli omborlar.

3) ILM: ma’lumotlarning hayot sikli

1. Ingest (hot) → NVMe/SSD, so’rovlarning yuqori chastotasi.

2. Warm → kamroq o’qiladi, kompresssiya, ustunli formatlar.

3. Cold/Archive → obʼekt/tasma, uzoq kirish.

4. Purge/Delete → olib tashlash kafolatlangan.

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) Kod sifatida siyosatlar (foydali eskizlar)

4. 1 Admission-siyosat (majburiy teglar/TTL)

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

4. CI/CD (Rego) ga 2 Gate - retenshensiz deployni taqiqlash

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

4. 3 S3/obyekt (lifecycle fragmenti)

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) Oqimlarda va navbatlarda retention

• `retention. ms`/`retention. bytes’- deraza retensheni.
• Compaction (`cleanup. policy = compact’) - kalitning oxirgi qiymatini saqlaymiz.
• Tiered Storage - «dumni» sovuq tirga olib boramiz.
• DLQ - alohida retenshen va TTL.

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

• Asosiy topiklarning retenshenini ≈ replay/qayta hisoblash biznes oynasini aniqlang.
• Voqealar uchun billing/audit - alohida uzoq retenshen yoki WORM.

6) Ma’lumotlar bazasi va retenshen

• Sana/diapazon bo’yicha partiyalashtirish, eski partiyalarni detach & drop.
• Sana maydonlari - TTL soʻrovlari uchun indekslar.
• Vaqtinchalik jadvallar (system-versioned) + eski versiya polislari 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;

• Kalitlar darajasidagi TTL (MongoDB TTL index, Redis’EXPIRE’, Cassandra TTL).
• Metriklar uchun Downsampling (xom 7d → aggregatlar 90d → uzunligi 365d).
• TSDBdagi retention siyosati (dedup/agregatsiyali Influx/ClickHouse Materialized Views).

7) Loglar, metriklar, treyslar

Logi: maydonlarni cheklash, niqoblash PD, TTL 7-30d, arxiv 90-180d.
Metriklar: xom yuqori chastotali - 7-14d; downsample (5m/1h) — 90–365д.
Treyslar: tail-sampling va «qiziqarli» (xatolar/dumlar) ni saqlash.

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) Olib tashlash: turlari va kafolatlari

Mantiqiy (soft-delete): yozuvni belgilash; tiklash uchun qulay, «olib tashlash huquqiga» mos kelmaydi.
Jismoniy (hard-delete): maʼlumotlarni/versiyalarni/replikalarni amalda olib tashlash.
Kriptografik (crypto-erasure): shifrlash kalitlarini olib tashlash/almashtirish, shundan soʻng maʼlumotlar tiklanmaydi.
Kaskadli: derivatsiyalarni (keshlar, indekslar, tahlillar) uzluksiz olib tashlash.

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) Olib tashlash huquqi, Legal Hold va eDiscovery

Olib tashlash/tuzatish huquqi: SLA ijro (masalan, 30 kundan ≤), yo’naltiriladigan harakatlar, kvitansiyalar.
Legal Hold: yuridik so’rovda - ko’rsatilgan to’plamlar/kalitlar uchun olib tashlashni muzlatish; TTL ustuvorligi siyosati.
eDiscovery: maʼlumotlar katalogi, artefaktlar boʻyicha toʻliq matn/atributiv qidiruv, kelishilgan formatlarda eksport qilish.

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

10) Bekaplar vs arxivlar vs WORM

Bekaplar - yo’qotishdan/buzilishdan tiklash uchun; qisqa retenshen, tezkor RTO.
Arxivlar - audit/tahlillar uchun uzoq muddatli saqlash, arzon, uzoq foydalanish imkoniyati.
WORM - komplayens uchun o’zgarmas tashuvchilar (moliya/hisobot); «write-once, read-many» siyosati.

• «Asrlar arxivi» deb hisoblamang.
• Qayta tiklash mashqlari (DR-kunlar), vaqt va to’liqlik to’g’risida hisobot.
• Saqlash joyidan alohida retenshen, shifrlash va kalitlar bilan bekaplar katalogi.

11) Maxfiylik va anonimlashtirish

Taxallusni oʻzgartirish: kalit jadvali orqali PIIni kechiktirilgan bogʻlash (crypto-erasure kalitiga ruxsat beradi).
Anonimlashtirish: qaytarib bo’lmaydigan texnikalar (k-anonimlik, shovqin, umumlashtirish); usulni, reidentifikatsiya qilish xavfini va yaroqlilik muddatini hujjatlashtiring.

12) Muvofiqlik monitoringi va hisobot

Nazorat panellari: valid retenshenli datasetlar ulushi, ILM fazalari bo’yicha hajmlar, olib tashlash xatolari.
Alertlar: issiq tirdagi maqsadli hajmning oshib ketishi, Legal Hold tugaydigan «osilgan» o’chirishlar.
Hisobotlar: bir oylik olib tashlash auditi (so’rovlar soni, o’rtacha muddat, muvaffaqiyatsizliklar), kripto-shreddingi chop etish.

13) Jarayonlarga integratsiya: geyta va revyu

Design-gate: yangi dataset’owner/purpose/retention’dan oʻtmaydi.
Release-gate: retenshenni egasiz/asossiz oshiruvchi migratsiyalar bloklanadi.
Cost-gate: hot/warm hajmi byudjetdan oshadi - ILMni kuchaytirish uchun trigger.
Security-gate: PDni niqobsiz loglar/treyslarga va TTLga kiritishni taqiqlash.

14) Anti-patternlar

«Hamma narsani abadiy saqlaymiz - birdan foydali boʻladi».
Siyosatga kiritilmagan dasturlarda qattiq kodlangan TTL.
Niqobsiz/TTL/o’chirilmagan loglar va treyslardagi PD.
Toʻliq oʻchirilmagan (keshda/DWH/backaplarda qoldirilgan).
Legal Hold yo’qligi - tergov ostida ma’lumotlarni o’chirish.
Hamma narsada bitta umumiy shifrlash kaliti - «kripto-o’chirish» mumkin emas.
Nol kuzatish: «Biz olib tashlaganimizga ishonamiz», ammo hech qanday dalil yo’q.

15) Arxitektorning chek-varaqasi

1. Har bir dataset uchun owner, purpose, classification, retention, storage tier bormi?
2. ILM/TTL siyosati kod sifatida deklaratsiyalangan va avtomatik ravishda qoʻllaniladimi?
3. PD loglarda/treyslarda yashiriladi; «oq» toʻplamlardan tashqarida taqiqlanganmi?
4. Shaxsiy olib tashlash jarayonlari (SLA, audit, kvitansiyalar) bormi?
5. Crypto-erasure mumkin (per-tenant/per-dataset kalitlari, KMS/rotation)?
6. Bekaplar: jadval, shifrlash, tiklash testlari, alohida kalitlar?
7. Legal Hold/eDiscovery: Qoʻllab-quvvatlanyaptimi?
8. Kafka/navbatlar: belgilangan retenshen/compaction/tiering, DLQ alohida siyosatga ega?
9. Metrika va alertlar retenshen va hajmlarga rioya qilishga mosmi?
10. SDLCdagi revyu va geytlar retenshensiz artefaktlarni blokirovka qiladimi?

16) Mini-retseptlar

16. 1 ClickHouse: 180 kundan oshgan «dumini kesish»

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 Trassalar uchun 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 (g’oya)

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)

Xulosa

Saqlash siyosati - bu ma’lumotlar platformasining «skeleti»: ular ma’lumotlarning turli sinflari qancha yashashini, har lahzada qayerda yashashini, vaqt o’tishi bilan qanday arzonlashishini va qachon izsiz yo’q bo’lib ketishini tasvirlaydi - qonuniy, shaffof va tekshiriladigan. Siyosatni kod sifatida retenshen qiling, ILMni xavfsizlik va qiymat bilan bog’lang, kuzatuv va geytlarni yoqing - va siz bir vaqtning o’zida samarali, maqbul va o’sishga tayyor tizimni olasiz.