Τώρα το θέμα του DevOps είναι σε διαφημιστική εκστρατεία. Αγωγός συνεχούς ενοποίησης και παράδοσης όλοι το εφαρμόζουν. Αλλά οι περισσότεροι δεν δίνουν πάντα τη δέουσα προσοχή στη διασφάλιση της αξιοπιστίας των συστημάτων πληροφοριών σε διάφορα στάδια του αγωγού CI/CD. Σε αυτό το άρθρο θα ήθελα να μιλήσω για την εμπειρία μου στην αυτοματοποίηση των ελέγχων ποιότητας λογισμικού και στην εφαρμογή πιθανών σεναρίων για την «αυτοίασή» του.
Εργάζομαι ως μηχανικός στο τμήμα διαχείρισης υπηρεσιών πληροφορικής μιας εταιρείας . Ο βασικός τομέας εξειδίκευσής μου είναι η εφαρμογή διαφόρων συστημάτων παρακολούθησης απόδοσης και διαθεσιμότητας εφαρμογών. Επικοινωνώ συχνά με πελάτες πληροφορικής από διαφορετικά τμήματα της αγοράς σχετικά με τρέχοντα θέματα σχετικά με την παρακολούθηση της ποιότητας των υπηρεσιών πληροφορικής τους. Ο κύριος στόχος είναι η ελαχιστοποίηση του χρόνου του κύκλου απελευθέρωσης και η αύξηση της συχνότητας των απελευθερώσεων. Αυτό, φυσικά, είναι καλό: περισσότερες εκδόσεις - περισσότερες νέες δυνατότητες - περισσότεροι ικανοποιημένοι χρήστες - περισσότερα κέρδη. Αλλά στην πραγματικότητα, τα πράγματα δεν πάνε πάντα καλά. Με πολύ υψηλά ποσοστά ανάπτυξης, τίθεται αμέσως το ερώτημα σχετικά με την ποιότητα των εκδόσεων μας. Ακόμη και με έναν πλήρως αυτοματοποιημένο αγωγό, μία από τις μεγαλύτερες προκλήσεις είναι η μεταφορά των υπηρεσιών από τη δοκιμή στην παραγωγή χωρίς να επηρεάζεται ο χρόνος λειτουργίας της εφαρμογής και η εμπειρία χρήστη.
Με βάση τα αποτελέσματα πολυάριθμων συνομιλιών με πελάτες, μπορώ να πω ότι απελευθερώνεται ο ποιοτικός έλεγχος, το πρόβλημα της αξιοπιστίας της εφαρμογής και η δυνατότητα «αυτοίασης» της (για παράδειγμα, επαναφορά σε σταθερή έκδοση) σε διάφορα στάδια του CI Το /CD pipeline είναι από τα πιο συναρπαστικά και σχετικά θέματα.
Πρόσφατα, ο ίδιος εργάστηκα από την πλευρά του πελάτη - στην υπηρεσία υποστήριξης λογισμικού εφαρμογών διαδικτυακής τραπεζικής. Η αρχιτεκτονική της εφαρμογής μας χρησιμοποιούσε μεγάλο αριθμό αυτογραφικών μικροϋπηρεσιών. Το πιο λυπηρό είναι ότι δεν μπόρεσαν όλοι οι προγραμματιστές να αντεπεξέλθουν στον υψηλό ρυθμό ανάπτυξης· η ποιότητα ορισμένων μικροϋπηρεσιών υπέφερε, γεγονός που προκάλεσε αστεία ψευδώνυμα για αυτούς και τους δημιουργούς τους. Υπήρχαν ιστορίες για τα υλικά από τα οποία κατασκευάστηκαν αυτά τα προϊόντα.
«Διατύπωση του προβλήματος»
Η υψηλή συχνότητα εκδόσεων και ο μεγάλος αριθμός μικροϋπηρεσιών καθιστούν δύσκολη την κατανόηση της λειτουργίας της εφαρμογής στο σύνολό της, τόσο στο στάδιο της δοκιμής όσο και στο στάδιο της λειτουργίας. Οι αλλαγές συμβαίνουν συνεχώς και είναι πολύ δύσκολο να τις ελέγξετε χωρίς καλά εργαλεία παρακολούθησης. Συχνά, μετά από μια νυχτερινή κυκλοφορία το πρωί, οι προγραμματιστές κάθονται σαν σε πυριτιδαποθήκη και περιμένουν να μην σπάσει τίποτα, αν και όλοι οι έλεγχοι ήταν επιτυχείς στο στάδιο της δοκιμής.
Υπάρχει ακόμα ένα σημείο. Στο στάδιο της δοκιμής, ελέγχεται η λειτουργικότητα του λογισμικού: η υλοποίηση των κύριων λειτουργιών της εφαρμογής και η απουσία σφαλμάτων. Οι ποιοτικές αξιολογήσεις απόδοσης είτε λείπουν είτε δεν λαμβάνουν υπόψη όλες τις πτυχές της εφαρμογής και του επιπέδου ολοκλήρωσης. Ορισμένες μετρήσεις ενδέχεται να μην ελέγχονται καθόλου. Ως αποτέλεσμα, όταν συμβαίνει μια βλάβη σε ένα περιβάλλον παραγωγής, το τμήμα τεχνικής υποστήριξης το μαθαίνει μόνο όταν οι πραγματικοί χρήστες αρχίσουν να παραπονιούνται. Θα ήθελα να ελαχιστοποιήσω τον αντίκτυπο του λογισμικού χαμηλής ποιότητας στους τελικούς χρήστες.
Μία από τις λύσεις είναι η εφαρμογή διαδικασιών για τον έλεγχο της ποιότητας του λογισμικού σε διάφορα στάδια του αγωγού CI/CD και η προσθήκη διαφόρων σεναρίων για την επαναφορά του συστήματος σε περίπτωση έκτακτης ανάγκης. Θυμόμαστε επίσης ότι έχουμε DevOps. Οι επιχειρήσεις αναμένουν να λάβουν ένα νέο προϊόν το συντομότερο δυνατό. Επομένως, όλοι οι έλεγχοι και τα σενάρια μας πρέπει να είναι αυτοματοποιημένα.
Η εργασία χωρίζεται σε δύο μέρη:
- ποιοτικός έλεγχος των συγκροτημάτων στο στάδιο της δοκιμής (για την αυτοματοποίηση της διαδικασίας σύλληψης συγκροτημάτων χαμηλής ποιότητας).
- έλεγχος ποιότητας λογισμικού στο περιβάλλον παραγωγής (μηχανισμοί αυτόματης ανίχνευσης προβλημάτων και πιθανά σενάρια αυτοίασής τους).
Εργαλείο παρακολούθησης και συλλογής μετρήσεων
Για να επιτευχθούν οι καθορισμένοι στόχοι απαιτείται ένα σύστημα παρακολούθησης που μπορεί να ανιχνεύει προβλήματα και να τα μεταφέρει σε συστήματα αυτοματισμού σε διάφορα στάδια του αγωγού CI/CD. Θα είναι επίσης θετικό εάν αυτό το σύστημα παρέχει χρήσιμες μετρήσεις για διάφορες ομάδες: ανάπτυξη, δοκιμή, λειτουργία. Και είναι απολύτως υπέροχο αν είναι και για επαγγελματικούς λόγους.
Για τη συλλογή μετρήσεων, μπορείτε να χρησιμοποιήσετε ένα σύνολο διαφορετικών συστημάτων (Prometheus, ELK Stack, Zabbix, κ.λπ.), αλλά, κατά τη γνώμη μου, οι λύσεις της κατηγορίας APM είναι οι πλέον κατάλληλες για αυτές τις εργασίες (), που μπορεί να απλοποιήσει πολύ τη ζωή σας.
Ως μέρος της δουλειάς μου στην υπηρεσία υποστήριξης, άρχισα να κάνω ένα παρόμοιο έργο χρησιμοποιώντας μια λύση κλάσης APM από τη Dynatrace. Τώρα, δουλεύοντας για έναν ολοκληρωτή, γνωρίζω αρκετά καλά την αγορά συστημάτων παρακολούθησης. Η υποκειμενική μου γνώμη: Το Dynatrace είναι το καταλληλότερο για την επίλυση τέτοιων προβλημάτων.
Το Dynatrace παρέχει μια οριζόντια προβολή κάθε λειτουργίας του χρήστη σε αναλυτικό επίπεδο μέχρι το επίπεδο εκτέλεσης κώδικα. Μπορείτε να παρακολουθείτε ολόκληρη την αλυσίδα αλληλεπίδρασης μεταξύ διαφόρων υπηρεσιών πληροφοριών: από τα επίπεδα front-end εφαρμογών ιστού και φορητών συσκευών, διακομιστές εφαρμογών back-end, δίαυλο ενοποίησης έως μια συγκεκριμένη κλήση στη βάση δεδομένων.
. Αυτόματη κατασκευή όλων των εξαρτήσεων μεταξύ των στοιχείων του συστήματος
. Αυτόματος εντοπισμός και κατασκευή της διαδρομής λειτουργίας της υπηρεσίας
Θυμόμαστε επίσης ότι πρέπει να ενσωματωθούμε με διάφορα εργαλεία αυτοματισμού. Εδώ η λύση διαθέτει ένα βολικό API που σας επιτρέπει να στέλνετε και να λαμβάνετε διάφορες μετρήσεις και συμβάντα.
Στη συνέχεια, ας προχωρήσουμε σε μια πιο λεπτομερή ματιά στον τρόπο επίλυσης αυτών των προβλημάτων χρησιμοποιώντας το σύστημα Dynatrace.
Εργασία 1. Αυτοματοποίηση ποιοτικού ελέγχου συγκροτημάτων στο στάδιο της δοκιμής
Η πρώτη πρόκληση είναι να βρείτε προβλήματα όσο το δυνατόν νωρίτερα στη γραμμή παράδοσης της εφαρμογής. Μόνο οι «καλές» εκδόσεις κώδικα πρέπει να φτάσουν στην παραγωγή. Για να γίνει αυτό, ο αγωγός σας στο στάδιο της δοκιμής θα πρέπει να περιλαμβάνει πρόσθετες οθόνες για τον έλεγχο της ποιότητας των υπηρεσιών σας.
Ας ρίξουμε μια ματιά βήμα προς βήμα στον τρόπο υλοποίησης και αυτοματοποίησης αυτής της διαδικασίας:
Το σχήμα δείχνει τη ροή των αυτοματοποιημένων βημάτων ελέγχου ποιότητας λογισμικού:
- ανάπτυξη συστήματος παρακολούθησης (εγκατάσταση πρακτόρων).
- τον εντοπισμό συμβάντων για την αξιολόγηση της ποιότητας του λογισμικού σας (μετρήσεις και τιμές κατωφλίου) και τη μεταφορά τους στο σύστημα παρακολούθησης·
- παραγωγή δοκιμών φορτίου και απόδοσης·
- συλλογή δεδομένων απόδοσης και διαθεσιμότητας στο σύστημα παρακολούθησης·
- μεταφορά δεδομένων δοκιμής με βάση συμβάντα αξιολόγησης ποιότητας λογισμικού από το σύστημα παρακολούθησης στο σύστημα CI/CD. Αυτόματη ανάλυση συγκροτημάτων.
Βήμα 1. Ανάπτυξη του συστήματος παρακολούθησης
Πρώτα πρέπει να εγκαταστήσετε τους πράκτορες στο περιβάλλον δοκιμής σας. Ταυτόχρονα, η λύση Dynatrace έχει ένα ωραίο χαρακτηριστικό - χρησιμοποιεί τον καθολικό παράγοντα OneAgent, ο οποίος είναι εγκατεστημένος σε μια παρουσία λειτουργικού συστήματος (Windows, Linux, AIX), εντοπίζει αυτόματα τις υπηρεσίες σας και αρχίζει να συλλέγει δεδομένα παρακολούθησης σε αυτές. Δεν χρειάζεται να διαμορφώσετε ξεχωριστό πράκτορα για κάθε διεργασία. Η κατάσταση θα είναι παρόμοια για τις πλατφόρμες cloud και κοντέινερ. Ταυτόχρονα, μπορείτε επίσης να αυτοματοποιήσετε τη διαδικασία εγκατάστασης του πράκτορα. Το Dynatrace ταιριάζει απόλυτα στην έννοια της "υποδομής ως κώδικα" (): Υπάρχουν έτοιμα σενάρια και οδηγίες για όλες τις δημοφιλείς πλατφόρμες. Ενσωματώνετε τον πράκτορα στη διαμόρφωση της υπηρεσίας σας και όταν τον αναπτύξετε, λαμβάνετε αμέσως μια νέα υπηρεσία με έναν ήδη ενεργό πράκτορα.
Βήμα 2: Καθορίστε τα συμβάντα ποιότητας του λογισμικού σας
Τώρα πρέπει να αποφασίσετε για τη λίστα των υπηρεσιών και των επιχειρηματικών λειτουργιών. Είναι σημαντικό να λαμβάνετε υπόψη ακριβώς εκείνες τις λειτουργίες χρήστη που είναι κρίσιμες για την υπηρεσία σας. Εδώ προτείνω να συμβουλευτείτε αναλυτές επιχειρήσεων και συστημάτων.
Στη συνέχεια, πρέπει να καθορίσετε ποιες μετρήσεις θέλετε να συμπεριλάβετε στην αξιολόγηση για κάθε επίπεδο. Για παράδειγμα, αυτός θα μπορούσε να είναι χρόνος εκτέλεσης (διαιρούμενος σε μέσο όρο, διάμεσος, εκατοστιαίες μονάδες, κ.λπ.), σφάλματα (λογικό, υπηρεσία, υποδομή κ.λπ.) και διάφορες μετρήσεις υποδομής (σωρός μνήμης, συλλέκτης απορριμμάτων, αριθμός νημάτων κ.λπ.).
Για αυτοματοποίηση και ευκολία χρήσης από την ομάδα DevOps, εμφανίζεται η έννοια της «Παρακολούθηση ως κώδικας». Αυτό που εννοώ με αυτό είναι ότι ένας προγραμματιστής/ελεγκτής μπορεί να γράψει ένα απλό αρχείο JSON που καθορίζει μετρήσεις διασφάλισης ποιότητας λογισμικού.
Ας δούμε ένα παράδειγμα τέτοιου αρχείου JSON. Τα αντικείμενα από το Dynatrace API χρησιμοποιούνται ως ζεύγη κλειδιών/τιμών (η περιγραφή του API βρίσκεται εδώ ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}Το αρχείο είναι μια σειρά από ορισμούς χρονοσειρών:
- timeseriesId – η μέτρηση που ελέγχεται, για παράδειγμα, Χρόνος απόκρισης, Πλήθος σφαλμάτων, Μνήμη που χρησιμοποιείται κ.λπ.
- συνάθροιση - επίπεδο συγκέντρωσης μετρήσεων, στην περίπτωσή μας μέσος όρος, αλλά μπορείτε να χρησιμοποιήσετε οποιαδήποτε χρειάζεστε (μέσος όρος, ελάχ., μέγιστο, άθροισμα, μέτρηση, εκατοστημόριο).
- ετικέτες – ετικέτα αντικειμένου στο σύστημα παρακολούθησης ή μπορείτε να καθορίσετε ένα συγκεκριμένο αναγνωριστικό αντικειμένου.
- σοβαρό και προειδοποιητικό – αυτοί οι δείκτες ρυθμίζουν τις τιμές κατωφλίου των μετρήσεών μας· εάν η τιμή δοκιμής υπερβαίνει το αυστηρό όριο, τότε η κατασκευή μας επισημαίνεται ως μη επιτυχημένη.
Το παρακάτω σχήμα δείχνει ένα παράδειγμα χρήσης τέτοιων ορίων.
Βήμα 3: Δημιουργία φορτίου
Αφού καθορίσουμε τα επίπεδα ποιότητας της υπηρεσίας μας, πρέπει να δημιουργήσουμε ένα δοκιμαστικό φορτίο. Μπορείτε να χρησιμοποιήσετε οποιοδήποτε από τα εργαλεία δοκιμών με τα οποία αισθάνεστε άνετα, όπως Jmeter, Selenium, Neotys, Gatling κ.λπ.
Το σύστημα παρακολούθησης της Dynatrace σάς επιτρέπει να καταγράφετε διάφορα μεταδεδομένα από τις δοκιμές σας και να αναγνωρίζετε ποιες δοκιμές ανήκουν σε ποιον κύκλο έκδοσης και σε ποια υπηρεσία. Συνιστάται η προσθήκη επιπλέον κεφαλίδων σε αιτήματα δοκιμής HTTP.
Το παρακάτω σχήμα δείχνει ένα παράδειγμα όπου, χρησιμοποιώντας την πρόσθετη κεφαλίδα X-Dynatrace-Test, υποδεικνύουμε ότι αυτή η δοκιμή σχετίζεται με τη δοκιμή της λειτουργίας της προσθήκης ενός αντικειμένου στο καλάθι.
Όταν εκτελείτε κάθε δοκιμή φόρτωσης, στέλνετε πρόσθετες πληροφορίες συμφραζομένων στο Dynatrace χρησιμοποιώντας το API συμβάντος από τον διακομιστή CI/CD. Με αυτόν τον τρόπο, το σύστημα μπορεί να κάνει διαφοροποίηση μεταξύ διαφορετικών δοκιμών.
. Συμβάν στο σύστημα παρακολούθησης σχετικά με την έναρξη της δοκιμής φορτίου
Βήμα 4-5. Συλλέξτε δεδομένα απόδοσης και μεταφέρετε δεδομένα στο σύστημα CI/CD
Μαζί με το παραγόμενο τεστ, μεταδίδεται ένα συμβάν στο σύστημα παρακολούθησης σχετικά με την ανάγκη συλλογής δεδομένων για τον έλεγχο των δεικτών ποιότητας της υπηρεσίας. Καθορίζει επίσης το αρχείο JSON, το οποίο καθορίζει τις βασικές μετρήσεις.
Εκδήλωση σχετικά με την ανάγκη ελέγχου της ποιότητας του λογισμικού που δημιουργείται στον διακομιστή CI/CD για αποστολή στο σύστημα παρακολούθησης
Στο παράδειγμά μας, καλείται το συμβάν ποιοτικού ελέγχου perfSigDynatraceReport (Απόδοση_Υπογραφή) - αυτό είναι έτοιμο για ενσωμάτωση με το Jenkins, το οποίο αναπτύχθηκε από τα παιδιά της T-Systems Multimedia Solutions. Κάθε δοκιμαστικό συμβάν εκκίνησης περιέχει πληροφορίες σχετικά με την υπηρεσία, τον αριθμό έκδοσης και τον χρόνο δοκιμής. Το πρόσθετο συλλέγει τιμές απόδοσης κατά το χρόνο κατασκευής, τις αξιολογεί και συγκρίνει το αποτέλεσμα με προηγούμενες εκδόσεις και μη λειτουργικές απαιτήσεις.
Συμβάν στο σύστημα παρακολούθησης σχετικά με την έναρξη ενός ελέγχου ποιότητας κατασκευής.
Μετά την ολοκλήρωση της δοκιμής, όλες οι μετρήσεις για την αξιολόγηση της ποιότητας του λογισμικού μεταφέρονται πίσω σε ένα σύστημα συνεχούς ενοποίησης, για παράδειγμα, το Jenkins, το οποίο δημιουργεί μια αναφορά για τα αποτελέσματα.
Το αποτέλεσμα των στατιστικών στοιχείων για συγκροτήματα στον διακομιστή CI/CD.
Για κάθε μεμονωμένη κατασκευή, βλέπουμε στατιστικά στοιχεία για κάθε μέτρηση που ορίσαμε σε ολόκληρη τη δοκιμή. Βλέπουμε επίσης αν υπήρξαν παραβιάσεις σε ορισμένες τιμές κατωφλίου (προειδοποίηση και σοβαρά κατώφλια). Με βάση τις συγκεντρωτικές μετρήσεις, ολόκληρη η κατασκευή επισημαίνεται ως σταθερή, ασταθής ή αποτυχημένη. Επίσης, για ευκολία, μπορείτε να προσθέσετε δείκτες στην αναφορά συγκρίνοντας την τρέχουσα έκδοση με την προηγούμενη.
Δείτε αναλυτικά στατιστικά στοιχεία για συγκροτήματα στον διακομιστή CI/CD.
Λεπτομερής σύγκριση δύο συγκροτημάτων
Εάν είναι απαραίτητο, μπορείτε να μεταβείτε στη διεπαφή Dynatrace και εκεί μπορείτε να δείτε τα στατιστικά στοιχεία για κάθε μια από τις κατασκευές σας με περισσότερες λεπτομέρειες και να τα συγκρίνετε μεταξύ τους.
Σύγκριση στατιστικών κατασκευής στο Dynatrace.
Ευρήματα
Ως αποτέλεσμα, λαμβάνουμε μια υπηρεσία "παρακολούθηση ως υπηρεσία", αυτοματοποιημένη στη συνεχή ολοκλήρωση. Ο προγραμματιστής ή ο υπεύθυνος δοκιμών χρειάζεται μόνο να ορίσει μια λίστα μετρήσεων σε ένα αρχείο JSON και όλα τα άλλα γίνονται αυτόματα. Λαμβάνουμε διαφανή ποιοτικό έλεγχο των εκδόσεων: όλες τις ειδοποιήσεις σχετικά με την απόδοση, την κατανάλωση πόρων ή τις αρχιτεκτονικές παλινδρομήσεις.
Εργασία 2. Αυτοματοποίηση ποιοτικού ελέγχου λογισμικού σε περιβάλλον παραγωγής
Έτσι, λύσαμε το πρόβλημα του τρόπου αυτοματοποίησης της διαδικασίας παρακολούθησης στο στάδιο της δοκιμής στο Pipeline. Με αυτόν τον τρόπο ελαχιστοποιούμε το ποσοστό των συναρμολογήσεων χαμηλής ποιότητας που φτάνουν στο περιβάλλον παραγωγής.
Αλλά τι να κάνετε εάν το κακό λογισμικό καταλήξει να πουληθεί ή κάτι απλώς χαλάσει. Για μια ουτοπία, θέλαμε μηχανισμούς για την αυτόματη ανίχνευση προβλημάτων και, ει δυνατόν, το ίδιο το σύστημα να επαναφέρει τη λειτουργικότητά του, τουλάχιστον τη νύχτα.
Για να γίνει αυτό, πρέπει, κατ' αναλογία με την προηγούμενη ενότητα, να προβλέπουμε αυτόματους ελέγχους ποιότητας λογισμικού στο περιβάλλον παραγωγής και να τους βασίσουμε σε σενάρια για αυτοίαση του συστήματος.
Αυτόματη διόρθωση ως κωδικός
Οι περισσότερες εταιρείες έχουν ήδη μια συσσωρευμένη βάση γνώσεων για διάφορους τύπους κοινών προβλημάτων και μια λίστα ενεργειών για την επίλυσή τους, για παράδειγμα, επανεκκίνηση διαδικασιών, εκκαθάριση πόρων, επαναφορά εκδόσεων, επαναφορά μη έγκυρων αλλαγών διαμόρφωσης, αύξηση ή μείωση του αριθμού των στοιχείων στο το σύμπλεγμα, εναλλαγή του μπλε ή πράσινου περιγράμματος κ.λπ.
Ενώ αυτές οι περιπτώσεις χρήσης είναι γνωστές εδώ και χρόνια σε πολλές από τις ομάδες με τις οποίες μιλάω, λίγοι έχουν σκεφτεί ή έχουν επενδύσει στην αυτοματοποίησή τους.
Αν το καλοσκεφτείτε, δεν υπάρχει τίποτα υπερβολικά περίπλοκο στην υλοποίηση διαδικασιών για την απόδοση της εφαρμογής αυτο-ίασης· πρέπει να παρουσιάσετε τα ήδη γνωστά σενάρια εργασίας των διαχειριστών σας με τη μορφή σεναρίων κώδικα (η έννοια "αυτόματη επιδιόρθωση ως κώδικα") , που γράψατε εκ των προτέρων για κάθε συγκεκριμένη περίπτωση. Τα σενάρια αυτόματης επιδιόρθωσης θα πρέπει να στοχεύουν στην εξάλειψη της βασικής αιτίας του προβλήματος. Εσείς οι ίδιοι καθορίζετε τις σωστές ενέργειες για να απαντήσετε σε ένα περιστατικό.
Οποιαδήποτε μέτρηση από το σύστημα παρακολούθησής σας μπορεί να λειτουργήσει ως έναυσμα για την εκκίνηση του σεναρίου, το κύριο πράγμα είναι ότι αυτές οι μετρήσεις καθορίζουν με ακρίβεια ότι όλα είναι άσχημα, καθώς δεν θα θέλατε να λαμβάνετε ψευδώς θετικά αποτελέσματα σε ένα παραγωγικό περιβάλλον.
Μπορείτε να χρησιμοποιήσετε οποιοδήποτε σύστημα ή σύνολο συστημάτων: Prometheus, ELK Stack, Zabbix κ.λπ. Αλλά θα δώσω μερικά παραδείγματα που βασίζονται σε μια λύση APM (το Dynatrace θα είναι και πάλι παράδειγμα) που θα σας βοηθήσουν επίσης να κάνετε τη ζωή σας πιο εύκολη.
Πρώτον, υπάρχουν όλα όσα σχετίζονται με την απόδοση όσον αφορά τη λειτουργία της εφαρμογής. Η λύση παρέχει εκατοντάδες μετρήσεις σε διάφορα επίπεδα που μπορείτε να χρησιμοποιήσετε ως ενεργοποιητές:
- επίπεδο χρήστη (προγράμματα περιήγησης, εφαρμογές για κινητά, συσκευές IoT, συμπεριφορά χρήστη, μετατροπές κ.λπ.)
- επίπεδο υπηρεσιών και λειτουργιών (απόδοση, διαθεσιμότητα, σφάλματα κ.λπ.)·
- επίπεδο υποδομής εφαρμογών (μετρήσεις λειτουργικού συστήματος κεντρικού υπολογιστή, JMX, MQ, διακομιστής ιστού κ.λπ.)
- επίπεδο πλατφόρμας (εικονικοποίηση, σύννεφο, κοντέινερ κ.λπ.).
Επίπεδα παρακολούθησης στο Dynatrace.
Δεύτερον, όπως είπα νωρίτερα, το Dynatrace έχει ένα ανοιχτό API, το οποίο καθιστά πολύ εύκολη την ενσωμάτωση με διάφορα συστήματα τρίτων κατασκευαστών. Για παράδειγμα, αποστολή ειδοποίησης στο σύστημα αυτοματισμού όταν γίνεται υπέρβαση των παραμέτρων ελέγχου.
Παρακάτω είναι ένα παράδειγμα αλληλεπίδρασης με το Ansible.
Παρακάτω θα δώσω μερικά παραδείγματα για το τι είδους αυτοματοποίηση μπορεί να γίνει. Αυτό είναι μόνο ένα μέρος των περιπτώσεων· η λίστα τους στο περιβάλλον σας μπορεί να περιοριστεί μόνο από τη φαντασία σας και τις δυνατότητες των εργαλείων παρακολούθησης.
1. Κακή ανάπτυξη – επαναφορά έκδοσης
Ακόμα κι αν δοκιμάσουμε τα πάντα πολύ καλά σε ένα δοκιμαστικό περιβάλλον, εξακολουθεί να υπάρχει πιθανότητα μια νέα έκδοση να σκοτώσει την εφαρμογή σας σε περιβάλλον παραγωγής. Ο ίδιος ανθρώπινος παράγοντας δεν έχει ακυρωθεί.
Στο παρακάτω σχήμα βλέπουμε ότι υπάρχει ένα απότομο άλμα στο χρόνο εκτέλεσης των λειτουργιών στην υπηρεσία. Η αρχή αυτού του άλματος συμπίπτει με το χρόνο ανάπτυξης στην εφαρμογή. Μεταδίδουμε όλες αυτές τις πληροφορίες ως συμβάντα στο σύστημα αυτοματισμού. Εάν η απόδοση της υπηρεσίας δεν επανέλθει στο κανονικό μετά την ώρα που ορίσαμε, τότε αυτόματα καλείται ένα σενάριο που επαναφέρει την έκδοση στην παλιά.
Υποβάθμιση της απόδοσης των λειτουργιών μετά την ανάπτυξη.
2. Φόρτωση πόρων στο 100% - προσθέστε έναν κόμβο στη δρομολόγηση
Στο ακόλουθο παράδειγμα, το σύστημα παρακολούθησης προσδιορίζει ότι ένα από τα στοιχεία αντιμετωπίζει 100% φορτίο CPU.
Φορτίο CPU 100%
Υπάρχουν πολλά διαφορετικά πιθανά σενάρια για αυτό το συμβάν. Για παράδειγμα, το σύστημα παρακολούθησης ελέγχει επιπλέον εάν η έλλειψη πόρων σχετίζεται με αύξηση του φορτίου στην υπηρεσία. Αν ναι, τότε εκτελείται ένα σενάριο που προσθέτει αυτόματα έναν κόμβο στη δρομολόγηση, αποκαθιστώντας έτσι τη λειτουργικότητα του συστήματος στο σύνολό του.
Κλιμάκωση μετά από περιστατικό
3. Έλλειψη χώρου στον σκληρό δίσκο - καθαρισμός δίσκου
Νομίζω ότι πολλοί άνθρωποι έχουν ήδη αυτοματοποιήσει αυτές τις διαδικασίες. Χρησιμοποιώντας το APM, μπορείτε επίσης να παρακολουθείτε τον ελεύθερο χώρο στο υποσύστημα του δίσκου. Εάν δεν υπάρχει χώρος ή ο δίσκος λειτουργεί αργά, καλούμε ένα σενάριο για να το καθαρίσουμε ή να προσθέσουμε χώρο.
Φορτίο δίσκου 100%
4. Χαμηλή δραστηριότητα χρήστη ή χαμηλή μετατροπή - εναλλαγή μεταξύ μπλε και πράσινου κλάδου
Βλέπω συχνά πελάτες να χρησιμοποιούν δύο βρόχους (μπλε-πράσινη ανάπτυξη) για εφαρμογές σε περιβάλλον παραγωγής. Αυτό σας επιτρέπει να κάνετε γρήγορη εναλλαγή μεταξύ υποκαταστημάτων κατά την παράδοση νέων εκδόσεων. Συχνά, μετά την ανάπτυξη, μπορεί να συμβούν δραματικές αλλαγές που δεν γίνονται αμέσως αντιληπτές. Σε αυτήν την περίπτωση, ενδέχεται να μην παρατηρηθεί υποβάθμιση της απόδοσης και της διαθεσιμότητας. Για να ανταποκριθείτε γρήγορα σε τέτοιες αλλαγές, είναι καλύτερο να χρησιμοποιείτε διάφορες μετρήσεις που αντικατοπτρίζουν τη συμπεριφορά των χρηστών (αριθμός περιόδων σύνδεσης και ενέργειες χρήστη, μετατροπές, ποσοστό εγκατάλειψης). Το παρακάτω σχήμα δείχνει ένα παράδειγμα στο οποίο, όταν πέφτουν τα ποσοστά μετατροπής, πραγματοποιείται εναλλαγή μεταξύ των κλάδων λογισμικού.
Το ποσοστό μετατροπής μειώνεται μετά την εναλλαγή μεταξύ των υποκαταστημάτων λογισμικού.
Μηχανισμοί αυτόματης ανίχνευσης προβλημάτων
Τέλος, θα σας δώσω ένα ακόμη παράδειγμα για το γιατί μου αρέσει περισσότερο το Dynatrace.
Στο μέρος της ιστορίας μου σχετικά με την αυτοματοποίηση ποιοτικών ελέγχων συγκροτημάτων σε περιβάλλον δοκιμής, προσδιορίσαμε όλες τις τιμές κατωφλίου με μη αυτόματο τρόπο. Αυτό είναι φυσιολογικό για ένα περιβάλλον δοκιμής· ο ίδιος ο ελεγκτής καθορίζει τους δείκτες πριν από κάθε δοκιμή ανάλογα με το φορτίο. Σε ένα περιβάλλον παραγωγής, είναι επιθυμητό τα προβλήματα να εντοπίζονται αυτόματα, λαμβάνοντας υπόψη διάφορους βασικούς μηχανισμούς.
Το Dynatrace διαθέτει ενδιαφέροντα ενσωματωμένα εργαλεία τεχνητής νοημοσύνης που, βασισμένα σε μηχανισμούς για τον προσδιορισμό ανώμαλων μετρήσεων (βασική βάση) και τη δημιουργία χάρτη αλληλεπίδρασης μεταξύ όλων των στοιχείων, συγκρίνοντας και συσχετίζοντας συμβάντα μεταξύ τους, προσδιορίζουν ανωμαλίες στη λειτουργία της υπηρεσίας σας και παρέχουν λεπτομερείς πληροφορίες για κάθε πρόβλημα και τη βασική αιτία.
Αναλύοντας αυτόματα τις εξαρτήσεις μεταξύ των στοιχείων, το Dynatrace καθορίζει όχι μόνο εάν η προβληματική υπηρεσία είναι η βασική αιτία, αλλά και η εξάρτησή της από άλλες υπηρεσίες. Στο παρακάτω παράδειγμα, το Dynatrace παρακολουθεί και αξιολογεί αυτόματα την υγεία κάθε υπηρεσίας κατά την εκτέλεση της συναλλαγής, προσδιορίζοντας την υπηρεσία Golang ως τη βασική αιτία.
Ένα παράδειγμα προσδιορισμού της βασικής αιτίας μιας αποτυχίας.
Το παρακάτω σχήμα δείχνει τη διαδικασία παρακολούθησης προβλημάτων με την εφαρμογή σας από την αρχή ενός περιστατικού.
Οπτικοποίηση ενός αναδυόμενου προβλήματος με εμφάνιση όλων των στοιχείων και συμβάντων σε αυτά
Το σύστημα παρακολούθησης συγκέντρωσε ένα πλήρες χρονολόγιο γεγονότων που σχετίζονται με το πρόβλημα που προέκυψε. Στο παράθυρο κάτω από τη γραμμή χρόνου βλέπουμε όλα τα βασικά συμβάντα για κάθε ένα από τα στοιχεία. Με βάση αυτά τα συμβάντα, μπορείτε να ορίσετε διαδικασίες για αυτόματη διόρθωση με τη μορφή σεναρίων κώδικα.
Επιπλέον, σας συμβουλεύω να ενσωματώσετε ένα σύστημα παρακολούθησης με το Service Desk ή έναν εντοπισμό σφαλμάτων. Όταν παρουσιαστεί ένα πρόβλημα, οι προγραμματιστές λαμβάνουν γρήγορα πλήρεις πληροφορίες για να τις αναλύσουν σε επίπεδο κώδικα στο περιβάλλον παραγωγής.
Συμπέρασμα
Ως αποτέλεσμα, καταλήξαμε σε μια διοχέτευση CI/CD με ενσωματωμένους αυτοματοποιημένους ελέγχους ποιότητας λογισμικού στο Pipeline. Ελαχιστοποιούμε τον αριθμό των συγκροτημάτων χαμηλής ποιότητας, αυξάνουμε την αξιοπιστία του συστήματος στο σύνολό του και εάν το σύστημά μας εξακολουθεί να αποτυγχάνει, εκκινούμε μηχανισμούς για την επαναφορά του.
Αξίζει σίγουρα να επενδύσετε προσπάθεια για την αυτοματοποίηση της παρακολούθησης ποιότητας λογισμικού· δεν είναι πάντα μια γρήγορη διαδικασία, αλλά με την πάροδο του χρόνου θα αποφέρει καρπούς. Σας συνιστώ μετά την επίλυση ενός νέου περιστατικού στο περιβάλλον παραγωγής, να σκεφτείτε αμέσως ποιες οθόνες να προσθέσετε για ελέγχους στο δοκιμαστικό περιβάλλον, ώστε να αποφύγετε την είσοδο μιας κακής κατασκευής στην παραγωγή και επίσης να δημιουργήσετε ένα σενάριο για να διορθώσετε αυτόματα αυτά τα προβλήματα.
Ελπίζω τα παραδείγματά μου να σας βοηθήσουν στις προσπάθειές σας. Θα με ενδιαφέρει επίσης να δω τα παραδείγματα μετρήσεων που χρησιμοποιούνται για την εφαρμογή συστημάτων αυτοθεραπείας.
Πηγή: www.habr.com