حالا توی سال ۲۰۲۱ هستیم و از وسط پای‌تخت قدرت اول منطقه 🙂 و به دنبال قطعی‌های برق بهار و تاب‌ستان ۱۴۰۰ ایران تصمیم گرفتم تجربیاتم رو از دردسرهای یک مدیرشبکه یا مدیر ICT در زمان قطعی برق با شما به اشتراک بگذارم! اگرچه در یک دنیای نرمال قطع برق با فرکانسی که این روزها ما تجربه می‌کنیم اتفاق نمیفته، اما به هر حال اگر یک مدیر شبکه هستید لازمه برای هر شرایطی آماده باشید. پس تجربه من رو بخونید و اگر شما هم تجربه‌ای دارید خوش‌حال می‌شم به اشتراک بگذارید تا مطلب رو به مرور کامل‌تر کنیم.
مهندسی IT یا مهندسی برق؟!
یکی از بحث بر انگیزترین مواردی که این روزها با همکاران مطرح می‌کنم این هست که شما به عنوان یک مدیر ICT یا شبکه آیا باید یک آشنایی حداقلی با زیرساخت و مفاهیم برق شبکه‌تون داشته باشید یا خیر. این سوال احتمالن جواب مشخصی نداره و بسته به شرایط و مقیاس کاری شرکتی که در اون شاغل هستید متفاوت هست. معمولن در شبکه‌های سازمانی بزرگ تیم فناوری اطلاعات از تیم‌ها و نقش‌های تخصصی متفاوتی تشکیل شده و همه نقش‌ها الزامی به آشنایی با این موارد ندارند اما از نظر من مدیران واحد ICT در شبکه‌های بزرگ باید یک آشنایی حداقلی از مفاهیم دنیای برق و یک آشنایی خوب با زیرساخت برق شبکه خودشون داشته باشند. بدیهی هست که این مورد منافاتی با این که شرکت شما دارای واحد تاسیسات مستقل هست نداره اما در نهایت چون بحث در این رابطه معمولن بی نتیجه هست قضاوت درباره جواب درست رو به خود شما واگذار می‌کنم و مستقیم می‌ریم سراغ تجربیات.
مستندات زیرساخت برق
تصور کنید برق قطع شده، دیزل ژنراتور تریپ خورده و برای این که مدت بیش‌تری UPS و متعاقبا سرورها رو روشن نگه دارید تصمیم می‌گیرید سوئیچ‌های طبقات رو از مدار خارج کنید؛ در تابلوی برق مرکز داده شرکت رو باز می‌کنید و با انبوهی از کلیدهای مینیاتوری مواجه می‌شید که هیچ کدوم لیبلی ندارند! تجربه‌ی این اتفاق بسیار ساده احتمالن فشار ذهنی سنگینی رو به شما تحمیل خواهد کرد. پس همین امروز A تا Z زیرساخت برق شبکه رو مستند کنید. در شرکت‌های بزرگ معمولن شبکه برق با وجود دیزل ژنراتور و چندین UPS و خطوط جداگانه برق اضطراری پیچیدگی‌های خاصی داره و این مورد بیش‌تر به چشم میاد. همکاران شما در واحد تاسیسات احتمالن می تونن تا حد زیادی به شما کمک کنند و اسناد خودشون رو در اختیار شما قرار بدن اما اگر به در بسته خوردید همراه کردن یک مشاور خبره برای مستندسازی می‌تونه گره گشا باشه.
این قدم فارغ از نفس مستند کردن باعث می‌شه با مشکلات احتمالی که در زیرساخت برق وجود داره آشنا بشید و قبل از بحران برای رفع اون‌ها اقدام کنید. علاوه بر این در توسعه‌های آتی دید خیلی به‌تری از محدودیت‌های پیش رو دارید.
UPS و ژنراتور
این روزها استفاده از UPS تقریبا فراگیر شده و حتا در شبکه‌های کوچک و حداقل برای تجهزات شبکه از UPS استفاده می‌شه. نوع و توان UPS، افزونه‌گی و نحوه پیاده‌سازی اون مسئله پیچیده‌ای هست که لازمه یک مهندس برق خبره درباره‌ی اون به شما مشاوره بده اما شما ملزم هستید درباره چند مورد اطلاع دقیق داشته باشید.
بدیهی‌ترین نکته درباره UPS ها لزوم تعویض دوره‌ای باتری اون‌ها هست، به عنوان یک مهندس از شما انتظار می‌ره به جای مبنا قراردادن سن که دقیق نیست، اعداد مقاومت باتری‌ها رو مبنا قرار بدید. هر چند که در ایران معمولن به همون عدد چهار سال اشاره می‌کنند اما شما حرفه‌ای عمل کنید و همیشه اطمینان داشته باشید که باتری‌های سالمی دارید.
مدت زمان شارژدهی یک UPS در زمان قطع برق به موارد متفاوتی مثل میزان لود، کیفیت باتری، دما و… بستگی داره اما این روزها خیلی از UPSها خودشون با انجام Self Test یک زمان تخمین می‌زنن که از کنسول وب یا نمایشگر خود دستگاه قابل دسترسی هست. اگر هم مرد/زن میدان عمل هستید می‌تونید در یک شرایط ایمن به صورت عملی مدت زمان دشارژ شدن از ۱۰۰ تا ۵۰ درصد رو اندازه‌گیری کنید و با یک نسبت ساده به یک عدد نسبتن دقیق برای ۱۰۰ تا ۰ درصد برسید.
دسترسی به کنسول مدیریتی و پیکربندی SNMP روی UPS می‌تونه اطلاعات بسیار دقیقی به شما بده و اطمینان داشته باشید که هر مشکلی رو می‌تونید به محض وقوع متوجه بشید. پس اگر تا الان اقدامی نکردید همین الان اقدام کنید.
سرویس مرتب UPS و اطمینان از صحت عملکرد اون بسیار مهم هست. بسته به شرایط می‌تونید برای این کار قرارداد بلند مدت ببندید یا به صورت موردی شرکت‌ها متخصص رو برای بازدید دعوت کنید. شاید حداقل شش ماه یک بار عدد مناسبی باشه تا UPS رو خیلی جدی و حتا عملیاتی تست و در صورت نیاز سرویس کنید.
در رابطه با ژنراتور مسائل مشابهی وجود داره اما شرایط کمی فرق داره. عمده ساختمان‌هایی که ژنراتور دارن از اون برای تامین برق کل ساختمان استفاده می‌کنن، نه صرفا مرکز داده، به همین خاطر هم معمولن مدیریت و اطمینان از عملکرد اون‌ها بر عهده واحد تاسیسات هست، اما تجربه نشون داده این مسئله از سمت اون‌ها خیلی جدی گرفته نمی‌شه و تریپ خوردن ژنراتور و تموم شدن سوخت و استارت نخوردن اصلن بعید نیست، بنابر این ارسال یک پیام یادآوری سرویس ژنراتور از سمت شما در سامانه مکاتبات اداری در بازه‌های مشخص می‌تونه کمک کننده باشه.
لزوم تعریف نقش‌ها در زمان قطع برق
فرض کنید برق قطع شده، ژنراتور به هر دلیلی وارد مدار نشده و فقط چند ده دقیقه تا اتمام شارژ UPS فرصت دارید سرویس‌ها رو به صورت ایمن خاموش کنید تا احتمال بروز خطا رو به حداقل برسونید. آیا قطع برق طبق برنامه قبلی بوده؟ کی باید این موضوع رو از اداره برق پیگیری کنه؟ ژنراتور به صورت خودکار وارد مدار نشده، آیا واحد تاسیسات اقدامی کرده و ممکنه دستی روشن بشه یا خیر؟ کی قراره کدوم سرویس‌ها رو خاموش کنه؟ و یه عالمه سوال دیگه از این دست که تهش به «چه کسی؟» ختم می‌شه.
تعریف دقیق نقش افراد و تیم‌های مختلف در زمان قطع برق بسیار حیاتی هست و باید قبل از وقوع حتمن مستند بشه و در یک شبیه‌سازی عملیاتی عینن بررسی و در نهایت بازبینی بشه. وگرنه پیدا پاسخ سوالات بالا مدت زمان بسیاری رو از شما تلف می‌کنه. زمانی که از دست دادن هر دقیقه‌ش می‌تونه از یک قطع برق ساده یک بحران تمام عیار برای شما درست کنه!
اتوماسیون و برنامه مشخص برای خاموشی سرویس‌ها
در ادامه فرض‌های تلخ قبلی این بار فرض کنید همه‌ی اقدامات قبل انجام شده و حالا از همه چیز قطع امید کردین و تصمیم گرفتین سرویس‌ها خاموش بشه. اول از همه بدونید این اتفاق باید تا جای ممکن باید اتوماسیون بشه، تضمینی نیست وقتی برق قطع می‌شه تیم فناوری اطلاعات سرکار باشه، پس لازمه همین الان دست به کار بشید و فرآیند خاموش کردن سرویس‌ها و دستگاه‌ها رو اتوماسیون کنید. این کار با استفاده از نرم‌افزارهای مانیتورینگ یا پلاگین‌های خود UPS معمولن شدنی هست و بسته به نوع UPS و مانیتورینگ احتمالن راهکارهای متفاوتی پیش رو دارید اما در نهایت در حداقلی‌ترین موارد با استفاده از SNMP می‌تونید مشکل رو حل کنید. (در ایران برای UPSهای APC که بسیار رایج هست می‌شه از راهکار PowerChute نام برد)
طبق تجربه‌ی من اتوماسیون کردن خاموشی سرویس‌ها در عین این که ساده به نظر میاد دارای پیچیدگی‌های زیادی هست و پیاده‌سازی درست و موفق اون بسیار وقت گیر هست و بعضا نیاز به آزمون و خطا داره. بدیهیه وقتی شما چند صد ماشین مجازی و ده‌ها سرور و SAN و سوئیچ و … دارید نمی‌تونید به ترتیب حروف الفبا شروع به خاموش کردن کنید. پیدا کردن وابستگی‌های سرویس‌ها و اولویت‌های سازمان چیزی هست که شناسایی دقیق اون بسیار زمان‌بر و نیازمند مطالعه دقیق و مشورت بخش‌های مختلف واحد ICT هست. علاوه بر این توی این راهکار لازمه دستگاه‌های مختلف سخت‌افزاری و نرم‌افزاری با زبان‌های متفاوت رو با هم هماهنگ کنید و این فرآیند راحت نیست.
با تمام تاکیدی که روی اتوماسیون داشتم لازمه برنامه مشخصی هم برای زمانی داشته باشید که این کار قراره توسط افراد انجام بشه. هر کسی چه سرویسی رو چه زمانی باید خاموش کنه. اگر فکر می‌کنید این مسئله خیلی ساده هست می‌تونید در اولین روزکاری پیش رو از خیلی همکارانتون بخواید تصمیم بگیرن مثلن SAN ها رو خاموش کنن، خیلی وقت‌ها تجربه شبیه اولین باری خواهد بود که vim رو باز کردین و خواستین خارج بشین 🙂
معلومه که همه این موارد برای روشن کردن سرویس‌ها هم صادق هست، UPS باید حداقل چند درصد شارژ بشه که سرویس‌ها روشن بشه، کدوم سرویس اول روشن بشه، آیا اتوماسیون هست روشن شدن و … .
در نهایت من برای خودم یک فرمول ساده دارم، اگر بحرانی قابل پیش‌بینی بوده ولی زمان وقوع اون سوالی برای شما پیش میاد که جوابش رو نمی‌دونین یعنی راه رو اشتباه اومدین، پس همین الان به همه‌ی سوال‌ها فکر کنین و جواب درست رو پیدا کنین، جواباتون رو توی یک شبیه‌سازی عملیاتی تست کنید تا دفعه بعد وسط قطع برق تنها نگرانی شما طعم قهوه‌تون باشه 🙂
پ.ن۱: وسط این داستانای اتوماسیون خاموشی سرویس و مانیتورینگ و … تا حد زیادی درگیر SNMP و پلاگین‌های ثالث و iLO و امثالهم می‌شین، یادتون نره که اولویت اول باید پیکربندی ایمن باشه وگرنه هر کدوم از اون‌ها می‌تونه بستر مناسبی برای نفوذ باشه
پ.ن۲: اگر شما هم تجربه مشابهی دارید خوش‌حال می‌شم به اشتراک بذارید تا به متن اضافه بشه