سیاست های نگهداری و نگهداری

1) اصول

1. هدف و به حداقل رساندن. ما دقیقا آن را ذخیره می کنیم و دقیقا به همان اندازه که برای اهداف پردازش نیاز داریم.
2. سیاست به عنوان کد نگهداری یک سیاست اجرایی است، نه PDF.
3. دفاع در عمق TTL/ILM + رمزگذاری + ممیزی + حقوقی نگه دارید.
4. برگشت پذیری و اثبات حذف قابل اثبات است: سیاهههای مربوط به عمل، خرد کردن رمزنگاری، گزارش انطباق.
5. هزینه و کربن آگاه است. نگهداری طول می کشد به حساب $/GB-ماه و رد پای کربن از ذخیره سازی/خروج.

2) طبقه بندی داده ها و «نقشه Retenschen»

• عملیاتی (OLTP): سفارشات، پرداخت ها، جلسات.
• تحلیلی (DWH/تاریخ): حوادث، حقایق ورود به سیستم، برش.
• شخصی (PII/امور مالی/بهداشت): نیاز به شرایط خاص و حقوق افراد.
• فنی: سیاهههای مربوط، معیارها، مسیرهای پیاده روی، مصنوعات CI.
• اسناد/رسانه ها: WORM/بایگانی/legasi.

برای هر کلاس، مجموعه: مالک، هدف، چارچوب قانونی، تاریخ، سطح حفاظت، ذخیره سازی فعلی و هدف.

3) چرخه عمر داده ILM

1. مصرف (داغ) → NVMe/SSD، میزان درخواست بالا.

2. گرم → کمتر خوانده شده، فشرده سازی، فرمت های ستون.

3. سرد/بایگانی → شیء/نوار، دسترسی طولانی.

4. پاک کردن/حذف → حذف تضمین شده (از جمله کپی/پشتیبان گیری).

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 سیاست پذیرش (برچسب های مورد نیاز/TTL)

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

4. 2 دروازه در 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/object (قطعه چرخه عمر)

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) حفظ در موضوعات و صف

• گفت: خانم/حفظ. بایت - حفظ پنجره.
• تراکم ('پاکسازی. policy = compact ') - آخرین مقدار کلید را ذخیره کنید.
• ذخیره سازی چند لایه - ما «دم» را به یک گالری تیراندازی سرد می بریم.
• 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) پایگاه داده و نگهداری

• پارتیشن بندی بر اساس تاریخ/محدوده، جدا کردن و رها کردن احزاب قدیمی.
• فیلدهای تاریخ - شاخصها برای درخواستهای 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 در سطح کلیدی (شاخص TTL MongoDB، Redis 'EXPIRE'، Cassandra TTL).
• Downsampling برای معیارها (خام 7d → دانه 90d → طول 365d).
• سیاست های نگهداری در TSDB (نمایش های مادی/ClickHouse با dedup/aggregation).

7) سیاههها، معیارها، مسیرهای پیاده روی

سیاهههای مربوط: زمینه های محدود، ماسک PD، TTL 7-30d، آرشیو 90-180d.
معیارها: فرکانس بالا خام - 7-14d ؛ نمونه (5 متر/1 ساعت) - 90 تا 365д.
مسیرهای پیاده روی: نمونه برداری دم و نگه داشتن «جالب» (اشکالات/دم) طولانی تر.

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) حذف: انواع و ضمانت

Logical (soft-delete): علامت گذاری یک رکورد مناسب برای بازیابی، متناسب با «حق حذف» نیست.
فیزیکی (حذف سخت) - حذف واقعی داده ها/نسخه ها/کپی ها.
رمزنگاری (رمزنگاری پاک کردن): حذف/جایگزینی کلید های رمزگذاری، پس از آن داده ها بازسازی نمی شود.
Cascade: حذف پایان به پایان مشتقات (caches، indexes، analytics).

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) حق حذف، نگهداری قانونی و کشف الکترونیکی

حق حذف/اصلاح: SLA اعدام (به عنوان مثال، ≤30 روز)، اقدامات ردیابی، رسید.
نگه حقوقی: در درخواست قانونی - توقف حذف برای مجموعه/کلید مشخص شده ؛ سیاست اولویت بیش از 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) پشتیبان گیری در مقابل آرشیو در مقابل WORM

پشتیبان گیری - برای بازیابی از دست دادن/آسیب ؛ بازگشت کوتاه، RTO سریع.
بایگانی - نگهداری طولانی مدت برای حسابرسی/تجزیه و تحلیل، ارزان، دسترسی طولانی.

