Retention და შენახვის პოლიტიკა

1) პრინციპები

1. Purpose & Minimization. ჩვენ ვხარობთ ზუსტად და ზუსტად იმდენი, რამდენიც საჭიროა დამუშავების მიზნებისთვის.
2. Policy as Code. Retenschen არის შესრულებული პოლიტიკა და არა PDF.
3. Defense in Depth. TTL/ILM + დაშიფვრა + აუდიტი + Legal Hold.
4. Reversibility & Proof. მოცილება გადამოწმებულია: მოქმედების ლოგოები, კრიპტო-შრედინგი, შესაბამისობის ანგარიში.
5. Cost & Carbon Aware. Retenschen ითვალისწინებს $/GB-mes და ნახშირბადის შენახვის ბილიკს/egress.

2) მონაცემთა კლასიფიკაცია და „retenshen რუკა“

• ოპერაციული (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 in 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. ms`/`retention. bytes '- ფანჯრის retenchen.
• 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

• დაადგინეთ ძირითადი ღერძების ჭრილობა - reple/გადაანგარიშების ბიზნეს ფანჯარა.
• მოვლენებისთვის, ბილინგი/აუდიტი - ცალკე გრძელი რეტენჩენი ან WORM.

6) მონაცემთა ბაზები და რეტენჩენი

• განაწილება თარიღის/დიაპაზონის, ძველი ნაწილების detach & drop.
• თარიღის მქონე ველები - ინდექსები TTL მოთხოვნებისთვის.
• ტემპორალური ცხრილი (სისტემა-ვერსია) + ძველი ვერსიების პოლისი.

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 ინდექსი, Redis 'EXPIRE', Cassandra TTL).
• Downsampling for metricris (ნედლეული 7d-aggragates 90d, გრძელი 365 d).
• Retention პოლიტიკოსები TSDB- ში (Influx/ClickHouse Materialized Views ერთად დედაპლატა/აგრეგაცია).

7) Logs, მეტრიკა, ტრეისი

Logs: შეზღუდეთ ველები, შენიღბეთ PD, TTL 7-30d, არქივი 90-180d.
მეტრიკა: ნედლეული მაღალი სიხშირე - 7-14d; 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) მოცილება: ტიპები და გარანტიები

ლოგიკური (რბილი): ჩანაწერის შენიშვნა; მოსახერხებელია აღდგენისთვის, არ შეესაბამება „მოცილების უფლებას“.
ფიზიკური (მძიმე): მონაცემების/ვერსიების/რეპლიკების ფაქტობრივი წაშლა.
კრიპტოგრაფიული (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) მოხსნის უფლება, იურიდიული ჰოლდი და 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) Bacapes vs არქივები vs WORM

Bacaps - ზარალის/დაზიანების აღდგენისთვის; მოკლე retenschen, სწრაფი RTO.
არქივები - აუდიტის/ანალიტიკის გრძელვადიანი შენახვა, იაფი, გრძელი წვდომა.
WORM - უცვლელი შესაბამისობის მატარებლები (ფინანსები/ანგარიშგებები); პოლიტიკოსები „write-once, read-many“.

• ნუ გამოთვლით bacap- ს, როგორც „მარადიული არქივი“.
• აღდგენის რეპეტიციები (DR დღეები), მოხსენება დროისა და სისრულის შესახებ.
• Backap- ის კატალოგი crestens, დაშიფვრა და გასაღებები საცავებისგან დამოუკიდებლად.

11) კონფიდენციალურობა და ანონიმიზაცია

ფსევდონიმი: PII- ის გადავადებული აკრეფა გასაღების ცხრილის საშუალებით (საშუალებას გაძლევთ crypto-erasure გასაღები).
ანონიმიზაცია: შეუქცევადი ტექნიკა (კ-ანონიმურობა, ხმაური, განზოგადება); აღწერეთ მეთოდი, რეიდენტიფიკაციის რისკი და შენახვის ვადა.

12) შესაბამისობისა და ანგარიშგების მონიტორინგი

