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. CI/CD-ге 2 Gate (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д).
• TSDB-дегі retention саясаты (дедуп/агрегациясы бар 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/tiering берілген, 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-ді қауіпсіздік пен құнмен біріктіріңіз, бақылау мен гейттерді қосыңыз - және сіз бір уақытта тиімді, сыйымды және өсуге дайын жүйені аласыз.