ساعت ۱۰ صبح است و تیم NOC دوباره همان Alarm آشنای مصرف CPU را می‌بیند. مقدار CPU یکی از سرورهای مالی از ۸۰ درصد عبور کرده، اما هیچ کاربری اختلالی گزارش نکرده است. کارشناس نمودار را باز می‌کند و می‌بیند این اتفاق تقریباً هر روز در همین بازه زمانی رخ می‌دهد؛ زمانی که پردازش‌های مالی و گزارش‌گیری سنگین اجرا می‌شوند. چند دقیقه بعد مصرف CPU پایین می‌آید و Alarm بسته می‌شود.

اگر این الگو هر روز تکرار شود، مشکل فقط یک هشدار اضافی نیست. به‌مرور تیم عملیات به Alarm عادت می‌کند و این همان نقطه‌ای است که Alert Fatigue می‌تواند باعث شود یک هشدار واقعی هم میان Noise گم شود.

Adaptive Thresholds در ManageEngine OpManager برای همین مسئله طراحی شده است. به‌جای اینکه یک Threshold ثابت برای تمام ساعات شبانه‌روز و همه Deviceها داشته باشیم، OpManager می‌تواند رفتار تاریخی هر Monitor را بررسی کند، مقدار مورد انتظار را پیش‌بینی کند و Threshold را متناسب با همان Baseline تغییر دهد. این قابلیت در کنار Anomaly Detection و Forecast Alerts می‌تواند مدل هشداردهی NOC را از «هر عبور از عدد ثابت» به «تشخیص انحراف معنادار» نزدیک کند.

اگر با محصول آشنا نیستید، صفحه OpManager Plus مدانت نقطه شروع مناسبی برای بررسی قابلیت‌ها، لایسنس و خدمات پیاده‌سازی است.

چرا Threshold ثابت همیشه جواب نمی‌دهد؟

فرض کنید برای تمام Serverها مقدار ۸۰ درصد را به‌عنوان Critical CPU تعیین کرده‌اید. این عدد شاید برای یک Domain Controller منطقی باشد، اما برای سروری که هر روز یک Batch Job سنگین دارد الزاماً معیار خوبی نیست. حتی روی یک Server مشخص نیز مصرف ۷۰ درصد در ساعت ۱۰ صبح و مصرف ۷۰ درصد در ساعت ۳ بامداد معنای یکسانی ندارد.

Threshold ثابت فقط می‌پرسد: «آیا مقدار از عدد تعیین‌شده عبور کرده است؟» اما در عملیات واقعی سؤال بهتر این است: «آیا مقدار فعلی برای این Resource، در این ساعت و با توجه به رفتار گذشته، غیرعادی است؟»

برای مثال ممکن است CPU سرور مالی هر روز بین ساعت ۹ تا ۱۱ به ۸۵ درصد برسد و این رفتار کاملاً طبیعی باشد. در مقابل، همان Server شاید ساعت ۳ بامداد معمولاً ۱۵ درصد مصرف داشته باشد؛ افزایش ناگهانی آن به ۶۰ درصد می‌تواند ارزش بررسی بیشتری داشته باشد، حتی اگر هنوز Threshold ثابت ۸۰ درصد نقض نشده باشد.

Adaptive Threshold در OpManager چطور کار می‌کند؟

بر اساس مستند جاری ManageEngine، OpManager برای ایجاد الگوی قابل اتکا به حداقل ۱۴ روز داده Performance نیاز دارد. در این دوره می‌توان از Thresholdهای Manual استفاده کرد و بعد از شکل‌گیری Baseline، Adaptive Threshold را فعال کرد.

منطق کلی به این صورت است:

1. OpManager داده تاریخی Monitor را جمع‌آوری می‌کند.
2. الگوی مصرف و مقدار Forecast برای بازه زمانی موردنظر محاسبه می‌شود.
3. Administrator برای Severityهای مختلف Deviation تعریف می‌کند.
4. Threshold نهایی از ترکیب Forecast و Deviation ساخته می‌شود.
5. اگر مقدار واقعی از محدوده مورد انتظار عبور کند، Alarm متناسب با Severity تولید می‌شود.

