کالبدشکافی AppDynamics (بخش سوم): چالش Infrastructure Visibility؛ از مشاهده Metricهای زیرساخت تا دید یکپارچه Infrastructure

 پیش از ورود به بحث لازم است تأکید کنیم که هدف این مجموعه مقالات زیر سؤال بردن ارزش یا توانمندی ابزارهای مطرح مانیتورینگ زیرساخت فناوری اطلاعات نیست. بسیاری از این راهکارها سال‌هاست در سازمان‌های مختلف مورد استفاده قرار گرفته‌اند و نقش مهمی در پایش و مدیریت محیط‌های IT ایفا می‌کنند. آنچه در این مجموعه مقالات بررسی می‌شود، بیشتر نگاهی تحلیلی به برخی محدودیت‌ها و چالش‌هایی است که می‌توانند برای سازمان‌ها مسئله‌ساز شوند. ازاین‌رو، اگر قصد خرید نرم‌افزار AppDynamics را دارید، پیشنهاد می‌کنیم پیش از تصمیم‌گیری، مجموعه مقالات کالبدشکافی AppDynamics را نیز مطالعه کنید.

در یک زیرساخت سازمانی، Application تنها یکی از اجزای زنجیره خدمات فناوری اطلاعات است. پشت هر Application مجموعه‌ای از Serverها، Virtual Machineها، Databaseها، Middlewareها، Storageها، تجهیزات Network و سایر اجزای زیرساختی قرار دارند که عملکرد آن‌ها مستقیماً بر کیفیت سرویس نهایی اثر می‌گذارد.

در چنین محیطی، صرفاً دانستن اینکه یک Application کند شده یا یک Business Transaction با خطا مواجه شده، برای تیم عملیات کافی نیست. تیم‌های زیرساخت و NOC باید بتوانند وضعیت خود Infrastructure را نیز به‌صورت مستقل مشاهده و تحلیل کنند؛ یعنی بدانند چه اتفاقی در Server، Network، Storage یا سایر اجزای زیرساخت در حال رخ دادن است، این اتفاق از چه زمانی آغاز شده، چه اجزایی را تحت تأثیر قرار داده و در نهایت چه اثری بر سرویس‌های سازمان خواهد داشت.

این موضوع ما را به مفهوم Infrastructure Visibility می‌رساند.

Infrastructure Visibility چیست؟

Infrastructure Visibility را نمی‌توان صرفاً به نمایش چند Metric مانند CPU، Memory، Disk یا Network Traffic محدود کرد. در یک محیط عملیاتی، دید واقعی نسبت به Infrastructure زمانی شکل می‌گیرد که اطلاعات مربوط به وضعیت اجزای زیرساخت، رخدادها، روند تغییرات، وابستگی میان اجزا و تأثیر آن‌ها بر سرویس‌ها در کنار یکدیگر قابل مشاهده و تحلیل باشند.

برای مثال، افزایش CPU یک Server به‌تنهایی یک Metric است؛ اما اگر مشخص باشد این Server میزبان چند سرویس است، افزایش CPU از چه زمانی آغاز شده، چه فرآیندی باعث آن شده و کدام سرویس‌ها ممکن است در نتیجه آن تحت تأثیر قرار بگیرند، این اطلاعات از سطح Metric فراتر رفته و به Operational Visibility تبدیل می‌شود.

بنابراین می‌توان میان دو سطح از دید زیرساخت تفاوت قائل شد:

Metric Visibility یعنی مشاهده وضعیت و شاخص‌های عملکردی اجزای .Infrastructure 

Operational Visibility یعنی مشاهده این شاخص‌ها در کنار وضعیت اجزا، رخدادها، وابستگی‌ها، Context عملیاتی و اثر احتمالی آن‌ها بر سرویس‌ها.

این تفاوت در زیرساخت‌های بزرگ اهمیت بیشتری پیدا می‌کند؛ زیرا تعداد زیاد Componentها باعث می‌شود بررسی تک‌تک Metricها به‌تنهایی تصویر مناسبی از وضعیت واقعی محیط ارائه نکند.

AppDynamics در Infrastructure Visibility چه رویکردی دارد؟

AppDynamics قابلیت Infrastructure Visibility را در اختیار کاربران قرار می‌دهد و می‌تواند اطلاعات مربوط به Infrastructure و Network را در کنار اطلاعات مربوط به عملکرد Application قرار دهد. بنابراین نمی‌توان گفت AppDynamics   صرفاً یک ابزار  Application Monitoring است و زیرساخت را نمی‌بیند.

