برش بازیابی: بازسازی سامانه هوش مصنوعی بدون آمیختن خط‌های زمانی

یک دستیار پشتیبانی پس از قطعی بالا می‌آید. پایگاه داده تا ۰۹:۴۰ بازیابی شده، ذخیره‌گاه فایل وضعیت ۰۹:۵۵ را دارد، نمایه برداری از نسخه دیشب آمده و پرامپت متعلق به انتشار ۱۰:۰۵ است. سرویس پاسخ می‌دهد و بررسی‌های سلامت سبزند. اما این ترکیب هرگز وجود نداشته است: بعضی اسناد هنوز در پایگاه داده نیستند، برخی بردارها فایل‌های بعداً تغییریافته را توصیف می‌کنند و پرامپت، طرح ابزاری را فرض می‌کند که رابط بازیابی‌شده نمی‌شناسد.

پس تصمیم خواننده فقط این نیست که «نسخه پشتیبان داریم یا نه؟» پرسش دقیق‌تر چنین است: هر جزء این سامانه هوش مصنوعی باید بازیابی شود، از نو ساخته شود یا آگاهانه کنار گذاشته شود؛ و کدام برش مشترک بازیابی، مجموعه حاصل را برای ارائه خدمت ایمن می‌کند؟ Restore موفق، بایت‌ها را برمی‌گرداند. Recovery موفق، قابلیتی منسجم را به کسب‌وکار برمی‌گرداند که میزان فقدانش معلوم است، اجزایش با هم سازگارند، اثرهایش در سامانه‌های بیرونی تطبیق داده شده و شواهد کافی برای ازسرگیری کار دارد.

بازیابی را به‌صورت یک وضعیت کسب‌وکار تعریف کنید

هدف‌های کلاسیک بازیابی همچنان ضروری‌اند. راهنمای بازیابی بحران AWS، «هدف نقطه بازیابی» یا RPO را به میزان قابل‌قبول فقدان داده و «هدف زمان بازیابی» یا RTO را به مدت قابل‌قبول توقف خدمت پیوند می‌دهد. راهنمای برنامه‌ریزی Google Cloud نیز که آخرین بار در ژوئیه ۲۰۲۴ بازبینی شده، از تحلیل اثر کسب‌وکار آغاز می‌کند و توضیح می‌دهد که RPO و RTO سخت‌گیرانه‌تر معمولاً هزینه و پیچیدگی عملیاتی بیشتری دارند.

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

معیار پذیرش را با زبان کسب‌وکار بنویسید. برای نمونه:

تا ساعت ۱۲:۰۰، کارشناسان پشتیبانی می‌توانند تمام پرونده‌های قطعی‌شده پیش از ۰۹:۴۲ را ببینند؛ هیچ اقدام پس از ۰۹:۴۲ بی‌صدا تکرار نمی‌شود؛ همه پاسخ‌ها از پرامپت و سیاست تأییدشده انتشار ۱۸ استفاده می‌کنند؛ و هر تیکت یا پیام نامطمئن برای تطبیق متوقف می‌ماند.

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

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

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

گراف وضعیت را با پنج طبقه بسازید:

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

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

یک برش بازیابی انتخاب کنید، نه تازه‌ترین نسخه هر جزء

برش بازیابی تازه‌ترین مرزی است که در آن می‌توان وضعیت مرجع، اجرای نسخه‌دار و اثرهای بیرونی شناخته‌شده را با یکدیگر سازگار کرد. این مرز می‌تواند نشانگر تراکنش پایگاه داده، restore point نام‌گذاری‌شده، offset لاگ رویداد، manifest انتشار، مجموعه نسخه‌های فایل یا بسته‌ای از چند نشانگر مرتبط باشد. اتکا به ساعت دیواری کافی نیست؛ ساعت‌ها اختلاف دارند، نوشتن‌ها دیر می‌رسند و بعضی سامانه‌ها زمان وقوع رویداد را جدا از زمان پردازش نگه می‌دارند.