ManageEngine این مدل را برای Performance Monitorها ارائه کرده و امکان تعریف Deviation به‌صورت مقدار ثابت یا Percentage وجود دارد.

یک مثال عددی ساده

فرض کنید Forecast مصرف CPU برای ساعت ۱۰ صبح برابر ۵۵ درصد است و شما Deviationها را این‌طور تعریف کرده‌اید:

در ساعت دیگری ممکن است Forecast همان Server فقط ۲۰ درصد باشد. در آن حالت Thresholdهای عملیاتی هم پایین‌تر می‌آیند و افزایش غیرعادی زودتر دیده می‌شود. مزیت اصلی همین است: Threshold دیگر یک عدد ثابت برای تمام روز نیست.

Adaptive Threshold چه کمکی به کاهش False Positive می‌کند؟

False Positive زمانی رخ می‌دهد که سیستم هشدار می‌دهد اما بررسی کارشناسی نشان می‌دهد رفتار در Context واقعی محیط طبیعی بوده است. مثال‌های رایج شامل Backup شبانه، پردازش پایان ماه، اسکن دوره‌ای، Batch Job، عملیات ETL، Maintenance Window و Peak مصرف قابل پیش‌بینی هستند.

اگر سیستم مانیتورینگ این الگوها را نشناسد، هر Peak می‌تواند Alarm تولید کند. Adaptive Threshold با استفاده از رفتار تاریخی کمک می‌کند Peakهای تکرارشونده و قابل انتظار از Deviations واقعی جدا شوند. هدف کاهش حساسیت نیست؛ هدف این است که حساسیت با Context همان Resource تنظیم شود.

تغییر مهم OpManager در Build جدید 12.8.709

در Readme رسمی OpManager، Build 12.8.709 منتشرشده در ۲۱ ژوئیه ۲۰۲۶ یک بهبود مهم برای Adaptive Threshold معرفی شده است: امکان تعریف هم‌زمان Suppress Limits و Static Limits.

این قابلیت از نظر طراحی عملیاتی مهم است، چون اجازه می‌دهد دو نیاز متضاد را هم‌زمان پوشش دهید:

• در یک محدوده مشخص Alarmهای کم‌ارزش Suppress شوند.
• اگر مقدار از یک Hard Limit قطعی عبور کرد، Alarm حتماً Trigger شود؛ حتی اگر Baseline تاریخی رفتار دیگری نشان دهد.

این یعنی Adaptive Threshold قرار نیست Safety Limitهای فنی را حذف کند. برای مثال اگر Temperature یک تجهیز از محدوده ایمن عبور کند یا Disk Free به سطح بحرانی برسد، ممکن است بخواهید یک Static Limit مستقل از مدل تاریخی داشته باشید.

Manual Threshold، Adaptive Threshold و Anomaly Detection چه تفاوتی دارند؟

این چهار روش رقیب هم نیستند. یک طراحی بالغ معمولاً ترکیبی از آن‌ها را استفاده می‌کند.

Anomaly Detection در OpManager چه چیزی اضافه می‌کند؟

در مستند رسمی ManageEngine، Anomaly Detection در OpManager داده Performance را در سطح Device و Group تحلیل می‌کند و داده Anomaly را به‌صورت ساعتی به‌روزرسانی می‌کند. برخلاف Adaptive Threshold که بر Forecast روند Performance تکیه دارد، Anomaly Detection روی تغییر رفتاری و Deviations ناگهانی تمرکز می‌کند.

برای نمونه، ممکن است Packet Loss برای چند دقیقه جهش کند اما هنوز هیچ Threshold کلاسیکی را نقض نکند. Anomaly Detection می‌تواند این تغییر را در Context رفتار معمول Device نشان دهد و زمان وقوع آن را مشخص کند.

