With over 20 years of experience, we transform your digital presence. We specialize in website and E-Shop development, SEO and Digital Marketing, ERP software and smart automation that take your business to the next level.
Address:
154 Egnatia Street, Thessaloniki 546 36
Phone:
+30 231 231 4095
E-mail:
hello@twodots.gr
Ready for the next step?;
Η OpenAI ξεχώρισε δύο bugs αναλύοντας core dumps ως πληθυσμό. Τι σημαίνει core dump epidemiology για AI, e-commerce, automations και αξιοπιστία.
Core dump epidemiology είναι η πληθυσμιακή ανάλυση πολλών crashes ώστε να ξεχωρίζουν διαφορετικά failure modes που μοιάζουν με ένα. Στην έρευνα της OpenAI, ένα καθαρό dataset από production core dumps ενός έτους αποκάλυψε δύο ανεξάρτητες αιτίες: έναν προβληματικό Azure host και ένα race condition 18 ετών στη GNU libunwind. Για μια επιχείρηση, το πρακτικό μάθημα είναι σαφές: πριν διορθώσει ένα e-commerce, AI ή automation σύμπτωμα, πρέπει να μπορεί να ταξινομήσει αξιόπιστα όλα τα περιστατικά.
Σε μεγάλα AI προϊόντα, το πιο ακριβό bug δεν είναι πάντα αυτό που φαίνεται στα logs. Μερικές φορές είναι αυτό που μοιάζει αδύνατο, επειδή στην πραγματικότητα είναι δύο διαφορετικά προβλήματα που μπερδεύονται σε μία ιστορία.
Η τεχνική ανάλυση της OpenAI για το «core dump epidemiology» είναι μια χρήσιμη υπενθύμιση για κάθε ομάδα που χτίζει ψηφιακά προϊόντα, e-commerce υποδομές, automation flows ή AI εργαλεία: η αξιοπιστία δεν βελτιώνεται μόνο με καλύτερο κώδικα. Βελτιώνεται όταν η επιχείρηση μπορεί να βλέπει καθαρά το σύνολο των αποτυχιών της, να ξεχωρίζει μοτίβα και να μη βγάζει συμπεράσματα από μεμονωμένα περιστατικά.
Στην περίπτωση της OpenAI, οι μηχανικοί εξέτασαν crashes μέσα σε υπηρεσίες του Rockset, το οποίο αποτελεί μέρος της data infrastructure που βοηθά το ChatGPT να αναζητά σχετικές πληροφορίες κατά την εκτέλεση αιτημάτων. Το σύμπτωμα ήταν παράξενο: C++ συναρτήσεις φαινόταν να επιστρέφουν σε άκυρες διευθύνσεις μνήμης ή να έχουν στο stack μη αναμενόμενη μετατόπιση. Η αρχική υπόθεση ήταν ότι υπήρχε ένα ενιαίο, σπάνιο software bug. Η πραγματικότητα ήταν πιο ενδιαφέρουσα: υπήρχαν δύο ανεξάρτητα bugs, ένα θέμα hardware σε συγκεκριμένο host και ένα παλιό race condition στη GNU libunwind.
Με την πρώτη ματιά, ένα άρθρο για core dumps, C++, Linux signals και exception unwinding μοιάζει να αφορά μόνο infrastructure engineers. Όμως το επιχειρησιακό μάθημα είναι πολύ ευρύτερο. Κάθε digital business σήμερα στηρίζεται σε αλυσίδες εργαλείων: CMS, e-commerce πλατφόρμες, analytics, CRM, ad platforms, AI agents, automations, data warehouses και third-party APIs. Όταν κάτι πάει στραβά, το πιο συνηθισμένο λάθος είναι να ψάχνουμε μία αιτία πίσω από κάθε παρόμοιο σύμπτωμα.
Ένα checkout που “μερικές φορές” αποτυγχάνει, ένα feed προϊόντων που χάνει εγγραφές, ένα AI workflow που δίνει ασταθή αποτελέσματα ή μια διαφημιστική καμπάνια που εμφανίζει παράξενες διακυμάνσεις μπορεί να μη σημαίνει ένα πρόβλημα. Μπορεί να σημαίνει πολλαπλές κατηγορίες αποτυχίας που μοιάζουν ίδιες στην επιφάνεια. Αν η ομάδα κοιτάζει μόνο μεμονωμένα περιστατικά, κινδυνεύει να διορθώσει το λάθος πράγμα.
Η OpenAI εξηγεί ότι τα μοντέλα και οι agents της χρειάζονται scalable data infrastructure για να αναζητούν δεδομένα την ώρα που απαντούν. Το Rockset, το οποίο αποκτήθηκε από την OpenAI το 2024, χρησιμοποιείται για search και real-time analytics σε εσωτερικές περιπτώσεις, όπως connectors και αναζήτηση πάνω σε συνομιλίες ή knowledge bases. Για να έχει υψηλή απόδοση και αποδοτική χρήση μνήμης, κομμάτια του execution layer είναι γραμμένα σε C++.
Η επιλογή της C++ έχει λογική σε υποδομές υψηλής απόδοσης. Δίνει χαμηλού επιπέδου έλεγχο στο σύστημα, αλλά δεν προσφέρει εγγενή memory safety. Έτσι, ένα σφάλμα μπορεί να οδηγήσει σε invalid memory access και segfault. Η OpenAI χρησιμοποιεί fatal signal handler για stack traces και ανεβάζει core dumps σε Azure blob storage, ώστε να μπορεί να αναλύει την κατάσταση του προγράμματος τη στιγμή του crash.
Το κρίσιμο σημείο για business readers είναι αυτό: όταν μια υπηρεσία είναι αρκετά μεγάλη, τα σπάνια bugs παύουν να είναι θεωρητικά. Ένα race condition με πιθανότητα που μοιάζει αμελητέα σε ένα μικρό σύστημα μπορεί να γίνει καθημερινό operational issue σε fleet κλίμακα, ειδικά όταν το σύστημα παράγει μεγάλο αριθμό events, exceptions ή background tasks.
Η ομάδα ξεκίνησε όπως ξεκινούν πολλές σοβαρές τεχνικές έρευνες: πήρε μερικά core dumps και τα εξέτασε σε βάθος. Σε αρκετά crashes, μια μέθοδος με όνομα DocumentTree::updateDocument φαινόταν να έχει καλέσει κάποια άγνωστη συνάρτηση, το stack να αλλοιώθηκε και στη συνέχεια η εκτέλεση να επέστρεψε σε διεύθυνση που δεν ήταν εκτελέσιμος κώδικας. Σε άλλα, το return address ήταν NULL ή ο stack pointer έμοιαζε να έχει μετατοπιστεί κατά 8 bytes.
Αυτό το είδος συμπτώματος είναι δύσκολο, επειδή τα ίδια τα logs μπορεί να είναι αναξιόπιστα. Αν το stack είναι αλλοιωμένο, το stack trace που καταγράφεται μπορεί να λείπει ή να παραπλανεί. Η OpenAI προσπάθησε να βρει όλα τα περιστατικά με log queries, αλλά αυτά είχαν false positives και false negatives. Με άλλα λόγια, το dataset δεν ήταν αρκετά καθαρό για να στηρίξει ασφαλή συμπεράσματα.
Εδώ βρίσκεται ένα μάθημα που ισχύει και εκτός engineering. Αν ένα marketing dashboard, ένα CRM report ή ένα e-commerce analytics setup περιέχει θόρυβο, η ομάδα μπορεί να παράγει πολύ πειστικές αλλά λανθασμένες εξηγήσεις. Το πρόβλημα δεν είναι πάντα η ανάλυση. Συχνά είναι η ποιότητα της εισόδου.
Η OpenAI περιγράφει τη στροφή ως πέρασμα από τον τρόπο σκέψης του γιατρού στον τρόπο σκέψης του επιδημιολόγου. Ο “γιατρός” κοιτάζει έναν ασθενή, κάνει λεπτομερείς εξετάσεις και προσπαθεί να εξηγήσει ένα συγκεκριμένο περιστατικό. Ο “επιδημιολόγος” κοιτάζει ολόκληρο τον πληθυσμό και αναζητά μοτίβα: πότε ξεκίνησε το πρόβλημα, σε ποιες περιοχές εμφανίζεται, ποια hardware SKUs επηρεάζονται, αν συνδέεται με συγκεκριμένη έκδοση λογισμικού ή αν υπάρχουν κρυφές ομάδες περιστατικών.
Αυτή η αλλαγή είναι εξαιρετικά χρήσιμη και για επιχειρησιακή λήψη αποφάσεων. Αν βλέπεις αυξημένα abandoned carts, δεν αρκεί να κοιτάξεις ένα session recording. Χρειάζεται να δεις πληθυσμιακά δεδομένα: browser, χώρα, payment method, shipping option, campaign source, device, ώρα, version του site, consent state και τρίτα scripts. Αν ένα AI chatbot αποτυγχάνει σε συγκεκριμένες ερωτήσεις, δεν αρκεί να διαβάσεις τρεις συνομιλίες. Χρειάζεται taxonomy αποτυχιών, clustering και επαναλαμβανόμενη μέτρηση.
Δύο τρόποι να ερευνήσεις το ίδιο σύμπτωμα
Ανακατασκευάζει ένα crash, ένα checkout failure ή μία αποτυχημένη εκτέλεση. Δίνει πλούσιο τεχνικό context, αλλά μπορεί να εγκλωβίσει την ομάδα σε υπόθεση που δεν εξηγεί τον υπόλοιπο πληθυσμό.
Ομαδοποιεί failures ανά χρόνο, έκδοση, host, region, provider ή error signature. Δείχνει αν ένα φαινομενικά ενιαίο πρόβλημα κρύβει δύο διαφορετικές αιτίες και πού πρέπει να γίνει η επόμενη βαθιά έρευνα.
Αντί να συνεχίσει με χειροκίνητη εξέταση, η ομάδα δημιούργησε pipeline για αυτόματη ανάλυση των core dumps. Σύμφωνα με την ανάρτηση, χρησιμοποίησαν το ChatGPT για να γράψει script που κατέβαζε prefix από κάθε core file, εξήγαγε registers, φιλτράριζε γνωστά false positives από logs και χαρακτήριζε το crash ως return-to-null, misaligned-stack ή άλλη κατηγορία. Το script έτρεξε παράλληλα σε όλα τα production Rockset core dumps του προηγούμενου έτους.
Με αυτό το καθαρό dataset, η εικόνα άλλαξε αμέσως. Τα “ίδια” crashes χωρίστηκαν σε δύο πληθυσμούς. Τα return-to-null περιστατικά ήταν διασκορπισμένα σε πολλά clusters και γεωγραφικές περιοχές. Τα misaligned-stack crashes είχαν καθαρή ημερομηνία έναρξης, εμφανίζονταν σε μία περιοχή και έδειχναν να σχετίζονται με έναν φυσικό host που προκαλούσε corruption σε όποια VM τύχαινε να τρέχει πάνω του.
Αυτή είναι η στιγμή που αξίζει να κρατήσει κάθε business owner: όταν το dataset έγινε σωστό, το πρόβλημα έγινε πιο απλό. Όχι επειδή το τεχνικό αντικείμενο ήταν εύκολο, αλλά επειδή η ομάδα σταμάτησε να αναμιγνύει δύο διαφορετικές αιτίες σε μία εξήγηση.
Το πρώτο bug ήταν hardware. Η ομάδα εντόπισε ότι τα misaligned-stack crashes μπορούσαν να συνδεθούν με έναν συγκεκριμένο φυσικό host σε Azure. Δεν κατάφερε να αναπαράγει ελεγχόμενα το register corruption, ακόμη και μετά από εβδομάδες stress testing. Όταν όμως ο προβληματικός host αφαιρέθηκε από την κυκλοφορία, τα συγκεκριμένα crashes εξαφανίστηκαν.
Αυτό δεν είναι “μόνιμη λύση” με την έννοια ότι δεν αποτρέπει για πάντα παρόμοιο hardware failure. Η σωστή κίνηση ήταν να βελτιωθεί η ανίχνευση. Η OpenAI αναφέρει ότι βελτίωσε τον fatal signal handler ώστε να περιλαμβάνει register state, έκανε αλλαγές στο control plane ώστε τα VMs να επαναχρησιμοποιούνται συχνότερα και ενημέρωσε runbooks και mental models της ομάδας.
Για μια εταιρεία που δεν γράφει C++, το αντίστοιχο είναι να μη σταματά στην προσωρινή διόρθωση. Αν ένα payment provider έχει intermittent failure, δεν αρκεί να αλλάξεις provider ή να ξανατρέξεις την παραγγελία. Χρειάζεται καλύτερη σήμανση, alerting, fallback στρατηγική, runbook και τρόπο να αναγνωρίζεις την επανάληψη χωρίς manual detective work κάθε φορά.
Αφού απομονώθηκε το hardware πρόβλημα, τα υπόλοιπα crashes έγιναν πιο καθαρά. Η ομάδα διαπίστωσε ότι τα return-to-null περιστατικά συνέβαιναν κατά τη διάρκεια C++ exception unwinding. Όταν μια C++ εφαρμογή πετά exception, το runtime πρέπει να βρει ποιο catch block θα το χειριστεί και ποιοι destructors ή cleanup handlers πρέπει να τρέξουν. Αυτή η διαδικασία δεν είναι ένα απλό function return. Είναι δυναμική μεταφορά ελέγχου που αποκαθιστά registers και stack frames.
Στο binary υπήρχαν δύο βιβλιοθήκες που μπορούσαν να εκτελέσουν exception unwinding: libgcc και GNU libunwind. Η ομάδα περίμενε ότι θα χρησιμοποιούνταν η libgcc, αλλά είδε ότι ο dynamic linker επέλεγε GNU libunwind. Διαβάζοντας τον κώδικα της libunwind, οι μηχανικοί εντόπισαν ότι δημιουργούσε ένα ucontext_t πάνω στο stack και μετά καλούσε assembly routine για να αποκαταστήσει registers.
Το race condition εμφανιζόταν σε ένα εξαιρετικά στενό σημείο: η routine άλλαζε το %rsp, με αποτέλεσμα το προσωρινό struct να μην προστατεύεται πλέον ως ενεργό stack memory. Αν ακριβώς τότε έφτανε signal, ο kernel μπορούσε να γράψει signal frame σε περιοχή που αλλοίωνε αυτό το struct. Αν η αλλοίωση συνέβαινε πριν διαβαστεί το instruction pointer, η εκτέλεση μπορούσε να πάει σε NULL.
Η εντυπωσιακή λεπτομέρεια είναι ότι το παράθυρο του race ήταν ουσιαστικά ενός instruction. Θεωρητικά μοιάζει αμελητέο. Όμως η OpenAI εξηγεί γιατί μπορούσε να εμφανίζεται αρκετά συχνά: υψηλός ρυθμός exceptions λόγω ingest backpressure, συχνά SIGUSR2 signals για CPU time accounting και αλλαγή που αύξησε τη χρήση stack από τον signal handler. Όταν αυτά πολλαπλασιάστηκαν σε fleet κλίμακα, το σπάνιο έγινε πραγματικό.
Τέσσερις αριθμοί που εξηγούν την έρευνα
Τα στοιχεία προέρχονται από την τεχνική ανάρτηση της OpenAI και περιγράφουν τη συγκεκριμένη διερεύνηση· δεν αποτελούν benchmark για κάθε υποδομή.
Τα AI workflows που υιοθετούν σήμερα οι επιχειρήσεις έχουν παρόμοια χαρακτηριστικά πολυπλοκότητας, έστω σε διαφορετικό επίπεδο. Ένα agentic workflow μπορεί να καλεί search, CRM, CMS, email, database, vector store, payment data και analytics. Όταν το αποτέλεσμα είναι λάθος, η αιτία μπορεί να βρίσκεται στο prompt, στο retrieval, στο permission model, στο source freshness, στο API rate limit, σε encoding issue, σε cache, σε ανθρώπινη αλλαγή περιεχομένου ή σε downstream connector.
Αν όλα αυτά καταγράφονται ως “AI failed”, η ομάδα δεν μπορεί να μάθει. Χρειάζεται ταξινόμηση συμβάντων. Για παράδειγμα: αποτυχία ανάκτησης δεδομένων, μη διαθέσιμο connector, ασαφής εντολή, λανθασμένη πηγή, hallucination, policy block, timeout, conflict σε state, ή αλλαγή σε third-party API. Αυτό είναι το επιχειρησιακό αντίστοιχο του να ξεχωρίσεις return-to-null από misaligned-stack.
Το ίδιο ισχύει σε marketing automations. Ένα newsletter μπορεί να αποτύχει επειδή το segment ήταν λάθος, επειδή το template έσπασε σε mobile, επειδή το προϊόν δεν είχε stock, επειδή το tracking δεν πέρασε UTM ή επειδή το consent state δεν επέτρεπε αποστολή. Αν η ομάδα βλέπει μόνο «χαμηλό performance», θα βγάλει γενικό συμπέρασμα. Αν βλέπει πληθυσμιακά μοτίβα, μπορεί να διορθώσει την πραγματική αιτία.
Σήμα για δεύτερο failure mode
Αν μία εξήγηση δεν καλύπτει καθαρά όλα τα περιστατικά, μη βαφτίζετε τα counterexamples «θόρυβο».
Χωρίστε πρώτα τα failures ανά χρόνο, έκδοση, υποδομή, provider και error signature. Στο περιστατικό της OpenAI, αυτή η διάσπαση ξεχώρισε το hardware corruption από το race condition της libunwind και σταμάτησε την αναζήτηση μιας ανύπαρκτης ενιαίας αιτίας.
Για ένα e-commerce ή B2B brand στην Ελλάδα, το μάθημα δεν είναι να αρχίσει να αναλύει core dumps. Είναι να χτίσει κουλτούρα observability σε ό,τι επηρεάζει έσοδα, εμπειρία πελάτη και brand trust. Αυτό σημαίνει ότι τα κρίσιμα flows πρέπει να έχουν καθαρά events, αναγνωρίσιμα IDs, timestamps, source attribution και τρόπο συσχέτισης ανάμεσα σε εργαλεία.
Στο checkout, κράτα στοιχεία για payment provider, shipping method, browser, device, country, coupon, cart value και error code. Στα lead forms, κράτα source campaign, validation errors, CRM sync status και duplicate handling. Στα AI content workflows, κράτα source URLs, model version, prompt version, retrieval context, human review status και publish outcome. Στα ad automations, κράτα feed version, disapproval reason, creative asset ID και audience changes.
Η αξία δεν είναι μόνο στο monitoring. Είναι στο να μπορείς να απαντήσεις γρήγορα: «αυτό είναι ένα bug ή δύο;», «ξεκίνησε μετά από release;», «επηρεάζει συγκεκριμένο κανάλι;», «συνδέεται με συγκεκριμένο provider;», «είναι μόνιμο ή εμφανίζεται κάτω από load;». Όσο πιο γρήγορα απαντάς, τόσο λιγότερο χάνεις χρόνο σε λάθος υποθέσεις. Η ίδια πειθαρχία χρειάζεται όταν η κατασκευή ή ανανέωση ενός website συνδέει CMS, analytics, forms, payments και τρίτες υπηρεσίες.
Έξι βήματα για διαγνώσιμα digital workflows
Χαρτογραφήστε checkout, lead form, feed προϊόντων, CRM sync και AI automation. Για κάθε flow γράψτε ποιο επιχειρηματικό αποτέλεσμα κινδυνεύει όταν αποτύχει.
Χρησιμοποιήστε correlation ID, ακριβές timestamp, έκδοση, provider και τελικό status, ώστε το ίδιο περιστατικό να ακολουθείται από το site μέχρι το CRM ή τον connector.
Ξεχωρίστε validation, permission, timeout, upstream API, stale data, content error και ανθρώπινη απόρριψη. Το γενικό «AI failed» ή «checkout error» δεν επιτρέπει μάθηση.
Καταγράψτε release, environment, device, payment method, prompt ή workflow version και source freshness, χωρίς να αποθηκεύετε περισσότερα προσωπικά δεδομένα από όσα χρειάζονται.
Ομαδοποιήστε ανά ημερομηνία έναρξης, region, browser, host, integration και error signature. Ελέγξτε αν δύο ομάδες περιστατικών αντιδρούν διαφορετικά στην ίδια αλλαγή.
Ορίστε detection, owner, προσωρινό mitigation, μόνιμη διόρθωση και κριτήριο επανελέγχου. Η έρευνα ολοκληρώνεται όταν η επόμενη εμφάνιση αναγνωρίζεται γρηγορότερα.
Η τελική λύση της OpenAI δεν ήταν μόνο η αλλαγή από GNU libunwind σε libgcc unwinder ή η απομόνωση ενός προβληματικού host. Ήταν η επένδυση σε καλύτερο dataset, αυτοματοποιημένη ανάλυση και operational tooling. Η ομάδα upstreamed reproducer και fix στη GNU libunwind, επαλήθευσε ότι άλλα unwinders δεν είχαν το ίδιο issue και βελτίωσε τα εσωτερικά της εργαλεία ώστε παρόμοια προβλήματα να είναι πιο εύκολα ανιχνεύσιμα στο μέλλον.
Για τις επιχειρήσεις, αυτό μεταφράζεται σε μια απλή αρχή: μη χτίζεις μόνο workflows, χτίζε και τη δυνατότητα να τα διαγνώσεις. Ένα automation χωρίς reporting είναι μαύρο κουτί. Ένα AI σύστημα χωρίς audit trail είναι ρίσκο. Ένα marketing stack χωρίς καθαρή ονοματολογία και ταξινόμηση σφαλμάτων οδηγεί σε αποφάσεις με θόρυβο.
Το “core dump epidemiology” είναι τεχνικός όρος, αλλά η ιδέα είναι επιχειρησιακή: όταν έχεις αρκετά περιστατικά, σταμάτα να τα αντιμετωπίζεις σαν μεμονωμένα δράματα. Φτιάξε καθαρό πληθυσμιακό dataset, βρες clusters, χώρισε αιτίες και μετά διόρθωσε. Αυτό είναι το μονοπάτι από το χάος στην αξιοπιστία.
Αυτοματισμοί επιχειρήσεων & AI
Η TWO DOTS χαρτογραφεί κρίσιμες ροές, integrations, audit trails και σημεία ανθρώπινου ελέγχου, ώστε ένα AI ή automation project να μπορεί να μετρηθεί, να διαγνωστεί και να βελτιωθεί.
Frequently Asked Questions (FAQs)
Είναι η ανάλυση πολλών core dumps ως πληθυσμού περιστατικών και όχι ως μεμονωμένων crashes. Η ομάδα συγκρίνει χρόνο, έκδοση, region, host, hardware και error signature, ώστε να εντοπίσει clusters και διαφορετικές αιτίες που μοιάζουν ίδιες στην επιφάνεια.
Τα crashes που αρχικά αντιμετωπίζονταν ως ένα πρόβλημα προέρχονταν από δύο ανεξάρτητες αιτίες: silent hardware corruption σε έναν φυσικό Azure host και ένα παλιό race condition στη GNU libunwind κατά το C++ exception unwinding.
Η αλλοίωση του stack έκανε ορισμένα stack traces ελλιπή ή παραπλανητικά, ενώ τα log queries έδιναν false positives και false negatives. Η βαθιά εξέταση λίγων περιστατικών ανακάτευε counterexamples από δύο διαφορετικά failure modes και εμπόδιζε μια συνεπή εξήγηση.
Σύμφωνα με την OpenAI, το ChatGPT βοήθησε να γραφτεί script που κατέβαζε prefix από κάθε core file, εξήγαγε registers, φιλτράριζε γνωστά false positives και ταξινομούσε crashes. Η τεχνική κρίση, η ανάλυση των clusters και η τελική επιβεβαίωση παρέμειναν έργο της ομάδας.
Ένα κοινό σύμπτωμα, όπως αποτυχία checkout, μπορεί να κρύβει διαφορετικές αιτίες σε payment provider, browser, shipping rule, stock sync ή release. Χρειάζονται κοινά IDs, σαφείς error categories και ανάλυση ανά κανάλι και περιβάλλον πριν αποφασιστεί η διόρθωση.
Χρήσιμα πεδία είναι workflow και prompt version, model, source URLs ή retrieval context, connector status, permissions, retries, timestamps, ανθρώπινη έγκριση και τελικό αποτέλεσμα. Η καταγραφή πρέπει να είναι επαρκής για διάγνωση, με ελαχιστοποίηση προσωπικών ή ευαίσθητων δεδομένων.
Όχι για να ξεκινήσει. Χρειάζεται όμως συνεπή ονοματολογία, timestamps, correlation IDs, λίγες χρήσιμες κατηγορίες σφαλμάτων, owner για κάθε κρίσιμο flow και ένα απλό runbook. Εργαλεία μεγαλύτερης κλίμακας προστίθενται όταν ο όγκος και η πολυπλοκότητα το δικαιολογούν.
