Γειά σου! Είμαστε "Hosting Technologies" και ξεκινήσαμε πριν από 5 χρόνια — το πρώτο vds hosting που δημιουργήθηκε ειδικά για προγραμματιστές. Προσπαθούμε να το κάνουμε βολικό, όπως το DigitalOcean, αλλά με ρωσική υποστήριξη, μεθόδους πληρωμής και διακομιστές στη Ρωσία. Όμως το DigitalOcean δεν είναι μόνο αξιοπιστία και τιμή, είναι και υπηρεσία.
Το λογισμικό από το ISPsystem αποδείχθηκε ότι ήταν ένα σχοινί που μας έδεσε τα χέρια στο δρόμο για μια δροσερή υπηρεσία. Πριν από τρία χρόνια, χρησιμοποιήσαμε τη χρέωση Billmanager και τον πίνακα ελέγχου διακομιστή VMmanager και γρήγορα συνειδητοποιήσαμε ότι ήταν σχεδόν αδύνατο να παρέχουμε μια καλή υπηρεσία χωρίς τον δικό μας πίνακα ελέγχου.
Πώς το σύστημα ISP σκότωσε την ευκολία
Σφάλματα
Δεν μπορούσαμε να διορθώσουμε το σφάλμα μόνοι μας - κάθε φορά έπρεπε να γράφουμε στην υποστήριξη κάποιου άλλου και να περιμένουμε. Η λύση σε οποιοδήποτε πρόβλημα απαιτούσε την απάντηση τρίτης εταιρείας.
Η υποστήριξη του συστήματος ISP ανταποκρίθηκε κανονικά, αλλά οι διορθώσεις ήρθαν μόνο μετά από μερικές εκδόσεις, και μετά όχι πάντα και όχι όλες. Μερικές φορές τα κρίσιμα σφάλματα διορθώνονταν για αρκετές εβδομάδες. Έπρεπε να καθησυχάσουμε τους πελάτες, να ζητήσουμε συγγνώμη και να περιμένουμε το ISPsystem να διορθώσει το σφάλμα.
Απειλή διακοπής λειτουργίας
Οι ενημερώσεις θα μπορούσαν να δημιουργήσουν απρόβλεπτους χρόνους διακοπής λειτουργίας που προκάλεσαν νέα σφάλματα.
Κάθε ενημέρωση ήταν μια λοταρία: έπρεπε να καλύπτω τις χρεώσεις και να κάνω θυσίες στους θεούς των ενημερώσεων - μερικές φορές η ενημέρωση προκάλεσε διακοπή λειτουργίας για 10-15 λεπτά. Οι διαχειριστές μας εκείνη τη στιγμή ήταν στα μάτια τους - ποτέ δεν ξέραμε πόσο θα διαρκούσε ο χρόνος διακοπής λειτουργίας και δεν μπορούσαμε να προβλέψουμε πότε το ISPsystem θα αποφάσιζε να κυκλοφορήσει μια νέα ενημέρωση.
Στην πέμπτη γενιά, το Billmanager έγινε καλύτερο, αλλά για να αποκτήσω πρόσβαση στις απαραίτητες δυνατότητες, έπρεπε να εγκαταστήσω μια beta, η οποία ήδη ενημερωνόταν κάθε εβδομάδα. Αν κάτι έσπασε, έπρεπε να δώσω πρόσβαση σε άλλους προγραμματιστές για να διορθώσουν κάτι.
Άβολη διεπαφή πίνακα
Όλα χωρίστηκαν σε διαφορετικά πάνελ και ελέγχονταν από διαφορετικά σημεία. Για παράδειγμα, οι πελάτες πλήρωναν μέσω του Billmanager και έπρεπε να επανεκκινήσουν ή να επανεγκαταστήσουν το VDS στο VMManager. Το προσωπικό μας έπρεπε επίσης να αλλάζει μεταξύ των παραθύρων για να βοηθήσει έναν πελάτη, να ελέγξει το φορτίο στον διακομιστή του ή να δει ποιο λειτουργικό σύστημα χρησιμοποιούσε.
Μια τέτοια διεπαφή απαιτεί χρόνο - τόσο τη δική μας όσο και των πελατών μας. Δεν τίθεται θέμα ευκολίας, όπως αυτή της DigitalOcean, σε μια τέτοια κατάσταση.
Σύντομοι κύκλοι ζωής με συχνές ενημερώσεις API
Γράψαμε τις δικές μας προσθήκες - για παράδειγμα, μια προσθήκη με πρόσθετους τρόπους πληρωμής που δεν υπάρχουν στο VMManager.
Τα τελευταία χρόνια, το VMManager είχε σχετικά σύντομο κύκλο ζωής και σε νέες εκδόσεις, τα ονόματα των μεταβλητών ή των συναρτήσεων στο API μπορούσαν να αλλάξουν αυθαίρετα - αυτό έσπασε τις προσθήκες μας. Η υποστήριξη για παλαιότερες εκδόσεις καταργήθηκε γρήγορα και έπρεπε να ενημερωθεί.
Δεν είναι δυνατή η τροποποίηση
Πιο συγκεκριμένα, είναι δυνατό, αλλά εξαιρετικά αναποτελεσματικό. Οι περιορισμοί άδειας χρήσης δεν σας επιτρέπουν να κάνετε αλλαγές στον πηγαίο κώδικα, μπορείτε μόνο να γράψετε πρόσθετα. Μέγιστες προσθήκες - ορισμένα στοιχεία μενού, ένας οδηγός βήμα προς βήμα. Το σύστημα ISP έχει σχεδιαστεί για ευελιξία, αλλά χρειαζόμασταν εξειδικευμένες λύσεις.
Έτσι, η απόφαση ήταν ώριμη να γράψω το δικό μου πάνελ. Έχουμε θέσει στόχους:
- Απαντήστε γρήγορα σε σφάλματα, σφάλματα και μπορείτε να τα διορθώσετε μόνοι σας χωρίς να κάνετε τον πελάτη να περιμένει.
- Τροποποιήστε ελεύθερα τη διεπαφή για ροές εργασίας και ανάγκες πελατών.
- Αυξήστε τη χρηστικότητα με καθαρό και κατανοητό σχεδιασμό.
Και ξεκινήσαμε την ανάπτυξη.
Νέα Αρχιτεκτονική Πάνελ
Έχουμε μια αυτάρκη ομάδα ανάπτυξης, οπότε γράψαμε μόνοι μας το πάνελ.
Η κύρια εργασία έγινε από τρεις μηχανικούς - ο τεχνικός διευθυντής Sergey σκέφτηκε την αρχιτεκτονική και έγραψε τον πράκτορα διακομιστή, ο Alexey έκανε τη χρέωση και το front-end συναρμολογήθηκε από τον front-ender μας Artysh.
Βήμα 1: Πράκτορας διακομιστή
Ο παράγοντας διακομιστή είναι ένας διακομιστής ιστού python που διαχειρίζεται τη βιβλιοθήκη , που με τη σειρά του κυβερνά .
Ο πράκτορας διαχειρίζεται όλες τις υπηρεσίες στον διακομιστή: δημιουργία, διακοπή, διαγραφή vds, εγκατάσταση λειτουργικών συστημάτων, αλλαγή παραμέτρων και ούτω καθεξής μέσω της βιβλιοθήκης libvirt. Κατά τη δημοσίευση του άρθρου, πρόκειται για περισσότερες από σαράντα διαφορετικές λειτουργίες, τις οποίες συμπληρώνουμε ανάλογα με την εργασία και τις ανάγκες του πελάτη.
Θεωρητικά, το libvirt μπορούσε να ελεγχθεί απευθείας από τη χρέωση, αλλά αυτό απαιτούσε πάρα πολύ πρόσθετο κώδικα και αποφασίσαμε να διαχωρίσουμε αυτές τις λειτουργίες μεταξύ του αντιπροσώπου και της χρέωσης - η χρέωση απλώς υποβάλλει αιτήματα στον πράκτορα μέσω του JSON API.
Ο πράκτορας είναι το πρώτο πράγμα που κάναμε, καθώς δεν απαιτούσε καμία διεπαφή και ήταν δυνατό να το δοκιμάσουμε απευθείας από την κονσόλα διακομιστή.
Τι μας έδωσε ο πράκτορας διακομιστή: έχει εμφανιστεί ένα επίπεδο που απλοποιεί τη ζωή για όλους - η χρέωση δεν χρειάζεται να στείλει μια ολόκληρη δέσμη εντολών, αλλά μόνο να υποβάλει αίτημα. Και ο πράκτορας θα κάνει ό,τι χρειάζεται: για παράδειγμα, θα εκχωρήσει χώρο στο δίσκο και μνήμη RAM.
Βήμα 2. Χρέωση
Για τον προγραμματιστή μας Alex, αυτός δεν ήταν ο πρώτος πίνακας ελέγχου - ο Alex ήταν στη φιλοξενία για μεγάλο χρονικό διάστημα, επομένως κατάλαβε γενικά τι χρειαζόταν ο πελάτης και τι χρειαζόταν ο οικοδεσπότης.
Ονομάζουμε τη χρέωση μεταξύ μας "πίνακα ελέγχου": περιέχει όχι μόνο χρήματα και υπηρεσίες, αλλά και τη διαχείρισή τους, την υποστήριξη πελατών και πολλά άλλα.
Για τη μετάβαση από το λογισμικό ISPSystem, ήταν απαραίτητο να διατηρηθεί πλήρως η προηγούμενη λειτουργικότητα για τους πελάτες, να μεταφερθούν όλες οι οικονομικές ενέργειες των χρηστών από την παλιά χρέωση στη νέα, καθώς και όλες οι υπηρεσίες και οι μεταξύ τους συνδέσεις. Μελετήσαμε τι υπάρχει στο τρέχον προϊόν, στη συνέχεια τις λύσεις των ανταγωνιστών, κυρίως DO και Vultr. Εξετάσαμε τα μειονεκτήματα και τα πλεονεκτήματα, συλλέξαμε σχόλια από άτομα που εργάζονταν με παλιά προϊόντα από το σύστημα ISP.
Η νέα χρέωση χρησιμοποίησε δύο στοίβες: κλασική PHP, MySQL (και στο μέλλον σχεδιάζεται να μεταβεί σε PostgreSQL), Yii2 ως πλαίσιο στο backend και VueJS στο μπροστινό μέρος. Οι στοίβες λειτουργούν ανεξάρτητα η μία από την άλλη, αναπτύσσονται από διαφορετικά άτομα και επικοινωνούν χρησιμοποιώντας το JSON API. Για ανάπτυξη τότε και τώρα χρησιμοποιούμε и από το JetBrains και τους αγαπώ πολύ (ρε παιδιά!)
Το πάνελ έχει σχεδιαστεί σε αρθρωτή βάση: λειτουργικές μονάδες συστήματος πληρωμών, μονάδα μητρώου τομέα ή, για παράδειγμα, λειτουργική μονάδα πιστοποιητικού SSL. Μπορείτε εύκολα να προσθέσετε μια νέα λειτουργία ή να αφαιρέσετε μια παλιά. Οι βάσεις για την επέκταση τίθενται αρχιτεκτονικά, συμπεριλαμβανομένης της αντίθετης κατεύθυνσης, «προς το υλικό».
Τι πήραμε: ένας πίνακας ελέγχου στον οποίο έχουμε πλήρη έλεγχο. Τώρα τα σφάλματα διορθώνονται σε ώρες, όχι σε εβδομάδες, και οι νέες δυνατότητες υλοποιούνται κατόπιν αιτήματος των πελατών και όχι κατόπιν αιτήματος του ISPSystem.
Βήμα 3 Διασύνδεση
Η διεπαφή είναι το πνευματικό τέκνο της ομάδας μας.
Αρχικά, εξετάσαμε τι θα συνέβαινε εάν δημιουργούσαμε ένα πρόσθετο μέσω του ISPsystem API χωρίς να αλλάξουμε ουσιαστικά τίποτα στη διεπαφή. Αποδείχθηκε έτσι και αποφασίσαμε να κάνουμε τα πάντα από την αρχή.
Πιστεύαμε ότι το κύριο πράγμα είναι να κάνουμε τη διεπαφή λογική, με καθαρό και μινιμαλιστικό σχεδιασμό και τότε θα έχουμε ένα όμορφο πάνελ. Η θέση των στοιχείων συζητήθηκε στο Megaplan και η διεπαφή που βλέπουν τώρα οι χρήστες στον πίνακα ελέγχου θα γεννηθεί σταδιακά.
Η σχεδίαση της σελίδας χρέωσης ήταν η πρώτη που εμφανίστηκε, γιατί έχουμε ήδη κάνει πρόσθετα πληρωμής για το σύστημα ISP.
Frontend
Αποφάσισαν να κάνουν το πάνελ μια εφαρμογή SPA - μη απαιτητική σε πόρους και με γρήγορη φόρτωση δεδομένων. Ο front-ender μας Artysh αποφάσισε να το γράψει στο Vue — εκείνη την εποχή είχε μόλις εμφανιστεί το Vue. Υποθέσαμε ότι το πλαίσιο θα αναπτυσσόταν δυναμικά, όπως το React, μετά από κάποιο χρονικό διάστημα η κοινότητα του Vue θα αναπτυσσόταν και θα εμφανιζόταν μια θάλασσα από βιβλιοθήκες. Ποντάραμε στο Vue και δεν το μετανιώσαμε - τώρα χρειάζεται λίγος χρόνος για να προσθέσουμε νέες λειτουργίες στο μπροστινό μέρος που έχουν ήδη προγραμματιστεί στο backend. Θα σας πούμε περισσότερα για το μπροστινό πάνελ σε ξεχωριστό άρθρο.
Σύνδεση του frontend με το backend
Το frontend συνδέθηκε με το backend μέσω ειδοποιήσεων push. Έπρεπε να δουλέψω σκληρά και να γράψω τον δικό μου χειριστή, αλλά τώρα οι πληροφορίες στη σελίδα ενημερώνονται σχεδόν αμέσως.
Τι συνέβη: Η διεπαφή του πίνακα έχει γίνει πιο απλή. Το κάναμε προσαρμοστικό και η γρήγορη φόρτωση σάς επιτρέπει να το χρησιμοποιείτε ακόμη και από κινητά τηλέφωνα τα τελευταία λεπτά πριν από την απογείωση, χωρίς να εγκαταστήσετε ξεχωριστή εφαρμογή για εργασία με τον πίνακα.
Βήμα 4. Σχέδιο δοκιμών και μετεγκατάστασης
Όταν ξεκίνησαν όλα και πέρασαν οι πρώτες δοκιμές, προέκυψε το ζήτημα της μετανάστευσης. Πρώτα απ 'όλα, εγκαταστήσαμε τη χρέωση και ξεκινήσαμε να δοκιμάζουμε τη λειτουργία της με τον πράκτορα διακομιστή.
Στη συνέχεια, γράψαμε ένα απλό σενάριο που μεταφέρει τη βάση δεδομένων από την παλιά χρέωση στη νέα.
Έπρεπε να δοκιμάσω και να επανελέγξω κυριολεκτικά τα πάντα, αφού τα δεδομένα συγχωνεύτηκαν σε μια νέα βάση δεδομένων από τρεις παλιές: Billmanager, VMmanager και τον IPmanager του διαχειριστή. Ίσως οι δοκιμαστικές μετεγκαταστάσεις είναι το πιο δύσκολο πράγμα που συναντήσαμε στη διαδικασία ανάπτυξης ενός νέου πίνακα.
Μετά από επανέλεγχο, κλείσαμε την παλιά τιμολόγηση. Η μεταφορά των τελικών δεδομένων ήταν μια πολύ ανησυχητική στιγμή, αλλά, δόξα τω Θεώ, ολοκληρώθηκε σε λίγα λεπτά και χωρίς αισθητά προβλήματα. Υπήρχαν μικρά σφάλματα που διορθώσαμε κατά τη διάρκεια της εβδομάδας. Ο περισσότερος χρόνος αφιερώθηκε στη δοκιμή του τι συνέβη.
Στη συνέχεια στείλαμε επιστολές σε πελάτες με τη διεύθυνση του νέου πίνακα και τη χρέωση και κάναμε μια ανακατεύθυνση.
Εν περιλήψει: ΕΙΝΑΙ ΖΩΝΤΑΝΟ!
Χαρούμενο τέλος
Από τις πρώτες ώρες εργασίας του λογισμικού μας, νιώσαμε όλες τις απολαύσεις της μετάβασης. Ο κώδικας ήταν εντελώς δικός μας και με βολική αρχιτεκτονική και η διεπαφή ήταν καθαρή και λογική.
Πρώτη κριτική μετά την κυκλοφορία του νέου πάνελ
Ξεκινήσαμε τη διαδικασία μετάβασης τον Δεκέμβριο, την παραμονή της Πρωτοχρονιάς του 2017, όταν το φόρτο ήταν λιγότερο, για να διευκολύνουμε τη μετάβαση για τους πελάτες - σχεδόν κανείς δεν εργάζεται την παραμονή των εορτών.
Το κύριο πράγμα που αποκτήσαμε κατά τη μετάβαση στο σύστημά μας (εκτός από τη γενική αξιοπιστία και την ευκολία) είναι η δυνατότητα γρήγορης προσθήκης λειτουργιών για βασικούς πελάτες - να είναι το πρόσωπό τους, όχι ο κώλος τους.
Ποιο είναι το επόμενο;
Μεγαλώνουμε, ο όγκος δεδομένων, πελατών, δεδομένων πελατών αυξάνεται. Έπρεπε να προσθέσω έναν διακομιστή Memcached και δύο διαχειριστές ουρών με διαφορετικές εργασίες στο backend. Το frontend έχει προσωρινή αποθήκευση και τις δικές του ουρές.
Φυσικά, είχαμε ακόμα περιπέτειες καθώς το προϊόν αναπτύχθηκε και γινόταν πιο περίπλοκο, για παράδειγμα όταν προσθέσαμε το HighLoad.
Στο επόμενο άρθρο, θα σας πούμε πώς ξεκίνησε το τιμολόγιο Hi-CPU: σχετικά με το υλικό, το λογισμικό, ποιες εργασίες λύσαμε και τι κάναμε.
Πηγή: www.habr.com