Charity Majors, CTO & Co-Founder at Honeycomb – Συνέντευξη

Η Charity είναι μηχανικός λειτουργιών και τυχαίος ιδρυτής startup στο Honeycomb. Πριν από αυτό, εργάστηκε στο Parse, Facebook (META ) και Linden Lab σε υποδομή και εργαλεία για développers, και πάντα φαινόταν να τρέχει τις βάσεις δεδομένων. Είναι συν-συγγραφέας του Database Reliability Engineering της O’Reilly, και αγαπά την ελεύθερη ομιλία, το ελεύθερο λογισμικό και το σινγκλ μαλτ σκότς.

Ήσουν ο Production Engineering Manager στο Facebook (τώρα Meta) για πάνω από 2 χρόνια, ποια ήταν κάποια από τα highlights σας από αυτή την περίοδο και ποια είναι κάποια από τα βασικά συμπεράσματα σας από αυτή την εμπειρία;

Εργάστηκα στο Parse, το οποίο ήταν ένα backend για κινητές εφαρμογές, κάτι σαν το Heroku για κινητές. Δεν είχα ποτέ ενδιαφερθεί να εργαστώ σε μια μεγάλη εταιρεία, αλλά μας αγόρασε το Facebook. Ένα από τα βασικά συμπεράσματα μου ήταν ότι οι αγοραπωλησίες είναι πραγματικά πολύ δύσκολες, ακόμη και στις καλύτερες περιπτώσεις. Η συμβουλή που δίνω πάντα σε άλλους ιδρυτές τώρα είναι αυτή: αν θα αγοραστείτε, βεβαιωθείτε ότι έχετε έναν εκτελεστικό χορηγό και σκεφτείτε πολύ καλά αν έχετε στρατηγική συμφωνία. Το Facebook αγόρασε το Instagram λίγο πριν αγοράσει το Parse, και η αγοραπωλησία του Instagram δεν ήταν καθόλου εύκολη, αλλά ήταν τελικά πολύ επιτυχημένη επειδή είχαν στρατηγική συμφωνία και einen ισχυρό χορηγό.

Δεν είχα μια εύκολη στιγμή στο Facebook, αλλά είμαι πολύ ευγνώμων για τον χρόνο που πέρασα εκεί· δεν ξέρω αν θα μπορούσα να ξεκινήσω μια εταιρεία χωρίς τα μαθήματα που έμαθα για οργανωτική δομή, διαχείριση, στρατηγική, κ.λπ. Επίσης, μου έδωσε μια πρεστίζ που με έκανε ελκυστική για τους VC, κανείς από τους οποίους δεν μου είχε δώσει τον χρόνο της ημέρας μέχρι τότε. Είμαι λίγο δυσαρεστημένος γι’ αυτό, αλλά θα το πάρω.

Μπορείτε να μοιραστείτε την ιστορία πίσω από το λανσάρισμα του Honeycomb;

Βέβαια. Από αρχιτεκτονικής πλευράς, το Parse ήταν μπροστά στο χρόνο μας — χρησιμοποιούσαμε microservices πριν υπήρχαν microservices, είχαμε ένα μαζικά sharded δεδομένο στρώμα, και ως πλατφόρμα που εξυπηρετούσε πάνω από ένα εκατομμύριο κινητές εφαρμογές, είχαμε πολλά πραγματικά περίπλοκα προβλήματα πολυ-ενοικίασης. Οι πελάτες μας ήταν développers, και ήταν συνεχώς γράφοντας και ανεβάζοντας τυχαία κώδικα και νέες ερωτήσεις, shall we say, “ποικίλης ποιότητας” — και απλά έπρεπε να τα πάρουμε όλα και να τα κάνουμε να δουλέψουν, κάπως.

