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