داده‌های قدیمی هم هزینه دارند و باید درباره نگهداری آن‌ها تصمیم گرفت

هزینه داده‌های قدیمی - مجله راگا

این مقاله درباره پاک‌کردن عجولانه داده نیست. هدف، ساختن یک سیاست قابل دفاع برای نگهداری، آرشیو، بکاپ و حذف است. چنین سیاستی باید با نیاز کسب‌وکار، الزامات حقوقی، ارزش اطلاعات، هزینه بازیابی و ریسک امنیتی هماهنگ باشد. تصمیم خوب ظرفیت را آزاد می‌کند، اما مهم‌تر از آن، مسئولیت داده را روشن می‌سازد.

در این راهنما، موضوع از چند زاویه بررسی می‌شود: جلسه‌ای که با یک نمودار شروع شد، چهار واژه‌ای که نباید جای هم استفاده شوند، مالک داده باید پیش از مالک Storage مشخص شود. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.

در این مقاله می‌خوانید

  • جلسه‌ای که با یک نمودار شروع شد
  • چهار واژه‌ای که نباید جای هم استفاده شوند
  • مالک داده باید پیش از مالک Storage مشخص شود
  • نگهداری بیشتر همیشه محافظه‌کارانه‌تر نیست

جلسه‌ای که با یک نمودار شروع شد

مدیر زیرساخت در جلسه می‌گوید شصت درصد فضای سامانه فایل بیش از یک سال تغییر نکرده است. این عدد به‌تنهایی مجوز حذف نیست. بخشی از فایل‌ها شاید اسناد قرارداد باشند، بخشی نتیجه پروژه‌های پایان‌یافته و بخشی نسخه‌های شخصی که کارکنان برای اطمینان ساخته‌اند. نمودار سن را نشان می‌دهد، نه ارزش و تعهد سازمان را.

مدیرعامل از تیم می‌خواهد به‌جای ارائه یک عدد کلی، داده‌ها را به گروه‌های قابل تصمیم تقسیم کند. سؤال از «چقدر فضا داریم» به «برای کدام داده چه سطح خدمتی لازم است» تغییر می‌کند. این تغییر ساده، خرید ظرفیت را از یک واکنش فوری به بخشی از برنامه مدیریت اطلاعات تبدیل می‌کند.

چهار واژه‌ای که نباید جای هم استفاده شوند

داده فعال برای اجرای کار روزانه استفاده می‌شود و معمولاً به دسترسی سریع نیاز دارد. آرشیو، داده‌ای است که کمتر مصرف می‌شود اما به دلیل ارزش تاریخی، حقوقی یا عملیاتی باید قابل جست‌وجو و بازیابی بماند. بکاپ نسخه‌ای برای بازگرداندن داده یا سرویس پس از حذف، خرابی یا حادثه است. نگهداری نیز قاعده‌ای است که تعیین می‌کند هر نوع داده تا چه زمانی و با چه مسئولیتی حفظ شود.

اگر بکاپ به آرشیو تبدیل شود، پیدا کردن یک سند قدیمی به جست‌وجو در زنجیره‌ای از نسخه‌ها وابسته می‌شود. اگر آرشیو را بکاپ در نظر بگیریم، ممکن است نسخه محافظت‌شده و نقطه بازیابی کافی نداشته باشیم. اگر داده فعال را فقط برای ترس از حذف روی لایه سریع نگه داریم، هزینه بالا می‌رود بی‌آنکه سطح خدمت واقعی بهتر شود.

مالک داده باید پیش از مالک Storage مشخص شود

تیم زیرساخت می‌تواند ظرفیت، سن فایل و الگوی دسترسی را گزارش کند، اما معمولاً نمی‌داند یک پرونده برای دفاع حقوقی، حسابرسی یا ادامه خدمت چه ارزشی دارد. این تصمیم به مالک کسب‌وکاری داده نیاز دارد. واحد مالی درباره اسناد مالی، منابع انسانی درباره پرونده کارکنان و واحد قراردادها درباره مستندات تعهدات نظر می‌دهند.