Βρισκόμασταν στην αιχμή μιας σειράς αλλαγών που έχουν γίνει mainstream. Παλιότερα, οι περισσότερες αρχιτεκτονικές ήταν khá απλές, και θα αποτυγχάνουν επανειλημμένα με προβλέψιμους τρόπους. Είχατε ένα web στρώμα, μια εφαρμογή, και μια βάση δεδομένων, και η περισσότερη複雑η ήταν δεμένη στο application κώδικα. Έτσι, θα γράφατε ελέγχους παρακολούθησης για να παρακολουθήσετε αυτές τις αποτυχίες, και θα κατασκευάζατε στατικές πίνακες για τα μετρικά και τα δεδομένα παρακολούθησης.

Αυτή η βιομηχανία έχει δει μια έκρηξη σε αρχιτεκτονική複雑η τα τελευταία 10 χρόνια. Έχουμε σπάσει το monolith, ώστε τώρα να έχετε από vài υπηρεσίες έως χιλιάδες εφαρμογές microservices. Η πολυγλωσσική διατήρηση είναι το κανονικό· αντί για “τη βάση δεδομένων” είναι κανονικό να έχετε πολλά διαφορετικά είδη αποθήκευσης, καθώς και οριζόντια sharding, στρώματα caching, db-per-microservice, queueing, και άλλα. Επάνω σε αυτό, έχετε server-side hosted containers, third-party υπηρεσίες και πλατφόρμες, serverless κώδικας, block αποθήκευση, και άλλα.

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

Το debugging αυτών των προβλημάτων από την αρχή είναι απίστευτα δύσκολο. Με τα logs και τα μετρικά, βασικά πρέπει να ξέρετε τι ψάχνετε πριν να μπορέσετε να το βρείτε. Αλλά ξεκινήσαμε να ταΐζουμε κάποια σύνολα δεδομένων σε ένα εργαλείο του Facebook που ονομάζεται Scuba, το οποίο μας επέτρεψε να κοπιάζουμε και να ψιλοκόβουμε σε τυχαίες διαστάσεις και υψηλή καρдинаλικότητα δεδομένων σε πραγματικό χρόνο, και ο χρόνος που μας πήρε να αναγνωρίσουμε και να επιλύσουμε αυτά τα προβλήματα από την αρχή έπεσε σαν βράχος, σαν από ώρες σε… λεπτά; δευτερόλεπτα; Δεν ήταν πλέον ένα πρόβλημα μηχανικής. Μόνο ένα πρόβλημα υποστήριξης. Μπορούσατε απλά να ακολουθήσετε το μονοπάτι των ψιχίων μέχρι την απάντηση κάθε φορά, κλικ-κλικ-κλικ.

Ήταν εκπληκτικό. Αυτή η τεράστια πηγή αβεβαιότητας και μόχθου και δυσαρεστημένων πελατών και 2 π.μ. κλήσεων… έφυγε. Δεν ήταν μέχρι που η Christine και εγώ εγκαταλείψαμε το Facebook που συνειδητοποιήσαμε πόσο πολύ είχε μεταμορφώσει τον τρόπο με τον οποίο αλληλεπιδρούσαμε με το λογισμικό. Η ιδέα να επιστρέψουμε στις παλιές μέρες της παρακολούθησης και των πινάκων ήταν απλά αδιανόητη.

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

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

Η παραδοσιακή παρακολούθηση έχει τρεις πυλώνες: μετρικά, logs και traces. Συνήθως πρέπει να αγοράσετε πολλά εργαλεία για να καλύψετε τις ανάγκες σας: logging, tracing, APM, RUM, dashboarding, οπτικοποίηση, κ.λπ. Κάθε ένα από αυτά είναι βελτιστοποιημένο για eine διαφορετική περίπτωση χρήσης σε διαφορετική μορφή. Jako μηχανικός, κάθεστε στο μέσο αυτών, προσπαθώντας να καταλάβετε όλα αυτά. Ψάχνετε τους πίνακες για να βρείτε οπτικά μοτίβα, αντιγράφετε και επικολλάτε IDs από logs σε traces και πίσω. Είναι πολύ αντιδραστικό και κομματιωμένο, και συνήθως αναφέρεστε σε αυτά τα εργαλεία όταν έχετε ένα πρόβλημα — είναι σχεδιασμένα για να σας βοηθήσουν να λειτουργήσετε τον κώδικα σας και να βρείτε σφάλματα και λάθη.

