Dzmitry Lazerka, Συνιδρυτής της VictoriaMetrics – Σειρά Συνεντεύξεων

Ο Dzmitry Lazerka, συνιδρυτής της VictoriaMetrics, είναι έμπειρος μηχανικός λογισμικού και ηγέτης τεχνολογίας με βαθιά εξειδίκευση στη μηχανική μάθηση, στα συστήματα δεδομένων μεγάλης κλίμακας, στην παρατηρησιμότητα και στις υποδομές. Πριν συνιδρύσει τη VictoriaMetrics το 2018, εργάστηκε ως μηχανικός μηχανικής μάθησης στο τμήμα αυτόνομων οχημάτων Level 5 της Lyft, όπου συνέβαλε στην ανάπτυξη συστημάτων αναγνώρισης και ανάλυσης πραγματικών σεναρίων οδήγησης. Νωρίτερα, ηγήθηκε έργων μηχανικής μάθησης και υποδομών δεδομένων στη Spire Global, υπήρξε συνιδρυτής με αρμοδιότητα τη μηχανική στην Bellgram και εργάστηκε σε συστήματα δεδομένων και αναλυτικής στην Duetto Research και στην Google μέσω της EPAM Systems. Σε όλη τη σταδιοδρομία του, ο Lazerka έχει δημιουργήσει και διευθύνει έργα που καλύπτουν την αυτόνομη οδήγηση, τη θαλάσσια πρόβλεψη, την αναζήτηση, την αναλυτική, την κατανεμημένη επεξεργασία δεδομένων και εξαιρετικά επεκτάσιμα συστήματα υποστήριξης.

Η VictoriaMetrics είναι μια εταιρεία παρατηρησιμότητας ανοικτού κώδικα που αναπτύσσει εργαλεία για τη συλλογή, την αποθήκευση, την υποβολή ερωτημάτων και την ανάλυση μεγάλων όγκων λειτουργικών δεδομένων. Η τεχνολογία της ξεκίνησε με τη VictoriaMetrics, μια βάση δεδομένων χρονοσειρών υψηλών επιδόσεων και λύση παρακολούθησης σχεδιασμένη για επεκτασιμότητα, γρήγορα ερωτήματα, αποδοτική αποθήκευση και χαμηλό λειτουργικό φόρτο, και έκτοτε εξελίχθηκε σε μια ευρύτερη στοίβα παρατηρησιμότητας που καλύπτει μετρικές, αρχεία καταγραφής και κατανεμημένα ίχνη μέσω των VictoriaMetrics, VictoriaLogs και VictoriaTraces. Η εταιρεία προσφέρει επίσης εταιρικές και πλήρως διαχειριζόμενες υλοποιήσεις στο cloud, καθώς και δυνατότητες ανίχνευσης ανωμαλιών που εφαρμόζουν μηχανική μάθηση σε δεδομένα χρονοσειρών. Η πλατφόρμα της υποστηρίζει τεχνολογίες όπως OpenTelemetry, ροές εργασίας συμβατές με Prometheus, Grafana και Kubernetes, προσφέροντας στους οργανισμούς ευελιξία για την ενσωμάτωση της VictoriaMetrics στα υπάρχοντα περιβάλλοντα παρατηρησιμότητας.

Πριν συνιδρύσετε τη VictoriaMetrics, εργαστήκατε σε συστήματα δεδομένων μεγάλης κλίμακας, αναλυτικής και μηχανικής μάθησης στην Google, στη Spire Global, στο τμήμα αυτόνομων οχημάτων της Lyft και σε άλλες νεοφυείς επιχειρήσεις. Τι σας οδήγησε τελικά στην ίδρυση της VictoriaMetrics και ποια προβλήματα από εκείνους τους προηγούμενους ρόλους σάς έπεισαν ότι η παρακολούθηση και η παρατηρησιμότητα χρειάζονταν μια θεμελιωδώς διαφορετική προσέγγιση;

