Retention жана сактоо саясаты

1) Принциптер

1. Purpose & Minimization. Биз кайра иштетүү максаттары үчүн зарыл болгон так жана так сакталат.
2. Policy as Code. Retenshen - бул PDF эмес, аткарылуучу саясат.
3. Defense in Depth. TTL/ILM + шифрлөө + аудиттер + мыйзамдуу кармоо.
4. Reversibility & Proof. Алып салуу текшерилет: иш-аракеттердин логи, крипто-шреддинг, сактоо отчету.
5. Cost & Carbon Aware. Retenshen $/GB-ай жана көмүртек сактоо/egress.

2) Маалыматтарды классификациялоо жана "ретеншен картасы"

• Операциялык (OLTP): буйрутмалар, төлөмдөр, сессиялар.
• Аналитикалык (DWH/даталар): окуялар, лог-фактылар, кесимдер.
• Жеке (PII/финансы/ден соолук): атайын мөөнөттөрдү жана субъекттердин укуктарын талап кылат.
• Техникалык: Логи, метрика, соода, артефакт CI.
• Документтер/медиа: WORM/Archive/Legacy.

Ар бир класс үчүн төмөнкүлөрдү белгилеңиз: ээси, максаты, укуктук базасы, мөөнөттөрү, коргоо деңгээли, учурдагы жана максаттуу сактагычтар.

3) ILM: маалыматтар жашоо айлампасы

1. Ingest (Hot) → NVMe/SSD, суроо жогорку жыштыгы.

2. Warm → азыраак окулат, кысуу, колонка форматтары.

3. Cold/Archive → объект/тасма, узак жетүү.

4. Purge/Delete → кепилденген алып салуу (анын ичинде репликалар/backaps).

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) - retenshen жок деплой тыюу салуу

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 '- терезе retenshen.
• Compaction (`cleanup. policy = compact ') - ачкычтын акыркы маанисин сактайбыз.
• Tiered Storage - "куйругун" муздак тирге алып.
• DLQ - өзүнчө retenshen жана TTL.

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

• Негизги топиктердин Retenshen ≈ реплика/кайра саноо бизнес терезесин аныктаңыз.
• Иш-чаралар үчүн биллинг/аудит - өзүнчө узак retenshen же WORM.

6) Маалымат базалары жана ретеншен

• Дата/диапазон боюнча партиялаштыруу, detach & эски партиялардын тамчы.
• Датасы бар талаалар - TTL-суроо үчүн индекстер.
• Убактылуу таблицалар (system-versioned) + эски версиялардын саясаттары.

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 (чийки 7d → агрегаттар 90d → узун 365d).
• TSDB retention саясаты (Influx/ClickHouse Materialized Views дедуп/топтоо менен).

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

Логи: талааларды чектөө, PD, TTL 7-30d, архив 90-180d.
Метрика: чийки жогорку жыштыгы - 7-14d; downsample (5m/1h) — 90–365д.
Tracks: 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): маалыматтарды/версияларды/репликаларды иш жүзүндө жок кылуу.
Крипто (крипто-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) Алып салуу укугу, Юридикалык 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) Backup vs Archives vs WORM

Backaps - жоготуу/зыян калыбына келтирүү үчүн; кыска retenshen, тез RTO.
Архивдер - аудит/аналитика үчүн узак мөөнөттүү сактоо, арзан, узак мүмкүнчүлүк.
WORM - комплаенс үчүн өзгөрүлбөгөн алып жүрүүчүлөр (финансы/отчеттуулук); саясат "write-once, read-many".

• "Кылымдар архиви" деп эсептебеңиз.
• Repaints калыбына келтирүү (DR-күн), убакыт жана толуктугу жөнүндө отчет.
• Ретеншен, шифрлөө жана ачкычтар менен сактоо каталогу.

11) Купуялык жана анонимдештирүү

Псевдонимизация: PIIди ачкыч таблицасы аркылуу кийинкиге калтыруу (crypto-erasure ачкычына мүмкүндүк берет).
Атын атагысы келбеген ыкмалар (k-атын атагысы келбеген, ызы-чуу, жалпылоо); ыкманы, реидентификациялоо тобокелдигин жана жарактуулук мөөнөтүн документтештириңиз.

12) Шайкештик мониторинги жана отчеттуулук

Control Panel: Valid Retenshen менен Datasets үлүшү, ILM фазалары боюнча көлөмдөр, алып салуу каталары.
Alerty: ысык тире максаттуу көлөмүн ашып, "илинип" алып салуу, Legal Hold аяктайт.
Отчеттор: бир айлык аудит алып салуу (суроо саны, орточо мөөнөтү, ийгиликсиздик), крипто-shredding басып чыгаруу.

13) Процесстерге интеграция: гейтс жана ревю

Design-gate: жаңы dataset 'owner/purpose/retention'.
Release-gate: ээси/негиздемеси жок retenshen көбөйтөт көчүрүү - бөгөттөлгөн.
Cost-gate: hot/warm көлөмү бюджеттен жогору - ILM-катуулатуу боюнча триггер.
Security-Gate: PDди камуфляжсыз жана TTLге киргизүүгө тыюу салуу.

14) Анти-үлгүлөрү

"Биз баарын түбөлүккө сактайбыз - күтүлбөгөн жерден пайдалуу болот".
Саясатта жок тиркемелерде катуу коддолгон TTL.
PD жашырып жок логдор жана соода-сатык/TTL/алып салуу.
Толук эмес алып салуу (кэш/DWH/backaps калды).
Юридикалык Hold жоктугу - тергөө боюнча маалыматтарды өчүрүү.
Бир жалпы шифрлөө ачкычы - "крипто-өчүрүү" мүмкүн эмес.
Нөл байкоо: "Биз жок деп ишенебиз", бирок эч кандай далил жок.

15) Архитектордун чек тизмеси

1. Ар бир маалымат үчүн owner, purpose, classification, retention, storage tier бар?
2. ILM/TTL саясаты код катары жарыяланган жана автоматтык түрдө колдонулат?
3. PD блогдордо/соодаларда жашырылган; "ак" комплекттерден тышкары тыюу салынганбы?
4. Жеке алып салуу процесстери (SLA, аудит, дүмүрчөктөр) барбы?
5. Crypto-erasure мүмкүн (per-tenant/per-dataset ачкычтар, KMS/rotation)?
6. Backup: расписание, шифрлөө, калыбына келтирүү тесттери, жеке ачкычтар?
7. Legal Hold/eDiscovery: колдоого алынган, TTL үстөмдүк, иш-аракет журналдар?
8. Kafka/кезек: белгиленген retenshen/compaction/tiering, DLQ өзүнчө саясаты бар?
9. Метрика жана Алерт Retenshen сактоо жана Тира боюнча көлөмүн?
10. SDLCдеги ревью жана гейтс ретеншен жок артефакттарды бөгөттөп жатабы?

16) Mini Recipes

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 крипто-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)

Корутунду

Сактоо саясаты - бул сиздин маалымат платформаңыздын "скелети": алар ар бир учурда ар кандай маалымат класстары канча жашап жатканын, убакыттын өтүшү менен алар кантип арзандап жатканын жана качан изи жок жоголуп баратканын - мыйзамдуу, ачык-айкын жана текшерүүгө болот. Code сыяктуу саясат Retenshen, коопсуздук жана наркы менен ILM туташтырып, байкоо жана гейтс кирет - жана ошол эле учурда натыйжалуу, комплаенс жана өсүүгө даяр системасын алат.