در Dashboard مربوط به Anomaly، OpManager مقدار Expected، مقدار واقعی، درصد Deviation، Device درگیر و زمان رخداد را نمایش می‌دهد. این اطلاعات برای NOC کمک می‌کند بفهمد کدام تغییر ارزش Investigation بیشتری دارد.

Forecast Alerts؛ از واکنش به پیشگیری

Adaptive Threshold درباره وضعیت فعلی و انحراف از رفتار مورد انتظار صحبت می‌کند، اما Capacity Planning سؤال متفاوتی دارد: «اگر روند فعلی ادامه پیدا کند، چه زمانی Resource تمام می‌شود؟»

OpManager از Forecast Alerts و Zia Insights برای پیش‌بینی Resource Exhaustion استفاده می‌کند. نمونه رایج، Disk Utilization است: اگر روند رشد Storage نشان دهد ظرفیت در یک بازه نزدیک به محدوده بحرانی می‌رسد، تیم عملیات می‌تواند قبل از Incident اقدام کند.

این تغییر رویکرد مهم است؛ NOC به‌جای اینکه فقط Alarmهای امروز را ببندد، بخشی از مشکلات فردا را هم قبل از Impact شناسایی می‌کند.

کدام Monitorها را Adaptive کنیم و کدام را ثابت نگه داریم؟

فعال کردن Adaptive Threshold برای همه Metricها بدون طراحی، همان‌قدر اشتباه است که استفاده از یک Threshold ثابت برای تمام شبکه. پیشنهاد عملی این است که Resourceها را براساس نوع رفتار و Criticality دسته‌بندی کنید.

Rollout درست Adaptive Threshold در یک NOC

۱. از کل شبکه شروع نکنید

یک Pilot کوچک روی ۱۰ تا ۳۰ Device از یک کلاس مشابه انتخاب کنید. برای مثال چند Application Server با Workload قابل مقایسه. هدف این است که قبل و بعد از تغییر، کیفیت Alarmها قابل سنجش باشد.

۲. دوره Learning را جدی بگیرید

برای Deviceهای جدید، طبق مستند جاری ManageEngine حداقل ۱۴ روز Performance Data برای شکل‌گیری مدل لازم است. در این مدت Manual Threshold را حذف نکنید.

۳. Deviation را با Runbook هماهنگ کنید

Attention، Trouble و Critical نباید صرفاً سه عدد باشند. برای هر Severity باید مشخص باشد تیم NOC چه اقدامی انجام می‌دهد. اگر Attention هیچ Action یا Trend Review مشخصی ندارد، شاید وجود آن فقط Noise تولید کند.

۴. Hard Limitهای بحرانی را حفظ کنید

به‌خصوص با قابلیت جدید Static Limits در Build 12.8.709، می‌توان Adaptive Behavior را با Safety Limit ترکیب کرد. این روش برای Resourceهای حساس منطقی‌تر از حذف کامل Threshold ثابت است.

۵. Maintenance Window را در طراحی لحاظ کنید

اگر سیستم در زمان Maintenance عمداً رفتار متفاوت دارد، Alarm Suppression و Downtime Schedule باید بخشی از طراحی باشد. Adaptive Threshold قرار نیست جای برنامه‌ریزی Maintenance را بگیرد.

چه KPIهایی نشان می‌دهند تنظیمات بهتر شده‌اند؟

فقط کم شدن تعداد Alarmها موفقیت نیست. اگر Alarm از ۲۰۰۰ به ۲۰۰ برسد اما Incident واقعی از دست برود، سیستم بدتر شده است. KPIهای کاربردی‌تر شامل این موارد هستند:

