اُکالا قطع نیست! روایت یک چالش پنهان در عملیات فروشگاهی

اُکالا به‌ عنوان یکی از بازیگران اصلی خرده‌فروشی آنلاین در ایران، هر روز با شبکه‌ای گسترده از فروشگاه‌ها، تأمین‌کنندگان و مسیرهای لجستیکی در ارتباط است. مقیاس این ارتباطات باعث می‌شود بخش بزرگی از کیفیت تجربه‌ی مشتری، نه فقط به محصول و قیمت، بلکه به پایداری زیرساخت‌ها و کارآمدی عملیات فروشگاهی وابسته باشد. در چنین فضایی، بسیاری از چالش‌ها نه در دیتاسنتر و سرویس‌های مرکزی، بلکه در دل فروشگاه‌ها اتفاق می‌افتند؛ جایی که دیده‌نشدن یک اختلال کوچک می‌تواند به یک مسئله‌ی بزرگ عملیاتی تبدیل شود. این مقاله روایت یکی از همین تجربه‌هاست؛ تجربه‌ای که دیدگاه ما را نسبت به «رصد عملیات فروشگاهی» تغییر داد.

مدت‌ها در عملیات فروشگاه‌های زنجیره‌ای با یک جملهٔ تکراری روبه‌رو بودیم:

«اُکالا قطع است!»

پشت این جمله همیشه یک سؤال بزرگ پنهان بود؛ اینکه دقیقاً چه چیزی قطع است؟ 

اینترنت؟ DNS اختلال دارد؟ یا شاید فقط یک کابل LAN که کسی حواسش به آن نبوده کنده شده است؟ 

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

در چنین شرایطی تیم پشتیبانی مجبور بود برای کوچک‌ترین مسئله، حضوری مراجعه کند؛ کاری که زمان‌بر بود و هزینه‌های اضافی ایجاد می‌کرد. همین خلأ، ما را به سمت ساخت یک ابزار سبک، مستقل و قابل‌اعتماد برد؛ ابزاری که مستقیم از دل فروشگاه برای ما حرف بزند و نه از روی حدس و گمان. نتیجه‌ی‌ این نیاز و تجربه‌ی‌ عملیاتی، چیزی شد که بعدها «Okala Heartbeat» نام گرفت.

چالش اصلی در ابتدای راه خیلی ساده و شفاف بود: هیچ‌ گونه Visibility واقعی نسبت به وضعیت لحظه‌ای شبکهٔ فروشگاه‌ها نداشتیم. هر بار که فروشگاهی اعلام می‌کرد «اُکالا قطع شده»، ما با دنیایی از احتمال‌ها روبه‌رو می‌شدیم:

• از این‌که شاید اینترنت فروشگاه به‌طور کامل قطع شده باشد تا اینکه DNS resolve نمی‌شود.

• شبکه داخلی دچار مشکل شده است.

• برنامه‌ی‌ ارسال موجودی اجرا نمی‌شود.

• سیستم روی Wi-Fi است و ناپایدار شده است.

• کارت شبکه Down است.

• حتی یک کابل LAN قطع شده و روی زمین رها شده است.

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

یکی از مهم‌ترین محدودیت‌ها، اجرا شدن این ابزار روی انواع سیستم‌های قدیمی فروشگاهی بود. از ویندوز ۷ و XP گرفته تا دستگاه‌های ۳۲ بیتی و ترمینال‌های کم‌قدرت، بسیاری از آن‌ها حتی امکان نصب NET Runtime. جدید را نداشتند. بنابراین تصمیم مهمی گرفته شد: استفاده از AOT و Single-File Publish در NET.

با AOT، کد قبل از اجرا کامپایل می‌شود و Single-File همه‌چیز را در یک فایل واحد قرار می‌دهد. نتیجه یک فایل اجرایی شد که بدون هیچ نصبی اجرا می‌شود، وابسته به هیچ Runtime دیگری نیست، روی تمام نسخه‌های ویندوز کار می‌کند، سریع بالا می‌آید و مصرف حافظه‌اش به‌شدت پایین است. دستور build هم ساده بود:

dotnet publish -c Release -r win-x86 -p:PublishAot=true -p:PublishSingleFile=true

در فروشگاه‌ها این تنها فایلی بود که باید کپی می‌شد و همین اقدام ساده باعث شد Heartbeat در محیط‌هایی با منابع محدود نیز پایدار عمل کند.

برای اینکه این ابزار بتواند اطلاعات دقیق و عملیاتی از فروشگاه‌ها دریافت کند، تصمیم گرفتیم به حداقل Dependency ممکن تکیه کنیم. بنابراین هیچ ابزار اضافی نصب نشد و از قابلیت‌های داخلی ویندوز استفاده کردیم. Heartbeat دستورات CLI سیستم را مستقیماً اجرا می‌کند؛ دستوراتی مثل ipconfig، nslookup، netsh، route و tasklist. خروجی این دستورات همان لحظه خوانده و parse می‌شود. استفاده از ProcessStartInfo امکان اجرای این دستورات را بدون ایجاد پنجره یا وقفه فراهم می‌کند. نمونه‌ای کوتاه از اجرای یک دستور مثل nslookup در #C این‌گونه است:

