کالبدشکافی AppDynamics (بخش پنجم): چالش Root Cause Analysis؛ از Correlation رویدادها تا تشخیص علت اصلی

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

وقتی یک سرویس سازمانی دچار اختلال می‌شود، معمولاً فقط یک Alert ایجاد نمی‌شود. ممکن است هم‌زمان مصرف  CPUیک Server افزایش پیدا کند، Latency یک Application بالا برود، تعداد Errorها افزایش پیدا کند، یک Database کند شود و چند سرویس وابسته نیز رفتار غیرعادی نشان دهند. در چنین شرایطی، تیم عملیات با مجموعه‌ای از علائم مواجه است؛ اما همه این علائم الزاماً علت اختلال نیستند.

یکی از مهم‌ترین وظایف یک پلتفرم مانیتورینگ در چنین شرایطی، تفکیک Symptom از Root Cause است.اینجاست که Root Cause Analysis یا  RCAاهمیت پیدا می‌کند.

RCA دقیقاً چه مسئله‌ای را حل می‌کند؟

فرض کنیم کاربران یک سامانه سازمانی با کندی مواجه شده‌اند.سیستم مانیتورینگ ممکن است چندین مورد را هم‌زمان گزارش کند:افزایش Response Time در Application، افزایش Error Rate، افزایش CPU روی Server، افزایش Query Time در Database و در نهایت افت عملکرد یک سرویس.

اما سؤال تیم عملیات این نیست که «چه چیزهایی غیرعادی شده‌اند؟

سؤال اصلی این است:کدام رخداد یا Component در ابتدای این زنجیره قرار داشته و سایر مشکلات به‌دنبال آن ایجاد شده‌اند؟

اگر Database دچار مشکل شده و همین مسئله باعث افزایش Response Time Application شده باشد، افزایش Response Time یک Symptom است، نه لزوماً  Root Cause.RCA باید بتواند میان این دو تفاوت ایجاد کند.

به همین دلیل، تعداد Alertهایی که یک سیستم تولید می‌کند معیار مناسبی برای سنجش کیفیت RCA نیست. حتی در برخی شرایط، یک سیستم خوب باید بتواند تعداد زیادی Alert مرتبط را به یک مسئله اصلی‌تر تبدیل کند تا تیم عملیات به‌جای بررسی ده‌ها علامت، روی یک زنجیره علت و معلولی متمرکز شود.

Correlation با Root Cause Analysis یکی نیست

یکی از مفاهیم مهم در این حوزه، Event Correlation است.Correlation می‌تواند نشان دهد که چند رخداد با یکدیگر ارتباط زمانی، مکانی یا منطقی دارند. برای مثال، ممکن است مشخص شود افزایش Errorهای یک Application تقریباً هم‌زمان با افزایش Latency یک Database اتفاق افتاده است.اما هم‌زمانی دو رخداد لزوماً به معنای رابطه علت و معلولی میان آن‌ها نیست.ممکن است هر دو رخداد نتیجه یک مشکل سوم باشند یا حتی کاملاً مستقل از یکدیگر رخ داده باشند.

بنابراین:

Correlation می‌گوید چه چیزهایی به هم مرتبط به نظر می‌رسند؛ RCA باید تا حد امکان توضیح دهد چه چیزی علت و چه چیزهایی پیامد آن هستند.

این تفاوت در محیط‌های بزرگ اهمیت زیادی دارد، زیرا تعداد Metricها و Eventها به‌قدری زیاد است که صرفاً پیدا کردن ارتباط میان آن‌ها الزاماً مشکل تیم عملیات را حل نمی‌کند.

Dependency Mapping؛ پایه تحلیل علت و معلول

RCA بدون شناخت Dependencyها بسیار محدود می‌شود.اگر مشخص نباشد یک Application به کدام Service، Database، Server یا سایر Componentها وابسته است، تشخیص اینکه یک رخداد از کجا شروع شده و چه اثری ایجاد کرده، دشوار خواهد بود. برای مثال، فرض کنیم چند Application هم‌زمان دچار افزایش Latency شده‌اند.

اگر مشخص باشد همه آن‌ها به یک Database مشترک وابسته‌اند، تیم عملیات می‌تواند احتمال وجود یک مشکل مشترک را بررسی کند.

