تحدثنا في الجزء الأول عن سبب قرارنا بتغيير نظام BMS القديم في مراكز البيانات لدينا إلى نظام جديد. ولا يقتصر الأمر على التغيير فحسب، بل التطوير من الصفر ليناسب متطلباتك. وفي الجزء الثاني نقول كيف فعلنا ذلك.
تحليل السوق
مع الاخذ في الاعتبار رغباتنا وقرارنا برفض ترقية النظام الحالي، قمنا بكتابة اختصاصات للبحث عن حل في السوق وقمنا بإجراء استفسارات إلى العديد من الشركات الكبيرة العاملة فقط في إنشاء أنظمة SCADA الصناعية.
أظهرت الإجابات الأولى منهم أن قادة سوق أنظمة المراقبة يواصلون العمل بشكل أساسي على الخوادم الحديدية، على الرغم من أن عملية الانتقال إلى السحابة في هذا القطاع قد بدأت بالفعل. أما بالنسبة لحجز الأجهزة الافتراضية، فلا أحد يدعم هذا الخيار. علاوة على ذلك، كان هناك شعور بأن أياً من المطورين البارزين في السوق لم يظهر حتى فهمًا للحاجة إلى التكرار: كانت الإجابة الأكثر شيوعًا هي "السحابة لا تسقط". في الواقع، عُرض علينا مراقبة مركز البيانات في السحابة، الموجود فعليًا في نفس مركز البيانات.
نحن هنا بحاجة إلى إجراء استطراد بسيط حول عملية اختيار المقاول. السعر مهم بالطبع، ولكن خلال أي مناقصة لتنفيذ مشروع معقد، في مرحلة الحوار مع الموردين، تبدأ في الشعور بأي من المرشحين أكثر اهتمامًا وقدرة على تنفيذه.
هذا ملحوظ بشكل خاص في المشاريع المعقدة.
وفقًا لطبيعة الأسئلة التوضيحية للاختصاصات، يمكن تقسيم المقاولين إلى مهتمين بالبيع ببساطة (هناك ضغط قياسي من مدير المبيعات) ومهتمين بتطوير المنتج، بعد سماع العميل وفهمه، واتخاذ إجراءات بناءة تغييرات على الاختصاصات حتى قبل الاختيار النهائي (حتى على الرغم من الخطر الحقيقي المتمثل في تحسين المعارف التقليدية لشخص آخر وخسارة العطاء)، في النهاية، مجرد استعداد لمواجهة التحدي المهني وتقديم منتج جيد.
كل هذا جعلنا ننتبه إلى مطور محلي صغير نسبيًا - مجموعة شركات Sunline، التي استجابت لمعظم متطلباتنا على الفور وكانت مستعدة لتلبية جميع الاحتياجات المتعلقة بنظام إدارة المباني الجديد.
المخاطر
بينما كان اللاعبون الكبار يحاولون فهم ما نريده وكانوا يتحدثون معنا بمشاركة متخصصين في مرحلة ما قبل البيع، قام المطور المحلي بتحديد موعد في مكتبنا بمشاركة فريقهم الفني. وفي هذا الاجتماع، أبدى المقاول مرة أخرى استعداده للمشاركة في المشروع، والأهم من ذلك، شرح كيفية تنفيذ النظام المطلوب.
قبل الاجتماع، رأينا خطرين في العمل مع فريق لا يملك موارد شركة وطنية أو دولية كبيرة وراءه:
- قد يبالغ المتخصصون في تقدير قدراتهم، ونتيجة لذلك، لا يمكنهم التعامل ببساطة، على سبيل المثال، قد يستخدمون برامج معقدة أو يصممون خوارزميات تكرار غير عملية.
- بعد اكتمال المشروع، قد يتفكك فريق المشروع، وبالتالي، سيكون دعم المنتج في خطر.
وللحد من هذه المخاطر، قمنا بدعوة متخصصي التنمية لدينا إلى الاجتماع. تمت إجراء مقابلات شاملة مع موظفي المقاول المحتمل حول الأساس الذي بني عليه النظام، وكيف تم التخطيط لتنفيذ التكرار والمسائل الأخرى التي لا نتمتع بالكفاءة الكافية فيها، كقسم تشغيل.
كان الحكم إيجابيًا: إن بنية منصة BMS الحالية حديثة وبسيطة وموثوقة، ويمكن تحسينها، كما أن مخطط التكرار والمزامنة المقترح منطقي وقابل للتنفيذ.
تمكنت من إدارة الخطر الأول. أما الثاني فقد تم استبعاده، بعد أن حصل على تأكيد من المقاول بأنه على استعداد لنقل الكود المصدري لكود النظام وتوثيقه إلينا، وكذلك اختيار لغة البرمجة بايثون المعروفة لدى المتخصصين لدينا. وهذا يضمن لنا القدرة على صيانة النظام بأنفسنا دون أي صعوبات وفترة تدريب طويلة للموظفين في حالة خروج الشركة المطورة من السوق.
ومن المزايا الإضافية للنظام الأساسي أنه تم تنفيذه في حاويات Docker: الوظيفة الأساسية وواجهة الويب وقاعدة بيانات المنتج في هذه البيئة. يوفر هذا الأسلوب العديد من الفوائد، بما في ذلك الإعداد المسبق لنشر الحلول بشكل أسرع مقارنةً بالأسلوب "الكلاسيكي" والإضافة السهلة للأجهزة الجديدة إلى النظام. يعمل مبدأ "الكل معًا" على تبسيط تنفيذ النظام قدر الإمكان: يكفي تفريغ النظام ويمكنك تشغيله على الفور.
مع مثل هذا الحل، يكون من الأسهل عمل نسخ من النظام، ويمكنك تحسينه وتنفيذ الترقيات في بيئة منفصلة، دون إيقاف تشغيل الحل ككل.
وبعد التقليل إلى أدنى حد من كلا الخطرين، قدم المقاول عرض أسعار. تم وضع جميع المعلمات الأكثر أهمية لنظام BMS فيه.
حجز
يجب أن يكون نظام BMS الجديد موجودًا في السحابة، على جهاز افتراضي.
لا توجد أجهزة ولا خوادم، وجميع المضايقات والمخاطر المرتبطة بنموذج النشر هذا - لقد سمح لنا الحل السحابي بالتخلص منها إلى الأبد. تقرر أن يعمل النظام في السحابة الخاصة بنا في موقعين لمراكز البيانات في سانت بطرسبرغ وموسكو. هذان نظامان يعملان بكامل طاقتهما ويعملان في وضع الاستعداد النشط مع إمكانية الوصول لجميع المتخصصين المعتمدين.
ويؤمن النظامان بعضهما البعض، مما يوفر التكرار الكامل لكل من قنوات الطاقة الحاسوبية ونقل البيانات. يتم أيضًا تكوين إجراءات أمنية إضافية، بما في ذلك النسخ الاحتياطي للبيانات والقنوات والأنظمة والأجهزة الافتراضية بشكل عام، ونسخة احتياطية منفصلة لقاعدة البيانات مرة واحدة شهريًا (المورد الأكثر قيمة من حيث الإدارة والتحليل).
لاحظ أن التكرار كخيار لحل BMS تم تطويره خصيصًا لتلبية طلبنا. يبدو نظام الحجز نفسه كما يلي:
Поддержка
النقطة الأكثر أهمية للتشغيل الفعال لحل BMS هي الدعم الفني.
كل شيء بسيط هنا: سيكلفنا النظام الجديد 35 روبل وفقًا لهذا المؤشر. شهريًا لاتفاقية مستوى الخدمة "الرد خلال 000 ساعات"، أي 8 × 35/000 = 12 دولارًا سنويًا. السنة الأولى مجانية.
بالمقارنة، تبلغ تكلفة صيانة نظام إدارة المباني القديم من البائع 18 دولارًا سنويًا، مع زيادة المبلغ مقابل كل جهاز جديد يضاف! في الوقت نفسه، لم توفر الشركة مديرًا مخصصًا، فقد تم كل التفاعل من خلال مدير المبيعات الذي يهتم بنا كمشتري محتمل مع التركيز المقابل على معالجة الطلبات.
مقابل أموال أقل، حصلنا على دعم كامل للمنتج، مع مدير حساب يشارك في تطوير المنتج، مع نقطة دخول واحدة، وما إلى ذلك. أصبح الدعم أكثر مرونة من حيث الحجم - بفضل الوصول المباشر إلى المطورين لإجراء تعديلات سريعة على أي جانب من جوانب النظام، والتكامل عبر واجهة برمجة التطبيقات، وما إلى ذلك.
تحديثات
وفقا للبرنامج القطري المقترح في نظام إدارة المباني الجديد، يتم تضمين كافة التحديثات في تكلفة الدعم، أي. لا تحتاج إلى دفع إضافي. الاستثناء هو تطوير وظائف إضافية، بالإضافة إلى تلك المحددة في TOR.
كان النظام القديم يتضمن الدفع مقابل تحديثات البرامج الثابتة المجانية (مثل Java) وإصلاحات الأخطاء. كان من المستحيل رفض ذلك، في غياب التحديثات، فإن النظام ككل "تباطأ" بسبب الإصدارات القديمة من المكونات الداخلية.
وبطبيعة الحال، كان من المستحيل تحديث البرنامج دون شراء حزمة الدعم.
نهج مرن
متطلب أساسي آخر يتعلق بالواجهة. أردنا توفير الوصول إليه من خلال متصفح الويب من أي مكان، دون التواجد الإلزامي للمهندس على أراضي مركز البيانات. بالإضافة إلى ذلك، سعينا إلى إنشاء واجهة متحركة بحيث تكون ديناميكيات البنية التحتية أكثر وضوحًا للمهندسين المناوبين.
أيضًا، في النظام الجديد، كان من الضروري تقديم الدعم للصيغ لحساب تشغيل أجهزة الاستشعار الافتراضية في الأنظمة الهندسية - على سبيل المثال، للتوزيع الأمثل للطاقة الكهربائية بين رفوف المعدات. للقيام بذلك، يجب أن تكون تحت تصرفك جميع العمليات الرياضية المعتادة المطبقة على مؤشرات أجهزة الاستشعار.
علاوة على ذلك، كان الوصول إلى قاعدة بيانات SQL مطلوبًا مع القدرة على أخذ البيانات اللازمة منها حول تشغيل المعدات - أي جميع سجلات مراقبة ألفي جهاز وألفي جهاز استشعار افتراضي يولد حوالي 20 ألف متغير.
كانت هناك حاجة أيضًا إلى وحدة جرد الرف، مما يوفر تمثيلًا رسوميًا لموقع الأجهزة في كل وحدة مع حساب الوزن الإجمالي للأجهزة، والحفاظ على مكتبة الأجهزة، ومعلومات مفصلة حول كل عنصر.
تنسيق الاختصاصات وتوقيع العقد
في الوقت الذي كان من الضروري البدء في العمل على النظام الجديد، كانت المراسلات مع الشركات "الكبيرة" لا تزال بعيدة جدًا عن مناقشة تكلفة مقترحاتها، لذلك قمنا بمقارنة عرض الأسعار المستلم مع تكلفة تحديث نظام إدارة المباني القديم ( انظر الشكل. )، ونتيجة لذلك، اتضح أنها أكثر جاذبية من حيث السعر وتلبية متطلباتنا.
تم الاختيار.
بعد اختيار المقاول، بدأ المحامون في صياغة العقد، وقامت الفرق الفنية من كلا الجانبين بصقل الشروط المرجعية. كما تعلمون، فإن المواصفات الفنية التفصيلية والمختصة هي أساس نجاح أي عمل. كلما زادت التفاصيل في المعارف التقليدية، قلت خيبة الأمل مثل "لكننا أردناها خطأ".
سأقدم مثالين على مستوى تفاصيل المتطلبات في الاختصاصات:
- يتم تمكين مراكز البيانات المناوبة من إضافة أجهزة جديدة إلى نظام إدارة المباني، وغالبًا ما تكون هذه وحدات PDU. في نظام إدارة المباني القديم، كان هذا هو مستوى "المسؤول"، الذي يسمح، من بين أمور أخرى، بتغيير إعدادات متغيرات جميع الأجهزة، وكان من المستحيل فصل الوظائف. لم يناسبنا. في الإصدار الأساسي الحالي من النظام الأساسي الجديد، كان المخطط مشابهًا. لقد أشرنا على الفور في الاختصاصات إلى أننا أردنا فصل هذه الأدوار: يجب على الموظف المعتمد فقط تغيير الإعدادات، ولكن يجب أن يظل الأشخاص المناوبون قادرين على إضافة الأجهزة. وقد تم قبول هذا المخطط للتنفيذ.
- في أي نظام إدارة المباني القياسي، هناك ثلاث فئات نموذجية من الإخطارات: الأحمر - تحتاج إلى الرد على الفور، والأصفر - يمكنك المراقبة، والأزرق - "إعلامي". لقد استخدمنا تقليديًا الإشعارات الزرقاء لمراقبة متى يتم تجاوز معلمات الأعمال، مثل تجاوز حد طاقة الحامل الخاص بالعميل. كان هذا النوع من الإشعارات في حالتنا مخصصًا للمديرين ولم يكن ذا أهمية لخدمة التشغيل، ولكن في نظام إدارة المباني القديم كان يؤدي بانتظام إلى انسداد قائمة الحوادث النشطة والتدخل في العمل التشغيلي. لقد اعتبرنا أن التمييز بين المنطق واللون في سراويل الإشعارات كان ناجحًا واحتفظنا به، ومع ذلك، تمت الإشارة في TOR على وجه التحديد إلى أن الإشعارات "الزرقاء" يجب أن "تنهار" بصمت في قسم منفصل، دون تشتيت انتباه الحاضرين. وسيتم التعامل معها من قبل متخصصين تجاريين.
وبدرجة مماثلة من التفاصيل، تم وصف تنسيقات رسم الرسوم البيانية وعرض التقارير، والخطوط العريضة للواجهات، وقائمة الأجهزة التي تحتاج إلى مراقبة، وأشياء أخرى كثيرة.
لقد كان عملاً إبداعيًا حقيقيًا لثلاث مجموعات عمل: خدمة العملاء التي أملت متطلباتها وشروطها؛ متخصصون فنيون من الجانبين، وكانت مهمتهم ترجمة هذه الشروط إلى وثائق فنية؛ فرق من المبرمجين المقاولين الذين نفذوا متطلبات العميل وفقًا للوثائق الفنية المطورة ... ونتيجة لذلك، قمنا بتكييف بعض متطلباتنا غير المبدئية مع وظائف النظام الأساسي الحالي، وتعهد المقاول بإضافة شيء لنا.
التشغيل المتوازي لنظامين
حان وقت التنفيذ. من الناحية العملية، هذا يعني أننا نمنح المقاول الفرصة لنشر نموذج أولي لنظام إدارة المباني في السحابة الافتراضية الخاصة بنا وتوفير الوصول إلى الشبكة لجميع الأجهزة التي تتطلب المراقبة.
ومع ذلك، فإن النظام الجديد لم يكن جاهزًا للتشغيل بعد. في هذه المرحلة، كان من المهم بالنسبة لنا مواصلة المراقبة في النظام القديم وفي نفس الوقت منح إمكانية الوصول إلى الأجهزة في النظام الجديد. من المستحيل بناء نظام بشكل طبيعي دون رؤية أجهزة فيه، والتي بدورها لا يمكن فصلها عن المراقبة بواسطة النظام القديم.
ولم يكن من الواضح ما إذا كانت الأجهزة ستنجو من فحصها بواسطة نظامين في نفس الوقت دون إجراء اختبار فعلي. كان هناك احتمال أن يؤدي الاستقصاء المزدوج المتزامن إلى رفض متكرر للاستجابات من الأجهزة وسنحصل على الكثير من أخطاء عدم توفر الأجهزة، الأمر الذي سيؤدي بدوره إلى عرقلة عمل نظام المراقبة القديم.
قام قسم الشبكات بتشغيل مسارات افتراضية من نموذج أولي جديد لنظام إدارة المباني (BMS) تم نشره في السحابة إلى الأجهزة، وإليكم النتائج:
- الأجهزة المتصلة عبر بروتوكول SNMP لم تنقطع عمليا بسبب الوصول المتزامن،
- واجهت الأجهزة المتصلة عبر بوابات بروتوكول modbas-TCP مشكلات تم حلها من خلال انخفاض معقول في معدل الاستقصاء الخاص بها.
ثم بدأنا نلاحظ كيف يتم بناء نظام جديد أمام أعيننا، وظهرت فيه أجهزة مألوفة لنا بالفعل، ولكن في واجهة مختلفة - مريحة وسريعة ويمكن الوصول إليها حتى من الهاتف.
سنتحدث عما حدث نتيجة لذلك في الجزء الثالث من مقالتنا.
المصدر: www.habr.com