🌗 🚄 🤛🏿 Pemantauan di pusat data: bagaimana kami mengubah BMS lama ke yang baru. Bagian 2 👵 ↕️ 🌄

Pada bagian pertama, kami berbicara tentang mengapa kami memutuskan untuk mengubah sistem BMS lama di pusat data kami menjadi yang baru. Dan tidak hanya berubah, tetapi berkembang dari awal agar sesuai dengan kebutuhan Anda. Pada bagian kedua kami memberi tahu bagaimana kami melakukannya.

Analisis Pasar

Berdasarkan keinginan dan keputusan yang diuraikan di bagian pertama , untuk menolak memperbarui sistem yang ada, kami menulis pernyataan kerja untuk menemukan solusi di pasar dan mengajukan pertanyaan ke beberapa perusahaan besar yang hanya terlibat dalam pembuatan sistem industri SCADA.

Jawaban pertama dari mereka menunjukkan bahwa para pemimpin pasar untuk sistem pemantauan terutama terus bekerja pada server besi, meskipun proses migrasi ke awan di segmen ini telah dimulai. Adapun mesin virtual cadangan - tidak ada yang mendukung opsi ini. Selain itu, ada perasaan bahwa tidak ada pengembang yang terlihat di pasar bahkan menunjukkan pemahaman tentang perlunya redundansi: "awan tidak jatuh," adalah jawaban yang paling sering. Bahkan, kami ditawari untuk menempatkan pemantauan pusat data di awan yang secara fisik terletak di pusat data yang sama.

Di sini perlu dilakukan penyimpangan kecil tentang proses pemilihan kontraktor. Harga, tentu saja, penting, tetapi selama tender untuk implementasi proyek yang kompleks, pada tahap dialog dengan pemasok, Anda mulai merasakan kandidat mana yang lebih tertarik dan mampu mengimplementasikannya.

Ini terutama terlihat pada proyek-proyek kompleks.

Dengan sifat pertanyaan klarifikasi untuk TK, adalah mungkin untuk membagi kontraktor menjadi yang tertarik hanya untuk menjual (tekanan standar dari manajer penjualan dirasakan) dan mereka yang tertarik untuk mengembangkan produk, setelah mendengar dan memahami pelanggan, untuk membuat perubahan yang konstruktif terhadap spesifikasi teknis bahkan sebelum pilihan akhir (bahkan meskipun sebenarnya risiko untuk meningkatkan TK orang lain dan kehilangan tender), pada akhirnya, hanya siap untuk menerima tantangan profesional dan membuat produk yang bagus.

Semua ini membuat kami memperhatikan pengembang lokal yang relatif kecil - grup perusahaan Sunline, yang segera menanggapi sebagian besar persyaratan kami dan siap untuk memenuhi semua kebutuhan terkait BMS baru.

Risikonya

Sementara para pemain besar berusaha memahami apa yang kami inginkan, dan kami berada dalam korespondensi santai dengan bantuan spesialis pra-penjualan, seorang pengembang lokal membuat janji di kantor kami dengan partisipasi tim teknisnya. Pada pertemuan ini, kontraktor sekali lagi menunjukkan keinginan untuk berpartisipasi dalam proyek dan - yang paling penting - menjelaskan bagaimana sistem yang diperlukan akan dilaksanakan.

Sebelum pertemuan, kami melihat dua risiko bekerja dengan tim yang tidak memiliki sumber daya dari perusahaan besar nasional atau internasional:

Spesialis dapat melebih-lebihkan kemampuan mereka dan sebagai hasilnya tidak dapat mengatasi, misalnya, mereka akan menggunakan perangkat lunak canggih atau merancang algoritma cadangan yang tidak praktis.
Setelah implementasi proyek, tim proyek dapat bubar dan, oleh karena itu, dukungan produk akan dalam bahaya.

Untuk meminimalkan risiko ini, kami mengundang spesialis pengembangan kami sendiri ke pertemuan tersebut. Karyawan dari kontraktor potensial diwawancarai secara menyeluruh tentang sistem berdasarkan apa, bagaimana direncanakan untuk melaksanakan pemesanan, dan pada masalah lain di mana kita, sebagai layanan operasi, tidak cukup kompeten.

Putusan itu positif: arsitektur platform BMS yang ada modern, sederhana dan dapat diandalkan, dapat diselesaikan, skema pencadangan dan sinkronisasi yang diusulkan adalah logis dan efisien.

Mereka mengatasi risiko pertama. Mereka mengecualikan yang kedua, setelah menerima konfirmasi dari kontraktor bahwa mereka siap memberi kami kode sumber untuk sistem dan dokumentasi, serta memilih bahasa pemrograman Python, yang terkenal dengan spesialis kami. Ini menjamin kami kesempatan untuk mempertahankan sistem kami sendiri tanpa kesulitan dan pelatihan jangka panjang bagi karyawan jika perusahaan pengembang meninggalkan pasar.

