Ing bagean pisanan, kita ngomong babagan kenapa kita mutusake ngganti sistem BMS lawas ing pusat data kita karo sing anyar. Lan ora mung ngganti, nanging berkembang saka ngeruk kanggo cocog karo kabutuhan. Ing bagean kapindho kita pitutur marang kowe carane kita nindakaken.
Analisis pasar
Njupuk menyang akun sing diterangake ing wishes lan kaputusan kanggo nolak nganyari sistem sing wis ana, kita wrote specification technical kanggo nemokake solusi ing pasar lan nggawe pitakonan kanggo sawetara perusahaan gedhe mung melu nggawe sistem SCADA industri.
Tanggapan sing sepisanan saka wong-wong mau nuduhake manawa pimpinan pasar sistem pemantauan utamane terus nggarap server hardware, sanajan proses migrasi menyang awan ing segmen iki wis diwiwiti. Kanggo reservasi mesin virtual, ora ana sing ndhukung pilihan iki. Kajaba iku, ana perasaan yen ora ana pangembang sing katon ing pasar malah nuduhake pangerten babagan kabutuhan redundansi: "mega ora tiba" minangka jawaban sing paling umum. Nyatane, kita ditawakake kanggo ngawasi pusat data ing awan sing dumunung ing pusat data sing padha.
Ing kene kita kudu nggawe digression cilik babagan proses milih kontraktor. Price, mesthi, prakara, nanging ing sembarang tender kanggo implementasine saka project Komplek, ing tataran dialog karo supplier, sampeyan bakal miwiti kanggo aran kang calon luwih kasengsem lan saged ngleksanakake.
Iki utamané katon ing proyek Komplek.
Adhedhasar sifat njlentrehake pitakonan babagan spesifikasi teknis, kontraktor bisa dipérang dadi sing kasengsem mung adol (tekanan standar manajer penjualan dirasakake) lan sing kasengsem ngembangake produk, sawise krungu lan ngerti pelanggan, nggawe konstruktif. amandemen kanggo specifications technical malah sadurunge pilihan final (sanajan nyata resiko nambah specifications technical wong liya lan ilang tender), ing pungkasan padha mung siap kanggo nampa tantangan profesional lan nggawe produk apik.
Kabeh iki nggawe kita menehi perhatian marang pangembang lokal sing relatif cilik - klompok perusahaan Sunline, sing langsung nanggapi sebagian besar syarat lan siap ngetrapake kabeh kabutuhan babagan BMS anyar.
Risiko
Nalika pemain gedhe nyoba ngerti apa sing dikarepake lan nindakake korespondensi santai karo kita sing nglibatake spesialis tingkat pra-sale, pangembang lokal nggawe rapat ing kantor kita kanthi partisipasi tim teknis. Ing rapat iki, kontraktor maneh nuduhake kepinginan kanggo melu proyek kasebut lan, sing paling penting, nerangake carane sistem sing dibutuhake bakal ditindakake.
Sadurunge rapat kasebut, kita ndeleng rong risiko nggarap tim sing ora duwe sumber daya perusahaan nasional utawa internasional sing gedhe ing mburi:
- Spesialis bisa ngira-ngira kemampuane lan, minangka asil, mung gagal ngatasi; contone, dheweke bakal nggunakake piranti lunak rumit utawa ngrancang algoritma reservasi sing ora bisa ditindakake.
- Sawise proyek rampung, tim proyek bisa disintegrasi lan mulane, dhukungan produk bakal ana ing bebaya.
Kanggo nyilikake risiko kasebut, kita ngundang spesialis pangembangan dhewe menyang rapat kasebut. Karyawan kontraktor potensial diwawancarai kanthi lengkap babagan apa sistem kasebut adhedhasar, carane redundansi direncanakake bakal ditindakake, lan masalah liyane sing kita, minangka layanan operasi, ora cukup kompeten.
Putusan kasebut positif: arsitektur platform BMS sing ana modern, prasaja lan dipercaya, bisa ditingkatake, rencana redundansi lan sinkronisasi sing diusulake logis lan bisa ditindakake.
Resiko pisanan ditangani. Kapindho dikecualekake sawise nampa konfirmasi saka kontraktor yen dheweke siap nransfer kode sumber sistem lan dokumentasi kanggo kita, lan uga kanthi milih basa pemrograman Python, sing wis dikenal karo spesialis kita. Iki njamin kita kesempatan kanggo njaga sistem kasebut dhewe tanpa kesulitan lan latihan karyawan sing suwe nalika perusahaan pangembangan ninggalake pasar.
Kauntungan tambahan saka platform kasebut yaiku ditindakake ing wadhah Docker: kernel, antarmuka web lan fungsi database produk ing lingkungan iki. Pendekatan iki nyedhiyakake akeh kaluwihan, kalebu setelan prasetel kanggo kacepetan paling dhuwur saka penyebaran solusi dibandhingake karo tambahan "klasik" lan gampang saka piranti anyar kanggo sistem. Prinsip "kabeh bebarengan" nyederhanakake implementasine sistem sabisa-bisa: mung mbongkar sistem lan sampeyan bisa langsung nggunakake.
Kanthi solusi iki, luwih gampang kanggo nggawe salinan sistem, lan sampeyan bisa nambah lan ngleksanakake nganyarke ing lingkungan kapisah, tanpa mungkasi operasi saka solusi minangka kabèh.
Sawise loro risiko diminimalisir, kontraktor nyedhiyakake CP. Iki kalebu kabeh paramèter sing paling penting ing sistem BMS kanggo kita.
Reservasi
Sistem BMS anyar kudu dumunung ing méga, ing mesin virtual.
Ora ana hardware, ora ana server lan kabeh ora nyaman lan risiko sing ana gandhengane karo model penyebaran iki - solusi awan ngidini kita nyingkirake selawase. Diputusake yen sistem kasebut bakal digunakake ing awan kita ing rong situs pusat data ing St. Petersburg lan Moskow. Iki minangka rong sistem kanthi fungsi sing beroperasi ing mode siyaga aktif kanthi akses menyang kabeh spesialis sing sah.
Sistem loro kasebut ngasuransiake saben liyane, nyedhiyakake cadangan lengkap kanggo daya komputasi lan saluran transmisi data. Langkah-langkah keamanan tambahan uga wis dikonfigurasi, kalebu serep data lan saluran, sistem, mesin virtual umume, lan serep basis data sing kapisah sapisan sasi (sumber daya paling larang babagan manajemen lan analisis).
Elinga yen redundansi minangka pilihan ing solusi BMS dikembangake khusus kanggo panyuwunan kita. Skema reservasi dhewe katon kaya iki:
support
Titik paling penting kanggo operasi efektif solusi BMS yaiku dhukungan teknis.
Kabeh gampang ing kene: sistem anyar bakal regane 35 rubel miturut indikator iki. saben sasi kanggo SLA "respon ing 000 jam", sing, 8 x 35 / 000 = $12 saben taun. Taun pisanan gratis.
Kanggo mbandhingake, njaga BMS lawas saka vendor biaya $ 18 saben taun kanthi nambah jumlah kanggo saben piranti anyar sing ditambahake! Ing wektu sing padha, perusahaan ora nyedhiyakake manajer sing darmabakti, kabeh interaksi ditindakake liwat manajer penjualan sing kasengsem karo kita minangka panuku potensial kanthi penekanan sing cocog ing proses panjaluk.
Kanggo dhuwit kurang, kita nampa dhukungan produk lengkap, karo manajer akun sing bakal melu ing pangembangan produk, karo siji titik entri, etc. Dhukungan dadi luwih fleksibel - amarga akses langsung menyang pangembang kanggo pangaturan cepet menyang aspek apa wae sistem, integrasi liwat API, lsp.
Update
Miturut CP sing diusulake ing BMS anyar, kabeh nganyari kalebu ing biaya dhukungan, yaiku. ora mbutuhake pembayaran tambahan. Pangecualian yaiku pangembangan fungsi tambahan ngluwihi sing ditemtokake ing spesifikasi teknis.
Sistem lawas mbutuhake pembayaran kanggo nganyari perangkat kukuh (kayata Jawa) lan ndandani bug. Ora mungkin nolak iki; yen ora ana nganyari, sistem kasebut "kalem" amarga versi lawas saka komponen internal.
Lan, mesthi, ora bisa nganyari piranti lunak tanpa tuku paket dhukungan.
Pendekatan fleksibel
Syarat dhasar liyane yaiku antarmuka. We wanted kanggo nyedhiyani akses menyang liwat browser web saka ngendi wae, tanpa ngarsane wajib saka engineer ing tlatah pusat data. Kajaba iku, kita ngupaya nggawe antarmuka animasi supaya dinamika infrastruktur bakal luwih jelas kanggo para insinyur sing tugas.
Uga ing sistem anyar iku perlu kanggo nyedhiyani support kanggo rumus kanggo ngitung operasi saka sensor virtual ing sistem engineering - contone, kanggo distribusi optimal saka daya listrik ing rak peralatan. Kanggo nindakake iki, sampeyan kudu duwe kabeh operasi matematika biasa sing ditrapake kanggo indikator sensor.
Sabanjure, akses menyang database SQL dibutuhake kanthi kemampuan kanggo njupuk data sing dibutuhake babagan operasi peralatan - yaiku, kabeh rekaman pemantauan rong ewu piranti lan rong ewu sensor virtual sing ngasilake kira-kira 20 ewu variabel.
Modul akuntansi peralatan rak uga dibutuhake, nyedhiyakake perwakilan grafis saka susunan piranti ing saben unit kanthi pitungan bobot total hardware, njaga perpustakaan piranti lan informasi rinci babagan saben unsur.
Persetujuan spesifikasi teknis lan penandatanganan persetujuan
Nalika sampeyan kudu miwiti nggarap sistem anyar, korespondensi karo perusahaan "gedhe" isih adoh banget saka ngrembug babagan biaya proposal, mula kita mbandhingake CP sing ditampa karo biaya nganyari BMS lawas (ndeleng. ), lan minangka asil dadi luwih atraktif ing rega lan nyukupi syarat kita.
Pilihan wis digawe.
Sawise milih kontraktor, pengacara wiwit nggawe persetujuan, lan tim teknis saka loro-lorone wiwit polishing spesifikasi teknis. Kaya sing sampeyan ngerteni, spesifikasi teknis sing rinci lan kompeten minangka dhasar kanggo sukses karya apa wae. Sing luwih spesifik ana ing spesifikasi teknis, kurang kuciwane kaya "nanging iki dudu sing dikarepake."
Aku bakal menehi rong conto tingkat rincian syarat ing spesifikasi teknis:
- Pusat data sing tugas diwenehake kanggo nambah piranti anyar menyang BMS, sing paling kerep yaiku PDU. Ing BMS lawas, iki minangka level "administrator", sing uga ngidini ngganti setelan variabel kabeh piranti, lan ora bisa misahake fungsi kasebut. Iki ora cocog karo kita. Ing versi dhasar platform anyar sing ana, skema kasebut padha. Kita langsung nunjukake ing syarat-syarat referensi yen kita pengin misahake peran kasebut: mung karyawan sing sah kudu ngganti setelan kasebut, nanging sing tugas kudu terus bisa nambah piranti. Skema iki ditampa kanggo implementasine.
- Ing BMS standar ana telung kategori khas kabar: RED - kudu langsung ditanggapi, KUNING - bisa diamati, BIRU - "Informasi". Kita biasane nggunakake tandha biru kanggo ngawasi nalika paramèter bisnis wis ngluwihi, kayata rak pelanggan ngluwihi watesan kapasitas. Jenis kabar iki ing kasus kita ditujokake kanggo manajer lan ora dadi kapentingan kanggo layanan operasi, nanging ing BMS lawas, kanthi rutin nyumbat dhaptar kedadeyan aktif lan ngganggu karya operasional. Kita nganggep logika lan diferensiasi warna celana kabar sing sukses lan tetep, nanging spesifikasi teknis khusus nuduhake manawa kabar "biru" kudu, tanpa ngganggu petugas tugas, kanthi meneng "diwutahake" menyang bagean sing kapisah, ing ngendi dheweke bakal ditangani dening spesialis komersial.
Kanthi tingkat rinci sing padha, format kanggo nggawe grafik lan ngasilake laporan, garis antarmuka, dhaptar piranti sing kudu dipantau, lan liya-liyane.
Iki minangka karya saestu kreatif saka telung klompok kerja - layanan pelanggan, sing nemtokake syarat lan kahanan; spesialis teknis ing loro-lorone, sing tugas kanggo ngowahi kondisi kasebut dadi dokumentasi teknis; tim kontraktor programer sing ngleksanakake syarat customer miturut dokumentasi technical dikembangaké ... Akibaté, kita dicocogake sawetara syarat unprincipled kanggo fungsi saka platform ana, lan contractor nindakake kanggo nambah soko kanggo kita.
Operasi paralel saka rong sistem
Iku wektu kanggo implementasine. Ing laku, iki tegese kita menehi kontraktor kesempatan kanggo masang prototipe BMS ing maya virtual kita lan nyedhiyakake akses jaringan menyang kabeh piranti sing mbutuhake pemantauan.
Nanging, sistem anyar iki durung siap kanggo operasi. Ing tahap iki, penting kanggo kita njaga pemantauan ing sistem lawas lan ing wektu sing padha menehi akses menyang piranti menyang sistem anyar. Ora mungkin mbangun sistem kanthi bener tanpa ndeleng piranti kasebut, sing ora bisa dipateni saka ngawasi sistem lawas.
Apa piranti bisa nahan interogasi simultan dening rong sistem ora jelas tanpa tes nyata. Ana kemungkinan polling bebarengan kaping pindho bakal nyebabake asring nolak nanggapi saka piranti lan kita bakal nampa akeh kesalahan babagan ora kasedhiya piranti, sing bakal ngalangi operasi sistem pemantauan lawas.
Departemen jaringan mbukak rute virtual saka prototipe BMS anyar sing disebarake ing awan menyang piranti kasebut, lan entuk asil:
- piranti sing disambungake liwat protokol SNMP praktis ora nate pedhot amarga panjalukan bebarengan,
- piranti sing disambungake liwat gateways nggunakake protokol modbas-TCP wis masalah sing ditanggulangi dening intelligently ngurangi frekuensi polling sing.
Banjur kita wiwit mirsani carane sistem anyar dibangun ing ngarep kita, katon ing piranti sing wis menowo kanggo kita, nanging ing antarmuka beda - trep, cepet, diakses malah saka telpon.
Kita bakal ngandhani apa sing kedadeyan ing pungkasan ing bagean katelu saka artikel kita.
Source: www.habr.com