مستندات کنونی بازیابی نقطه‌ای PostgreSQL توضیح می‌دهد چگونه می‌توان با یک base backup و آرشیو write-ahead log، پایگاه داده را تا هدف انتخاب‌شده برگرداند. این مستند زنجیره وابستگی را نیز روشن می‌کند: بازیابی افزایشی به نسخه‌های قبلی و فایل‌های لاگ و تاریخ مرتبط نیاز دارد. این تضمین پایگاه داده است، نه تضمین کل سامانه هوش مصنوعی. بسته بازیابی هنوز باید مشخص کند کدام نسخه فایل، offset رویداد، digest انتشار و دستور ساخت نمایه با آن هدف پایگاه داده متناظر است.

از تمایزهای راهنمای معناشناسی زمان استفاده کنید:

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

اگر اجزا نمی‌توانند یک برش مشترک داشته باشند، مقدار اختلاف را ثبت و قابلیت آسیب‌دیده را قرنطینه کنید. ترکیب پایگاه داده ۰۹:۴۰ و نمایه ۱۰:۰۵ را پشت عبارت «آخرین نسخه موجود» پنهان نکنید.

میان بازیابی، بازسازی و کنارگذاشتن تصمیم بگیرید

این سه روش مسئله‌های متفاوتی را حل می‌کنند:

نمایه برداری معمولاً نامزد بازسازی است، نه مرجع اصلی. منبع مجاز، قواعد قطعه‌بندی، digest مدل embedding، تنظیمات، کنترل دسترسی و نگاشت منبع به بردار را حفظ کنید. snapshot نمایه فقط وقتی RTO را کوتاه می‌کند که منشأش با برش یکی باشد؛ وگرنه آن را بسازید و تعداد سند، پارتیشن مستأجر، نشانگر حذف و پرس‌وجوی آزمون را تطبیق دهید.

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

بسته بازیابی را طراحی کنید

بسته بازیابی، manifest محافظت‌شده‌ای برای مواد لازم یک برش است و باید شامل این موارد باشد:

1. خدمت کسب‌وکار، RTO، RPO، بیشینه اختلاف زمانی اجزا و حالت تنزل‌یافته قابل‌قبول؛
2. هدف‌های پایگاه داده، offsetهای رویداد، manifest نسخه فایل و پارتیشن‌های مستأجر؛
3. گذرنامه انتشار تأییدشده برای کد، مدل، پرامپت، سیاست، طرح ابزار و زیرساخت؛
4. دستور ساخت و snapshot منبع هر نمایه، مجموعه ویژگی یا خلاصه‌ای که بازسازی می‌شود؛
5. رسید اثرهای بیرونی، کلیدهای idempotency و پرس‌وجوهای تطبیق؛
6. روش صدور دوباره کلید و راه‌اندازی هویت از یک مرز مدیریتی پاک؛
7. داده آزمون، پرس‌وجوهای invariant، probeهای خصمانه مرز مستأجر و نتیجه مورد انتظار؛ و
8. مالک تصمیم برای مهار، انتخاب برش، خدمت تنزل‌یافته، فعال‌کردن نوشتن و بازگشت به محیط اصلی.

بسته و runbook را جایی نگه دارید که با ازکارافتادن control plane اصلی همچنان قابل‌دسترسی باشد. راهنمای قطعی زیرساخت Google Cloud که آخرین بار در مه ۲۰۲۴ بازبینی شده، هشدار می‌دهد عملیات حیاتی نباید برای رسیدن به هدف بازیابی به تغییرات management plane مانند ساخت ماشین مجازی یا به‌روزرسانی مجوز IAM وابسته باشد. جزئیات هر تأمین‌کننده فرق دارد، اما پرسش معماری عمومی است: آیا مسیر بازیابی وقتی اجرا می‌شود که همان سامانه پیکربندی‌کننده مسیر از کار افتاده باشد؟

با ترتیب کنترل‌شده بازیابی کنید

NIST SP 800-34 Rev. 1 که در ۲۰۱۰ منتشر شده، فعال‌سازی و اطلاع‌رسانی، بازیابی و بازبرپایی را از هم جدا می‌کند؛ در مرحله آخر باید با آزمون، سامانه بازگردانده‌شده پیش از شروع کار عادی اعتبارسنجی شود. NIST SP 800-184 که در دسامبر ۲۰۱۶ منتشر شده، playbook، آزمون واقع‌گرایانه، سنجه و بهبود مستمر را به بازیابی رخداد سایبری می‌افزاید. این انضباط را به ترتیب زیر تبدیل کنید:

1. مهار و حفظ شواهد: نوشتن خودکار، export، ورود داده آموزشی، تازه‌سازی نمایه و کار حذف را متوقف کنید. لاگ و رسیدها را نگه دارید، اما میزبان احتمالاً آلوده را مرجع قابل‌اعتماد ندانید.
2. انتخاب و تصویب برش: آخرین نقطه قابل‌قبول و بازه عدم قطعیت را تعیین کنید. علت رد نسخه جدیدتر را بنویسید.
3. راه‌اندازی کنترل پاک: اپراتور قابل‌اعتماد، اعتبارنامه تازه، زیرساخت بازیابی و manifest تغییرناپذیر فراهم کنید. وضعیت هویت زمان حادثه را کورکورانه وارد نکنید.
4. ابتدا مرجع را برگردانید: سامانه‌های مرجع و تاریخ رویداد را بازیابی کنید و تعداد، قید، مالکیت و جداسازی مستأجر را بسنجید.
5. ترکیب سازگار را مستقر کنید: زیرساخت و نسخه دقیق مدل، پرامپت، سیاست، کد و قرارداد ابزار متناسب با برش را برپا کنید.
6. مشتق‌ها را بسازید: نمایه، embedding، خلاصه و cache را از ورودی معتبر بسازید و تا پایان تطبیق، آن‌ها را ناقص علامت بزنید.
7. اثرهای بیرونی را تطبیق دهید: سامانه دوردست را با کلید idempotency یا رسید بپرسید. پیش از retry، هر اثر را قطعی، غایب، معکوس‌شده یا نامعلوم طبقه‌بندی کنید.
8. تدریجی به خدمت برگردید: ابتدا در انزوا آزمون کنید، سپس خواندن محدود، نوشتن منتخب و در پایان ترافیک عادی را باز کنید. موارد نامطمئن در صف انسانی بمانند.

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

مثال عملی: دستیار پشتیبانی در ساعت ۰۹:۴۲

ساعت ۱۰:۱۵ تیم می‌فهمد importer از ۰۹:۴۳ اسناد را به مستأجر اشتباه وصل کرده است. دستیار بعدتر فایل‌ها را برداری و دو گفت‌وگو را خلاصه کرده، سه تیکت و یک ایمیل فرستاده است. پایگاه داده PITR و سرویس برداری snapshot ساعتی دارد؛ سامانه تیکت در تراکنش محلی شریک نیست.

تیم ساعت ۰۹:۴۲ را به‌عنوان برش انتخاب می‌کند:

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

راهنمای بازیابی Foundry Agent Service مایکروسافت برای استقرار Standard می‌گوید سرویس، replication داخلی، backup، بازیابی نقطه‌ای، active-active میان‌منطقه‌ای یا ادغام وضعیت ندارد. روش پیشنهادی اغلب reconstruction و نگهداری تعریف agent مانند کد است؛ بخشی از thread هم ممکن است برنگردد. این مرز یک محصول است، نه محدودیت همگانی، اما نشان می‌دهد «agent مدیریت‌شده» لزوماً «بازیابی مدیریت‌شده» نیست.

اعتبار کسب‌وکار را بیازمایید، نه پایان موفق job را

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

• RTO و RPO تحقق‌یافته برای قابلیت کسب‌وکار، نه فقط سرویس ذخیره‌سازی؛
• بیشینه اختلاف میان اجزای مرجع بازیابی‌شده؛
• درصد رکوردهای مشتق‌شده دارای منشأ منبع و دستور ساخت؛
• نرخ رکورد بی‌منبع، تکراری و فایل مفقود پس از بازسازی؛
• تعداد اثر بیرونی نامعلوم هنگام فعال‌کردن نوشتن؛
• نقض مرز مستأجر و نشانگر حذف؛
• زمان صرف‌شده برای گام‌های دستی مستندننشده؛ و
• درصد بررسی‌های پذیرشی که نتیجه مورد انتظارشان پیش از مانور تعیین شده بود.

مدارک را به راهنمای شواهد ممیزی هوش مصنوعی وصل کنید. تصویر صفحه‌ای که می‌گوید «restore succeeded» فقط موفقیت گزارش‌شده یک job را ثابت می‌کند. مدرک قوی‌تر، برش مصوب، manifest اقلام، هش‌ها، offset لاگ، پرس‌وجوی آزمون، رسید اثر بیرونی، تصمیم اپراتور، انحراف و مجوز نهایی شروع خدمت را به هم پیوند می‌دهد.