WORM - رسانه های غیر قابل تغییر برای انطباق (مالی/گزارش) ؛ سیاستهای «یک بار بنویس، چندین بار بخوان»

• نسخه پشتیبان را به عنوان «بایگانی قرن ها» حساب نکنید.
• تمرینات بازیابی (DR روز)، زمان و گزارش کامل.
• دایرکتوری پشتیبان گیری با نگهداری، رمزگذاری و کلید به طور جداگانه از ذخیره سازی.

11) حریم خصوصی و ناشناس

Aliasing: PII تاخیر اتصال از طریق جدول کلید (اجازه می دهد تا رمزنگاری پاک کردن توسط کلید).
ناشناس: تکنیک های غیر قابل برگشت (k-ناشناس، سر و صدا، تعمیم) ؛ روش سند، خطر شناسایی مجدد و تاریخ انقضا.

12) نظارت بر انطباق و گزارش

پانل های کنترل: نسبت مجموعه داده ها با نگهداری معتبر، حجم توسط مراحل ILM، خطاهای حذف.
هشدارها: بیش از حجم هدف در خط تیره داغ، «آویزان» حذف انقضای حقوقی نگه دارید.
گزارش ها: حسابرسی حذف ماهانه (تعداد درخواست ها، مدت متوسط، شکست ها)، چاپ نسخه خرد شده.

13) ادغام در فرایندها: دروازه ها و بررسی ها

Design-gate: مجموعه داده های جدید بدون «مالک/هدف/نگهداری» بررسی نمی شود.
Release-gate: مهاجرت هایی که بدون مالک/توجیه نگهداری را افزایش می دهند مسدود می شوند.
هزینه دروازه: حجم در گرم/گرم بیش از بودجه - باعث سفت شدن ILM می شود.
امنیت دروازه: ممنوعیت ورود PD در سیاهههای مربوط/مسیرهای پیاده روی بدون پنهان کردن و TTL.

14) ضد الگوهای

«ما همه چیز را برای همیشه نگه می داریم - ناگهان مفید خواهد بود».
TTL های سخت افزاری در برنامه های کاربردی که در سیاست ها ارائه نشده اند.
PD در سیاهههای مربوط و آثار بدون ماسک/TTL/حذف.
حذف ناقص (سمت چپ در حافظه پنهان/DWH/پشتیبان گیری).
عدم برگزاری قانونی - پاک کردن اطلاعات تحت بررسی.
یک کلید رمزنگاری مشترک برای همه چیز - غیر ممکن است به نقطه «رمزنگاری پاک کردن».
مشاهده پذیری صفر: «ما معتقدیم که حذف شده ایم»، اما هیچ مدرکی وجود ندارد.

15) چک لیست معمار

1. برای هر مجموعه داده یک مالک، هدف، طبقه بندی، نگهداری، سطح ذخیره سازی وجود دارد ؟

2. آیا سیاست های ILM/TTL به عنوان کد اعلام شده و به طور خودکار اعمال می شود ؟

3. PDs در سیاهههای مربوط/آهنگ ماسک; خارج از مجموعه «سفید» ممنوع است ؟

4. آیا فرآیندهای حذف شخصی (SLA، حسابرسی، رسید) وجود دارد ؟

5. رمزنگاری پاک کردن ممکن است (در هر مستاجر/در هر کلید مجموعه داده, KMS/چرخش)?

6. پشتیبان گیری: برنامه، رمزگذاری، تست بازیابی، کلید های فردی ؟

7. حقوقی برگزاری/eDiscovery: پشتیبانی, غلبه بر TTL, سیاهههای مربوط فعالیت حفظ?
8. Kafka/صف: حفظ/تراکم/tiering مشخص, DLQ سیاست های جداگانه?

9. معیارها و هشدارها برای انطباق با Retenschen و حجم در گالری های تیراندازی پیکربندی شده اند ؟

10. آیا بررسی ها و دروازه ها در SDLC مسدود کردن مصنوعات بدون Retenschen ؟

16) دستور العمل های کوچک

16. 1 ClickHouse: «قطع دم» بیش از 180 روز

sql
ALTER TABLE events DELETE WHERE event_date < today() - 180;
OPTIMIZE TABLE events FINAL;

16. 2 Redis: TTL и تنبل پاکسازی

bash
SET session:123 value EX 3600
CONFIG SET maxmemory-policy allkeys-lru

16. 3 نمونه برداری دم برای مسیرهای پیاده روی

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 رمزنگاری پاک کردن (ایده)

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 با امنیت و هزینه، فعال کردن قابلیت مشاهده و دروازه - و شما یک سیستم است که هر دو موثر، سازگار و آماده برای رشد است.