Η παραγωγή καίγεται στην ανάπτυξη — τι είναι, αιτίες και αλγόριθμος ενεργειών

Τι σημαίνει “η παραγωγή καίγεται” και τι είδη βλαβών υπάρχουν

Η φράση “η παραγωγή καίγεται” (production is on fire, everything is down) περιγράφει μια κατάσταση όπου το περιβάλλον παραγωγής λειτουργεί εσφαλμένα και αυτό επηρεάζει τους χρήστες. Η βλάβη μπορεί να εκδηλωθεί ως πλήρης μη διαθεσιμότητα της εφαρμογής (blank screen, σφάλμα 502), μερική μη διαθεσιμότητα (η μονάδα πληρωμών δεν λειτουργεί αλλά άλλες λειτουργίες είναι διαθέσιμες) ή υποβάθμιση απόδοσης (εξαιρετικά αργή φόρτωση). Το severity του περιστατικού καθορίζεται από το ποσοστό των επηρεαζόμενων χρηστών και τη διάρκεια της βλάβης.

Σύμφωνα με το Atlassian Statuspage (2025), ο μέσος χρόνος διακοπής λειτουργίας για εφαρμογές κινητού το 2024 ήταν 27 λεπτά ανά περιστατικό. Οι συχνότερες αιτίες: παλινδρόμηση κώδικα μετά από deploy (34%), αστοχία παρόχου cloud (22%), προβλήματα βάσης δεδομένων (18%), σφάλματα διαμόρφωσης (15%) και επιθέσεις DDoS (11%). Βασικό συμπέρασμα: οι περισσότερες βλάβες σχετίζονται με αλλαγές που έκανε η ίδια η ομάδα, όχι με εξωτερικούς παράγοντες.

Είναι σημαντικό να γίνεται διάκριση μεταξύ crash (κατάρρευση εφαρμογής στην πλευρά του πελάτη) και backend outage (μη διαθεσιμότητα διακομιστή). Το crash συνήθως διορθώνεται με hotfix του κώδικα πελάτη, ενώ το backend outage μέσω αλλαγών υποδομής ή redeploy της υπηρεσίας. Μετρήσεις παρακολούθησης: για τον πελάτη — crash-free rate, για τον διακομιστή — error rate 5xx και p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — βοηθά στον γρήγορο προσδιορισμό του τύπου βλάβης.

Επίπεδα severity περιστατικών: P0, P1, P2 και κριτήρια ταξινόμησης

Η ενιαία ταξινόμηση severity είναι η βάση της γρήγορης αντίδρασης. Χωρίς αυτήν, η ομάδα χάνει χρόνο συζητώντας “πόσο επείγον είναι” αντί να ενεργεί. Η κλασική κλίμακα: P0 (critical) — η εφαρμογή είναι εντελώς μη διαθέσιμη ή διαρρέουν δεδομένα χρηστών, χρόνος αντίδρασης — άμεσα; P1 (high) — κρίσιμη λειτουργία δεν λειτουργεί για 50%+ χρηστών, χρόνος αντίδρασης — 15 λεπτά; P2 (medium) — μη κρίσιμη λειτουργία μη διαθέσιμη σε μέρος των χρηστών, χρόνος αντίδρασης — 1 ώρα.

Το P0 απαιτεί άμεση κλιμάκωση: ο εφημερεύων μηχανικός διακόπτει κάθε τρέχουσα εργασία και ασχολείται με το περιστατικό. Εάν μετά από 10 λεπτά το πρόβλημα δεν έχει λυθεί — συμμετέχει ο tech lead. Εάν μετά από 30 λεπτά — κλιμάκωση στον engineering manager. Για περιστατικά P0 επιτρέπεται η παραβίαση οποιωνδήποτε διαδικασιών: hotfix χωρίς πλήρη code review, απευθείας deploy στην παραγωγή, παράβλεψη κανόνων branch protection. Το emergency override πρέπει να έχει συμφωνηθεί εκ των προτέρων σε επίπεδο ομάδας.

Πίνακας severity

Είναι εξαιρετικά σημαντικό να μην κάνετε λάθος προς τα κάτω στο severity. Τα P0 + P1 που ταξινομούνται ως P2 οδηγούν σε καθυστερημένη αντίδραση και αύξηση του χρόνου διακοπής λειτουργίας. Κανόνας: εάν έχετε αμφιβολίες — ορίστε P0. Η υπερταξινόμηση (over-classification) είναι καλύτερη από την υποταξινόμηση (under-classification): καλύτερα να συγκαλέσετε μια επιπλέον συνάντηση παρά να χάσετε μία ώρα χρόνου αποκατάστασης.