using System.Diagnostics;
var process = new Process() 
{
     StartInfo = new ProcessStartInfo()     
     {
         FileName = "nslookup",
         Arguments = "okala.com",
         RedirectStandardOutput = true,
         UseShellExecute = false,
         CreateNoWindow = true
     } 
};

process.Start();

var output = process.StandardOutput.ReadToEnd();
process.WaitForExit();

این رویکرد به ما دو مزیت اساسی داد:

• اول آنکه هیچ Dependency اضافه‌ای لازم نبود و ابزار روی هر سیستم ویندوزی اجرا می‌شد.

• دوم اینکه می‌توانستیم دقیقاً همان اطلاعاتی را دریافت کنیم که خود سیستم به شکل native ارائه می‌دهد؛ یعنی وضعیت واقعی داخل ترمینال.

Heartbeat در اولین اجرا، خودش را به‌صورت کاملاً خودکار در ویندوز Register می‌کند تا همیشه در پس‌زمینه فعال باشد. بدون نیاز به installer یا ابزار جانبی، خودش را به Windows Service تبدیل می‌کند. در نخستین اجرا، ماژول Heartbeat یک دستور ساده با ساختار زیر اجرا می‌کند:

New-Service -Name "OkalaHeartBeat" -BinaryPathName "C:\Okala\heartbeat.exe" -StartupType Automatic Start-Service "OkalaHeartBeat

به این ترتیب سرویس همیشه بعد از boot فعال است و نیازی نیست کسی دستی آن را اجرا کند. برای محیط فروشگاهی که معمولاً کاربر نهایی دانش فنی بالایی ندارد، این رفتار پایدار و پیش‌بینی‌پذیر، کاملاً ضروری بود.

Heartbeat برای اینکه وضعیت واقعی شبکه را درست تحلیل کند فقط یک مقصد را تست نمی‌کند؛ بلکه هم‌زمان به چهار نقطه‌ی‌ مجزا در شبکه متصل می‌شود. این نقاط شامل:

• شبکه داخلی فروشگاه

• اینترانت ملی

• گیت‌وی اُکالا

• تست شبکه بین المللی اینترنت با سرور خارج از کشور

ترکیب این چهار نقطه، تصویری کامل از وضعیت شبکه ارائه می‌دهد. اگر اینترنت بین‌الملل قطع باشد، اگر DNS resolve نشود، اگر فقط شبکه داخلی مشکل داشته باشد یا اگر Wi-Fi ناپایدار باشد، Heartbeat تفاوت این سناریوها را تشخیص می‌دهد.

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

یکی از اولین کشف‌های Heartbeat شناسایی یک قطعی ۱۵ دقیقه‌ای وسط روز بود؛ قطعی‌ که تا آن روز هیچ‌وقت متوجه آن نشده بودیم. فروشگاه روی Wi-Fi بود و اتصال ناپایدار باعث قطع ارسال موجودی شده بود. Heartbeat این وضعیت را ثبت کرده و بعد از وصل شدن شبکه، گزارش کامل آن را ارسال کرد. پس از بررسی، فروشگاه موظف شد به‌جای Wi-Fi از کابل LAN استفاده کند و این مشکل برای همیشه برطرف شد. این تنها یک نمونه از ده‌ها قطعی پنهانی بود که هیچ‌وقت دیده نمی‌شد اما امروز کاملاً شفاف شده است.

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

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

• نیاز به پشتیبانی حضوری را به‌طور قابل‌توجهی کاهش دهد.

• زمان شناسایی و رفع اختلال‌ها را کوتاه‌تر کند.

• هزینه‌های عملیاتی را پایین بیاورد.

در نتیجه، هم فروشگاه‌ها تجربه‌ی پایدارتر و قابل‌اعتماد‌تری داشتند و هم مشتریان با کاهش تأخیر در ارسال سفارش‌ها و کاهش موارد «کنسلی سفارش به علت عدم موجودی» رضایت بیشتری تجربه کردند. از سوی دیگر، فشار روی تیم کال‌سنتر کاهش پیدا کرد، شاخص‌های رضایت مشتری از جمله NPS برای فروشگاه‌های پایلوت بهبود یافت و برای اولین‌بار دیدی شفاف و مستمر نسبت به وضعیت واقعی شبکه‌ی فروشگاه‌ها به‌دست آمد. مهم‌تر از همه، نقطه‌های کور از عملیات فروشگاهی حذف شدند و امکان واکنش آگاهانه و به‌موقع در برابر اختلال‌ها فراهم شد.

تجربه‌ی Okala Heartbeat به ما نشان داد که بسیاری از مسائل پیچیده‌ی عملیاتی، نه با ابزارهای سنگین، بلکه با مشاهده‌ دقیق و داده‌ی قابل اعتماد حل می‌شوند. این پروژه، الگویی شد برای نگاه دوباره به نقاط کوری که ممکن است در زنجیره‌ی عملیات وجود داشته باشد.

نویسنده مقاله: بهنام محمدی