Retention və saxlama siyasəti

1) Prinsiplər

1. Purpose & Minimization. Emal məqsədlərinə lazım olduğu qədər saxlayırıq.
2. Policy as Code. Retenshen PDF deyil, həyata keçirilən siyasətdir.
3. Defense in Depth. TTL/ILM + şifrələmə + audit + Legal Hold.
4. Reversibility & Proof. Silinməsi yoxlanılır: fəaliyyət qeydləri, kriptovalyutası, uyğunluq hesabatı.
5. Cost & Carbon Aware. Retenshen $/GB-ay və karbon izi saxlama/egress nəzərə alır.

2) Məlumatların təsnifatı və «retenşen kartı»

• Əməliyyat (OLTP): sifarişlər, ödənişlər, sessiyalar.
• Analitik (DWH/tarixlər): hadisələr, log-faktlar, kəsiklər.
• Fərdi (PII/maliyyə/sağlamlıq): xüsusi şərtlər və subyektlərin hüquqları tələb olunur.
• Texniki: loglər, metriklər, treyslər, CI artefaktları.
• Sənədlər/Media: WORM/Arxiv/Legasi.

Hər bir sinif üçün: sahibi, məqsədi, hüquqi bazası, vaxtı, qorunma səviyyəsi, cari və hədəf anbarları.

3) ILM: verilənlərin həyat dövrü

1. Ingest (hot) → NVMe/SSD, yüksək tezlikli sorğular.

2. Warm → az oxunur, sıxılma, sütun formatları.

3. Cold/Archive → obyekt/lent, uzun giriş.

4. Purge/Delete → zəmanətli silinmə (replikalar/backaplar daxil olmaqla).

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 kimi siyasətlər (faydalı eskizlər)

4. 1 Admission siyasəti (məcburi etiketlər/TTL)

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

4. CI/CD-də 2 qapı (Rego) - Retenshen olmadan deploi qadağası

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 fraqmenti)

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 axınlar və növbələr

• `retention. ms`/`retention. bytes '- pəncərə retenshen.
• Compaction (`cleanup. policy = compact ') - açarın son qiymətini saxlayırıq.
• Tiered Storage - «quyruğu» soyuq atışa aparırıq.
• DLQ - ayrı retenşen və TTL.

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

• Əsas topiklərin retenşenini replay/yenidən hesablama iş pəncərəsi ≈ müəyyən edin.
• Billing/audit hadisələri üçün - ayrı bir uzunmüddətli retenşen və ya WORM.

6) Verilənlər bazası və Retenshen

• Tarix/diapazona görə partizan, detach & köhnə partiyalar.
• Tarix sahələri - TTL sorğuları üçün indekslər.
• Zamansal cədvəllər (system-versioned) + köhnə versiyası purge polislər.

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 açar səviyyəsində (MongoDB TTL index, Redis 'EXPIRE', Cassandra TTL).
• Metrik üçün Downsampling (xam 7d → aqreqatlar 90d → uzun 365d).
• TSDB-də retention siyasəti (Influx/ClickHouse Materialized Views).

7) Log, metrika, treys

Log: sahələri məhdudlaşdırmaq, PD maskalamaq, TTL 7-30d, arxiv 90-180d.
Metriklər: xam yüksək tezlikli - 7-14d; downsample (5m/1h) — 90–365д.
Traces: tail-sampling və saxlama «maraqlı» (səhvlər/quyruqlar) daha uzun.

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) Çıxarılması: növləri və zəmanətləri

Məntiqi (soft-delete): qeyd; bərpa üçün əlverişli, «silinmə hüququ» altında uyğun deyil.
Fiziki (hard-delete): verilənlərin/versiyaların/replikaların faktiki silinməsi.
Kriptoqrafik (crypto-erasure): şifrələmə açarlarının silinməsi/dəyişdirilməsi, sonra verilənlər bərpa edilmir.
Kaskad: derivasiyaların aradan qaldırılması (keşlər, indekslər, analitika).

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) Silinmə hüququ, Legal Hold və eDiscovery

Çıxarılması/düzəldilməsi hüququ: SLA icrası (məsələn, 30 gün ≤), izlənilən hərəkətlər, qəbzlər.
Legal Hold: hüquqi sorğu zamanı - göstərilən dəstlər/açarlar üçün silinmənin dondurulması; TTL üzərində prioritet siyasət.
eDiscovery: verilənlər kataloqu, artefaktlar üzrə tam mətnli/atributiv axtarış, razılaşdırılmış formatlarda ixrac.

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