مالکیت به معنای سپردن همه کارها به یک واحد نیست. فناوری اطلاعات ابزار اندازه‌گیری و کنترل را فراهم می‌کند، امنیت سطح حفاظت را تعیین می‌کند و حقوق یا تطبیق، محدودیت‌های نگهداری را بررسی می‌کنند. مالک داده درباره هدف استفاده و دوره موردنیاز پاسخ‌گو است. بدون این تقسیم مسئولیت، هر واحد حذف را به دیگری واگذار می‌کند و انباشت ادامه می‌یابد.

نگهداری بیشتر همیشه محافظه‌کارانه‌تر نیست

گاهی سازمان تصور می‌کند حفظ همه‌چیز کم‌خطرترین انتخاب است. داده قدیمی می‌تواند اطلاعات شخصی، قرارداد منقضی‌شده، فایل‌های دارای دسترسی نامناسب یا نسخه‌های بدون کنترل را در خود نگه دارد. هر چه دامنه داده بیشتر باشد، کشف، حفاظت، پاسخ به حادثه و انتقال آن نیز دشوارتر می‌شود.

از سوی دیگر، حذف زودهنگام می‌تواند سازمان را از سابقه لازم برای پاسخ به مشتری، حسابرس یا یک اختلاف قراردادی محروم کند. بنابراین سیاست باید برای هر طبقه داده، حداقل و حداکثر دوره، رویداد آغاز دوره و استثناها را روشن کند. عبارت مبهم «تا اطلاع ثانوی» معمولاً همان نگهداری نامحدود است.

هزینه واقعی فقط قیمت هر ترابایت نیست

هزینه داده شامل ظرفیت اصلی، نسخه‌های تکثیرشده، بکاپ، Replication، پهنای باند، برق، پشتیبانی و زمان تیم عملیاتی است. یک ترابایت داده فعال ممکن است در چند محل و چند نسل بکاپ حضور داشته باشد. در نتیجه حذف یا انتقال یک مجموعه کم‌ارزش می‌تواند بیش از اندازه ظاهری آن ظرفیت آزاد کند.

کارایی نیز بخشی از هزینه است. رشد بی‌قاعده تعداد فایل‌ها می‌تواند فهرست‌برداری، اسکن امنیتی، بکاپ و بازیابی را طولانی کند. زمانی که پنجره بکاپ پر می‌شود، پاسخ صرفاً خرید مخزن بزرگ‌تر نیست؛ باید دانست چه داده‌ای وارد چرخه حفاظت شده و آیا دوره نگهداری آن هنوز توجیه دارد.

داده را بر اساس ارزش و الگوی مصرف طبقه‌بندی کنیم

برای شروع، سازمان به طبقه‌بندی پیچیده نیاز ندارد. می‌توان چهار سؤال را برای هر مجموعه پاسخ داد: چه کسی از آن استفاده می‌کند، آخرین بار چه زمانی تغییر کرده، در صورت نبودن چه آسیبی ایجاد می‌شود و چه الزام نگهداری دارد. پاسخ‌ها کمک می‌کنند داده فعال، نیمه‌فعال، آرشیوی و نامزد حذف از هم جدا شوند.

طبقه‌بندی باید در سطحی انجام شود که قابل اجرا باشد. بررسی تک‌تک فایل‌ها پروژه را متوقف می‌کند؛ تصمیم درباره کل سامانه نیز تفاوت‌ها را پنهان می‌سازد. پوشه پروژه، Share واحد، جدول سامانه یا Bucket می‌تواند واحد مناسبی باشد، به شرط آنکه مالک و الگوی استفاده مشخص باشند.

لایه‌بندی ذخیره‌سازی باید نتیجه سیاست باشد

پس از شناخت داده، می‌توان آن را روی لایه متناسب قرار داد. داده پرتراکنش یا حساس به تأخیر به Storage سریع و در دسترس نیاز دارد. آرشیو کم‌مصرف می‌تواند روی لایه اقتصادی‌تر قرار گیرد، اگر زمان بازیابی آن با نیاز واحد صاحب داده سازگار باشد. بکاپ نیز باید مخزن و کنترل‌های متناسب با هدف بازیابی داشته باشد.

