Γεια σου, Χαμπρ! Υποστηρίζω συστήματα πληροφορικής Highload εδώ και δέκα χρόνια. Δεν θα γράψω σε αυτό το άρθρο σχετικά με τα προβλήματα ρύθμισης του nginx ώστε να λειτουργεί σε λειτουργία 1000+ RPS ή άλλα τεχνικά πράγματα. Θα μοιραστώ τις παρατηρήσεις μου για τα προβλήματα στις διαδικασίες που προκύπτουν στην υποστήριξη και λειτουργία τέτοιων συστημάτων.
Παρακολούθηση
Η τεχνική υποστήριξη δεν περιμένει μέχρι να φτάσει ένα αίτημα με το περιεχόμενο "Τι Γιατί... ο ιστότοπος δεν λειτουργεί ξανά;" Μέσα σε ένα λεπτό μετά τη διακοπή λειτουργίας του ιστότοπου, η υποστήριξη θα πρέπει ήδη να δει το πρόβλημα και να αρχίσει να το επιλύει. Αλλά η τοποθεσία είναι η κορυφή του παγόβουνου. Η διαθεσιμότητά του είναι από τις πρώτες που παρακολουθούνται.
Τι να κάνετε με την κατάσταση όταν τα υπόλοιπα αγαθά ενός ηλεκτρονικού καταστήματος δεν φτάνουν πλέον από το σύστημα ERP; Ή το σύστημα CRM που υπολογίζει τις εκπτώσεις για τους πελάτες έχει σταματήσει να ανταποκρίνεται; Ο ιστότοπος φαίνεται να λειτουργεί. Το Conditional Zabbix λαμβάνει την απάντησή του 200. Η βάρδια δεν έχει λάβει καμία ειδοποίηση από την παρακολούθηση και παρακολουθεί με χαρά το πρώτο επεισόδιο της νέας σεζόν του Game of Thrones.
Η παρακολούθηση συχνά περιορίζεται μόνο στη μέτρηση της κατάστασης της μνήμης, της μνήμης RAM και του φορτίου του επεξεργαστή διακομιστή. Αλλά για τις επιχειρήσεις είναι πολύ πιο σημαντικό να υπάρχει διαθεσιμότητα προϊόντων στον ιστότοπο. Η υπό όρους αποτυχία μιας εικονικής μηχανής στο σύμπλεγμα θα οδηγήσει στο γεγονός ότι η κυκλοφορία θα σταματήσει να πηγαίνει σε αυτήν και το φόρτο σε άλλους διακομιστές θα αυξηθεί. Η εταιρεία δεν θα χάσει χρήματα.
Επομένως, εκτός από την παρακολούθηση των τεχνικών παραμέτρων των λειτουργικών συστημάτων στους διακομιστές, πρέπει να ρυθμίσετε τις παραμέτρους των επιχειρηματικών μετρήσεων. Μετρήσεις που επηρεάζουν άμεσα τα χρήματα. Διάφορες αλληλεπιδράσεις με εξωτερικά συστήματα (CRM, ERP και άλλα). Ο αριθμός των παραγγελιών για ένα ορισμένο χρονικό διάστημα. Επιτυχείς ή ανεπιτυχείς εξουσιοδοτήσεις πελατών και άλλες μετρήσεις.
Αλληλεπίδραση με εξωτερικά συστήματα
Οποιοσδήποτε ιστότοπος ή εφαρμογή για κινητά με ετήσιο κύκλο εργασιών άνω του ενός δισεκατομμυρίου ρούβλια αλληλεπιδρά με εξωτερικά συστήματα. Ξεκινώντας από το προαναφερθέν CRM και ERP και τελειώνοντας με τη μεταφορά δεδομένων πωλήσεων σε εξωτερικό σύστημα Big Data για την ανάλυση αγορών και την προσφορά στον πελάτη ενός προϊόντος που σίγουρα θα αγοράσει (στην πραγματικότητα όχι). Κάθε τέτοιο σύστημα έχει τη δική του υποστήριξη. Και συχνά η επικοινωνία με αυτά τα συστήματα προκαλεί πόνο. Ειδικά όταν το πρόβλημα είναι παγκόσμιο και πρέπει να το αναλύσεις σε διαφορετικά συστήματα.
Ορισμένα συστήματα παρέχουν έναν αριθμό τηλεφώνου ή τηλεγράφημα για τους διαχειριστές τους. Κάπου πρέπει να γράψετε γράμματα στους διαχειριστές ή να πάτε στους ανιχνευτές σφαλμάτων αυτών των εξωτερικών συστημάτων. Ακόμη και στο πλαίσιο μιας μεγάλης εταιρείας, διαφορετικά συστήματα λειτουργούν συχνά σε διαφορετικά λογιστικά συστήματα εφαρμογών. Μερικές φορές είναι αδύνατο να παρακολουθήσετε την κατάσταση μιας εφαρμογής. Λαμβάνετε ένα αίτημα σε ένα Jira υπό όρους. Στη συνέχεια, στο σχόλιο αυτής της πρώτης Jira βάζετε έναν σύνδεσμο για το θέμα σε μια άλλη Jira. Στο δεύτερο Jira στην εφαρμογή, κάποιος γράφει ήδη ένα σχόλιο που πρέπει να καλέσετε τον υπό όρους διαχειριστή Andrey για να επιλύσετε το πρόβλημα. Και ούτω καθεξής.
Η καλύτερη λύση σε αυτό το πρόβλημα θα ήταν η δημιουργία ενός ενιαίου χώρου επικοινωνίας, για παράδειγμα στο Slack. Πρόσκληση όλων των συμμετεχόντων στη διαδικασία λειτουργίας εξωτερικών συστημάτων να συμμετάσχουν. Και επίσης ένα ενιαίο tracker για να μην γίνονται διπλές εφαρμογές. Οι εφαρμογές θα πρέπει να παρακολουθούνται σε ένα μέρος, από την παρακολούθηση ειδοποιήσεων έως την έξοδο λύσεων σφαλμάτων στο μέλλον. Θα πείτε ότι αυτό δεν είναι ρεαλιστικό και έχει συμβεί ιστορικά να δουλεύουμε σε έναν ιχνηλάτη, και εκείνοι σε άλλο. Εμφανίστηκαν διαφορετικά συστήματα, είχαν τις δικές τους αυτόνομες ομάδες πληροφορικής. Συμφωνώ, και επομένως το πρόβλημα πρέπει να λυθεί από πάνω σε επίπεδο CIO ή κατόχου προϊόντος.
Κάθε σύστημα με το οποίο αλληλεπιδράτε θα πρέπει να παρέχει υποστήριξη ως υπηρεσία με σαφή SLA για την επίλυση προβλημάτων κατά προτεραιότητα. Και όχι όταν ο υπό όρους διαχειριστής Andrey έχει ένα λεπτό για εσάς.
Άνθρωπος Bottleneck
Όλοι σε ένα έργο (ή προϊόν) έχουν ένα άτομο του οποίου οι διακοπές προκαλούν σπασμούς στους ανωτέρους τους; Αυτός θα μπορούσε να είναι μηχανικός, αναλυτής ή προγραμματιστής devops. Εξάλλου, μόνο ένας μηχανικός devops γνωρίζει ποιοι διακομιστές έχουν εγκατεστημένα κοντέινερ, πώς να επανεκκινήσει το κοντέινερ σε περίπτωση προβλήματος και γενικά, οποιοδήποτε περίπλοκο πρόβλημα δεν μπορεί να λυθεί χωρίς αυτόν. Ο αναλυτής είναι ο μόνος που ξέρει πώς λειτουργεί ο πολύπλοκος μηχανισμός σας. Ποιες ροές δεδομένων πηγαίνουν πού. Κάτω από ποιες παραμέτρους αιτημάτων σε ποιες υπηρεσίες, ποιες θα λάβουμε απαντήσεις.
Ποιος θα καταλάβει γρήγορα γιατί υπάρχουν σφάλματα στα αρχεία καταγραφής και θα διορθώσει αμέσως ένα κρίσιμο σφάλμα στο προϊόν; Φυσικά ο ίδιος προγραμματιστής. Υπάρχουν και άλλα, αλλά για κάποιο λόγο μόνο αυτός καταλαβαίνει πώς λειτουργούν οι διάφορες μονάδες του συστήματος.
Η ρίζα αυτού του προβλήματος είναι η έλλειψη τεκμηρίωσης. Άλλωστε, αν περιγράφονταν όλες οι υπηρεσίες του συστήματός σας, τότε θα ήταν δυνατό να αντιμετωπίσετε το πρόβλημα χωρίς αναλυτή. Εάν ο devops έβγαζε μερικές μέρες από το πολυάσχολο πρόγραμμά του και περιέγραφε όλους τους διακομιστές, τις υπηρεσίες και τις οδηγίες για την επίλυση τυπικών προβλημάτων, τότε το πρόβλημα στην απουσία του θα μπορούσε να λυθεί χωρίς αυτόν. Δεν χρειάζεται να τελειώσετε γρήγορα την μπύρα σας στην παραλία ενώ είστε διακοπές και να αναζητήσετε wi-fi για να λύσετε το πρόβλημα.
Ικανότητα και ευθύνη του βοηθητικού προσωπικού
Σε μεγάλα έργα, οι εταιρείες δεν τσιγκουνεύονται τους μισθούς των προγραμματιστών. Αναζητούν ακριβούς μεσαίους ή ηλικιωμένους από παρόμοια έργα. Με την υποστήριξη η κατάσταση είναι λίγο διαφορετική. Προσπαθούν να μειώσουν αυτό το κόστος με κάθε δυνατό τρόπο. Οι εταιρείες προσλαμβάνουν φθηνούς χθεσινούς εργάτες της Enikey και μπαίνουν με τόλμη στη μάχη. Αυτή η στρατηγική είναι δυνατή εάν μιλάμε για έναν ιστότοπο επαγγελματικής κάρτας ενός εργοστασίου στο Zelenograd.
Αν μιλάμε για μεγάλο ηλεκτρονικό κατάστημα, τότε κάθε ώρα διακοπής κοστίζει περισσότερο από τον μηνιαίο μισθό ενός διαχειριστή της Enikey. Ας πάρουμε ως σημείο εκκίνησης 1 δισεκατομμύριο ρούβλια ετήσιου κύκλου εργασιών. Αυτός είναι ο ελάχιστος τζίρος οποιουδήποτε ηλεκτρονικού καταστήματος από την αξιολόγηση . Διαιρέστε αυτό το ποσό με τον αριθμό των ωρών ανά έτος και λάβετε περισσότερα από 100 ρούβλια καθαρών ζημιών. Και αν δεν μετρήσετε τις νυχτερινές ώρες, μπορείτε με ασφάλεια να διπλασιάσετε το ποσό.
Αλλά τα χρήματα δεν είναι το κύριο πράγμα, σωστά; (όχι, φυσικά το κυριότερο) Υπάρχουν και απώλειες φήμης. Η πτώση ενός γνωστού ηλεκτρονικού καταστήματος μπορεί να προκαλέσει τόσο κύμα κριτικών στα κοινωνικά δίκτυα όσο και δημοσιεύσεις σε θεματικά μέσα. Και οι συζητήσεις των φίλων στην κουζίνα με το στυλ "Μην αγοράζετε τίποτα εκεί, ο ιστότοπός τους είναι πάντα εκτός λειτουργίας" δεν μπορούν να μετρηθούν καθόλου.
Τώρα στην ευθύνη. Στην πρακτική μου, υπήρξε περίπτωση που ο εφημερεύων διαχειριστής δεν απάντησε έγκαιρα σε ειδοποίηση από το σύστημα παρακολούθησης σχετικά με τη μη διαθεσιμότητα του ιστότοπου. Ένα ευχάριστο καλοκαιρινό βράδυ Παρασκευής, ο ιστότοπος ενός γνωστού ηλεκτρονικού καταστήματος στη Μόσχα βρισκόταν ήσυχα. Το Σάββατο το πρωί, ο υπεύθυνος προϊόντων αυτού του ιστότοπου δεν κατάλαβε γιατί δεν άνοιξε ο ιστότοπος και επικράτησε σιωπή στις συνομιλίες υποστήριξης και επείγουσας ειδοποίησης στο Slack. Ένα τέτοιο λάθος μας κόστισε ένα εξαψήφιο ποσό και αυτός ο αξιωματικός υπηρεσίας τη δουλειά του.
Η υπευθυνότητα είναι μια δυσκολία στην ανάπτυξη. Είτε το έχει κάποιος είτε όχι. Ως εκ τούτου, κατά τη διάρκεια των συνεντεύξεων, προσπαθώ να ταυτίσω την παρουσία του με διάφορα ερωτήματα που δείχνουν έμμεσα αν ένας άνθρωπος έχει συνηθίσει να αναλαμβάνει ευθύνες. Αν κάποιος απαντήσει ότι επέλεξε ένα πανεπιστήμιο επειδή το είπαν οι γονείς του ή αλλάξει δουλειά επειδή η γυναίκα του είπε ότι δεν κερδίζει αρκετά, τότε είναι καλύτερα να μην ασχοληθείς με τέτοιους ανθρώπους.
Αλληλεπίδραση με την ομάδα ανάπτυξης
Όταν οι χρήστες αντιμετωπίζουν απλά προβλήματα με ένα προϊόν κατά τη λειτουργία, η υποστήριξη τα λύνει από μόνη της. Προσπαθεί να αναπαράγει το πρόβλημα, αναλύει τα αρχεία καταγραφής και ούτω καθεξής. Τι να κάνετε όμως όταν εμφανιστεί ένα σφάλμα στο προϊόν; Σε αυτήν την περίπτωση, η υποστήριξη αναθέτει την εργασία στους προγραμματιστές και εδώ αρχίζει η διασκέδαση.
Οι προγραμματιστές είναι συνεχώς υπερφορτωμένοι. Δημιουργούν νέα χαρακτηριστικά. Η διόρθωση σφαλμάτων με τις πωλήσεις δεν είναι η πιο ενδιαφέρουσα δραστηριότητα. Πλησιάζουν οι προθεσμίες για την ολοκλήρωση του επόμενου σπριντ. Και τότε έρχονται δυσάρεστα άτομα από την υποστήριξη και λένε: "Παράτα τα όλα αμέσως, έχουμε προβλήματα". Η προτεραιότητα τέτοιων εργασιών είναι ελάχιστη. Ειδικά όταν το πρόβλημα δεν είναι το πιο κρίσιμο και η κύρια λειτουργικότητα του ιστότοπου λειτουργεί και όταν ο διαχειριστής έκδοσης δεν τρέχει με διογκωμένα μάτια και γράφει: "Προσθέστε επειγόντως αυτήν την εργασία στην επόμενη έκδοση ή επείγουσα επιδιόρθωση."
Τα ζητήματα με κανονική ή χαμηλή προτεραιότητα μετακινούνται από έκδοση σε κυκλοφορία. Στην ερώτηση "Πότε θα ολοκληρωθεί η εργασία;" θα λάβετε απαντήσεις με το στυλ: «Συγγνώμη, υπάρχουν πολλές εργασίες αυτήν τη στιγμή, ρωτήστε τους επικεφαλής της ομάδας σας ή τον υπεύθυνο έκδοσης».
Τα προβλήματα παραγωγικότητας έχουν μεγαλύτερη προτεραιότητα από τη δημιουργία νέων λειτουργιών. Οι κακές κριτικές δεν θα αργήσουν να έρθουν εάν οι χρήστες πέφτουν συνεχώς πάνω σε σφάλματα. Η κατεστραμμένη φήμη είναι δύσκολο να αποκατασταθεί.
Τα ζητήματα αλληλεπίδρασης μεταξύ ανάπτυξης και υποστήριξης επιλύονται από το DevOps. Αυτή η συντομογραφία χρησιμοποιείται συχνά με τη μορφή ενός συγκεκριμένου ατόμου που βοηθά στη δημιουργία δοκιμαστικών περιβαλλόντων για ανάπτυξη, δημιουργεί αγωγούς CICD και φέρνει γρήγορα τον δοκιμασμένο κώδικα στην παραγωγή. Το DevOps είναι μια προσέγγιση στην ανάπτυξη λογισμικού όταν όλοι οι συμμετέχοντες στη διαδικασία αλληλεπιδρούν στενά μεταξύ τους και βοηθούν στη γρήγορη δημιουργία και ενημέρωση προϊόντων και υπηρεσιών λογισμικού. Εννοώ αναλυτές, προγραμματιστές, δοκιμαστές και υποστήριξη.
Σε αυτή την προσέγγιση, η υποστήριξη και η ανάπτυξη δεν είναι διαφορετικά τμήματα με δικούς τους στόχους και στόχους. Η ανάπτυξη εμπλέκεται στη λειτουργία και το αντίστροφο. Η διάσημη φράση των κατανεμημένων ομάδων: «Το πρόβλημα δεν είναι με το μέρος μου» δεν εμφανίζεται πλέον στις συνομιλίες τόσο συχνά και οι τελικοί χρήστες γίνονται λίγο πιο χαρούμενοι.
Πηγή: www.habr.com