Παρακολούθηση στο κέντρο δεδομένων: πώς αλλάξαμε το παλιό BMS σε νέο. Μέρος 2ο

Παρακολούθηση στο κέντρο δεδομένων: πώς αλλάξαμε το παλιό BMS σε νέο. Μέρος 2ο

Στο πρώτο μέρος, μιλήσαμε για το γιατί αποφασίσαμε να αντικαταστήσουμε το παλιό σύστημα BMS στα κέντρα δεδομένων μας με ένα νέο. Και όχι απλώς αλλάξτε, αλλά αναπτύξτε από την αρχή για να ανταποκρίνεται στις απαιτήσεις σας. Στο δεύτερο μέρος σας λέμε πώς τα καταφέραμε.

Η ανάλυση της αγοράς

Λαμβάνοντας υπόψη αυτά που περιγράφονται στο το πρώτο μέρος επιθυμίες και την απόφαση να αρνηθούμε την ενημέρωση του υπάρχοντος συστήματος, γράψαμε μια τεχνική προδιαγραφή για να βρούμε μια λύση στην αγορά και κάναμε έρευνες σε πολλές μεγάλες εταιρείες που ασχολούνται μόνο με τη δημιουργία βιομηχανικών συστημάτων SCADA. 

Οι πρώτες απαντήσεις από αυτούς έδειξαν ότι οι ηγέτες της αγοράς συστημάτων παρακολούθησης συνεχίζουν να εργάζονται κυρίως σε διακομιστές υλικού, αν και η διαδικασία μετάβασης στα σύννεφα σε αυτό το τμήμα έχει ήδη ξεκινήσει. Όσον αφορά την κράτηση εικονικών μηχανών, κανείς δεν υποστήριξε αυτήν την επιλογή. Επιπλέον, υπήρχε η αίσθηση ότι κανένας από τους προγραμματιστές που ήταν ορατός στην αγορά δεν έδειξε καν ότι κατανοούσε την ανάγκη για πλεονασμό: «το σύννεφο δεν πέφτει» ήταν η πιο κοινή απάντηση. Στην πραγματικότητα, μας προτάθηκε να τοποθετήσουμε την παρακολούθηση του κέντρου δεδομένων σε ένα σύννεφο που βρίσκεται φυσικά στο ίδιο κέντρο δεδομένων.

Εδώ πρέπει να κάνουμε μια μικρή παρέκβαση σχετικά με τη διαδικασία επιλογής αναδόχου. Η τιμή, φυσικά, έχει σημασία, αλλά σε κάθε διαγωνισμό για την υλοποίηση ενός σύνθετου έργου, στο στάδιο του διαλόγου με τους προμηθευτές, αρχίζεις να αισθάνεσαι ποιος από τους υποψηφίους ενδιαφέρεται περισσότερο και είναι ικανός να το υλοποιήσει. 

Αυτό είναι ιδιαίτερα αισθητό σε πολύπλοκα έργα. 

Με βάση τη φύση των διευκρινιστικών ερωτήσεων στις τεχνικές προδιαγραφές, οι εργολάβοι μπορούν να χωριστούν σε αυτούς που ενδιαφέρονται απλώς να πουλήσουν (αισθάνεται η τυπική πίεση ενός διευθυντή πωλήσεων) και σε όσους ενδιαφέρονται να αναπτύξουν ένα προϊόν, έχοντας ακούσει και κατανοήσει τον πελάτη, κάνοντας εποικοδομητικό τροποποιήσεις των τεχνικών προδιαγραφών ακόμη και πριν την τελική επιλογή (ακόμα και παρά τον πραγματικό κίνδυνο βελτίωσης των τεχνικών προδιαγραφών κάποιου άλλου και απώλειας του διαγωνισμού), στο τέλος είναι απλά έτοιμοι να δεχτούν μια επαγγελματική πρόκληση και να φτιάξουν ένα καλό προϊόν.

