برق ساختمان قطع میشود، اما همه سرورها هنوز روشناند. داشبورد شبکه وضعیت سبز نشان میدهد و تیم پشتیبانی تصور میکند فرصت کافی دارد. چند دقیقه بعد، ظرفیت باتری کمتر از انتظار میشود و خاموشی ناگهانی ذخیرهساز، چند خدمت را همزمان از دسترس خارج میکند. مسئله فقط قطع برق نبود؛ سازمان نمیدانست با بار فعلی، چه زمانی برای تصمیمگیری باقی مانده است.
پایش برق اضطراری باید به یک پرسش عملی پاسخ دهد: با وضعیت فعلی، کدام خدمت در معرض توقف است و تیم عملیات چه اقدامی باید انجام دهد؟ در این مقاله، طراحی این پایش را با کمک ManageEngine OpManager بررسی میکنیم؛ از اعتبارسنجی دادههای دستگاه تا هشدار، مسئولیت پاسخ و آزمون سناریوی خاموشی.
روشن بودن دستگاه با آماده بودن برق پشتیبان فرق دارد
پاسخ دادن کارت شبکه دستگاه برق اضطراری، فقط دسترسپذیری همان مسیر مدیریتی را نشان میدهد. برای تصمیم درباره تداوم خدمت، اطلاعات بیشتری لازم است: وضعیت کار با باتری، میزان بار، زمان تخمینی پشتیبانی و هشدارهای خود تجهیز. برعکس، قطع ارتباط مدیریتی نیز بهتنهایی ثابت نمیکند برق خروجی قطع شده است.
در معرفی رسمی پایش برق اضطراری در OpManager، بررسی دسترسپذیری، جمعآوری مشخصات باتری، بار، دما و ورودی و خروجی برق توضیح داده شده است. دسترسی به هر شاخص به مدل دستگاه، کارت مدیریتی و اطلاعاتی که آن تجهیز منتشر میکند وابسته است؛ همه دستگاهها را دارای مجموعه شاخص یکسان فرض نکنید.
اول مشخص کنید چه چیزی به چه چیزی وابسته است
پیش از تنظیم هشدار، مسیر برق را روی کاغذ یا در مستندات مورد تأیید ترسیم کنید: دستگاه برق اضطراری، واحد توزیع برق رک، تجهیزات متصل و خدمات وابسته. اگر دو منبع تغذیه سرور هر دو به یک مسیر مشترک وصل باشند، وجود دو کابل الزاماً به معنای دو مسیر مستقل نیست.
پیشنهاد اجرایی این است که برای هر رک، مسئول فنی، مسیر برق و فهرست خدمات حساس ثبت شود. این اطلاعات باید با بازدید مجاز و اسناد تأسیسات تطبیق داده شود. اتصال کابل برق، آزمایش بار و هر مداخله الکتریکی را به افراد واجد صلاحیت بسپارید؛ تیم پایش نباید برای آزمایش نرمافزار، برق زنده تجهیزات را خودسرانه قطع کند.
برای درست شدن ارتباط میان رک، دستگاه و مسئول آن، از نتیجه انبارگردانی تجهیزات فناوری استفاده کنید. هشدار دقیق درباره تجهیزی که محل و مالک آن اشتباه ثبت شده، ممکن است به تیم نامناسب برسد.
چه شاخصهایی را کنار هم ببینیم؟
جدول زیر یک الگوی پیشنهادی برای انتخاب داده و پاسخ عملیاتی است. نام و واحد هر شاخص باید با مستندات دستگاه تطبیق داده شود.
| شاخص | پرسش عملیاتی | اقدام پس از مشاهده وضعیت نامطلوب |
|---|---|---|
| وضعیت برق ورودی | آیا دستگاه از باتری استفاده میکند؟ | اعتبارسنجی با تیم تأسیسات و آغاز پیگیری |
| زمان تخمینی پشتیبانی | برای پاسخ کنترلشده چقدر فرصت داریم؟ | مقایسه با زمان موردنیاز دستورالعمل توقف |
| میزان بار خروجی | آیا اضافه شدن تجهیزات حاشیه اطمینان را کم کرده است؟ | بررسی ظرفیت و تغییرات اخیر رک |
| وضعیت باتری و هشدار دستگاه | آیا خود تجهیز نیاز به رسیدگی اعلام میکند؟ | ارجاع به نگهداری طبق راهنمای سازنده |
| دمای گزارششده | آیا شرایط نسبت به محدوده مجاز نامناسب است؟ | بررسی محیط و تهویه با مسئول مربوط |
| تازگی داده | آیا عدد نمایشدادهشده هنوز معتبر است؟ | بررسی ارتباط و علامتگذاری داده قدیمی |
در این طراحی، «داده دریافت نشده» نباید به صفر تبدیل شود. صفر شدن زمان پشتیبانی با نامشخص بودن آن یکسان نیست. این تفکیک را در نمایش، گزارش و قواعد پاسخ حفظ کنید.
داده دستگاه را پیش از اعتماد کردن آزمایش کنید
واحد اندازهگیری را کنترل کنید
شناسه پایش، نوع مقدار و واحد را از راهنمای سازنده بردارید. استاندارد مدیریت تجهیزات برق اضطراری نمونهای از تعریف ساختاریافته شاخصهای باتری و برق است؛ با این حال تجهیزات ممکن است از شاخصهای اختصاصی سازنده هم استفاده کنند. یک مقدار را صرفاً به دلیل شبیه بودن نام آن به دقیقه، درصد یا درجه تفسیر نکنید.
عدد کنسول را با خود تجهیز مقایسه کنید
در راهاندازی اولیه، مقدار نمایشگر دستگاه یا کنسول رسمی آن را با عدد ثبتشده در ابزار پایش تطبیق دهید. اختلاف میتواند ناشی از واحد، فاصله نمونهبرداری یا انتخاب شاخص نامناسب باشد. نتیجه تطبیق را ثبت کنید تا پس از ارتقای کارت مدیریتی یا تغییر الگوی پایش، دوباره قابل بررسی باشد.
زمان پشتیبانی را وعده قطعی تلقی نکنید
برای تصمیمگیری، زمان گزارششده را بهعنوان برآورد تجهیز در شرایط همان لحظه در نظر بگیرید، نه تضمین زمان باقیمانده. در دستورالعمل عملیاتی، حاشیه اطمینان و رفتار هنگام نامعتبر شدن داده را مشخص کنید. مقدار این حاشیه باید بر اساس آزمونهای مجاز، توصیه سازنده و نیاز خدمات تعیین شود.
هشدار خوب باید فرصت اقدام ایجاد کند
از یک آستانه یکسان برای همه رکها استفاده نکنید. رک حاوی سامانه مالی، تجهیز شبکه شعبه و محیط آزمایشی، نیاز پاسخ یکسانی ندارند. در پیشنهاد ما، هشدارها سه وضعیت را از هم جدا میکنند: نیاز به بررسی، نیاز به اقدام فوری و از دست رفتن امکان پایش.
مثلاً اگر زمان اجرای توقف کنترلشده یک خدمت در آزمون سازمان مشخص شده باشد، هشدار باید پیش از رسیدن به آن نقطه و با حاشیه مصوب صادر شود. این یک روش طراحی است، نه عدد آماده برای همه شبکهها. فقط درصد شارژ را معیار تصمیم نگذارید و وضعیت بار و کیفیت داده را هم لحاظ کنید.
OpManager امکان استفاده از الگوهای اعلان و گردش کار وابسته به هشدار را معرفی کرده است. پیش از وصل کردن اقدام اجرایی به هشدار، ابتدا مسیر اطلاعرسانی و صحت شرط را آزمایش کنید. برای ترکیب بررسی دورهای و پیامهای رویدادی تجهیزات، راهنمای پایش رویدادمحور شبکه مکمل این طراحی است.
خاموشی خودکار را به یک شرط ساده نسپارید
پیشنهاد کمریسک این است که مرحله نخست فقط مشاهده و اعلان باشد. سپس صحت هشدار و پاسخ انسانی در چند سناریوی کنترلشده ارزیابی شود. خودکارسازی توقف تجهیزات باید مالک، مجوز، ترتیب اجرای تأییدشده، شرط لغو و امکان مشاهده نتیجه داشته باشد.
ترتیب توقف یکسانی برای همه سامانهها وجود ندارد. وابستگی برنامه، پایگاه داده، ذخیرهساز و مجازیسازی باید در دستورالعمل همان محیط مشخص شود. همچنین باید معلوم باشد پس از برگشت برق چه کسی سلامت خدمات را تأیید میکند؛ روشن شدن دستگاهها پایان رخداد نیست.
خود سامانه پایش هم به برق نیاز دارد
یک ضعف مهم در طراحی این است که سرور پایش، سوئیچ ارتباطی و مسیر ارسال اعلان همگی همراه تجهیزات تحت نظارت خاموش شوند. بررسی کنید در سناریوی قطعی کدام قسمت از مسیر تشخیص تا اطلاعرسانی باقی میماند و چه مسیر جایگزینی در دسترس تیم است.
این بررسی را با آزمون اعلامشده و هماهنگ انجام دهید. میتوان ابتدا شرایط را با داده آزمایشی یا محیط غیرعملیاتی شبیهسازی کرد. هدف، اثبات رسیدن هشدار و مشخص بودن مسئول اقدام است، نه ایجاد قطعی واقعی برای نشان دادن عملکرد داشبورد.
معیار تحویل پروژه چه باشد؟
فهرست تجهیزات، صحت واحد شاخصها، دریافت اعلان، تعیین مسئول پاسخ، ثبت وضعیت داده قدیمی و سناریوی بازگشت خدمت را در معیار پذیرش قرار دهید. گزارش ماهانه نیز بهتر است تجهیزهای بدون داده، هشدارهای بیپاسخ و تغییر ظرفیت رکها را نشان دهد؛ صرفاً نمودار روشن بودن دستگاه کافی نیست.
برای انتخاب معماری پایش و ارزیابی امکانات موردنیاز، راهکار پایش زیرساخت مدانت را مبنا قرار دهید. انتخاب محصول و ظرفیت لایسنس باید بعد از مشخص شدن تجهیزات و دامنه پایش انجام شود، نه بر اساس تعداد نمودارهای مطلوب.
نکات کلیدی
- دسترسپذیری کارت شبکه، سلامت کامل برق اضطراری را ثابت نمیکند.
- مسیر برق و خدمات وابسته باید پیش از تعریف هشدار مشخص شوند.
- داده قدیمی، مقدار صفر و وضعیت عادی سه حالت متفاوتاند.
- خودکارسازی توقف فقط پس از آزمون و تأیید دستورالعمل محیط انجام شود.
سخن پایانی
ارزش پایش برق اضطراری در این نیست که بعد از خاموشی بگوید چه اتفاقی افتاده است؛ باید پیش از پایان فرصت، تصمیم درست را ممکن کند. برای رسیدن به این هدف، شناخت وابستگیها و آزمون پاسخ به اندازه نصب ابزار اهمیت دارد.
مدانت برای انتخاب و تهیه لایسنس، استقرار پایش، طراحی هشدار و آموزش تیم عملیات خدمات تخصصی ارائه میکند. از طریق درخواست جلسه فنی، ارزیابی را با یک رک نمونه و معیار پذیرش روشن آغاز کنید.
