تصور کنید مهندسی هستید که باید قطعات یک پازل را در چهار اتاق مختلف پیدا کند تا بفهمد چرا سیستم از کار افتاده است. این همان وضعیتی بود که تیم عملیاتی NIIMBOT پیش از اتخاذ رویکرد جدید تجربه می‌کرد. تحلیل ریشه‌ای (Root Cause Analysis) برای خطاهای بین-دامنه (cross-domain) در این شرکت، به‌طور معمول ده‌ها دقیقه زمان می‌برد تا اینکه آن‌ها موتور STAROps از Alibaba Cloud را یکپارچه کردند.
به نقل از گزارش منتشر شده در ۴ سپتامبر ۲۰۲۶، این شرکت با جزئیات توضیح داد که چگونه ساخت ابزارهای نظارتی (Observability) داخلی خود را متوقف کرد تا یک بنیاد AIOps بومی ابر (cloud-native) را بپذیرد.
زمینه: معمای استراتژیک یک تیم بالغ
برای یک تیم از نظر فنی بالغ، چالش اصلی این نیست که «آیا می‌توانند» ابزاری را بسازند، بلکه این است که «آیا باید» آن را بسازند. شرکت NIIMBOT که در سال ۲۰۱۲ تأسیس شد، بیش از یک دهه را صرف پیشبرد سخت‌افزارهای چاپ برچسب هوشمند، پلتفرم‌های خدمات چاپ ابری و سیستم‌های مدیریت عملکرد سازمانی کرده است. محصولات آن‌ها اکنون به بیش از ۲۲ میلیون کاربر در سراسر جهان می‌رسد و حوزه‌هایی چون خرده‌فروشی، مخابرات، محیط‌های اداری، صنعت، بهداشت و درمان، آزمایشگاه‌ها و منازل را پوشش می‌دهد.
با گسترش سریع کسب‌وکار در مقیاس جهانی، پیچیدگی سیستم‌های آن‌ها به‌طور تصاعدی رشد کرد. NIIMBOT پیش از این یک حضور جهانی گسترده داشت و یک پشته (stack) جامع نظارتی را روی علی‌بابا کلاود ایجاد کرده بود. این مجموعه شامل موارد زیر بود:
- Real User Monitoring (RUM): برای جمع‌آوری داده‌های تجربه کاربر در بخش فرانت‌اند.
- Managed Service for Prometheus: برای نظارت بر متریک‌های کانتینر و منابع ابری.
- Application Real-Time Monitoring Service (ARMS): برای ردیابی عملکرد اپلیکیشن (Tracing).
- Simple Log Service (SLS): برای مدیریت و تحلیل لاگ‌ها.
- Grafana: (به صورت مدیریت‌شده توسط خود شرکت) برای ارائه داشبوردهای یکپارچه متصل به منابع فوق.
با وجود این مجموعه ابزارهای گسترده، تیم با یک سؤال بنیادی روبرو بود: آیا باید به ساخت بنیاد داده‌های نظارتی و «دوقلوی دیجیتال» عملیاتی خود ادامه دهند یا مجموعه‌ای از قابلیت‌های آماده را بپذیرند؟ آن‌ها متوجه شدند که اگرچه می‌توانند آن را بسازند، اما هزینه همبسته‌سازی خودکار داده‌های چندبعدی و نگهداری یک نمای توپولوژی به‌روز (Real-time Topology)، نیازمند سرمایه‌گذاری کلان و پشتیبانی مداوم است.
هزینه نگهداری ابزارهای داخلی
تیم NIIMBOT توانایی ساخت یک پلتفرم SRE را از پایه داشت. با این حال، آن‌ها تشخیص دادند که حفظ یک نمای پویا و لحظه‌ای از توپولوژی سیستم، فعالیتی بسیار هزینه‌بر از نظر منابع است. تلاشی که برای دقیق نگه داشتن این مدل‌ها همزمان با تکامل سیستم لازم است، دائمی و وقفه‌ناپذیر است.
در واقع، مهندسان مجبور بودند برچسب‌های زمانی (timestamps) را بین لاگ‌ها، متریک‌ها و ردیابی‌ها به‌صورت دستی تطبیق دهند. این اصطکاک باعث ایجاد یک شکاف بحرانی شد: داده‌ها وجود داشتند، اما ارتباط بین نقاط داده وجود نداشت.
سه شکست ساختاری
طبق گزارش dev.to، شرکت NIIMBOT با سه گلوگاه عملیاتی اصلی مواجه بود که پیچیدگی عملیات را به سطح جدیدی رسانده بود:
- توپولوژی تکه‌تکه (Fragmented Topology): فراخوانی‌های API داخلی و وابستگی‌های ابری خارجی در گراف‌های جداگانه‌ای قرار داشتند. در حالی که ARMS برخی روابط API داخلی را نشان می‌داد، وابستگی‌هایی مانند نمونه‌های RDS، نمونه‌های Redis و صف‌های پیام (Message Queues) در نماهای نظارتی مجزا پراکنده بودند. این دو را نمی‌شد در یک گراف پویا ترکیب کرد. نقشه‌برداری دستی این موارد ناکارآمد بود؛ زیرا وابستگی‌هایی که امروز مستند می‌شدند، ممکن بود پس از انتشار نسخه هفته آینده منسوخ شوند.
- داده‌های گسسته (Disconnected Data): متریک‌ها، لاگ‌ها، ردیابی‌ها و رویدادها همگی جمع‌آوری می‌شدند، اما جمع‌آوری همه چیز به معنای متصل کردن همه چیز نیست. عیب‌یابی نیازمند تغییر مداوم زمینه (Context-switching) بین نمودارهای متریک، ردیابی‌ها، لاگ‌ها و رویدادهای تغییر بود. مهندسان باید زمان‌ها را دستی تطبیق می‌دادند و هیچ رشته واحدی وجود نداشت که ابعاد مختلف را به‌طور خودکار به هم پیوند دهد.
- نویز هشدارها (Alert Noise): یک حادثه واحد باعث ایجاد آبشاری از هشدارها در تمام لایه‌ها — فرانت‌اند، بک‌اند، میان‌افزار (Middleware)، دیتابیس و کانتینرها — به‌طور همزمان می‌شد. این وضعیت، منبع واقعی مشکل را دفن می‌کرد. تحلیل ریشه‌ای به‌شدت به غریزه مهندس وابسته بود تا تصمیم بگیرد از کجا شروع کند و مکان‌یابی خطاهای بین-دامنه به‌طور معمول ده‌ها دقیقه زمان می‌برد.
راهکار چهارلایه
شرکت NIIMBOT تصمیم گرفت از «اختراع دوباره چرخ» دست بردارد و یک معماری چهارلایه را با استفاده از اکوسیستم علی‌بابا کلاود پیاده‌سازی کند. پس از بحث‌های فنی، آن‌ها دریافتند که علی‌بابا کلاود پیش از این همبسته‌سازی خودکار در ابعاد داده‌های نظارتی و آگاهی پویا از توپولوژی سرتاسری (End-to-End) را ارائه می‌دهد. این امر به ابر اجازه داد تا بنیاد داده‌های نظارتی و دوقلوی دیجیتال را فراهم کند، در حالی که پلتفرم SRE داخلی شرکت بر ارکستراسیون و گردش‌کارهای حلقه-بسته (Closed-loop) متمرکز شد که برای منطق تجاری خاص NIIMBOT طراحی شده بود.
جزئیات پیاده‌سازی
۱. بنیاد داده‌های نظارتی یکپارچه و چندبعدی
به جای جایگزینی استقرار‌های موجود، NIIMBOT از Cloud Monitor 2.0 (CMS 2.0) استفاده کرد تا چهار قابلیت جمع‌آوری موجود را در یک صفحه داده (Data Plane) واحد بیاورد.
- همگرایی داده‌ها: داده‌های فرانت‌اند از RUM، متریک‌های کانتینر از Prometheus، ردیابی‌ها از ARMS و لاگ‌های تجاری از SLS اکنون در یک مکان متمرکز می‌شوند.
- صفحه یکپارچه: این ساختار یک بنیاد سازگار برای مدل‌سازی توپولوژی و تشخیص‌های هوشمند فراهم می‌کند.
- حذف سیلوها: داده‌ها دیگر در سیلوهای جداگانه قرار ندارند، بلکه وارد یک لایه همبسته‌سازی مشترک با تعاریف یکسان می‌شوند.
۲. دوقلوی دیجیتال عملیاتی UModel
این قابلیت محرک اصلی تغییر رویکرد NIIMBOT بود. UModel به‌طور خودکار سیستم‌های تجاری را مدل‌سازی کرده و یک توپولوژی سرتاسری را می‌سازد که شامل مسیر زیر است:
فرانت‌اند $\rightarrow$ بک‌اند $\rightarrow$ میان‌افزار $\rightarrow$ دیتابیس $\rightarrow$ کانتینرها
این یک نقشه زنده است، نه یک نمودار استاتیک. این نقشه به‌صورت لحظه‌ای با استقرار اپلیکیشن‌ها، تغییر وابستگی‌ها یا مقیاس‌بندی حجم کاری (Workload) به‌روز می‌شود و نیازی به نگهداری دستی ندارد. کلیک روی هر گره (Node) بلافاصله داده‌های نظارتی مرتبط با آن را نمایش می‌دهد و تیم را از کار دستی نگهداری مدل‌های توپولوژی نجات می‌دهد.
۳. تشخیص هوشمند STAROps
با استقرار توپولوژی UModel، ابزار STAROps تحلیل ریشه‌ای خودکار (RCA) را انجام می‌دهد. این ابزار روابط بالادستی و پایین‌دستی را در UModel دنبال می‌کند، گره‌های مرتبط را می‌یابد، داده‌های نظارتی آن‌ها را بازیابی کرده و مراحل بررسی را بازمی‌گرداند.
STAROps سطوح مختلفی از پیچیدگی را مدیریت می‌کند:
- تحلیل تک-دامنه (Single-Domain): به‌طور قابل‌اعتمادی مسائل زیرساختی، مانند سطوح بهره‌وری منابع Pod یا متریک‌های غیرعادی منابع ابری را شناسایی می‌کند.
- تحلیل بین-دامنه (Cross-Domain): برای موارد پیچیده، مانند Garbage Collection مکرر در یک Pod — که هم لایه کانتینر و هم متریک‌های JVM در سطح اپلیکیشن را در بر می‌گیرد — STAROps می‌تواند از نظارت اپلیکیشن شروع کند، توپولوژی را تا متریک‌های JVM دنبال کند و ریشه مشکل را pinpoint کند.
۴. یکپارچگی OpenAPI با پلتفرم SRE داخلی
شرکت NIIMBOT این قابلیت‌ها را از طریق OpenAPI در پلتفرم SRE خود جاسازی کرد. مهندسان به‌جای جابجایی به یک کنسول ابری مجزا، STAROps را مستقیماً به عنوان یک موتور تشخیص فعال می‌کنند.
- جریان زنده (Live Streaming): پلتفرم داخلی، جریانی زنده از نتایج تحلیل و تشخیص را دریافت می‌کند.
- فرآیند استدلال: با یک کلیک، مهندسان می‌توانند فرآیند استدلال STAROps را دنبال کرده و نتایج را به‌صورت لحظه‌ای ببینند.
- خودمختاری پلتفرم: این مدل به‌جای جایگزینی پلتفرم‌ها، قابلیت‌ها را در آن‌ها جاسازی می‌کند و استقلال رابط کاربری خاص کسب‌وکار NIIMBOT را حفظ می‌کند.
تأثیر تجاری و بهره‌وری
این تغییر، تیم عملیات را از «آتشفشان‌شان‌هایی» که فقط به دنبال خاموش کردن آتش بودند، به «ناظرانی پیش‌دستانه» تبدیل کرد. ارزش تجاری در سه حوزه کلیدی محقق شده است:
- تشخیص حلقه-بسته با یک کلیک: پیش از این، مهندسان برچسب‌های زمانی را به‌صورت دستی در ARMS، Prometheus، SLS و Grafana تطبیق می‌دادند. اکنون، یک کلیک در پلتفرم SRE یک تشخیص کامل-دامنه را فعال می‌کند. STAROps داده‌ها را در دامنه‌های مختلف همبسته‌سازی کرده و ریشه مشکل را بازمی‌گرداند و نیاز به جستجوی لایه به لایه را از بین می‌برد.
- تغییر تمرکز منابع: با واگذاری نگهداری قابلیت‌های عمومی مانند مدل‌سازی توپولوژی به علی‌بابا کلاود، تیم مهندسی از صرف منابع گران‌بها برای «اختراع دوباره چرخ» دست کشید. آن‌ها تلاش‌های خود را بر مدیریت منابع ابری و بهینه‌سازی معماری سیستم متمرکز کرده‌اند — کارهایی که مستقیماً به رشد کسب‌وکار کمک می‌کند.
- مدیریت پیش‌دستانه: تیم از حالت انتظار برای هشدارها، تعقیب خطاها و بررسی‌های پس از حادثه، به سمت بازرسی پیش‌دستانه و شناسایی زودهنگام مشکلات حرکت کرده است. این امر انتقال آن‌ها به یک مدل عملیاتی واقعی AIOps را تکمیل می‌کند.
مسیر رسیدن به تشخیص‌های «آگاهانه»
شرکت NIIMBOT اکنون در حال گسترش این نقشه زنده و تشخیص تک-کلیکی در سیستم‌های تجاری هسته خود است. با اضافه شدن سیستم‌های بیشتر، پوشش AIOps همگام با کسب‌وکار گسترش می‌یابد. نقشه راه آینده آن‌ها شامل دو هدف اصلی است:
از همبسته‌سازی مبتنی بر ردیابی به همبسته‌سازی مستقل از نقطه ورود
در حال حاضر، STAROps ریشه‌های خطا را در امتداد توپولوژی UModel شناسایی می‌کند. گام بعدی این است که نتایج مستقل از نقطه شروع بررسی باشند. چه مهندس با یک Pod شروع کند، چه با یک کانتینر یا یک ردیابی اپلیکیشن، سیستم باید به‌طور خودکار به بالا و پایین گسترش یابد تا هر بعد نظارتی را بدون نیاز به انتخاب نقطه ورود «درست» توسط کاربر، متصل کند.
بهبود یکپارچگی OpenAPI
شرکت NIIMBOT و علی‌بابا کلاود از بازخوردهای روزانه برای بهبود پاسخ‌دهی و کامل بودن جریان تشخیص استفاده می‌کنند. هدف این است که تحلیل‌های نمایش داده شده در پلتفرم داخلی، دقیق‌تر و منسجم‌تر شوند و یکپارچگی OpenAPI را به یک تجربه واقعاً بدون درز تبدیل کنند.
این انتقال، یک تغییر استراتژیک را برای تیم‌های SRE بالغ برجسته می‌کند. ارزش اکنون از «توانایی ساخت یک ابزار نظارتی» به «توانایی ارکستراسیون بینش‌های مبتنی بر هوش مصنوعی در یک گردش‌کار خاص تجاری» تغییر یافته است.
گفتگو