درس ۸ از ۱۰

Threshold و Alert

موضوع این درس Threshold و Alert است؛ اول مفهوم اصلی را ساده روشن می‌کنیم، بعد سراغ نشانه‌ها و ابزارهای بررسی می‌رویم و در پایان می‌بینیم هنگام خطا از کجا باید شروع کنی؛ مثال‌ها را با فضای سامانه Monitoring جلو می‌بریم تا موضوع به کار واقعی وصل شود این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

این درس برای مطالعه کامل نوشته شده است

با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست

Threshold بر اساس وضعیت پایه تعیین شود

Threshold حدی است که عبور Metric از آن می‌تواند Alert بسازد؛ به مدت زمان و چند نمونه پشت‌سرهم هم فکر کن تا Alert کاذب کم شود یک مقدار ثابت برای همه Serverها مناسب نیست وضعیت پایه، وضعیت عادی و سالم سیستم است که برای مقایسه هنگام خرابی استفاده می‌شود؛ مصرف معمول CPU، Latency و Config سالم نمونه وضعیت پایه است عدد خارج از عادت لزوماً بد نیست؛ اثر روی سرویس را هم ببین برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمع‌آوری متمرکز کمک می‌کند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیام‌ها در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونه‌هایی از شاخص‌هایی هستند که بسته به سرویس معنا پیدا می‌کنند؛ Threshold بدون Baseline می‌تواند Alert زیاد و بی‌ارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود

Alert زیاد باعث خستگی تیم می‌شود

Alert زیاد باعث خستگی تیم می‌شود؛ اینجا یک رابطه علت و معلولی داریم؛ یعنی دیدن نشانه به‌تنهایی علت را ثابت نمی‌کند، اما این عامل باید در فهرست فرضیه‌ها قرار بگیرد و با یک تست مناسب تأیید یا رد شود هشدار پیامی است که سامانه پایش پس از برآورده شدن یک شرط مهم تولید می‌کند؛ هشدار خوب مشخص می‌کند چه چیزی، کجا و از چه زمانی غیرعادی شده است هشدار زیاد و بی‌ارزش باعث می‌شود هشدار واقعی نادیده گرفته شود اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونه‌هایی از شاخص‌هایی هستند که بسته به سرویس معنا پیدا می‌کنند؛ Threshold بدون Baseline می‌تواند Alert زیاد و بی‌ارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمع‌آوری متمرکز کمک می‌کند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیام‌ها

Warning و Critical فرق دارند

Warning باید قبل از خرابی فرصت اقدام بدهد و Critical نشان‌دهنده وضعیت جدی‌تر است؛ Thresholdها باید با وضعیت عادی سرویس تنظیم شوند نه عدد دلخواه در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمع‌آوری متمرکز کمک می‌کند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیام‌ها اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونه‌هایی از شاخص‌هایی هستند که بسته به سرویس معنا پیدا می‌کنند؛ Threshold بدون Baseline می‌تواند Alert زیاد و بی‌ارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

وابستگی Awareness هشدار زنجیره‌ای را کم می‌کند

وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه می‌تواند چند سرویس ظاهراً نامرتبط را هم‌زمان خراب کند پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیام‌های رویداد ارائه می‌دهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده می‌شود؛ همگام بودن زمان سیستم‌ها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمع‌آوری متمرکز کمک می‌کند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیام‌ها برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونه‌هایی از شاخص‌هایی هستند که بسته به سرویس معنا پیدا می‌کنند؛ Threshold بدون Baseline می‌تواند Alert زیاد و بی‌ارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود

هر Alert مسئول و اقدام اولیه مشخص داشته باشد

هشدار پیامی است که سامانه پایش پس از برآورده شدن یک شرط مهم تولید می‌کند؛ هشدار خوب مشخص می‌کند چه چیزی، کجا و از چه زمانی غیرعادی شده است برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمع‌آوری متمرکز کمک می‌کند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیام‌ها در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونه‌هایی از شاخص‌هایی هستند که بسته به سرویس معنا پیدا می‌کنند؛ Threshold بدون Baseline می‌تواند Alert زیاد و بی‌ارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

مثال محیط واقعی

فرض کن در سامانه Monitoring مشکلی گزارش شده و احتمال می‌دهی به Threshold و Alert مربوط باشد. قبل از تغییر، وضعیت فعلی را با Dashboard پایش، Syslog/Event Viewer و SNMP بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است

اشتباهات رایج

این اشتباه‌ها را تکرار نکن

  • هشدار پیامی است که سامانه پایش پس از برآورده شدن یک شرط مهم تولید می‌کند؛ هشدار خوب مشخص می‌کند چه چیزی، کجا و از چه زمانی غیرعادی شده است
  • هشدار زیاد و بی‌ارزش باعث می‌شود هشدار واقعی نادیده گرفته شود
  • تغییر دادن تنظیمات مرتبط با Threshold و Alert قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
تمرین عملی

حالا خودت انجام بده

  1. در یک نمونه آزمایشی مرتبط با Threshold و Alert، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
  2. با Dashboard پایش، Syslog/Event Viewer و SNMP وضعیت مرتبط با Threshold و Alert را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
  3. یک خطای فرضی مرتبط با Threshold و Alert بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند

نکته‌هایی که باید با خودت ببری

  • Threshold بر اساس وضعیت پایه تعیین شود
  • Alert زیاد باعث خستگی تیم می‌شود
  • Warning و Critical فرق دارند
  • وابستگی Awareness هشدار زنجیره‌ای را کم می‌کند
  • هر Alert مسئول و اقدام اولیه مشخص داشته باشد
  • هشدارها را طوری تنظیم کن که معنی‌دار باشند و تیم را با Alert بی‌ارزش خسته نکنند
خودسنجی

قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده

این نکته را با یک مثال توضیح بده: Threshold بر اساس وضعیت پایه تعیین شود. بعد بگو در عمل چطور آن را بررسی می‌کنی.

وضعیت پایه، وضعیت عادی و سالم سیستم است که برای مقایسه هنگام خرابی استفاده می‌شود؛ مصرف معمول CPU، Latency و Config سالم نمونه وضعیت پایه است

این نکته را با یک مثال توضیح بده: Alert زیاد باعث خستگی تیم می‌شود. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Alert زیاد باعث خستگی تیم می‌شود؛ اینجا یک رابطه علت و معلولی داریم؛ یعنی دیدن نشانه به‌تنهایی علت را ثابت نمی‌کند، اما این عامل باید در فهرست فرضیه‌ها قرار بگیرد و با یک تست مناسب تأیید یا رد شود

این نکته را با یک مثال توضیح بده: Warning و Critical فرق دارند. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Warning باید قبل از خرابی فرصت اقدام بدهد و Critical نشان‌دهنده وضعیت جدی‌تر است؛ Thresholdها باید با وضعیت عادی سرویس تنظیم شوند نه عدد دلخواه

مطالعه درس همیشه عمومی است

برای ذخیره پیشرفت، دوره را رسمی شروع کن

با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود

ثبت‌نام و شروع رسمی