Όλα αυτά μας έκαναν να δώσουμε προσοχή σε έναν σχετικά μικρό τοπικό προγραμματιστή - τον όμιλο εταιρειών Sunline, ο οποίος ανταποκρίθηκε άμεσα στις περισσότερες απαιτήσεις μας και ήταν έτοιμος να υλοποιήσει όλες τις ανάγκες σχετικά με το νέο BMS. 

Κίνδυνοι

Ενώ οι μεγάλοι παίκτες προσπαθούσαν να καταλάβουν τι θέλαμε και συνέχιζαν χαλαρή αλληλογραφία μαζί μας με ειδικούς σε επίπεδο προπώλησης, ο τοπικός προγραμματιστής προγραμμάτισε μια συνάντηση στο γραφείο μας με τη συμμετοχή της τεχνικής του ομάδας. Στη συνάντηση αυτή, ο ανάδοχος έδειξε για άλλη μια φορά την επιθυμία του να συμμετάσχει στο έργο και, κυρίως, εξήγησε πώς θα εφαρμοστεί το απαιτούμενο σύστημα.    

Πριν από τη συνάντηση, είδαμε δύο κινδύνους από τη συνεργασία με μια ομάδα που δεν έχει τους πόρους μιας μεγάλης εθνικής ή διεθνούς εταιρείας πίσω της:

  1. Οι ειδικοί θα μπορούσαν να υπερεκτιμήσουν τις δυνατότητές τους και, ως αποτέλεσμα, απλώς να αποτύχουν να αντεπεξέλθουν· για παράδειγμα, θα χρησιμοποιήσουν πολύπλοκο λογισμικό ή θα σχεδιάσουν αλγόριθμους κράτησης που δεν μπορούν να πραγματοποιηθούν.
  2. Μετά την ολοκλήρωση του έργου, η ομάδα του έργου μπορεί να αποσυντεθεί και, ως εκ τούτου, η υποστήριξη προϊόντων θα τεθεί σε κίνδυνο.

Για να ελαχιστοποιήσουμε αυτούς τους κινδύνους, προσκαλέσαμε τους δικούς μας ειδικούς ανάπτυξης στη συνάντηση. Οι υπάλληλοι του πιθανού εργολάβου πήραν διεξοδική συνέντευξη σχετικά με το σε τι βασίζεται το σύστημα, πώς σχεδιάζεται να εφαρμοστεί η απόλυση και άλλα θέματα στα οποία εμείς, ως λειτουργική υπηρεσία, δεν είμαστε αρκετά ικανοί.

Η ετυμηγορία ήταν θετική: η αρχιτεκτονική της υπάρχουσας πλατφόρμας BMS είναι σύγχρονη, απλή και αξιόπιστη, μπορεί να βελτιωθεί, το προτεινόμενο σχέδιο πλεονασμού και συγχρονισμού είναι λογικό και εφαρμόσιμο. 

Ο πρώτος κίνδυνος αντιμετωπίστηκε. Το δεύτερο αποκλείστηκε μετά από επιβεβαίωση από τον ανάδοχο ότι ήταν έτοιμοι να μεταφέρουν τον πηγαίο κώδικα του συστήματος και την τεκμηρίωση σε εμάς, καθώς και επιλέγοντας τη γλώσσα προγραμματισμού Python, η οποία ήταν πολύ γνωστή στους ειδικούς μας. Αυτό μας εγγυήθηκε την ευκαιρία να διατηρήσουμε το σύστημα μόνοι μας χωρίς δυσκολίες και μια μακρά περίοδο εκπαίδευσης των εργαζομένων σε περίπτωση που η εταιρεία ανάπτυξης εγκαταλείψει την αγορά.

Ένα επιπλέον πλεονέκτημα της πλατφόρμας ήταν ότι υλοποιήθηκε σε κοντέινερ Docker: ο πυρήνας, η διεπαφή ιστού και η βάση δεδομένων προϊόντων λειτουργούν σε αυτό το περιβάλλον. Αυτή η προσέγγιση παρέχει πολλά πλεονεκτήματα, συμπεριλαμβανομένων των προκαθορισμένων ρυθμίσεων για την υψηλότερη ταχύτητα ανάπτυξης της λύσης σε σύγκριση με την «κλασική» και εύκολη προσθήκη νέων συσκευών στο σύστημα. Η αρχή «όλα μαζί» απλοποιεί την εφαρμογή του συστήματος όσο το δυνατόν περισσότερο: απλώς αποσυσκευάστε το σύστημα και μπορείτε να το χρησιμοποιήσετε αμέσως. 