• False Positive Rate: چند Alarm بعد از بررسی بدون Action واقعی بسته می‌شوند؟
• Actionable Alert Ratio: چه درصدی از Alarmها به Investigation، Ticket یا اقدام فنی منجر می‌شوند؟
• MTTD: زمان متوسط کشف مشکل چقدر است؟
• MTTA: تیم چقدر سریع اقدام را شروع می‌کند؟
• Repeated Alarm Count: چند Alarm تکراری برای یک الگوی شناخته‌شده داریم؟
• Critical Miss Rate: آیا Incident واقعی بدون Alarm مناسب رخ داده است؟
• Forecasted Capacity Issues: چند مشکل قبل از Exhaustion شناسایی شده‌اند؟

هدف نهایی «Alarm کمتر» نیست؛ Alarm قابل اقدام‌تر است.

هزینه Outage نشان می‌دهد چرا کیفیت Alert مهم است

Uptime Institute در گزارش Annual Outage Analysis 2026 اعلام کرده ۵۷ درصد پاسخ‌دهندگان در Survey سال ۲۰۲۵ گفته‌اند آخرین Major Outage آن‌ها بیش از ۱۰۰ هزار دلار هزینه داشته و یک نفر از هر پنج پاسخ‌دهنده هزینه‌ای بیش از یک میلیون دلار گزارش کرده است. همین گزارش اشاره می‌کند Outageهای مرتبط با Fiber و Connectivity رو به افزایش‌اند و احتمال اختلال طولانی‌تری دارند.

این آمار به این معنی نیست که Adaptive Threshold به‌تنهایی از Outage جلوگیری می‌کند؛ اما نشان می‌دهد چرا NOC باید Signal-to-Noise Ratio مناسبی داشته باشد. وقتی هزینه اختلال بالا است، تیم عملیات نباید زمان خود را با Alarmهای تکراری و بی‌اقدام مصرف کند.

Adaptive Threshold را به Incident Management وصل کنید

یک Alarm زمانی ارزش عملیاتی پیدا می‌کند که به فرآیند پاسخ وصل شود. OpManager می‌تواند با ابزارهای ITSM یکپارچه شود تا رخدادهای مهم به Ticket یا Incident تبدیل شوند. در مدانت، معماری یکپارچه ITOM و ITSM را در مطلب ITOM + ITSM؛ رویکرد یکپارچه برای مدیریت حوادث، دارایی و تغییر توضیح داده‌ایم.

برای مثال می‌توان تعریف کرد:

1. Attention فقط برای Trend Review ثبت شود.
2. Trouble برای NOC قابل Investigation باشد.
3. Critical در صورت تداوم به Incident تبدیل شود.
4. اگر Incident تکرار شد، Problem Record ایجاد شود.
5. اگر Root Cause مشخص شد، Knowledge یا Change مرتبط ثبت شود.

اگر از ServiceDesk Plus استفاده می‌کنید، اتصال Monitoring به Incident Management کمک می‌کند Alert از یک Event فنی به یک Workflow قابل پیگیری تبدیل شود. برای مطالعه بیشتر درباره فرآیندهای Service Desk و ITIL می‌توانید به سرویس دسک پلاس فارسی مراجعه کنید.

ارتباط Adaptive Threshold با Root Cause Analysis

Adaptive Threshold کمک می‌کند Noise کمتر شود، اما وقتی Incident واقعی رخ داد هنوز باید علت اصلی پیدا شود. در مقاله Root Cause Analysis در OpManager توضیح داده‌ایم که Topology، Dependency و Event Correlation چگونه می‌توانند مسیر رسیدن از Alarm به Root Cause را کوتاه‌تر کنند.

ترکیب این دو رویکرد منطقی است: ابتدا Alert Fidelity را بهتر کنید تا Alarmهای کم‌ارزش کمتر شوند؛ سپس برای Alarmهای مهم از Dependency و RCA استفاده کنید تا تیم به‌جای درمان Symptom، علت بالادستی را پیدا کند.

Checklist پیشنهادی برای تیم NOC

