Το SRE (Site Reliability Engineering) είναι μια προσέγγιση για να γίνουν προσβάσιμα έργα web. Θεωρείται πλαίσιο για DevOps και λέει πώς να πετύχετε στην εφαρμογή των πρακτικών DevOps. Αυτό το άρθρο μεταφράζεται βιβλία από την Google. Ετοίμασα αυτή τη μετάφραση μόνος μου και βασίστηκα στη δική μου εμπειρία στην κατανόηση των διαδικασιών παρακολούθησης. Στο κανάλι του τηλεγραφήματος и Δημοσίευσα επίσης έναν σύνδεσμο προς μια μετάφραση του Κεφαλαίου 4 του ίδιου βιβλίου σχετικά με τους Στόχους Επιπέδου Υπηρεσιών.
Μετάφραση από cat. Απολαύστε την ανάγνωση!
Οι ομάδες Google SRE διαθέτουν βασικές αρχές και βέλτιστες πρακτικές για τη δημιουργία επιτυχημένων συστημάτων παρακολούθησης και ειδοποίησης. Αυτό το κεφάλαιο παρέχει συστάσεις σχετικά με τα προβλήματα που μπορεί να αντιμετωπίσει ένας επισκέπτης ιστοσελίδας και πώς να επιλύσετε προβλήματα που δυσκολεύουν την εμφάνιση ιστοσελίδων.
Ορισμοί
Δεν υπάρχει ενιαίο λεξιλόγιο που να χρησιμοποιείται για τη συζήτηση θεμάτων που σχετίζονται με την παρακολούθηση. Ακόμη και στο Google, οι παρακάτω όροι δεν είναι σε κοινή χρήση, αλλά θα παραθέσουμε τις πιο κοινές ερμηνείες.
Παρακολούθηση
Συλλογή, επεξεργασία, συγκέντρωση και εμφάνιση ποσοτικών δεδομένων σε πραγματικό χρόνο σχετικά με το σύστημα: αριθμός αιτημάτων και τύποι αιτημάτων, αριθμός σφαλμάτων και τύποι σφαλμάτων, χρόνος επεξεργασίας αιτημάτων και χρόνος λειτουργίας διακομιστή.
Παρακολούθηση λευκού κουτιού
Παρακολούθηση με βάση τις μετρήσεις που εμφανίζονται από εσωτερικά στοιχεία του συστήματος, συμπεριλαμβανομένων των αρχείων καταγραφής, των μετρήσεων προφίλ χειριστή JVM ή HTTP που δημιουργούν εσωτερικά στατιστικά στοιχεία.
Παρακολούθηση μαύρου κουτιού
Δοκιμή της συμπεριφοράς της εφαρμογής από τη σκοπιά του χρήστη.
Ταμπλό (πίνακες εργαλείων)
Μια διεπαφή (συνήθως μια διεπαφή ιστού) που παρέχει μια επισκόπηση των βασικών δεικτών υγείας των υπηρεσιών. Ο πίνακας ελέγχου μπορεί να έχει φίλτρα, δυνατότητα επιλογής μετρήσεων που θα εμφανίζονται κ.λπ. Η διεπαφή έχει σχεδιαστεί για να προσδιορίζει τις πιο σημαντικές μετρήσεις για τους χρήστες. Ο πίνακας εργαλείων μπορεί επίσης να εμφανίζει πληροφορίες για το προσωπικό τεχνικής υποστήριξης: μια ουρά αιτημάτων, μια λίστα σφαλμάτων υψηλής προτεραιότητας, έναν εκτεθειμένο μηχανικό για μια δεδομένη περιοχή ευθύνης.
Ειδοποίηση (ειδοποίηση)
Ειδοποιήσεις που προορίζονται να ληφθούν από ένα άτομο μέσω e-mail ή με άλλο τρόπο, οι οποίες μπορεί να προκληθούν ως αποτέλεσμα σφαλμάτων ή αύξησης της ουράς αιτημάτων. Οι ειδοποιήσεις κατηγοριοποιούνται ως εξής: εισιτήρια, ειδοποιήσεις μέσω email και μηνύματα messenger.
Βασική αιτία (ριζική αιτία)
Ελάττωμα λογισμικού ή ανθρώπινο σφάλμα που, όταν διορθωθεί, δεν θα πρέπει να εμφανιστεί ξανά. Το πρόβλημα μπορεί να έχει πολλούς κύριους λόγους: ανεπαρκής αυτοματοποίηση διεργασιών, ελάττωμα λογισμικού, ανεπαρκής μελέτη της λογικής της εφαρμογής. Καθένας από αυτούς τους παράγοντες μπορεί να είναι η βασική αιτία και καθένας από αυτούς πρέπει να εξαλειφθεί.
Κόμβος και μηχανή (κόμβος και μηχανή)
Εναλλάξιμοι όροι που αναφέρονται σε μια μεμονωμένη παρουσία μιας εφαρμογής που εκτελείται σε φυσικό διακομιστή, εικονική μηχανή ή κοντέινερ. Μπορεί να υπάρχουν πολλές υπηρεσίες σε ένα μηχάνημα. Οι υπηρεσίες μπορεί να είναι:
- που σχετίζονται μεταξύ τους: για παράδειγμα, ένας διακομιστής κρυφής μνήμης και ένας διακομιστής ιστού.
- άσχετες υπηρεσίες στο ίδιο υλικό: για παράδειγμα, ένα αποθετήριο κώδικα και ένας οδηγός για ένα σύστημα διαμόρφωσης, όπως π.χ. ή .
Σπρώξτε
Οποιαδήποτε αλλαγή στη διαμόρφωση του λογισμικού.
Γιατί χρειάζεται παρακολούθηση
Υπάρχουν διάφοροι λόγοι για τους οποίους οι εφαρμογές πρέπει να παρακολουθούνται:
Ανάλυση μακροπρόθεσμων τάσεων
Πόσο μεγάλη είναι η βάση δεδομένων και πόσο γρήγορα αναπτύσσεται; Πώς αλλάζει ο ημερήσιος αριθμός χρηστών;
Σύγκριση απόδοσης
Είναι τα ερωτήματα πιο γρήγορα στο Acme Bucket of Bytes 2.72 από το Ajax DB 3.14; Πόσο καλύτερα αποθηκεύονται τα αιτήματα στην κρυφή μνήμη μετά την εμφάνιση ενός πρόσθετου κόμβου; Έχει γίνει ο ιστότοπος πιο αργός από την προηγούμενη εβδομάδα;
Ειδοποίηση (ειδοποιήσεις)
Κάτι έχει χαλάσει και κάποιος πρέπει να το φτιάξει. Ή κάτι θα σπάσει σύντομα και κάποιος πρέπει να το ελέγξει σύντομα.
Δημιουργία πινάκων ελέγχου
Οι πίνακες ελέγχου πρέπει να απαντούν σε βασικές ερωτήσεις και να περιλαμβάνουν κάτι από - καθυστερήσεις (λανθάνουσα κατάσταση), κίνηση (κίνηση), σφάλματα (σφάλματα) και τιμή φορτίου (κορεσμός).
Διεξαγωγή αναδρομικής ανάλυσης (debugging)
Η καθυστέρηση επεξεργασίας αιτημάτων αυξήθηκε, τι άλλο συνέβη την ίδια ώρα;
Τα συστήματα παρακολούθησης είναι χρήσιμα ως πηγή δεδομένων για συστήματα επιχειρηματικής ευφυΐας και για τη διευκόλυνση της ανάλυσης περιστατικών ασφαλείας. Δεδομένου ότι αυτό το βιβλίο εστιάζει σε τομείς μηχανικής στους οποίους οι SRE διαθέτουν εξειδίκευση, δεν θα συζητήσουμε εδώ τις τεχνικές παρακολούθησης.
Η παρακολούθηση και οι ειδοποιήσεις επιτρέπουν στο σύστημα να πει πότε έχει σπάσει ή πρόκειται να σπάσει. Όταν ένα σύστημα δεν μπορεί να επιδιορθωθεί αυτόματα, θέλουμε ένας άνθρωπος να αναλύσει την ειδοποίηση, να προσδιορίσει εάν το πρόβλημα εξακολουθεί να υπάρχει, να το διορθώσει και να προσδιορίσει τη βασική του αιτία. Εάν δεν ελέγχετε τα στοιχεία του συστήματος, δεν θα λάβετε ποτέ ειδοποίηση μόνο και μόνο επειδή "κάτι φαίνεται λίγο περίεργο".
Η φόρτωση ανθρώπινων ειδοποιήσεων είναι μια μάλλον δαπανηρή χρήση του χρόνου ενός υπαλλήλου. Εάν ο υπάλληλος εργάζεται, η ειδοποίηση διακόπτει τη ροή εργασίας. Εάν ο υπάλληλος βρίσκεται στο σπίτι, η ειδοποίηση διακόπτει τον προσωπικό χρόνο και πιθανώς τον ύπνο. Όταν οι ειδοποιήσεις εμφανίζονται πολύ συχνά, οι εργαζόμενοι παραλείπουν, καθυστερούν ή αγνοούν τις εισερχόμενες ειδοποιήσεις. Από καιρό σε καιρό αγνοούν την πραγματική ειδοποίηση, η οποία καλύπτεται από γεγονότα θορύβου. Οι διακοπές σέρβις μπορεί να διαρκέσουν για μεγάλο χρονικό διάστημα, καθώς τα συμβάντα θορύβου εμποδίζουν την ταχεία διάγνωση και επίλυση προβλημάτων. Τα αποτελεσματικά συστήματα δημόσιας αναγγελίας έχουν καλή αναλογία σήματος προς θόρυβο.
Προσδιορισμός εύλογων προσδοκιών από το σύστημα παρακολούθησης
Η ρύθμιση της παρακολούθησης για μια σύνθετη εφαρμογή είναι μια πολύπλοκη μηχανική εργασία από μόνη της. Ακόμη και με μια σημαντική υποδομή εργαλείων συλλογής, προβολής και ειδοποίησης, μια ομάδα 10-12 μελών της Google SRE περιλαμβάνει συνήθως ένα ή δύο άτομα των οποίων ο κύριος σκοπός είναι η κατασκευή και η συντήρηση συστημάτων παρακολούθησης. Αυτός ο αριθμός μειώθηκε με την πάροδο του χρόνου καθώς γενικεύουμε και συγκεντρώνουμε την υποδομή παρακολούθησης, αλλά κάθε ομάδα SRE έχει συνήθως τουλάχιστον ένα μέλος του προσωπικού μόνο για παρακολούθηση. Πρέπει να ειπωθεί ότι ενώ είναι πολύ ενδιαφέρον να παρακολουθείτε τους πίνακες εργαλείων του συστήματος παρακολούθησης, οι ομάδες SRE αποφεύγουν προσεκτικά καταστάσεις που απαιτούν από κάποιον να κοιτάξει την οθόνη για να παρακολουθεί προβλήματα.
Γενικά, η Google έχει προχωρήσει σε απλά και γρήγορα συστήματα παρακολούθησης με βέλτιστα εργαλεία ανάλυσης εκ των υστέρων. Αποφεύγουμε τα «μαγικά» συστήματα που προσπαθούν να προβλέψουν τα κατώφλια ή να ανακαλύψουν αυτόματα τη βασική αιτία. Οι αισθητήρες που ανιχνεύουν ανεπιθύμητο περιεχόμενο σε αιτήματα τελικού χρήστη είναι το μόνο αντιπαράδειγμα. Όσο αυτοί οι αισθητήρες παραμένουν απλοί, μπορούν να ανιχνεύσουν γρήγορα τις αιτίες σοβαρών ανωμαλιών. Άλλες μορφές χρήσης δεδομένων παρακολούθησης, όπως ο σχεδιασμός χωρητικότητας ή η πρόβλεψη κίνησης, είναι πιο απαιτητικές. Μια παρατήρηση για πολύ μεγάλο χρονικό διάστημα (μήνες ή χρόνια) με χαμηλό ρυθμό δειγματοληψίας (ώρες ή ημέρες) θα αποκαλύψει μια μακροπρόθεσμη τάση.
Η ομάδα της Google SRE έχει εργαστεί με διάφορους βαθμούς επιτυχίας με πολύπλοκες ιεραρχίες εξαρτήσεων. Σπάνια χρησιμοποιούμε κανόνες όπως "αν μάθω ότι η βάση δεδομένων έχει γίνει αργή, λαμβάνω μια ειδοποίηση επιβράδυνσης της βάσης δεδομένων, διαφορετικά λαμβάνω μια αργή ειδοποίηση ιστότοπου." Οι κανόνες που βασίζονται στην εξάρτηση αναφέρονται συνήθως στα αμετάβλητα μέρη του συστήματός μας, όπως το σύστημα φιλτραρίσματος της επισκεψιμότητας των χρηστών στο κέντρο δεδομένων. Για παράδειγμα, "εάν έχει ρυθμιστεί το φιλτράρισμα της κυκλοφορίας του κέντρου δεδομένων, μην με ειδοποιείστε για καθυστερήσεις στην επεξεργασία των αιτημάτων των χρηστών" είναι ένας κοινός κανόνας για τις ειδοποιήσεις του κέντρου δεδομένων. Λίγες ομάδες της Google υποστηρίζουν σύνθετες ιεραρχίες εξαρτήσεων, επειδή η υποδομή μας έχει σταθερό ρυθμό συνεχούς ανακατασκευής.
Μερικές από τις ιδέες που περιγράφονται σε αυτό το κεφάλαιο εξακολουθούν να ισχύουν: υπάρχει πάντα ένας τρόπος να μεταβείτε πιο γρήγορα από το σύμπτωμα στη βασική αιτία, ειδικά σε συστήματα που αλλάζουν συνεχώς. Επομένως, ενώ αυτό το κεφάλαιο περιγράφει ορισμένους στόχους για τα συστήματα παρακολούθησης και τον τρόπο επίτευξης αυτών των στόχων, είναι σημαντικό τα συστήματα παρακολούθησης να είναι απλά και κατανοητά σε όλους στην ομάδα.
Ομοίως, για να διατηρηθεί το επίπεδο θορύβου χαμηλό και το επίπεδο σήματος υψηλό, οι προσεγγίσεις για την παρακολούθηση αντικειμένων που ειδοποιούνται πρέπει να είναι πολύ απλές και αξιόπιστες. Οι κανόνες που δημιουργούν προειδοποιήσεις για τους ανθρώπους θα πρέπει να είναι εύκολα κατανοητοί και να παρουσιάζουν ένα σαφές πρόβλημα.
Συμπτώματα έναντι αιτιών
Το σύστημά σας παρακολούθησης θα πρέπει να απαντά σε δύο ερωτήσεις: «τι είναι χαλασμένο» και «γιατί είναι χαλασμένο».
Το «τι έσπασε» αναφέρεται στο σύμπτωμα και το «γιατί έσπασε» αναφέρεται στην αιτία. Ο παρακάτω πίνακας δείχνει παραδείγματα τέτοιων συνδέσμων.
Σύμπτωμα
λόγος
Λήψη σφάλματος HTTP 500 ή 404
Οι διακομιστές βάσεων δεδομένων αρνούνται τις συνδέσεις
Αργή απαντήσεις διακομιστή
Υψηλή χρήση CPU ή κατεστραμμένο καλώδιο Ethernet
Οι χρήστες στην Ανταρκτική δεν λαμβάνουν GIF για γάτες
Το CDN σας μισεί τους επιστήμονες και τα αιλουροειδή, επομένως ορισμένες IP βρίσκονται στη μαύρη λίστα
Ιδιωτικό περιεχόμενο είναι διαθέσιμο παντού
Η κυκλοφορία μιας νέας έκδοσης λογισμικού έκανε το τείχος προστασίας να ξεχάσει όλα τα ACL και να αφήσει όλους να εισέλθουν
Το "Τι" και το "γιατί" είναι ένα από τα πιο σημαντικά δομικά στοιχεία για τη δημιουργία ενός καλού συστήματος παρακολούθησης με μέγιστο σήμα και ελάχιστο θόρυβο.
Black-box εναντίον White-box
Συνδυάζουμε εκτεταμένη παρακολούθηση λευκού κουτιού με μέτρια παρακολούθηση μαύρου κουτιού για κρίσιμες μετρήσεις. Ο ευκολότερος τρόπος σύγκρισης του Blackbox με το White-box είναι ότι το Blackbox εστιάζεται στα συμπτώματα και είναι αντιδραστική και όχι προληπτική παρακολούθηση: «το σύστημα δεν λειτουργεί σωστά αυτήν τη στιγμή». Το White-box εξαρτάται από τις δυνατότητες εσωτερικού ελέγχου των συστημάτων: αρχεία καταγραφής συμβάντων ή διακομιστές ιστού. Έτσι, το White-box σάς επιτρέπει να εντοπίσετε επερχόμενα προβλήματα, δυσλειτουργίες που μοιάζουν με αναμετάδοση ενός αιτήματος κ.λπ.
Σημειώστε ότι σε ένα πολυεπίπεδο σύστημα, ένα σύμπτωμα στον τομέα της ευθύνης ενός μηχανικού είναι ένα σύμπτωμα στον τομέα της ευθύνης ενός άλλου μηχανικού. Για παράδειγμα, η απόδοση της βάσης δεδομένων έχει μειωθεί. Οι αργές αναγνώσεις βάσης δεδομένων είναι ένα σύμπτωμα της βάσης δεδομένων SRE που τις εντοπίζει. Ωστόσο, για ένα front-end SRE που παρακολουθεί έναν αργό ιστότοπο, ο λόγος για την ίδια αργή ανάγνωση της βάσης δεδομένων είναι ότι η βάση δεδομένων είναι αργή. Ως εκ τούτου, η παρακολούθηση λευκού κουτιού άλλοτε εστιάζεται στα συμπτώματα και άλλοτε στα αίτια, ανάλογα με το πόσο εκτεταμένη είναι.
Κατά τη συλλογή τηλεμετρίας για εντοπισμό σφαλμάτων, απαιτείται παρακολούθηση White-box. Εάν οι διακομιστές ιστού αργούν να ανταποκριθούν σε ερωτήματα βάσης δεδομένων, πρέπει να γνωρίζετε πόσο γρήγορα ο διακομιστής Ιστού επικοινωνεί με τη βάση δεδομένων και πόσο γρήγορα ανταποκρίνεται. Διαφορετικά, δεν θα μπορείτε να διακρίνετε τη διαφορά μεταξύ ενός αργού διακομιστή βάσης δεδομένων και ενός προβλήματος δικτύου μεταξύ του διακομιστή web και της βάσης δεδομένων.
Η παρακολούθηση μαύρου κουτιού έχει ένα βασικό πλεονέκτημα κατά την αποστολή ειδοποιήσεων: ενεργοποιείτε μια ειδοποίηση στον παραλήπτη όταν το πρόβλημα έχει ήδη προκαλέσει πραγματικά συμπτώματα. Από την άλλη, για το πρόβλημα του Black-box που δεν έχει προκύψει ακόμη, αλλά για το επερχόμενο, η παρακολούθηση είναι άχρηστη.
Τέσσερα χρυσά σήματα
Τα τέσσερα χρυσά σήματα παρακολούθησης είναι η καθυστέρηση, η κίνηση, τα σφάλματα και ο κορεσμός. Εάν μπορείτε να μετρήσετε μόνο τέσσερις μετρήσεις συστήματος χρηστών, εστιάστε σε αυτές τις τέσσερις.
Καθυστέρηση
Ο χρόνος που απαιτείται για την επεξεργασία του αιτήματος. Είναι σημαντικό να γίνει διάκριση μεταξύ του λανθάνοντος χρόνου επιτυχημένων και αποτυχημένων αιτημάτων. Για παράδειγμα, ένα σφάλμα HTTP 500 που προκαλείται από μια απώλεια σύνδεσης με μια βάση δεδομένων ή άλλο backend μπορεί να διαγνωστεί πολύ γρήγορα, ωστόσο, ένα σφάλμα HTTP 500 μπορεί να υποδεικνύει αποτυχημένο αίτημα. Η εύρεση της επίδρασης ενός σφάλματος 500 στη συνολική καθυστέρηση μπορεί να οδηγήσει σε λανθασμένα συμπεράσματα. Από την άλλη, ένα αργό σφάλμα είναι ακόμη και ένα γρήγορο σφάλμα! Επομένως, είναι σημαντικό να παρακολουθείτε τον λανθάνοντα χρόνο σφαλμάτων αντί να φιλτράρετε απλώς τα σφάλματα.
Κυκλοφορία
Ο αριθμός των αιτημάτων προς το σύστημά σας, μετρημένος σε μετρήσεις συστήματος υψηλού επιπέδου. Για μια υπηρεσία Ιστού, αυτή η μέτρηση αντιπροσωπεύει συνήθως τον αριθμό των αιτημάτων HTTP ανά δευτερόλεπτο διαιρεμένο με τη φύση των αιτημάτων (για παράδειγμα, στατικό ή δυναμικό περιεχόμενο). Για ένα σύστημα ροής ήχου, αυτή η μέτρηση μπορεί να επικεντρωθεί στον ρυθμό I/O του δικτύου ή στον αριθμό των ταυτόχρονων περιόδων σύνδεσης. Για ένα σύστημα αποθήκευσης κλειδιού-τιμής, αυτή η μέτρηση θα μπορούσε να είναι συναλλαγές ή αναζητήσεις ανά δευτερόλεπτο.
Λάθη
Αυτό είναι το ποσοστό των αποτυχημένων αιτημάτων, είτε ρητά (για παράδειγμα, HTTP 500), σιωπηρά (για παράδειγμα, HTTP 200 αλλά σε συνδυασμό με κακό περιεχόμενο) είτε βάσει πολιτικής (για παράδειγμα, "Εάν καταγράψετε μια απάντηση σε ένα δευτερόλεπτο, οποιαδήποτε ένα δευτερόλεπτο είναι σφάλμα"). Εάν δεν υπάρχουν αρκετοί κωδικοί απόκρισης HTTP για την έκφραση όλων των συνθηκών αποτυχίας, ενδέχεται να απαιτούνται δευτερεύοντα (εσωτερικά) πρωτόκολλα για τον εντοπισμό μερικής αποτυχίας. Η παρακολούθηση όλων αυτών των λανθασμένων αιτημάτων μπορεί να είναι μη ενημερωτική, ενώ οι δοκιμές συστήματος από άκρο σε άκρο μπορούν να σας βοηθήσουν να ανακαλύψετε ότι επεξεργάζεστε λάθος περιεχόμενο.
Κορεσμός
Η μέτρηση δείχνει πόσο βαριά χρησιμοποιείται η υπηρεσία σας. Αυτό είναι ένα μέτρο παρακολούθησης συστήματος που προσδιορίζει τους πόρους που είναι πιο περιορισμένοι (για παράδειγμα, σε ένα σύστημα με περιορισμένη μνήμη, εμφανίζει μνήμη, σε ένα σύστημα με περιορισμένο I/O, δείχνει τον αριθμό των I/O). Σημειώστε ότι πολλά συστήματα υποβαθμίζονται πριν φτάσουν στο 100% της χρήσης, επομένως είναι απαραίτητο να έχετε έναν στόχο χρήσης.
Σε πολύπλοκα συστήματα, ο κορεσμός μπορεί να συμπληρωθεί με μέτρηση φορτίου υψηλότερου επιπέδου: μπορεί η υπηρεσία σας να χειριστεί σωστά τη διπλή κίνηση, να χειριστεί μόνο 10% περισσότερη κίνηση ή να χειριστεί ακόμη λιγότερη κίνηση από αυτήν που μπορεί σήμερα; Για απλές υπηρεσίες που δεν έχουν παραμέτρους που αλλάζουν την πολυπλοκότητα του αιτήματος (π.χ. "Δώστε μου τίποτα" ή "Χρειάζομαι έναν μοναδικό μονοτονικό ακέραιο") που σπάνια αλλάζουν διαμόρφωση, μια τιμή δοκιμής στατικού φορτίου μπορεί να είναι επαρκής. Ωστόσο, Όπως συζητήθηκε στην προηγούμενη παράγραφο, οι περισσότερες υπηρεσίες θα πρέπει να χρησιμοποιούν έμμεσα σήματα, όπως η χρήση της CPU ή το εύρος ζώνης δικτύου που έχουν γνωστό άνω όριο. Η αυξανόμενη καθυστέρηση είναι συχνά ο κύριος δείκτης κορεσμού. Η μέτρηση του χρόνου απόκρισης του 99ου εκατοστημόριου σε ένα μικρό παράθυρο (π.χ. ένα λεπτό) μπορεί να δώσει ένα πολύ πρώιμο σήμα κορεσμού.
Τέλος, ο κορεσμός σχετίζεται επίσης με προβλέψεις επικείμενου κορεσμού, όπως: "Φαίνεται ότι η βάση δεδομένων σας θα γεμίσει τον σκληρό σας δίσκο σε 4 ώρες".
Εάν μετρήσετε και τα τέσσερα χρυσά σήματα και όταν υπάρχει πρόβλημα με μία από τις μετρήσεις (ή, σε περίπτωση κορεσμού, σχεδόν πρόβλημα), ειδοποιήσετε το άτομο, η υπηρεσία σας θα καλύπτεται λίγο πολύ από την παρακολούθηση.
Ανησυχείτε για την ουρά (ή τα όργανα και την απόδοση)
Κατά την κατασκευή ενός συστήματος παρακολούθησης από την αρχή, είναι δελεαστικό να αναπτυχθεί ένα σύστημα που βασίζεται σε μέσους όρους: μέση καθυστέρηση, μέση χρήση CPU κόμβου ή μέση πληρότητα βάσης δεδομένων. Ο κίνδυνος των δύο τελευταίων παραδειγμάτων είναι προφανής: οι επεξεργαστές και οι βάσεις δεδομένων απορρίπτονται με πολύ απρόβλεπτο τρόπο. Το ίδιο ισχύει και για την καθυστέρηση. Εάν εκτελείτε μια υπηρεσία Ιστού με μέσο χρόνο καθυστέρησης 100ms σε 1000 αιτήματα ανά δευτερόλεπτο, το 1% των αιτημάτων μπορεί να διαρκέσει 5 δευτερόλεπτα. Εάν οι χρήστες εξαρτώνται από πολλές τέτοιες υπηρεσίες web, το 99ο εκατοστημόριο ενός μεμονωμένου backend μπορεί εύκολα να γίνει ο διάμεσος χρόνος απόκρισης της διεπαφής.
Ο απλούστερος τρόπος για να γίνει διάκριση μεταξύ ενός αργού μέσου όρου και μιας πολύ αργής ουράς αιτημάτων είναι η συλλογή μετρήσεων των αιτημάτων που εκφράζονται σε στατιστικά στοιχεία (τα ιστογράμματα είναι ένα κατάλληλο εργαλείο για εμφάνιση), αντί για πραγματικές καθυστερήσεις: πόσα αιτήματα εξυπηρετήθηκαν από την υπηρεσία που έλαβε μεταξύ 0 ms και 10 ms, μεταξύ 10 ms και 30 ms, μεταξύ 30 ms και 100 ms, μεταξύ 100 ms και 300 ms, κ.λπ. Η επέκταση των ορίων του ιστογράμματος περίπου εκθετικά (με συντελεστή περίπου 3) είναι συχνά ένας εύκολος τρόπος οπτικοποίησης της κατανομής των αιτημάτων.
Επιλογή της σωστής κοκκοποίησης για μετρήσεις
Διαφορετικά στοιχεία του συστήματος θα πρέπει να μετρώνται με διαφορετικά επίπεδα λεπτομέρειας. Για παράδειγμα:
- Η παρακολούθηση της χρήσης της CPU για μια χρονική περίοδο δεν θα εμφανίσει μεγάλες αιχμές που οδηγούν σε υψηλές καθυστερήσεις.
- Από την άλλη πλευρά, για μια υπηρεσία ιστού που στοχεύει όχι περισσότερες από 9 ώρες διακοπής λειτουργίας ετησίως (99,9% ετήσιος χρόνος λειτουργίας), ο έλεγχος για απόκριση HTTP 200 περισσότερες από μία ή δύο φορές ανά λεπτό θα ήταν πιθανώς άσκοπα συχνός.
- Ομοίως, ο έλεγχος για ελεύθερο χώρο στον σκληρό δίσκο για 99,9% διαθεσιμότητα περισσότερες από μία φορά κάθε 1-2 λεπτά είναι πιθανώς περιττός.
Προσέξτε πώς δομείτε την κοκκοποίηση των διαστάσεων. Ένας ρυθμός χρήσης της CPU 1 ανά δευτερόλεπτο μπορεί να παρέχει ενδιαφέροντα δεδομένα, αλλά τέτοιες συχνές μετρήσεις μπορεί να είναι πολύ ακριβές στη συλλογή, αποθήκευση και ανάλυση. Εάν ο στόχος παρακολούθησης απαιτεί υψηλή ευαισθησία και δεν απαιτεί υψηλή απόκριση, μπορείτε να μειώσετε αυτά τα κόστη ρυθμίζοντας τη συλλογή μετρήσεων στον διακομιστή και στη συνέχεια διαμορφώνοντας ένα εξωτερικό σύστημα για τη συλλογή και τη συγκέντρωση αυτών των μετρήσεων. Θα μπορούσες:
- Μετρήστε τη χρήση της CPU κάθε δευτερόλεπτο.
- Μειώστε τις λεπτομέρειες στο 5%.
- Συγκεντρώστε μετρήσεις κάθε λεπτό.
Αυτή η στρατηγική θα σας επιτρέψει να συλλέγετε εξαιρετικά αναλυτικά δεδομένα χωρίς να αντιμετωπίζετε υψηλά γενικά έξοδα για ανάλυση και αποθήκευση.
Όσο πιο απλό γίνεται, αλλά όχι πιο εύκολο
Η στοίβαξη διαφορετικών απαιτήσεων η μία πάνω στην άλλη μπορεί να οδηγήσει σε ένα πολύ περίπλοκο σύστημα παρακολούθησης. Για παράδειγμα, το σύστημά σας μπορεί να έχει τα ακόλουθα περίπλοκα στοιχεία:
- Ειδοποιήσεις σύμφωνα με διαφορετικά όρια για καθυστέρηση αιτημάτων, σε διαφορετικά εκατοστημόρια, σε όλα τα είδη διαφορετικών μετρήσεων.
- Σύνταξη πρόσθετου κώδικα για τον εντοπισμό και τον εντοπισμό πιθανών αιτιών.
- Δημιουργήστε σχετικούς πίνακες εργαλείων για καθεμία από τις πιθανές αιτίες προβλημάτων.
Οι πηγές πιθανών επιπλοκών δεν τελειώνουν ποτέ. Όπως όλα τα συστήματα λογισμικού, η παρακολούθηση μπορεί να γίνει τόσο πολύπλοκη που γίνεται εύθραυστη, δύσκολη η αλλαγή και η συντήρηση της.
Επομένως, σχεδιάστε το σύστημα παρακολούθησης για να το απλοποιήσετε όσο το δυνατόν περισσότερο. Όταν επιλέγετε τι θα παρακολουθείτε, έχετε υπόψη σας τα εξής:
- Οι κανόνες που πιο συχνά καταγράφουν πραγματικά περιστατικά θα πρέπει να είναι όσο το δυνατόν πιο απλοί, προβλέψιμοι και αξιόπιστοι.
- Η διαμόρφωση για τη συλλογή δεδομένων, τη συγκέντρωση και την ειδοποίηση που εκτελείται σπάνια (για παράδειγμα, λιγότερο από κάθε τρίμηνο για ορισμένες ομάδες SRE) θα πρέπει να καταργηθεί.
- Οι μετρήσεις που συλλέγονται αλλά δεν εμφανίζονται σε κανένα πλαίσιο προεπισκόπησης ή χρησιμοποιούνται από οποιαδήποτε ειδοποίηση είναι υποψήφιες για διαγραφή.
Στη Google, η βασική συλλογή και η συγκέντρωση μετρήσεων, σε συνδυασμό με ειδοποιήσεις και πίνακες ελέγχου, λειτουργεί καλά ως ένα σχετικά αυτόνομο σύστημα (το σύστημα παρακολούθησης της Google είναι στην πραγματικότητα χωρισμένο σε πολλά υποσυστήματα, αλλά συνήθως οι άνθρωποι γνωρίζουν όλες τις πτυχές αυτών των υποσυστημάτων). Μπορεί να είναι δελεαστικό να συνδυάσετε την παρακολούθηση με άλλες μεθόδους δοκιμής πολύπλοκων συστημάτων: λεπτομερές προφίλ συστήματος, εντοπισμός σφαλμάτων διεργασιών, λεπτομέρειες παρακολούθησης εξαίρεσης ή αποτυχίας, δοκιμή φορτίου, συλλογή και ανάλυση αρχείων καταγραφής ή επιθεώρηση κυκλοφορίας. Ενώ τα περισσότερα από αυτά τα πράγματα μοιράζονται κοινά με τη βασική παρακολούθηση, η ανάμειξή τους θα οδηγήσει σε πάρα πολλά αποτελέσματα και θα δημιουργήσει ένα περίπλοκο και εύθραυστο σύστημα. Όπως συμβαίνει με πολλές άλλες πτυχές της ανάπτυξης λογισμικού, η υποστήριξη διαφορετικών συστημάτων με σαφή, απλά, χαλαρά συνδεδεμένα σημεία ολοκλήρωσης είναι η καλύτερη στρατηγική (για παράδειγμα, η χρήση ενός web API για την ανάκτηση συνοπτικών δεδομένων σε μορφή που μπορεί να παραμείνει σταθερή για μεγάλο χρονικό διάστημα ).
Σύνδεση αρχών μεταξύ τους
Οι αρχές που συζητούνται σε αυτό το κεφάλαιο μπορούν να συνδυαστούν σε μια φιλοσοφία παρακολούθησης και προειδοποίησης που υποστηρίζεται και ακολουθείται από τις ομάδες Google SRE. Η τήρηση αυτής της φιλοσοφίας παρακολούθησης είναι επιθυμητή, είναι ένα καλό σημείο εκκίνησης για τη δημιουργία ή την αναθεώρηση μιας μεθοδολογίας προειδοποίησης και μπορεί να σας βοηθήσει να κάνετε τις σωστές ερωτήσεις στις λειτουργίες ανεξάρτητα από το μέγεθος του οργανισμού σας ή την πολυπλοκότητα της υπηρεσίας ή του συστήματος.
Κατά τη δημιουργία κανόνων παρακολούθησης και ειδοποίησης, η υποβολή των ακόλουθων ερωτήσεων μπορεί να σας βοηθήσει να αποφύγετε ψευδώς θετικά και περιττές ειδοποιήσεις:
- Αυτός ο κανόνας εντοπίζει μια κατά τα άλλα μη ανιχνεύσιμη κατάσταση συστήματος που είναι επείγουσα, καλεί για δράση και αναπόφευκτα επηρεάζει τον χρήστη;
- Μπορώ να αγνοήσω αυτήν την προειδοποίηση γνωρίζοντας ότι είναι καλοήθης; Πότε και γιατί μπορώ να αγνοήσω αυτήν την προειδοποίηση και πώς μπορώ να αποφύγω αυτό το σενάριο;
- Σημαίνει αυτή η ειδοποίηση ότι οι χρήστες επηρεάζονται αρνητικά; Υπάρχουν περιπτώσεις όπου οι χρήστες δεν επηρεάζονται αρνητικά, για παράδειγμα, λόγω φιλτραρίσματος κυκλοφορίας ή όταν χρησιμοποιούνται δοκιμαστικά συστήματα, οι ειδοποιήσεις για τα οποία πρέπει να φιλτράρονται;
- Μπορώ να ενεργήσω ως απάντηση σε αυτήν την ειδοποίηση; Είναι επείγοντα αυτά τα μέτρα ή μπορούν να περιμένουν μέχρι το πρωί; Είναι ασφαλές να αυτοματοποιηθεί η ενέργεια; Αυτή η ενέργεια θα είναι μια μακροπρόθεσμη λύση ή μια βραχυπρόθεσμη λύση;
- Μερικοί άνθρωποι λαμβάνουν πολλαπλές ειδοποιήσεις για αυτό το ζήτημα, επομένως είναι δυνατόν να μειωθεί ο αριθμός;
Αυτές οι ερωτήσεις αντικατοπτρίζουν τη θεμελιώδη φιλοσοφία σχετικά με τις ειδοποιήσεις και τα συστήματα προειδοποίησης:
- Κάθε φορά που έρχεται μια ειδοποίηση, πρέπει να αντιδράσω επειγόντως. Μπορώ να βιάζομαι πολλές φορές την ημέρα πριν κουραστώ.
- Κάθε ειδοποίηση πρέπει να είναι ενημερωμένη.
- Κάθε απάντηση σε μια προειδοποίηση πρέπει να απαιτεί ανθρώπινη παρέμβαση. Εάν η ειδοποίηση μπορεί να επεξεργαστεί αυτόματα, δεν θα πρέπει να έρθει.
- Οι ειδοποιήσεις πρέπει να αφορούν ένα νέο ζήτημα ή ένα συμβάν που δεν έχει συμβεί στο παρελθόν.
Αυτή η προσέγγιση θολώνει ορισμένες διακρίσεις: εάν μια ειδοποίηση ικανοποιεί τις προηγούμενες τέσσερις προϋποθέσεις, δεν έχει σημασία αν η ειδοποίηση αποστέλλεται από ένα σύστημα παρακολούθησης White-box ή ένα Black-Box. Αυτή η προσέγγιση ενισχύει επίσης ορισμένες διαφορές: είναι καλύτερο να δαπανηθεί πολύ περισσότερη προσπάθεια για τον εντοπισμό των συμπτωμάτων παρά για τις αιτίες. όταν πρόκειται για αίτια, χρειάζεται να ανησυχείτε μόνο για τις αναπόφευκτες αιτίες.
Μακροχρόνια παρακολούθηση
Στα σημερινά περιβάλλοντα παραγωγής, τα συστήματα παρακολούθησης παρακολουθούν ένα συνεχώς εξελισσόμενο σύστημα παραγωγής με μεταβαλλόμενη αρχιτεκτονική λογισμικού, χαρακτηριστικά φορτίου και στόχους απόδοσης. Οι ειδοποιήσεις, οι οποίες επί του παρόντος είναι δύσκολο να αυτοματοποιηθούν, μπορεί να γίνουν κοινές, ίσως και να αξίζουν να αντιμετωπιστούν. Σε αυτό το σημείο, κάποιος πρέπει να βρει και να διορθώσει τις βασικές αιτίες του προβλήματος. Εάν μια τέτοια ανάλυση δεν είναι δυνατή, η αντίδραση στην ειδοποίηση απαιτεί πλήρη αυτοματοποίηση.
Είναι σημαντικό οι αποφάσεις παρακολούθησης να λαμβάνονται έχοντας κατά νου μακροπρόθεσμους στόχους. Κάθε ειδοποίηση που εκτελείται σήμερα απομακρύνει ένα άτομο από τη βελτίωση του συστήματος αύριο, επομένως υπάρχει συχνά μείωση στη διαθεσιμότητα ή στην απόδοση ενός παραγωγικού συστήματος για το χρόνο που απαιτείται για τη μακροπρόθεσμη βελτίωση του συστήματος παρακολούθησης. Ας δούμε δύο παραδείγματα που επεξηγούν αυτό το φαινόμενο.
Bigtable SRE: Μια ιστορία για υπερβολική ειδοποίηση
Η εσωτερική υποδομή της Google παρέχεται συνήθως και μετριέται με βάση το επίπεδο εξυπηρέτησης (SLO). Πριν από χρόνια, το SLO της υπηρεσίας Bigtable βασιζόταν στη μέση απόδοση μιας συνθετικής συναλλαγής που προσομοιώνει έναν τρέχοντα πελάτη. Λόγω προβλημάτων στο Bigtable και σε χαμηλότερα επίπεδα της στοίβας αποθήκευσης, η μέση απόδοση οδηγήθηκε από μια "μεγάλη" ουρά: το χειρότερο 5% των ερωτημάτων ήταν συχνά σημαντικά πιο αργά από τα υπόλοιπα.
Οι ειδοποιήσεις μέσω email στάλθηκαν καθώς πλησίαζε το όριο SLO και οι ειδοποιήσεις αγγελιοφόρων εστάλησαν σε περίπτωση υπέρβασης του SLO. Και οι δύο τύποι ειδοποιήσεων αποστέλλονταν αρκετά συχνά, καταναλώνοντας απαράδεκτα ποσά χρόνου μηχανικής: η ομάδα ξόδεψε σημαντικό χρόνο αναλύοντας τις ειδοποιήσεις για να βρει μερικές που ήταν πραγματικά σχετικές. Συχνά χάσαμε ένα ζήτημα που επηρέαζε πραγματικά τους χρήστες, επειδή μόνο μερικές από τις ειδοποιήσεις αφορούσαν το συγκεκριμένο ζήτημα. Πολλές από τις ειδοποιήσεις δεν ήταν επείγουσες λόγω κατανοητών προβλημάτων υποδομής και αντιμετωπίστηκαν με τυπικό τρόπο ή δεν αντιμετωπίστηκαν καθόλου.
Για να διορθώσει την κατάσταση, η ομάδα χρησιμοποίησε μια προσέγγιση με τρεις άξονες: ενώ εργαζόμαστε σκληρά για να βελτιώσουμε την απόδοση του Bigtable, ορίσαμε προσωρινά το 75ο εκατοστημόριο για την καθυστέρηση απόκρισης ερωτημάτων ως στόχο SLO. Επίσης, απενεργοποιήσαμε τις ειδοποιήσεις μέσω email, καθώς ήταν τόσες πολλές που ήταν αδύνατο να χάσουμε χρόνο για να τις διαγνώσουμε.
Αυτή η στρατηγική μας επέτρεψε να αρχίσουμε να επιδιορθώνουμε μακροπρόθεσμα ζητήματα στο Bigtable και στα χαμηλότερα επίπεδα της στοίβας αποθήκευσης, αντί να διορθώνουμε συνεχώς ζητήματα τακτικής. Οι μηχανικοί μπορούσαν πραγματικά να ολοκληρώσουν τη δουλειά τους όταν δεν βομβαρδίζονταν με ειδοποιήσεις όλη την ώρα. Τελικά, η προσωρινή καθυστέρηση στην επεξεργασία των ειδοποιήσεων μας επέτρεψε να βελτιώσουμε την ποιότητα της υπηρεσίας.
Gmail: Προβλέψιμες, Αλγοριθμικές Ανθρώπινες Αποκρίσεις
Στην αρχή, το Gmail χτίστηκε σε ένα τροποποιημένο σύστημα ελέγχου διεργασιών Workqueue που δημιουργήθηκε για να ομαδοποιεί κομμάτια ευρετηρίου αναζήτησης διεργασιών. Το Workqueue προσαρμόστηκε σε διαδικασίες μεγάλης διάρκειας και στη συνέχεια εφαρμόστηκε στο Gmail, αλλά ορισμένα σφάλματα στον αδιαφανή κώδικα χρονοπρογραμματιστή αποδείχθηκαν πολύ δύσκολο να διορθωθούν.
Εκείνη την εποχή, η παρακολούθηση του Gmail ήταν δομημένη έτσι ώστε οι ειδοποιήσεις να ενεργοποιούνται όταν ακυρώνονταν μεμονωμένες εργασίες χρησιμοποιώντας το Workqueue. Αυτή η προσέγγιση δεν ήταν ιδανική, επειδή ακόμη και εκείνη την εποχή το Gmail εκτελούσε πολλές χιλιάδες εργασίες, καθεμία από τις οποίες δόθηκε σε κλάσματα του ποσοστού των χρηστών μας. Φροντίσαμε πολύ για να διασφαλίσουμε ότι οι χρήστες του Gmail έχουν καλή εμπειρία χρήστη, αλλά ο χειρισμός πολλών ειδοποιήσεων ήταν εκτός θέματος.
Για να λύσει αυτό το πρόβλημα, το Gmail SRE δημιούργησε ένα εργαλείο για να βοηθήσει στον εντοπισμό σφαλμάτων του προγραμματιστή όσο το δυνατόν καλύτερα, ώστε να ελαχιστοποιηθεί ο αντίκτυπος στους χρήστες. Η ομάδα είχε πολλές συζητήσεις σχετικά με το εάν θα αυτοματοποιούσε απλώς ολόκληρο τον κύκλο από την εύρεση του προβλήματος έως την επίλυσή του μέχρι να βρεθεί μια μακροπρόθεσμη λύση, αλλά ορισμένοι ανησυχούσαν ότι μια τέτοια λύση θα καθυστερούσε την πραγματική διόρθωση του προβλήματος.
Αυτή η ένταση ήταν συνηθισμένη μέσα στην ομάδα και συχνά αντανακλούσε την έλλειψη εμπιστοσύνης στην αυτοπειθαρχία: ενώ ορισμένα μέλη της ομάδας θέλουν να δώσουν χρόνο για μια σωστή διόρθωση, άλλα ανησυχούν ότι η τελική λύση θα ξεχαστεί και η προσωρινή επιδιόρθωση θα διαρκέσει για πάντα. Αυτό το πρόβλημα αξίζει προσοχής, καθώς είναι πολύ εύκολο να διορθώσετε τα προβλήματα προσωρινά, αντί να κάνετε μόνιμη διόρθωση. Οι διευθυντές και το τεχνικό προσωπικό διαδραματίζουν βασικό ρόλο στην εφαρμογή μακροπρόθεσμων επιδιορθώσεων υποστηρίζοντας και δίνοντας προτεραιότητα σε πιθανές μακροπρόθεσμες διορθώσεις ακόμη και όταν ο αρχικός πόνος υποχωρεί.
Οι τακτικές επαναλαμβανόμενες ειδοποιήσεις και οι αλγοριθμικές αντιδράσεις θα πρέπει να είναι μια κόκκινη σημαία. Η απροθυμία της ομάδας σας να αυτοματοποιήσει αυτές τις ειδοποιήσεις σημαίνει ότι η ομάδα δεν έχει εμπιστοσύνη ότι μπορεί να εμπιστευτεί τους αλγόριθμους. Αυτό είναι ένα σοβαρό πρόβλημα που πρέπει να αντιμετωπιστεί.
Μακροπρόθεσμα
Ένα κοινό θέμα συνδέει τα παραδείγματα Bigtable και Gmail: ο ανταγωνισμός μεταξύ βραχυπρόθεσμης και μακροπρόθεσμης διαθεσιμότητας. Συχνά μια δυνατή προσπάθεια μπορεί να βοηθήσει ένα εύθραυστο σύστημα να επιτύχει υψηλή διαθεσιμότητα, αλλά αυτή η διαδρομή είναι συνήθως βραχύβια, γεμάτη με ομαδική εξάντληση και εξάρτηση από έναν μικρό αριθμό μελών αυτής της ίδιας ηρωικής ομάδας.
Μια ελεγχόμενη, βραχυπρόθεσμη μείωση της διαθεσιμότητας είναι συχνά επώδυνη, αλλά στρατηγικά σημαντική για τη μακροπρόθεσμη σταθερότητα του συστήματος. Είναι σημαντικό να μην εξετάζουμε κάθε ειδοποίηση μεμονωμένα, αλλά να εξετάζουμε εάν το συνολικό ποσοστό ειδοποιήσεων οδηγεί σε ένα υγιές, σωστά προσβάσιμο σύστημα με βιώσιμη ομάδα και ευνοϊκή πρόγνωση. Αναλύουμε στατιστικά του ποσοστού συναγερμών (συνήθως εκφράζονται ως περιστατικά ανά βάρδια, όπου ένα περιστατικό μπορεί να αποτελείται από πολλά σχετικά περιστατικά) σε τριμηνιαίες αναφορές με τη διοίκηση, επιτρέποντας στους υπεύθυνους λήψης αποφάσεων να παρουσιάζουν συνεχώς το φόρτο του συστήματος προειδοποίησης και τη συνολική υγεία της ομάδας.
Συμπέρασμα
Η πορεία προς την υγιή παρακολούθηση και ειδοποιήσεις είναι απλή και απλή. Επικεντρώνεται στα συμπτώματα του προβλήματος για το οποίο δημιουργούνται ειδοποιήσεις και η παρακολούθηση της αιτίας χρησιμεύει ως βοήθεια για την αποσφαλμάτωση προβλημάτων. Η παρακολούθηση των συμπτωμάτων είναι ευκολότερη όσο υψηλότερα βρίσκεστε στη στοίβα που ελέγχετε, αν και η παρακολούθηση του φορτίου της βάσης δεδομένων και της απόδοσης θα πρέπει να γίνεται απευθείας στην ίδια τη βάση δεδομένων. Οι ειδοποιήσεις μέσω email είναι πολύ περιορισμένης χρήσης και τείνουν να κλιμακώνονται εύκολα σε θόρυβο. Αντίθετα, θα πρέπει να χρησιμοποιήσετε έναν πίνακα εργαλείων που παρακολουθεί όλα τα τρέχοντα ζητήματα που ειδοποιούνται μέσω email. Ο πίνακας εργαλείων μπορεί επίσης να συνδυαστεί με ένα αρχείο καταγραφής συμβάντων για την ανάλυση ιστορικών συσχετίσεων.
Μακροπρόθεσμα, πρέπει να επιτευχθεί μια επιτυχημένη εναλλαγή μεταξύ ειδοποιήσεων συμπτωμάτων και επικείμενων πραγματικών προβλημάτων και να προσαρμοστούν οι στόχοι για να διασφαλιστεί ότι η παρακολούθηση υποστηρίζει την ταχεία διάγνωση.
Σας ευχαριστούμε που διαβάσατε τη μετάφραση μέχρι το τέλος. Εγγραφείτε στο κανάλι μου στο τηλεγράφημα σχετικά με την παρακολούθηση и .
Πηγή: www.habr.com