castomFLOW
باز کردن castomFLOW

اجراهایی که می‌توانید به آن‌ها اعتماد کنید

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

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

پیش از انتشار، شبیه‌سازی کنید

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

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

شبیه‌سازی پاسخِ همان پرسشی است که مانع روشن‌کردن اتوماسیون می‌شود: این در واقع چه‌کاری خواهد کرد؟

شبیه‌سازی · سفارش ۸۸ ۲۱۴هیچ چیزی ارسال نشد
  • 1اعتبارسنجی نشانیمطابقت داشت. می‌نوشت ۶ فیلد را.
  • ?شرطسفارش بالای ۱۰۰۰ زلوتی؟ نه — ۲۸۹٫۰۰ زلوتی. مسیر کوتاه طی شد.
  • 3فاکتوربه سیستم صدور فاکتور POST می‌شد. محموله به‌طور کامل نمایش داده شده است.
  • !اینجا گرفته شدنرخ مالیات بر ارزش افزوده از فیلد اشتباه نگاشت شده بود. در یک شبیه‌سازی پیدا شد، نه در صندوق ورودی یک حسابدار.

ارسال‌شده: هیچدریافت‌شده: هیچ

هر اجرا روی نسخه‌ای که با آن وارد شده حرکت می‌کند

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

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

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

ویرایش در حین کارنسخه ۴ ← نسخه ۵
  • 1قبل۲۹۱۸ اجرا در جریان، همگی روی نسخه ۴. برخی در انتظاری دو روزه.
  • 2انتشار نسخه ۵دو گام جابه‌جا شد، یک پیام بازنویسی شد.
  • 3بعدآن ۲۹۱۸ اجرا نسخه ۴ را به پایان می‌رسانند. هر چیز که از ۱۱:۴۰ آغاز شود نسخه ۵ را اجرا می‌کند.
  • §هیچ‌کسنیمی از یک گردش‌کار و نیمی از گردش‌کار دیگر دریافت نکرد.

نسخه روی هر اجرا ثبت می‌شودنسخه‌های قدیمی نگه داشته می‌شوند

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

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

این تمام ترفند است، و یک ویژگی ساختاری است نه یک وعده. کارگری که در میانه یک گام از بین برود — یک استقرار، یک خرابی، ماشینی که ناپدید می‌شود — اجرا را دقیقاً همان‌جا که بود رها می‌کند. کارگر دیگری آن را برمی‌دارد و گام را دوباره اجرا می‌کند. چون اثر و پیشروی یکجا ثبت می‌شوند، یا هر دو رخ داده‌اند یا هیچ‌کدام.

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

کارگر در میانه ارسال از بین رفتبازیابی شد
  • 1گام ۵ آغاز می‌شوداعلان ارسال را بفرست.
  • ✕کارگر از کار افتاداستقرار. هیچ چیزی ثبت نشده بود.
  • 2برچیده شدکارگر دیگری اجرا را همچنان روی گام ۵ می‌یابد.
  • ✓یک‌بار ارسال شدمشتری یک ایمیل دریافت کرد، نه دو ایمیل.

اثرات همراه با پیشروی ثبت می‌شوندکلید ایدمپوتنسی برای هر اجرا و هر گام

گزارشی که برای خواندن توسط انسان نوشته شده است

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

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

اجراهای ناموفق در یک جا جمع می‌شوند و علت آن‌ها گروه‌بندی می‌شود، تا «چهل‌ویک خطا در طول شب» به «یک تأمین‌کننده به مدت نه دقیقه 503 برگردانده» تبدیل شود، نه چهل‌ویک بررسی جداگانه.

در طول شب، گروه‌بندی‌شده۴۱ خطا
  • 1یک علتAPI تأمین‌کننده بین ۰۲:۴۱ تا ۰۲:۵۰ وضعیت 503 برگرداند.
  • 2چه اتفاقی افتادهر ۴۱ مورد دوباره اجرا شدند؛ ۳۹ مورد در تلاش دوم موفق شدند.
  • 3باقی‌ماندهدو مورد متوقف شده‌اند و منتظر یک نفر هستند. هر دو همراه با ردیفِ ناموفق فهرست شده‌اند.
  • §نه چهل‌ویکبررسی. فقط یکی، و یک تصمیم دربارهٔ دو رکورد.

اعتبارنامه‌ها پنهان‌سازی شدندنسخه ثبت شد

چه چیزهایی را ادعا نمی‌کنیم

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

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

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

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