اون داشبورد مانیتورینگ لعنتی رو باز کن!

سال‌هاست تیم‌های NOC، DevOps و SRE دو دسته‌ هستند:
گروه اول اون‌هایی که تیم NOC مستقل دارن و یه سری هم‌کار که چشم دوختن به گراف‌های مانیتورینگ و دنبال شکار Alertها هستند،
اما گروه دوم؛ تیم‌های کوچیک و بی‌نقص که با ایمیل و SMS دنیا رو می‌چرخون!

اگر شما توی تیم دومید و تیم اختصاصی NOC ندارید، حتی اگر کسب‌و‌کارتون در سطح کشوری سرویس می‌ده، احتمالن این مشکل رو دارید:

هیچ فرآیند روتینی برای نمایش دائمی داشبوردهای مانیتورینگ وجود نداره.

و این دقیقان نقطه‌ای هست که Incident‌ها ازش شروع می‌شن.

📉 «ابزار هست، داشبورد هم هست، ولی جلوی چشم نیست!»

اغلب این تیم‌ها:

• ابزار مانیتورینگ کامل دارند
• Alertها روی ایمیل، SMS، Push فعاله
• حتا چند تا داشبورد هم ساخته شده

اما مشکلی که هست:
تکیه اصلی روی Notification هست، نه روی Awareness.

از طرف دیگه، چون نفرات کم هستند، UI/UX داشبورد هیچ‌وقت اولویت نشده، و داشبورد از نظر کاربرپسندی و خوانایی تقریبن همیشه میراثِ سلیقه‌ی نفر فنی‌ای هست که اول ساخته!

🎨 چرا UI/UX توی داشبورد مانیتورینگ مهمه؟

تو روزهای آروم معمولن:

• تیم زیرساخت با داشبورد بد کنار می‌آد
• می‌دونند کدوم گراف کجاست
• با چشم بسته هم گراف Memory رو پیدا می‌کنن
• بخش زیادی از تشخیص رو از روی Log انجام می‌دن

اما Incident واقعی چی می‌شه؟

• کل تیم فنی، DevOps، Backend، NOC، همه درگیرن
• آدم‌هایی که هیچ‌وقت داشبورد رو ندیدن باید وضعیت رو بفهمن
• هر ۳۰ ثانیه یک نفر می‌پرسه:

«الان چی شد؟ مموری هنوز بالاست؟ CPU برگشت؟ شبکه قطعه؟ سرویس‌ها Load شدن؟»

و اگه متخصص بیرونی هم برای کمک وارد تیم بشه، اون‌جاست که یک داشبورد پیچیده مساویه با دردسر مضاعف.

داشبورد خوب یعنی: در ۵ ثانیه می‌فهمی چه خبره.

🧪 فرمول من برای طراحی داشبورد

بعد از ساخت داشبورد:

1. یک اسکرین‌شات می‌گیرم
2. برای ۲–۳ نفر فنی خارج از تیم می‌فرستم
3. این ۴ سؤال رو می‌پرسم:

• از این داشبورد چی می‌فهمی؟
• چی کمه که اگر بود کمک می‌کرد؟
• چی توی طراحی رو مُخته؟
• چه مدت طول کشید که بفهمی داشبورد چی می‌گه؟

تجربه نشون داده همیشه جواب‌های به‌تری می‌گیرم تا اینکه خودم اصلاحش کنم، چون وقتی دائمن درگیر ساختش هستی، ناخودگاه نمی‌توانی Out of the Box نگاه کنی.

گاهی یک طراح UI/UX توی شرکت، ۲ دقیقه وقت می‌گذاره، و یک نکته‌ی کوچک رنگ/چیدمان کیفیت کل داشبورد رو ۵ برابر می‌کنه. از رفتن سراغشون نترسید. خیلی از تیم‌ها نفرات UI/UX توی دیلی‌ها هستند و حتا نباشن هم معلمولن به خاطر ارتباط مستقیم با تیم فنی در دسترس هستن.

👀 چرا داشبورد باید همیشه باز باشه؟

تصور معمول اینه: «هر اتفاقی بیفته، ایمیل و پیامک می‌آد؛ دیگه چه نیازی به TV؟»

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

• Memory leak
• CPU spike آرام
• افزایش Error Rate
• افزایش Temperature
• افت Throughput
• Queue طولانی
• افت پکت‌ها

Alert ممکنه دیر برسه یا Threshold اشتباه باشه، اما چشم شما این روند رو خیلی قبل‌تر می‌بینه. اگر داشبورد باز باشه، فرصت دارید ۱۰ دقیقه زودتر دخالت کنید و Incident رو قبل از وقوع حل کنید.

داشبورد بسته = Blind Spot
داشبورد باز = Early Detection

🖥️ TV بزنید یا حداقل یک مانیتور رو فدا کنید

اگر دفتر دارید:
یک TV ساده + یک مرورگر همیشه باز کافیه.

اگر تیم ریموت هست:
حداقل روی یکی از مانیتورها یک صفحه‌ی دائم برای داشبورد اختصاص بدید.

مشکل اصلی اما چیه؟
اینکه ۲ هفته اول عالی رعایت می‌شه، اما بعد کم‌کم تبدیل می‌شه به:
«امروز خبری نیست…»
«اجازه بده صبحانه‌مو بخورم…»
«بعدن باز می‌کنم…»

این نباید به روتین سلیقه‌ای تبدیل بشه؛ باید به عنوان یک الزام عملیاتی تعریف بشه و به اون پای‌بند باشیم.

🤝 یک مزیت جانبی اما واقعی: Impress Your Boss

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

نکته مهم اینه که بین این که این بخش یک دست‌آورد باشه یا تبدیل به هدف بشه مرز باریکی هست. پس مراقب باشید راه رو گم نکنید.

🎯 جمع‌بندی

• Notification خوبه، اما خیلی وقتا Awareness یعنی نجات‌دهنده‌ی شما از Incident.
• UI/UX توی داشبورد، یک شوآف و ادا نیست؛ یک نیاز عملیاتیه
• داشبورد باید برای همه آدم‌ها قابل‌درک باشه، نه فقط سازنده‌اش.
• داشبورد باید همیشه جلوی چشم باشه، نه توی یه تب مخفی.
• یک TV ارزان‌تر از یک Incident چندساعته هست.