Pada bahagian pertama, kami bercakap tentang sebab kami memutuskan untuk menggantikan sistem BMS lama di pusat data kami dengan yang baharu. Dan bukan sahaja berubah, tetapi berkembang dari awal untuk memenuhi keperluan anda. Di bahagian kedua kami memberitahu anda bagaimana kami melakukannya.
Analisis pasaran
Mengambil kira yang diterangkan dalam hasrat dan keputusan untuk menolak untuk mengemas kini sistem sedia ada, kami menulis spesifikasi teknikal untuk mencari penyelesaian di pasaran dan membuat pertanyaan kepada beberapa syarikat besar yang hanya terlibat dalam penciptaan sistem SCADA industri.
Maklum balas pertama daripada mereka menunjukkan bahawa peneraju pasaran sistem pemantauan terutamanya terus bekerja pada pelayan perkakasan, walaupun proses pemindahan ke awan dalam segmen ini telah pun bermula. Bagi menempah mesin maya, tiada siapa yang menyokong pilihan ini. Selain itu, terdapat perasaan bahawa tiada pembangun yang kelihatan di pasaran malah menunjukkan pemahaman tentang keperluan untuk redundansi: "awan tidak jatuh" adalah jawapan yang paling biasa. Malah, kami ditawarkan untuk meletakkan pemantauan pusat data dalam awan yang terletak secara fizikal di pusat data yang sama.
Di sini kita perlu membuat sedikit penyelewengan tentang proses pemilihan kontraktor. Harga, tentu saja, penting, tetapi semasa sebarang tender untuk pelaksanaan projek yang kompleks, pada peringkat dialog dengan pembekal, anda mula merasakan calon mana yang lebih berminat dan mampu melaksanakannya.
Ini amat ketara pada projek yang kompleks.
Berdasarkan sifat menjelaskan soalan kepada spesifikasi teknikal, kontraktor boleh dibahagikan kepada mereka yang berminat untuk hanya menjual (tekanan standard pengurus jualan dirasai) dan mereka yang berminat untuk membangunkan produk, setelah mendengar dan memahami pelanggan, membuat konstruktif. pindaan kepada spesifikasi teknikal walaupun sebelum pilihan muktamad (walaupun terdapat risiko sebenar untuk menambah baik spesifikasi teknikal orang lain dan kehilangan tender), akhirnya mereka hanya bersedia untuk menerima cabaran profesional dan membuat produk yang baik.
Semua ini membuatkan kami memberi perhatian kepada pemaju tempatan yang agak kecil - kumpulan syarikat Sunline, yang bertindak balas kepada kebanyakan keperluan kami serta-merta dan bersedia untuk melaksanakan semua keperluan berkenaan BMS baharu.
Risiko
Semasa pemain besar cuba memahami apa yang kami mahukan dan menjalankan surat-menyurat santai dengan kami melibatkan pakar peringkat pra-jualan, pemaju tempatan menjadualkan mesyuarat di pejabat kami dengan penyertaan pasukan teknikalnya. Pada mesyuarat ini, kontraktor sekali lagi menunjukkan keinginannya untuk mengambil bahagian dalam projek itu dan, yang paling penting, menerangkan bagaimana sistem yang diperlukan akan dilaksanakan.
Sebelum mesyuarat, kami melihat dua risiko bekerja dengan pasukan yang tidak mempunyai sumber syarikat besar nasional atau antarabangsa di belakangnya:
- Pakar boleh menilai terlalu tinggi keupayaan mereka dan, akibatnya, gagal untuk mengatasinya; sebagai contoh, mereka akan menggunakan perisian yang kompleks atau mereka bentuk algoritma tempahan yang tidak boleh dilaksanakan.
- Selepas projek selesai, pasukan projek mungkin hancur dan, oleh itu, sokongan produk akan terancam.
Untuk meminimumkan risiko ini, kami menjemput pakar pembangunan kami sendiri ke mesyuarat itu. Kakitangan kontraktor yang berpotensi telah ditemu bual secara menyeluruh tentang apa yang berasaskan sistem, cara redundansi dirancang untuk dilaksanakan, dan isu lain di mana kami, sebagai perkhidmatan operasi, tidak cukup cekap.
Keputusan itu positif: seni bina platform BMS sedia ada adalah moden, mudah dan boleh dipercayai, boleh dipertingkatkan, cadangan redundansi dan skim penyegerakan adalah logik dan boleh dilaksanakan.
Risiko pertama telah ditangani. Yang kedua dikecualikan selepas menerima pengesahan daripada kontraktor bahawa mereka bersedia untuk memindahkan kod sumber sistem dan dokumentasi kepada kami, dan juga dengan memilih bahasa pengaturcaraan Python, yang terkenal oleh pakar kami. Ini menjamin kami peluang untuk mengekalkan sistem kami sendiri tanpa sebarang kesulitan dan tempoh latihan pekerja yang panjang sekiranya syarikat pembangunan meninggalkan pasaran.
Kelebihan tambahan platform ialah ia telah dilaksanakan dalam bekas Docker: kernel, antara muka web dan fungsi pangkalan data produk dalam persekitaran ini. Pendekatan ini memberikan banyak kelebihan, termasuk tetapan pratetap untuk kelajuan tertinggi penggunaan penyelesaian berbanding penambahan peranti baharu yang "klasik" dan mudah pada sistem. Prinsip "semua bersama" memudahkan pelaksanaan sistem sebanyak mungkin: hanya bongkar sistem dan anda boleh menggunakannya dengan serta-merta.
Dengan penyelesaian ini, lebih mudah untuk membuat salinan sistem, dan anda boleh memperbaikinya dan melaksanakan peningkatan dalam persekitaran yang berasingan, tanpa menghentikan operasi penyelesaian secara keseluruhan.
Setelah kedua-dua risiko diminimumkan, kontraktor menyediakan CP. Ia merangkumi semua parameter terpenting sistem BMS untuk kami.
Tempahan
Sistem BMS baharu terpaksa ditempatkan di awan, pada mesin maya.
Tiada perkakasan, tiada pelayan dan semua kesulitan serta risiko yang berkaitan dengan model penggunaan ini - penyelesaian awan membolehkan kami menyingkirkannya selama-lamanya. Telah diputuskan bahawa sistem akan beroperasi dalam awan kami di dua tapak pusat data di St. Petersburg dan Moscow. Ini adalah dua sistem berfungsi sepenuhnya yang beroperasi dalam mod siap sedia aktif dengan akses kepada semua pakar yang diberi kuasa.
Kedua-dua sistem menginsuranskan satu sama lain, menyediakan rizab penuh kedua-dua kuasa pengkomputeran dan saluran penghantaran data. Langkah keselamatan tambahan juga telah dikonfigurasikan, termasuk sandaran data dan saluran, sistem, mesin maya secara umum, dan sandaran pangkalan data yang berasingan sekali sebulan (sumber paling berharga dari segi pengurusan dan analisis).
Ambil perhatian bahawa lebihan sebagai pilihan dalam penyelesaian BMS telah dibangunkan khusus untuk permintaan kami. Skim tempahan itu sendiri kelihatan seperti ini:
Sokongan
Perkara yang paling penting untuk pengendalian berkesan penyelesaian BMS ialah sokongan teknikal.
Segala-galanya mudah di sini: sistem baharu akan menelan kos 35 rubel mengikut penunjuk ini. sebulan untuk "tindak balas SLA dalam masa 000 jam", iaitu, 8 x 35 / 000 = $12 setahun. Tahun pertama adalah percuma.
Sebagai perbandingan, mengekalkan BMS lama daripada vendor berharga $18 setahun dengan peningkatan dalam jumlah untuk setiap peranti baharu yang ditambahkan! Pada masa yang sama, syarikat tidak menyediakan pengurus yang berdedikasi; semua interaksi berlaku melalui pengurus jualan yang berminat dengan kami sebagai bakal pembeli dengan penekanan yang sepadan dalam memproses permintaan.
Untuk wang yang lebih murah, kami menerima sokongan produk penuh, dengan pengurus akaun yang akan mengambil bahagian dalam pembangunan produk, dengan satu titik kemasukan, dsb. Sokongan menjadi lebih fleksibel - terima kasih kepada akses terus kepada pembangun untuk pelarasan segera pada mana-mana aspek sistem, penyepaduan melalui API, dsb.
Updates
Menurut CP yang dicadangkan dalam BMS baharu, semua kemas kini termasuk dalam kos sokongan, i.e. tidak memerlukan bayaran tambahan. Pengecualian ialah pembangunan fungsi tambahan melebihi apa yang dinyatakan dalam spesifikasi teknikal.
Sistem lama memerlukan pembayaran untuk kedua-dua kemas kini perisian tegar (seperti Java) dan pembetulan pepijat. Adalah mustahil untuk menolak ini; jika tiada kemas kini, sistem secara keseluruhan "perlahan" disebabkan oleh versi lama komponen dalaman.
Dan, sudah tentu, adalah mustahil untuk mengemas kini perisian tanpa membeli pakej sokongan.
Pendekatan yang fleksibel
Satu lagi keperluan asas berkaitan antara muka. Kami mahu memberikan akses kepadanya melalui pelayar web dari mana-mana sahaja, tanpa kehadiran wajib jurutera di wilayah pusat data. Di samping itu, kami berusaha untuk mencipta antara muka animasi supaya dinamik infrastruktur akan lebih jelas kepada jurutera yang bertugas.
Juga dalam sistem baharu adalah perlu untuk menyediakan sokongan untuk formula untuk mengira operasi penderia maya dalam sistem kejuruteraan - contohnya, untuk pengagihan kuasa elektrik yang optimum merentas rak peralatan. Untuk melakukan ini, anda perlu mempunyai semua operasi matematik biasa yang digunakan untuk penunjuk sensor.
Seterusnya, akses kepada pangkalan data SQL diperlukan dengan keupayaan untuk mengambil daripadanya data yang diperlukan mengenai pengendalian peralatan - iaitu, semua rekod pemantauan dua ribu peranti dan dua ribu sensor maya menjana kira-kira 20 ribu pembolehubah.
Modul perakaunan peralatan rak juga diperlukan, memberikan gambaran grafik susunan peranti dalam setiap unit dengan pengiraan jumlah berat perkakasan, mengekalkan perpustakaan peranti dan maklumat terperinci tentang setiap elemen.
Kelulusan spesifikasi teknikal dan menandatangani perjanjian
Pada masa yang diperlukan untuk memulakan kerja pada sistem baharu, surat-menyurat dengan syarikat "besar" masih jauh daripada membincangkan kos cadangan mereka, jadi kami membandingkan CP yang diterima dengan kos mengemas kini BMS lama (lihat. ), dan hasilnya ia ternyata lebih menarik dari segi harga dan memenuhi keperluan kami.
Pilihan telah dibuat.
Selepas memilih kontraktor, peguam mula merangka perjanjian, dan pasukan teknikal dari kedua-dua pihak mula menggilap spesifikasi teknikal. Seperti yang anda ketahui, spesifikasi teknikal yang terperinci dan cekap adalah asas untuk kejayaan mana-mana kerja. Lebih banyak spesifikasi teknikal yang terdapat dalam spesifikasi teknikal, lebih sedikit kekecewaan seperti "tetapi ini bukan yang kami mahukan."
Saya akan memberikan dua contoh tahap perincian keperluan dalam spesifikasi teknikal:
- Pusat data yang bertugas diberi kuasa untuk menambah peranti baharu pada BMS, selalunya ini ialah PDU. Dalam BMS lama, ini ialah tahap "pentadbir", yang juga membenarkan menukar tetapan pembolehubah semua peranti, dan adalah mustahil untuk memisahkan fungsi. Ini tidak sesuai dengan kami. Dalam versi asas sedia ada platform baharu, skemanya adalah serupa. Kami dengan serta-merta menyatakan dalam terma rujukan bahawa kami ingin memisahkan peranan ini: hanya pekerja yang diberi kuasa harus menukar tetapan, tetapi mereka yang bertugas harus terus dapat menambahkan peranti. Skim ini telah diterima untuk dilaksanakan.
- Dalam mana-mana BMS standard terdapat tiga kategori biasa pemberitahuan: MERAH - mesti dibalas dengan segera, KUNING - boleh diperhatikan, BIRU - "Bermaklumat". Kami secara tradisinya menggunakan makluman biru untuk memantau apabila parameter perniagaan telah melebihi, seperti rak pelanggan melebihi had kapasitinya. Jenis pemberitahuan ini dalam kes kami ditujukan untuk pengurus dan tidak menarik minat perkhidmatan operasi, tetapi dalam BMS lama ia kerap menyumbat senarai insiden aktif dan mengganggu kerja operasi. Kami menganggap logik dan pembezaan warna seluar pemberitahuan berjaya dan mengekalkannya, bagaimanapun, spesifikasi teknikal secara khusus menunjukkan bahawa pemberitahuan "biru" harus, tanpa mengganggu pegawai bertugas, "menuangkan" secara senyap ke bahagian berasingan, di mana ia akan diuruskan oleh pakar komersial.
Dengan tahap perincian yang sama, format untuk membina graf dan menjana laporan, garis besar antara muka, senarai peranti yang perlu dipantau dan banyak perkara lain telah ditetapkan.
Ini adalah kerja yang benar-benar kreatif daripada tiga kumpulan kerja - perkhidmatan pelanggan, yang menentukan keperluan dan syaratnya; pakar teknikal di kedua-dua pihak, yang tugasnya adalah untuk mengubah keadaan ini menjadi dokumentasi teknikal; pasukan pengaturcara kontraktor yang melaksanakan keperluan pelanggan mengikut dokumentasi teknikal yang dibangunkan... Hasilnya, kami menyesuaikan beberapa keperluan kami yang tidak berprinsip kepada kefungsian platform sedia ada, dan kontraktor berusaha untuk menambah sesuatu untuk kami.
Operasi selari dua sistem
Sudah tiba masanya untuk pelaksanaan. Dalam amalan, ini bermakna kami memberi kontraktor peluang untuk menggunakan prototaip BMS dalam awan maya kami dan menyediakan akses rangkaian kepada semua peranti yang memerlukan pemantauan.
Bagaimanapun, sistem baharu itu belum lagi sedia untuk beroperasi. Pada peringkat ini, adalah penting bagi kami untuk mengekalkan pemantauan dalam sistem lama dan pada masa yang sama memberikan akses kepada peranti kepada sistem baharu. Adalah mustahil untuk membina sistem dengan betul tanpa melihat peranti di dalamnya, yang seterusnya tidak boleh dilumpuhkan daripada pemantauan oleh sistem lama.
Sama ada peranti itu boleh menahan soal siasat serentak oleh dua sistem tidak jelas tanpa ujian sebenar. Terdapat kemungkinan bahawa pengundian serentak berganda akan membawa kepada keengganan yang kerap untuk bertindak balas daripada peranti dan kami akan menerima banyak ralat mengenai ketiadaan peranti, yang seterusnya akan menyekat operasi sistem pemantauan lama.
Jabatan rangkaian menjalankan laluan maya daripada prototaip BMS baharu yang digunakan dalam awan ke peranti, dan kami mendapat keputusan:
- peranti yang disambungkan melalui protokol SNMP boleh dikatakan tidak pernah terputus kerana permintaan serentak,
- peranti yang disambungkan melalui get laluan menggunakan protokol modbas-TCP mempunyai masalah yang diselesaikan dengan mengurangkan kekerapan pengundian mereka secara bijak.
Dan kemudian kami mula memerhatikan bagaimana sistem baru sedang dibina di hadapan mata kami, peranti yang sudah biasa kepada kami muncul di dalamnya, tetapi dalam antara muka yang berbeza - mudah, pantas, boleh diakses walaupun dari telefon.
Kami akan memberitahu anda apa yang berlaku pada akhirnya di bahagian ketiga artikel kami.
Sumber: www.habr.com