Με αυτήν τη λύση, είναι πιο εύκολο να δημιουργήσετε αντίγραφα του συστήματος και μπορείτε να το βελτιώσετε και να εφαρμόσετε αναβαθμίσεις σε ξεχωριστό περιβάλλον, χωρίς να σταματήσετε τη λειτουργία της λύσης στο σύνολό της.  

Μόλις ελαχιστοποιήθηκαν και οι δύο κίνδυνοι, ο ανάδοχος παρείχε το CP. Κάλυψε όλες τις πιο σημαντικές παραμέτρους του συστήματος BMS για εμάς.

Rezervirovanye

Το νέο σύστημα BMS έπρεπε να βρίσκεται στο cloud, σε μια εικονική μηχανή. 

Χωρίς υλικό, χωρίς διακομιστές και όλες τις ενοχλήσεις και τους κινδύνους που σχετίζονται με αυτό το μοντέλο ανάπτυξης - η λύση cloud μας επέτρεψε να απαλλαγούμε από αυτά για πάντα. Αποφασίστηκε ότι το σύστημα θα λειτουργούσε στο cloud μας σε δύο τοποθεσίες κέντρων δεδομένων στην Αγία Πετρούπολη και τη Μόσχα. Πρόκειται για δύο πλήρως λειτουργικά συστήματα που λειτουργούν σε κατάσταση ενεργής αναμονής με πρόσβαση σε όλους τους εξουσιοδοτημένους ειδικούς. 

Τα δύο συστήματα ασφαλίζουν το ένα το άλλο, παρέχοντας πλήρη απόθεμα τόσο της υπολογιστικής ισχύος όσο και των καναλιών μετάδοσης δεδομένων. Έχουν επίσης διαμορφωθεί πρόσθετα μέτρα ασφαλείας, συμπεριλαμβανομένης της δημιουργίας αντιγράφων ασφαλείας δεδομένων και καναλιών, συστημάτων, εικονικών μηχανών γενικά και ξεχωριστού αντιγράφου ασφαλείας βάσης δεδομένων μία φορά το μήνα (ο πιο πολύτιμος πόρος από άποψη διαχείρισης και ανάλυσης). 

Σημειώστε ότι ο πλεονασμός ως επιλογή στη λύση BMS αναπτύχθηκε ειδικά για το αίτημά μας. Το ίδιο το πρόγραμμα κρατήσεων φαινόταν ως εξής:

Παρακολούθηση στο κέντρο δεδομένων: πώς αλλάξαμε το παλιό BMS σε νέο. Μέρος 2ο

Υποστήριξη

Το πιο σημαντικό σημείο για την αποτελεσματική λειτουργία μιας λύσης BMS είναι η τεχνική υποστήριξη. 

Όλα είναι απλά εδώ: ένα νέο σύστημα θα μας κόστιζε 35 ρούβλια σύμφωνα με αυτόν τον δείκτη. ανά μήνα για το SLA "απόκριση εντός 000 ωρών", δηλαδή 8 x 35 / 000 = 12 $ ετησίως. Το πρώτο έτος είναι δωρεάν. 

Για σύγκριση, η διατήρηση του παλιού BMS από τον πωλητή κόστιζε 18 $ ετησίως με αύξηση του ποσού για κάθε νέα συσκευή που προστίθεται! Ταυτόχρονα, η εταιρεία δεν παρείχε ειδικό διευθυντή· όλη η αλληλεπίδραση πραγματοποιήθηκε μέσω ενός διευθυντή πωλήσεων που ενδιαφέρεται για εμάς ως υποψήφιο αγοραστή με ανάλογη έμφαση στην επεξεργασία των αιτημάτων. 

