اجرای پایدار؛ راهکار جلوگیری از پرداخت‌های تکراری در عامل‌های هوش مصنوعی

تصور کنید یک فراخوانی API پرداخت با موفقیت انجام می‌شود، اما درست پیش از آنکه سیستم تراکنش را ثبت کند، پردازش کرش می‌کند. اگر عامل هوش مصنوعی شما صرفاً از ابتدا ری‌استارت شود، مشتری را برای بار دوم شارژ خواهد کرد؛ شکستی که هیچ مقدار مهندسی پرامپت (Prompt Engineering) نمی‌تواند آن را حل کند.

این «مسیر نامرئی» شکست، یکی از رایج‌ترین ریسک‌های محیط‌های عملیاتی (Production) است. این چالش در واقع ریشه در نقص‌های ساختاری گردش‌کارهای محاسباتی گذرا دارد که منجر به تکرار تراکنش‌ها می‌شود. طبق یک راهنمای فنی که در ۲۱ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این کرش‌ها اغلب بر اثر کشتن پردازش به دلیل کمبود حافظه (OOM kills)، قطع شدن نمونه‌های Spot یا استقرار (Deployment) ناگهانی نسخه‌های جدید رخ می‌دهند. اکثر توسعه‌دهندگان تنها خطاهای آشکار، مانند پاسخ ۵۰۰ API را تست می‌کنند، اما شکاف زمانی میان یک اثر جانبی موفق و ثبت آن در دیتابیس را نادیده می‌گیرند.

برای حل این مشکل، توسعه‌دهندگان به سراغ اجرای پایدار (Durable Execution) از طریق Dapr Workflow رفته‌اند. این سازوکار — شبیه به یک جعبه‌سیاه هواپیما که هر لحظه را ثبت می‌کند — تمام گام‌های تکمیل‌شده را در یک لاگ دائمی (Durable Log) هم‌زمان با اجرای جریان کاری ذخیره می‌کند. وقتی یک پردازش بازیابی می‌شود، محیط اجرا (Runtime) لاگ را بازپخش (Replay) کرده، نتایج ثبت‌شده برای گام‌های تمام‌شده را فوراً برمی‌گرداند و اجرا را تنها از اولین وظیفه ناتمام از سر می‌گیرد.

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

پیاده‌سازی فنی

در استفاده از Dapr Workflow با زبان پایتون، فرآیند به فعالیت‌ها و جریان‌های کاری انتزاع می‌شود:

• فعالیت‌ها (Activities): اثرات جانبی، مانند charge_card یا send_receipt در توابع مجزا ایزوله می‌شوند.
• جریان‌های کاری (Workflows): منطق اصلی (مثلاً order_flow) این فعالیت‌ها را با استفاده از yield ctx.call_activity به هم زنجیر می‌کند.
• بازیابی (Recovery): اگر پردازش بلافاصله پس از پرداخت توسط دستور kill -9 یا docker kill متوقف شود، سیستم هنگام شروع مجدد، نتیجه پرداخت را از تاریخچه بازیابی می‌کند و به جای اجرای مجدد پرداخت، نتیجه را بازمی‌گرداند.

یک پیش‌نیاز حیاتی در این سیستم، استفاده از کلیدهای یکتایی‌ساز (Idempotency Keys) است. چون ممکن است پردازش در شکاف میلی‌ثانیه‌ای بین بازگشت پاسخ موفق از ارائه‌دهنده پرداخت و ثبت آن در لاگ پایدار بمیرد، احتمال دارد فعالیت همچنان دو بار اجرا شود. یک کلید یکتایی‌ساز تضمین می‌کند که ارائه‌دهنده پرداخت درخواست تکراری را شناسایی کرده و تراکنش دوم را انجام ندهد.

برای توسعه‌دهنده، این یعنی بار مدیریت وضعیت از کد برنامه به محیط اجرا (Runtime) منتقل می‌شود. دیگر نیازی به ساخت دستی جداول چک‌پوینت یا ستون‌های «آیا این کارت قبلاً شارژ شده است؟» نیست و توسعه‌دهنده کد پایتون استاندارد می‌نویسد که از بالا به پایین خوانده می‌شود.

این رویکرد، تعریف بنیادین قابلیت اطمینان در عامل‌ها را تغییر می‌دهد. بازیابی دیگر چیزی نیست که برای هر فراخوانی ابزار به‌طور جداگانه طراحی شود، بلکه یک ویژگی سیستمی از محیط اجراست. عیب‌یابی نیز از حدس زدن بر اساس لاگ‌ها، به بررسی یک رکورد عینی (Concrete) از اینکه دقیقاً کدام گام‌ها اجرا شده‌اند و چه نتایجی برگردانده‌اند، تبدیل می‌شود.

گام بعدی شما

• سیستم خود را با «تست بدترین حالت» بررسی کنید: یک جریان کاری حساس را اجرا کرده و دقیقاً لحظه تکمیل اثر جانبی، پردازش را Force-kill کنید.
• اگر سیستم شما نمی‌تواند ثابت کند که بدون تکرار عملیات بازیابی شده است، مشتریان شما در نهایت بهای این نقص را می‌پردازند.
• برای پیاده‌سازی، مستندات Dapr Workflow را برای مدیریت وضعیت در پایتون مطالعه کنید.

اما داستان سخت‌افزاری این پایداری حتی پیچیده‌تر است — به تحلیل ما درباره‌ی مدیریت حافظه در خوشه‌های GPU مراجعه کنید.