Η σύγχρονη παρατηρησιμότητα έχει μια seule πηγή αλήθειας· τυχαία wide structured log events. Από αυτά τα γεγονότα μπορείτε να πάρτε τα μετρικά, τους πίνακες και τα logs σας. Μπορείτε να οπτικοποιήσετε αυτά τα δεδομένα με τον χρόνο ως μια ιχνηλάτηση, μπορείτε να κοπιάζετε και να ψιλοκόβετε, μπορείτε να zoom in σε ατομικές αιτήσεις και out στο μακρύ προφίλ. Επειδή όλα είναι συνδεμένα, δεν πρέπει να πηδάτε από εργαλείο σε εργαλείο, μαντεύοντας ή βασίζοντας σε直觉. Η σύγχρονη παρατηρησιμότητα δεν είναι μόνο για το πώς λειτουργείτε τα συστήματά σας, είναι για το πώς αναπτύσσετε τον κώδικα σας. Είναι το υπόστρωμα που σας επιτρέπει να συνδέσετε ισχυρά, στενά βρόχους ανατροφοδότησης που σας βοηθούν να αποστέλλετε πολλή αξία στους χρήστες σας γρήγορα, με εμπιστοσύνη, και να βρείτε προβλήματα πριν οι χρήστες σας.

Είστε γνωστός για την πίστη σας ότι η παρατηρησιμότητα προσφέρει μια seule πηγή αλήθειας σε περιβάλλοντα μηχανικής. Πώς ενσωματώνεται το AI σε αυτή την όραση, και ποια είναι τα οφέλη και οι προκλήσεις σε αυτό το контέκστ;

Η παρατηρησιμότητα είναι σαν να βάζετε τα γυαλιά σας πριν πηγαίνετε hurtling down την autoπίστη. Test-driven ανάπτυξη (TDD) επανασχεδίασε το λογισμικό στις αρχές της δεκαετίας του 2000, αλλά η TDD έχει χάσει την αποτελεσματικότητά της όσο περισσότερη複雑η βρίσκεται στα συστήματά μας αντί για τον κώδικα μας. Όλο και περισσότερο, αν θέλετε να πάρτε τα οφέλη που συνδέονται με την TDD, πρέπει πραγματικά να οργανώσετε τον κώδικα σας και να εκτελέσετε κάτι σαν παρατηρησιμότητα-οδηγούμενη ανάπτυξη, ή ODD, όπου οργανώσετε καθώς πηγαίνετε, αναπτύσσετε γρήγορα, και μετά κοιτάζετε τον κώδικα σας στην παραγωγή μέσω του φακού της οργάνωσης που μόλις γράψατε και ρωτάτε τον εαυτό σας: “κάνει αυτό που περίμενα να κάνει, και υπάρχει κάτι άλλο που φαίνεται… περίεργο;”

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

Αυτό το είδος ανάπτυξης — που περιλαμβάνει την παραγωγή σε γρήγορους βρόχους ανατροφοδότησης — είναι (μια chút αντι-παράδοξο) πολύ γρήγορο, εύκολο και απλό από το να βασίζεστε σε δοκιμές και αργότερες αναπτύξεις. Μόλις οι développers έχουν δοκιμάσει να δουλεύουν με αυτόν τον τρόπο, είναι φημισμένοι για το ότι δεν θέλουν να γυρίσουν πίσω στο παλιό, αργό τρόπο να κάνουν τα πράγματα.