Για λιγότερα χρήματα, λάβαμε πλήρη υποστήριξη προϊόντων, με έναν διαχειριστή λογαριασμού που θα συμμετείχε στην ανάπτυξη προϊόντων, με ένα μόνο σημείο εισόδου κ.λπ. Η υποστήριξη έγινε πολύ πιο ευέλικτη - χάρη στην άμεση πρόσβαση στους προγραμματιστές για γρήγορες προσαρμογές σε οποιαδήποτε πτυχή του συστήματος, ενσωμάτωση μέσω API κ.λπ.

Ενημερώσεις

Σύμφωνα με το προτεινόμενο CP στο νέο BMS, όλες οι ενημερώσεις περιλαμβάνονται στο κόστος υποστήριξης, δηλ. δεν απαιτούν πρόσθετη πληρωμή. Η εξαίρεση είναι η ανάπτυξη πρόσθετης λειτουργικότητας πέρα ​​από αυτό που καθορίζεται στις τεχνικές προδιαγραφές. 

Το παλιό σύστημα απαιτούσε πληρωμή τόσο για ενημερώσεις υλικολογισμικού (όπως Java) όσο και για διορθώσεις σφαλμάτων. Ήταν αδύνατο να το αρνηθεί κανείς· ελλείψει ενημερώσεων, το σύστημα στο σύνολό του "επιβράδυνε" λόγω παλαιών εκδόσεων εσωτερικών στοιχείων.

Και, φυσικά, ήταν αδύνατο να ενημερώσετε το λογισμικό χωρίς να αγοράσετε ένα πακέτο υποστήριξης.

Ευέλικτη προσέγγιση

Μια άλλη βασική απαίτηση αφορούσε τη διεπαφή. Θέλαμε να παρέχουμε πρόσβαση σε αυτό μέσω ενός προγράμματος περιήγησης ιστού από οπουδήποτε, χωρίς την υποχρεωτική παρουσία μηχανικού στην επικράτεια του κέντρου δεδομένων. Επιπλέον, επιδιώξαμε να δημιουργήσουμε μια κινούμενη διεπαφή, ώστε η δυναμική της υποδομής να είναι πιο ξεκάθαρη στους μηχανικούς που βρίσκονταν σε υπηρεσία. 

Επίσης, στο νέο σύστημα ήταν απαραίτητο να παρασχεθεί υποστήριξη για τύπους για τον υπολογισμό της λειτουργίας εικονικών αισθητήρων σε συστήματα μηχανικής - για παράδειγμα, για τη βέλτιστη κατανομή ηλεκτρικής ενέργειας σε ράφια εξοπλισμού. Για να γίνει αυτό, πρέπει να έχετε στη διάθεσή σας όλες τις συνήθεις μαθηματικές πράξεις που ισχύουν για τους δείκτες αισθητήρων. 

Στη συνέχεια, απαιτήθηκε πρόσβαση σε μια βάση δεδομένων SQL με τη δυνατότητα λήψης από αυτήν των απαραίτητων δεδομένων για τη λειτουργία του εξοπλισμού - συγκεκριμένα, όλα τα αρχεία παρακολούθησης δύο χιλιάδων συσκευών και δύο χιλιάδων εικονικών αισθητήρων που παράγουν περίπου 20 χιλιάδες μεταβλητές. 

Χρειαζόταν επίσης μια ενότητα για τον λογιστικό εξοπλισμό στο ράφι, η οποία παρείχε μια γραφική αναπαράσταση της διάταξης των συσκευών σε κάθε μονάδα με υπολογισμό του συνολικού βάρους του υλικού, διατηρώντας μια βιβλιοθήκη συσκευών και λεπτομερείς πληροφορίες για κάθε στοιχείο. 

Έγκριση τεχνικών προδιαγραφών και υπογραφή σύμβασης

Την εποχή που ήταν απαραίτητο να ξεκινήσουν οι εργασίες για το νέο σύστημα, η αλληλογραφία με «μεγάλες» εταιρείες απείχε ακόμη πολύ από το να συζητηθεί το κόστος των προτάσεών τους, επομένως συγκρίναμε το ληφθέν CP με το κόστος ενημέρωσης του παλιού BMS (βλ. πρώτο μέρος), και ως αποτέλεσμα αποδείχθηκε πιο ελκυστικό σε τιμή και ανταποκρίνεται στις απαιτήσεις μας.

