په لومړۍ برخه کې، موږ تشریح کړه چې ولې موږ پریکړه وکړه چې زموږ په معلوماتو مرکزونو کې زوړ BMS سیسټم په نوي سره بدل کړو. او نه یوازې دا بدل کړو، بلکې د خپلو اړتیاو پوره کولو لپاره یې له سره پراختیا ورکړو. په دویمه برخه کې، موږ به تشریح کړو چې موږ دا څنګه وکړ.
د بازار تحلیل
د پورته ذکر شویو ټکو په پام کې نیولو سره د غوښتنو او د موجوده سیسټم د لوړولو د پریښودو پریکړې په ځواب کې، موږ په بازار کې د حل لارې موندلو لپاره یو مشخصات ولیکل او له څو لویو شرکتونو څخه مو پوښتنې وکړې چې په ځانګړي ډول د صنعتي SCADA سیسټمونو په جوړولو کې بوخت دي.
د دوی له خوا لومړنیو ځوابونو څرګنده کړه چې د څارنې سیسټمونو کې د بازار مشران په عمده توګه په بې فلزي سرورونو کې کار کوي، که څه هم په دې برخه کې کلاوډ ته مهاجرت لا دمخه پیل شوی دی. د مجازی ماشین بیک اپ په اړه، هیڅوک د دې اختیار ملاتړ نه کوي. سربیره پردې، داسې بریښي چې په بازار کې هیڅ مخکښ پراختیا کونکي حتی د بیک اپ اړتیا په اړه پوهه نه ده ښودلې: "کلاوډ نه خرابیږي،" ترټولو عام ځواب و. په اصل کې، له موږ څخه غوښتل شوي وو چې د معلوماتو مرکز څارنه په یوه کلاوډ کې کوربه کړو چې په فزیکي توګه د ورته ډیټا مرکز دننه موقعیت لري.
دلته، د قراردادي د انتخاب پروسې په اړه یو لنډ معلومات اړین دي. البته، قیمت مهم دی، مګر د یوې پیچلې پروژې لپاره د هرې داوطلبۍ په جریان کې، د عرضه کونکو سره د خبرو اترو په جریان کې، تاسو احساس کوئ چې کوم نوماندان ډیر لیوالتیا لري او د هغې پلي کولو توان لري.
دا په ځانګړي ډول په پیچلو پروژو کې د پام وړ دی.
د تخنیکي مشخصاتو په اړه د وضاحت ورکوونکو پوښتنو د ماهیت پراساس، قراردادیان په هغو کسانو ویشل کیدی شي چې یوازې په پلور کې لیوالتیا لري (د پلور مدیر عادي فشار احساس کیږي) او هغه کسان چې د محصول په پراختیا کې لیوالتیا لري، د پیرودونکي غوږ نیسي او پوهیږي، د وروستي انتخاب څخه دمخه تخنیکي مشخصاتو ته رغنده سمونونه راولي (حتی د بل چا د تخنیکي مشخصاتو د ښه کولو او د داوطلبۍ له لاسه ورکولو اصلي خطر سره سره)، او په نهایت کې، هغه کسان چې په ساده ډول د مسلکي ننګونې منلو او ښه محصول رامینځته کولو ته چمتو دي.
دې ټولو موږ ته دا لاره هواره کړه چې خپل پام یو نسبتا کوچني سیمه ایز پراختیا کونکي، د سن لاین ګروپ شرکتونو ته واړوو، چې زموږ ډیری غوښتنو ته یې سمدلاسه ځواب ورکړ او د نوي BMS په اړه زموږ ټولې اړتیاوې پلي کولو ته چمتو و.
خطرونه
پداسې حال کې چې لوی لوبغاړي هڅه کوله چې پوه شي چې موږ څه غواړو او له موږ سره په آرامۍ سره په لیکو کې بوخت وو، د پلور دمخه متخصصین پکې شامل وو، یو ځایی پراختیا کونکي زموږ په دفتر کې د دوی تخنیکي ټیم سره یوه غونډه جوړه کړه. پدې غونډه کې، قراردادي یو ځل بیا په پروژه کې د ګډون لپاره خپله لیوالتیا وښودله او تر ټولو مهم، تشریح یې کړه چې اړین سیسټم به څنګه پلي شي.
د غونډې څخه مخکې، موږ د داسې ټیم سره د کار کولو دوه خطرونه ولیدل چې د لوی ملي یا نړیوال شرکت سرچینې یې تر شا نه وي:
- متخصصینو ممکن خپلې وړتیاوې ډیرې اټکل کړې وي او په پایله کې یې په ساده ډول د مقابلې توان نه درلود؛ د مثال په توګه، دوی ممکن پیچلي سافټویر وکاروي یا د غیر عملي بیک اپ الګوریتمونه ډیزاین کړي.
- د پروژې له پلي کېدو وروسته، د پروژې ټیم ممکن منحل شي او له همدې امله، د محصول ملاتړ ممکن له خطر سره مخ شي.
د دې خطرونو د کمولو لپاره، موږ خپل پراختیایي متخصصین غونډې ته راوبلل. د احتمالي قراردادي کارمندانو سره د سیسټم د بنسټ، د دوی د بې ځایه کیدو د پلي کولو د پلان جوړولو، او نورو مسلو په اړه په بشپړه توګه مرکې وشوې چې موږ، د عملیاتي څانګې په توګه، تخصص نه درلود.
پریکړه مثبته وه: د موجوده BMS پلیټ فارم جوړښت عصري، ساده او د باور وړ دی، نور هم پراختیا موندلی شي، او وړاندیز شوی بې ځایه کیدنه او همغږي کولو سکیم منطقي او فعال دی.
موږ لومړی خطر اداره کړ. موږ دوهم خطر د قراردادي څخه د تایید ترلاسه کولو سره له منځه یوړ چې دوی د سیسټم سرچینې کوډ او اسناد سپارلو ته لیواله دي، او د پایتون غوره کولو سره، چې زموږ متخصصینو ته پیژندل شوې د پروګرام کولو ژبه ده. دا ډاډ ترلاسه کړ چې موږ کولی شو سیسټم پخپله د کومې ستونزې یا اوږدې روزنې دورې پرته وساتو که چیرې پراختیا کونکی بازار پریږدي.
د پلیټ فارم یوه اضافي ګټه په ډاکر کانټینرونو کې د هغې پلي کول وو: کرنل، ویب انٹرفیس، او د محصول ډیټابیس ټول پدې چاپیریال کې کار کوي. دا طریقه ډیری ګټې وړاندې کوي، پشمول د دودیزو حلونو په پرتله د خورا ګړندي ځای پرځای کولو لپاره دمخه تنظیم شوي ترتیبات او سیسټم ته د نوي وسیلو ساده اضافه کول. "ټول په یوه کې" طریقه د سیسټم پلي کول ساده کوي: په ساده ډول سیسټم خلاص کړئ او دا د کارولو لپاره چمتو دی.
دا حل د سیسټم کاپي جوړول اسانه کوي، او دا په جلا چاپیریال کې د بشپړ حل بندولو پرته ښه او لوړ کیدی شي.
وروسته له دې چې دواړه خطرونه کم شول، قراردادي یو وړاندیز وړاندې کړ. دا زموږ لپاره د BMS سیسټم ټول مهم پیرامیټرونه په تفصیل سره بیان کړل.
ریزرویشن
د BMS نوی سیسټم باید په کلاوډ کې، په مجازی ماشین کې موقعیت ولري.
هیڅ هارډویر، هیڅ سرور، او د دې ځای پرځای کولو ماډل سره تړلې ټولې ناخوالې او خطرونه - د کلاوډ حل موږ ته اجازه راکړه چې دوی د تل لپاره له منځه یوسو. پریکړه وشوه چې سیسټم به زموږ په کلاوډ کې په سینټ پیټرزبورګ او مسکو کې د دوو ډیټا سینټر سایټونو کې کار وکړي. دا دوه په بشپړ ډول فعال سیسټمونه به په فعال سټینډ بای حالت کې کار وکړي، چې ټولو مجاز متخصصینو ته د لاسرسي وړ وي.
دواړه سیسټمونه یو بل ملاتړ کوي، د کمپیوټري بریښنا او ډیټا لیږد چینلونو کې بشپړ بې ځایه والی چمتو کوي. اضافي امنیتي تدابیر هم تنظیم شوي، په شمول د معلوماتو او چینلونو، سیسټمونو، او ټول مجازی ماشینونو بیک اپ، او همدارنګه جلا میاشتني ډیټابیس بیک اپ (د مدیریت او تحلیل لپاره ترټولو ارزښتناکه سرچینه).
دا د یادونې وړ ده چې د BMS حل د بې ځایه کیدو ځانګړتیا په ځانګړي ډول زموږ د اړتیاو پوره کولو لپاره رامینځته شوې وه. د بې ځایه کیدو سکیم پخپله داسې ښکاریده:
ملاتړ
د BMS حل د اغیزمن فعالیت لپاره ترټولو مهم اړخ تخنیکي ملاتړ دی.
دا ساده ده: یو نوی سیسټم به موږ ته د "۸ ساعته ځواب" SLA لپاره په میاشت کې ۳۵،۰۰۰ روبله لګښت ولري، یا په کال کې ۳۵،۰۰۰ x ۱۲ / ۸۰ = $۵،۲۵۰. لومړی کال وړیا دی.
په پرتله کولو سره، د پلورونکي د زاړه BMS ملاتړ په کال کې $18,000 لګښت لري، د هر نوي وسیلې لپاره فیس زیاتیږي! سربیره پردې، شرکت یو وقف شوی مدیر نه دی چمتو کړی؛ ټولې اړیکې د پلور مدیر له لارې ترسره شوې چې د احتمالي پیرودونکي په توګه زموږ سره علاقه درلوده او د پوښتنو په سمه توګه اداره کولو تمرکز یې کاوه.
په لږو پیسو سره، موږ د محصول بشپړ ملاتړ ترلاسه کړ، د حساب مدیر سره چې د محصول پراختیا کې ښکیل وو، د ننوتلو یو واحد ځای، او نور ډیر څه. ملاتړ د پام وړ ډیر انعطاف منونکی شو، د سیسټم د عملیاتو هر اړخ ته د چټک سمونونو لپاره پراختیا کونکو ته د مستقیم لاسرسي څخه مننه، د API ادغام، او نور ډیر څه.
اوسمهالونه
د وړاندیز شوي نرخ لیست سره سم، د نوي BMS ټول تازه معلومات د ملاتړ نرخ کې شامل دي، پدې معنی چې هیڅ اضافي لګښت نشته. استثنا د هغه فعالیت پراختیا ده چې په مشخصاتو کې مشخص شوي دي.
زاړه سیسټم د جوړ شوي وړیا سافټویر (لکه جاوا) او د بګ اصلاحاتو لپاره د دواړو تازه معلوماتو لپاره پیسو ته اړتیا درلوده. دا ناگزیر و، او د تازه معلوماتو پرته، سیسټم به په ټولیزه توګه د خپلو داخلي برخو د زړو نسخو له امله ورو شي.
او البته، د ملاتړ کڅوړې له اخیستلو پرته د سافټویر تازه کول ناممکن وو.
انعطاف منونکی چلند
بله مهمه اړتیا د انٹرفیس پورې اړه لري. موږ غوښتل ډاډ ترلاسه کړو چې دا د ویب براوزر له لارې له هر ځای څخه لاسرسی کیدی شي، پرته له دې چې انجینر په ساحه کې شتون ولري. موږ همدارنګه هڅه وکړه چې یو متحرک انٹرفیس رامینځته کړو ترڅو د زیربنا متحرک عملیات د دندې پرمهال انجینرانو لپاره ډیر لید شي.
نوي سیسټم ته د یوټیلټي سیسټمونو کې د مجازی سینسرونو د عملیاتو محاسبه کولو لپاره د فورمولونو ملاتړ کولو ته هم اړتیا وه - د مثال په توګه، د تجهیزاتو په ریکونو کې د بریښنا غوره توزیع کول. دا د سینسر لوستلو لپاره پلي کیدونکي ټولو پیژندل شوي ریاضيکي عملیاتو ته لاسرسی ته اړتیا لري.
بیا، د SQL ډیټابیس ته لاسرسی اړین و، چې د تجهیزاتو د عملیاتو په اړه اړین معلومات بیرته ترلاسه کولو وړتیا ولري - یعنې، د دوه زره وسیلو او دوه زره مجازی سینسرونو لپاره ټول د څارنې ریکارډونه، چې نږدې 20 زره متغیرات تولیدوي.
د ریک نصب شوي تجهیزاتو محاسبې ماډل ته هم اړتیا وه، چې په هر واحد کې د وسیلو موقعیت ګرافیکي استازیتوب چمتو کړي، د هارډویر ټول وزن محاسبه کړي، د وسیلو کتابتون وساتي، او د هر عنصر په اړه مفصل معلومات چمتو کړي.
د تخنیکي مشخصاتو تصویب او د قرارداد لاسلیک کول
په هغه وخت کې چې په نوي سیسټم کار پیل کول اړین وو، د "لویو" شرکتونو سره اړیکې لاهم د دوی د وړاندیزونو لګښت په اړه بحث کولو څخه خورا لرې وې، نو موږ ترلاسه شوي CP د زاړه BMS تازه کولو لګښتونو سره پرتله کړل (وګورئ )، او په پایله کې دا په قیمت کې او زموږ د اړتیاو سره سم ډیر زړه راښکونکی شو.
انتخاب وشو.
د قراردادي له غوره کولو وروسته، وکیلانو د قرارداد مسوده پیل کړه، او د دواړو خواوو تخنیکي ټیمونو د مشخصاتو اصلاح پیل کړه. لکه څنګه چې موږ پوهیږو، مفصل او ښه لیکل شوي مشخصات د هرې پروژې د بریالیتوب لپاره بنسټ دی. څومره چې مشخصات ډیر مشخص وي، هغومره لږ مایوسي لکه "مګر دا هغه څه ندي چې موږ یې غوښتل."
زه به په مشخصاتو کې د اړتیاوو د تفصیل د کچې دوه مثالونه درکړم:
- د معلوماتو مرکز دندو افسرانو ته اجازه ورکړل شوې ده چې BMS ته نوي وسایل اضافه کړي، ډیری وختونه PDUs. په زاړه BMS کې، دا د "مدیر" کچه وه، کوم چې د نورو شیانو په منځ کې، د ټولو وسیلو متغیر ترتیباتو بدلولو ته اجازه ورکړه، او د دې دندو جلا کول ناممکن وو. دا زموږ سره مناسب نه و. د نوي پلیټ فارم موجوده اساسي نسخه ورته ترتیب درلود. موږ سمدلاسه په مشخصاتو کې مشخص کړل چې موږ غواړو دا رولونه جلا کړو: یوازې مجاز کارمندان باید تنظیمات بدل کړي، مګر دندو افسران باید لاهم وکولی شي وسایل اضافه کړي. دا ترتیب د پلي کولو لپاره غوره شوی و.
- هر معیاري BMS د خبرتیا درې ځانګړي کټګورۍ لري: سور - سمدستي عمل ته اړتیا لري، ژیړ - څارل کیدی شي، او نیلي - "معلوماتي". موږ په دودیز ډول د سوداګریزو زیاتوالي څارلو لپاره "نیلي" خبرتیاوې کارولې، لکه د پیرودونکي د ریک بریښنا حد څخه ډیریدل. زموږ په قضیه کې، دا ډول خبرتیا د مدیرانو لپاره وه او د عملیاتو لپاره علاقه نه درلوده، مګر په زاړه BMS کې، دا په منظم ډول د فعال پیښو لیست ګډوډ کړ او د عملیاتي کار سره مداخله وکړه. موږ منطق او رنګ کوډ شوي خبرتیاوې بریالۍ وګڼلې او هغه مو وساتلې، مګر په مشخصاتو کې، موږ په ځانګړي ډول مشخص کړل چې "نیلي" خبرتیاوې باید په خاموشۍ سره په جلا برخه کې "غورځول" شي، چیرې چې دوی به د سوداګریزو متخصصینو لخوا اداره شي، پرته له دې چې د دندې پر مهال کارمندانو پام واړوي.
د ګرافونو د جوړولو او راپورونو د تولید لپاره بڼې، د انٹرفیس بڼې، د هغو وسیلو لیست چې باید وڅارل شي، او ډیری نور شیان په ورته توضیحاتو سره تشریح شوي.
دا یوه رښتیا هم تخلیقي هڅه وه چې درې کاري ډلې پکې شاملې وې: د پیرودونکو خدمت، چې خپلې اړتیاوې او شرایط یې ټاکل؛ د دواړو خواوو تخنیکي متخصصین، چې دنده یې دا وه چې دا شرایط په تخنیکي اسنادو کې وژباړي؛ او د قراردادي د پروګرام کونکو ټیم، چې د پرمختللي تخنیکي اسنادو په کارولو سره یې د پیرودونکي اړتیاوې پلي کړې. په نهایت کې، موږ خپل ځینې غیر ضروري اړتیاوې د موجوده پلیټ فارم فعالیت سره تطبیق کړې، پداسې حال کې چې قراردادي موافقه وکړه چې نور زموږ لپاره تنظیم کړي.
د دوو سیسټمونو موازي عملیات
دا د پلي کولو وخت و. په عمل کې، دا پدې مانا وه چې قراردادي ته دا توان ورکړل شو چې زموږ په مجازی کلاوډ کې د BMS پروټوټایپ ځای په ځای کړي او ټولو هغو وسیلو ته د شبکې لاسرسی چمتو کړي چې څارنې ته اړتیا لري.
په ورته وخت کې، نوی سیسټم لا د کار لپاره چمتو نه و. پدې مرحله کې، دا زموږ لپاره مهمه وه چې په زاړه سیسټم کې څارنه وساتو پداسې حال کې چې په ورته وخت کې نوي سیسټم ته وسایلو ته لاسرسی ورکړو. دا ناممکنه ده چې د سیسټم دننه وسایلو پیژندلو پرته په سمه توګه جوړ کړو، کوم چې په پایله کې د زاړه سیسټم لخوا د څارنې څخه غیر فعال کیدی نشي.
د حقیقي نړۍ ازموینې پرته، دا روښانه نه وه چې ایا وسایل به د دوو سیسټمونو لخوا په ورته وخت کې د رایې ورکولو سره مقاومت وکړي. دا خطر شتون درلود چې دوه ځله په ورته وخت کې رایه ورکول به د وسیلو د بار بار ردولو او د وسیلو د نه شتون ډیری غلطیو لامل شي، کوم چې به په پایله کې د زاړه څارنې سیسټم بند کړي.
د شبکې څانګې د نوي BMS پروټوټایپ څخه چې په کلاوډ کې ځای پر ځای شوی و، وسیلو ته مجازی لارې چلولې، او موږ لاندې پایلې ترلاسه کړې:
- د SNMP پروتوکول له لارې وصل شوي وسایل تقریبا هیڅکله د ورته غوښتنو له امله د قطع کیدو تجربه نه کوي،
- هغه وسایل چې د modbas-TCP پروتوکولونو په کارولو سره د دروازو له لارې وصل شوي وو ستونزې درلودې چې د دوی د رایې ورکولو فریکونسۍ په هوښیارۍ سره کمولو سره حل شوې.
او بیا موږ لیدل پیل کړل چې څنګه زموږ د سترګو په وړاندې یو نوی سیسټم جوړیږي، د هغو وسایلو سره چې موږ دمخه ورسره بلد وو، مګر په یو مختلف انٹرفیس کې - اسانه، ګړندی، او حتی د تلیفون څخه د لاسرسي وړ.
موږ به تاسو ته د خپلې مقالې په دریمه برخه کې د وروستۍ پایلې په اړه ووایو.
سرچینه: www.habr.com
