جلوگیری از اجرای تکراری در اتوماسیون یعنی یک درخواست کاری، حتی اگر پیام آن چند بار برسد یا ارتباط هنگام دریافت پاسخ قطع شود، ناخواسته چند بار اثر نگذارد. این موضوع زمانی مهم می‌شود که گردش کار از مرحله پیشنهاد فراتر می‌رود و واقعاً پرونده ایجاد می‌کند، موجودی را تغییر می‌دهد یا اعلان می‌فرستد. پاسخ‌ندادن یک سرویس همیشه به معنی انجام‌نشدن کار نیست؛ ممکن است عملیات انجام شده باشد، اما پاسخ آن به فرستنده نرسیده باشد.
برای مدیر کسب‌وکار، سؤال اصلی این نیست که نرم‌افزار چند بار تلاش می‌کند. سؤال این است که پس از ابهام، چگونه می‌فهمیم چه کاری واقعاً انجام شده و چه اقدامی هنوز مجاز است. در این راهنما، یک روش عملی برای تعریف این رفتار در پروژه اتوماسیون ارائه می‌کنیم. مثال‌ها فرضی‌اند و ادعای نتیجه یک پروژه مشتری یا تضمین حذف تمام خطاها نیستند.
چرا یک کار ممکن است دوبار انجام شود؟
مشتری دکمه ثبت را دوباره می‌زند، پیام‌رسان یک رویداد را دوباره تحویل می‌دهد، برنامه بعد از توقف دوباره راه می‌افتد یا کارمند از پنل عملیات را تکرار می‌کند. هرکدام می‌تواند چند اجرای فنی برای یک خواسته واحد ایجاد کند. اگر سامانه مقصد هر اجرا را درخواست تازه بداند، ممکن است دو پرونده یا دو اعلان ساخته شود، در حالی که مشتری فقط یک کار خواسته است.
از سوی دیگر، شباهت دو ورودی به‌تنهایی ثابت نمی‌کند که یکی تکراری است. دو سفارش یکسان در دو زمان متفاوت می‌توانند کاملاً معتبر باشند. پس حذف هر چیزی که شبیه مورد قبلی است، راه‌حل قابل اعتماد نیست. ابتدا باید «همان خواسته قبلی» را از «خواسته تازه با محتوای مشابه» جدا کنیم؛ این تعریف بخشی از طراحی کسب‌وکار است.
سه وضعیت را از هم جدا کنید: موفق، ناموفق و نامعلوم
فرض کنید اتوماسیون درخواست ایجاد پرونده را می‌فرستد و زمان انتظار پاسخ تمام می‌شود. در این نقطه، انتخاب فوری وضعیت ناموفق ممکن است اشتباه باشد. شاید پرونده ثبت شده باشد. وضعیت نامعلوم به تیم می‌گوید پیش از اقدام بعدی باید نتیجه در مقصد بررسی شود. این وضعیت نباید پشت یک پیام عمومی «خطا رخ داد» پنهان بماند.
برای هر مرحله بنویسید چه مدرکی موفقیت را ثابت می‌کند. شناسه پرونده مقصد، رسید قابل استعلام یا مشاهده نتیجه از مسیر رسمی می‌تواند مدرک باشد. بازشدن یک پنجره یا ثبت شروع اجرا در گزارش داخلی کافی نیست. شکست قطعی نیز باید نشانه مشخص داشته باشد؛ مثلاً رد درخواست به علت داده نامعتبر، نه صرفاً نبود پاسخ در مهلت تعیین‌شده.
شناسه خواسته کاری را از شماره تلاش جدا کنید
یک خواسته می‌تواند چند تلاش داشته باشد. بنابراین بهتر است شناسه پایدار خواسته و شناسه هر تلاش جدا باشند. کارکنان با شناسه خواسته، کل مسیر را می‌بینند و تیم فنی با شماره تلاش، جزئیات ارتباط را بررسی می‌کند. ساختن شناسه تازه در هر تکرار می‌تواند ارتباط تلاش‌ها را از بین ببرد و مقصد را به اشتباه بیندازد.
در راهنمای AWS درباره APIهای idempotent توضیح داده می‌شود که طراحی مناسب API می‌تواند تکرار درخواست را بدون اثر اضافی ممکن کند و شناسه ارائه‌شده از سوی درخواست‌کننده به تشخیص قصد تکراری کمک می‌کند. این قابلیت باید در قرارداد سرویس مقصد بررسی شود؛ صرف افزودن یک فیلد با این نام به درخواست، چنین تضمینی ایجاد نمی‌کند.
شناسه در چه محدوده‌ای معتبر است؟
شناسه باید در محدوده سازمان، نوع عملیات و مقصد معنا داشته باشد. استفاده اتفاقی از یک شناسه برای دو مشتری نباید باعث حذف درخواست معتبر یکی از آن‌ها شود. مدت نگهداری سابقه نیز مهم است: اگر پیام قدیمی پس از پاک‌شدن سابقه برسد، سامانه باید طبق سیاست مشخص تصمیم بگیرد. عدد مناسب برای این مدت از چرخه واقعی کار و محدودیت سرویس‌ها می‌آید.
اگر محتوای درخواست عوض شد چه می‌شود؟
تکرار همان درخواست با تغییر مبلغ، گیرنده یا نوع خدمت نباید بی‌سروصدا به نتیجه قبلی وصل شود. تیم باید تعیین کند که این حالت رد شود یا به‌عنوان اصلاح مستقل ثبت شود. اپراتور باید بفهمد در حال تلاش مجدد است یا درخواست جدید می‌سازد. این دو دکمه، حتی اگر ظاهر مشابهی داشته باشند، پیامد متفاوتی دارند.
برای هر اثر خارجی یک مرز کنترل تعریف کنید
یک گردش کار ممکن است پرونده بسازد، برچسب تعیین کند و پیام بفرستد. جلوگیری از پرونده تکراری به معنی جلوگیری از پیام تکراری نیست. هر مرحله اثرگذار باید وضعیت و مدرک خودش را داشته باشد. اگر مرحله سوم شکست خورد، شروع دوباره کل گردش ممکن است دو مرحله موفق قبلی را تکرار کند؛ ادامه از نقطه مناسب معمولاً نیازمند ثبت دقیق پیشرفت است.
در طراحی، مشخص کنید کدام سیستم مرجع نهایی هر نتیجه است. اگر دو بخش هم‌زمان خود را مالک ثبت بدانند، رسیدگی به تعارض دشوار می‌شود. همچنین کنترل تکرار باید در برابر اجراهای هم‌زمان بررسی شود؛ بررسی ساده «قبلاً وجود ندارد» و سپس ایجاد، ممکن است وقتی دو اجرا هم‌زمان می‌رسند کافی نباشد. این موضوع را در آزمون پذیرش به‌صورت یک سناریوی مستقل مطرح کنید.
سیاست تلاش مجدد را به نوع خطا وابسته کنید
اشتباه در داده ورودی معمولاً با ارسال دوباره همان داده برطرف نمی‌شود. نبود مجوز نیز با افزایش تعداد تلاش حل نمی‌شود. در مقابل، برخی اختلال‌های موقت ممکن است پس از فاصله زمانی برطرف شوند. مسئول پروژه باید از تیم فنی بخواهد دسته‌بندی خطاها و مسیر هر دسته را مستند کند، نه اینکه برای همه پاسخ‌های ناموفق یک حلقه تکرار مشترک بسازد.
تلاش‌های خودکار باید سقف تعداد، فاصله و مهلت کلی داشته باشند. در راهنمای کنترل تلاش مجدد AWS محدودکردن تکرار و استفاده از فاصله‌گذاری مطرح می‌شود. در پروژه خود، بار مقصد و اهمیت زمانی کار را هم در نظر بگیرید. تکرار نامحدود می‌تواند هم صف را شلوغ کند و هم تشخیص مشکل اصلی را دشوارتر سازد.
وقتی مقصد کنترل تکرار ندارد، چه کنیم؟
برخی نرم‌افزارهای قدیمی شناسه تکرارپذیر یا امکان استعلام دقیق ندارند. در این حالت نباید همان سطح تضمین یک API مجهز را وعده داد. اگر می‌توان درخواست را با یک مرجع یکتا در مقصد جست‌وجو کرد، این مسیر برای تعیین نتیجه مفید است. اگر نتیجه قابل اثبات نیست، توقف و بررسی انسانی ممکن است از تکرار کورکورانه کم‌خطرتر باشد.
کنترل محلی به‌تنهایی همیشه فاصله میان انجام کار در مقصد و ثبت نتیجه در مبدأ را پوشش نمی‌دهد. این محدودیت را در پیشنهاد پروژه بنویسید و برای آن رویه عملیاتی بسازید. مسئول بررسی، مهلت رسیدگی و مدرک لازم برای ادامه باید روشن باشد. برای طراحی این صف، راهنمای نظارت انسانی در اتوماسیون مکمل مناسبی است؛ تمرکز آن بر تصمیم انسانی است، نه مکانیزم جلوگیری از تکرار.
نقش هوش مصنوعی را از اختیار اجرای عمل جدا کنید
مدل می‌تواند شرح درخواست را دسته‌بندی کند یا پیشنهاد اقدام بدهد، اما نباید تنها مرجع تشخیص اینکه یک عمل خارجی قبلاً انجام شده باشد. این تشخیص به وضعیت ثبت‌شده و شواهد مقصد نیاز دارد. اگر مدل در تلاش دوم پاسخ متفاوتی تولید کرد، نباید بدون بررسی، مقصد یا پارامترهای عملیات جاری عوض شوند. پیشنهاد جدید و اجرای درخواست قبلی دو رویداد متفاوت‌اند.
مرز اجرای عمل را در یک لایه قابل کنترل نگه دارید: مجوز، ورودی معتبر، شناسه خواسته و نتیجه قبلی قبل از اقدام بررسی شوند. ثبت این اطلاعات به معنای ذخیره تمام متن‌های حساس در گزارش نیست. فقط داده لازم برای پیگیری را با دسترسی متناسب نگهداری کنید. کیفیت پاسخ مدل، جایگزین کنترل مجوز و سابقه عملیات نمی‌شود.
یک مثال فرضی: تبدیل درخواست پشتیبانی به پرونده
فرض کنید پیام مشتری باید پس از دسته‌بندی، یک پرونده در سامانه خدمات ایجاد کند. پیام دو بار تحویل می‌شود و پاسخ اولین ثبت نیز به‌موقع نمی‌رسد. اگر هر دریافت، یک پرونده تازه بسازد، کارشناس دو کار مشابه می‌بیند. طراحی مطلوب ابتدا هر دریافت را به خواسته اصلی مرتبط می‌کند و سپس وضعیت ثبت پرونده را بررسی می‌کند.
اگر شناسه پرونده قبلاً تأیید شده، دریافت دوم همان نتیجه را دنبال می‌کند. اگر نتیجه نامعلوم است، سامانه از مسیر پشتیبانی‌شده مقصد وضعیت را بررسی می‌کند. اگر هیچ راه مطمئنی برای تعیین نتیجه وجود ندارد، مورد به بررسی ارجاع می‌شود. پس از تأیید ایجاد پرونده، اعلان مشتری نیز با سابقه مستقل کنترل می‌شود تا بازیابی مرحله ثبت، اعلان را دوباره نفرستد.
صفحه عملیات باید به اپراتور کمک کند تصمیم درست بگیرد
نمایش یک چراغ قرمز کافی نیست. صفحه باید نام عمل، مقصد، آخرین وضعیت، زمان آخرین تلاش و مدرک نتیجه را نشان دهد. اقدام‌های «بررسی وضعیت»، «ادامه تلاش مجاز» و «ساخت درخواست جدید» باید تفاوت روشن داشته باشند. اگر ثبت دوباره می‌تواند پیامد مهمی ایجاد کند، دلیل تصمیم و نقش تأییدکننده ثبت شود.
همچنین مشخص کنید چه کسی مالک کارهای نامعلوم است. صفی که فقط رشد می‌کند و مسئول ندارد، راه‌حل محسوب نمی‌شود. اولویت رسیدگی را بر اساس اثر کسب‌وکاری و زمان انتظار تعیین کنید، نه صرفاً ترتیب ایجاد خطا. این گزارش باید موارد واقعاً متوقف را از تلاش‌های خودکار برنامه‌ریزی‌شده جدا نشان دهد تا کارکنان بی‌جهت مداخله نکنند.
آزمون پذیرش را با قطع ارتباط و اجرای هم‌زمان کامل کنید
فقط مسیر موفق را آزمایش نکنید. دو دریافت هم‌زمان، قطع پاسخ پس از ثبت مقصد، توقف برنامه بین مراحل، پیام دیررس و اصلاح محتوا با شناسه قبلی را در محیط آزمون اجرا کنید. برای هر حالت، تعداد آثار مجاز در مقصد و وضعیت قابل مشاهده در پنل را از قبل بنویسید. معیار، تعداد دفعات اجرای کد نیست؛ نتیجه کاری است.
تغییر قانون گردش کار نیز باید پوشش داده شود. یک تلاش قدیمی نباید ناخواسته تحت قواعد جدید به اقدام دیگری تبدیل شود. این موضوع با نسخه‌بندی قوانین اتوماسیون مرتبط است، اما جای آن را نمی‌گیرد: نسخه‌بندی مشخص می‌کند کدام قانون اجرا شود و کنترل تکرار مشخص می‌کند همان عمل دوباره اثر نگذارد. هر دو باید در سناریوی بازیابی دیده شوند.
چه چیزهایی را در محدوده پروژه بنویسیم؟
برای هر عملیات اثرگذار، مقصد، شناسه کاری، روش اثبات نتیجه، رفتار تکرار، سیاست خطا و مسئول استثنا را مشخص کنید. محدودیت سرویس‌های بیرونی را جدا بنویسید و ادعای «همیشه دقیقاً یک بار» را بدون تعریف دامنه نپذیرید. نتیجه قابل اتکا از ترکیب قرارداد فنی، وضعیت ثبت‌شده، آزمون و رویه عملیاتی به دست می‌آید، نه از یک کلید تنظیمات.
برای بررسی خدمات هوش مصنوعی و اتوماسیون ایزی‌ساز، یک نمونه گردش کار واقعی و فهرست اقدام‌هایی را آماده کنید که تکرارشان هزینه یا اختلال ایجاد می‌کند. این فهرست نقطه شروع خوبی برای تعیین اولویت کنترل‌هاست. ابتدا حساس‌ترین اثرها را قابل پیگیری کنید و سپس دامنه اتوماسیون را گسترش دهید.