საკონტროლო პანელები: აქტიური ჩამწერი სენსორების წილი, ILM ფაზების მოცულობა, წაშლის შეცდომები.
ალერტები: ცხელი სიბნელეში სამიზნე მოცულობის გადაჭარბება, ლეგალური ჰოლდის ამოწურვის „შეჩერება“.
მოხსენებები: ყოველთვიური მოცილების აუდიტი (მოთხოვნის რაოდენობა, საშუალო ვადა, წარუმატებლობა), კრიპტო-ნაკადის დაბეჭდვა.

13) ინტეგრაცია პროცესებში: კარიბჭეები და შურისძიება

დიზაინი: ახალი თარიღი არ გადის შურისძიებას 'owner/purpose/retention' გარეშე.
Release-gate: მიგრაცია, რომელიც ზრდის retenshen მფლობელის/დასაბუთების გარეშე - იბლოკება.
Cost-gate: ცხელი/warm მოცულობა აღემატება ბიუჯეტს - ILM გამკაცრებას.
Security-gate: აკრძალვა LD- ში/ტრეისებში შენიღბვის გარეშე და TTL.

14) ანტი შაბლონები

„ყველაფერი სამუდამოდ შევინახოთ - მოულოდნელად სასარგებლო იქნება“.
მკაცრად დაშიფრული TTL პროგრამებში, რომლებიც არ შედის პოლიტიკაში.
PD ლოგოებში და ტრეისებში შენიღბვის გარეშე/TTL) წაშლა.
არასრული მოცილება (დარჩა ქეში/DWH/ბეიკოპებში).
Legal Hold- ის არარსებობა არის მონაცემთა წაშლა გამოძიების ქვეშ.
დაშიფვრის ერთი ზოგადი გასაღები ყველაფრისთვის - შეუძლებელია წერტილოვანი „კრიპტო-წაშლა“.
ნულოვანი დაკვირვება: „ჩვენ გვჯერა, რომ ამოიღეს“, მაგრამ არანაირი მტკიცებულება არ არსებობს.

15) არქიტექტორის ჩეკის სია

1. თითოეული თარიღისთვის არის owner, purpose, classification, retention, storage tier?
2. ILM/TTL პოლიტიკოსები გამოცხადებულია კოდად და ავტომატურად გამოიყენება?
3. PD შენიღბულია ლოგებში/ტრეისებში; აკრძალულია „თეთრი“ კომპლექტების გარეთ?
4. არსებობს პერსონალური წაშლის პროცესები (SLA, აუდიტი, ქვითრები)?
5. შესაძლებელია Crypto-erasure (კლავიშების წინა ტენანტი/per dataset, KMS/rotation)?
6. Bacaps: გრაფიკი, დაშიფვრა, აღდგენის ტესტები, ინდივიდუალური გასაღებები?
7. Legal Hold/edIscovery: მხარს უჭერს, ჭარბობს TTL, მიმდინარეობს სამოქმედო ჟურნალები?
8. Kafka/რიგები: მითითებულია retenschen/compaction/tiering, DLQ- ს აქვს ცალკეული პოლიტიკოსები?
9. არის თუ არა მეტრიკა და ალერტები retenshen- ის დასაცავად და ტირამისთვის მოცულობები?
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)

დასკვნა

შენახვის პოლიტიკოსები თქვენი მონაცემთა პლატფორმის „ჩონჩხი“ არიან: ისინი აღწერენ რამდენი სხვადასხვა მონაცემთა კლასია, სადაც ისინი ყოველ მომენტში ცხოვრობენ, როგორ იაფია დროთა განმავლობაში და როდის ქრება კვალის გარეშე - კანონიერი, გამჭვირვალე და გადამოწმებული. გახადეთ retenschen პოლიტიკა, როგორც კოდი, დააკავშირეთ ILM უსაფრთხოებასთან და ღირებულებასთან, ჩართეთ დაკვირვება და კარიბჭეები - და მიიღებთ სისტემას, რომელიც ერთდროულად ეფექტურია, შესაბამისია და მზად არის ზრდისთვის.