Pada bagian pertama, kami membahas alasan kami memutuskan untuk mengganti sistem BMS lama di pusat data kami dengan yang baru. Dan bukan sekedar berubah, tapi kembangkan dari awal agar sesuai dengan kebutuhan Anda. Di bagian kedua kami memberi tahu Anda bagaimana kami melakukannya.
Analisis Pasar
Dengan mempertimbangkan hal-hal yang dijelaskan dalam keinginan dan keputusan untuk menolak memperbarui sistem yang ada, kami menulis spesifikasi teknis untuk menemukan solusi di pasar dan mengajukan pertanyaan ke beberapa perusahaan besar yang hanya bergerak dalam pembuatan sistem SCADA industri.
Tanggapan pertama dari mereka menunjukkan bahwa para pemimpin pasar sistem pemantauan terus bekerja pada server perangkat keras, meskipun proses migrasi ke cloud di segmen ini telah dimulai. Mengenai pemesanan mesin virtual, tidak ada yang mendukung opsi ini. Selain itu, ada perasaan bahwa tidak ada pengembang yang terlihat di pasar yang menunjukkan pemahaman tentang perlunya redundansi: “cloud tidak jatuh” adalah jawaban yang paling umum. Faktanya, kami ditawari untuk menempatkan pemantauan pusat data di cloud yang secara fisik terletak di pusat data yang sama.
Di sini kita perlu melakukan sedikit penyimpangan tentang proses pemilihan kontraktor. Harga tentu saja penting, tetapi dalam setiap tender untuk pelaksanaan proyek yang kompleks, pada tahap dialog dengan pemasok, Anda mulai merasakan kandidat mana yang lebih tertarik dan mampu melaksanakannya.
Hal ini terutama terlihat pada proyek yang kompleks.
Berdasarkan sifat pertanyaan klarifikasi terhadap spesifikasi teknis, kontraktor dapat dibagi menjadi mereka yang tertarik hanya menjual (tekanan standar dari seorang manajer penjualan dirasakan) dan mereka yang tertarik untuk mengembangkan produk, mendengar dan memahami pelanggan, membuat konstruktif amandemen spesifikasi teknis bahkan sebelum pilihan akhir (walaupun ada risiko nyata meningkatkan spesifikasi teknis orang lain dan kalah dalam tender), pada akhirnya mereka siap 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 mengimplementasikan semua kebutuhan terkait BMS baru.
Risiko
Sementara para pemain besar mencoba memahami apa yang kami inginkan dan melakukan korespondensi santai dengan kami yang melibatkan spesialis tingkat pra-penjualan, pengembang lokal menjadwalkan pertemuan di kantor kami dengan partisipasi tim teknisnya. Pada pertemuan ini, kontraktor sekali lagi menunjukkan keinginannya untuk berpartisipasi dalam proyek dan, yang terpenting, menjelaskan bagaimana sistem yang dibutuhkan akan diterapkan.
Sebelum pertemuan tersebut, kami melihat dua risiko bekerja dengan tim yang tidak didukung oleh sumber daya dari perusahaan besar nasional atau internasional:
- Para spesialis dapat melebih-lebihkan kemampuan mereka dan, sebagai akibatnya, gagal mengatasinya; misalnya, mereka akan menggunakan perangkat lunak yang rumit atau merancang algoritma reservasi yang tidak layak.
- Setelah proyek selesai, tim proyek mungkin terpecah dan oleh karena itu, dukungan produk akan berada dalam bahaya.
Untuk meminimalkan risiko ini, kami mengundang pakar pembangunan kami sendiri ke pertemuan tersebut. Karyawan calon kontraktor diwawancarai secara menyeluruh tentang apa yang menjadi dasar sistem, bagaimana redundansi direncanakan akan diterapkan, dan masalah lain yang kami, sebagai layanan operasi, tidak cukup kompeten.
Keputusannya positif: arsitektur platform BMS yang ada modern, sederhana dan dapat diandalkan, dapat ditingkatkan, skema redundansi dan sinkronisasi yang diusulkan logis dan dapat diterapkan.
Risiko pertama telah diatasi. Yang kedua dikecualikan setelah menerima konfirmasi dari kontraktor bahwa mereka siap untuk mentransfer kode sumber sistem dan dokumentasi kepada kami, dan juga dengan memilih bahasa pemrograman Python, yang dikenal oleh spesialis kami. Hal ini menjamin kami memiliki kesempatan untuk memelihara sistem kami sendiri tanpa kesulitan apa pun dan pelatihan karyawan dalam jangka waktu yang lama jika perusahaan pengembang meninggalkan pasar.
Keuntungan tambahan dari platform ini adalah diimplementasikan dalam wadah Docker: kernel, antarmuka web, dan fungsi basis data produk di lingkungan ini. Pendekatan ini memberikan banyak keuntungan, termasuk pengaturan preset untuk kecepatan penerapan solusi tertinggi dibandingkan dengan “klasik” dan kemudahan penambahan perangkat baru ke sistem. Prinsip “bersama-sama” menyederhanakan implementasi sistem sebanyak mungkin: cukup buka paket sistem dan Anda dapat segera menggunakannya.
Dengan solusi ini, lebih mudah untuk membuat salinan sistem, dan Anda dapat memperbaikinya serta menerapkan peningkatan di lingkungan terpisah, tanpa menghentikan pengoperasian solusi secara keseluruhan.
Setelah kedua risiko diminimalkan, kontraktor menyediakan CP. Ini mencakup semua parameter terpenting sistem PASI bagi kami.
Reservasi
Sistem BMS baru harus ditempatkan di cloud, pada mesin virtual.
Tidak ada perangkat keras, tidak ada server, dan semua ketidaknyamanan serta risiko yang terkait dengan model penerapan ini - solusi cloud memungkinkan kami menghilangkannya selamanya. Diputuskan bahwa sistem akan beroperasi di cloud kami di dua lokasi pusat data di St. Petersburg dan Moskow. Ini adalah dua sistem yang berfungsi penuh yang beroperasi dalam mode siaga aktif dengan akses ke semua spesialis resmi.
Kedua sistem mengasuransikan satu sama lain, menyediakan cadangan penuh daya komputasi dan saluran transmisi data. Langkah-langkah keamanan tambahan juga telah dikonfigurasi, termasuk pencadangan data dan saluran, sistem, mesin virtual secara umum, dan pencadangan basis data terpisah sebulan sekali (sumber daya paling berharga dalam hal manajemen dan analisis).
Perhatikan bahwa redundansi sebagai opsi dalam solusi BMS dikembangkan secara khusus untuk permintaan kami. Skema reservasinya sendiri terlihat seperti ini:
Dukungan
Poin terpenting untuk pengoperasian solusi PASI yang efektif adalah dukungan teknis.
Semuanya sederhana di sini: sistem baru akan menelan biaya 35 rubel menurut indikator ini. per bulan untuk SLA “respons dalam 000 jam”, yaitu 8 x 35/000 = $12 per tahun. Tahun pertama gratis.
Sebagai perbandingan, pemeliharaan BMS lama dari vendor memerlukan biaya $18 per tahun dengan peningkatan jumlah untuk setiap perangkat baru yang ditambahkan! Pada saat yang sama, perusahaan tidak menyediakan manajer khusus; semua interaksi terjadi melalui manajer penjualan yang tertarik pada kami sebagai pembeli potensial dengan penekanan yang sesuai pada pemrosesan permintaan.
Dengan biaya lebih sedikit, kami menerima dukungan produk penuh, 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 cepat terhadap segala aspek sistem, integrasi melalui API, dll.
Update
Menurut CP yang diusulkan di BMS baru, semua pembaruan sudah termasuk dalam biaya dukungan, yaitu. tidak memerlukan pembayaran tambahan. Pengecualiannya adalah pengembangan fungsionalitas tambahan di luar yang ditentukan dalam spesifikasi teknis.
Sistem lama memerlukan pembayaran untuk pembaruan firmware (seperti Java) dan perbaikan bug. Tidak mungkin untuk menolak hal ini; dengan tidak adanya pembaruan, sistem secara keseluruhan “melambat” karena versi komponen internal yang lama.
Dan, tentu saja, tidak mungkin memperbarui perangkat lunak tanpa membeli paket dukungan.
Pendekatan yang fleksibel
Persyaratan mendasar lainnya berkaitan dengan antarmuka. Kami ingin menyediakan akses ke sana melalui browser web dari mana saja, tanpa kehadiran wajib seorang insinyur di wilayah pusat data. Selain itu, kami berupaya membuat antarmuka animasi sehingga dinamika infrastruktur akan lebih jelas bagi para insinyur yang bertugas.
Juga dalam sistem baru, perlu untuk memberikan dukungan formula untuk menghitung pengoperasian sensor virtual dalam sistem teknik - misalnya, untuk distribusi daya listrik yang optimal di seluruh rak peralatan. Untuk melakukan ini, Anda harus memiliki semua operasi matematika yang biasa diterapkan pada indikator sensor.
Selanjutnya, akses ke database SQL diperlukan dengan kemampuan untuk mengambil data yang diperlukan tentang pengoperasian peralatan - yaitu, semua catatan pemantauan dari dua ribu perangkat dan dua ribu sensor virtual yang menghasilkan sekitar 20 ribu variabel.
Modul akuntansi peralatan rak juga diperlukan, memberikan representasi grafis dari susunan perangkat di setiap unit dengan perhitungan berat total perangkat keras, memelihara perpustakaan perangkat dan informasi rinci tentang setiap elemen.
Persetujuan spesifikasi teknis dan penandatanganan perjanjian
Pada saat diperlukan untuk mulai mengerjakan sistem baru, korespondensi dengan perusahaan “besar” masih sangat jauh dari pembahasan biaya proposal mereka, jadi kami membandingkan CP yang diterima dengan biaya pemutakhiran BMS lama (lihat. ), dan hasilnya ternyata harganya lebih menarik dan memenuhi kebutuhan kami.
Pilihan telah dibuat.
Setelah memilih kontraktor, pengacara mulai membuat kesepakatan, dan tim teknis dari kedua belah pihak mulai menyempurnakan spesifikasi teknis. Seperti yang Anda ketahui, spesifikasi teknis yang detail dan kompeten menjadi landasan keberhasilan setiap pekerjaan. Semakin spesifik spesifikasi teknisnya, semakin sedikit kekecewaan seperti “tapi bukan ini yang kami inginkan”.
Saya akan memberikan dua contoh tingkat detail persyaratan dalam spesifikasi teknis:
- Pusat data yang bertugas diberi wewenang untuk menambahkan perangkat baru ke BMS, yang paling sering adalah PDU. Di BMS lama, ini adalah level “administrator”, yang juga memungkinkan perubahan pengaturan variabel semua perangkat, dan tidak mungkin memisahkan fungsinya. Ini tidak cocok untuk kami. Dalam versi dasar platform baru yang ada, skemanya serupa. Kami segera menunjukkan dalam kerangka acuan bahwa kami ingin memisahkan peran-peran ini: hanya karyawan yang berwenang yang boleh mengubah pengaturan, namun mereka yang bertugas harus terus dapat menambahkan perangkat. Skema ini diterima untuk diterapkan.
- Dalam BMS standar apa pun, ada tiga kategori umum pemberitahuan: MERAH - harus segera ditanggapi, KUNING - dapat diamati, BIRU - “Informasional”. Kami biasanya menggunakan peringatan biru untuk memantau ketika parameter bisnis telah terlampaui, seperti rak pelanggan melebihi batas kapasitasnya. Jenis pemberitahuan dalam kasus kami ini ditujukan untuk manajer dan tidak menarik bagi layanan operasi, namun di BMS lama, pemberitahuan ini sering menyumbat daftar insiden aktif dan mengganggu pekerjaan operasional. Kami menganggap logika dan diferensiasi warna dari celana notifikasi berhasil dan mempertahankannya, namun, spesifikasi teknis secara khusus menunjukkan bahwa notifikasi "biru" harus, tanpa mengganggu petugas jaga, secara diam-diam "menuangkan" ke bagian terpisah, di mana mereka akan ditangani oleh spesialis komersial.
Dengan tingkat detail yang sama, format untuk membuat grafik dan menghasilkan laporan, garis besar antarmuka, daftar perangkat yang perlu dipantau, dan banyak hal lainnya telah ditentukan.
Ini adalah karya yang benar-benar kreatif dari tiga kelompok kerja - layanan pelanggan, yang menentukan persyaratan dan ketentuannya; spesialis teknis di kedua sisi, yang tugasnya mengubah kondisi ini menjadi dokumentasi teknis; tim pemrogram kontraktor yang menerapkan persyaratan pelanggan sesuai dengan yang dikembangkan dokumentasi teknis... Hasilnya, kami menyesuaikan beberapa persyaratan tidak berprinsip kami dengan fungsionalitas platform yang ada, dan kontraktor berjanji untuk menambahkan sesuatu untuk kami.
Operasi paralel dari dua sistem
Saatnya untuk implementasi. Dalam praktiknya, ini berarti kami memberikan kesempatan kepada kontraktor untuk menerapkan prototipe BMS di cloud virtual kami dan menyediakan akses jaringan ke semua perangkat yang memerlukan pemantauan.
Namun, sistem baru tersebut belum siap dioperasikan. Pada tahap ini, penting bagi kami untuk mempertahankan pemantauan di sistem lama dan pada saat yang sama memberikan akses perangkat ke sistem baru. Tidak mungkin membangun sistem dengan baik tanpa melihat perangkat di dalamnya, yang pada gilirannya tidak dapat dinonaktifkan dari pemantauan oleh sistem lama.
Apakah perangkat tersebut dapat bertahan dalam interogasi simultan oleh dua sistem masih belum jelas tanpa pengujian yang sebenarnya. Ada kemungkinan bahwa jajak pendapat ganda secara bersamaan akan menyebabkan seringnya penolakan respons dari perangkat dan kami akan menerima banyak kesalahan terkait tidak tersedianya perangkat, yang pada gilirannya akan memblokir pengoperasian sistem pemantauan lama.
Departemen jaringan menjalankan rute virtual dari prototipe BMS baru yang diterapkan di cloud ke perangkat, dan kami mendapatkan hasilnya:
- perangkat yang terhubung melalui protokol SNMP praktis tidak pernah terputus karena permintaan simultan,
- perangkat yang terhubung melalui gateway menggunakan protokol modbas-TCP memiliki masalah yang diselesaikan dengan mengurangi frekuensi pollingnya secara cerdas.
Dan kemudian kami mulai mengamati bagaimana sistem baru sedang dibangun di depan mata kami, perangkat yang sudah kami kenal muncul di dalamnya, tetapi dalam antarmuka yang berbeda - nyaman, cepat, dapat diakses bahkan dari telepon.
Kami akan memberi tahu Anda apa yang terjadi pada akhirnya di bagian ketiga artikel kami.
Sumber: www.habr.com