Πέρασα τη σταδιοδρομία μου δουλεύοντας με μεγάλους όγκους δεδομένων. Στην Google, στη Spire, στη Lyft και σε άλλες εταιρείες μαθαίνεις γρήγορα ότι κάτι που λειτουργεί καλά σε μια κλίμακα μπορεί να γίνει ακριβό ή δύσκολο στη λειτουργία σε μια άλλη. Η παρακολούθηση αντιμετωπίζει ακριβώς αυτό το πρόβλημα.

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

Αυτό είδαν άμεσα οι συνιδρυτές μου, Aliaksandr Valialkin και Roman Khavronenko. Είχαν εμπειρία στη λειτουργία του Prometheus και στην αντιμετώπιση περιορισμών μνήμης. Η προσθήκη συστημάτων όπως το Thanos έλυνε ορισμένα προβλήματα κλιμάκωσης, αλλά εισήγαγε επίσης περισσότερα στοιχεία και μεγαλύτερη λειτουργική πολυπλοκότητα. Και με το InfluxDB είδαμε πώς μια αλλαγή άδειας χρήσης μπορούσε να επηρεάσει τις μηχανικές αποφάσεις αφού οι ομάδες είχαν ήδη επενδύσει στην τεχνολογία.

Έτσι, η ιδέα πίσω από τη VictoriaMetrics ήταν πρακτική: Μπορούμε να δημιουργήσουμε μια βάση δεδομένων χρονοσειρών που να κάνει την ίδια δουλειά με σημαντικά λιγότερους πόρους και να είναι απλούστερη στη λειτουργία;

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

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

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

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

Θα εξέταζα πρώτα την πληθικότητα.

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

Το δύσκολο είναι ότι αυτό δεν συμβαίνει επειδή κάποιος πήρε μία κακή απόφαση. Συμβαίνει σταδιακά. Προσθέστε περισσότερες υπηρεσίες, pods του K8s, πελάτες και ετικέτες και το κόστος πολλαπλασιάζεται.

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

Αν αντιμετωπίζετε όλα αυτά τα δεδομένα με τον ίδιο τρόπο, καταλήγετε να πληρώνετε υψηλές τιμές υποδομής ή SaaS για δεδομένα που δεν το απαιτούν.

Γι’ αυτό ορισμένες εταιρείες αντιμετωπίζουν την παρατηρησιμότητα ως πρόβλημα αγοράς, ρωτώντας ποια πλατφόρμα είναι ευκολότερο να αναπτυχθεί σήμερα. Εγώ θέτω ερωτήματα όπως: «Τι συμβαίνει όταν η ποσότητα τηλεμετρίας αυξηθεί κατά δέκα φορές; Τι συμβαίνει με την πληθικότητα; Τι αποθηκεύουμε; Για πόσο χρόνο; Και τι συμβαίνει με το κόστος;»

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

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

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

Η παρατηρησιμότητα είναι ένα μηχανικό σύστημα. Και το κόστος της πρέπει επίσης να σχεδιάζεται.

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

Είναι συνδυασμός παραγόντων, αλλά το μεγαλύτερο μέρος της διαφοράς προέρχεται από τη συμπίεση και το αποτύπωμα πόρων. Η VictoriaMetrics χρησιμοποιεί ειδικά σχεδιασμένη συμπίεση για δεδομένα χρονοσειρών, οπότε οι ίδιες μετρικές καταλαμβάνουν ένα κλάσμα του χώρου στον δίσκο που θα χρειάζονταν σε μια βάση δεδομένων γενικού σκοπού. Επιπλέον, χρησιμοποιούμε τέσσερις έως πέντε φορές λιγότερη μνήμη RAM από το Prometheus στους ίδιους ρυθμούς εισαγωγής και έως δέκα φορές λιγότερο χώρο στον δίσκο. Όταν η Grammarly πραγματοποίησε τη δοκιμή σκοπιμότητας, αυτό φάνηκε άμεσα στον λογαριασμό AWS, επειδή δεν αποθήκευε απλώς λιγότερα δεδομένα· χρησιμοποιούσε επίσης λιγότερες και μικρότερες παρουσίες για να το πετύχει.

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