10) Arxivlər vs arxivlər vs WORM

Backaps - itki/zərər bərpa üçün; qısa retenshen, sürətli RTO.
Arxivlər - audit/analitika üçün uzunmüddətli saxlama, ucuz, uzun giriş.
WORM - komplayens üçün dəyişməz daşıyıcılar (maliyyə/hesabat); «write-once, read-many» siyasəti.

• Arxapı «əsrlər arxivi» hesab etməyin.
• Repetisiyalar bərpa (DR-gün), vaxt və tamlıq hesabatı.
• Retenshen, şifrələmə və açarları ilə arxa xətt kataloqu.

11) Gizlilik və anonimləşdirmə

Pseudonimization: açar cədvəli vasitəsilə PII gecikmiş bağlama (crypto-erasure açar imkan verir).
Anonimləşdirmə: geri dönməz texnika (k-anonimlik, səs-küy, ümumiləşdirmə); metodu, reidentifikasiya riskini və raf ömrünü sənədləşdirin.

12) Uyğunluq monitorinqi və hesabat

Nəzarət panelləri: valid retenşenli datasetlərin payı, ILM fazaları üzrə həcmlər, çıxarılma səhvləri.
Alertlər: isti tirdə hədəf həcmini aşmaq, Legal Hold-dan keçən «asılı» çıxarışlar.
Hesabatlar: aylıq silmə auditi (sorğuların sayı, orta müddət, uğursuzluqlar), kriptovalyutanın çapı.

13) Proseslərə inteqrasiya: geyta və revyu

Design-gate: Yeni dataset 'owner/purpose/retention' olmadan review keçmir.
Release-gate: sahibinin/əsaslandırılması olmadan retenshen artıran miqrasiyalar bloklanır.
Cost-gate: hot/warm həcmi büdcəni üstələyir - ILM sərtləşdirilməsi üçün tetikleyici.
Security-gate: Gizlətmədən və TTL olmadan PD-nin log/treyslərə daxil edilməsinin qadağan edilməsi.

14) Anti-nümunələr

«Biz hər şeyi əbədi saxlayırıq - birdən faydalı olacaq».
Proqramlarda TTL-lər siyasətə daxil edilmir.
/ TTL/silinmədən log və treyslərdə PD.
Natamam silinmə (cache/DWH/backup buraxıldı).
Qeyri-qanuni Hold - istintaq altında məlumatların silinməsi.
Hər şey üçün bir ümumi şifrələmə açarı - nöqtəli «kriptovalyutası» mümkün deyil.
Sıfır müşahidə: «silindiyinə inanırıq», lakin heç bir sübut yoxdur.

15) Memarın yoxlama siyahısı

1. Hər bir dataset üçün owner, purpose, classification, retention, storage tier var?
2. ILM/TTL siyasəti kod kimi elan edilir və avtomatik tətbiq olunur?
3. PD log/treys maskalanır; «ağ» dəstləri xaricində qadağan?
4. Şəxsi silinmə prosesləri (SLA, audit, qəbzlər) varmı?
5. Crypto-erasure mümkündür (per-tenant/per-dataset açarları, KMS/rotation)?
6. Backup: cədvəl, şifrələmə, bərpa testləri, fərdi açarlar?
7. Legal Hold/eDiscovery: dəstəklənir, TTL üzərində üstünlük təşkil edir, fəaliyyət jurnalları aparılır?
8. Kafka/növbələr: müəyyən retenshen/compaction/tiering, DLQ ayrı siyasətləri var?
9. Retenşenə riayət etmək üçün metriklər və alertlər və tirlər üzrə həcmlər?
10. SDLC-də revyu və geytalar retenshen olmadan artefaktları bloklayır?

16) Mini reseptlər

16. 1 ClickHouse: 180 gündən yuxarı «quyruğunu kəsin»

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. Trass üçün 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 (ideya)

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)

Nəticə

Saxlama siyasəti sizin məlumat platformanızın «skeletidir»: onlar hər an nə qədər fərqli məlumat sinifləri yaşadıqlarını, harada olduqlarını, zaman keçdikcə necə ucuzlaşdıqlarını və izsiz yoxa çıxdıqlarını izah edirlər - qanuni, şəffaf və yoxa çıxa bilər. Bir kod kimi bir siyasət retenshen edin, təhlükəsizlik və dəyər ilə ILM bağlayın, müşahidə və geytaları daxil edin - və eyni zamanda effektiv, komplayent və böyüməyə hazır bir sistem əldə edəcəksiniz.