Τι με ενθουσιάζει για το AI είναι ότι όταν αναπτύσσετε με LLMs, πρέπει να αναπτύσσετε στην παραγωγή. Ο μόνος τρόπος που μπορείτε να πάρτε ένα σύνολο δοκιμών είναι πρώτα να επικυρώσετε τον κώδικα σας στην παραγωγή και να εργαστείτε πίσω. Νομίζω ότι η γραφή λογισμικού που υποστηρίζεται από LLMs θα είναι τόσο κοινή ως δεξιοτεχνία όσο η γραφή λογισμικού που υποστηρίζεται από MySQL ή Postgres σε quelques χρόνια, και η ελπίδα μου είναι ότι αυτό θα οδηγήσει τους μηχανικούς σε ένα καλύτερο τρόπο ζωής.

Έχετε εκφράσει ανησυχίες για τη συσσώρευση τεχνικού χρέους λόγω της επανάστασης του AI. Μπορείτε να εξηγήσετε τα είδη τεχνικού χρέους που μπορεί να εισαγάγει το AI και πώς το Honeycomb βοηθά στη διαχείριση ή μείωση αυτών των χρεών;

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

Και αν βάλετε κώδικα στην παραγωγή που κανείς δεν καταλαβαίνει, το Honeycomb δεν μπορεί να βοηθήσει με αυτό. Αλλά αν σας αρέσει να αποστέλλετε καθαρό, επαναλαμβανόμενο λογισμικό, η οργάνωση και η παρατηρησιμότητα είναι απολύτως απαραίτητες σε αυτή την προσπάθεια. Η οργάνωση είναι σαν ντοκουμέντα плюς αναφορά πραγματικού χρόνου. Η οργάνωση είναι ο μόνος τρόπος που μπορείτε πραγματικά να επιβεβαιώσετε ότι ο κώδικάς σας κάνει αυτό που πρέπει να κάνει, και ότι συμπεριφέρεται όπως οι χρήστες σας περιμένουν.

Πώς το Honeycomb χρησιμοποιεί το AI για να βελτιώσει την αποτελεσματικότητα και την αποτελεσματικότητα των ομάδων μηχανικής;

Οι μηχανικοί μας χρησιμοποιούν το AI πολύ εσωτερικά, ιδιαίτερα το CoPilot. Οι νεότεροι μηχανικοί μας αναφέρουν ότι χρησιμοποιούν το ChatGPT κάθε μέρα για να απαντήσουν σε ερωτήσεις και να τους βοηθήσουν να καταλάβουν το λογισμικό που χτίζουν. Οι πιο senior μηχανικοί μας λένε ότι είναι υπέροχο για τη δημιουργία κώδικα που θα ήταν πολύ χρονοβόρο ή ενοχλητικό να γράψουν, όπως όταν έχετε ένα巨ανιο YAML αρχείο να γεμίσετε. Είναι επίσης χρήσιμο για τη δημιουργία τμημάτων κώδικα σε γλώσσες που δεν χρησιμοποιείτε συνήθως, ή από API τεκμηρίωση. Όπως, μπορείτε να δημιουργήσετε κάποια πραγματικά καλά, χρηστικά παραδείγματα πραγμάτων χρησιμοποιώντας τα AWS SDKs και APIs,既然 ότι είχε εκπαιδευτεί σε repos που είχαν πραγματική χρήση αυτού του κώδικα.

Ωστόσο, κάθε φορά που αφήνετε το AI να γεννήσει τον κώδικα σας, πρέπει να περάσετε από αυτόν γραμμή προς γραμμή για να βεβαιωθείτε ότι κάνει το σωστό πράγμα, επειδή θα φαντασιώνει σκουπίδια μερικές φορές.

Μπορείτε να δώσετε παραδείγματα για το πώς τα AI-ενισχυμένα χαρακτηριστικά όπως ο βοηθός ερωτήσεων σας ή η ολοκλήρωση του Slack βελτιώνουν τη συνεργασία της ομάδας;