• Deviceها را براساس Role و Criticality گروه‌بندی کنید.
• Threshold ثابت یکسان را روی تمام Serverها اعمال نکنید.
• برای Device جدید دوره Learning حداقل ۱۴ روزه در نظر بگیرید.
• Adaptive Threshold را ابتدا روی Scope محدود Pilot کنید.
• Deviation هر Severity را با Runbook واقعی هماهنگ کنید.
• Hard Limitهای ایمنی را برای Metricهای حساس حفظ کنید.
• در Buildهای جدید از Suppress و Static Limits استفاده هدفمند کنید.
• Anomaly Dashboard را برای Spikeها و تغییر رفتار Device بررسی کنید.
• Forecast Alert را برای Capacity Planning فعالانه وارد عملیات کنید.
• Alarmهای Critical را به Incident Management متصل کنید.
• False Positive Rate و Actionable Alert Ratio را قبل و بعد از تغییر اندازه بگیرید.
• پس از تغییر Workload، Migration یا تغییر معماری، Baseline را دوباره ارزیابی کنید.

چه زمانی Adaptive Threshold انتخاب مناسبی نیست؟

اگر Metric رفتار تاریخی معناداری ندارد، Adaptive Threshold ممکن است ارزش کمی داشته باشد. برای مثال یک Server موقت که فقط هفته‌ای یک ساعت روشن می‌شود، یک سنسور سخت‌افزاری با Safety Limit مشخص یا Metricی که Threshold قانونی و قطعی دارد، احتمالاً با Rule ثابت بهتر مدیریت می‌شود.

همچنین Adaptive Threshold نباید جای Capacity Planning، Change Management یا Monitoring Coverage را بگیرد. اگر Device مهم اصلاً Monitor نشده یا Dependency آن شناخته‌شده نیست، هوشمندتر کردن Threshold مشکل اصلی را حل نمی‌کند.

برای خرید و پیاده‌سازی OpManager چه چیزی را بررسی کنیم؟

قبل از انتخاب Edition یا تعداد Device، بهتر است Scope واقعی Monitoring مشخص شود: تعداد Router و Switch، Server، Interface، WAN Link، نیاز به Flow Analysis، Configuration Management، Applications Monitoring، High Availability و Enterprise Distributed Monitoring. ساختار لایسنس باید بر اساس معماری واقعی سازمان انتخاب شود، نه فقط تعداد IPها.

برای بررسی هزینه و استعلام لایسنس می‌توانید از صفحه استعلام قیمت محصولات ManageEngine استفاده کنید. مدانت خدمات مشاوره، طراحی معماری، نصب، پیاده‌سازی، آموزش و پشتیبانی OpManager را نیز ارائه می‌دهد.

سخن پایانی

اگر کارشناسان NOC هر روز Alarmهایی را می‌بندند که از قبل می‌دانند هیچ Incident واقعی پشت آن‌ها نیست، مشکل فقط زیاد بودن Alert نیست؛ اعتماد تیم به سیستم مانیتورینگ در حال کاهش است.

Adaptive Thresholds در OpManager کمک می‌کند Baseline هر Monitor از رفتار واقعی آن ساخته شود و Peakهای قابل انتظار از Deviations مهم جدا شوند. Anomaly Detection تغییر رفتار را از زاویه دیگری نشان می‌دهد، Forecast Alerts نگاه عملیات را به آینده می‌برد و قابلیت‌های جدید Build 12.8.709 امکان ترکیب Threshold تطبیقی با Suppress و Static Limits را فراهم می‌کند.

برای یک NOC بالغ، بهترین طراحی معمولاً ترکیبی است: Manual Limit برای مرزهای قطعی، Adaptive Threshold برای Workloadهای متغیر، Anomaly Detection برای تغییر Pattern و Forecast برای Capacity. نتیجه مطلوب هم ساده است: کمتر شدن Noise بدون از دست دادن Signal.

منابع

• ManageEngine: Enabling Adaptive Thresholds in OpManager
• ManageEngine OpManager: Anomaly Detection
• ManageEngine OpManager Readme 12.8
• ManageEngine OpManager: Zia Insights and Forecast Recommendations
• Uptime Institute: Annual Outage Analysis 2026