Keuntungan tambahan dari platform adalah bahwa platform ini diimplementasikan dalam wadah Docker: di lingkungan ini, kernel, antarmuka web dan fungsi basis data produk. Pendekatan ini memberikan banyak keuntungan, termasuk pengaturan preset untuk kecepatan penyebaran solusi tertinggi dibandingkan dengan "klasik" dan penambahan sederhana perangkat baru ke sistem. Prinsip "semua bersama" menyederhanakan implementasi sistem sebanyak mungkin: itu cukup untuk membongkar sistem dan Anda dapat segera mengoperasikannya.

Dengan solusi seperti itu, lebih mudah untuk membuat salinan sistem, dan dimungkinkan untuk memperbaikinya dan mengimplementasikan peningkatan di lingkungan yang terpisah, tanpa menghentikan solusi secara keseluruhan.

Setelah kedua risiko diminimalkan, kontraktor memberikan KP. Itu berhasil semua parameter paling penting dari sistem BMS bagi kami.

Reservasi

Sistem BMS baru seharusnya berada di cloud pada mesin virtual.

Tidak ada perangkat keras, tidak ada server dan semua ketidaknyamanan dan risiko yang terkait dengan model penyebaran ini - solusi cloud memungkinkan kami untuk menyingkirkannya selamanya. Diputuskan bahwa sistem akan bekerja di cloud kami di dua situs pusat data di St. Petersburg dan Moskow. Ini adalah dua sistem yang berfungsi penuh yang beroperasi dalam mode siaga aktif dengan akses untuk semua spesialis yang berwenang.

Kedua sistem saling mengasuransikan, menyediakan cadangan penuh untuk daya komputasi dan saluran transmisi data. Langkah-langkah keamanan tambahan juga telah disiapkan, termasuk mencadangkan data dan saluran, sistem, mesin virtual secara umum, dan cadangan basis data terpisah sebulan sekali (sumber daya paling berharga dalam perspektif manajemen dan analisis).

Perhatikan bahwa redundansi sebagai opsi dari solusi BMS dikembangkan khusus untuk permintaan kami. Skema pencadangan itu sendiri terlihat seperti ini:

Dukung

Poin paling penting untuk operasi efektif dari solusi BMS adalah dukungan teknis.

Semuanya sederhana di sini: sistem baru akan menelan biaya 35.000 rubel pada indikator ini. per bulan untuk SLA "respons dalam 8 jam", yaitu, 35.000 x 12/80 = $ 5.250 per tahun. Tahun pertama gratis.

Sebagai perbandingan: dukungan BMS lama dari vendor berharga $ 18.000 dolar per tahun dengan peningkatan jumlah untuk setiap perangkat baru yang ditambahkan! Pada saat yang sama, perusahaan tidak menyediakan manajer yang berdedikasi, semua interaksi terjadi melalui manajer penjualan yang tertarik pada kami sebagai pembeli potensial dengan penekanan yang sesuai dalam memproses permintaan.

Untuk lebih sedikit uang, kami menerima dukungan produk lengkap, dengan manajer akun yang akan mengambil bagian dalam pengembangan produk, dengan satu titik masuk, dll. Dukungan menjadi jauh lebih fleksibel - berkat akses langsung ke pengembang untuk penyesuaian operasional pada setiap aspek sistem, integrasi melalui API, dll.

Pembaruan

Menurut usulan KP dalam BMS baru, semua pembaruan termasuk dalam biaya dukungan, mis. tidak memerlukan pembayaran tambahan. Pengecualian adalah pengembangan fungsionalitas tambahan di luar yang ditentukan dalam Kerangka Acuan.

Sistem lama mengasumsikan pembayaran untuk memperbarui firmware perangkat lunak bebas (seperti Java) dan untuk memperbaiki bug. Tidak mungkin untuk menolak ini, karena tidak adanya pembaruan sistem secara keseluruhan "melambat" karena versi lama komponen internal.

Dan, tentu saja, tidak mungkin untuk memperbarui perangkat lunak tanpa membeli paket dukungan.

Pendekatan yang fleksibel

Persyaratan mendasar lainnya menyangkut antarmuka. Kami ingin memberikan akses ke sana melalui peramban web dari mana saja, tanpa kehadiran seorang insinyur di pusat data. Selain itu, kami berusaha keras untuk membuat antarmuka animasi, sehingga dinamika fungsi infrastruktur lebih terlihat oleh para insinyur yang bertugas.

Juga dalam sistem baru, perlu untuk memberikan dukungan untuk formula untuk menghitung operasi sensor virtual dalam sistem rekayasa - misalnya, untuk distribusi daya listrik yang optimal di antara rak dengan peralatan. Untuk melakukan ini, Anda harus memiliki semua operasi matematika biasa yang berlaku untuk indikator sensor.