Το Prometheus έχει γίνει θεμελιώδες για την παρακολούθηση περιβαλλόντων cloud-native, ωστόσο ορισμένοι οργανισμοί τελικά συναντούν περιορισμούς κλιμάκωσης ή λειτουργίας. Τι οδηγεί συνήθως μια εταιρεία να αναζητήσει κάτι πέρα από μια συμβατική εγκατάσταση Prometheus και πότε η VictoriaMetrics γίνεται μια λογική εναλλακτική;

Το Prometheus είναι εξαιρετικό σε αυτό για το οποίο δημιουργήθηκε: μια μηχανή συλλογής και ειδοποιήσεων ενός κόμβου. Οι ομάδες συνήθως φτάνουν στα όριά του με δύο τρόπους: είτε η πληθικότητα αυξάνεται πέρα από όσα μπορεί να χωρέσει στη μνήμη μία παρουσία Prometheus είτε χρειάζονται μακροχρόνια διατήρηση και καθολικά ερωτήματα σε πολλαπλά συμπλέγματα, κάτι για το οποίο το Prometheus δεν σχεδιάστηκε ποτέ να κάνει μόνο του. Τότε προσθέτουν το Thanos ή το Cortex και συνήθως εκεί αρχίζει ο λειτουργικός πόνος. Από τη λειτουργία ενός εκτελέσιμου περνούν σε ένα κατανεμημένο σύστημα με compactor, querier, store gateway και πολλά ακόμη στοιχεία που μπορούν να παρουσιάσουν βλάβη στις τρεις τα ξημερώματα.

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

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

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

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

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

Η αξιοποίηση της GPU από μόνη της δεν σας λέει αρκετά.

Μπορεί να δείτε αξιοποίηση 90% σε έναν πίνακα ελέγχου και να υποθέσετε ότι όλα λειτουργούν σωστά. Αυτό που πραγματικά θέλετε να γνωρίζετε, όμως, είναι: Τι κάνει η GPU;

Πρέπει να εξετάσετε βαθύτερα. Ποιοι πυρήνες CUDA εκτελούνται; Πώς εκχωρείται η μνήμη GPU; Πόσος χρόνος δαπανάται στη μετακίνηση μνήμης αντί για υπολογισμούς; Χρησιμοποιεί το φορτίο τους Tensor Cores όταν πρέπει; Είναι πράγματι η GPU το σημείο συμφόρησης ή περιμένει δεδομένα από κάπου αλλού;

Αυτές είναι σημαντικές ερωτήσεις επειδή οι GPU είναι ακριβές. Μια μικρή αναποτελεσματικότητα που επαναλαμβάνεται σε εκατοντάδες ή χιλιάδες GPU μετατρέπεται σε ένα πολύ μεγάλο χρηματικό ποσό.

Για παράδειγμα, αν οι GPU περιμένουν επειδή ο αγωγός δεδομένων δεν μπορεί να τις τροφοδοτήσει αρκετά γρήγορα, η αγορά περισσότερων GPU δεν θα λύσει το πρόβλημα. Πρέπει να βρείτε το σημείο συμφόρησης. Το ίδιο ισχύει και για τη μνήμη. Αν τα φορτία εκχωρούν τη μνήμη αναποτελεσματικά, η καλύτερη ορατότητα μπορεί να βοηθήσει τους μηχανικούς να προσαρμόσουν τα μεγέθη παρτίδας ή να εκτελέσουν περισσότερα φορτία στο ίδιο υλικό.

Εδώ αποκτά ιδιαίτερο ενδιαφέρον η παρατηρησιμότητα για τις υποδομές AI. Δεν αφορά μόνο τον εντοπισμό κάποιας βλάβης. Μπορεί να σας δείξει πού σπαταλάτε υπολογιστικούς πόρους.

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

Με το OpenTelemetry και έργα όπως το OpenLIT μπορούμε να αποκτήσουμε πολύ βαθύτερη ορατότητα στα φορτία GPU. Στη συνέχεια, με τη VictoriaMetrics, μπορούμε να συγκεντρώνουμε τα δεδομένα, να αφαιρούμε διαστάσεις που δεν είναι χρήσιμες και να διατηρούμε αποδοτικά τις πληροφορίες που πραγματικά χρειάζονται οι μηχανικοί.

