پیش از ورود به بحث لازم است تأکید کنیم که هدف این مجموعه مقالات زیر سؤال بردن ارزش یا توانمندی ابزارهای مطرح مانیتورینگ زیرساخت فناوری اطلاعات نیست. بسیاری از این راهکارها سالهاست در سازمانهای مختلف مورد استفاده قرار گرفتهاند و نقش مهمی در پایش و مدیریت محیطهای IT ایفا میکنند. آنچه در این مجموعه مقالات بررسی میشود، بیشتر نگاهی تحلیلی به برخی محدودیتها و چالشهایی است که میتوانند برای سازمانها مسئلهساز شوند. ازاینرو، اگر قصد خرید نرمافزار AppDynamics را دارید، پیشنهاد میکنیم پیش از تصمیمگیری، مجموعه مقالات کالبدشکافی AppDynamics را نیز مطالعه کنید.
در دو بخش گذشته دیدیم که AppDynamics چگونه از یک رویکرد Application-Centric به سمت مشاهده فناوریهای مختلف و سپس Infrastructure Visibility حرکت میکند. اما در یک محیط سازمانی، داشتن قابلیتهای متعدد تنها بخشی از مسئله است. سؤال مهمتر این است که وقتی تعداد Applicationها، Serverها، Databaseها، Middlewareها و Technologyهای تحت مانیتورینگ افزایش پیدا میکند، مدیریت خودِ سیستم مانیتورینگ چقدر ساده باقی میماند؟
در یک محیط کوچک، اضافه کردن یک Application یا فعال کردن مانیتورینگ یک Technology جدید ممکن است تنها چند مرحله ساده داشته باشد. اما در سازمانی با صدها یا هزاران Component، مسئله دیگر فقط «آیا این Technology پشتیبانی میشود؟» نیست. پرسشهایی مانند نحوه استقرار، مدیریت Configuration، کنترل Versionها، نگهداری Agentها و Integrationها، هماهنگی تغییرات و Troubleshooting خود پلتفرم مانیتورینگ اهمیت پیدا میکنند.
اینجاست که مفهوم Operational Complexity مطرح میشود.
Operational Complexity به معنی «پیچیده بودن یک نرمافزار» نیست. یک سیستم ممکن است از نظر کاربری پیچیده نباشد، اما برای نگهداری و توسعه در مقیاس سازمانی، عملیات قابلتوجهی ایجاد کند.
در یک پلتفرم مانیتورینگ Enterprise، پیچیدگی عملیاتی میتواند از بخشهای مختلفی ایجاد شود؛ از نحوه Onboarding کردن Technologyهای جدید گرفته تا مدیریت Agentها، Extensionها و Integrationها، نگهداری Configurationها، کنترل تغییرات و بررسی خطاهایی که ممکن است نه در خود Infrastructure، بلکه در لایه مانیتورینگ ایجاد شده باشند.
به همین دلیل، برای ارزیابی یک پلتفرم مانیتورینگ نباید فقط پرسید:
چه Technologyهایی را پشتیبانی میکند؟
بلکه باید پرسید:
برای اضافه کردن، تغییر دادن و نگهداری این Technologyها، چه میزان عملیات مستمر لازم است؟
این دو سؤال، الزاماً پاسخ یکسانی ندارند.
هرچه محیط IT سازمان متنوعتر باشد، نیاز به پوشش Technologyهای بیشتری نیز افزایش پیدا میکند.
در یک سازمان ممکن است همزمان از Windows و Linux، چند نوع Database، چند Vendor تجهیزات Network، Virtualization Platformهای مختلف، Middlewareهای متفاوت و تعداد زیادی Application استفاده شود.
AppDynamics برای پوشش این محیط گسترده، از مجموعهای از قابلیتها و روشهای Integration استفاده میکند. این موضوع از نظر Technology Coverage یک مزیت مهم محسوب میشود؛ اما هر Integration جدید، از منظر عملیات نیز یک مؤلفه جدید برای مدیریت ایجاد میکند.
به بیان ساده، افزایش قابلیت پوشش Technology لزوماً به معنای کاهش پیچیدگی عملیاتی نیست.
هرچه دامنه مانیتورینگ گستردهتر شود، تیم عملیات باید مطمئن شود که Integrationها درست کار میکنند، Configurationها با محیط هماهنگ هستند و تغییرات زیرساختی باعث ایجاد مشکل در فرآیند جمعآوری داده نمیشوند.
بنابراین در مقیاس Enterprise، Technology Coverage و Operational Manageability باید در کنار یکدیگر بررسی شوند.
در بخش دوم این مجموعه درباره نقش Agent و Integration در پوشش Technologyهای مختلف صحبت کردیم. در این بخش لازم نیست دوباره خود Agent را بهعنوان یک محدودیت مطرح کنیم؛ نکته مهمتر، Lifecycle آن است.
هر Agentی که در محیط سازمان مستقر میشود، بخشی از چرخه عملیاتی پلتفرم مانیتورینگ را تشکیل میدهد.
با گذشت زمان ممکن است Application تغییر کند، Server جابهجا شود، Operating System بهروزرسانی شود، نسخه Application تغییر کند یا Policyهای امنیتی سازمان تغییر کنند. در چنین شرایطی، Agent نیز باید از نظر Version، Configuration و Compatibility با محیط جدید هماهنگ باشد.
در یک محیط کوچک، مدیریت این تغییرات معمولاً ساده است. اما وقتی تعداد Agentها زیاد میشود، مدیریت وضعیت آنها به یک موضوع مستقل عملیاتی تبدیل میشود.
سؤال دیگر فقط این نیست که:
آیا Agent نصب شده است؟
بلکه باید دانست:
کدام Version روی هر Component نصب است؟
کدام Agentها نیاز به Upgrade دارند؟
کدام Agentها دچار خطا شدهاند؟
آیا تغییر Version یک Component روی جمعآوری داده تأثیر گذاشته است؟
و آیا Configuration فعلی با وضعیت جدید محیط سازگار است؟
این موضوع بهخصوص در سازمانهایی که فرآیندهای رسمی Change Management دارند اهمیت بیشتری پیدا میکند.