اما اگر Dependencyها صرفاً در سطح Application یا Transaction دیده شوند و ارتباط کامل Componentهای Infrastructure و Service در دسترس نباشد، تحلیل Root Cause می‌تواند به اطلاعات بیشتری نیاز داشته باشد.به همین دلیل، کیفیت Dependency Model نقش مهمی در کیفیت RCA دارد.هرچه مدل Dependency دقیق‌تر و جامع‌تر باشد، سیستم مانیتورینگ Context بیشتری برای تحلیل در اختیار خواهد داشت.

Application Dependency با IT Dependency تفاوت دارد

در محیط‌های مدرن، Dependency فقط رابطه میان دو Application نیست.یک سرویس ممکن است به یک API وابسته باشد؛ API روی یک Application Server اجرا شود؛ Application Server  روی یک Virtual Machine قرار داشته باشد؛ Virtual Machine روی یک Host اجرا شود و Host نیز به  Storageو Network مشخصی وابسته باشد.

در چنین زنجیره‌ای، یک اختلال در پایین‌ترین بخش می‌تواند در لایه‌های بالاتر به شکل‌های مختلف ظاهر شود.

برای مثال:

Storage → Host → Virtual Machine → Application Server → Application → Business Service

اگر Storage دچار مشکل شود، ممکن است در نهایت کاربر فقط کندی یک Business Service را مشاهده کند.بنابراین RCA مؤثر باید بتواند از علامت مشاهده‌شده در لایه بالاتر، مسیر وابستگی را به سمت Componentهای پایین‌تر دنبال کند.

در جهت معکوس نیز باید بتواند نشان دهد که یک رخداد در Infrastructure چه سرویس‌ها و Applicationهایی را تحت تأثیر قرار خواهد داد.این همان جایی است که تفاوت میان یک Application Dependency Model و یک Enterprise IT Dependency Model اهمیت پیدا می‌کند.

AppDynamics و Root Cause Analysis

AppDynamics قابلیت‌های متعددی برای Correlation و تحلیل عملکرد Application و Infrastructure دارد و می‌تواند اطلاعات مربوط به Application، Transaction، Infrastructure و Dependencyها را در فرآیند عیب‌یابی مورد استفاده قرار دهد.

-بنابراین نمی‌توان گفت AppDynamics فاقد RCA یا Correlation است.

اتفاقاً RCA یکی از حوزه‌هایی است که در معماری AppDynamics اهمیت زیادی دارد، زیرا هدف آن فقط نمایش وضعیت Componentها نیست و تلاش می‌کند ارتباط میان Performance، Dependency و رخدادهای مختلف را برای تحلیل اختلالات مشخص کند.اما مانند بخش‌های قبلی، سؤال اصلی در اینجا نیز باید دقیق‌تر مطرح شود.

مسئله این نیست که:

آیا AppDynamics، RCA دارد؟

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

RCA در AppDynamics بر چه Contextی بنا شده و تا چه سطحی می‌تواند یک اختلال را در سراسر زنجیره IT دنبال کند؟

این تفاوت در محیط‌هایی که Application محور اصلی عملیات است با محیط‌هایی که تیم NOC مسئول کل Infrastructure و Serviceهای سازمان است، اهمیت پیدا می‌کند.

مشکل Alert Storm؛ وقتی RCA باید نویز را کاهش دهد

یکی از مشکلات رایج در محیط‌های بزرگ، Alert Storm است.فرض کنیم یک Network Component دچار اختلال شده است و در نتیجه آن، چند Server، Database و Application نیز رفتار غیرعادی پیدا می‌کنند.

در چنین شرایطی ممکن است ده‌ها یا حتی صدها Alert تولید شود.اگر سیستم مانیتورینگ این رخدادها را بدون  Context مناسب نمایش دهد، تیم عملیات با انبوهی از Alertها مواجه خواهد شد.

اما اگر بتواند تشخیص دهد که چندین Alert به یک زنجیره Dependency مشترک مربوط هستند، می‌توان آن‌ها را به یک Incident یا Root Cause احتمالی مرتبط کرد.این مسئله یکی از مهم‌ترین تفاوت‌های میان Alert Management و Root Cause Analysis است.