Τα πρώτα 10 λεπτά: αλγόριθμος ενεργειών σε περίπτωση βλάβης

Timer starts: από τη στιγμή που φτάνει η ειδοποίηση ή το μήνυμα από τον χρήστη. Τα πρώτα 10 λεπτά — τα πιο σημαντικά. Αλγόριθμος: 1) confirm the issue — βεβαιωθείτε ότι το πρόβλημα είναι πραγματικό (όχι ψευδής συναγερμός); 2) stop the bleeding — μειώστε άμεσα τον αντίκτυπο (rollback, feature toggle, αποκλεισμός endpoint); 3) communicate — γράψτε στο γενικό κανάλι #incident την κατάσταση: τι συνέβη, severity, τι γίνεται. Τα πρώτα 10 λεπτά δεν δαπανώνται για ανάλυση της βασικής αιτίας.

Παράλληλα με τη διακοπή της αιμορραγίας, ένας μηχανικός ξεκινά τη διάγνωση, ο δεύτερος — την επικοινωνία. Κανάλια επικοινωνίας: Slack #incident channel (για την ομάδα), σελίδα κατάστασης (για τους χρήστες), email/SMS κλιμάκωσης (για τη διοίκηση). Κάθε 15 λεπτά — ενημέρωση κατάστασης με πληροφορίες: τι είναι γνωστό, τι γίνεται, εκτιμώμενος χρόνος αποκατάστασης. Η σελίδα κατάστασης (Status page) (StatuPage, Statuspal) εμφανίζει τον χρόνο λειτουργίας και το ιστορικό περιστατικών για εξωτερικούς χρήστες.

Πώς να σταματήσετε την αιμορραγία: rollback, feature toggle και hotfix

Ο πρώτος και σημαντικότερος κανόνας: μην προσπαθείτε να διορθώσετε το πρόβλημα στην παραγωγή. Εάν η νέα έκδοση προκάλεσε τη βλάβη — rollback στην προηγούμενη σταθερή έκδοση. Εάν η βλάβη προκλήθηκε από μια συγκεκριμένη λειτουργία που είναι απενεργοποιημένη μέσω feature toggle — απλώς απενεργοποιήστε το toggle. Εάν ούτε rollback ούτε toggle είναι διαθέσιμα — hotfix με ελάχιστο diff. Το rollback είναι η ασφαλέστερη επιλογή, επειδή επιστρέφουμε σε μια κατάσταση που ήδη λειτουργούσε.

Το feature toggle (γνωστό και ως feature flag) — ένα ισχυρό εργαλείο για stop-the-bleeding χωρίς deploy. Εάν η μονάδα πληρωμών κατέρρευσε αλλά είναι απενεργοποιημένη μέσω toggle — οι χρήστες απλώς δεν βλέπουν το κουμπί πληρωμής, δεν λαμβάνουν οθόνη σφάλματος. Το toggle δεν απαιτεί δημιουργία build, δεν απαιτεί έλεγχο καταστήματος, λειτουργεί σε δευτερόλεπτα. Κάθε κρίσιμη λειτουργία πρέπει να είναι υπό feature toggle με δυνατότητα απενεργοποίησης σε επίπεδο διακομιστή (remote config). Το feature flag είναι η πρώτη γραμμή άμυνας.

Εάν το rollback είναι αδύνατο (π.χ. λόγω μη αναστρέψιμης μετεγκατάστασης ΒΔ) και το toggle δεν προβλέπεται — τελευταίο μέσο: hotfix με ελάχιστη διόρθωση. Το hotfix δημιουργείται από την τελευταία ετικέτα έκδοσης, περιέχει μόνο τις γραμμές που είναι απαραίτητες για την εξάλειψη της βλάβης και υποβάλλεται σε fast-track deploy (βλ. άρθρο “Hotfix — επείγουσες διορθώσεις”). Ο χρυσός κανόνας: μετά τη σταθεροποίηση, κάνετε πάντα root cause analysis, ακόμα κι αν η αιτία φαίνεται προφανής.

Διάγνωση αιτιών: αρχεία καταγραφής, μετρήσεις και ειδοποιήσεις

Μετά τη διακοπή της αιμορραγίας (ή παράλληλα, εάν το επιτρέπει ο αριθμός των μηχανικών) ξεκινά η διάγνωση. Η πρώτη πηγή — τα αρχεία καταγραφής. Η κεντρική καταγραφή (ELK, Grafana Loki, Datadog Logs) επιτρέπει την εύρεση σφαλμάτων βάσει χρονικής σήμανσης, αναγνωριστικού χρήστη ή αναγνωριστικού αιτήματος. Σημαντικό: τα αρχεία καταγραφής πρέπει να είναι δομημένα (JSON) ώστε το grep να λειτουργεί γρήγορα. Η δομημένη καταγραφή (structured logging) είναι υποχρεωτική απαίτηση για όλες τις υπηρεσίες.

