چند بار درخواست مشتری در سیستم شما نادیده گرفته شده؟ در یک صرافی ارز دیجیتال با حجم فعالیت بالا، همین سؤال ساده نقطه شروع یکی از مهمترین پروژههای اتوماسیونی بود که طراحی کردم. از بیش از ۲۸ ورکفلویی که برای این کسبوکار ساختم، یکی از آنها مستقیماً روی جایی اثر گذاشت که خطای انسانی بیشترین آسیب را به اعتماد کاربر میزند: بررسی درخواستهای واریز، برداشت و احراز هویت.
مشکل؛ درخواستهایی که از چشم اپراتور دور میماندند
در صرافیهای دیجیتال، یک اپراتور باید هر درخواست واریز، برداشت یا احراز هویت را بررسی و تعیینتکلیف کند. این فرآیند در ظاهر ساده است، اما وقتی حجم تراکنشها بالا میرود، مشکل واقعی خودش را نشان میدهد.
در این پروژه، سایت صرافی تمام این درخواستها را روی پنل مدیریتی خودش ثبت میکرد. اپراتور باید بهصورت مداوم پنل را چک میکرد تا ببیند به کدام درخواست هنوز پاسخ نداده است. مشکل از همینجا شروع میشد؛ در ساعتهای پرترافیک، درخواستهای زیادی همزمان وارد صف میشدند و برخی از آنها، به دلیل حجم بالای کار یا فاصله زمانی بین چککردنهای اپراتور، بدون بررسی باقی میماندند.
نتیجه این وضعیت چه بود؟ کاربری که منتظر تأیید برداشت یا احراز هویت خودش بود، هیچ اطلاعی از وضعیت درخواستش نداشت. این تأخیر، مخصوصاً در حوزه فینتک و ارز دیجیتال که سرعت و اعتماد اهمیت بالایی دارند، مستقیماً به نارضایتی کاربر و افت اعتبار پلتفرم منجر میشد.
چرا راهحلهای ساده کافی نبودند
آیا افزایش تعداد اپراتورها میتوانست این مشکل را حل کند؟ در عمل، نه بهطور کامل. حتی با افزایش نیرو، مشکل اصلی همچنان پابرجا بود: هیچ سیستمی وجود نداشت که بهصورت فعال درخواستهای بدونپاسخ را شناسایی و اطلاعرسانی کند. اپراتور همچنان باید حدس میزد کدام درخواست را بررسی نکرد، و این یعنی وابستگی کامل به دقت و حافظه یک انسان در میانه حجم بالای کار.
مسئله واقعی، پس، فقط «بررسینکردن درخواستها» نبود؛ نبود یک لایه نظارتی خودکار بود که بدون دخالت مستقیم انسان، فاصله بین ثبت درخواست و پاسخ به آن را کنترل کند.
راهکار؛ طراحی یک لایه نظارتی خودکار باn8n
برای حل این مسئله، یک ورکفلوی نظارتی در n8n طراحی کردم که بهطور مستمر وضعیت درخواستها را از طریق API صرافی بررسی میکند. منطق کلی این ورکفلو ساده اما دقیق بود: اپراتور باید هر درخواست واریز، برداشت یا احراز هویتی را که سیستم ثبت میکرد، در یک بازه زمانی مشخص تعیینتکلیف میکرد؛ اگر این اتفاق نمیافتاد، سیستم باید خودش او را باخبر میکرد.
این ورکفلو سه مرحله اصلی داشت:
- دریافت دورهای دیتای درخواستها از API صرافی، شامل واریز، برداشت و احراز هویت.
- بررسی وضعیت هر درخواست و تشخیص اینکه آیا اپراتور بهموقع به آن پاسخ داده یا نه.
- ارسال هشدار برای درخواستهایی که همچنان بدون تعیینتکلیف میمانند.
نکتهای که ترجیح میدهم از همین ابتدا شفاف بگویم: هدف این ورکفلو جایگزینکردن اپراتور نبود، بلکه حذف نقطه کوری بود که حجم بالای کار بهطور طبیعی پدید میآورد. تصمیم فنی کلیدی این بود که سیستم نباید فقط داده نمایش بدهد؛ باید در لحظهای که مشکلی پیش میآید، اطلاعرسانی کند.
چالش نوتیفیکیشن؛ جایی که راهکار اول جواب نداد
طبیعی است که بپرسید: چرا برای هشدار از تلگرام یا پوشنوتیفیکیشن معمولی استفاده نکردم؟ در عمل، همین سؤال یکی از مهمترین چالشهای پروژه بود.
در نسخه اولیه، قرار بود هشدارها را از طریق تلگرام یا پوشنوتیفیکیشن استاندارد ارسال کنم. اما در ایران، قطعی یا محدودیت دسترسی به اینترنت بینالملل یک واقعیت زیرساختی است، نه یک استثنا. اگر در لحظهای که یک درخواست حساس بدونپاسخ مانده، دسترسی به اینترنت بینالملل قطع باشد، کل زنجیره هشدار عملاً از کار میافتد؛ درست همان لحظهای که بیشترین نیاز به آن وجود دارد.
این محدودیت را اینطور حل کردم: سیستم هشدار را روی پیامرسان بله پیادهسازی کردم. بله، به دلیل زیرساخت داخلی، از طریق اینترنت ملی هم در دسترس است و به اتصال بینالملل وابسته نیست. این یک تصمیم فنی کوچک بهنظر میرسد، اما دقیقاً همان جایی است که تفاوت بین یک ورکفلوی نمایشی و یک ورکفلوی قابلاعتماد در عمل خودش را نشان میدهد.
تجربه عملی؛ از طراحی منطق تا اجرای واقعی روی داده زنده
اجرای این ورکفلو روی داده واقعی صرافی، چند نکته را روشن کرد که در طراحی تئوریک قابل پیشبینی نبودند.
اولین نکته، حجم و تنوع درخواستها بود. واریز، برداشت و احراز هویت هرکدام منطق بررسی متفاوتی داشتند؛ زمان انتظار مجاز برای یک درخواست احراز هویت با زمان انتظار مجاز برای یک درخواست برداشت یکسان نبود. به همین دلیل، ورکفلو بهجای یک منطق واحد، برای هر نوع درخواست یک مسیر بررسی جداگانه در نظر گرفت که در نهایت به یک نقطه مشترک برای ارسال هشدار میرسید.
نکته دوم، جلوگیری از هشدارهای تکراری بود. اگر سیستم هر بار که چک میکرد یک درخواست همچنان بدونپاسخ است دوباره هشدار میفرستاد، اپراتور بهسرعت نسبت به این هشدارها بیتفاوت میشد. برای همین، منطق ورکفلو را طوری تنظیم کردم که هر درخواست فقط یکبار هشدار اولیه دریافت کند، مگر آنکه پس از مدت مشخصی همچنان بدونپاسخ باقی بماند.
آیا این یعنی ورکفلو بدون هیچ محدودیتی کار میکند؟ خیر. وابستگی این سیستم به پایداری و ساختار API صرافی جدی است؛ اگر ساختار پاسخ API تغییر کند یا دادهها با تأخیر برگردند، باید منطق بررسی را دوباره بازبینی کنم. این محدودیت را از ابتدا با مانیتورینگ دورهای روی خود ورکفلو مدیریت کردم، نه با نادیدهگرفتنش.
برای نمونه، در یکی از هفتههای اجرای اولیه، تعداد درخواستهای احراز هویت بهطور ناگهانی افزایش پیدا کرد. همین افزایش، ورکفلو را در معرض آزمایش واقعی قرار داد؛ سیستم بدون نیاز به تغییر دستی، حجم بیشتر را پوشش داد و هشدارهای مربوطه را بدون تأخیر محسوس ارسال کرد. همانجا بهترین اثبات این بود که طراحی اولیه درست پیش رفت.
نتیجه؛ از درخواستهای بیپاسخ تا نظارت پیوسته
نتیجه اجرای این ورکفلو را میتوان در دو سطح توضیح داد: سطح عملیاتی و سطح تجربه کاربر.
در سطح عملیاتی، دیگر هیچ درخواست واریز، برداشت یا احراز هویتی بدون تعیینتکلیف باقی نمیماند. اپراتور بهجای چککردن مداوم و دستی پنل هر پانزده دقیقه، منتظر میماند تا در صورت وجود درخواست بدونپاسخ، خود سیستم به او اطلاع بدهد. طبق برآورد تیم، همین تغییر توانست تا حدود نود درصد در زمانی که اپراتور صرف بررسی مداوم درخواستها میکرد صرفهجویی کند.
در سطح تجربه کاربر، نتیجه مستقیمتر بود: کاهش محسوس تأخیر در پاسخدهی به درخواستها، و بهتبع آن، کاهش نارضایتی کاربرانی که پیشتر منتظر پاسخی میماندند که گاهی دیر یا هرگز نمیرسید.
نکته مهمتر از عدد صرفهجویی، تغییر نوع کار اپراتور بود. اپراتور از حالت واکنشی و مداوم به حالت رویدادمحور رسید؛ فقط زمانی وارد عمل میشد که سیستم به او اطلاع میداد اتفاقی نیاز به بررسی دارد، نه اینکه دائم منتظر پیداکردن مشکل باشد.
جمعبندی عملی
اگر بخواهم این پروژه را در چند نکته عملی خلاصه کنم، اینها هستند:
- مشکل واقعی را از داده واقعی پیدا کنید، نه از فرض؛ در این پروژه، حجم بالای تراکنشها بود که نقطه کور را آشکار کرد.
- اتوماسیون هشدار را روی زیرساختی طراحی کنید که در بدترین شرایط هم کار کند؛ برای بازار ایران، این یعنی توجه به محدودیت دسترسی بینالملل از همان مرحله طراحی.
- جلوگیری از هشدار تکراری بهاندازه ارسال هشدار اهمیت دارد؛ سیستمی که بیشازحد هشدار بدهد، کاربران بهمرور آن را نادیده میگیرند.
- نتیجه یک ورکفلوی خوب همیشه فقط صرفهجویی در زمان نیست؛ تغییر نوع کار انسانی از واکنشی به نظارتی، ارزش بلندمدتتری دارد.
توصیه میکنم پیش از طراحی هر ورکفلوی نظارتی مشابه، ابتدا مسیر واقعی داده و محدودیتهای زیرساختی محیط اجرا را بررسی کنید؛ خیلی از خرابیهای این نوع سیستمها، نه از منطق طراحی، بلکه از نادیدهگرفتن همین محدودیتها میآید.
سوالات متداول
سوالات درباره منطق و طراحی ورکفلو
آیا این ورکفلو بهطور کامل جای اپراتور انسانی را میگیرد؟
خیر. این ورکفلو تصمیم نهایی درباره یک درخواست را نمیگیرد؛ فقط تضمین میکند که اپراتور هیچ درخواستی را از دست نمیدهد.
چرا برای هشدار از تلگرام استفاده نکردم؟
چون در صورت قطعی یا محدودیت اینترنت بینالملل، هشدار تلگرام ممکن است دقیقاً در لحظه بحرانی دیر برسد یا اصلاً نرسد.
چرا پیامرسان بله را برای این پروژه انتخاب کردم؟
چون از طریق اینترنت ملی هم قابلدسترسی است و این ویژگی وابستگی به پایداری اینترنت بینالملل را حذف میکند.
آیا این نوع ورکفلو فقط برای صرافیهای ارز دیجیتال کاربرد دارد؟
خیر. هر کسبوکاری که با درخواستهای حساس و وابسته به زمان سروکار دارد، از رزرو گرفته تا پشتیبانی مشتری، میتواند از همین منطق نظارتی استفاده کند.
آیا اجرای چنین ورکفلویی نیاز به زیرساخت پیچیده دارد؟
نه لزوماً. بخش اصلی این پروژه را با n8n و اتصال به API صرافی پیادهسازی کردم؛ پیچیدگی اصلی در طراحی منطق بود، نه در ابزار.
سوالات درباره اجرا، محدودیتها و کاربرد
چطور از ارسال هشدارهای تکراری و آزاردهنده جلوگیری کردم؟
با تعریف یک منطق زمانبندی که هر درخواست را فقط یکبار هشدار اولیه میدهد، مگر آنکه پس از مدت مشخصی همچنان بدونپاسخ بماند.
آیا این ورکفلو با تغییر ساختار API صرافی از کار میافتد؟
اگر ساختار پاسخ API بهطور اساسی تغییر کند، باید منطق بررسی را بازبینی کنم؛ به همین دلیل، مانیتورینگ دورهای روی خود ورکفلو را هم انجام میدهم.
این سیستم چه نوع درخواستهایی را بررسی میکرد؟
درخواستهای واریز، برداشت و احراز هویت، که هرکدام منطق زمانی و بررسی جداگانهای داشتند.
آیا این پروژه فقط یک هشداردهنده ساده بود یا چیزی بیشتر؟
بیشتر از یک هشداردهنده ساده بود؛ یک لایه نظارتی کامل بود که وضعیت درخواستها را بهطور مستمر با داده واقعی از API صرافی تطبیق میداد.
چرا این پروژه را نمونه اتوماسیون سازمانی میدانم، نه فقط یک اسکریپت ساده؟
چون منطق آن مبتنی بر تحلیل واقعی یک فرآیند سازمانی، مدیریت محدودیت زیرساختی محلی و جلوگیری از خطای انسانی در مقیاس بود، نه یک اتوماسیون تکمرحلهای.
[…] هستید، میتوانید تجربه عملی این نوع پروژهها را در کیس استادی اتوماسیون واقعی؛ ۲۸+ ورکفلو صرافی هم ببینید. پروژههای دیگرم را میتوانید در pouyaamery.ir […]