Alert Management می‌گوید چه چیزی غیرعادی است.RCA تلاش می‌کند توضیح دهد چرا این اتفاقات به‌صورت هم‌زمان رخ داده‌اند.در نتیجه، هدف RCA خوب فقط پیدا کردن یک Root Cause نیست؛ بلکه کاهش حجم تحلیل مورد نیاز توسط تیم عملیات نیز هست.

Root Cause همیشه یک Component نیست

یک نکته مهم دیگر این است که Root Cause الزاماً یک Server یا یک Device مشخص نیست.ممکن است علت اختلال یک Configuration اشتباه، تغییر اخیر، محدودیت ظرفیت، افزایش بار، خطای Network، رفتار غیرعادی یک Application یا ترکیبی از چند عامل باشد.بنابراین سیستم RCA نباید صرفاً به دنبال «قرمزترین Component» بگردد.

یک Metric با مقدار بسیار بالا الزاماً علت اصلی اختلال نیست.ممکن است CPU یک Server به دلیل مشکلی در Component  دیگری افزایش پیدا کرده باشد و در واقع خود CPU بالا یک Symptom ثانویه باشد.

به همین دلیل، RCA نیازمند ترکیبی از اطلاعات مختلف است:

Metrics، Events، Dependencies، Historical Behavior، Context و تغییرات محیط.

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

RCA در مقیاس  Enterprise؛ مسئله Context است

در محیط‌های کوچک، یک کارشناس باتجربه ممکن است بتواند با بررسی چند Dashboard و Log، علت اختلال را پیدا کند.اما در محیط‌های Enterprise، تعداد Componentها، سرویس‌ها، Dependencyها و رخدادها به حدی افزایش پیدا می‌کند که اتکا به بررسی دستی دشوارتر می‌شود.در این شرایط، ارزش RCA به میزان Contextی وابسته است که سیستم می‌تواند در اختیار تحلیل قرار دهد.اگر اطلاعات هر Component جدا از سایر اجزا مشاهده شود، کارشناس باید خودش ارتباط میان داده‌ها را پیدا کند.اما اگر سیستم بتواند Relationshipها و Dependencyها را نیز در تحلیل وارد کند، بخشی از این کار می‌تواند به‌صورت خودکار یا نیمه‌خودکار انجام شود.به همین دلیل، RCA را نمی‌توان از Dependency Mapping و Event Correlation  جدا کرد.

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

Dependency Mapping → شناخت رابطه‌ها

Event Correlation → شناخت ارتباط رخدادها

Root Cause Analysis → تحلیل علت اصلی

هرچه این سه لایه بهتر با یکدیگر کار کنند، تیم عملیات با اطلاعات منسجم‌تری برای Troubleshooting مواجه خواهد شد.

آیا RCA یک پاسخ قطعی ارائه می‌دهد؟

یکی از نکاتی که در ارزیابی سیستم‌های RCA باید مورد توجه قرار گیرد، میزان قطعیت نتایج است.در محیط IT همیشه نمی‌توان با اطمینان کامل گفت یک رخداد مشخص، تنها علت یک Incident بوده است. ممکن است چند عامل هم‌زمان در ایجاد یک اختلال نقش داشته باشند.بنابراین خروجی RCA باید در بسیاری از موارد به‌عنوان Root Cause احتمالی یا مجموعه‌ای از عوامل محتمل در نظر گرفته شود، نه یک حقیقت قطعی که بدون بررسی کارشناس پذیرفته شود.

این موضوع اهمیت زیادی دارد؛ زیرا استفاده نادرست از RCA می‌تواند به False Root Cause منجر شود؛ یعنی سیستم یک Component را به‌عنوان علت اصلی معرفی کند، در حالی که آن Component صرفاً یکی از علائم یا عوامل ثانویه بوده است.در نتیجه، ارزش یک سیستم RCA فقط به این نیست که یک Root Cause نمایش دهد؛ بلکه باید بتواند شواهد و Context کافی برای بررسی آن نیز ارائه کند.

رویکرد معین؛ RCA بر مبنای ارتباط میان اشیا

در پلتفرم مانیتورینگ معین، تحلیل Root Cause صرفاً بر اساس وضعیت منفرد یک Component انجام نمی‌شود؛ بلکه ارتباط میان اشیا و نقشی که هر شیء در یک سامانه دارد نیز می‌تواند در تحلیل رخدادها وارد شود.

