Di bagian sebelumnya, kami berbicara tentang cara kami membuat dan menerapkan sistem pemantauan pusat data baru . Hasilnya, kami memiliki mekanisme yang kuat untuk melacak dan memelihara statistik semua parameter pusat data yang memengaruhi ketersediaan sumber dayanya dan indikator operasi yang tidak terputus.
Tugas selanjutnya dalam pengembangan sistem adalah pertanyaan penyesuaiannya: bagaimana membuatnya nyaman untuk bekerja dengan sistem baru, dan itu sendiri akan menjadi seinformatif mungkin?
Masalahnya di sini adalah fungsionalitas sistem memungkinkan Anda mengaktifkan banyak pemberitahuan dan sinyal darurat - dengan pengaturan seperti itu, staf akan dipaksa untuk terus meresponsnya, mengerjakan skenario yang sesuai.
Pilihan lainnya adalah dengan mengatur jumlah notifikasi yang tidak mencukupi, sehingga menimbulkan resiko bagi peserta untuk melewatkan acara yang sangat penting.
Pada bagian ini, kami akan membagikan pengalaman praktis kami dalam menyiapkan sistem pemantauan pusat data kami.
Sedikit teori
"Variabel yang dikumpulkan oleh sistem SCADA dibagi menjadi tele-signaling dan telemetri" - mereka pernah mengajari saya di institut. Dan nyatanya, tidak ada yang berubah: telesignaling adalah sebuah keadaanperangkat, misalnya, "tidak ada alarm", "ada alarm", "buka", "tutup", dll.
Dan telemetri, seperti yang Anda duga, adalah nilai digital dari beberapa parameter, misalnya, "220 Volt" atau "10 Ampere".
Status atau nilai yang ditetapkan oleh pengguna di mana pesan (alarm) muncul di layar disebut "setpoint". Anda dapat mengatur penundaan sebelum pesan muncul, yaitu, alarm muncul di layar hanya setelah X detik (asalkan darurat belum berhenti lebih awal) atau untuk "membekukan" pesan di layar - dalam hal ini, alarm telah menghilang, tetapi pesan tentangnya ada di layar disimpan selama X detik lagi.
Kecelakaan berdasarkan prioritas biasanya dibagi menjadi tiga jenis utama: "Merah", "Kuning" dan "Biru". Kecelakaan "Merah" membutuhkan tindakan segera oleh karyawan, "Kuning" memperingatkan mereka tentang sesuatu, "Biru" paling sering melaporkan beberapa peristiwa tidak kritis. Misalnya, kami telah menyimpulkan kecelakaan "Biru" dari ringkasan yang dilihat petugas dan menggunakannya untuk memantau berbagai parameter komersial (melebihi kapasitas yang dipesan). Kecelakaan ini dilaporkan hanya kepada manajer dan tidak mengganggu petugas.
Untuk kenyamanan mengonfigurasi jenis peralatan yang sama, variabel di perangkat yang berbeda, tetapi dengan nama yang sama (misalnya, "OutputCurrent") memiliki pengaturan yang sama di semua perangkat dalam sistem. Jika kita mengubah pengaturan di satu tempat, itu berubah di semua tempat.
Ketika sebuah perangkat membutuhkan pengaturan individu untuk variabel yang dibutuhkan, kami menerapkan tanda khusus "Hanya untuk perangkat ini". Sekarang variabel telah menjadi individu untuk satu perangkat tertentu, memiliki pengaturannya sendiri dan tidak mempengaruhi variabel lain dengan nama yang sama.
Selain itu, perangkat itu sendiri memiliki pengaturan pabrik sendiri. Misalnya, PDU dikonfigurasi oleh pabrik untuk mengenali alarm arus lebih 32A. Jika dipicu, PDU akan memberi tahu tentang jenis alarm "Alarm Beban Berlebih". Dan ini adalah variabel yang sama sekali berbeda, tidak terkait dengan variabel "OutputCurrent" yang dikonfigurasi di BMS.
Contoh pengaturan default pabrik di dalam PDU:
Jadi, kami telah membuat daftar fungsi utama untuk menyiapkan sistem pemantauan.
Bagaimana cara menyetel "piano" ini dengan benar? Mari kita bahas tugas secara berurutan.
Apa yang ingin kita capai
Tugas terpenting: pesan alarm apa pun di
Tugas kedua adalah meminimalkan pesan palsu atau tidak informatif. Tidak peduli seberapa penuh perhatian dan tanggung jawab Anda, jika sesuatu terus-menerus berkedip, berkedip, dan berdering di depan mata mereka, mereka akan melewatkan kecelakaan nyata, tenggelam dalam lautan peringatan, atau mematikan suara - dan akibatnya, mereka juga akan melewatkan peringatan insiden tersebut.
Tahap 1. Penentuan variabel yang diperlukan dan tidak perlu untuk setiap perangkat
Biasanya, setiap perangkat dilengkapi dengan apa yang disebut "peta variabel", yang menjadi dasarnya "driver" dibuat oleh insinyur yang menjalankan tugasnya. Tugasnya adalah untuk "menunjukkan" ke sistem pemantauan di mana register dari data yang diterima terdapat variabel yang diperlukan. Misalnya, register 1 dari protokol polling perangkat berisi informasi tentang mode operasi mesin "System_on_fun", dan register 2 - tentang mode operasi kompresor "Compressor_1".
Jumlah variabel untuk satu perangkat seringkali lebih dari 100. Karyawan yang awalnya mengonfigurasi sistem (biasanya insinyur TI) tidak dapat memutuskan sendiri apa yang penting di sini dan apa yang tidak. Sebagai aturan, semua variabel ditambahkan ke pemantauan pada prinsip "bagaimana jika mereka berguna".
Pada awalnya, ini diperbolehkan - staf operasi dapat melihat nilai sebenarnya dari semua variabel yang tersedia dan memahami apa yang sebenarnya mereka butuhkan. Tetapi jika Anda membiarkan sistem dalam keadaan ini untuk waktu yang lama, maka kami akan mendapatkan efek negatif berikut:
- Variabel yang berlebihan memuat tugas operasional sistem pemantauan dan meningkatkan ukuran arsip; sistem dipaksa untuk memproses dan menyimpan data yang tidak perlu.
- Semakin banyak variabel yang disurvei, semakin tinggi kemungkinan kegagalan polling. Hal ini terutama berlaku untuk perangkat yang terhubung melalui loop (misalnya, melalui gateway yang menggunakan protokol MODBUS). Hal ini mengarah pada penerimaan status "tidak ada data (N / A)" atau "jeda komunikasi", yang pada kenyataannya, perangkat secara berkala keluar dari pemantauan.
- Beberapa variabel berlebihan "secara default". Misalnya, versi peralatan Anda tidak memiliki kompresor atau sensor tekanan, tetapi terdaftar di driver universal untuk seluruh rangkaian model peralatan dan disurvei, ditambahkan ke arsip, memuat jaringan dan pemrosesan.
Tangkapan layar menunjukkan bagian dari kode driver. Simbol // menunjukkan variabel yang tersembunyi dari polling. Juga terlihat daftar variabel yang ditampilkan kepada pengguna saat menyetel setpoint di BMS itu sendiri.
Menurut pengalaman kami, lebih baik tidak menyentuh pengaturan pabrik di dalam perangkat pada tahap awal (tentu saja, jika mereka belum memberi tahu Anda tentang kecelakaan itu). Namun, pada setiap sesi pelatihan tentang peralatan tertentu, karyawan harus diingatkan tentang adanya pengaturan baik di perangkat itu sendiri maupun di BMS. Ke depannya, ini akan membantu petugas untuk memahami dengan tepat apa sebenarnya penyebab dari pesan alarm tersebut.
Variabel yang tidak berguna di driver harus secara bertahap diungkapkan dan disembunyikan dari polling, dan variabel lainnya harus dibagi menjadi variabel yang harus ditetapkan pengaturannya, dan yang disimpan tanpa pengaturan hanya untuk analisis dan statistik selanjutnya.
Ini tidak boleh dilakukan oleh penyetel sistem, tetapi oleh karyawan yang memahami pengoperasian sistem yang dikendalikan oleh sistem pemantauan - sebaiknya kepala teknisi atau kepala teknisi listrik.
Tahap 2. Meminimalkan pesan palsu dan tidak informatif
Positif palsu sering terjadi karena kegagalan dalam mengumpulkan perangkat. Jika kartu jaringan dari perangkat tidak berdaya sendiri, maka kegagalan dalam polling dan pemadaman listrik yang sebenarnya akan ditampilkan sebagai salah satu jenis kegagalan - "komunikasi putus".
Dalam hal ini, perlu membagi peralatan menjadi kritis (misalnya, PDU) dan biasa (misalnya, panel ventilasi "SHCHUV"). Untuk peralatan konvensional, Anda dapat mengatur penundaan untuk sinyal "pemutusan" (misalnya, 300 detik) - maka sebagian besar pemutusan palsu akan diabaikan.
Jelas bahwa penundaan seperti itu tidak dapat ditempatkan pada peralatan kritis, oleh karena itu, jika terus-menerus memberikan kegagalan palsu, maka Anda harus berurusan dengan jaringan fisik, jumlah variabel yang disurvei. Sangat mungkin bahwa banyak perangkat yang "digantung" pada satu gateway dan jaringan perlu disegmentasi dengan menambahkan gateway baru.
Kecelakaan non-informatif paling sering terjadi selama proses sementara. Mereka tidak dapat disebut salah - mereka benar-benar ada, tetapi mereka "normal" untuk mode operasi peralatan tertentu. Contoh paling jelas adalah transisi ke genset diesel.
Dalam hal ini, bagian dari peralatan yang diberi daya tanpa UPS "biasanya" mati daya dan memberikan kesalahan "pemutusan", dan UPS sendiri mengeluarkan sejumlah besar pesan - "tidak ada daya pada input", "tidak ada daya on bypass "," power supply dari baterai "Dll. Staf segera menerima lusinan pesan.
Untuk mengoptimalkan jumlah pesan saat beralih ke DGS, Anda harus:
- setel untuk alarm yang muncul "normal" selama transisi penundaan waktu yang lebih lama daripada waktu ketika catu daya dari genset muncul. Misalnya, atur penundaan untuk sinyal "pemutusan" panel ventilasi selama 300 detik ketika waktu standar untuk beralih ke genset diesel adalah 200 detik.
Kemudian catu daya ke SCHU akan muncul sebelum penundaan setpoint, dan situasinya tidak akan dikenali sebagai keadaan darurat. Pada saat yang sama, ada perangkat penting yang diberi daya oleh UPS dan harus selalu terhubung (misalnya, PDU) - pesan tentang "pemutusan" akan muncul tanpa penundaan.
- menganalisis pesan dari UPS ketika beralih ke genset diesel dan membaginya menjadi yang "normal" dengan menetapkan jenis "kuning" (misalnya, pernyataan fakta "tidak ada daya pada input") dan "tidak normal "(" pemutusan pemutus baterai ", yang seharusnya bukan mode operasi apa pun), dengan menetapkannya ke tipe" merah ".
Pada saat yang sama, kami menulis secara terpisah dalam instruksi kepada petugas jaga bahwa jika terjadi transisi ke genset diesel, kecelakaan "kuning" dapat diamati dan tidak dikenali (mereka akan hilang sendiri setelah selesainya transisi reguler ), dan kecelakaan "merah" dapat dihilangkan dengan segera (seharusnya tidak).
Mengandalkan teori saja, sangat sulit untuk menyesuaikan setpoint untuk proses "sementara" ini pada satu waktu. Untuk penyetelan yang sukses, perlu untuk mengamati transisi ke DGS beberapa kali secara real time.
Misalnya, kami perlu mengamati 4-5 transisi untuk penyiapan BMS baru yang dapat diterima. Untuk menganalisis proses transisi yang tidak terjadwal, kami membuat rekaman layar sistem pemantauan, karena penting untuk mengamati alarm bukan di arsip acara, tetapi untuk menganalisis kemunculan alarm dalam dinamika ringkasan operasional.
Langkah 3. Tip tambahan dari pengalaman kami
1. Pada layar shift tugas, seharusnya tidak ada indikasi yang tidak perlu dalam warna pesan alarm.
Contoh dunia nyata. Salah satu pusat data memesan peta aliran suhu di ruang server. Ini adalah model aliran udara 3D dengan banyak data suhu dari sensor. Hasilnya adalah pemandangan udara utara dengan aliran udara - di suatu tempat udara disorot dengan warna hijau, di suatu tempat - kuning dan merah (dari yang terdingin hingga terpanas). Pada saat yang sama, suhu udara di mana-mana dalam batas normal, dan warna hanya digunakan untuk kejelasan tampilan perbedaan suhu di berbagai titik.
Selanjutnya, tampilan "beraneka ragam" ini ditampilkan di salah satu monitor di "ruang tugas". Hasilnya, ternyata alat yang dibuat untuk proses analitik muncul di depan mata mereka yang bertugas, yang "diasah" untuk berlari ke peralatan saat mereka melihat warna merah dan tegang saat melihat warna kuning.
Mungkin, mereka menjelaskan kepada petugas bahwa di layar kiri "merah / kuning" adalah normal, dan di layar kanan warna yang sama adalah sinyal untuk beraksi. Namun, jelas bahwa praktik ini meningkatkan risiko kesalahan manusia dengan sangat serius.
Adalah logis untuk menghapus sistem seperti itu dari monitor di ruang tugas, mereka harus diamati oleh kepala teknisi untuk tujuan menganalisis tren - misalnya, setelah beberapa perubahan dalam parameter lingkungan udara di ruang server atau commissioning peralatan baru.
2. Gunakan notifikasi SMS dengan hati-hati.
Beberapa tahun yang lalu, kami masih takut dengan Internet seluler yang buruk dan menggunakan SMS alih-alih pengirim pesan instan. Setelah saya secara tidak sengaja menyetel pengaturan yang salah, itu diterapkan ke semua perangkat dengan nama yang sama di 100 perangkat, dan kolega saya yang berlangganan milis menerima masing-masing 100 pesan SMS. Sejak itu, kami tidak lagi menggunakan SMS-mailing.
3. Atur duplikasi pesan tentang masalah melalui utusan.
Ini dapat dilakukan, misalnya, melalui Microsoft Teams atau Telegram. Baik Anda dan orang yang bertugas akan menerima pesan tentang kecelakaan, sementara telepon akan mengeluarkan suara dan getar (yang tidak terjadi saat bekerja dengan sistem melalui browser).
Dan jangan takut pesannya akan banyak. Dalam pengalaman kami, selama hari-hari rata-rata operasi pusat data, hanya beberapa lusin pesan yang diterima, dan tidak memuat telepon karyawan. Artinya, peralatan pusat data dan sistem BMS dapat dikonfigurasi agar tidak menerima ratusan notifikasi dan pada saat yang sama tidak melewatkan sesuatu yang penting.
Untuk mengurangi jumlah pesan, sertakan dalam milis hanya pemberitahuan tentang terjadinya alarm "merah" dan "kuning", yaitu, jumlah minimum yang diperlukan, memungkinkan Anda untuk tetap memperhatikan denyut nadi peristiwa.
4. Kelompokkan pesan dalam utusan.
Selama transisi ke genset diesel atau karena kecelakaan yang kompleks, Anda akan mengalami lusinan keadaan darurat aktif, telepon akan terus bergetar dari pesan masuk ke messenger, mencegah Anda melakukan panggilan penting atau membuka jendela sistem pemantauan.
Anda dapat mengkonfigurasi distribusi sehingga pembawa pesan menerima satu pesan umum dengan daftar umum kecelakaan yang terjadi di menit terakhir. Pengaturan ini tidak mempengaruhi munculnya alarm dalam ringkasan sistem BMS (alarm muncul dalam ringkasan tanpa penundaan), dan selama 1 menit penundaan dalam penerimaan pesan di telepon Anda, Anda tidak akan melewatkan apa pun, tetapi akan ada berkali-kali lebih sedikit pesan di ponsel Anda.
5. Sorot pesan tentang hilangnya koneksi dengan server di antarmuka.
Misalnya, Internet hilang di tempat para petugas. Antarmuka pengguna tidak memiliki koneksi dengan server dan oleh karena itu alarm tidak muncul dalam ringkasan, tulisan redup "server tidak tersedia" mungkin tidak diperhatikan oleh personel, karyawan dapat melihat panel BMS "hijau" dengan parameter numerik untuk waktu yang lama, tidak menyadari bahwa itu sedang offline.
Tangkapan layar menunjukkan contoh indikasi hilangnya komunikasi dengan server BMS, sementara parameter peralatan yang tidak relevan ditampilkan.
6. Hubungkan sebanyak mungkin sistem ke pemantauan.
Misalnya, sistem alarm kebakaran tradisional bekerja secara mandiri, dan panelnya tergantung di pos keamanan.
Ya, pada sinyal "KEBAKARAN", algoritma otomatis dari sistem dipicu, sistem peringatan dimulai, tetapi petugas keamanan menginformasikan tentang munculnya sinyal "Kesalahan" atau "Perhatian" dalam suara yang bertugas.
Sangat sulit untuk sepenuhnya menghubungkan sistem seperti itu ke pemantauan, tetapi dalam sistem seperti itu mudah untuk mengkonfigurasi tiga sinyal relai "kesalahan", "perhatian" dan "api", dan kemudian menghubungkannya dengan "kontak kering" ke BMS modul sistem.
Ini mengurangi risiko faktor manusia yang terkenal kejam. Contoh sinyal uji "KEBAKARAN" di sistem BMS pusat data, dihubungkan melalui "kontak kering".
Menyimpulkan Sejarah 4-Seri Kami
Sistem pemantauan pusat data lebih dari sekadar "mata dan telinga" untuk memantau sistem rekayasa pusat data. Pengoperasian yang benar memungkinkan pencapaian tingkat keandalan tertinggi melalui kelangsungan situs, dan, oleh karena itu, memberi perusahaan keunggulan kompetitif tambahan.
Setelah melewati jalan yang agak sulit dan jauh, kami mendapat:
- sistem pemantauan yang cepat dan stabil yang saat ini memantau lebih dari 2.500 perangkat dan menghitung sekitar 10.000 sensor virtual;
- reservasi sistem berdasarkan platform solusi cloud Lindatacenter di St. Petersburg dan Moskow;
- -, , 1 ;
- , , ;
- , , – .