Ναι, βέβαια. Ο βοηθός ερωτήσεων μας είναι ένα υπέροχο παράδειγμα. Η χρήση query builders είναι περίπλοκη και δύσκολη, ακόμη και για power users. Αν έχετε εκατοντάδες ή χιλιάδες διαστάσεις στα τηλεμετρικά σας, δεν μπορείτε πάντα να θυμηθείτε εκ των προτέρων τι είναι τα πιο πολύτιμα από αυτά. Και ακόμη και οι power users λένε ότι ξεχνούν τις λεπτομέρειες για το πώς να γεννήσουν certains τύπους γραφικών.

Οтак, ο βοηθός ερωτήσεων μας σας επιτρέπει να κάνετε ερωτήσεις χρησιμοποιώντας φυσική γλώσσα. Όπως, “ποια είναι τα πιο αργά endpoints;”, ή “τι συνέβη μετά την τελευταία μου ανάπτυξη;” και γεννάει μια ερώτηση και σας ρίχνει μέσα σε αυτή. Οι περισσότεροι άνθρωποι βρίσκουν ότι είναι δύσκολο να συνθέσουν μια νέα ερώτηση από την αρχή και εύκολο να τροποποιήσουν μια υπάρχουσα.

Το Honeycomb υποσχέθηκε ταχύτερη επίλυση περιστατικών. Μπορείτε να περιγράψετε πώς η ολοκλήρωση των logs, metrics και traces σε ένα ενοποιημένο τύπο δεδομένων βοηθά στην ταχύτερη αντιμετώπιση προβλημάτων και επίλυση προβλημάτων;

Όλα είναι συνδεμένα. Δεν πρέπει να μαντεύετε. Αντί να κοιτάζετε ότι αυτός ο πίνακας μοιάζει με αυτόν τον πίνακα, ή να μαντεύετε ότι αυτή η αύξηση στα μετρικά σας πρέπει να είναι η ίδια με αυτή την αύξηση στα logs σας με βάση τα χρονικά σημεία….αντί, τα δεδομένα είναι όλα συνδεμένα. Δεν πρέπει να μαντεύετε, μπορείτε απλά να ρωτήσετε.

Τα δεδομένα γίνονται πολύτιμα από το контέκστ. Η τελευταία γενιά εργαλείων δούλεψε με το να αφαιρεί όλα τα kontέκστ κατά την время της γραφής· μια φορά που έχετε απορρίψει το kontέκστ, δεν μπορείτε ποτέ να το πάρει πίσω.

Επίσης: με τα logs και τα μετρικά, πρέπει να ξέρετε τι ψάχνετε πριν να μπορέσετε να το βρείτε. Αυτό δεν ισχύει για τη σύγχρονη παρατηρησιμότητα. Δεν πρέπει να ξέρετε τίποτα, ή να ψάχνετε για τίποτα.

Όταν αποθηκεύετε αυτά τα πλούσια kontέκστ δεδομένα, μπορείτε να κάνετε πράγματα με αυτά που φαίνονται σαν μαγία. Έχουμε ένα εργαλείο που ονομάζεται BubbleUp, όπου μπορείτε να τραβήξετε einen φούσκωμα γύρω από οτιδήποτε νομίζετε ότι είναι περίεργο ή μπορεί να είναι ενδιαφέρον, και υπολογίζουμε όλες τις διαστάσεις μέσα στο φούσκωμα έναντι του εξωτερικού, της βάσης, και ταξινομούμε και διαφοροποιούμε. Έτσι, είστε σαν “αυτό το φούσκωμα είναι περίεργο” και σας λέμε αμέσως, “είναι διαφορετικό σε xyz τρόπους”. Πολύ από το debugging βγάζει “εδώ есть κάτι που με ενδιαφέρει, αλλά γιατί με ενδιαφέρει;” Όταν μπορείτε να αναγνωρίσετε αμέσως ότι είναι διαφορετικό επειδή αυτές οι αιτήσεις έρχονται από Android συσκευές, με αυτό το συγκεκριμένο build ID, χρησιμοποιώντας αυτή τη γλώσσα pack, σε αυτή τη περιοχή, με αυτή την εφαρμογή ID, με μια μεγάλη φόρτωση … τώρα πιθανότατα ξέρετε ακριβώς τι είναι λάθος και γιατί.