یکی از قابلیت‌های این رویکرد، امکان تعریف Rule-Based برای مشخص کردن رابطه و اهمیت اجزای مختلف است. برای مثال، در یک سامانه ممکن است یک Database به‌عنوان پایگاه داده اصلی و یک Database دیگر به‌عنوان Backup تعریف شود. در این حالت، از دسترس خارج شدن Database پشتیبان و Database اصلی الزاماً نباید اثر یکسانی در وضعیت سامانه داشته باشد.

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

در اینجا سیستم صرفاً نمی‌گوید «یک Database Down شده است». بلکه با توجه به رابطه، نقش و اهمیت آن شیء در سامانه، وضعیت رخداد را در سطح بالاتری تفسیر می‌کند.

این تفاوت در محیط‌های بزرگ اهمیت بیشتری پیدا می‌کند. ممکن است ده‌ها Component در یک سامانه وجود داشته باشند، اما همه آن‌ها اهمیت یکسانی نداشته باشند. بنابراین برای تحلیل درست وضعیت یک Service، صرفاً دانستن اینکه کدام  Component دچار مشکل شده کافی نیست؛ باید مشخص باشد آن Component چه نقشی در سرویس دارد و اختلال آن چه اثری بر وضعیت کلی سامانه می‌گذارد.

در نتیجه، Rule-Based Analysis می‌تواند به تیم عملیات کمک کند تا به‌جای برخورد یکسان با تمام Alertها، اهمیت رخداد را بر اساس Context و نقش Component در سامانه تعیین کند.

البته Rule-Based Analysis به‌تنهایی معادل RCA کامل نیست. کیفیت RCA همچنان به عواملی مانند مدل Dependency، دقت Ruleها، کیفیت داده‌های مانیتورینگ و Context موجود در سیستم وابسته است. اما ترکیب این موارد می‌تواند کمک کند وضعیت Componentها از سطح یک Alert منفرد فراتر رفته و در چارچوب وضعیت واقعی سامانه و سرویس تفسیر شود.

در چنین رویکردی، هدف صرفاً پاسخ دادن به این سؤال نیست که «چه چیزی Down شده است؟»؛ بلکه باید بتوان پاسخ داد که «چه چیزی Down شده، چه نقشی در سامانه داشته و این رخداد چه اثری بر وضعیت کلی سرویس دارد؟»

جمع‌بندی

Root Cause Analysis یکی از مهم‌ترین قابلیت‌های یک پلتفرم مانیتورینگ Enterprise است، اما نباید آن را صرفاً با یک دکمه یا الگوریتم که در نهایت یک Component را به‌عنوان Root Cause معرفی می‌کند، اشتباه گرفت.یک RCA مؤثر باید بتواند میان Symptom و Cause تفاوت ایجاد کند، رخدادهای مرتبط را از یکدیگر تفکیک کند، Dependencyها را در تحلیل وارد کند و تا حد امکان مسیر اثرگذاری یک مشکل را در زنجیره IT مشخص کند.

AppDynamics در این حوزه قابلیت‌های قابل‌توجهی برای Correlation و تحلیل Application و Infrastructure دارد. بنابراین مسئله اصلی در ارزیابی آن، وجود یا عدم وجود RCA نیست؛ بلکه باید بررسی کرد این تحلیل بر چه  Dependency Model و چه Contextی انجام می‌شود و تا چه سطحی می‌تواند یک Incident را فراتر از Application و در سراسر محیط IT دنبال کند.در نهایت، تفاوت میان یک سیستم دارای RCA و یک سیستم واقعاً مؤثر در RCA، در کیفیت داده، Dependency، Correlation و Context مشخص می‌شود.وقتی تعداد Alertها زیاد است، تیم عملیات به اطلاعات بیشتری نیاز ندارد؛ به اطلاعات مرتبط‌تر نیاز دارد.

و شاید مهم‌ترین سؤال در ارزیابی یک پلتفرم RCA همین باشد:آیا سیستم فقط به شما می‌گوید چه چیزهایی غیرعادی هستند، یا می‌تواند به شما کمک کند بفهمید این اتفاقات چگونه به یکدیگر مرتبط شده‌اند و اختلال از کجا آغاز شده است؟

مجموعه مقالات کالبدشکافی AppDynamics