Η επιλογή έχει γίνει.

Αφού επέλεξαν έναν ανάδοχο, οι δικηγόροι άρχισαν να συντάσσουν συμφωνία και οι τεχνικές ομάδες και από τις δύο πλευρές άρχισαν να γυαλίζουν τις τεχνικές προδιαγραφές. Όπως γνωρίζετε, οι λεπτομερείς και ικανές τεχνικές προδιαγραφές αποτελούν τη βάση για την επιτυχία κάθε εργασίας. Όσο περισσότερες λεπτομέρειες υπάρχουν στις τεχνικές προδιαγραφές, τόσο λιγότερες απογοητεύσεις τύπου «αλλά δεν είναι αυτό που θέλαμε».

Θα δώσω δύο παραδείγματα του επιπέδου λεπτομέρειας των απαιτήσεων στις τεχνικές προδιαγραφές:

  1. Τα κέντρα δεδομένων που βρίσκονται σε υπηρεσία έχουν την εξουσία να προσθέτουν νέες συσκευές στο BMS, τις περισσότερες φορές αυτές είναι PDU. Στο παλιό BMS, αυτό ήταν το επίπεδο "διαχειριστής", το οποίο επέτρεπε επίσης την αλλαγή των ρυθμίσεων μεταβλητών όλων των συσκευών και ήταν αδύνατο να διαχωριστούν οι λειτουργίες. Αυτό δεν μας ταίριαζε. Στην υπάρχουσα βασική έκδοση της νέας πλατφόρμας, το σχήμα ήταν παρόμοιο. Υποδείξαμε αμέσως στους όρους εντολής ότι θέλαμε να διαχωρίσουμε αυτούς τους ρόλους: μόνο ένας εξουσιοδοτημένος υπάλληλος θα πρέπει να αλλάξει τις ρυθμίσεις, αλλά όσοι βρίσκονται σε υπηρεσία θα πρέπει να συνεχίσουν να μπορούν να προσθέτουν συσκευές. Αυτό το σχέδιο έγινε δεκτό για εφαρμογή.
  2.  Σε κάθε τυπικό BMS υπάρχουν τρεις τυπικές κατηγορίες ειδοποιήσεων: ΚΟΚΚΙΝΟ - πρέπει να ανταποκριθεί αμέσως, ΚΙΤΡΙΝΟ - μπορεί να παρατηρηθεί, ΜΠΛΕ - "Πληροφοριακή". Χρησιμοποιούμε παραδοσιακά μπλε ειδοποιήσεις για να παρακολουθούμε πότε έχει γίνει υπέρβαση των παραμέτρων της επιχείρησης, όπως το ράφι ενός πελάτη που υπερβαίνει το όριο χωρητικότητάς του. Αυτός ο τύπος ειδοποίησης στην περίπτωσή μας προοριζόταν για διευθυντές και δεν ενδιέφερε την υπηρεσία λειτουργιών, αλλά στο παλιό BMS έφραζε τακτικά τη λίστα των ενεργών συμβάντων και παρενέβαινε στις επιχειρησιακές εργασίες. Θεωρήσαμε επιτυχημένη την ίδια τη λογική και τη χρωματική διαφοροποίηση του παντελονιού κοινοποίησης και τη διατηρήσαμε, ωστόσο, οι τεχνικές προδιαγραφές έδειχναν συγκεκριμένα ότι οι «μπλε» ειδοποιήσεις θα έπρεπε, χωρίς να αποσπούν την προσοχή των αξιωματικών υπηρεσίας, να «χύνονται» σιωπηλά σε ξεχωριστό τμήμα, όπου θα αντιμετωπιστεί από εμπορικούς ειδικούς.

Με παρόμοιο βαθμό λεπτομέρειας, ορίστηκαν οι μορφές για την κατασκευή γραφημάτων και τη δημιουργία αναφορών, τα περιγράμματα των διεπαφών, ο κατάλογος των συσκευών που έπρεπε να παρακολουθούνται και πολλά άλλα πράγματα. 