Selanjutnya, akses ke database SQL diperlukan dengan kemampuan untuk mengambil darinya data yang diperlukan tentang pengoperasian peralatan - yaitu, semua catatan tentang pemantauan dua ribu perangkat dan dua ribu sensor virtual menghasilkan sekitar 20 ribu variabel.

Kami juga membutuhkan modul untuk peralatan akuntansi di rak, memberikan representasi grafis dari lokasi perangkat di masing-masing unit dengan perhitungan berat total perangkat keras, memelihara perpustakaan perangkat, dan informasi terperinci tentang setiap elemen.

Harmonisasi TK dan penandatanganan perjanjian

Pada saat itu, ketika perlu untuk mulai bekerja pada sistem baru, korespondensi dengan perusahaan "besar" masih sangat jauh dari membahas biaya proposal mereka, jadi kami membandingkan KP yang diterima dengan biaya memperbarui BMS lama (lihat bagian pertama ), dan Hasilnya, ternyata lebih menarik dalam harga dan sesuai dengan persyaratan kami.

Pilihan telah dibuat.

Setelah memilih kontraktor, pengacara mulai menyusun kontrak, dan tim teknis di kedua sisi menyempurnakan spesifikasi teknis. Seperti yang Anda ketahui, TK yang terperinci dan kompeten adalah dasar untuk keberhasilan setiap pekerjaan. Semakin spesifik dalam TK, semakin sedikit kekecewaan seperti "tapi kami tidak menyukainya".

Saya akan memberikan dua contoh tingkat detail persyaratan dalam TK:

BMS , PDU. BMS «», , . . . , : , . .
BMS : – , – , – «». «» , , . , BMS . , , «» , , «» , .

Dengan tingkat detail yang sama, format bagan dan pelaporan, garis besar antarmuka, daftar perangkat yang perlu dipantau, dan banyak hal lain yang ditentukan.

Itu adalah karya yang benar-benar kreatif dari tiga kelompok kerja - layanan pelanggan, yang menentukan persyaratan dan ketentuannya; spesialis teknis dari kedua belah pihak yang bertugas mengubah kondisi ini menjadi dokumentasi teknis; tim pemrogram kontraktor yang mengimplementasikan persyaratan pelanggan untuk dokumentasi teknis yang dikembangkan ... Sebagai hasilnya, kami menyesuaikan beberapa persyaratan kami yang tidak berprinsip pada fungsi platform yang ada, sesuatu yang dilakukan kontraktor untuk ditambahkan bagi kami.

Operasi paralel dari dua sistem

Sudah waktunya untuk implementasi. Dalam praktiknya, ini berarti bahwa kami memberi kontraktor kesempatan untuk menggunakan prototipe BMS di cloud virtual kami dan menyediakan akses jaringan ke semua perangkat yang membutuhkan pemantauan.

Apalagi sistem baru itu belum siap untuk beroperasi. Pada tahap ini, penting bagi kita untuk menjaga pemantauan dalam sistem yang lama dan pada saat yang sama memberikan akses ke perangkat dari sistem yang baru. Tidak mungkin untuk membangun sistem secara normal tanpa melihat perangkat di dalamnya, yang pada gilirannya tidak dapat terputus dari pemantauan oleh sistem yang lama.

Apakah perangkat dapat menahan pemungutan suara simultan oleh dua sistem tidak jelas tanpa tes nyata. Ada kemungkinan bahwa pemungutan suara ganda secara simultan akan menyebabkan penolakan sering terhadap respons dari perangkat dan kami akan menerima banyak kesalahan karena tidak tersedianya perangkat, yang pada gilirannya akan memblokir pengoperasian sistem pemantauan yang lama.

Departemen jaringan melemparkan rute virtual dari prototipe BMS baru yang digunakan di cloud ke perangkat, dan kami mendapatkan hasilnya:

perangkat yang terhubung melalui protokol SNMP praktis tidak jatuh ke putuskan karena panggilan simultan,
perangkat yang terhubung melalui gateway menggunakan protokol modbas-TCP memiliki masalah yang diselesaikan dengan pengurangan yang wajar dalam frekuensi polling mereka.

Dan kemudian kita mulai mengamati bagaimana sistem baru sedang dibangun di depan mata kita, perangkat yang sudah kita kenal muncul di dalamnya, tetapi dalam antarmuka yang berbeda - nyaman, cepat, dapat diakses bahkan dari telepon.

Kami akan berbicara tentang apa yang terjadi sebagai akibat di bagian ketiga artikel kami.

Pemantauan di pusat data: bagaimana kami mengubah BMS lama ke yang baru. Bagian 2