Η χρήσιμη ερώτηση δεν είναι: «Πόσο αξιοποιούνται οι GPU μου;»

Είναι: «Πόση χρήσιμη εργασία λαμβάνω από τις GPU για τις οποίες πληρώνω;»

Μόλις μπορέσετε να απαντήσετε σε αυτό, μπορείτε να αρχίσετε να παίρνετε καλύτερες μηχανικές και οικονομικές αποφάσεις.

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

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

Οι τρόποι αστοχίας είναι επίσης διαφορετικοί. Μια παραδοσιακή υπηρεσία είτε ανταποκρίνεται σωστά είτε όχι. Ένας πράκτορας μπορεί να ανταποκριθεί επιτυχώς και παρ’ όλα αυτά να είναι λανθασμένος, αργός ή ακριβός, χωρίς τίποτε από αυτά να εμφανίζεται ως τυπικό σφάλμα σε έναν πίνακα ελέγχου σχεδιασμένο για χρόνο διαθεσιμότητας.

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

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

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

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

Η VictoriaMetrics έχει παραμείνει ανοικτού κώδικα και έχει ακολουθήσει μια αυτοχρηματοδοτούμενη προσέγγιση, χρηματοδοτούμενη από τους πελάτες, αντί για το παραδοσιακό μοντέλο νεοφυούς εταιρείας υποδομών με χρηματοδότηση επιχειρηματικού κεφαλαίου. Πώς έχει επηρεάσει αυτό τον τρόπο με τον οποίο δημιουργείτε το προϊόν, το τιμολογείτε και αποφασίζετε ποιες τεχνολογίες παραμένουν ανοικτού κώδικα;

Η αυτοχρηματοδότηση αλλάζει τη δομή κινήτρων περισσότερο απ’ όσο περιμένουν οι περισσότεροι. Χωρίς ένα διοικητικό συμβούλιο να μας ζητά να πετύχουμε έναν συγκεκριμένο αριθμό ARR μέχρι ένα συγκεκριμένο τρίμηνο, δεν χρειάστηκε να κάνουμε τους συμβιβασμούς που συνήθως συνοδεύουν αυτή την πίεση, όπως να περιορίσουμε σκόπιμα την έκδοση ανοικτού κώδικα για να εξαναγκάσουμε τους χρήστες να περάσουν σε μια επί πληρωμή βαθμίδα ή να αλλάξουμε την άδεια χρήσης όπως έκαναν η InfluxDB ή η HashiCorp όταν χρειάστηκε να προστατεύσουν τα έσοδά τους από παρόχους cloud. Η VictoriaMetrics OSS χρησιμοποιεί σήμερα την άδεια Apache 2.0 και δεν σχεδιάζουμε να την αλλάξουμε.

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

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

Η στοίβα συγκλίνει λειτουργικά πριν συγκλίνει σε ένα ενιαίο προϊόν και αυτή η διάκριση έχει σημασία. Οι περισσότερες ομάδες δεν θέλουν μία μονολιθική πλατφόρμα με ένα ενιαίο περιβάλλον χρήστη που τα κλειδώνει όλα μαζί. Θέλουν οι μετρικές, τα αρχεία καταγραφής και τα ίχνη να λειτουργούν με ένα λειτουργικό μοντέλο, έναν προμηθευτή και μία προσέγγιση αδειοδότησης, χωρίς να εγκαταλείπουν τη δυνατότητα ανεξάρτητης λειτουργίας κάθε σήματος, αν αυτό χρειάζεται μια συγκεκριμένη ομάδα. Αυτή είναι η κατεύθυνση προς την οποία αναπτύσσεται η VictoriaMetrics. Δεν προσπαθούμε να συνδέσουμε τα πάντα σε ένα μόνο εκτελέσιμο. Προσπαθούμε να διασφαλίσουμε ότι τα τρία σήματα μοιράζονται τον ίδιο κινητήρα και τα ίδια χαρακτηριστικά αποδοτικότητας, ώστε η προσθήκη ενός δεύτερου ή τρίτου σήματος να μη σημαίνει την υιοθέτηση ενός δεύτερου ή τρίτου λειτουργικού προβλήματος.

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

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