در قسمت اول، در مورد اینکه چرا تصمیم گرفتیم سیستم BMS قدیمی را در مراکز داده خود با یک سیستم جدید جایگزین کنیم، صحبت کردیم. و نه تنها تغییر دهید، بلکه از ابتدا مطابق با نیازهای شما توسعه دهید. در قسمت دوم به شما می گوییم که چگونه این کار را انجام دادیم.
تجزیه و تحلیل بازار
با در نظر گرفتن مواردی که در مایلیم و تصمیم به امتناع از به روز رسانی سیستم موجود، ما یک مشخصات فنی برای یافتن راه حلی در بازار نوشتیم و از چندین شرکت بزرگ که فقط در زمینه ایجاد سیستم های SCADA صنعتی فعالیت می کنند پرس و جو کردیم.
اولین پاسخ آنها نشان داد که رهبران بازار سیستم های مانیتورینگ در درجه اول به کار بر روی سرورهای سخت افزاری ادامه می دهند، اگرچه روند مهاجرت به ابرها در این بخش قبلاً آغاز شده است. در مورد رزرو ماشین های مجازی، هیچ کس از این گزینه پشتیبانی نمی کند. علاوه بر این، این احساس وجود داشت که هیچ یک از توسعه دهندگان قابل مشاهده در بازار حتی درک نیاز به افزونگی را نشان ندادند: "ابر در حال سقوط نیست" رایج ترین پاسخ بود. در واقع، به ما پیشنهاد شد که مانیتورینگ مرکز داده را در یک ابری که به صورت فیزیکی در همان مرکز داده قرار دارد، قرار دهیم.
در اینجا باید یک انحراف کوچک در مورد فرآیند انتخاب پیمانکار انجام دهیم. قیمت، البته مهم است، اما در طول هر مناقصه برای اجرای یک پروژه پیچیده، در مرحله گفتگو با تامین کنندگان، شما شروع به احساس می کنید که کدام یک از نامزدها علاقه مندتر و توانایی اجرای آن را دارند.
این امر به ویژه در پروژه های پیچیده قابل توجه است.
بر اساس ماهیت شفاف سازی سوالات به مشخصات فنی، پیمانکاران را می توان به علاقه مندان به فروش ساده (فشار استاندارد یک مدیر فروش احساس می شود) و علاقه مندان به توسعه محصول با شنیدن و درک مشتری، سازنده تقسیم کرد. اصلاحات در مشخصات فنی حتی قبل از انتخاب نهایی (حتی با وجود خطر واقعی بهبود مشخصات فنی شخص دیگری و شکست در مناقصه)، در نهایت آنها به سادگی آماده پذیرش یک چالش حرفه ای و ساخت یک محصول خوب هستند.
همه اینها باعث شد که به یک توسعه دهنده محلی نسبتاً کوچک توجه کنیم - گروه شرکت های Sunline که به اکثر نیازهای ما بلافاصله پاسخ داد و آماده اجرای تمام نیازهای مربوط به BMS جدید بود.
خطرات
در حالی که بازیکنان بزرگ در تلاش بودند تا بفهمند ما چه می‌خواهیم و مکاتباتی را که شامل متخصصان سطح پیش‌فروش بود، انجام می‌دادند، توسعه‌دهنده محلی جلسه‌ای را در دفتر ما با مشارکت تیم فنی خود برنامه‌ریزی کرد. در این جلسه پیمانکار بار دیگر تمایل خود را برای مشارکت در پروژه نشان داد و از همه مهمتر نحوه اجرای سیستم مورد نیاز را توضیح داد.
قبل از جلسه، ما شاهد دو خطر در کار با تیمی بودیم که منابع یک شرکت بزرگ ملی یا بین المللی را پشت سر خود ندارد:
- متخصصان می توانند توانایی های خود را بیش از حد برآورد کنند و در نتیجه به سادگی از پس این کار بر نمی آیند؛ برای مثال، از نرم افزارهای پیچیده استفاده می کنند یا الگوریتم های رزرو غیرقابل اجرا را طراحی می کنند.
- پس از اتمام پروژه، تیم پروژه ممکن است متلاشی شود و بنابراین، پشتیبانی محصول در خطر خواهد بود.
برای به حداقل رساندن این خطرات، متخصصان توسعه خودمان را به جلسه دعوت کردیم. با کارمندان پیمانکار احتمالی در مورد اینکه این سیستم بر چه اساسی استوار است، چگونه برنامه‌ریزی برای پیاده‌سازی برنامه‌ریزی شده است و سایر مواردی که ما به‌عنوان یک سرویس عملیاتی در آنها صلاحیت کافی نداریم، مصاحبه کاملی انجام شد.
حکم مثبت بود: معماری پلت فرم BMS موجود مدرن، ساده و قابل اعتماد است، می توان آن را بهبود بخشید، طرح افزونگی و هماهنگ سازی پیشنهادی منطقی و قابل اجرا است.
با اولین خطر برخورد شد. دومی پس از دریافت تاییدیه از طرف پیمانکار مبنی بر آمادگی آنها برای انتقال کد منبع سیستم و مستندات به ما و همچنین با انتخاب زبان برنامه نویسی پایتون که برای متخصصان ما کاملاً شناخته شده بود، حذف شد. این فرصت را برای ما تضمین کرد که در صورت خروج شرکت توسعه از بازار، سیستم را بدون هیچ مشکلی و یک دوره طولانی آموزش کارمندان حفظ کنیم.
مزیت اضافی پلتفرم این بود که در کانتینرهای Docker پیاده سازی شد: هسته، رابط وب و عملکرد پایگاه داده محصول در این محیط. این رویکرد مزایای بسیاری از جمله تنظیمات از پیش تعیین شده برای بالاترین سرعت استقرار راه حل در مقایسه با "کلاسیک" و افزودن آسان دستگاه های جدید به سیستم را ارائه می دهد. اصل "همه با هم" اجرای سیستم را تا حد امکان ساده می کند: فقط بسته بندی سیستم را باز کنید و بلافاصله می توانید از آن استفاده کنید.
با این راه حل، کپی برداری از سیستم آسان تر است و می توانید بدون توقف عملکرد راه حل، آن را بهبود بخشید و در یک محیط جداگانه ارتقا دهید.
هنگامی که هر دو خطر به حداقل رسید، پیمانکار CP را ارائه کرد. تمام پارامترهای مهم سیستم BMS را برای ما پوشش می دهد.
رزرو
سیستم BMS جدید باید در فضای ابری، روی یک ماشین مجازی قرار می گرفت.
بدون سخت افزار، بدون سرور و تمام مشکلات و خطرات مرتبط با این مدل استقرار - راه حل ابری به ما اجازه داد تا برای همیشه از شر آنها خلاص شویم. تصمیم گرفته شد که این سیستم در فضای ابری ما در دو سایت مرکز داده در سن پترزبورگ و مسکو کار کند. این دو سیستم کاملاً کاربردی هستند که در حالت آماده به کار فعال با دسترسی به تمام متخصصان مجاز کار می کنند.
این دو سیستم یکدیگر را بیمه می کنند و ذخیره کاملی از توان محاسباتی و کانال های انتقال داده را فراهم می کنند. اقدامات امنیتی اضافی نیز پیکربندی شده است، از جمله پشتیبان گیری از داده ها و کانال ها، سیستم ها، ماشین های مجازی به طور کلی، و یک نسخه پشتیبان از پایگاه داده جداگانه یک بار در ماه (با ارزش ترین منبع از نظر مدیریت و تجزیه و تحلیل).
توجه داشته باشید که افزونگی به عنوان یک گزینه در راه حل BMS به طور خاص برای درخواست ما ایجاد شده است. خود طرح رزرو به این صورت بود:
پشتیبانی
مهمترین نکته برای عملکرد موثر یک راه حل BMS پشتیبانی فنی است.
همه چیز در اینجا ساده است: یک سیستم جدید طبق این شاخص برای ما 35 روبل هزینه خواهد داشت. در هر ماه برای SLA "پاسخ در عرض 000 ساعت"، یعنی 8 x 35 / 000 = 12 دلار در سال. سال اول رایگان است.
برای مقایسه، نگهداری BMS قدیمی از فروشنده 18 دلار در سال با افزایش مبلغ برای هر دستگاه جدید اضافه می شود! در عین حال، این شرکت مدیر اختصاصی ارائه نکرد؛ تمام تعاملات از طریق یک مدیر فروش انجام شد که به ما به عنوان یک خریدار بالقوه علاقه مند است و تاکید مربوط به پردازش درخواست ها را دارد.
با پول کمتر، ما پشتیبانی کامل محصول را دریافت کردیم، با یک مدیر حساب که در توسعه محصول شرکت می کرد، با یک نقطه ورود و غیره. پشتیبانی بسیار انعطاف‌پذیرتر شد - به لطف دسترسی مستقیم به توسعه‌دهندگان برای تنظیمات سریع هر جنبه از سیستم، یکپارچه‌سازی از طریق API و غیره.
به روز رسانی
با توجه به CP پیشنهادی در BMS جدید، تمام به روز رسانی ها در هزینه پشتیبانی گنجانده شده است. نیازی به پرداخت اضافی ندارند استثنا توسعه عملکرد اضافی فراتر از آنچه در مشخصات فنی مشخص شده است است.
سیستم قدیمی هم برای به‌روزرسانی‌های میان‌افزار (مانند جاوا) و هم برای رفع اشکال، نیاز به پرداخت داشت. امتناع از این غیرممکن بود؛ در صورت عدم به روز رسانی، سیستم به طور کلی به دلیل نسخه های قدیمی اجزای داخلی "آهسته" شد.
و البته بروزرسانی نرم افزار بدون خرید بسته پشتیبانی غیرممکن بود.
رویکرد انعطاف پذیر
یکی دیگر از نیازهای اساسی مربوط به رابط است. ما می‌خواستیم بدون حضور اجباری مهندس در قلمرو مرکز داده، دسترسی به آن را از طریق مرورگر وب از هر جایی فراهم کنیم. علاوه بر این، ما به دنبال ایجاد یک رابط متحرک بودیم تا پویایی زیرساخت برای مهندسان وظیفه بیشتر روشن شود.
همچنین در سیستم جدید پشتیبانی از فرمول هایی برای محاسبه عملکرد سنسورهای مجازی در سیستم های مهندسی - به عنوان مثال، برای توزیع بهینه توان الکتریکی در قفسه های تجهیزات ضروری بود. برای انجام این کار، شما باید تمام عملیات ریاضی معمولی که برای نشانگرهای حسگر قابل اجرا هستند را در اختیار داشته باشید.
در مرحله بعد، دسترسی به پایگاه داده SQL با توانایی گرفتن داده های لازم در مورد عملکرد تجهیزات - یعنی تمام سوابق نظارت دو هزار دستگاه و دو هزار حسگر مجازی که تقریباً 20 هزار متغیر را تولید می کنند - مورد نیاز بود.
یک ماژول حسابداری تجهیزات رک نیز مورد نیاز بود، که نمایشی گرافیکی از آرایش دستگاه ها در هر واحد با محاسبه وزن کل سخت افزار، نگهداری کتابخانه ای از دستگاه ها و اطلاعات دقیق در مورد هر عنصر ارائه می کرد.
تصویب مشخصات فنی و امضای قرارداد
در زمانی که شروع کار بر روی سیستم جدید ضروری بود، مکاتبه با شرکت های "بزرگ" هنوز از بحث در مورد هزینه پیشنهادات آنها بسیار دور بود، بنابراین ما CP دریافتی را با هزینه های به روز رسانی BMS قدیمی مقایسه کردیم (نگاه کنید به. ، و در نتیجه از نظر قیمت جذاب تر است و نیازهای ما را برآورده می کند.
انتخاب انجام شده است.
پس از انتخاب پیمانکار، وکلا شروع به تنظیم قرارداد کردند و تیم های فنی دو طرف شروع به صیقل دادن مشخصات فنی کردند. همانطور که می دانید مشخصات فنی دقیق و شایسته مبنای موفقیت هر کاری است. هر چه مشخصات فنی بیشتر باشد، ناامیدی‌های کمتری مانند «اما این چیزی نیست که ما می‌خواستیم» کمتر می‌شود.
من دو مثال از سطح جزئیات الزامات در مشخصات فنی ارائه خواهم کرد:
- مراکز داده در حال وظیفه این اختیار را دارند که دستگاه‌های جدیدی را به BMS اضافه کنند، اغلب اینها PDU هستند. در BMS قدیمی، این سطح "مدیر" بود که امکان تغییر تنظیمات متغیر همه دستگاه ها را نیز فراهم می کرد و جدا کردن عملکردها غیرممکن بود. این به ما نمی خورد در نسخه پایه موجود پلت فرم جدید، این طرح مشابه بود. ما بلافاصله در شرایط مرجع نشان دادیم که می‌خواهیم این نقش‌ها را از هم جدا کنیم: فقط یک کارمند مجاز باید تنظیمات را تغییر دهد، اما آنهایی که در وظیفه هستند باید همچنان بتوانند دستگاه‌ها را اضافه کنند. این طرح برای اجرا پذیرفته شد.
- در هر BMS استاندارد سه دسته معمولی از اعلان ها وجود دارد: قرمز - باید فوراً به آن پاسخ داده شود، زرد - قابل مشاهده است، آبی - "اطلاعاتی". ما به طور سنتی از هشدارهای آبی برای نظارت بر زمانی که پارامترهای تجاری فراتر رفته است، مانند رک مشتری بیش از حد ظرفیت خود استفاده می کنیم. این نوع اعلان در مورد ما برای مدیران در نظر گرفته شده بود و مورد توجه سرویس عملیات نبود، اما در BMS قدیمی مرتباً لیست حوادث فعال را مسدود می کرد و در کار عملیاتی دخالت می کرد. ما منطق و تمایز رنگی شلوار اعلان را موفقیت آمیز دانستیم و آن را حفظ کردیم، با این حال، مشخصات فنی به طور خاص نشان می دهد که اعلان های "آبی" باید بدون پرت کردن افسران وظیفه، بی سر و صدا در یک بخش جداگانه "ریخته شوند"، جایی که آنها توسط متخصصان بازرگانی رسیدگی خواهد شد.
با درجه مشابهی از جزئیات، قالب‌های ساخت نمودارها و تولید گزارش‌ها، خطوط کلی رابط‌ها، فهرست دستگاه‌هایی که نیاز به نظارت داشتند و بسیاری موارد دیگر تجویز شدند.
این یک کار واقعاً خلاقانه از سه گروه کاری بود - خدمات مشتری، که الزامات و شرایط آن را دیکته می کرد. متخصصان فنی در هر دو طرف که وظیفه آنها تبدیل این شرایط به اسناد فنی بود. تیم‌هایی از برنامه‌نویسان پیمانکاری که مطابق با مستندات فنی توسعه‌یافته، الزامات مشتری را پیاده‌سازی کردند... در نتیجه، برخی از الزامات غیراصولی خود را با عملکرد یک پلتفرم موجود تطبیق دادیم و پیمانکار متعهد شد که چیزی برای ما اضافه کند.
عملکرد موازی دو سیستم
زمان اجرا فرا رسیده است. در عمل، این به این معنی بود که ما به پیمانکار این فرصت را می‌دهیم تا نمونه اولیه BMS را در ابر مجازی خود مستقر کند و دسترسی شبکه را به همه دستگاه‌هایی که نیاز به نظارت دارند، فراهم کند.
با این حال، سیستم جدید هنوز برای عملیات آماده نشده بود. در این مرحله حفظ نظارت در سیستم قدیمی و در عین حال دسترسی به دستگاه ها به سیستم جدید برای ما مهم بود. ساختن صحیح یک سیستم بدون دیدن دستگاه هایی در آن غیرممکن است، که به نوبه خود نمی تواند توسط سیستم قدیمی غیرفعال شود.
این که آیا دستگاه ها می توانند بازجویی همزمان توسط دو سیستم را تحمل کنند، بدون آزمایش واقعی مشخص نبود. این احتمال وجود داشت که نظرسنجی مضاعف همزمان منجر به امتناع مکرر دستگاه ها از پاسخگویی شود و خطاهای زیادی مبنی بر در دسترس نبودن دستگاه ها دریافت کنیم که به نوبه خود مانع از عملکرد سیستم مانیتورینگ قدیمی می شود.
بخش شبکه مسیرهای مجازی را از نمونه اولیه BMS جدید مستقر شده در فضای ابری به دستگاه ها اجرا کرد و ما نتایج را دریافت کردیم:
- دستگاه های متصل شده از طریق پروتکل SNMP عملاً هرگز به دلیل درخواست های همزمان قطع نمی شوند.
- دستگاه‌هایی که از طریق دروازه‌ها با استفاده از پروتکل‌های modbas-TCP متصل می‌شوند، مشکلاتی داشتند که با کاهش هوشمند فرکانس نظرسنجی آنها حل شد.
و سپس ما شروع به مشاهده کردیم که چگونه یک سیستم جدید در برابر چشمان ما ساخته می شود ، دستگاه هایی که قبلاً برای ما آشنا بودند در آن ظاهر می شدند ، اما در یک رابط متفاوت - راحت ، سریع ، حتی از طریق تلفن قابل دسترسی.
در پایان در قسمت سوم مقاله خود به شما خواهیم گفت که چه اتفاقی افتاد.
منبع: www.habr.com