یکی از نقاطی که Operational Complexity در آن بهتدریج آشکار میشود، Configuration Management است.
در ابتدای پیادهسازی یک سیستم مانیتورینگ، Configurationها معمولاً محدود هستند. اما با توسعه محیط، تعداد Ruleها، Thresholdها، Policyها، Dashboardها، Alertها، Integrationها و تنظیمات مرتبط نیز افزایش پیدا میکند.
اگر برای هر Technology یا Application نیاز به Configurationهای اختصاصی وجود داشته باشد، این Configurationها باید در طول زمان مدیریت شوند.
فرض کنید یک سازمان چند صد Application و تعداد زیادی Server دارد. اگر تغییر یک استاندارد مانیتورینگ نیازمند اصلاح Configuration در تعداد زیادی Component باشد، مسئله دیگر فقط ایجاد یک Configuration جدید نیست؛ بلکه Propagation، کنترل تغییرات و جلوگیری از Configuration Drift اهمیت پیدا میکند.
Configuration Drift زمانی رخ میدهد که Componentهایی که قرار بوده Configuration مشابهی داشته باشند، به مرور زمان از یکدیگر فاصله بگیرند.
در چنین شرایطی، ممکن است دو Server مشابه رفتار متفاوتی در سیستم مانیتورینگ داشته باشند؛ نه به این دلیل که وضعیت واقعی آنها متفاوت است، بلکه به دلیل تفاوت در Configuration.
بنابراین یک پلتفرم Enterprise باید نهتنها امکان Configuration را فراهم کند، بلکه در مقیاس بزرگ نیز امکان Governance و مدیریت آن را تا حد امکان ساده نگه دارد.
Integration یکی از مهمترین ابزارها برای توسعه قابلیتهای یک پلتفرم مانیتورینگ است.
اما هر Integration یک نقطه تعامل جدید با محیط IT ایجاد میکند.
ممکن است یک Integration به API یک محصول دیگر وابسته باشد، Integration دیگری به Credential مشخصی نیاز داشته باشد و یک Extension نیز به Version خاصی از یک Technology وابسته باشد.
در نتیجه، وقتی محیط مانیتورینگ بزرگتر میشود، تیم عملیات تنها با خود AppDynamics کار نمیکند؛ بلکه با مجموعهای از ارتباطات میان AppDynamics و سایر اجزای محیط نیز سروکار دارد.
این موضوع الزاماً ایراد AppDynamics نیست. اساساً هر پلتفرم مانیتورینگ که بخواهد Technologyهای متنوعی را پوشش دهد، تا حدی با این مسئله مواجه خواهد شد.
اما تفاوت محصولات میتواند در نحوه مدیریت این پیچیدگی باشد.
یک معماری خوب باید تلاش کند پیچیدگی Integrationها را از دید تیم عملیات پنهان یا متمرکز کند و تا حد امکان فرآیند اضافهکردن و نگهداری Technologyهای جدید را استاندارد و قابل کنترل نگه دارد.
یک موضوع مهم دیگر، مسئلهای است که معمولاً در زمان طراحی سیستم مانیتورینگ کمتر مورد توجه قرار میگیرد:
چه اتفاقی میافتد وقتی خود سیستم مانیتورینگ دچار مشکل شود؟
در یک محیط Enterprise، ممکن است دادهای دریافت نشود، Metric خاصی بهروزرسانی نشود، Integration از کار بیفتد، Agent اطلاعات ارسال نکند یا یک Configuration اشتباه باعث ایجاد رفتار غیرمنتظره شود.
در این شرایط، تیم عملیات باید بتواند تشخیص دهد که مشکل از خود Infrastructure است یا از لایه Monitoring.
این مسئله با بزرگتر شدن معماری Monitoring اهمیت بیشتری پیدا میکند، زیرا هرچه تعداد Agentها، Integrationها، Extensionها و Configurationها بیشتر باشد، تعداد نقاطی که باید در زمان Troubleshooting بررسی شوند نیز افزایش پیدا میکند.
بنابراین یکی از معیارهای مهم در یک پلتفرم مانیتورینگ Enterprise، فقط قدرت آن در Monitoring the Environment نیست؛ بلکه توانایی آن در Operating the Monitoring Platform نیز هست.
به عبارت دیگر، تیم IT باید بتواند خود پلتفرم مانیتورینگ را نیز بهعنوان یک سیستم عملیاتی مدیریت کند.
در اینجا میتوان به یک تفاوت مهم میان دو معیار رسید.
Technology Coverage پاسخ میدهد:
این پلتفرم چه چیزهایی را میتواند مانیتور کند؟
اما Operational Manageability میپرسد:
مدیریت همین پوشش در طول زمان چقدر قابل کنترل است؟
ممکن است یک محصول از نظر Technology Coverage بسیار گسترده باشد، اما برای هر Technology نیازمند فرآیندهای متفاوتی برای Deployment، Configuration، Upgrade و Troubleshooting باشد.
در چنین شرایطی، با افزایش اندازه محیط، بخشی از ظرفیت تیم عملیات ممکن است صرف نگهداری خود سیستم مانیتورینگ شود.
بنابراین در ارزیابی یک پلتفرم Enterprise، تعداد Technologyهای تحت پوشش بهتنهایی معیار کافی نیست.
باید دید این پوشش چگونه در طول زمان مدیریت میشود.
وقتی از Scalability صحبت میکنیم، معمولاً اولین چیزی که به ذهن میرسد تعداد Nodeها یا Metricهایی است که یک پلتفرم میتواند مدیریت کند.
اما در یک سیستم مانیتورینگ Enterprise، مقیاسپذیری ابعاد دیگری نیز دارد.
آیا اضافه کردن 100 یا 1000 Component جدید باعث افزایش متناسب در پیچیدگی Configuration میشود؟
آیا Upgrade کردن پلتفرم و اجزای آن همچنان قابل کنترل است؟
آیا تیم عملیات میتواند وضعیت Agentها و Integrationها را بهصورت متمرکز مشاهده کند؟
آیا میتوان Policyها و استانداردهای مانیتورینگ را بدون انجام تغییرات دستی گسترده اعمال کرد؟
و آیا با افزایش تعداد Componentها، تعداد Alertها و Exceptionهای مربوط به خود سیستم مانیتورینگ نیز افزایش پیدا نمیکند؟
به همین دلیل، Scalability در Monitoring فقط ظرفیت فنی جمعآوری داده نیست؛ ظرفیت عملیاتی مدیریت سیستم نیز بخشی از آن است.
باز هم پاسخ مطلق به این سؤال، خیر است.
AppDynamics برای محیطهای پیچیده و Applicationهای Enterprise طراحی شده و بسیاری از قابلیتهای آن دقیقاً برای مدیریت همین محیطها ایجاد شدهاند. بنابراین نمیتوان صرفاً به دلیل وجود Agent، Integration یا Extension نتیجه گرفت که AppDynamics الزاماً یک پلتفرم پیچیده است.
موضوع اصلی این است که با افزایش دامنه استفاده از محصول، هزینه عملیاتی ناشی از مدیریت این اجزا چگونه کنترل میشود.
این موضوع به معماری سازمان، تعداد Technologyها، روش Deployment، فرآیند Change Management، سطح استانداردسازی و نحوه استفاده از قابلیتهای AppDynamics نیز وابسته است.
بنابراین نقد دقیقتر این نیست که:
AppDynamicsپیچیده است.
بلکه سؤال این است:
در یک محیط Enterprise با Technologyهای متنوع و تغییرات مداوم، چه مقدار عملیات برای توسعه، نگهداری و Governance پلتفرم مانیتورینگ مورد نیاز است؟
این سؤال، معیار قابلدفاعتری برای مقایسه محصولات مختلف است.
در پلتفرم مانیتورینگ معین، تمرکز صرفاً بر اضافه کردن Technologyهای بیشتر به فهرست موارد قابل مانیتورینگ نیست؛ مسئله مهمتر این است که این Technologyها چگونه در فرآیند روزمره مانیتورینگ مدیریت میشوند.
وقتی یک سازمان از فناوریهای متنوعی استفاده میکند، داشتن روشهای متعدد برای جمعآوری اطلاعات و مدیریت هر Technology میتواند بهمرور زمان بار عملیاتی تیم مانیتورینگ را افزایش دهد. بنابراین یک پلتفرم یکپارچه باید تلاش کند فرآیندهایی مانند Onboarding، Configuration، مشاهده وضعیت، مدیریت Alert و تحلیل رخدادها را تا حد امکان در یک چارچوب مشترک قرار دهد.
در این رویکرد، اضافه شدن یک Technology جدید نباید به معنای ایجاد یک مدل کاملاً متفاوت برای کار تیم عملیات باشد. اطلاعات Technology جدید باید بتواند در همان محیط مانیتورینگ موجود قرار بگیرد و بدون ایجاد پیچیدگی غیرضروری، در کنار سایر اجزای تحت مانیتورینگ قابل استفاده و تحلیل باشد.
اهمیت این موضوع زمانی بیشتر میشود که محیط IT دائماً در حال تغییر است. در چنین شرایطی، ارزش یک پلتفرم فقط به قابلیت آن برای مانیتور کردن یک Component جدید محدود نمیشود؛ بلکه باید بتواند تغییرات مداوم محیط را با کمترین سربار مدیریتی جذب کند.
به همین دلیل، در ارزیابی یک پلتفرم مانیتورینگ سازمانی، در کنار Technology Coverage باید به Operational Manageability نیز توجه کرد؛ یعنی اینکه تیم IT با چه میزان effort میتواند سیستم مانیتورینگ را توسعه دهد، Configurationها را مدیریت کند، تغییرات را اعمال کند و در صورت بروز مشکل، خود پلتفرم را Troubleshoot کند.
از این منظر، هدف یک پلتفرم یکپارچه صرفاً جمعآوری داده بیشتر نیست؛ بلکه ایجاد یک محیط عملیاتی است که با افزایش مقیاس، پیچیدگی مدیریتی آن با همان سرعت افزایش پیدا نکند.
Operational Complexity یکی از موضوعاتی است که معمولاً در مقایسه پلتفرمهای مانیتورینگ کمتر از قابلیتهای فنی دیده میشود.
در یک محیط کوچک، تفاوت میان دو پلتفرم ممکن است بیشتر در تعداد Technologyهای تحت پوشش یا قابلیتهای Dashboard و Alert مشخص شود. اما در مقیاس Enterprise، نحوه Deployment، Configuration Management، Lifecycle، Upgrade، Integration Management و Troubleshooting خود پلتفرم میتواند به اندازه قابلیتهای اصلی آن اهمیت پیدا کند.
AppDynamics ابزار قدرتمندی برای مانیتورینگ Application و محیطهای Enterprise است و گستردگی Integrationها و قابلیتهای آن بخشی از توانمندی محصول محسوب میشود. در عین حال، هرچه محیط بزرگتر و ناهمگونتر شود، مدیریت اجزای مختلف Monitoring نیز به یک مسئله عملیاتی تبدیل میشود.
بنابراین چالش اصلی را نباید «زیاد بودن قابلیتهای AppDynamics» دانست؛ مسئله این است که چگونه میتوان این قابلیتها را در مقیاس سازمانی، با Configurationهای قابلکنترل، Lifecycle مشخص و کمترین سربار عملیاتی مدیریت کرد.
در نهایت، یک پلتفرم مانیتورینگ Enterprise زمانی واقعاً مقیاسپذیر است که نهتنها بتواند تعداد زیادی Metric و Component را مدیریت کند، بلکه بتواند پیچیدگی ناشی از همین مقیاس را نیز برای تیم عملیات قابلکنترل نگه دارد.
در بخش بعد، میتوانیم از Operational Complexity عبور کنیم و به یکی از مهمترین وعدههای پلتفرمهای مدرن مانیتورینگ برسیم: Root Cause Analysis؛ جایی که سؤال دیگر فقط «چه چیزی خراب شده است؟» نیست، بلکه باید مشخص شود «عامل اصلی این اختلال کدام Component یا Dependency بوده است؟»