انتقال به لایه ارزان‌تر تصمیمی صرفاً فنی نیست. اگر واحد حقوقی یک سند را باید در چند دقیقه پیدا کند، آرشیوی با بازیابی چندساعته شاید مناسب نباشد. اگر گزارش فقط برای مراجعه نادر نگهداری می‌شود، پرداخت دائمی برای کارایی بالا منطقی نیست. سطح خدمت هر لایه باید پیش از جابه‌جایی توافق شود.

سیاست چرخه عمر را به ابزار تبدیل کنیم

سیاست زمانی اثر دارد که بتوان آن را به قاعده اجرایی تبدیل کرد. برای نمونه، فایل پروژه پس از بسته‌شدن و تأیید مالک می‌تواند از لایه فعال به آرشیو منتقل شود. پس از پایان دوره مصوب و نبود منع حقوقی، حذف کنترل‌شده انجام می‌شود. هر مرحله باید ثبت شود تا سازمان بداند چه اتفاقی افتاده است.

اتوماسیون می‌تواند سن، آخرین دسترسی یا برچسب داده را بررسی کند، اما نباید جای تصمیم مالک را بگیرد. در مرحله نخست بهتر است گزارش و پیشنهاد تولید شود و انتقال پس از تأیید انجام گیرد. وقتی کیفیت برچسب‌ها و فرایند تثبیت شد، بخش بیشتری از چرخه عمر را می‌توان خودکار کرد.

نسخه‌های تکراری را از داده معتبر جدا کنیم

در سناریوی ما، چند واحد یک نسخه از گزارش نهایی را در پوشه‌های شخصی نگه داشته‌اند. بعضی نسخه‌ها نام مشابه دارند و مشخص نیست کدام معتبر است. حذف Duplicate فقط با مقایسه فنی فایل حل نمی‌شود؛ سازمان باید مرجع رسمی هر نوع سند را معرفی و دسترسی مناسب به آن ایجاد کند.

اگر کارکنان به مرجع اعتماد نکنند یا بازیابی آن دشوار باشد، دوباره نسخه محلی می‌سازند. بنابراین برنامه کاهش داده باید تجربه دسترسی را نیز اصلاح کند. تعیین Source of Truth، کنترل نسخه و آموزش کوتاه کارکنان از بازگشت انباشت جلوگیری می‌کند.

داده‌های بدون مالک یک علامت هشدار هستند

پوشه واحدی که منحل شده، خروجی سامانه‌ای که جایگزین شده یا Share مربوط به پیمانکار سابق ممکن است سال‌ها باقی بماند. نبود مالک به معنای نبود ارزش نیست، اما نشان می‌دهد تصمیم‌گیری متوقف شده است. این مجموعه‌ها باید در فهرست استثنا قرار گیرند و مالک جانشین برای آن‌ها تعیین شود.

اگر هیچ واحدی مسئولیت را نمی‌پذیرد، کمیته کوچک حاکمیت داده می‌تواند بر اساس منشأ، محتوا، الزامات و ریسک تصمیم بگیرد. تا زمان تصمیم، دسترسی و حفاظت باید کنترل شود. رهاکردن داده بدون مالک روی فضای مشترک، هم هزینه و هم سطح حمله را افزایش می‌دهد.

حذف نیز یک فرایند قابل کنترل است

فشردن کلید Delete پایان کار نیست. باید روشن باشد داده از کدام نسخه‌های اصلی، Replica و بکاپ حذف می‌شود و چه زمانی دیگر قابل بازیابی نخواهد بود. روش پاک‌سازی به نوع رسانه، حساسیت داده و سیاست سازمان وابسته است. ثبت تأیید مالک و نتیجه اجرا، امکان پاسخ‌گویی بعدی را فراهم می‌کند.

سیاست Legal Hold یا منع حذف نیز لازم است. ممکن است یک پرونده به دلیل اختلاف، حسابرسی یا بررسی امنیتی موقتاً خارج از چرخه عادی نگهداری قرار گیرد. این استثنا باید تاریخ بازبینی و مسئول مشخص داشته باشد؛ وگرنه استثناها به مخزن دائمی تبدیل می‌شوند.

ظرفیت آینده را از روی محرک رشد بسنجیم

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

