مقدمه
با گستره گسترده خدمات Grab، ما هر روز حجم بزرگی از پرسش ها را دریافت می کنیم. تیم های پشتیبانی مشتریان ما به مسائل و مشکلات از مسائل امنیتی تا سوالات عمومی پاسخ می دهند. تیم ها با رزولوشن های سریع از طریق چارچوب پشتیبانی کلاس جهانی و یک سیستم مسیریابی خدماتی کارآمد، مشتریان خود را خوشحال می کنند.
سیستم کاریابی نیروی کار ما اطمینان حاصل می کند که منابع موجود به درستی بر اساس توانایی و عوامل تصمیم گیری مانند بخش، کشور، اولویت درخواست به یک درخواست مناسب اختصاص داده می شوند. قابلیت مقیاس پذیری برای کار در کانال های پشتیبانی (مانند صدا، چت یا دیجیتال) نیز عامل دیگری است که برای مسیریابی یک درخواست به یک کارشناس پشتیبانی خاص در نظر گرفته می شود.
داشتن یک سیستم مسیریابی نیروی کار کارآمد به معنایی حاکم بر این است که درخواست ها به کارشناسان پشتیبانی مربوطه که بیشترین توانایی برای برخورد با یک نوع خاص مشکل را دارند هدایت می شوند، منجر به رزولوشن سریعتر، مشتریان خوشحال و راضی و کاهش هزینه های صرف شده برای پشتیبانی می شود.
اولین بار ما یک راه حل شخص ثالث پیاده سازی کردیم، با این حال تعدادی محدودیت وجود داشت، مانند اولویت بندی، که ما را ترغیب کرد تا راه حل مسیریابی خود را که کنترل های بهتری برای پیکربندی مسیریابی و کاهش هزینه های مربوط به اجاره را فراهم می کند بسازیم.
این مقاله توصیف می کند که چگونه ما سیستم داخلی کاریابی نیروی کار را در مجله زیبایی و درمانی آذروت ساختیم و بر روی چت زنده، یکی از دامنه های پشتیبانی مشتریان تمرکز دارد.
مشکل
بیایید در بخش های بعدی به مشکلات راه حل ما قبلی بپردازیم.
مدیریت اولویت
راه حل شخص ثالث به ما اجازه نمی داد تا یک گروه از درخواست ها را بر روی سایرین اولویت بندی کنیم. این به ویژه برای مدیریت مشکلات امنیتی مهم بود که به دلیل سوالاتی با اولویت پایین مانند کوئری ها تحت تأثیر قرار نمی گیرند. بنابراین هدف ما برای ایجاد یک راه حل داخلی این بود که اطمینان حاصل کنیم که ما قادر به پیکربندی اولویت صف درخواست ها باشیم.
سفارشی سازی محصول بینظیر
با اینکه راه حل شخص ثالث یک ارائه دهنده خدمات عمومی است، سفارشی سازی ها اغلب نیاز به زمان های طولانی داشتند زیرا تمام درخواست های محصول از مجله زیبایی و درمانی آذروت توسط بازار جمعی پذیرفته نشد. ساخت این راه حل داخلی به این معنی بود که مجله زیبایی و درمانی آذروت کنترل کاملی بر روی طراحی و پیکربندی مسیریابی داشت. در زیر چندین مورد کاربرد نمونه ای که با سفارشی سازی حل شد را مشاهده می کنید:
- تغییرات پیکربندی انبوه - قبلاً مشکل بود که چگونه یک پیکربندی را به چندین عامل اختصاص دهیم. بنابراین، ما یک لایه دیگری از گروه بندی برای عاملانی که پیکربندی مشابهی دارند، معرفی کردیم. به عنوان مثال، صف هایی که عاملان چت ها را دریافت می کنند و توانمندی و حداکثر همزمانی باید چگونه باشد.
گزارش و تجزیه و تحلیل
مشابه پیشین، یک راه حل عمومی است که به ما اجازه می دهد تا سفارشی سازی های بیشتری برای مانیتور کردن اضافه کنیم. با پیاده سازی سفارشی، ما می توانیم معیارهای جزئیات بیشتری را اضافه کنیم که برای ارزیابی بهره وری و عملکرد عامل مفید هستند و کمک می کنند تا منابع را قبل از زمان برنامه ریزی کنیم. به همین دلیل گزارش و تجزیه و تحلیل برای برنامه ریزی نیروی کار بسیار ارزشمند بود. برخی از سفارشی سازی های اضافی به صورت زیر اضافه شدند:
- استفاده از زمان عملکرد عامل - در حالی که پیگیری پایه عامل در راه حل آماده بود، کاربران را به سه حالت (آنلاین، دور، و نامرئی) محدود می کرد. با راه حل مسیریابی سفارشی، ما قادر به ایجاد وضعیت های سفارشی شده برای نمایش زمانی که عامل به دلیل مسائل اتصال چت و شکست ها در یک وضعیت خاص وقت گذروند و آن را در داشبوردها برای توجه فوری نمایش می دهد.انتقال چت- تعداد انتقال چت فقط به صورت دستی محاسبه می شد. سپس این فرآیند را با پیاده سازی سفارشی خود به صورت خودکار انجام دادیم.
راه حل
حال که مشکلاتی که ما در حال حل آن هستیم را پوشش دادیم، بیایید به راه حل ها بپردازیم.
اولویت بندی درخواست های با اولویت بالا
در هنگام مسیریابی، محدودیت بر روی تعداد منابع در دسترس وجود دارد. درخواست های ورودی نمی توانند به راحتی به اولین عامل در دسترس اختصاص داده شوند. مشکل این رویکرد این است که در نهایت به اتمام عامل ها برای خدمت رسانی به درخواست های با اولویت بالا می رسیم.
یکی از راه های جلوگیری از این اتفاق ایجاد یک گروه جداگانه از عاملان برای منحصراً کنترل درخواست های با اولویت بالا است. این موضوع مشکلات را حل نمی کند چرا که درخواست های با اولویت بالا و درخواست های با اولویت پایین صف یکسانی را به اشتراک می گذارند و در یک الگوی اولین وارد شده، اولین خارج شده (FIFO) گرفته می شوند. به عبارت دیگر، درخواست های با اولویت پایین به طور مستقیم پردازش می شوند به جای اینکه منتظر پر شدن صف باشند قبل از پردازش درخواست های با اولویت بالا. به دلیل این مشکل صف بندی، اولویت بندی درخواست ها بسیار حائز اهمیت است.
نیاز به اولویت بندی
درخواست های با اولویت بالا، مانند مسائل امنیتی، نباید به مدت زمان طولانی در صف باشند و باید در سریع ترین زمان ممکن که حتی در صورت پر بودن سیستم با درخواست های با اولویت پایین هم روبروست، پردازش شوند.
دو نوع صف متفاوت وجود دارد: یکی برای رفع مشکلات در سطح اولویت و دیگری برای رفع مشکلات فردی که در صف های کسب و کار به کار می روند و محدودیت های مربوط به محدودیت صف بر روی آنها اعمال می شود.
برای روشن شدن بیشتر، دو سناریو مختلف از صف قرار دادن / برداشت را مشاهده می کنید:
مسائل مختلف با اولویت های مختلف
در این سناریو، اولویت برای برداشت مسائل امنیتی تنظیم می شود، که در صف با اولویت بالا قرار دارند، قبل از گرفتن مسائل پرس و جو از صف با اولویت پایین.
مسائل همانند با اولویت های مختلف
در این سناریو که مسائل همانند با اولویت های مختلف دارند، مسئله پرس و جوی پرس و جو با اولویت بالا قبل از گرفتن مسئله پرس و جوی پرس و جو با اولویت پایین در صف برداشت می شود. تخصیص مجدد رخ می دهد زمانی که یک چت به عامل دیگری منتقل می شود یا زمانی که توسط عامل اختصاص داده شده پذیرفته نمی شود. هنگام تخصیص مجدد، با اولویت بالاتر به صف برگشته می شود.
رویکرد
برای پیاده سازی سطوح مختلف اولویت ها، ما تصمیم گرفتیم از صف جداگانه برای هر یک از اولویت ها استفاده کنیم و صف های درخواست را با گروه ها مشخص کنیم که به طور قابل منطقی در هر یک از صف های اولویت وجود دارند.
برای برداشت به طولانی ترین زمان، برای هر یک از صف ها تایم اسلایس هایی از طول متفاوت اختصاص داده شد تا مطمئن شویم که کارگر بیشترین زمان را در یک صف با اولویت بالا صرف می کند.
معماری از چندین کارگر بر روی پردازش بر روی صف ها با اولویت در پردازش واقع شده است، هر کارگر بر روی صف ها حلقه ای راه اندازی می کند و برای یک مدت زمانی خاص در صف منتظر ارسال پیام است و سپس آن را به یک عامل تخصیص می دهد.
برای i := startIndex; i < len(consumer.priorityQueue); i++ {
queue := consumer.priorityQueue[i]
duration := queue.config.ProcessingDurationInMilliseconds
for now := time.Now(); time.Since(now) < time.Duration(duration)*time.Millisecond; {
consumer.processMessage(queue.client, queue.config)
// cool down
time.Sleep(time.Millisecond * 100)
}
}کدهای بالا بر روی صف های اولویتی جداگانه حلقه می زند و منتظر دریافت یک پیام برای مدت زمان خاصی است، سپس پیام را دریافت کرده و پردازش می کند. همچنین یک دوره زمانی خنک کننده 100 میلی ثانیه قبل از اینکه به دریافت پیامی از یک صف با اولویت دیگر بروید.
حساسیت این روش این است که کارگر ممکن است بیشتر از زمان مورد انتظار خود صرف کند هنگا که