Dans la première partie, nous avons expliqué pourquoi nous avons décidé de remplacer notre ancien système BMS dans nos centres de données par un nouveau. Et pas simplement le remplacer, mais le développer à partir de zéro selon nos exigences. Dans la deuxième partie, nous expliquons comment nous avons fait cela.
Analyse du marché
En tenant compte des souhaits décrits dans nos choix et de la décision de renoncer à la mise à jour du système existant, nous avons rédigé un cahier des charges pour rechercher une solution sur le marché et avons sollicité plusieurs grandes entreprises spécialisées uniquement dans la création de systèmes SCADA industriels.
Les premières réponses de ces entreprises ont montré que les leaders du marché des systèmes de surveillance continuent majoritairement à travailler sur des serveurs physiques, même si le processus de migration vers le cloud a déjà commencé dans ce secteur. En ce qui concerne la sauvegarde des machines virtuelles, aucune option n'était supportée. De plus, il semblait que les développeurs notables sur le marché n'avaient même pas compris la nécessité de la sauvegarde : « le cloud ne tombe jamais » était la réponse la plus fréquente. En réalité, on nous proposait de placer la surveillance du centre de données dans un cloud physiquement situé dans le même centre de données.
Il convient de faire une petite digression sur le processus de choix du sous-traitant. Le prix a bien sûr son importance, mais lors de tout appel d'offres pour la réalisation d'un projet complexe, au stade du dialogue avec les fournisseurs, on commence à sentir qui parmi les candidats est le plus intéressé et capable de le réaliser.
C'est particulièrement notable dans les projets complexes.
En fonction de la nature des questions de clarification posées au cahier des charges, on peut distinguer les sous-traitants intéressés simplement à vendre (le standard manifeste d'un responsable commercial se fait sentir) et ceux qui souhaitent développer un produit, entendent et comprennent le client, apportent des modifications constructives au cahier des charges même avant le choix final (même en dépit du réel risque d'améliorer un cahier des charges d'un autre et de perdre l'appel d'offres), et finalement ceux prêts à relever un défi professionnel et à créer un bon produit.
Tout cela nous a fait porter attention à un développeur local relativement petit – le groupe d'entreprises « Sunline », qui a répondu à la majorité de nos exigences immédiatement et était prêt à satisfaire tous les besoins concernant le nouveau BMS.
Risques
Alors que les grands acteurs tentaient de comprendre ce que nous voulions et engageaient des échanges lents impliquant des experts au niveau prévente, un développeur local a fixé un rendez-vous dans nos locaux avec sa équipe technique. Lors de cette réunion, le sous-traitant a une fois de plus démontré son désir de participer au projet et, surtout, a expliqué comment le système requis serait réalisé.
Avant la réunion, nous avons identifié deux risques liés au travail avec une équipe n'ayant pas le soutien d'une grande entreprise nationale ou internationale :
- Les spécialistes pouvaient surestimer leurs capacités et, par conséquent, ne pas être à la hauteur, par exemple, en utilisant un logiciel complexe ou en concevant des algorithmes de réservation irréalisables.
- Après la réalisation du projet, l'équipe peut se dissoudre et, par conséquent, le support du produit pourrait être en danger.
Pour minimiser ces risques, nous avons invité nos propres experts en développement à la réunion. Les employés du sous-traitant potentiel ont été soigneusement interrogés sur la base du système, sur la façon dont la réservation est prévue et sur d'autres questions où nous, en tant que service d'exploitation, manquons de compétence.
Le verdict a été positif : l'architecture de la plateforme BMS existante est moderne, simple et fiable, elle peut être adaptée, le schéma de réservation et de synchronisation proposé est logique et fonctionnel.
Nous avons résolu le premier risque. Le second a été éliminé après avoir reçu du sous-traitant la confirmation de sa volonté de nous transmettre le code source du système et la documentation, tout en choisissant le langage de programmation Python, bien connu de nos spécialistes. Cela nous a garantis la possibilité de maintenir le système par nos propres moyens sans aucune difficulté ni période d'apprentissage prolongée en cas de départ de l'entreprise de développement du marché.
Un autre avantage de la plateforme était qu'elle était réalisée dans des conteneurs Docker : dans cet environnement fonctionnent le noyau, l'interface web et la base de données du produit. Cette approche offre de nombreux avantages, y compris la préconfiguration des réglages pour une vitesse de déploiement de la solution bien supérieure à celle de la « classique » et l'ajout facile de nouveaux appareils au système. Le principe de l'« ensemble » simplifie au maximum le déploiement du système : il suffit de décompresser le système et il peut être exploité immédiatement.
Avec cette solution, il est plus facile de faire des copies de la système, et son amélioration ainsi que la mise en œuvre de mises à jour peuvent se faire dans un environnement séparé, sans interrompre le fonctionnement de la solution dans son ensemble.
Après que les deux risques ont été minimisés, le contractant a fourni un devis. Celui-ci a été élaboré en tenant compte de tous les paramètres les plus importants pour nous du système BMS.
Redondance
Le nouveau système BMS devait être basé dans le cloud, sur une machine virtuelle.
Aucun matériel, aucun serveur, et tous les désagréments et risques liés à ce modèle de déploiement – la solution cloud nous a permis de nous en débarrasser définitivement. Il a été décidé que le système fonctionnerait dans notre cloud sur deux sites de centres de données à Saint-Pétersbourg et à Moscou. Ce sont deux systèmes entièrement fonctionnels, opérant en mode actif-passif avec accès pour tous les spécialistes autorisés.
Les deux systèmes se protègent mutuellement, assurant une réserve complète tant au niveau des ressources de calcul que des canaux de transmission de données. Des mesures de sécurité supplémentaires ont également été mises en place, y compris la sauvegarde des données et des canaux, des systèmes, des machines virtuelles dans leur ensemble, et une sauvegarde distincte de la base de données une fois par mois (ressource la plus précieuse dans la gestion et l'analyse à long terme).
À noter que la réservation en tant qu'option de la solution BMS a été spécialement conçue à notre demande. Le schéma de réservation était le suivant :
Support
Un point crucial pour l'exploitation efficace de la solution BMS est le soutien technique.
Ici, tout est simple : ce nouveau système nous coûterait, à ce niveau, 35 000 RUB par mois pour le SLA 'réaction sous 8 heures', soit 35 000 x 12 / 80 = 5 250 $ par an. La première année est gratuite.
Pour comparaison : le support de l'ancien système BMS par le fournisseur coûtait 18 000 $ par an, avec une augmentation du montant pour chaque nouvel appareil ajouté ! En outre, l'entreprise ne fournissait pas de gestionnaire dédié ; toutes les interactions se faisaient par l'intermédiaire du responsable commercial, qui avait un intérêt dans nous en tant qu'acheteur potentiel, avec l'accent approprié dans le traitement des demandes.
Pour moins d'argent, nous avons obtenu un soutien complet du produit, avec un gestionnaire de compte qui participerait au développement du produit, avec un point d'entrée unique, etc. Le support est devenu bien plus flexible – grâce à un accès direct aux développeurs pour des ajustements rapides sur tous les aspects du fonctionnement du système, l'intégration via API, etc.
Mises à jour
Selon la proposition faite dans le nouveau BMS, toutes les mises à jour sont incluses dans le coût du support, c'est-à-dire qu'elles ne nécessitent aucun paiement supplémentaire. L'exception concerne le développement de fonctionnalités supplémentaires, au-delà de celles spécifiées dans le cahier des charges.
L'ancien système supposait des paiements pour la mise à jour des logiciels gratuits intégrés (comme Java) ainsi que pour la correction des erreurs. Il était impossible d'y renoncer ; en l'absence de mises à jour, le système en général « ralentissait » à cause des anciennes versions des composants internes.
Et, bien sûr, il était impossible de mettre à jour le logiciel sans acheter un package de support.
Approche flexible
Une autre exigence clé concernait l'interface. Nous voulions permettre l'accès via un navigateur web depuis n'importe quel endroit, sans la présence obligatoire d'un ingénieur sur le site du Data Center. De plus, nous aspirions à créer une interface animée, afin que la dynamique du fonctionnement de l'infrastructure soit plus claire pour les ingénieurs de garde.
De plus, le nouveau système devait assurer le support de formules pour le calcul du fonctionnement des capteurs virtuels dans les systèmes d'ingénierie – par exemple, pour une distribution optimale de l'énergie électrique sur les racks d'équipement. Pour cela, il était nécessaire d'avoir à disposition toutes les opérations mathématiques familières, applicables aux indicateurs des capteurs.
Ensuite, un accès à la base de données SQL était nécessaire pour obtenir les données requises sur le fonctionnement de l'équipement – à savoir, tous les enregistrements de la surveillance de deux mille appareils et de deux mille capteurs virtuels, générant environ vingt mille variables.
Un module de gestion des équipements en rack était également nécessaire, fournissant une représentation graphique de l'emplacement des appareils dans chaque unité, avec un calcul du poids total du matériel, la gestion d'une bibliothèque d'appareils et des informations détaillées sur chaque élément.
Validation du cahier des charges et signature du contrat
Au moment où il était nécessaire de commencer à travailler sur le nouveau système, la correspondance avec les « grandes » entreprises était encore très éloignée de la discussion sur le prix de leurs offres, nous avons donc comparé le devis reçu aux coûts de mise à jour de l'ancienne BMS (voir ), et il s'est finalement avéré plus attrayant en prix et conforme à nos exigences.
Le choix a été fait.
Après la sélection du fournisseur, les juristes ont commencé à rédiger le contrat, tandis que les équipes techniques des deux côtés affinaient le cahier des charges. Comme on le sait, un cahier des charges détaillé et bien rédigé est la clé du succès de tout projet. Plus il y a de détails dans le cahier des charges, moins il y a de déceptions comme « nous ne voulions pas ça ».
Je vais donner deux exemples de niveau de détail des exigences dans le cahier des charges :
- Les opérateurs de centres de données sont habilités à ajouter de nouveaux appareils au BMS, le plus souvent des PDU. Dans l'ancienne BMS, c'était un niveau « administrateur », permettant notamment de modifier les réglages de toutes les variables des appareils, et il était impossible de séparer les fonctions. Cela ne nous convenait pas. Dans la version de base de la nouvelle plateforme, le schéma était similaire. Nous avons immédiatement précisé dans le cahier des charges que nous souhaitions séparer ces rôles : les réglages ne devraient être modifiés que par un employé autorisé, mais les opérateurs devraient continuer à avoir la possibilité d'ajouter des dispositifs. Ce schéma a été adopté pour la mise en œuvre.
- Dans toute BMS standard, il existe trois catégories de notifications types : ROUGE – intervention immédiate requise, JAUNE – à surveiller, BLEUE – « Informationnelle ». Nous avons traditionnellement utilisé les notifications « bleues » pour surveiller les dépassements de paramètres commerciaux, par exemple, le dépassement de la puissance maximale du rack client. Ce type de notifications était destiné aux managers et n'intéressait pas le service d'exploitation, mais dans l'ancienne BMS, il obstruait régulièrement la liste des incidents actifs et gênait le travail opérationnel. Nous avons trouvé la logique et la différenciation colorée des notifications réussies et les avons conservées, cependant, dans le cahier des charges, nous avons spécifiquement indiqué que les notifications « bleues » devaient, sans distraire les agents de garde, tomber silencieusement dans une section séparée, où elles seront traitées par des experts commerciaux.
Des formats de construction de graphiques et de génération de rapports, les contours des interfaces, la liste des dispositifs à surveiller et encore de nombreuses autres choses ont été spécifiés avec un degré de détail similaire.
C'était vraiment un travail créatif de trois groupes de travail – le service client, qui dictait ses exigences et conditions ; les spécialistes techniques des deux parties, dont la tâche était de transformer ces conditions en documentation technique ; l'équipe de programmeurs du sous-traitant, qui mettait en œuvre les exigences du client selon la documentation technique élaborée... En fin de compte, nous avons adapté certaines de nos exigences non essentielles aux fonctionnalités de la plateforme existante, tandis que le sous-traitant s'est engagé à ajouter certaines fonctions pour nous.
Travail parallèle de deux systèmes
Le moment de la mise en œuvre est venu. En pratique, cela signifiait que nous donnions au sous-traitant la possibilité de déployer un prototype BMS dans notre cloud virtuel et de fournir un accès réseau à tous les dispositifs nécessitant une surveillance.
Cependant, le nouveau système n'était pas encore prêt à fonctionner. À ce stade, il était important pour nous de maintenir la surveillance dans l'ancien système tout en donnant accès aux dispositifs au nouveau système. Il est impossible de construire correctement un système sans voir les dispositifs qu'on ne peut pas déconnecter de la surveillance de l'ancien système.
Il n'était pas évident que les appareils résisteraient à une interrogation simultanée par deux systèmes sans tests réels. Il existait un risque que l'interrogation double entraîne de fréquents échecs de réponse des appareils, ce qui produirait de nombreuses erreurs de disponibilité des appareils, bloquant ainsi le fonctionnement de l'ancien système de surveillance.
Le service réseau a établi des routes virtuelles de prototype de la nouvelle BMS déployée dans le cloud vers les appareils, et nous avons obtenu les résultats suivants :
- les appareils connectés via le protocole SNMP ne se déconnectaient pratiquement pas en raison d'interrogations simultanées,
- les appareils connectés via des passerelles avec les protocoles modbas-TCP ont rencontré des problèmes, qui ont été résolus par une réduction raisonnable de la fréquence de leur interrogation.
Et ensuite, nous avons commencé à observer comment un nouveau système se construisait sous nos yeux, y intégrant déjà des appareils que nous connaissions, mais avec une interface différente – pratique, rapide, accessible même depuis un téléphone.
Nous parlerons du résultat final dans la troisième partie de notre article.
Source : habr.com