دروازه انتشار

تا وقتی مالک سامانه به پرسش‌های زیر پاسخ مثبت نداده، آن را بازیابی‌پذیر ننامید:

1. آیا قابلیت کسب‌وکار، حالت تنزل‌یافته، RTO، RPO و بیشینه اختلاف قابل‌قبول اجزا روشن است؟
2. آیا وضعیت مرجع، نسخه‌دار، مشتق‌شده، اثر بیرونی و موقت طبقه‌بندی شده‌اند؟
3. آیا می‌توان یک برش را برای پایگاه داده، فایل، رویداد، انتشار و نمایه نام برد؟
4. آیا هر ذخیره‌گاه مشتق‌شده دستور بازسازی آزموده‌شده و manifest منبع دارد؟
5. آیا اثر بیرونی بدون retry کور قابل‌تطبیق است؟
6. آیا اعتبارنامه و مسیر کنترل بازیابی از مرز خراب مستقل‌اند؟
7. آیا قواعد حذف، نگهداری، حاکمیت مکانی و مستأجر در backup و محیط بازیابی برقرارند؟
8. آیا تیم پیش از فعال‌کردن نوشتن می‌تواند اعتبار سطح برنامه را ثابت کند؟
9. آیا بازگشت به محیط اصلی بدون دورریختن اقدام‌های دوره تنزل‌یافته تمرین شده است؟
10. آیا کل فرایند در یک مانور زمان‌دار و واقع‌گرایانه به هدف رسیده است؟

پس از هر تغییر مدل، پرامپت، سیاست، نمایه، هویت، منطقه، تأمین‌کننده، نگهداری یا ابزار، برنامه را بازبینی کنید. وقتی زمان Restore به RTO نزدیک می‌شود، پوشش منشأ افت می‌کند، مانور وابستگی پنهان به control plane را آشکار می‌کند یا محصول وضعیت موقتی را به وعده‌ای برای کاربر تبدیل می‌کند نیز بازبینی لازم است. بازیابی قابلیت ذخیره‌سازی نیست؛ توافقی زنده درباره تاریخی است که سازمان می‌تواند با اطمینان از سر بگیرد.

یادداشت منابع — بازبینی‌شده در ۲۰۲۶-۰۸-۱۸

• NIST SP 800-34 Rev. 1 — انتشار مه ۲۰۱۰ و به‌روزرسانی نوامبر ۲۰۱۰؛ برنامه اقتضایی، مراحل بازیابی، بازبرپایی و اولویت‌های اثر کسب‌وکار.
• NIST SP 800-184 — انتشار ۲۲ دسامبر ۲۰۱۶؛ playbook بازیابی، تمرین واقع‌گرایانه، سنجه و بهبود.
• راهنمای توسعه امن سامانه هوش مصنوعی NCSC — انتشار و بازبینی ۲۷ نوامبر ۲۰۲۳؛ فهرست دارایی هوش مصنوعی، نسخه‌بندی، حفاظت، failover و بازگرداندن وضعیت سالم شناخته‌شده.
• راهنمای بازیابی workload در AWS — تعریف RPO، RTO، دسترس‌پذیری، تاب‌آوری و تداوم کسب‌وکار.
• راهنمای برنامه‌ریزی بازیابی Google Cloud — آخرین بازبینی ۵ ژوئیه ۲۰۲۴؛ تحلیل اثر کسب‌وکار و موازنه RPO و RTO.
• معماری قطعی زیرساخت Google Cloud — آخرین بازبینی ۱۰ مه ۲۰۲۴؛ بازیابی سرتاسری، صحت، طبقه‌بندی اهمیت و محدودیت وابستگی به management plane.
• آرشیو پیوسته و بازیابی نقطه‌ای PostgreSQL — مستندات نسخه جاری ۱۸، بازبینی‌شده در ۱۸ اوت ۲۰۲۶؛ base backup، آرشیو WAL، وابستگی افزایشی، هدف بازیابی و timeline.
• بازیابی بحران Microsoft Foundry Agent Service — راهنمای رسمی جاری، بازبینی‌شده در ۱۸ اوت ۲۰۲۶؛ مرز وضعیت، reconstruction، محدودیت سرویس و مانور بازیابی.