برنامه ظرفیت بهتر است سه سناریو داشته باشد: ادامه روند فعلی، اجرای سیاست نگهداری و رشد یک پروژه جدید. فرض هر سناریو کنار عدد نوشته می‌شود. مدیریت سپس می‌بیند چه مقدار خرید اجتناب‌ناپذیر است و چه مقدار با اصلاح سیاست به تعویق می‌افتد.

شاخص‌هایی که جلسه بعدی را بهتر می‌کنند

به‌جای گزارش یک درصد کلی مصرف، داشبورد می‌تواند ظرفیت را بر اساس مالک، نوع داده، سن، نرخ رشد و لایه Storage نشان دهد. مقدار داده بدون مالک، حجم منتقل‌شده به آرشیو، زمان بازیابی آزمایشی و موارد پایان‌یافته دوره نگهداری نیز شاخص‌های مفیدی هستند.

هدف شاخص، تشویق حذف بیشتر نیست. اگر واحدی داده قدیمی زیادی دارد اما الزام روشن و دسترسی کنترل‌شده ارائه می‌کند، وضعیت قابل دفاع است. مسئله، داده‌ای است که هزینه دارد ولی دلیل، مالک و مسیر بازیابی آن معلوم نیست.

پایلوت را از یک محدوده قابل فهم آغاز کنیم

سازمان تصمیم می‌گیرد یک Share مربوط به پروژه‌های پایان‌یافته را انتخاب کند. تیم ابتدا مالک‌ها را شناسایی، نمونه داده را طبقه‌بندی و دوره‌های نگهداری را تأیید می‌کند. سپس بخشی به آرشیو منتقل می‌شود و بازیابی چند پرونده آزمایش می‌گردد. داده‌ای که دوره‌اش تمام شده، پس از تأیید و کنترل استثناها حذف می‌شود.

پایلوت باید نتیجه قابل اندازه‌گیری داشته باشد: ظرفیت آزادشده، زمان صرف‌شده، خطاهای برچسب‌گذاری، رضایت کاربران و توان بازیابی. یافته‌ها قبل از گسترش به سامانه‌های دیگر وارد سیاست می‌شوند. این مسیر از اجرای یک دستور حذف گسترده و پرریسک جلوگیری می‌کند.

نقش راگا در تصمیم ذخیره‌سازی

راگا می‌تواند ارزیابی را از موجودی و الگوی مصرف آغاز کند و ارتباط داده فعال، آرشیو، بکاپ و ظرفیت آینده را در یک مدل واحد نشان دهد. خروجی این بررسی باید شامل مالک‌ها، طبقه‌های داده، سطح خدمت هر لایه، قواعد چرخه عمر و سناریوی ظرفیت باشد.

پیشنهاد فنی پس از روشن‌شدن سیاست ارائه می‌شود. ممکن است نتیجه ترکیبی از بهینه‌سازی محیط فعلی، ایجاد لایه آرشیو، استفاده از Object Storage، اصلاح بکاپ یا افزایش هدفمند ظرفیت باشد. ارزش مشاوره در انتخاب تجهیز بیشتر نیست؛ در این است که هر هزینه به یک نیاز روشن و قابل سنجش متصل شود.

جست‌وجو و کشف داده پیش از طبقه‌بندی

سازمان برای تصمیم به دید اولیه نیاز دارد. ابزارهای گزارش‌گیری می‌توانند محل، حجم، سن، مالک احتمالی، نوع فایل و الگوی دسترسی را جمع کنند. این مرحله نباید محتوای حساس را بی‌دلیل در اختیار افراد بیشتری قرار دهد؛ دسترسی تحلیلگران و محل نگهداری گزارش‌ها باید کنترل شود.

خروجی کشف، نقشه‌ای برای گفت‌وگو با واحدهاست و به‌تنهایی حکم حذف صادر نمی‌کند. نمونه‌برداری کمک می‌کند کیفیت Metadata و انتساب مالک بررسی شود. داده رمزگذاری‌شده، پایگاه داده و محتوای برنامه‌های قدیمی ممکن است به روش متفاوتی برای شناسایی نیاز داشته باشند.

بازیابی آرشیو را در شرایط واقعی بسنجیم

