Dans la première partie, nous avons expliqué pourquoi nous avons décidé de remplacer l'ancien système BMS de nos centres de données par un nouveau. Et ne vous contentez pas de changer, mais développez-le à partir de zéro pour répondre à vos besoins. Dans la deuxième partie, nous vous expliquons comment nous avons procédé.
Analyse de marché
Compte tenu de ceux décrits dans souhaits et décision de refuser de mettre à jour le système existant, nous avons rédigé un cahier des charges technique pour trouver une solution sur le marché et nous sommes renseignés auprès de plusieurs grandes entreprises engagées uniquement dans la création de systèmes SCADA industriels.
Les toutes premières réponses de leur part ont montré que les leaders du marché des systèmes de surveillance continuent de travailler principalement sur des serveurs matériels, même si le processus de migration vers les cloud dans ce segment a déjà commencé. Quant à la réservation de machines virtuelles, personne ne prenait en charge cette option. De plus, on avait le sentiment qu'aucun des développeurs visibles sur le marché ne faisait preuve d'une compréhension de la nécessité de la redondance : « le cloud ne tombe pas » était la réponse la plus courante. En fait, on nous a proposé de placer la surveillance du data center dans un cloud physiquement situé dans le même data center.
Ici, nous devons faire une petite parenthèse sur le processus de sélection d'un entrepreneur. Le prix, bien sûr, compte, mais lors de tout appel d'offres pour la mise en œuvre d'un projet complexe, au stade du dialogue avec les fournisseurs, on commence à sentir lequel des candidats est le plus intéressé et capable de le mettre en œuvre.
Ceci est particulièrement visible sur les projets complexes.
Sur la base de la nature des questions de clarification des spécifications techniques, les entrepreneurs peuvent être divisés en ceux intéressés par la simple vente (la pression standard d'un directeur commercial se fait sentir) et ceux intéressés par le développement d'un produit, après avoir entendu et compris le client, en faisant un travail constructif. des modifications des spécifications techniques avant même le choix final (même malgré le risque réel d'améliorer les spécifications techniques de quelqu'un d'autre et de perdre l'appel d'offres), ils sont finalement simplement prêts à relever un défi professionnel et à fabriquer un bon produit.
Tout cela nous a amené à prêter attention à un développeur local relativement petit - le groupe de sociétés Sunline, qui a immédiatement répondu à la plupart de nos exigences et était prêt à mettre en œuvre tous les besoins concernant le nouveau BMS.
Risques
Pendant que les grands acteurs essayaient de comprendre ce que nous voulions et entretenaient avec nous une correspondance tranquille impliquant des spécialistes du niveau prévente, le développeur local a programmé une réunion dans nos bureaux avec la participation de son équipe technique. Lors de cette rencontre, l'entrepreneur a une fois de plus démontré sa volonté de participer au projet et, surtout, expliqué comment le système requis serait mis en œuvre.
Avant la réunion, nous avions vu deux risques à travailler avec une équipe qui ne dispose pas derrière elle des ressources d’une grande entreprise nationale ou internationale :
- Les spécialistes pourraient surestimer leurs capacités et, par conséquent, ne pas y faire face ; par exemple, ils utiliseront des logiciels complexes ou concevront des algorithmes de réservation irréalisables.
- Une fois le projet terminé, l'équipe de projet peut se désintégrer et, par conséquent, le support produit sera menacé.
Pour minimiser ces risques, nous avons invité nos propres spécialistes du développement à la réunion. Les employés de l'entrepreneur potentiel ont été interrogés de manière approfondie sur les bases du système, la manière dont la redondance est prévue et d'autres questions pour lesquelles nous, en tant que service d'exploitation, ne sommes pas suffisamment compétents.
Le verdict a été positif : l'architecture de la plateforme BMS existante est moderne, simple et fiable, peut être améliorée, le schéma de redondance et de synchronisation proposé est logique et réalisable.
Le premier risque a été traité. Le second a été exclu après avoir reçu la confirmation de l'entrepreneur qu'il était prêt à nous transférer le code source du système et la documentation, ainsi qu'en choisissant le langage de programmation Python, bien connu de nos spécialistes. Cela nous a garanti la possibilité d'entretenir nous-mêmes le système sans aucune difficulté et une longue période de formation des employés en cas de départ du marché de la société de développement.
Un avantage supplémentaire de la plateforme était qu'elle était implémentée dans des conteneurs Docker : le noyau, l'interface Web et la base de données de produits fonctionnent dans cet environnement. Cette approche offre de nombreux avantages, notamment des paramètres prédéfinis pour la vitesse de déploiement la plus élevée de la solution par rapport à l'ajout « classique » et facile de nouveaux appareils au système. Le principe « tous ensemble » simplifie au maximum la mise en œuvre du système : il suffit de déballer le système et vous pouvez l'utiliser immédiatement.
Avec cette solution, il est plus facile de faire des copies du système, et vous pouvez l'améliorer et mettre en œuvre des mises à niveau dans un environnement séparé, sans arrêter le fonctionnement de la solution dans son ensemble.
Une fois les deux risques minimisés, l’entrepreneur a fourni le PC. Il couvrait pour nous tous les paramètres les plus importants du système BMS.
Réservation
Le nouveau système BMS devait être situé dans le cloud, sur une machine virtuelle.
Pas de matériel, pas de serveurs et tous les inconvénients 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. Il s'agit de deux systèmes entièrement fonctionnels fonctionnant en mode veille active avec accès à tous les spécialistes autorisés.
Les deux systèmes s'assurent mutuellement, fournissant une réserve complète de puissance de calcul et de canaux de transmission de données. Des mesures de sécurité supplémentaires ont également été configurées, notamment la sauvegarde des données et des canaux, des systèmes, des machines virtuelles en général, ainsi qu'une sauvegarde séparée de la base de données une fois par mois (la ressource la plus précieuse en termes de gestion et d'analyse).
A noter que la redondance en option dans la solution BMS a été développée spécifiquement pour notre demande. Le système de réservation lui-même ressemblait à ceci :
support
Le point le plus important pour le fonctionnement efficace d’une solution BMS est le support technique.
Tout est simple ici : un nouveau système nous coûterait 35 000 roubles selon cet indicateur. par mois pour le SLA « réponse dans les 8 heures », soit 35 000 x 12 / 80 = 5 250 $ par an. La première année est gratuite.
À titre de comparaison, la maintenance de l'ancien BMS du fournisseur coûtait 18 000 $ par an avec une augmentation du montant pour chaque nouvel appareil ajouté ! Dans le même temps, l'entreprise n'a pas fourni de responsable dédié, toutes les interactions ont eu lieu par l'intermédiaire d'un directeur commercial qui s'intéresse à nous en tant qu'acheteur potentiel et met l'accent sur le traitement des demandes.
Pour moins cher, nous avons bénéficié d'un support produit complet, avec un account manager qui participerait au développement du produit, avec un point d'entrée unique, etc. Le support est devenu beaucoup plus flexible - grâce à l'accès direct aux développeurs pour des ajustements rapides à n'importe quel aspect du système, à l'intégration via API, etc.
Mises à jour
Selon le CP proposé dans le nouveau BMS, toutes les mises à jour sont incluses dans le coût du support, c'est-à-dire ne nécessitent pas de paiement supplémentaire. L'exception concerne le développement de fonctionnalités supplémentaires au-delà de ce qui est spécifié dans les spécifications techniques.
L'ancien système exigeait un paiement pour les mises à jour du micrologiciel (comme Java) et les corrections de bogues. Il était impossible de refuser cela : en l'absence de mises à jour, le système dans son ensemble était « ralenti » en raison 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 fondamentale concernait l’interface. Nous souhaitions y donner accès via un navigateur web depuis n'importe où, sans la présence obligatoire d'un ingénieur sur le territoire du data center. De plus, nous avons cherché à créer une interface animée afin que la dynamique de l'infrastructure soit plus claire pour les ingénieurs en service.
Le nouveau système devait également prendre en charge les formules permettant de calculer le fonctionnement des capteurs virtuels dans les systèmes d'ingénierie, par exemple pour la répartition optimale de l'énergie électrique entre les racks d'équipement. Pour ce faire, vous devez disposer de toutes les opérations mathématiques habituelles applicables aux indicateurs de capteurs.
Ensuite, il fallait accéder à une base de données SQL avec la possibilité d'en extraire les données nécessaires sur le fonctionnement de l'équipement, à savoir tous les enregistrements de surveillance de deux mille appareils et deux mille capteurs virtuels générant environ 20 mille variables.
Un module de comptabilité des équipements de rack était également nécessaire, fournissant une représentation graphique de la disposition des appareils dans chaque unité avec calcul du poids total du matériel, conservant une bibliothèque d'appareils et des informations détaillées sur chaque élément.
Approbation des spécifications techniques et signature d’un accord
Au moment où il fallait commencer à travailler sur le nouveau système, la correspondance avec les « grandes » entreprises était encore très loin de discuter du coût de leurs propositions, nous avons donc comparé le CP reçu avec les coûts de mise à jour de l'ancien BMS (voir. ), et en conséquence, son prix s'est avéré plus attractif et répondait à nos exigences.
Le choix est fait.
Après avoir sélectionné un entrepreneur, les avocats ont commencé à rédiger un accord et les équipes techniques des deux parties ont commencé à peaufiner les spécifications techniques. Comme vous le savez, des spécifications techniques détaillées et compétentes constituent la base du succès de tout travail. Plus il y a de détails dans les spécifications techniques, moins il y a de déceptions du type « mais ce n'est pas ce que nous voulions ».
Je donnerai deux exemples du niveau de détail des exigences dans les spécifications techniques :
- Les centres de données en service sont habilités à ajouter de nouveaux appareils au BMS, le plus souvent des PDU. Dans l'ancien BMS, il s'agissait du niveau « administrateur », qui permettait également de modifier les paramètres variables de tous les appareils, et il était impossible de séparer les fonctions. Cela ne nous convenait pas. Dans la version de base existante de la nouvelle plateforme, le schéma était similaire. Nous avons immédiatement indiqué dans les termes de référence que nous souhaitions séparer ces rôles : seul un employé autorisé devrait modifier les paramètres, mais les personnes en service devraient continuer à pouvoir ajouter des appareils. Ce schéma a été accepté pour la mise en œuvre.
- Dans tout BMS standard, il existe trois catégories typiques de notifications : ROUGE - doit recevoir une réponse immédiate, JAUNE - peut être observée, BLEU - "Informationnelle". Nous utilisons traditionnellement des alertes bleues pour surveiller les dépassements de paramètres commerciaux, par exemple lorsque le rack d'un client dépasse sa limite de capacité. Ce type de notification dans notre cas était destiné aux managers et n'intéressait pas le service opérationnel, mais dans l'ancien BMS il encombrait régulièrement la liste des incidents actifs et interférait avec le travail opérationnel. Nous avons considéré que la logique même et la différenciation des couleurs des pantalons de notification étaient réussies et les avons conservées. Cependant, les spécifications techniques indiquaient spécifiquement que les notifications « bleues » devaient, sans distraire les agents de service, « couler » silencieusement dans une section séparée, où elles seront traitées par des spécialistes commerciaux.
Avec un degré de détail similaire, les formats de construction de graphiques et de génération de rapports, les contours des interfaces, la liste des appareils à surveiller et bien d'autres choses ont été prescrits.
Il s'agit d'un travail véritablement créatif de trois groupes de travail : le service client, qui a dicté ses exigences et ses conditions ; des spécialistes techniques des deux côtés, dont la tâche était de transformer ces conditions en documentation technique ; des équipes de programmeurs sous-traitants qui ont mis en œuvre les exigences du client conformément à la documentation technique développée. En conséquence, nous avons adapté certaines de nos exigences sans principes à la fonctionnalité d'une plate-forme existante et l'entrepreneur s'est engagé à ajouter quelque chose pour nous.
Fonctionnement parallèle de deux systèmes
Il est temps de mettre en œuvre. En pratique, cela signifiait que nous donnions à l'entrepreneur la possibilité de déployer un prototype BMS dans notre cloud virtuel et de fournir un accès réseau à tous les appareils nécessitant une surveillance.
Toutefois, 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 et en même temps de donner accès aux appareils au nouveau système. Il est impossible de construire correctement un système sans y voir des périphériques, dont la surveillance ne peut à son tour pas être désactivée par l'ancien système.
Il n’était pas évident de savoir si les appareils pouvaient résister à des interrogations simultanées par deux systèmes sans de véritables tests. Il était possible qu'une double interrogation simultanée conduise à de fréquents refus de réponse de la part des appareils et que nous recevions de nombreuses erreurs concernant l'indisponibilité des appareils, ce qui bloquerait à son tour le fonctionnement de l'ancien système de surveillance.
Le service réseau a exécuté des routes virtuelles depuis un prototype du nouveau BMS déployé dans le cloud jusqu'aux appareils, et nous avons obtenu les résultats :
- les appareils connectés via le protocole SNMP n'ont pratiquement jamais été déconnectés en raison de requêtes simultanées,
- les appareils connectés via des passerelles utilisant les protocoles modbas-TCP présentaient des problèmes qui ont été résolus en réduisant intelligemment leur fréquence d'interrogation.
Et puis nous avons commencé à observer comment un nouveau système se construisait sous nos yeux, des appareils qui nous étaient déjà familiers y apparaissaient, mais dans une interface différente - pratique, rapide, accessible même depuis un téléphone.
Nous vous raconterons ce qui s’est finalement passé dans la troisième partie de notre article.
Source: habr.com