کالبدشکافی ManageEngine (بخش چهارم): جزیرههای کور اطلاعاتی؛ چرا پیدا کردن «علت ریشهای» در محیطهای چندماژولار دشوار میشود؟
پیش از ورود به بحث لازم است تأکید کنیم که هدف این مجموعه مقالات زیر سؤال بردن ارزش یا توانمندی ابزارهای مطرح مانیتورینگ زیرساخت فناوری اطلاعات نیست. بسیاری از این راهکارها سالهاست در سازمانهای مختلف مورد استفاده قرار گرفتهاند و نقش مهمی در پایش و مدیریت محیطهای IT ایفا میکنند. آنچه در این مجموعه مقالات بررسی میشود، بیشتر نگاهی تحلیلی به برخی محدودیتها و چالشهایی است که میتوانند برای سازمانها مسئلهساز شوند.
در بسیاری از بحرانهای عملیاتی، مشکل اصلی کمبود داده نیست؛ برعکس، دادهها بیش از حد هستند. شبکه هشدار میدهد، اپلیکیشن هشدار میدهد، لاگها پر از خطا هستند و مانیتورینگ دهها سیگنال مختلف تولید میکند. اما با وجود این همه داده، تیم عملیات هنوز با یک سؤال ساده درگیر است:
«مشکل دقیقاً از کجا شروع شده است؟»
در چنین لحظاتی، بسیاری از تیمها متوجه میشوند که ابزار مانیتورینگ آنها تصویری یکپارچه از سیستم ارائه نمیدهد، بلکه مجموعهای از داشبوردهای جداگانه است که هر کدام فقط بخشی از واقعیت را نشان میدهند. این همان جایی است که مفهوم «جزیرههای کور اطلاعاتی» شکل میگیرد.
در قسمت دوم کالبدشکافی ManageEngine دیدیم که این ابزار با وجود ظاهر یکپارچه، در عمل با پدیدهای روبهرو است که میتوان آن را «توهم یکپارچگی» نامید. یکی از مهمترین پیامدهای این معماری، دشوار شدن پیدا کردن علت ریشهای اختلالات در زمان بحرانهای عملیاتی است.
وقتی ManageEngine در یک زیرساخت واقعی مورد استفاده قرار میگیرد، تیم عملیات خیلی زود با یک شکاف معماری جدی روبهرو میشود: دادههای مانیتورینگ در سیستم وجود دارند، اما در جزیرههای جداگانه ذخیره و تحلیل میشوند.
ManageEngine در زیرساختهای پیچیده چه رفتاری دارد؟
برای درک بهتر اثر این معماری چندماژولار، بیایید دو سناریوی متفاوت را بررسی کنیم.
سناریوی اول: یک مشکل ساده در یک لایه
فرض کنید یک سرور اپلیکیشن دچار افزایش شدید مصرف CPU شده است. در نتیجه پاسخدهی سرویس کند میشود. در این شرایط، Applications Manager بهسرعت افزایش مصرف منابع را تشخیص میدهد و هشدار مربوطه را ثبت میکند. تیم عملیات با بررسی همان ماژول میتواند متوجه شود که مشکل از مصرف غیرعادی CPU در همان سرور است.
در چنین سناریویی، چندماژولار بودن سیستم مشکل بزرگی ایجاد نمیکند. علت اختلال در همان لایهای قرار دارد که هشدار از آن صادر شده و مهندس عملیات میتواند نسبتاً سریع علت را پیدا کند.
اما همه اختلالات به این سادگی نیستند.
سناریوی دوم: اختلالی که از چند لایه عبور میکند
حال سناریوی پیچیدهتری را در نظر بگیرید. کاربران گزارش میدهند که یک سرویس مالی بهشدت کند شده است.
در ManageEngine اتفاقات زیر رخ میدهد:
- OpManager افزایش latency در شبکه را گزارش میدهد.
- Applications Manager کاهش throughput اپلیکیشن را ثبت میکند.
- NetFlow Analyzer افزایش غیرعادی ترافیک در یک مسیر شبکه را نشان میدهد.
- Log360 چندین خطای timeout در لاگهای سرویس ثبت میکند.
در این لحظه دادههای زیادی در سیستم وجود دارد، اما هر ماژول فقط بخشی از واقعیت را میبیند. موتور تحلیلی یکپارچه و عمیقی برای کنار هم قرار دادن این رویدادها در یک مدل مشترک وجود ندارد؛ موتوری که بتواند تشخیص دهد کدام رویداد علت اصلی و کدامها صرفاً پیامد آن هستند.
نتیجه این است که تیم عملیات به جای یک هشدار مشخص، با چندین سیگنال پراکنده روبهرو میشود و باید بهصورت دستی بین داشبوردهای مختلف جابهجا شود تا تصویر کامل از مشکل بسازد. در معماری جزیرهای ManageEngine، زمان طلایی شما صرف جابهجایی بین تبها و داشبوردها میشود که نتیجه مستقیم آن، افزایش قابل توجه شاخص MTTR (میانگین زمان رفع خرابی) و نارضایتی کاربران است. در لحظات بحرانی که ثانیهها برای کسبوکار حیاتی هستند، واگذار کردن کشف علت ریشهای به حدس و گمانِ یک مهندسِ تحت استرس، بزرگترین ریسک عملیاتی است.
محدودیت معماری چندماژولار
در سناریوهایی مانند سناریوی دوم است که محدودیت واقعی این معماری چندماژولار آشکار میشود. مشکل اصلی در چنین سناریوهایی کمبود داده نیست؛ دادهها وجود دارند. مسئله این است که این دادهها در یک مدل مشترک تحلیل نمیشوند.
وقتی هر ماژول بهصورت مستقل داده جمعآوری، پردازش و هشدار تولید میکند، سیستم عملاً به مجموعهای از ابزارهای جداگانه تبدیل میشود. در چنین شرایطی همبستگی رویدادها، تشخیص وابستگی سرویسها و پیدا کردن علت ریشهای اختلالات، بیشتر به تجربه مهندس عملیات وابسته میشود تا توانایی خود پلتفرم.
اگر زیرساخت شما ساده و تکلایه باشد، شاید این محدودیت چندان محسوس نباشد. اما در محیطهایی که سرویسها در چند لایه مختلف اجرا میشوند—از شبکه و زیرساخت گرفته تا اپلیکیشن و دیتابیس—این شکاف معماری میتواند زمان تشخیص و رفع اختلالات را به شکل قابل توجهی افزایش دهد.
به همین دلیل بسیاری از پلتفرمهای جدید Observability تلاش کردهاند این مشکل را از سطح معماری حل کنند؛ یعنی به جای چند ماژول مستقل، همه سیگنالهای سیستم (متریکها، لاگها و رویدادها) را در یک هسته داده مشترک تحلیل کنند.
پلتفرم مانیتورینگ معین نیز با همین رویکرد طراحی شده است. در این معماری، دادههای لایههای مختلف زیرساخت — از متریکهای سرورها و تجهیزات شبکه گرفته تا لاگها و رویدادهای اپلیکیشن — به جای اینکه در ماژولهای جداگانه نگهداری شوند، در یک هسته داده مشترک جمعآوری و تحلیل میشوند.
این یکپارچگی در پلتفرم معین باعث میشود سیستم بتواند ارتباط میان رویدادهای مختلف را بهتر تشخیص دهد؛ برای مثال تشخیص دهد که افزایش latency شبکه چگونه میتواند به کاهش کارایی اپلیکیشن و ایجاد خطا در لاگها منجر شود. در نتیجه، به جای مجموعهای از هشدارهای پراکنده، مسیر رسیدن به علت ریشهای اختلالات کوتاهتر و شفافتر میشود.