انتقال موفق به آرشیو پایان کار نیست. واحد صاحب داده باید بتواند یک پرونده را بر اساس شناسه، تاریخ یا موضوع پیدا و در زمان توافق‌شده دریافت کند. اگر بازیابی فقط با حضور یک متخصص یا اجرای فرایند دستی طولانی ممکن باشد، سطح خدمت واقعی کمتر از تصور خواهد بود.

آزمون دوره‌ای می‌تواند چند درخواست واقعی اما کنترل‌شده را انتخاب کند و زمان جست‌وجو، مجوز، بازیابی و تحویل را اندازه بگیرد. نتیجه به انتخاب لایه، ساختار Metadata و آموزش کاربران بازمی‌گردد. آرشیو اقتصادی وقتی ارزش دارد که داده در لحظه نیاز قابل استفاده بماند.

استثناها را با تاریخ بازبینی اداره کنیم

پروژه تحقیقاتی، پرونده حقوقی یا الزام قراردادی ممکن است دوره عمومی را تغییر دهد. هر استثنا باید مجموعه داده، دلیل، تأییدکننده و تاریخ بازبینی داشته باشد. تمدید خودکار و بی‌پایان، سیاست را بی‌اثر می‌کند. در تاریخ بازبینی، مالک دوباره نیاز را تأیید یا داده را به چرخه عادی بازمی‌گرداند.

تصمیم نهایی جلسه بودجه

در پایان جلسه، خرید فوری به‌طور کامل رد نمی‌شود؛ بخشی از رشد عملیاتی واقعی است. با این حال، مدیریت تصویب می‌کند که خرید با یک Assessment چهار هفته‌ای همراه شود. واحدها مالک داده‌های اصلی خود را معرفی می‌کنند، تیم زیرساخت گزارش سن و مصرف را می‌سازد و حقوق دوره‌های نگهداری را بازبینی می‌کند.

نتیجه مورد انتظار فقط آزادشدن فضا نیست. سازمان باید بتواند برای هر مجموعه مهم بگوید چرا نگهداری می‌شود، کجا قرار دارد، چه زمانی بازیابی می‌شود و چه کسی حذف یا تمدید آن را تأیید می‌کند. وقتی این پاسخ‌ها روشن باشند، Storage از مخزنی که دائماً پر می‌شود به زیرساختی تبدیل می‌شود که بر اساس ارزش داده اداره می‌گردد.

چک‌لیست تصمیم‌گیری

  • ظرفیت و کارایی به‌صورت جداگانه اندازه‌گیری شوند.
  • نوع بار کاری و الگوی رشد داده مشخص باشد.
  • دوره نگهداری و فضای رزرو در محاسبه بیایند.
  • آزمون تحویل و بازیابی با داده نماینده انجام شود.

وضعیت Storage را با داده واقعی بررسی کنید

ظرفیت، کارایی، رشد، نگهداری و بازیابی Storage سازمان را پیش از توسعه یا خرید ارزیابی کنید.

سؤالات متداول

فضای آزاد برای ارزیابی Storage کافی است؟

خیر. تأخیر، IOPS، Throughput، نوع بار کاری، رشد و فضای رزرو نیز باید بررسی شوند.

ظرفیت آینده Storage چگونه محاسبه می‌شود؟

نرخ رشد، دوره نگهداری، کاهش داده، فضای رزرو و زمان تأمین باید در مدل ظرفیت لحاظ شوند.

تحویل Storage چگونه تأیید می‌شود؟

آزمون ظرفیت، کارایی، دسترس‌پذیری و بازیابی باید با معیار پذیرش از پیش توافق‌شده انجام شود.

منابع

[۱] NIST — راهنمای پاک‌سازی رسانه و حذف قابل کنترل داده مشاهده منبع

[۲] Microsoft Learn — مدیریت چرخه عمر داده در Azure Storage مشاهده منبع

مطالب مرتبط در سایت راگا

برای تکمیل این مسیر، خدمات تأمین تجهیزات IT راگا و مقاله «ماندن روی پلتفرم فعلی یا مهاجرت؛ هزینه تغییر را چه کسی حساب کرده است؟» را ببینید.