اتفاقاً یکی از نقاط قوت AppDynamics این است که می‌تواند اطلاعات Infrastructure را برای تحلیل عملکرد  Application  نیز به کار بگیرد. برای مثال، زمانی که عملکرد یک Application یا Business Transaction دچار افت می‌شود، اطلاعات مربوط به Server، منابع سیستم‌عامل و Network می‌تواند به پیدا کردن عوامل مؤثر بر این افت کمک کند.

اما نکته قابل بررسی در اینجا وجود یا عدم وجود Infrastructure Visibility نیست؛ بلکه مدل ارائه و عمق این  Visibility است.

در یک رویکرد Application-Centric، Application و سرویس‌های وابسته به آن معمولاً نقطه مهمی برای شروع تحلیل هستند و اطلاعات Infrastructure در بسیاری از سناریوها در خدمت تحلیل عملکرد Application قرار می‌گیرد.

در مقابل، در یک رویکرد Infrastructure-Centric یا Unified Monitoring، خود Infrastructure نیز می‌تواند یک حوزه مستقل برای مشاهده و تحلیل باشد؛ حتی زمانی که هنوز هیچ Applicationی دچار اختلال نشده است.

این تفاوت ظریفی است، اما در محیط‌های سازمانی اهمیت زیادی دارد.

از مشاهده Metric تا درک وضعیت  Infrastructure

فرض کنیم CPU یک Server به شکل غیرعادی افزایش پیدا کرده است.

در ساده‌ترین حالت، سیستم مانیتورینگ می‌تواند افزایش CPU را به‌عنوان یک Metric غیرعادی نمایش دهد و حتی برای آن Alert ایجاد کند. اما تیم عملیات معمولاً به اطلاعات بیشتری نیاز دارد:

• آیا این Server برای چند Application استفاده می‌شود؟
• آیا افزایش CPU یک اتفاق موقت است یا یک روند در حال تشدید؟
• آیا هم‌زمان Memory یا Disk نیز دچار تغییر شده است؟
• آیا Component دیگری در Infrastructure نیز رفتار مشابهی دارد؟
• آیا این وضعیت می‌تواند روی یک سرویس مهم سازمانی اثر بگذارد؟

و اگر اثرگذار است، مسیر این تأثیر از Infrastructure تا Service و Application چگونه است؟

اینجاست که تفاوت بین مشاهده Infrastructure و درک  Infrastructureمشخص می‌شود.

هرچه تعداد Componentها و سرویس‌های سازمان بیشتر شود، ارزش اصلی سیستم مانیتورینگ دیگر فقط در تعداد Metricهایی که جمع‌آوری می‌کند نیست؛ بلکه در توانایی آن برای تبدیل این داده‌ها به یک Context عملیاتی قابل استفاده است.

مسئله Shared Infrastructure؛ یک Component، چند سرویس

یکی از چالش‌های مهم در Infrastructureهای سازمانی، وجود منابع مشترک است.

یک Server ممکن است هم‌زمان میزبان چند Application باشد. یک Database می‌تواند به چند سرویس مختلف سرویس‌دهی کند. یک Storage یا مسیر Network ممکن است در چند زنجیره سرویس مورد استفاده قرار گرفته باشد.

در چنین شرایطی، یک مشکل زیرساختی لزوماً فقط یک Application را تحت تأثیر قرار نمی‌دهد.

برای مثال، اختلال در یک Storage می‌تواند هم‌زمان روی چند Server و چند Application اثر بگذارد. بنابراین اگر تحلیل تنها از نقطه‌نظر یک Application انجام شود، ممکن است نشانه‌های یک مشکل مشترک در Infrastructure به‌صورت جداگانه در چند سرویس دیده شوند.

در اینجا داشتن یک مدل ارتباطی میان اجزای Infrastructure و سرویس‌ها اهمیت پیدا می‌کند.

یک مدل عملیاتی ایده‌آل باید بتواند مسیرهایی مانند این را قابل مشاهده کند:

Infrastructure Component → Dependency → Service → Application Impact

و در جهت معکوس نیز:

Application → Service → Infrastructure Component

مسیر اول به تیم عملیات کمک می‌کند بفهمد یک مشکل زیرساختی چه دامنه‌ای از اثرگذاری دارد و مسیر دوم کمک می‌کند در زمان بروز مشکل Application، به سمت Infrastructure حرکت کرده و عامل احتمالی را پیدا کند.

بنابراین مسئله اصلی فقط داشتن Dependency Mapping نیست؛ بلکه دامنه و سطح مدل‌سازی Dependencyها اهمیت دارد.

