‏ساختن نرم‌افزار مقاوم با هوش مصنوعی و برنامه‌ریزی برای روز فاجعه

Gergely Orosz تو خبرنامه Pragmatic Engineer چند بخش از کتاب تازه Sam Newman به اسم Building Resilient Distributed Systems رو منتشر کرده. به گفته Orosz، نوشتن کتاب به‌جای دو سال سه سال طول کشیده، چون Newman برگشته و هرجا هوش مصنوعی مربوط بوده، اون بخش رو از نو نوشته. موضوع اصلی اینه که اگه یه اتفاق بزرگ مثل آتش‌سوزی، قطعی برق یا خرابی کل یه ریجن ابری پیش بیاد، چطور سیستم رو برگردونی.

Newman برای این کار دو معیار پیشنهاد می‌ده. RPO یعنی حداکثر داده‌ای که می‌تونی از دست بدی؛ اگه هر یک ساعت بکاپ می‌گیری، RPO یک ساعت‌ه. RTO یعنی سیستم حداکثر چقدر می‌تونه خوابیده باشه تا دوباره بالا بیاد. به گفته نویسنده، صفر کردن هر دوتاش عملاً ممکن نیست و هرچی کمترشون کنی، هزینه و پیچیدگی خیلی بیشتر می‌شه. تازه بخش‌های مختلف یه سیستم هم می‌تونن RPO و RTO متفاوت داشته باشن؛ مثلاً تو یه بانک، پرداخت مهم‌تر از ثبت‌نام مشتری جدیده. نویسنده معتقده این دوتا خوب تو قالب SLO جا نمی‌شن، چون فاجعه اونقدر زیاد اتفاق نمی‌افته که بشه براش داده جمع کرد.

کتاب چهار الگو رو به ترتیب هزینه و پیچیدگی معرفی می‌کنه. Backup and Restore ارزون‌ترینه ولی RTO طولانی داره. تو Pilot Light داده مدام به سایت دوم کپی می‌شه ولی سرورها فقط موقع خرابی ساخته می‌شن. Warm Failover از قبل یه مقدار زیرساخت آماده داره، معمولاً برای سرویس‌های حیاتی‌تر. Multisite Active-Active هم ترافیک رو همزمان از چند سایت سرو می‌کنه و کمترین RTO و RPO رو داره، ولی گرون‌ترینه.

یه نکته تازه کتاب کمبود زیرساخت‌ه. Newman می‌گه به‌خاطر تقاضای GenAI، قیمت GPU و حافظه تو ۲۰۲۵ و ۲۰۲۶ خیلی بالا رفته و بعضی مشتری‌هاش حتی برای کارهای معمولی هم ظرفیت کافی تو ابرهای بزرگ پیدا نمی‌کنن. پس اگه طرحت روی این حساب کرده که موقع خرابی سرور جدید بالا میاری، ممکنه با بقیه سر همون ظرفیت کم دعوا کنی. راه‌حل‌هایی که پیشنهاد می‌ده: رزرو ظرفیت (مثلاً EC2 تو AWS، البته Lambda رو نمی‌شه رزرو کرد)، اولویت دادن به سرویس‌های حیاتی، یا داشتن زیرساخت کاملاً اضافه که وقتی بیکاره برای کاری مثل load test ازش استفاده کنی.

در مورد نرم‌افزارهایی که از مدل‌های هوش مصنوعی استفاده می‌کنن، Newman می‌گه OpenAI و Anthropic در مقایسه با ارائه‌دهنده‌های ابری سابقه پایداری خوبی ندارن. پیشنهادش graceful degradation هست، یعنی اگه مدل در دسترس نبود سیستم با قابلیت کمتر کار کنه، یا داشتن ارائه‌دهنده پشتیبان، مثلاً مدل‌های OpenAI روی Azure. یه مشکل دیگه اینه که رفتار مدل‌ها ممکنه بی‌خبر عوض بشه، پس باید هم تست معمولی داشته باشی هم evals (یعنی ابزارهایی که خروجی مدل رو ارزیابی می‌کنن). latency مدل‌ها هم خیلی نوسان داره، برای همین نویسنده پیشنهاد می‌ده timeout رو بر اساس تعداد توکن تنظیم کنی یا جریان خروجی مدل رو زیر نظر بگیری.

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

نکات کلیدی:

• RPO یعنی حداکثر داده از دست رفته و RTO یعنی حداکثر زمان از کار افتادن سیستم.
• چهار الگوی بازیابی: Backup and Restore، Pilot Light، Warm Failover و Multisite Active-Active.
• قیمت GPU و حافظه تو ۲۰۲۵ و ۲۰۲۶ بالا رفته و ساختن سرور تازه موقع فاجعه تضمینی نیست.
• تو AWS می‌شه ظرفیت EC2 رو رزرو کرد ولی برای Lambda این امکان نیست.
• مدل‌های OpenAI روی Azure هم در دسترسن و می‌تونن ارائه‌دهنده پشتیبان باشن.
• استفاده همزمان از مدل‌های چند ارائه‌دهنده تو یه flow ریسک قطعی رو بیشتر می‌کنه.