Ο διευθυντής Λειτουργιών της πύλης Banki.ru Andrey Nikolsky μίλησε στο περσινό συνέδριο σχετικά με τις υπηρεσίες ορφανών: πώς να εντοπίσετε ένα ορφανό στην υποδομή, γιατί οι ορφανές υπηρεσίες είναι κακές, τι να κάνετε με αυτές και τι να κάνετε εάν τίποτα δεν βοηθά.
Κάτω από την περικοπή υπάρχει μια έκδοση κειμένου της αναφοράς.
Γεια σας συνάδελφοι! Το όνομά μου είναι Andrey, διευθύνω τις επιχειρήσεις στο Banki.ru.
Έχουμε μεγάλες υπηρεσίες, αυτές είναι τέτοιες μονολιθικές υπηρεσίες, υπάρχουν υπηρεσίες με μια πιο κλασική έννοια και υπάρχουν πολύ μικρές. Στην ορολογία εργατών-αγροτών, λέω ότι αν μια υπηρεσία είναι απλή και μικρή, τότε είναι μικρο, και αν δεν είναι πολύ απλή και μικρή, τότε είναι απλώς μια υπηρεσία.
Πλεονεκτήματα των υπηρεσιών
Θα εξετάσω γρήγορα τα πλεονεκτήματα των υπηρεσιών.
Το πρώτο είναι η κλιμάκωση. Μπορείτε να κάνετε γρήγορα κάτι στην υπηρεσία και να ξεκινήσετε την παραγωγή. Έχετε λάβει κίνηση, έχετε κλωνοποιήσει την υπηρεσία. Έχετε περισσότερη επισκεψιμότητα, το έχετε κλωνοποιήσει και ζείτε με αυτό. Αυτό είναι ένα καλό μπόνους, και, καταρχήν, όταν ξεκινήσαμε, θεωρήθηκε το πιο σημαντικό πράγμα για εμάς, γιατί τα κάνουμε όλα αυτά.
Δεύτερον, μεμονωμένη ανάπτυξη, όταν έχετε πολλές ομάδες ανάπτυξης, πολλούς διαφορετικούς προγραμματιστές σε κάθε ομάδα και κάθε ομάδα αναπτύσσει τη δική της υπηρεσία.
Με τις ομάδες υπάρχει μια απόχρωση. Οι προγραμματιστές είναι διαφορετικοί. Και υπάρχουν, για παράδειγμα, . Το είδα για πρώτη φορά με τον Maxim Dorofeev. Μερικές φορές οι άνθρωποι με νιφάδες χιονιού είναι σε ορισμένες ομάδες και όχι σε άλλες. Αυτό κάνει τις διάφορες υπηρεσίες που χρησιμοποιούνται σε όλη την εταιρεία λίγο ανομοιόμορφες.
Κοιτάξτε την εικόνα: αυτός είναι ένας καλός προγραμματιστής, έχει μεγάλα χέρια, μπορεί να κάνει πολλά. Το κύριο πρόβλημα είναι από πού προέρχονται αυτά τα χέρια.
Οι υπηρεσίες καθιστούν δυνατή τη χρήση διαφορετικών γλωσσών προγραμματισμού που είναι πιο κατάλληλες για διαφορετικές εργασίες. Κάποια υπηρεσία είναι στο Go, κάποια στο Erlang, κάποια στο Ruby, κάτι στην PHP, κάτι στην Python. Γενικά, μπορείτε να επεκταθείτε πολύ ευρέως. Υπάρχουν και εδώ αποχρώσεις.
Η αρχιτεκτονική προσανατολισμένη στις υπηρεσίες αφορά κυρίως το devops. Δηλαδή, εάν δεν έχετε αυτοματισμό, δεν υπάρχει διαδικασία ανάπτυξης, εάν τη ρυθμίσετε χειροκίνητα, οι διαμορφώσεις σας μπορούν να αλλάξουν από παράδειγμα υπηρεσίας σε παράδειγμα και πρέπει να πάτε εκεί για να κάνετε κάτι, τότε είστε στην κόλαση.
Για παράδειγμα, έχετε 20 υπηρεσίες και πρέπει να αναπτύξετε με το χέρι, έχετε 20 κονσόλες και ταυτόχρονα πατάτε το «enter» σαν νίντζα. Δεν είναι πολύ καλό.
Αν έχεις σέρβις μετά από δοκιμή (αν υπάρχει δοκιμή φυσικά) και πρέπει ακόμα να το τελειώσεις με αρχείο για να λειτουργήσει στην παραγωγή, σου έχω και άσχημα νέα.
Εάν βασίζεστε σε συγκεκριμένες υπηρεσίες της Amazon και εργάζεστε στη Ρωσία, τότε πριν από δύο μήνες είχατε επίσης το "Όλα γύρω καίγονται, είμαι καλά, όλα είναι ωραία".
Χρησιμοποιούμε το Ansible για την αυτοματοποίηση της ανάπτυξης, το Puppet για τη σύγκλιση, το Bamboo για την αυτοματοποίηση της ανάπτυξης και το Confluence για να τα περιγράψουμε όλα.
Δεν θα σταθώ σε αυτό λεπτομερώς, διότι η έκθεση αφορά περισσότερο τις πρακτικές αλληλεπίδρασης και όχι την τεχνική εφαρμογή.
Για παράδειγμα, είχαμε προβλήματα όπου το Puppet στον διακομιστή λειτουργεί με το Ruby 2, αλλά κάποια εφαρμογή είναι γραμμένη για το Ruby 1.8 και δεν λειτουργούν μαζί. Κάτι δεν πάει καλά εκεί. Και όταν χρειάζεται να εκτελέσετε πολλές εκδόσεις του Ruby σε ένα μηχάνημα, συνήθως αρχίζετε να αντιμετωπίζετε προβλήματα.
Για παράδειγμα, δίνουμε σε κάθε προγραμματιστή μια πλατφόρμα στην οποία υπάρχουν περίπου όλα όσα έχουμε, όλες οι υπηρεσίες που μπορούν να αναπτυχθούν, ώστε να έχει ένα απομονωμένο περιβάλλον, να μπορεί να το σπάσει και να το χτίσει όπως θέλει.
Συμβαίνει να χρειάζεστε κάποιο ειδικά μεταγλωττισμένο πακέτο με υποστήριξη για κάτι εκεί. Είναι αρκετά σκληρό. Άκουσα μια αναφορά όπου η εικόνα του Docker ζυγίζει 45 GB. Στο Linux, φυσικά, είναι πιο απλό, όλα είναι μικρότερα εκεί, αλλά και πάλι δεν θα υπάρχει αρκετός χώρος.
Λοιπόν, υπάρχουν αντικρουόμενες εξαρτήσεις, όταν ένα κομμάτι του έργου εξαρτάται από μια βιβλιοθήκη μιας έκδοσης, ένα άλλο κομμάτι του έργου εξαρτάται από μια άλλη έκδοση και οι βιβλιοθήκες δεν εγκαθίστανται καθόλου μαζί.
Έχουμε τοποθεσίες και υπηρεσίες στην PHP 5.6, ντρεπόμαστε για αυτά, αλλά τι μπορούμε να κάνουμε; Αυτή είναι η μοναδική μας τοποθεσία. Υπάρχουν ιστότοποι και υπηρεσίες στην PHP 7, υπάρχουν περισσότερες από αυτές, δεν ντρεπόμαστε για αυτές. Και κάθε προγραμματιστής έχει τη δική του βάση όπου βλέπει με χαρά.
Εάν γράφετε σε μια εταιρεία σε μία γλώσσα, τότε τρεις εικονικές μηχανές ανά προγραμματιστή ακούγονται φυσιολογικά. Εάν έχετε διαφορετικές γλώσσες προγραμματισμού, τότε η κατάσταση χειροτερεύει.
Έχετε τοποθεσίες και υπηρεσίες σε αυτό, σε αυτό, στη συνέχεια έναν άλλο ιστότοπο για το Go, έναν ιστότοπο για τη Ruby και μερικά άλλα Redis στο πλάι. Ως αποτέλεσμα, όλα αυτά μετατρέπονται σε ένα μεγάλο πεδίο υποστήριξης και όλη την ώρα κάποιο από αυτά μπορεί να σπάσει.
Επομένως, αντικαταστήσαμε τα οφέλη της γλώσσας προγραμματισμού με τη χρήση διαφορετικών πλαισίων, καθώς τα πλαίσια PHP είναι αρκετά διαφορετικά, έχουν διαφορετικές δυνατότητες, διαφορετικές κοινότητες και διαφορετική υποστήριξη. Και μπορείτε να γράψετε μια υπηρεσία ώστε να έχετε ήδη κάτι έτοιμο για αυτήν.
Κάθε υπηρεσία έχει τη δική της ομάδα
Το κύριο πλεονέκτημά μας, που έχει αποκρυσταλλωθεί εδώ και πολλά χρόνια, είναι ότι κάθε υπηρεσία έχει τη δική της ομάδα. Αυτό είναι βολικό για ένα μεγάλο έργο, μπορείτε να εξοικονομήσετε χρόνο στην τεκμηρίωση, οι διαχειριστές γνωρίζουν καλά το έργο τους.
Μπορείτε εύκολα να υποβάλετε εργασίες από την υποστήριξη. Για παράδειγμα, χάλασε η ασφαλιστική υπηρεσία. Και αμέσως η ομάδα που ασχολείται με το ασφαλιστικό πάει να το φτιάξει.
Νέα χαρακτηριστικά δημιουργούνται γρήγορα, επειδή όταν έχετε μία ατομική υπηρεσία, μπορείτε γρήγορα να βιδώσετε κάτι σε αυτήν.
Και όταν διακόψετε την υπηρεσία σας, και αυτό αναπόφευκτα συμβαίνει, δεν επηρεάσατε τις υπηρεσίες άλλων ανθρώπων και προγραμματιστές από άλλες ομάδες δεν έρχονται τρέχοντας κοντά σας με κουβέντες και λένε: "Άι-άι, μην το κάνεις αυτό".
Όπως πάντα, υπάρχουν αποχρώσεις. Έχουμε σταθερές ομάδες, οι μάνατζερ είναι καρφωμένοι στην ομάδα. Υπάρχουν ξεκάθαρα έγγραφα, οι διευθυντές παρακολουθούν στενά τα πάντα. Κάθε ομάδα με έναν μάνατζερ έχει πολλές υπηρεσίες και υπάρχει ένα συγκεκριμένο σημείο αρμοδιότητας.
Εάν οι ομάδες αιωρούνται (το χρησιμοποιούμε επίσης μερικές φορές), υπάρχει μια καλή μέθοδος που ονομάζεται "star map".
Έχετε μια λίστα υπηρεσιών και ατόμων. Ένας αστερίσκος σημαίνει ότι το άτομο είναι ειδικός σε αυτήν την υπηρεσία, ένα βιβλίο σημαίνει ότι το άτομο μελετά αυτήν την υπηρεσία. Η αποστολή του ατόμου είναι να αλλάξει το φυλλάδιο με έναν αστερίσκο. Και αν δεν γράφεται τίποτα μπροστά από την υπηρεσία, τότε αρχίζουν τα προβλήματα, για τα οποία θα μιλήσω περαιτέρω.
Πώς εμφανίζονται οι ορφανές υπηρεσίες;
Το πρώτο πρόβλημα, ο πρώτος τρόπος για να αποκτήσετε μια ορφανή υπηρεσία στην υποδομή σας είναι να απολύσετε ανθρώπους. Είχε ποτέ κανείς μια επιχείρηση να τηρήσει τις προθεσμίες πριν από την αξιολόγηση των εργασιών; Μερικές φορές συμβαίνει ότι οι προθεσμίες είναι περιορισμένες και απλώς δεν υπάρχει αρκετός χρόνος για τεκμηρίωση. «Πρέπει να παραδώσουμε την υπηρεσία στην παραγωγή και μετά θα την προσθέσουμε».
Αν η ομάδα είναι μικρή, συμβαίνει να υπάρχει ένας προγραμματιστής που γράφει τα πάντα, οι υπόλοιποι είναι στα φτερά. "Έγραψα τη βασική αρχιτεκτονική, ας προσθέσουμε τις διεπαφές." Μετά, κάποια στιγμή ο μάνατζερ, για παράδειγμα, φεύγει. Και κατά τη διάρκεια αυτής της περιόδου, όταν ο διαχειριστής έχει φύγει και δεν έχει ακόμη διοριστεί νέος, οι ίδιοι οι προγραμματιστές αποφασίζουν πού πηγαίνει η υπηρεσία και τι συμβαίνει εκεί. Και όπως γνωρίζουμε (ας πάμε μερικές διαφάνειες πίσω), σε ορισμένες ομάδες υπάρχουν άνθρωποι με νιφάδες χιονιού, μερικές φορές επικεφαλής της ομάδας νιφάδας χιονιού. Μετά τα παρατάει και έχουμε μια ορφανή υπηρεσία.
Ταυτόχρονα, τα καθήκοντα από την υποστήριξη και από τις επιχειρήσεις δεν εξαφανίζονται· καταλήγουν στο υστέρημα. Αν υπήρξαν αρχιτεκτονικά λάθη κατά την ανάπτυξη της υπηρεσίας, καταλήγουν και αυτά στο υστέρημα. Η υπηρεσία σιγά σιγά επιδεινώνεται.
Πώς να αναγνωρίσετε ένα ορφανό;
Αυτή η λίστα περιγράφει καλά την κατάσταση. Ποιος έμαθε τίποτα για τις υποδομές τους;
Σχετικά με τεκμηριωμένες λύσεις: υπάρχει μια υπηρεσία και, γενικά, λειτουργεί, έχει ένα εγχειρίδιο δύο σελίδων για το πώς να εργαστείτε μαζί της, αλλά κανείς δεν ξέρει πώς λειτουργεί μέσα.
Ή, για παράδειγμα, υπάρχει κάποιο είδος συντόμευσης συνδέσμου. Για παράδειγμα, αυτήν τη στιγμή έχουμε τρεις συντομεύσεις συνδέσμων σε χρήση για διαφορετικούς σκοπούς σε διαφορετικές υπηρεσίες. Αυτές είναι μόνο οι συνέπειες.
Τώρα θα είμαι ο καπετάνιος του προφανούς. Τι πρέπει να γίνει? Πρώτα, πρέπει να μεταφέρουμε την υπηρεσία σε άλλο μάνατζερ, άλλη ομάδα. Εάν ο επικεφαλής της ομάδας σας δεν έχει παραιτηθεί ακόμα, τότε σε αυτήν την άλλη ομάδα, όταν καταλάβετε ότι η υπηρεσία είναι σαν ορφανή, πρέπει να συμπεριλάβετε κάποιον που καταλαβαίνει τουλάχιστον κάτι γι 'αυτό.
Το κύριο πράγμα: πρέπει να έχετε τις διαδικασίες μεταφοράς γραμμένες με αίμα. Στην περίπτωσή μας, συνήθως το παρακολουθώ αυτό, γιατί τα χρειάζομαι όλα για να λειτουργήσουν. Οι διευθυντές χρειάζονται να παραδοθεί γρήγορα και αυτό που θα συμβεί αργότερα δεν είναι πλέον τόσο σημαντικό για αυτούς.
Ο επόμενος τρόπος για να κάνετε ένα ορφανό είναι «Θα το κάνουμε με εξωτερική ανάθεση, θα είναι πιο γρήγορο και μετά θα το παραδώσουμε στην ομάδα». Είναι ξεκάθαρο ότι όλοι έχουν κάποια σχέδια στην ομάδα, μια στροφή. Συχνά ένας επιχειρηματικός πελάτης πιστεύει ότι ο ανάδοχος θα κάνει το ίδιο πράγμα με το τεχνικό τμήμα που έχει η εταιρεία. Αν και τα κίνητρά τους είναι διαφορετικά. Υπάρχουν περίεργες τεχνολογικές λύσεις και περίεργες αλγοριθμικές λύσεις στο outsourcing.
Για παράδειγμα, είχαμε μια υπηρεσία που είχε Sphinx σε διάφορα απροσδόκητα μέρη. Θα σου πω αργότερα τι έπρεπε να κάνω.
Οι εξωτερικοί ανάδοχοι έχουν αυτογραμμένα πλαίσια. Αυτή είναι απλώς γυμνή PHP με copy-paste από προηγούμενο έργο, όπου μπορείτε να βρείτε όλα τα είδη των πραγμάτων. Τα σενάρια ανάπτυξης είναι ένα μεγάλο μειονέκτημα όταν χρειάζεται να χρησιμοποιήσετε ορισμένα πολύπλοκα σενάρια Bash για να αλλάξετε πολλές γραμμές σε κάποιο αρχείο και αυτά τα σενάρια ανάπτυξης καλούνται από κάποιο τρίτο σενάριο. Ως αποτέλεσμα, αλλάζετε το σύστημα ανάπτυξης, επιλέγετε κάτι άλλο, πηδάτε, αλλά η υπηρεσία σας δεν λειτουργεί. Γιατί εκεί χρειάστηκε να βάλουμε 8 ακόμα συνδέσμους μεταξύ διαφορετικών φακέλων. Ή συμβαίνει να λειτουργούν χίλιοι δίσκοι, αλλά εκατό χιλιάδες να μην λειτουργούν πια.
Θα συνεχίσω να είμαι καπετάνιος. Η αποδοχή μιας εξωτερικής ανάθεσης υπηρεσίας είναι μια υποχρεωτική διαδικασία. Είχε ποτέ σε κάποιον μια εξωτερική ανάθεση υπηρεσία να φτάσει και να μην γίνει δεκτός πουθενά; Αυτό δεν είναι τόσο δημοφιλές, φυσικά, όσο μια ορφανή υπηρεσία, αλλά ακόμα.
Η υπηρεσία πρέπει να ελεγχθεί, η υπηρεσία πρέπει να ελεγχθεί, οι κωδικοί πρόσβασης πρέπει να αλλάξουν. Είχαμε μια περίπτωση που μας έδωσαν μια υπηρεσία, υπάρχει ένας πίνακας διαχείρισης "if login == 'admin' && password == 'admin'...", είναι γραμμένο ακριβώς στον κώδικα. Καθόμαστε και σκεφτόμαστε, και ο κόσμος το γράφει αυτό το 2018;
Η δοκιμή χωρητικότητας αποθήκευσης είναι επίσης απαραίτητη. Πρέπει να κοιτάξετε τι θα συμβεί σε εκατό χιλιάδες δίσκους, ακόμη και πριν βάλετε κάπου αυτή την υπηρεσία στην παραγωγή.
Δεν πρέπει να είναι ντροπή να στείλετε μια υπηρεσία για βελτίωση. Όταν λέτε: "Δεν θα δεχτούμε αυτήν την υπηρεσία, έχουμε 20 εργασίες, κάντε τις, μετά θα δεχτούμε", αυτό είναι φυσιολογικό. Η συνείδησή σας δεν πρέπει να πληγώνεται από το γεγονός ότι δημιουργείτε έναν διευθυντή ή ότι η επιχείρηση σπαταλά χρήματα. Στη συνέχεια, η επιχείρηση θα ξοδέψει περισσότερα.
Είχαμε μια περίπτωση που αποφασίσαμε να αναθέσουμε σε εξωτερικούς συνεργάτες ένα πιλοτικό έργο.
Παραδόθηκε έγκαιρα, και αυτό ήταν το μόνο ποιοτικό κριτήριο. Γι' αυτό κάναμε ένα άλλο πιλοτικό έργο, το οποίο δεν ήταν καν πιλοτικό πλέον. Αυτές οι υπηρεσίες έγιναν δεκτές και με διοικητικά μέσα είπαν, εδώ είναι ο κωδικός σας, εδώ είναι η ομάδα, εδώ είναι ο διευθυντής σας. Οι υπηρεσίες στην πραγματικότητα έχουν ήδη αρχίσει να αποκομίζουν κέρδη. Ταυτόχρονα, στην πραγματικότητα, είναι ακόμα ορφανά, κανείς δεν καταλαβαίνει πώς λειτουργούν και οι διευθυντές κάνουν ό,τι μπορούν για να αποκηρύξουν τα καθήκοντά τους.
Υπάρχει μια άλλη μεγάλη ιδέα - η ανάπτυξη των ανταρτών. Όταν κάποιο τμήμα, συνήθως το τμήμα μάρκετινγκ, θέλει να δοκιμάσει μια υπόθεση και διατάζει ολόκληρη την υπηρεσία να ανατεθεί σε εξωτερικούς συνεργάτες. Αρχίζει να μπαίνει η κίνηση, κλείνουν τα έγγραφα, υπογράφουν έγγραφα με τον εργολάβο, μπαίνουν σε λειτουργία και λένε: «Ρε παιδιά, έχουμε υπηρεσία εδώ, έχει ήδη κίνηση, μας φέρνει λεφτά, ας το δεχτούμε». Λέγαμε, «Όπα, πώς γίνεται αυτό».
Και ένας άλλος τρόπος για να αποκτήσετε μια ορφανή υπηρεσία: όταν κάποια ομάδα βρεθεί ξαφνικά φορτωμένη, η διοίκηση λέει: "Ας μεταφέρουμε την υπηρεσία αυτής της ομάδας σε άλλη ομάδα, έχει μικρότερο φορτίο." Και μετά θα το μεταφέρουμε σε μια τρίτη ομάδα και θα αλλάξουμε τον προπονητή. Και στο τέλος έχουμε πάλι ορφανό.
Ποιο είναι το πρόβλημα με τα ορφανά;
Ποιος δεν ξέρει, αυτό είναι το θωρηκτό Wasa που ανυψώθηκε στη Σουηδία, διάσημο για το γεγονός ότι βυθίστηκε 5 λεπτά μετά την εκτόξευση. Και ο βασιλιάς της Σουηδίας, παρεμπιπτόντως, δεν εκτέλεσε κανέναν για αυτό. Κατασκευάστηκε από δύο γενιές μηχανικών που δεν ήξεραν πώς να κατασκευάζουν τέτοια πλοία. Φυσικό αποτέλεσμα.
Το πλοίο θα μπορούσε να βυθιστεί, παρεμπιπτόντως, με πολύ χειρότερο τρόπο, για παράδειγμα, όταν ο βασιλιάς επέβαινε ήδη πάνω του κάπου σε μια καταιγίδα. Και έτσι, πνίγηκε αμέσως, σύμφωνα με το Agile είναι καλό να αποτύχεις νωρίς.
Αν αποτύχουμε νωρίς, συνήθως δεν υπάρχουν προβλήματα. Για παράδειγμα, κατά την αποδοχή στάλθηκε για αναθεώρηση. Αλλά αν αποτύχουμε ήδη στην παραγωγή, όταν επενδύονται χρήματα, τότε μπορεί να υπάρξουν προβλήματα. Συνέπειες, όπως λέγονται στις επιχειρήσεις.
Γιατί οι ορφανές υπηρεσίες είναι επικίνδυνες:
- Η υπηρεσία μπορεί να σπάσει ξαφνικά.
- Το σέρβις παίρνει πολύ χρόνο για να επισκευαστεί ή δεν επισκευάζεται καθόλου.
- Προβλήματα ασφαλείας.
- Προβλήματα με βελτιώσεις και ενημερώσεις.
- Εάν μια σημαντική υπηρεσία χαλάσει, η φήμη της εταιρείας υποφέρει.
Τι να κάνετε με τις υπηρεσίες ορφανών;
Θα επαναλάβω τι να κάνω ξανά. Πρώτον, πρέπει να υπάρχει τεκμηρίωση. 7 χρόνια στο Banki.ru με δίδαξαν ότι οι δοκιμαστές δεν πρέπει να δέχονται τον λόγο των προγραμματιστών και ότι οι λειτουργίες δεν πρέπει να λαμβάνουν τον λόγο όλων. Πρέπει να ελέγξουμε.
Δεύτερον, είναι απαραίτητο να γραφτούν διαγράμματα αλληλεπίδρασης, επειδή συμβαίνει ότι οι υπηρεσίες που δεν έχουν πολύ καλή υποδοχή περιέχουν εξαρτήσεις για τις οποίες κανείς δεν είπε. Για παράδειγμα, οι προγραμματιστές εγκατέστησαν την υπηρεσία στο κλειδί τους σε κάποιο Yandex.Maps ή Dadata. Έχετε ξεμείνει από το δωρεάν όριο, όλα έχουν σπάσει και δεν ξέρετε τι συνέβη καθόλου. Όλες αυτές οι τσουγκράνες πρέπει να περιγράφονται: η υπηρεσία χρησιμοποιεί Dadata, SMS, κάτι άλλο.
Τρίτον, η εργασία με τεχνικό χρέος. Όταν κάνετε κάποιου είδους πατερίτσες ή δέχεστε μια υπηρεσία και λέτε ότι κάτι πρέπει να γίνει, πρέπει να βεβαιωθείτε ότι έχει γίνει. Γιατί τότε μπορεί να αποδειχθεί ότι η μικρή τρύπα δεν είναι τόσο μικρή και θα πέσετε μέσα από αυτήν.
Με αρχιτεκτονικές εργασίες, είχαμε μια ιστορία για τη Σφίγγα. Μία από τις υπηρεσίες χρησιμοποίησε το Sphinx για να εισάγει λίστες. Απλώς μια σελιδοποιημένη λίστα, αλλά αναπροσαρμόστηκε κάθε βράδυ. Συναρμολογήθηκε από δύο ευρετήρια: ένα μεγάλο ευρετηριαζόταν κάθε βράδυ, και υπήρχε επίσης ένα μικρό ευρετήριο που βιδώθηκε σε αυτό. Κάθε μέρα, με πιθανότητα 50% είτε να βομβαρδιστεί είτε όχι, ο δείκτης έπεφτε κατά τον υπολογισμό και τα νέα μας σταμάτησαν να ενημερώνονται στην κεντρική σελίδα. Στην αρχή χρειάστηκαν 5 λεπτά για να αναπροσαρμοσθεί ο δείκτης, στη συνέχεια ο δείκτης αυξήθηκε και κάποια στιγμή άρχισε να χρειάζονται 40 λεπτά για να αναπροσαρμόσει τον δείκτη. Όταν το κόψαμε αυτό, αναπνεύσαμε με ανακούφιση, γιατί ήταν ξεκάθαρο ότι θα περνούσε λίγος ακόμα χρόνος και ο ευρετήριός μας θα αναπροσαρμόστηκε σε πλήρη απασχόληση. Αυτό θα είναι μια αποτυχία για την πύλη μας, δεν υπάρχουν νέα για οκτώ ώρες - αυτό είναι, η επιχείρηση έχει σταματήσει.
Σχέδιο για εργασία με μια ορφανή υπηρεσία
Στην πραγματικότητα, αυτό είναι πολύ δύσκολο να γίνει, γιατί το devops έχει να κάνει με την επικοινωνία. Θέλετε να έχετε καλές σχέσεις με τους συναδέλφους σας και όταν χτυπάτε τους συναδέλφους και τους διευθυντές σας με κανονισμούς, μπορεί να έχουν αντικρουόμενα συναισθήματα για εκείνους τους ανθρώπους που το κάνουν αυτό.
Εκτός από όλα αυτά τα σημεία, υπάρχει ένα άλλο σημαντικό πράγμα: συγκεκριμένα άτομα πρέπει να είναι υπεύθυνα για κάθε συγκεκριμένη υπηρεσία, για κάθε συγκεκριμένο τμήμα της διαδικασίας ανάπτυξης. Όταν δεν υπάρχουν άνθρωποι και πρέπει να προσελκύσεις κάποιους άλλους για να μελετήσουν όλο αυτό το θέμα, γίνεται δύσκολο.
Εάν όλα αυτά δεν βοήθησαν και η ορφανή υπηρεσία σας είναι ακόμα ορφανή, κανείς δεν θέλει να την αναλάβει, η τεκμηρίωση δεν είναι γραμμένη, η ομάδα που κλήθηκε σε αυτήν την υπηρεσία αρνείται να κάνει οτιδήποτε, υπάρχει ένας απλός τρόπος - να επαναλάβετε τα παντα .
Δηλαδή παίρνεις ξανά τις απαιτήσεις για την υπηρεσία και γράφεις μια νέα υπηρεσία, καλύτερη, σε καλύτερη πλατφόρμα, χωρίς περίεργες τεχνολογικές λύσεις. Και μεταναστεύετε σε αυτό στη μάχη.
Είχαμε μια κατάσταση όταν πήραμε μια υπηρεσία στο Yii 1 και συνειδητοποιήσαμε ότι δεν μπορούσαμε να την αναπτύξουμε περαιτέρω, επειδή ξεμείναμε από προγραμματιστές που μπορούσαν να γράφουν καλά στο Yii 1. Όλοι οι προγραμματιστές γράφουν καλά στο Symfony XNUMX. Τι να κάνω? Διαθέσαμε χρόνο, διαθέσαμε μια ομάδα, διαθέσαμε έναν διευθυντή, ξαναγράψαμε το έργο και αλλάξαμε ομαλά την κυκλοφορία σε αυτό.
Μετά από αυτό, η παλιά υπηρεσία μπορεί να διαγραφεί. Αυτή είναι η αγαπημένη μου διαδικασία, όταν πρέπει να αφαιρέσετε και να καθαρίσετε κάποια υπηρεσία από το σύστημα διαχείρισης διαμόρφωσης και μετά να περάσετε και να δείτε ότι όλα τα αυτοκίνητα στην παραγωγή έχουν απενεργοποιηθεί, έτσι ώστε οι προγραμματιστές να μην έχουν ίχνη. Το αποθετήριο παραμένει στο Git.
Αυτό είναι το μόνο για το οποίο ήθελα να μιλήσω, είμαι έτοιμος να συζητήσω, το θέμα είναι το holivar, πολλοί έχουν κολυμπήσει σε αυτό.
Οι διαφάνειες είπαν ότι ενοποιήσατε τις γλώσσες. Ένα παράδειγμα ήταν η αλλαγή μεγέθους των εικόνων. Είναι πραγματικά απαραίτητο να περιοριστεί αυστηρά σε μία γλώσσα; Επειδή η αλλαγή μεγέθους εικόνας στην PHP, λοιπόν, θα μπορούσε πραγματικά να γίνει στο Golang.
Στην πραγματικότητα, είναι προαιρετικό, όπως όλες οι πρακτικές. Ίσως, σε ορισμένες περιπτώσεις, να είναι ακόμη και ανεπιθύμητο. Αλλά πρέπει να καταλάβετε ότι εάν έχετε ένα τεχνικό τμήμα σε μια εταιρεία 50 ατόμων, 45 από αυτούς είναι ειδικοί PHP, άλλοι 3 είναι devop που γνωρίζουν Python, Ansible, Puppet και κάτι τέτοιο, και μόνο ένας από αυτούς γράφει σε μερικά κάποια υπηρεσία αλλαγής μεγέθους εικόνας Go, στη συνέχεια, όταν φύγει, η τεχνογνωσία συνοδεύεται από αυτήν. Ταυτόχρονα, θα χρειαστεί να αναζητήσετε έναν προγραμματιστή που να γνωρίζει αυτή τη γλώσσα, ειδικά αν είναι σπάνια. Δηλαδή από οργανωτικής πλευράς αυτό είναι προβληματικό. Από την άποψη του devops, δεν θα χρειαστεί απλώς να κλωνοποιήσετε κάποιο έτοιμο σύνολο βιβλίων που χρησιμοποιείτε για την ανάπτυξη υπηρεσιών, αλλά θα πρέπει να τα γράψετε ξανά από την αρχή.
Αυτήν τη στιγμή χτίζουμε μια υπηρεσία στο Node.js και αυτή θα είναι απλώς μια πλατφόρμα κοντά για κάθε προγραμματιστή με ξεχωριστή γλώσσα. Καθίσαμε όμως και σκεφτήκαμε ότι το παιχνίδι άξιζε το κερί. Δηλαδή, αυτή είναι μια ερώτηση για να κάτσεις να σκεφτείς.
Πώς παρακολουθείτε τις υπηρεσίες σας; Πώς συλλέγετε και παρακολουθείτε τα αρχεία καταγραφής;
Συλλέγουμε κορμούς στο Elasticsearch και τους βάζουμε στο Kibana και ανάλογα με το αν είναι περιβάλλον παραγωγής ή δοκιμής, χρησιμοποιούνται διαφορετικοί συλλέκτες εκεί. Κάπου Ξυλοκόπος, αλλού κάτι άλλο, δεν θυμάμαι. Και υπάρχουν ακόμα κάποια μέρη σε ορισμένες υπηρεσίες όπου εγκαθιστούμε το Telegraf και κάνουμε λήψη κάπου αλλού ξεχωριστά.
Πώς να ζήσετε με την Puppet και την Ansible στο ίδιο περιβάλλον;
Στην πραγματικότητα, τώρα έχουμε δύο περιβάλλοντα, το ένα είναι Puppet, το άλλο είναι το Ansible. Εργαζόμαστε για να τα υβριδοποιήσουμε. Το Ansible είναι ένα καλό πλαίσιο για την αρχική ρύθμιση, το Puppet είναι ένα κακό πλαίσιο για την αρχική ρύθμιση, επειδή απαιτεί πρακτική εργασία απευθείας στην πλατφόρμα και το Puppet διασφαλίζει τη σύγκλιση της διαμόρφωσης. Αυτό σημαίνει ότι η πλατφόρμα διατηρείται σε ενημερωμένη κατάσταση και για να διατηρείται ενημερωμένο το μηχάνημα που έχει ενεργοποιηθεί, πρέπει να εκτελείτε βιβλία αναπαραγωγής σε αυτό συνεχώς με κάποια συχνότητα. Αυτή είναι η διαφορά.
Πώς διατηρείτε τη συμβατότητα; Έχετε ρυθμίσεις παραμέτρων και στο Ansible και στο Puppet;
Αυτός είναι ο μεγάλος μας πόνος, διατηρούμε τη συμβατότητα με τα χέρια μας και σκεφτόμαστε πώς να προχωρήσουμε από όλο αυτό κάπου τώρα. Αποδεικνύεται ότι το Puppet βγάζει πακέτα και διατηρεί ορισμένους συνδέσμους εκεί και το Ansible, για παράδειγμα, βγάζει τον κώδικα και προσαρμόζει εκεί τις πιο πρόσφατες ρυθμίσεις παραμέτρων εφαρμογής.
Η παρουσίαση αφορούσε διαφορετικές εκδόσεις του Ruby. Ποια λύση;
Το συναντήσαμε σε ένα μέρος και πρέπει να το κρατάμε στο μυαλό μας όλη την ώρα. Απλώς απενεργοποιήσαμε το τμήμα που έτρεχε στο Ruby που δεν ήταν συμβατό με τις εφαρμογές και το κρατήσαμε ξεχωριστό.
Το φετινό συνέδριο θα πραγματοποιηθεί στις 7 Δεκεμβρίου στην Τεχνόπολη. Δεχόμαστε αιτήσεις για αναφορές έως τις 11 Νοεμβρίου. μας αν θέλετε να μιλήσουμε.
Οι εγγραφές για τους συμμετέχοντες έχουν ανοίξει, ελάτε μαζί μας!
Πηγή: www.habr.com