Αυτή ήταν μια πραγματικά δημιουργική δουλειά τριών ομάδων εργασίας - της εξυπηρέτησης πελατών, η οποία υπαγόρευσε τις απαιτήσεις και τις προϋποθέσεις της. τεχνικούς ειδικούς και στις δύο πλευρές, καθήκον των οποίων ήταν να μετατρέψουν αυτές τις συνθήκες σε τεχνική τεκμηρίωση. ομάδες εργολάβων προγραμματιστών που υλοποίησαν τις απαιτήσεις του πελάτη σύμφωνα με την αναπτυγμένη τεχνική τεκμηρίωση... Ως αποτέλεσμα, προσαρμόσαμε ορισμένες από τις μη αρχές μας απαιτήσεις στη λειτουργικότητα μιας υπάρχουσας πλατφόρμας και ο ανάδοχος ανέλαβε να προσθέσει κάτι για εμάς. 

Παράλληλη λειτουργία δύο συστημάτων

Παρακολούθηση στο κέντρο δεδομένων: πώς αλλάξαμε το παλιό BMS σε νέο. Μέρος 2ο
Ήρθε η ώρα της υλοποίησης. Στην πράξη, αυτό σήμαινε ότι δίνουμε στον ανάδοχο την ευκαιρία να αναπτύξει ένα πρωτότυπο BMS στο εικονικό μας σύννεφο και να παρέχουμε πρόσβαση στο δίκτυο σε όλες τις συσκευές που απαιτούν παρακολούθηση.

Ωστόσο, το νέο σύστημα δεν ήταν ακόμη έτοιμο για λειτουργία. Σε αυτό το στάδιο, ήταν σημαντικό για εμάς να διατηρήσουμε την παρακολούθηση στο παλιό σύστημα και ταυτόχρονα να δώσουμε πρόσβαση στις συσκευές στο νέο σύστημα. Είναι αδύνατο να κατασκευαστεί σωστά ένα σύστημα χωρίς να δεις συσκευές σε αυτό, οι οποίες με τη σειρά τους δεν μπορούν να απενεργοποιηθούν από την παρακολούθηση από το παλιό σύστημα. 

Το αν οι συσκευές μπορούσαν να αντέξουν την ταυτόχρονη ανάκριση από δύο συστήματα δεν ήταν προφανές χωρίς πραγματικές δοκιμές. Υπήρχε πιθανότητα η διπλή ταυτόχρονη ψηφοφορία να οδηγήσει σε συχνές αρνήσεις απάντησης από συσκευές και να λαμβάνουμε πολλά σφάλματα σχετικά με τη μη διαθεσιμότητα συσκευών, κάτι που με τη σειρά του θα εμπόδιζε τη λειτουργία του παλιού συστήματος παρακολούθησης.

Το τμήμα δικτύου έτρεξε εικονικές διαδρομές από ένα πρωτότυπο του νέου BMS που έχει αναπτυχθεί στο cloud στις συσκευές και πήραμε τα αποτελέσματα: 

  • συσκευές που συνδέονται μέσω του πρωτοκόλλου SNMP ουσιαστικά δεν αποσυνδέθηκαν ποτέ λόγω ταυτόχρονων αιτημάτων, 
  • συσκευές που συνδέονταν μέσω πυλών χρησιμοποιώντας πρωτόκολλα modbas-TCP είχαν προβλήματα που επιλύθηκαν μειώνοντας έξυπνα τη συχνότητα μέτρησης.  

Και τότε αρχίσαμε να παρατηρούμε πώς κατασκευαζόταν ένα νέο σύστημα μπροστά στα μάτια μας, εμφανίστηκαν συσκευές ήδη γνωστές σε εμάς, αλλά σε διαφορετική διεπαφή - βολική, γρήγορη, προσβάσιμη ακόμη και από ένα τηλέφωνο.

Θα σας πούμε τι συνέβη τελικά στο τρίτο μέρος του άρθρου μας.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο