Dans les parties précédentes, nous avons expliqué comment nous avons créé et mis en œuvre un nouveau système de surveillance de centre de données. En conséquence, nous disposons d' un mécanisme puissant pour suivre et maintenir les statistiques de tous les paramètres du centre de données qui affectent la disponibilité de ses ressources et des indicateurs de fonctionnement ininterrompu.
La tâche suivante sur le chemin du développement du système était la question de son ajustement: comment rendre pratique le travail avec le nouveau système, et il serait lui-même aussi informatif que possible?
Le problème ici est que la fonctionnalité du système vous permet d'activer de nombreuses notifications et signaux d'urgence - avec de tels paramètres, le personnel sera obligé d'y répondre en permanence, en élaborant les scénarios appropriés.
Une autre option consiste à définir un nombre insuffisant de ces notifications, ce qui crée des risques pour les préposés de rater un événement vraiment important.
Dans cette partie, nous partagerons notre expérience pratique dans la mise en place de notre système de surveillance de centre de données.
Un peu de théorie
«Les variables collectées par le système SCADA sont divisées en télé-signalisation et télémétrie» - m'ont-ils appris une fois à l'institut. Et en fait, rien n'a changé: la télésignalisation est un étatdispositifs, par exemple, « pas d' alarme », « il y a une alarme », « ouvert », « fermé », etc.
Et la télémétrie, comme vous pouvez le deviner, est la valeur numérique de certains paramètres, par exemple, « 220 Volts » ou "10 ampères".
L'état ou la valeur réglé par l'utilisateur auquel un message (alarme) apparaît à l'écran est appelé «point de consigne». Vous pouvez définir un délai avant que le message n'apparaisse, c'est-à-dire que l'alarme n'apparaisse à l'écran qu'après X secondes (à condition que l'urgence ne se soit pas arrêtée plus tôt) ou pour «geler» le message à l'écran - dans ce cas, l'alarme a déjà disparu, mais le message à ce sujet est sur l'écran stocké pendant encore X secondes.
Les accidents par priorité sont généralement divisés en trois types principaux: «Rouge», «Jaune» et «Bleu». Les accidents «rouges» nécessitent une action immédiate de la part des employés, les «jaunes» les préviennent de quelque chose, les «bleus» signalent le plus souvent des événements non critiques. Par exemple, nous avons déduit les accidents «bleus» du résumé que les préposés voient et les utilisent pour surveiller divers paramètres commerciaux (dépassant la capacité commandée). Ces accidents sont signalés uniquement aux gestionnaires et ne distraient pas les préposés.
Pour faciliter la configuration du même type d'équipement, les variables de différents appareils, mais avec le même nom (par exemple, «OutputCurrent») ont les mêmes paramètres sur tous les appareils du système. Si nous modifions le paramètre en un seul endroit, cela change partout.
Lorsqu'un appareil nécessite des réglages individuels pour la variable requise, nous appliquons une marque spéciale «Uniquement pour cet appareil». Désormais, la variable est devenue individuelle pour un appareil spécifique, a son propre paramètre et n'affecte pas les autres variables du même nom.
De plus, les appareils eux-mêmes ont leurs propres paramètres d'usine. Par exemple, la PDU est configurée en usine pour reconnaître une alarme de surintensité de 32A. S'il est déclenché, le PDU notifiera le type d'alarme "Alarme de surcharge". Et c'est une variable complètement différente, sans rapport avec la variable "OutputCurrent" configurée dans le BMS.
Exemple de paramètres d'usine par défaut dans une PDU:
Nous avons donc répertorié les principales fonctionnalités de mise en place d'un système de surveillance.
Comment accorder correctement ce "piano"? Passons en revue les tâches dans l'ordre.
Ce que nous voulons accomplir
La tâche la plus importante: tout message d'alarme sur le panneau de commande
La deuxième tâche consiste à minimiser les messages faux ou non informatifs. Peu importe à quel point vous êtes attentif et responsable, si quelque chose clignote, clignote et sonne constamment devant leurs yeux, alors ils vont soit rater un véritable accident, se noyer dans une mer d'alertes, soit couper le son - et en conséquence, ils manqueront également l'alerte d'incident.
Étape 1. Détermination des variables nécessaires et inutiles pour chaque appareil
Habituellement, chaque appareil est livré avec une soi-disant "carte des variables", sur la base de laquelle un "pilote" est créé par l'ingénieur de mise en service. Sa tâche est "d'indiquer" au système de surveillance dans quel registre des données reçues se trouve la variable requise. Par exemple, le registre 1 du protocole d'interrogation de l'appareil contient des informations sur le mode de fonctionnement du moteur "System_on_fun" et le registre 2 - sur le mode de fonctionnement du compresseur "Compressor_1".
Le nombre de variables pour un appareil est souvent supérieur à 100. L'employé qui configure initialement le système (généralement un ingénieur informatique) ne peut pas décider lui-même ce qui est important ici et ce qui ne l'est pas. En règle générale, toutes les variables sont ajoutées au suivi sur le principe du «et si elles s'avèrent utiles».
Au début, cela est permis - le personnel des opérations peut examiner les valeurs réelles de toutes les variables disponibles et comprendre ce dont il a vraiment besoin. Mais si vous laissez le système dans cet état pendant une longue période, nous aurons les effets négatifs suivants:
- Des variables superflues chargent la tâche opérationnelle du système de surveillance et augmentent la taille de l'archive; le système est obligé de traiter et de sauvegarder les données inutiles.
- Plus il y a de variables interrogées, plus la probabilité d'échec d'interrogation est élevée. Cela est particulièrement vrai pour les appareils connectés via une boucle (par exemple, via une passerelle utilisant le protocole MODBUS). Ceci conduit à la réception des états «pas de données (N / A)» ou «rupture de communication», c'est-à-dire que l'appareil cesse périodiquement de surveiller.
- Certaines variables sont superflues "par défaut". Par exemple, votre version de l'équipement n'a pas de compresseur ou de capteur de pression, mais ils sont enregistrés dans le pilote universel pour toute la gamme de modèles d'équipement et sont interrogés, ajoutés à l'archive, chargeant le réseau et le traitement.
Les captures d'écran montrent une partie du code du pilote. Les symboles // indiquent les variables cachées du sondage. Une liste de variables est également visible pour l'utilisateur lors de la définition des points de consigne dans le BMS lui-même.
Selon notre expérience, il est préférable de ne pas toucher les paramètres d'usine à l'intérieur des appareils au stade initial (bien sûr, s'ils ne vous informent pas déjà de l'accident). Cependant, à chaque session de formation sur un équipement spécifique, il convient de rappeler aux employés la présence de paramètres à la fois dans l'appareil lui-même et dans le BMS. À l'avenir, cela aidera les préposés à comprendre exactement quelle est exactement la cause du message d'alarme.
Les variables superflues dans le pilote doivent être progressivement révélées et masquées du sondage, et les autres doivent être divisées en celles auxquelles les paramètres doivent être attribués et celles qui sont enregistrées sans paramètres uniquement pour une analyse et des statistiques ultérieures.
Cela ne devrait pas être fait par le régleur du système, mais par un employé qui comprend le fonctionnement du système contrôlé par le système de surveillance - de préférence l'ingénieur en chef ou l'ingénieur en chef de l'électricité.
Étape 2. Minimisation des messages faux et non informatifs Des
faux positifs se produisent souvent en raison d'échecs lors de l'interrogation du périphérique. Si la carte réseau de l'appareil n'est pas auto-alimentée, alors une panne d'interrogation et une coupure de courant réelle seront affichées comme un type de panne - «rupture de communication».
Dans ce cas, il est nécessaire de diviser l'équipement en panneaux de ventilation critiques (par exemple, PDU) et ordinaires (par exemple, panneaux de ventilation «SHCHUV»). Pour les équipements conventionnels, vous pouvez définir un délai pour le signal "déconnexion" (par exemple, 300 secondes) - la plupart des fausses déconnexions seront alors ignorées.
Il est clair qu'un tel retard ne peut pas être placé sur un équipement critique.Par conséquent, s'il donne constamment de fausses pannes, vous devez vous occuper du réseau physique, du nombre de variables interrogées. Il est tout à fait possible que de nombreux appareils soient "accrochés" sur une passerelle et il est nécessaire de segmenter le réseau en ajoutant de nouvelles passerelles.
Les accidents non informatifs surviennent le plus souvent lors de processus transitoires. Ils ne peuvent pas être qualifiés de faux - ils existent réellement, mais ils sont «normaux» pour un mode de fonctionnement spécifique de l'équipement. L'exemple le plus évident est la transition vers un groupe électrogène diesel.
Dans ce cas, une partie de l'équipement alimenté sans UPS «normalement» est hors tension et donne une erreur «déconnexion», et l'onduleur lui-même émet tout un tas de messages - «pas d'alimentation à l'entrée», «pas d'alimentation sur bypass "," alimentation par batterie "Etc. Le personnel reçoit immédiatement des dizaines de messages.
Pour optimiser le nombre de messages lors du passage à DGS, vous devez:
- réglé pour des alarmes apparaissant «normalement» pendant la transition des temporisations plus longues que le temps où l'alimentation électrique du groupe électrogène apparaît. Par exemple, réglez le délai du signal "déconnexion" du panneau de ventilation sur 300 secondes lorsque le temps standard de commutation vers le groupe électrogène diesel est de 200 secondes.
Ensuite, l'alimentation électrique du SCHU apparaîtra avant le délai de consigne et la situation ne sera pas reconnue comme une urgence. Dans le même temps, il existe des périphériques critiques qui sont alimentés par l'onduleur et doivent toujours être connectés (par exemple, PDU) - les messages concernant leur «déconnexion» devraient apparaître sans délai.
- analyser les messages de l'onduleur lors du passage à un groupe électrogène diesel et les diviser en «normaux» en leur attribuant un type «jaune» (par exemple, une déclaration du fait «il n'y a pas de courant à l'entrée») et «anormal "(" déconnexion du disjoncteur de batterie ", qui ne doit être aucun mode de fonctionnement), avec leur affectation au type" rouge ".
Dans le même temps, nous écrivons séparément dans les instructions aux officiers de service qu'en cas de transition vers un groupe électrogène diesel, des accidents «jaunes» peuvent être observés et non reconnus (ils disparaîtront d'eux-mêmes après l'achèvement d'une transition régulière ), et les accidents «rouges» peuvent être éliminés immédiatement (ils ne devraient pas l'être).
S'appuyant uniquement sur la théorie, il est très difficile d'ajuster les points de consigne pour ce processus «transitoire» en une seule fois. Pour un réglage réussi, il est nécessaire d'observer les transitions vers le DGS plusieurs fois en temps réel.
Par exemple, nous devions observer 4-5 transitions pour une configuration acceptable d'un nouveau BMS. Pour analyser le processus de transition non programmé, nous avons réalisé un enregistrement de l'écran du système de surveillance, car il est important d'observer les alarmes non pas dans l'archive des événements, mais d'analyser l'occurrence des alarmes dans la dynamique du résumé opérationnel.
Étape 3. Conseils supplémentaires tirés de notre expérience
1. Sur les écrans du quart de travail, il ne devrait y avoir aucune indication inutile dans les couleurs des messages d'alarme.
Exemple du monde réel. Un centre de données a commandé une carte de flux de température dans la salle des serveurs. Il s'agit d'un modèle 3D de flux d'air avec de nombreuses données de température provenant de capteurs. Le résultat était une vue de l'air du nord avec des courants d'air - quelque part l'air était surligné en vert, quelque part - jaune et rouge (du plus froid au plus chaud). Dans le même temps, les températures de l'air sont partout dans les limites normales et les couleurs ne sont utilisées que pour la clarté de l'affichage de la différence de température en différents points.
De plus, cette vue «hétéroclite» était affichée sur l'un des moniteurs de la «salle des fonctions». En conséquence, il s'est avéré que l'outil, créé pour l'analyse des processus, est apparu aux yeux des personnes de service, qui ont été «affûtées» pour courir vers l'équipement quand elles voient du rouge et se fatiguer quand elles voient du jaune.
Probablement, ils ont expliqué aux préposés que sur l'écran de gauche "rouge / jaune" est normal, et sur l'écran de droite, les mêmes couleurs sont un signal pour l'action. Cependant, il est clair que cette pratique augmente très sérieusement le risque d'erreur humaine.
Il est logique de retirer de tels systèmes des moniteurs dans la salle des fonctions, ils doivent être observés par l'ingénieur en chef dans le but d'analyser les tendances - par exemple, après quelques changements dans les paramètres de l'environnement de l'air dans la salle des serveurs ou la mise en service de nouveaux équipements.
2. Utilisez les notifications par SMS avec prudence.
Il y a plusieurs années, nous avions encore peur d'un mauvais Internet mobile et utilisions les SMS au lieu des messageries instantanées. Une fois que j'ai accidentellement défini le mauvais paramètre, il a été appliqué à tous les appareils du même nom dans 100 appareils, et mes collègues abonnés à la liste de diffusion ont reçu 100 messages SMS chacun. Depuis lors, nous n'avons plus utilisé l'envoi de SMS.
3. Configurez la duplication des messages sur les problèmes via la messagerie.
Cela peut être fait, par exemple, via Microsoft Teams ou Telegram. Vous et la personne de service recevrez des messages sur les accidents, tandis que le téléphone émettra des sons et vibrera (ce qui n'est pas le cas lorsque vous travaillez avec le système via un navigateur).
Et n'ayez pas peur qu'il y ait beaucoup de messages. D'après notre expérience, au cours de la journée moyenne d'une opération de centre de données, seules quelques dizaines de messages sont reçus et ils ne chargent pas les téléphones des employés. Autrement dit, l'équipement du centre de données et le système BMS peuvent être configurés de manière à ne pas recevoir des centaines de notifications et en même temps à ne rien manquer d'important.
Pour réduire le nombre de messages, n'incluez dans la liste de diffusion que des notifications sur l' apparition d' alarmes «rouges» et «jaunes», c'est-à-dire le minimum nécessaire, vous permettant de garder le doigt sur le pouls des événements.
4. Regroupez les messages dans les messagers.
Lors de la transition vers un groupe électrogène diesel ou en raison d'un accident complexe, vous aurez des dizaines d'urgences actives, le téléphone vibrera constamment des messages entrants au messager, vous empêchant de passer un appel important ou d'ouvrir la fenêtre du système de surveillance.
Vous pouvez configurer la distribution pour que le messager reçoive un message général avec une liste générale des accidents survenus au cours de la dernière minute. Ce paramètre n'affecte pas l'apparition des alarmes dans le résumé du système BMS (les alarmes apparaissent dans le résumé sans délai), et pendant 1 minute de retard dans la réception d'un message sur votre téléphone, vous ne manquerez de rien, mais il y aura beaucoup moins de messages sur votre téléphone.
5. Mettez en surbrillance le message concernant la perte de connexion avec le serveur dans l'interface.
Par exemple, Internet a été perdu dans les locaux des préposés. L'interface utilisateur n'a pas de connexion avec le serveur et donc l'alarme n'apparaît pas dans le résumé, l'inscription grisée «le serveur n'est pas disponible» peut ne pas être remarquée par le personnel, les employés peuvent consulter le panneau BMS «vert» avec des paramètres numériques pendant longtemps, sans savoir qu'il est situé hors ligne.
La capture d'écran montre un exemple d'indication de la perte de communication avec le serveur BMS, tandis que des paramètres non pertinents de l'équipement sont affichés.
6. Connectez autant de systèmes que possible à la surveillance.
Par exemple, traditionnellement, un système d'alarme incendie fonctionne de manière autonome et son panneau est suspendu au poste de sécurité.
Oui, sur le signal "FIRE", les algorithmes automatiques des systèmes se déclenchent, le système d'alerte démarre, mais l'agent de sécurité informe de l'apparition des signaux "Fault" ou "Attention" dans une voix de service.
Il est très difficile de connecter complètement un tel système à la surveillance, mais dans un tel système, il est facile de configurer trois signaux de relais «défaut», «attention» et «incendie», puis de les connecter avec des «contacts secs» au BMS module système.
Cela réduit le risque du facteur humain notoire. Un exemple de signal de test "FEU" dans le système BMS du centre de données, connecté via des "contacts secs".
Récapitulatif de notre histoire de la série 4
Un système de surveillance de centre de données est plus que de simples «yeux et oreilles» pour surveiller les systèmes d'ingénierie de centre de données. Son bon fonctionnement permet d'atteindre le plus haut niveau de fiabilité grâce à la continuité du site et, par conséquent, confère à l'entreprise un avantage concurrentiel supplémentaire.
Après avoir parcouru un chemin assez difficile et long, nous avons obtenu:
- un système de surveillance rapide et stable qui surveille actuellement plus de 2 500 appareils et calcule environ 10 000 capteurs virtuels;
- réservation système basée sur la plateforme de solutions cloud Lin clouddatacenter à Saint-Pétersbourg et Moscou;
- -, , 1 ;
- , , ;
- , , – .