نسخه‌بندی قوانین اتوماسیون یعنی هر تغییر مهم در منطق یک فرایند با شناسه، تاریخ انتشار و دامنه اجرای مشخص ثبت شود؛ نمونه‌های جدید با نسخه تازه آغاز شوند و کارهایی که قبلاً شروع شده‌اند تا پایان با منطق سازگار خود ادامه دهند. بدون این مرزبندی، یک تغییر ظاهراً ساده در شرط، ترتیب مراحل یا ساختار داده می‌تواند درخواست‌های در حال اجرا را متوقف کند، نتیجه‌های متناقض بسازد یا امکان توضیح تصمیم سیستم را از بین ببرد.
این راهنما برای مدیر عملیات، مالک فرایند، تیم محصول و تیم فنی نوشته شده است. هدف، انتخاب یک ابزار خاص نیست؛ هدف ساختن روشی است که بتوان قانون اتوماسیون را تغییر داد، اثر آن را سنجید و در صورت مشکل به نسخه امن برگشت، بدون آنکه سفارش، درخواست، پرونده یا کار جاری گم شود.
پاسخ کوتاه: چرا نسخه‌بندی قانون با تاریخچه تغییر فرق دارد؟
تاریخچه تغییر فقط می‌گوید چه کسی چه چیزی را عوض کرده است. نسخه‌بندی علاوه بر آن مشخص می‌کند هر نمونه فرایند با کدام مجموعه قانون اجرا می‌شود. اگر امروز حد تأیید مالی تغییر کند، درخواست دیروز نباید ناگهان وسط مسیر به شاخه‌ای برود که هنگام شروع وجود نداشته است؛ مگر اینکه یک تصمیم مهاجرت صریح و کنترل‌شده گرفته شده باشد.
پس سه شناسه باید از هم جدا باشند:
- شناسه تعریف فرایند: نوع جریان، مانند «تأیید خرید»؛
- شناسه نسخه: منطق منتشرشده، مانند نسخه فعال در یک بازه مشخص؛
- شناسه نمونه اجرا: یک درخواست واقعی که با نسخه معین آغاز شده است.
این تفکیک پایه پاسخ‌گویی است. وقتی نتیجه غیرمنتظره‌ای رخ می‌دهد، تیم باید بتواند ورودی، نسخه قانون، مسیر طی‌شده و خروجی را کنار هم ببیند.
چه تغییرهایی می‌توانند فرایند در حال اجرا را بشکنند؟
همه ویرایش‌ها هم‌ارز نیستند. اصلاح توضیح یک فیلد معمولاً رفتار را تغییر نمی‌دهد، اما تغییرهای زیر باید به‌عنوان تغییر سازگاری بررسی شوند:
- افزودن، حذف یا جابه‌جایی یک مرحله؛
- تغییر شرط شاخه‌بندی یا حد عددی تصمیم؛
- تغییر نام، نوع یا الزام یک ورودی و خروجی؛
- تغییر نقش مسئول یا سطح دسترسی مرحله؛
- حذف فعالیتی که نمونه‌های قدیمی هنوز به آن می‌رسند؛
- تغییر زمان انتظار، سیاست تکرار یا رفتار در خطا؛
- جایگزینی سرویس بیرونی، مدل هوش مصنوعی یا قالب پیام؛
- تغییر معنای یک وضعیت، بدون تبدیل داده‌های قبلی.
مستند رسمی نسخه‌بندی Durable Functions مایکروسافت نیز هشدار می‌دهد که تغییر ترتیب فراخوانی فعالیت‌ها، تایمرها یا رویدادها و تغییر امضای فعالیت می‌تواند برای اجراهای فعال ناسازگار باشد. این نمونه فنی است، اما اصل آن برای موتورهای گردش کار و اتوماسیون سفارشی هم کاربرد دارد: منطق فعال را نباید بدون برنامه سازگاری جایگزین کرد.
مدل پایه: نسخه قدیم را برای اجراهای قدیمی زنده نگه دارید
ساده‌ترین سیاست قابل اتکا این است: از لحظه انتشار، نمونه‌های جدید به نسخه تازه متصل شوند و نمونه‌های قبلی با نسخه قبلی ادامه دهند. موتور اجرا هنگام هر گام باید نسخه ذخیره‌شده روی نمونه را بخواند، نه صرفاً «آخرین قانون فعال» را.
این رویکرد اجرای هم‌زمان نسخه‌ها را ضروری می‌کند. لازم نیست هر نسخه برای همیشه باقی بماند؛ باید تا زمانی نگه داشته شود که نمونه فعال، امکان بازپخش یا الزام ممیزی به آن وابسته است. بعد از پایان دوره نگهداری، نسخه می‌تواند بایگانی شود، اما تعریف آن نباید طوری حذف شود که تاریخچه اجرا غیرقابل تفسیر شود.
اگر سامانه فقط یک فیلد `is_active` دارد و با فعال‌کردن نسخه جدید قبلی را بازنویسی می‌کند، هنوز نسخه‌بندی واقعی ندارد. حداقل باید شناسه تغییرناپذیر نسخه، وضعیت انتشار، زمان اثر، نویسنده/تأییدکننده و رابطه هر نمونه اجرا با نسخه ذخیره شود.
چه زمانی باید نمونه‌های در حال اجرا مهاجرت کنند؟
ادامه نسخه قدیم همیشه ممکن نیست. ممکن است قانون قبلی از نظر حقوقی یا امنیتی نامعتبر شده باشد، سرویس وابسته خاموش شود یا خطایی در نسخه قبلی نتیجه اشتباه تولید کند. در این شرایط مهاجرت باید یک عملیات مستقل باشد، نه اثر جانبی انتشار.
پیش از مهاجرت چهار سؤال را پاسخ دهید:
1. کدام وضعیت‌های جاری با نسخه جدید سازگارند؟ 2. داده‌های قدیمی چگونه به ساختار جدید تبدیل می‌شوند؟ 3. اگر مهاجرت نیمه‌کاره ماند، مسیر بازگشت چیست؟ 4. مسئول تأیید نتیجه و پاسخ‌گویی به کاربران چه کسی است؟
مهاجرت دسته‌ای را با یک مجموعه کوچک و نماینده شروع کنید. نتیجه هر نمونه باید قبل و بعد ثبت شود. نمونه‌ای که در یک مرحله حساس منتظر پاسخ کاربر یا سرویس بیرونی است ممکن است به سیاست جداگانه نیاز داشته باشد. گاهی بهترین تصمیم این است که فقط نمونه‌های یک وضعیت مشخص مهاجرت شوند و بقیه روی نسخه قدیم پایان یابند.
چرخه عمر پیشنهادی برای هر نسخه
پیش‌نویس
تغییر هنوز قابل اجرا نیست. مالک فرایند می‌تواند شرط‌ها را مرور کند، داده آزمایشی بسازد و تفاوت با نسخه فعال را ببیند. پیش‌نویس نباید نمونه واقعی دریافت کند.
آماده آزمایش
نسخه در محیط یا مسیر کنترل‌شده اجرا می‌شود. سناریوهای عادی، مرزی، خطا و قطع سرویس وابسته آزموده می‌شوند. ورودی و خروجی هر آزمون باید قابل تکرار باشد.
انتشار محدود
بخشی از درخواست‌های جدید، یک شعبه یا یک گروه کاربر نسخه تازه را دریافت می‌کند. این مرحله برای سنجش رفتار واقعی است، نه دورزدن معیار پذیرش. نرخ خطا، زمان چرخه، مداخله انسانی و برگشت به روش دستی پایش می‌شود.
فعال عمومی
نسخه پیش‌فرض برای نمونه‌های جدید است. نسخه قبلی هنوز اجراهای فعال خود را تکمیل می‌کند. داشبورد باید حجم نمونه‌های هر نسخه و وضعیت آن‌ها را جدا نشان دهد.
بازنشسته
نمونه جدید نمی‌گیرد. فقط برای تکمیل اجراهای قبلی، بازپخش یا ممیزی در دسترس است. حذف نهایی باید بعد از پایان نمونه‌های فعال و دوره نگهداری انجام شود.
معیار پذیرش نسخه جدید را قبل از انتشار بنویسید
عبارت «قانون اصلاح شد» قابل آزمون نیست. معیار پذیرش باید به ورودی، مسیر و نتیجه متصل باشد. برای مثال:
- درخواست زیر سقف مشخص بدون تأیید مدیر ارشد عبور کند؛
- درخواست بالای سقف به نقش درست ارجاع شود؛
- نبود داده اجباری به جای تصمیم حدسی، توقف قابل توضیح ایجاد کند؛
- قطع سرویس مالی باعث تکرار کنترل‌شده شود و درخواست دوبار ثبت نشود؛
- نمونه شروع‌شده با نسخه قبلی بعد از انتشار نسخه جدید همان مسیر قبلی را کامل کند؛
- لغو نسخه جدید، ورودی‌های تازه را به آخرین نسخه امن هدایت کند.
برای طراحی اصل جریان، راهنمای اتوماسیون گردش تأیید را ببینید. نسخه‌بندی جای طراحی درست نقش‌ها، مهلت‌ها و مسیرهای استثنا را نمی‌گیرد؛ آن طراحی را قابل تغییر و قابل نگهداری می‌کند.
انتشار امن: سایه، محدود و مرحله‌ای
پیش از آنکه نسخه جدید تصمیم واقعی بگیرد، می‌توان آن را در حالت سایه روی کپی ورودی‌های واقعی اجرا کرد. خروجی سایه اثر عملیاتی ندارد، اما اختلاف تصمیم نسخه قدیم و جدید را آشکار می‌کند. این روش برای قانون‌های طبقه‌بندی، اولویت‌بندی یا ارجاع مفید است.
بعد از تحلیل اختلاف‌ها، انتشار محدود انجام دهید. معیار توقف از قبل تعیین شود: افزایش خطای بحرانی، رشد زمان چرخه، افزایش ارجاع دستی یا ناسازگاری داده می‌تواند انتشار را متوقف کند. درصد ترافیک به‌تنهایی معیار موفقیت نیست؛ کیفیت نتیجه و امکان بازیابی مهم‌تر است.
اگر نسخه تازه به هوش مصنوعی وابسته است، خروجی مدل را با نسخه prompt، مدل، منبع دانش و آستانه اطمینان ثبت کنید. تغییر هرکدام می‌تواند رفتار قانون را عوض کند، حتی اگر نمودار فرایند ثابت باشد. برای درخواست‌هایی که باید به صف مناسب بروند، راهنمای مسیریابی هوشمند درخواست‌ها مرز بین طبقه‌بندی و منطق ادامه فرایند را توضیح می‌دهد.
Rollback واقعی چیست؟
Rollback فقط بازگرداندن فایل برنامه نیست. پس از انتشار ممکن است نمونه‌های جدید با ساختار داده یا وضعیت تازه ساخته شده باشند. باید مشخص کنید:
- آیا نسخه قبلی ورودی‌های جدید را می‌فهمد؟
- نمونه‌هایی که با نسخه جدید آغاز شده‌اند روی همان نسخه می‌مانند یا متوقف می‌شوند؟
- تغییر پایگاه داده برگشت‌پذیر است یا باید با روش expand-and-contract انجام شود؟
- پیام یا پرداختی که ارسال شده چگونه از تکرار محافظت می‌شود؟
- چه کسی و بر اساس کدام شاخص فرمان بازگشت می‌دهد؟
راه امن معمولاً این است که مسیر دریافت نمونه‌های جدید به نسخه پایدار برگردد، اما نمونه‌های شروع‌شده با نسخه جدید کورکورانه به عقب منتقل نشوند. سپس برای هر وضعیت تصمیم مهاجرت یا تکمیل گرفته شود. کلیدهای idempotency و شناسه عملیات از دوباره‌کاری پیام، پرداخت یا ثبت سند جلوگیری می‌کنند.
مدیریت استثنا و تصمیم انسانی
نسخه جدید ممکن است حالتی را ببیند که در سناریوهای آزمایشی نبود. در این وضعیت، خروجی ساختگی یا انتخاب پیش‌فرض خطرناک است. قانون باید بتواند با دلیل روشن به صف بررسی انسانی برود و بعد از تصمیم، ادامه مسیر را از همان نقطه پیگیری کند.
این صف نباید به محل دائمی تخلیه خطا تبدیل شود. نوع استثنا، نسخه قانون، داده ناقص، تصمیم انسانی و زمان رسیدگی را اندازه بگیرید. استثناهای پرتکرار ورودی نسخه بعدی‌اند. الگوی انسان در حلقه اتوماسیون برای تعریف مرز تصمیم خودکار و مسئولیت بازبین کاربردی است.
مشاهده‌پذیری و ممیزی بین نسخه‌ها
داشبورد عملیاتی باید حداقل این شاخص‌ها را به تفکیک نسخه نشان دهد:
- تعداد نمونه آغازشده، فعال، کامل، خطادار و متوقف؛
- زمان چرخه و زمان انتظار در هر مرحله؛
- تعداد تکرار، timeout و فراخوانی ناموفق سرویس بیرونی؛
- نرخ ارجاع به انسان و دلیل آن؛
- اختلاف نتیجه نسخه سایه و نسخه فعال؛
- تعداد نمونه مهاجرت‌شده و نتیجه مهاجرت؛
- مصرف هزینه‌ای سرویس‌ها یا مدل‌های هوش مصنوعی.
گزارش تجمیعی بدون تفکیک نسخه می‌تواند مشکل را پنهان کند. اگر زمان چرخه بعد از انتشار بالا رفت، باید بتوان فهمید مشکل در نسخه جدید است، در ترکیب ورودی‌ها یا در سرویس وابسته. رخدادها بهتر است شناسه نمونه، نسخه، مرحله، correlation ID و نتیجه را داشته باشند؛ اما داده حساس نباید بی‌دلیل در log ذخیره شود.
اشتباه‌های رایج
ویرایش مستقیم نسخه فعال
این کار بازتولید نتیجه گذشته را ناممکن می‌کند. نسخه منتشرشده باید تغییرناپذیر باشد؛ اصلاح آن یک نسخه تازه می‌سازد.
مهاجرت همه نمونه‌ها در لحظه انتشار
نمونه‌ها در وضعیت‌های متفاوت‌اند و یک تبدیل عمومی معمولاً همه آن‌ها را پوشش نمی‌دهد. ابتدا سازگاری را بر اساس وضعیت طبقه‌بندی کنید.
نگهداری نسخه بدون مالک
اگر کسی مسئول پایان نسخه قدیمی نباشد، کد و داده قدیمی برای همیشه رشد می‌کند. مالک بازنشستگی و تاریخ مرور تعیین کنید.
سنجش فقط خطای فنی
نسخه ممکن است بدون exception اجرا شود اما تصمیم تجاری نادرست بگیرد. نمونه‌های طلایی، مقایسه نتیجه و بازبینی کسب‌وکار لازم‌اند.
حذف امکان توضیح تصمیم
ذخیره صرف خروجی کافی نیست. ورودی مؤثر، قواعد اعمال‌شده و دلیل عبور از شاخه باید در حد مناسب قابل مشاهده باشد.
چک‌لیست پیش از انتشار
- نسخه منتشرشده تغییرناپذیر و شناسه آن روی هر نمونه ذخیره می‌شود.
- تغییر سازگار و ناسازگار طبقه‌بندی شده است.
- تکلیف نمونه‌های فعال برای هر وضعیت مشخص است.
- تبدیل داده و بازگشت آن آزموده شده است.
- سناریوهای عادی، مرزی، خطا و قطع وابستگی اجرا شده‌اند.
- نسخه جدید ابتدا در سایه یا دامنه محدود بررسی می‌شود.
- معیار توقف و مسئول rollback تعیین شده است.
- داشبورد نتیجه را به تفکیک نسخه نشان می‌دهد.
- نسخه قدیم تا پایان اجراهای وابسته قابل دسترس می‌ماند.
- تاریخ بازنشستگی و مالک پاک‌سازی ثبت شده است.
جمع‌بندی
نسخه‌بندی قوانین اتوماسیون، تغییر را از یک ویرایش پرریسک به یک انتشار قابل کنترل تبدیل می‌کند. اصل کلیدی این است که «تعریف جریان» با «نمونه در حال اجرا» یکی نیست. نمونه باید بداند با کدام نسخه آغاز شده و تغییر مسیر آن باید تصمیمی صریح، آزموده و قابل بازگشت باشد.
از یک مدل ساده شروع کنید: نسخه تغییرناپذیر، اتصال نمونه به نسخه، اجرای هم‌زمان قدیم و جدید، انتشار محدود و داشبورد تفکیک‌شده. سپس برای تغییرهای اجباری، مسیر مهاجرت مرحله‌ای و کنترل استثنا بسازید. این ساختار باعث می‌شود اتوماسیون با رشد کسب‌وکار قابل تکامل بماند، بدون اینکه هر انتشار کارهای نیمه‌تمام را به خطر بیندازد.
برای طراحی یا بازطراحی یک جریان قابل نسخه‌بندی، با تیم خدمات هوش مصنوعی و اتوماسیون ایزی‌ساز گفتگو کنید یا از صفحه تماس ایزی‌ساز جلسه بررسی اولیه بخواهید.