Δεν είναι μόνο για το ενοποιημένο δεδομένο, όμως — αν και αυτό είναι ένα τεράστιο μέρος του. Είναι επίσης για το πώς χειριζόμαστε με ευκολία τα δεδομένα υψηλής καρдинаλικότητας, όπως μοναδικοί IDs, IDs καλαθιού αγορών, IDs εφαρμογών, ονόματα και επώνυμα, κ.λπ. Η τελευταία γενιά εργαλείων δεν μπορεί να χειριστεί πλούσια δεδομένα σαν αυτά, που είναι κάτι που δεν μπορείτε να πιστέψετε όταν το σκεφτείτε, επειδή πλούσια, υψηλή καρдинаλικότητα δεδομένα είναι τα πιο πολύτιμα και ταυτοποιήσιμα δεδομένα από όλα.

Πώς η βελτίωση της παρατηρησιμότητας μεταφράζεται σε καλύτερα επιχειρηματικά αποτελέσματα;

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

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

Πού βλέπετε το μέλλον της παρατηρησιμότητας να πηγαίνει, ιδιαίτερα σε σχέση με τις εξελίξεις του AI;

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

Είναι για να συνδέσετε τα σημεία μεταξύ επιχειρηματικών αποτελεσμάτων και τεχνολογικών μεθόδων.

Και είναι για να βεβαιωθείτε ότι καταλαβαίνετε το λογισμικό που βγάζετε στον κόσμο. Όσο πιο περίπλοκο γίνεται το λογισμικό και τα συστήματα, και ιδιαίτερα καθώς το AI γίνεται όλο και περισσότερο μέρος του μείγματος, είναι πιο σημαντικό niż ποτέ να κρατάμε τους εαυτούς μας σε ένα ανθρώπινο πρότυπο κατανοησιμότητας και διαχείρισης.

Από την πλευρά της παρατηρησιμότητας, θα δούμε αυξανόμενα επίπεδα σοφιστικέ στο pipeline δεδομένων — χρησιμοποιώντας machine learning και sophisticated δειγματοληψία τεχνικές για να ισορροπήσετε αξία έναντι κόστους, για να κρατήσετε όσο το δυνατόν περισσότερες λεπτομέρειες για outlier events και σημαντικά events και να αποθηκεύσετε περίληψη του υπόλοιπου με όσο το δυνατόν πιο φθηνό κόστος.

Οι προμηθευτές AI κάνουν πολλά υπερβολικά ισχυρά ισχυρισματα για το πώς μπορούν να καταλάβουν το λογισμικό σας καλύτερα από εσάς, ή πώς μπορούν να επεξεργαστούν τα δεδομένα και να πουν στους ανθρώπινους σας ποια ενέργειες να κάνουν. Από όλα όσα έχω δει, αυτό είναι ένα ακριβό όνειρο. Ψευδείς θετικοί είναι απίστευτα ακριβοί. Δεν υπάρχει αντικατάσταση για την κατανόηση των συστημάτων σας και των δεδομένων σας. Το AI μπορεί να βοηθήσει τους μηχανικούς σας με αυτό! Αλλά δεν μπορεί να αντικαταστήσει τους μηχανικούς σας.

Ευχαριστώ πολύ για τη μεγάλη συνέντευξη, οι αναγνώστες που θέλουν να μάθουν περισσότερα πρέπει να επισκεφθούν το Honeycomb.