Εντοπισμός εφαρμογών που κρασάρουν αμέσως μετά τη δημοσίευση

Στις 25 Σεπτεμβρίου, τρεις δημοσιεύσεις σημάνθηκαν ως επιτυχημένες, παρόλο που το API της εφαρμογής κρασάριζε δευτερόλεπτα μετά από κάθε εκκίνηση. Επειδή «πέτυχαν», δεν τρέχε καμία επαναφορά· ένας έλεγχος στο παρασκήνιο τις απέτυχε λίγα λεπτά αργότερα, και ολόκληρος ο ιστότοπος επέστρεψε 404. Ο έλεγχος υγείας μετρούσε τα κρασαρίσματα στη λίστα συμβάντων της πλατφόρμας φιλοξενίας, η οποία κρατά μόνο τα τελευταία πέντε συμβάντα ανά μηχάνημα, οπότε ένας βρόχος κρασαρισμάτων την γεμίζει και το μέτρημα δεν αυξάνεται ποτέ. Τώρα συγκρίνει τον χρόνο του πιο πρόσφατου κρασαρίσματος, και μια δημοσίευση με βρόχο κρασαρισμάτων αποτυγχάνει και επαναφέρει την προηγούμενη έκδοση.

Τι περιμένει μια δημοσίευση

Όταν δημοσιεύετε μια εφαρμογή με backend στο Mythex, η νέα έκδοση ανεβαίνει στα μηχανήματα της πλατφόρμας φιλοξενίας μας, και ένας έλεγχος υγείας αποφασίζει αν η δημοσίευση πήγε live ή απέτυχε. Αν απέτυχε, μια επαναφορά επαναφέρει την προηγούμενη έκδοση.

Το δύσκολο είναι ότι το «ξεκίνησε» δεν είναι το ίδιο με το «σερβίρει». Η πλατφόρμα αναφέρει ένα μηχάνημα ως ξεκινημένο μόλις σηκωθεί. Μια εφαρμογή που κρασάρει ένα δευτερόλεπτο μετά την εκκίνηση επανεκκινείται αμέσως, και λίγο αργότερα φαίνεται ξανά ως ξεκινημένη. Ο έλεγχος υγείας είχε λοιπόν αποκτήσει πολλά επίπεδα με τον καιρό:

1. Κοιτάξτε δύο φορές. Αφού ένα μηχάνημα φανεί ως ξεκινημένο, περιμένετε λίγο και κοιτάξτε ξανά. Ένα κρασάρισμα κατά την εκκίνηση συχνά αποτυγχάνει τη δεύτερη ματιά.
2. Προσέξτε τους βρόχους κρασαρισμάτων. Αν η πλατφόρμα αναφέρει ότι ένα μηχάνημα κρασάριζε επανειλημμένα και σταμάτησε να το επανεκκινεί, αποτυγχάνετε.
3. Μετρήστε τα κρασαρίσματα από την αρχή της δημοσίευσης. Δύο «ξεκίνησε» ματιές μπορεί να βρίσκονται εκατέρωθεν μιας επανεκκίνησης. Οπότε αν έχει γίνει οποιοδήποτε κρασάρισμα από την αρχή της δημοσίευσης, κοιτάτε για τρίτη φορά· αν υπάρχουν περισσότερα κρασαρίσματα απ' ό,τι στην προηγούμενη ματιά, η εφαρμογή δεν μένει σε λειτουργία.

Ο τρίτος έλεγχος είναι αυτός που απέτυχε εδώ.

Γιατί το μέτρημα έμενε σταθερό

Η πληροφορία για τα κρασαρίσματα προέρχεται από τη λίστα συμβάντων κάθε μηχανήματος: εκκινήσεις, εξόδους, επανεκκινήσεις. Η πλατφόρμα κρατά μόνο τα τελευταία πέντε συμβάντα ανά μηχάνημα.

Φανταστείτε μια εφαρμογή που κρασάρει 2,5 δευτερόλεπτα μετά από κάθε εκκίνηση, όπως μία από τις δικές μας. Κάθε κύκλος προσθέτει ένα κρασάρισμα και μία εκκίνηση. Μετά από μερικούς κύκλους, η λίστα είναι γεμάτη. Από εκεί και πέρα, κάθε νέο συμβάν σπρώχνει έξω ένα παλιό. Η λίστα κινείται προς τα εμπρός, αλλά κρατά πάντα περίπου το ίδιο μείγμα: μερικά κρασαρίσματα, μερικές εκκινήσεις.

Έτσι το «πόσα κρασαρίσματα από την αρχή της δημοσίευσης» έδινε τον ίδιο αριθμό σε κάθε ματιά. Η δεύτερη ματιά έβλεπε, ας πούμε, δύο κρασαρίσματα. Η τρίτη ματιά έβλεπε επίσης δύο, διαφορετικά κρασαρίσματα αλλά ίδιο πλήθος. Ο έλεγχος συμπέρανε ότι το κρασάρισμα είχε σταματήσει και πέρασε τη δημοσίευση.

Αυτό συνέβη τρεις φορές στις 25 Σεπτεμβρίου, σε δύο εφαρμογές. Κάθε φορά:

• η δημοσίευση σημάνθηκε ως ζωντανή,
• δεν έτρεξε επαναφορά, επειδή τίποτα δεν είχε αποτύχει,
• ο συμφιλιωτής μας, μια εργασία φόντου που ελέγχει τις αναπτύξεις εκ των υστέρων, απέτυχε την ανάπτυξη λίγα λεπτά αργότερα,
• και ολόκληρος ο ιστότοπος επέστρεψε 404.

Μια δημοσίευση που αποτυγχάνει στην ώρα της είναι διορθώσιμη: η επαναφορά επαναφέρει την προηγούμενη έκδοση. Μια δημοσίευση που αποτυγχάνει λίγα λεπτά αργότερα, αφού έχει ήδη δηλωθεί επιτυχία, έχει ήδη παραλείψει την επαναφορά της.

Πώς το βρήκαμε

Το αναπαράγαμε τοπικά: πήραμε ένα λειτουργικό API, το αφήσαμε να κοιμηθεί, και μετά το επαναδημοσιεύσαμε με μια αλλαγή που κρασάριζε κατά την εκκίνηση. Ο έλεγχος υγείας το σημάνε ως ζωντανό.

Αυτό ταίριαζε με την παραγωγή: και στις τρεις δημοσιεύσεις, η εφαρμογή πέθαινε δευτερόλεπτα μετά από κάθε εκκίνηση, κι όμως το μέτρημα κρασαρισμάτων που συνέκρινε ο έλεγχος δεν αυξανόταν ποτέ μεταξύ των ματιών.

Η διόρθωση: συγκρίνετε το πιο πρόσφατο κρασάρισμα, όχι το πλήθος

Αντί να μετράει κρασαρίσματα, ο έλεγχος κοιτάζει τώρα τον χρόνο του πιο πρόσφατου κρασαρίσματος από την αρχή της δημοσίευσης.

Αν η δεύτερη ματιά δείξει οποιοδήποτε κρασάρισμα από την έναρξη της δημοσίευσης, ο έλεγχος περιμένει και κοιτάζει για τρίτη φορά. Αν το πιο πρόσφατο κρασάρισμα στην τρίτη ματιά είναι μεταγενέστερο από το πιο πρόσφατο στη δεύτερη, το μηχάνημα κρασάρισε ξανά στο ενδιάμεσο. Δεν μένει σε λειτουργία, και η δημοσίευση αποτυγχάνει με μήνυμα που λέει ότι το μηχάνημα κρασάριζε επανειλημμένα από τη δημοσίευση και εξακολουθεί να επανεκκινείται.

Αυτό λειτουργεί ανεξάρτητα από το πόσο μικρή είναι η λίστα συμβάντων. Ένα ολισθαίνον παράθυρο πέντε συμβάντων μπορεί να κρύψει πόσα κρασαρίσματα έγιναν, αλλά δεν μπορεί να κρύψει ότι ένα νέο μόλις συνέβη, γιατί το πιο πρόσφατο συμβάν είναι πάντα αυτό που κρατιέται.

Με αυτή την αλλαγή, η τοπική αναπαραγωγή συμπεριφέρεται σωστά: η δημοσίευση αποτυγχάνει, και επαναφέρεται η προηγούμενη image. Υπάρχει επίσης τεστ που προσομοιώνει τη συμπεριφορά της πλατφόρμας —κάθε έλεγχος προσθέτει ένα κρασάρισμα και μία εκκίνηση και περικόπτει τη λίστα σε πέντε— και ελέγχει ότι η ετυμηγορία είναι αποτυχία και όχι επιτυχία.

Τι κρατήσαμε από όλο αυτό

• Γνωρίστε το σχήμα των δεδομένων που μετράτε. Ένα μέτρημα πάνω σε λίστα με όριο παύει να έχει νόημα μόλις γεμίσει η λίστα. Το όριο δεν ήταν κρυμμένο· απλώς δεν είχαμε σχεδιάσει τον έλεγχο γύρω του.
• Προτιμήστε το «συνέβη κάτι καινούργιο;» από το «πόσα συνέβησαν;». Το πιο πρόσφατο timestamp επιβιώνει από την περικοπή. Ένα σύνολο όχι.
• Μια αργή αποτυχία είναι χειρότερη από μια έγκαιρη. Το ίδιο χαλασμένο build είναι αβλαβές αν η δημοσίευση αποτύχει και επαναφερθεί, αλλά κατεβάζει έναν ιστότοπο αν πρώτα δηλωθεί επιτυχία.
• Αναπαραγάγετε με τις πραγματικές συνθήκες. Το σφάλμα χρειαζόταν μηχάνημα που είχε ήδη κρασάρει αρκετά ώστε να γεμίσει η λίστα συμβάντων του. Ένα μόνο γρήγορο κρασάρισμα σε τεστ δεν θα το είχε δείξει.

Αυτή η διόρθωση συμπληρώνεται από μια άλλη της ίδιας ημέρας, που διασφάλισε ότι η επαναφορά επαναφέρει την παλιά έκδοση αντί να τη διαγράφει: μια αποτυχημένη επαναδημοσίευση δεν διαγράφει ποτέ ένα λειτουργικό backend. Αν η δική σας εφαρμογή αποτυγχάνει στη δημοσίευση επειδή κρασάρει κατά την εκκίνηση, η αντιμετώπιση προβλημάτων δημοσίευσης και ο οδηγός μας για αποσφαλμάτωση εφαρμογής που έφτιαξε AI είναι καλά σημεία εκκίνησης.