Proactive Monitoring؛ قبل از اینکه Application دچار اختلال شود

یکی از برداشت‌های اشتباه این است که Infrastructure Monitoring فقط زمانی ارزش دارد که Application دچار مشکل شده باشد.

در عمل، Infrastructure Visibility می‌تواند برای شناسایی نشانه‌های اولیه مشکل نیز مورد استفاده قرار گیرد. برای مثال، افزایش تدریجی مصرف منابع، پر شدن Storage، افزایش خطاهای Network، تغییر غیرعادی در وضعیت یک Component یا شکل‌گیری یک روند نامتعارف می‌تواند پیش از آنکه به اختلال محسوس در Application منجر شود، شناسایی شود.

AppDynamics نیز قابلیت‌هایی برای مشاهده و تحلیل وضعیت Infrastructure و ایجاد Alert بر اساس Metricها و شرایط تعریف‌شده دارد. بنابراین نقد این بخش نباید این باشد که AppDynamics امکان Proactive Monitoring ندارد.

تفاوت در اینجاست که در یک مدل Unified Monitoring، این اطلاعات بخشی از یک تصویر بزرگ‌تر از وضعیت IT سازمان هستند و تیم عملیات می‌تواند مسئله را بدون اینکه الزاماً از یک Application خاص شروع کرده باشد، بررسی کند.

به بیان ساده، سؤال این نیست که:

«آیا AppDynamics می‌تواند وضعیت Server را مانیتور کند؟»

بلکه سؤال مهم‌تر این است:

«آیا اطلاعات مربوط به Server، Network، Storage، Database، Middleware و سایر اجزای Infrastructure در قالب یک مدل عملیاتی یکپارچه قابل مشاهده و تحلیل هستند؟»

Infrastructure Visibility برای NOC چه معنایی دارد؟

برای تیم NOC، Infrastructure Visibility صرفاً یک صفحه شامل نمودارهای CPU و Memory نیست.

NOC معمولاً باید بتواند در یک محیط گسترده به سؤالاتی مانند این پاسخ دهد:

1. کدام Componentها در حال حاضر وضعیت غیرعادی دارند؟
2. کدام رخدادها مهم‌تر هستند؟
3. کدام Componentها با یکدیگر ارتباط دارند؟
4. یک مشکل زیرساختی چه سرویس‌هایی را تحت تأثیر قرار می‌دهد؟
5. آیا چند Alert ظاهراً مستقل در واقع به یک Root Cause مشترک مربوط هستند؟
6. و مهم‌تر از همه، آیا می‌توان از وضعیت فعلی Infrastructure به تأثیر احتمالی آن بر سرویس‌های سازمان رسید؟

بنابراین هرچه تعداد تجهیزات و فناوری‌ها افزایش پیدا کند، ارزش یک Dashboard صرفاً به تعداد Metricهای نمایش داده‌شده وابسته نیست. آنچه اهمیت بیشتری پیدا می‌کند، وجود یک Context مشترک برای تحلیل وضعیت محیط است.

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

Infrastructure Visibility یا  Unified Infrastructure Model؟

در اینجا باید میان دو مفهوم تفاوت قائل شد.

Infrastructure Visibility یعنی امکان مشاهده و تحلیل وضعیت اجزای Infrastructure.

اما Unified Infrastructure Model یک گام جلوتر است؛ در این مدل فقط وضعیت Componentها ثبت نمی‌شود، بلکه رابطه میان آن‌ها و ارتباطشان با سرویس‌ها و Applicationها نیز بخشی از مدل عملیاتی سیستم است.

به همین دلیل، وقتی درباره یکپارچگی مانیتورینگ صحبت می‌کنیم، تعداد فناوری‌های تحت پوشش به‌تنهایی معیار کافی نیست.

ممکن است یک سیستم تعداد زیادی Technology را پوشش دهد، اما اطلاعات هر Technology عمدتاً به‌صورت جداگانه مشاهده شود. در مقابل، یک سیستم Unified باید بتواند اطلاعات مختلف را در یک Context مشترک قرار دهد و رابطه میان Componentها، سرویس‌ها و  Applicationها را قابل تحلیل کند.

این همان نقطه‌ای است که Infrastructure Visibility از یک قابلیت جمع‌آوری Metric به یک قابلیت مهم در عملیات IT تبدیل می‌شود.

آیا Infrastructure Visibility در AppDynamics یک نقطه ضعف است؟

پاسخ مطلق به این سؤال، خیر است.