Η δεύτερη πηγή — οι μετρήσεις. Τα Grafana, Datadog, New Relic δείχνουν πότε συνέβη η αύξηση σφαλμάτων, σε ποια endpoints, με ποιους κωδικούς κατάστασης. Η σύγκριση μετρήσεων πριν και μετά το deploy βοηθά στον εντοπισμό του προβλήματος σε μια συγκεκριμένη υπηρεσία ή endpoint. Οι μετρήσεις RED (Rate, Errors, Duration) αποτελούν το πρότυπο παρακολούθησης μικροϋπηρεσιών.

Η τρίτη πηγή — η κατανεμημένη ιχνηλάτηση (distributed tracing). Τα Jaeger, Zipkin, Datadog APM δείχνουν τη διαδρομή του αιτήματος μέσω μικροϋπηρεσιών και εντοπίζουν πού ακριβώς συνέβη η καθυστέρηση ή το σφάλμα. Η ιχνηλάτηση είναι ιδιαίτερα χρήσιμη σε βλάβες αλληλουχίας, όταν ένα σφάλμα σε μία υπηρεσία προκαλεί σφάλματα σε όλες τις εξαρτώμενες υπηρεσίες. Το Trace ID πρέπει να μεταδίδεται από τον πελάτη σε όλες τις υπηρεσίες backend.

# Γρήγορο παράδειγμα διάγνωσης με χρήση kubectl και αρχείων καταγραφής
# Λίστα pod με σφάλματα
kubectl get pods --field-selector=status.phase!=Running

# Έλεγχος αρχείων καταγραφής pod που κατέρρευσε
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Αναζήτηση σφαλμάτων στην υπηρεσία για τα τελευταία 30 λεπτά
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Σημαντικό: μην προσπαθείτε να διαγνώσετε την αιτία πριν σταματήσετε την αιμορραγία. Εάν το 50% των χρηστών βλέπει crash — πρώτα rollback, μετά ανάλυση. Εξαίρεση: εάν το rollback θα διαρκούσε περισσότερο από ένα άμεσο hotfix (π.χ. σε περίπτωση ασυμβατότητας δεδομένων). Σε αυτήν την περίπτωση, το hotfix εφαρμόζεται αμέσως και το post-mortem διεξάγεται μετά τη σταθεροποίηση. Το diagnosis before fix είναι ένα επικίνδυνο μοτίβο που αυξάνει τον χρόνο διακοπής λειτουργίας.

Post-mortem: πώς να αναλύετε περιστατικά χωρίς αναζήτηση ενόχων

Το post-mortem (επίσης γνωστό ως incident review) — μια δομημένη ανάλυση του περιστατικού που διεξάγεται 24-72 ώρες μετά την επίλυσή του. Στόχος: να κατανοήσουμε γιατί συνέβη η βλάβη, γιατί η παρακολούθηση και οι δοκιμές δεν την εντόπισαν πριν από την παραγωγή και τι να αλλάξουμε στις διαδικασίες για να αποτρέψουμε την επανάληψη. Η κουλτούρα χωρίς ενοχοποίηση (blameless culture) είναι η θεμελιώδης αρχή: το post-mortem συζητά διαδικασίες, εργαλεία και επικοινωνία, όχι λάθη συγκεκριμένων ατόμων.

Δομή του εγγράφου post-mortem: timeline (χρονολογία γεγονότων με χρονικές σημάνσεις), impact (επηρεαζόμενοι χρήστες, διάρκεια, οικονομικές απώλειες), root cause (τεχνική βασική αιτία), detection (πώς ανακαλύφθηκε, γιατί δεν εντοπίστηκε νωρίτερα), response (τι έγινε, τι θα μπορούσε να γίνει γρηγορότερα), action items (συγκεκριμένες εργασίες με υπεύθυνους και προθεσμίες). Τα action items πρέπει να είναι S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Τυπικά action items μετά από βλάβη παραγωγής: προσθήκη παρακολούθησης και ειδοποίησης για τη μέτρηση που ήταν σιωπηλή; επέκταση κάλυψης δοκιμών για την περίπτωση που παραλείφθηκε; προσθήκη σελίδας στο runbook με αλγόριθμο βήμα προς βήμα για παρόμοια κατάσταση; διεξαγωγή εκπαίδευσης της ομάδας για το εργαλείο που χρησιμοποιήθηκε λανθασμένα. Κάθε action item είναι μια συγκεκριμένη αλλαγή που μειώνει την πιθανότητα επανάληψης του περιστατικού.