AppDynamics در حوزه Application Performance Monitoring و مشاهده عملکرد سرویس‌ها قابلیت‌های قدرتمندی دارد و Infrastructure Visibility نیز بخشی از قابلیت‌های آن است. بنابراین نمی‌توان صرفاً بر اساس وجود یا عدم وجود قابلیت Infrastructure Monitoring، آن را نقطه ضعف AppDynamics دانست.

موضوع اصلی، عمق، دامنه و مدل ارائه این Visibility است.

برای سازمانی که اولویت اصلی آن Application Performance، Business Transactions و ارتباط میان Application و زیرساخت زیربنایی است، رویکرد AppDynamics می‌تواند کاملاً منطقی و قدرتمند باشد.

اما برای سازمانی که مسئله اصلی آن ایجاد یک دید یکپارچه از کل IT Infrastructure است و می‌خواهد Server، Network، Storage، Virtualization، Database، Middleware، Application و Business Service را در یک مدل عملیاتی مشترک مشاهده و تحلیل کند، باید دقیق‌تر بررسی شود که Infrastructure Visibility در محصول موردنظر تا چه اندازه مستقل، عمیق و یکپارچه است.

به عبارت دیگر، پرسش درست این نیست که:

«آیا AppDynamics زیرساخت را مانیتور می‌کند؟»

بلکه باید پرسید:

«Infrastructure در مدل مانیتورینگ AppDynamics چه جایگاهی دارد و تا چه سطحی می‌توان رابطه میان اجزای Infrastructure و سرویس‌های سازمان را در یک Context واحد تحلیل کرد؟»

رویکرد معین؛ Infrastructure به‌عنوان یکی از لایه‌های اصلی IT

در معین، مانیتورینگ بر اساس یک لایه واحد از IT تعریف نمی‌شود.

معماری مانیتورینگ معین سه سطح اصلی را در کنار یکدیگر قرار می‌دهد:

• Computing Infrastructure
• Application Infrastructure
• Business Applications

در این مدل، Server، Network، Storage، Virtualization و سایر اجزای زیرساخت در کنار Database، Middleware، Application و سرویس‌های کسب‌وکار در یک چارچوب واحد قرار می‌گیرند.

اهمیت این مدل صرفاً در پوشش Technologyهای مختلف نیست. هدف این است که وضعیت Componentها، ارتباط میان آن‌ها و وابستگی آن‌ها به سرویس‌ها در یک Context مشترک قابل مشاهده باشد.

در نتیجه، تیم عملیات می‌تواند هم از سمت Application به سمت Infrastructure حرکت کند و هم از سمت Infrastructure به سمت سرویس و Application.

این همان تفاوتی است که میان «مشاهده زیرساخت» و «داشتن یک مدل یکپارچه از زیرساخت و سرویس» وجود دارد.

جمع‌بندی

Infrastructure Visibility یکی از مؤلفه‌های مهم در مانیتورینگ سازمانی است، اما نباید آن را صرفاً با جمع‌آوری Metricهای Server، Network یا سایر تجهیزات یکی دانست.

AppDynamics قابلیت مشاهده و تحلیل Infrastructure را دارد و این قابلیت، به‌خصوص در ارتباط با Application Performance، ارزش قابل‌توجهی ایجاد می‌کند. بنابراین نقد فنی AppDynamics در این حوزه نباید بر این ادعا استوار باشد که «زیرساخت را مانیتور نمی‌کند.»

چالش اصلی در مقایسه محصولات، به مدل مانیتورینگ، عمق Visibility، دامنه Dependencyها و میزان یکپارچگی اطلاعات  Infrastructureبا Service و  Applicationبرمی‌گردد.

در یک سازمان بزرگ، داشتن هزاران Metric لزوماً به معنای داشتن دید کامل نسبت به IT نیست. ارزش واقعی زمانی ایجاد می‌شود که این Metricها در کنار Context، Dependency و Impact قابل تحلیل باشند و تیم عملیات بتواند از یک رخداد Infrastructure به سرویس تحت تأثیر و از یک اختلال Application به Component زیرساختی مرتبط برسد.

در چنین نگاهی، Infrastructure دیگر صرفاً لایه‌ای برای پشتیبانی از Application نیست؛ بلکه یکی از اجزای اصلی مدل عملیاتی IT است.

و دقیقاً در همین نقطه، تفاوت میان Infrastructure Visibility و Unified Monitoring اهمیت پیدا می‌کند؛ موضوعی که در ادامه این مجموعه، در بررسی چالش Operational Complexity می‌توان آن را از زاویه دیگری بررسی کرد.