Dzmitry Lazerka, VictoriaMetrics के सह-संस्थापक – साक्षात्कार श्रृंखला

Dzmitry Lazerka, VictoriaMetrics के सह-संस्थापक – एक अनुभवी सॉफ्टवेयर इंजीनियर और प्रौद्योगिकी नेता हैं जिनके पास मशीन लर्निंग, बड़े पैमाने के डेटा सिस्टम, ऑब्ज़र्वेबिलिटी और इन्फ्रास्ट्रक्चर में गहरी विशेषज्ञता है। 2018 में VictoriaMetrics की सह-स्थापना करने से पहले, उन्होंने Lyft की Level 5 स्वायत्त वाहन डिवीजन में मशीन लर्निंग इंजीनियर के रूप में काम किया, जहाँ उन्होंने वास्तविक‑विश्व ड्राइविंग परिदृश्यों को पहचानने और विश्लेषण करने के लिए सिस्टम विकसित करने में मदद की। पहले, उन्होंने Spire Global में मशीन लर्निंग और डेटा इन्फ्रास्ट्रक्चर प्रोजेक्ट्स का नेतृत्व किया, Bellgram में एक इंजीनियरिंग सह-संस्थापक के रूप में कार्य किया, और EPAM Systems के माध्यम से Duetto Research और Google में डेटा और एनालिटिक्स सिस्टम पर काम किया। अपने करियर में, Lazerka ने स्वायत्त ड्राइविंग, समुद्री भविष्यवाणी, सर्च, एनालिटिक्स, वितरित डेटा प्रोसेसिंग और अत्यधिक स्केलेबल बैकएंड सिस्टम्स सहित कई प्रोजेक्ट्स का निर्माण और नेतृत्व किया है।

VictoriaMetrics एक ओपन‑सॉर्स ऑब्ज़र्वेबिलिटी कंपनी है जो बड़े पैमाने पर ऑपरेशनल डेटा एकत्रित करने, संग्रहीत करने, क्वेरी करने और विश्लेषण करने के लिए टूल बनाती है। इसकी तकनीक की शुरुआत VictoriaMetrics से हुई, जो स्केलेबिलिटी, तेज़ क्वेरी, कुशल स्टोरेज और कम ऑपरेशनल ओवरहेड के लिए डिज़ाइन किया गया एक हाई‑परफ़ॉर्मेंस टाइम‑सीरीज़ डेटाबेस और मॉनिटरिंग समाधान है, और तब से यह VictoriaMetrics, VictoriaLogs और VictoriaTraces के माध्यम से मेट्रिक्स, लॉग्स और वितरित ट्रेसेज़ को कवर करने वाले व्यापक ऑब्ज़र्वेबिलिटी स्टैक में विस्तारित हो गया है। कंपनी एंटरप्राइज़ और पूरी तरह प्रबंधित क्लाउड डिप्लॉयमेंट्स के साथ-साथ टाइम‑सीरीज़ डेटा पर मशीन लर्निंग लागू करने वाली एनोमली डिटेक्शन क्षमताएँ भी प्रदान करती है। इसका प्लेटफ़ॉर्म OpenTelemetry, Prometheus‑संगत वर्कफ़्लो, Grafana और Kubernetes सहित तकनीकों को सपोर्ट करता है, जिससे संगठनों को मौजूदा ऑब्ज़र्वेबिलिटी वातावरण में VictoriaMetrics को एकीकृत करने की लचीलापन मिलती है।

VictoriaMetrics की सह-स्थापना करने से पहले, आपने Google, Spire Global, Lyft की स्वायत्त वाहन डिवीजन और अन्य स्टार्टअप्स में बड़े पैमाने के डेटा, एनालिटिक्स और मशीन लर्निंग सिस्टम्स पर काम किया। अंततः आपको VictoriaMetrics स्थापित करने के लिए क्या प्रेरित किया, और उन पूर्व भूमिकाओं की कौन सी समस्याओं ने आपको यह विश्वास दिलाया कि मॉनिटरिंग और ऑब्ज़र्वेबिलिटी को मूलतः अलग दृष्टिकोण की आवश्यकता है?

मैंने अपना करियर बड़े पैमाने पर डेटा के साथ काम करते हुए बिताया। Google, Spire, Lyft और अन्य कंपनियों में, आप जल्दी ही सीखते हैं कि जो चीज़ एक स्केल पर अच्छी तरह काम करती है, वह दूसरे स्केल पर महंगी या संचालित करने में कठिन हो सकती है। मॉनिटरिंग में बिल्कुल यही समस्या है।

जैसे-जैसे इन्फ्रास्ट्रक्चर बढ़ता है, आप अधिक मेट्रिक्स बनाते हैं। आप अधिक सेवाएँ, अधिक इंस्टेंस और अधिक लेबल जोड़ते हैं, जब तक कि अचानक मॉनिटरिंग सिस्टम को स्वयं को चलाने के लिए पर्याप्त इन्फ्रास्ट्रक्चर की आवश्यकता न पड़ जाए, जो हमारे लिए कभी समझ में नहीं आया। एक ऐसा सिस्टम जो आपके प्रोडक्शन वातावरण की निगरानी के लिए बनाया गया है, उसे अधिक जटिल और महंगा नहीं होना चाहिए।

इसी बात को मेरे सह-संस्थापक Aliaksandr Valialkin और Roman Khavronenko ने सीधे देखा। उन्हें Prometheus चलाने और मेमोरी सीमाओं का सामना करने का अनुभव था। Thanos जैसे सिस्टम जोड़ने से कुछ स्केलिंग समस्याएँ हल हुईं, लेकिन इससे अधिक घटक और अधिक ऑपरेशनल जटिलता भी आई। और InfluxDB के साथ, हमने देखा कि लाइसेंसिंग परिवर्तन कैसे इंजीनियरिंग निर्णयों को प्रभावित कर सकता है, जब टीमें पहले से ही तकनीक में निवेश कर चुकी होती हैं।

इसलिए VictoriaMetrics के पीछे विचार व्यावहारिक था: क्या हम एक टाइम‑सीरीज़ डेटाबेस बना सकते हैं जो वही कार्य कम संसाधनों के साथ करे और संचालित करने में सरल हो?

हमने बड़े ऑब्ज़र्वेबिलिटी कंपनी बनाने की योजना से शुरुआत नहीं की। हमने एक इंजीनियरिंग समस्या को हल करके शुरू किया।

इसे ओपन‑सॉर्स बनाना इसका हिस्सा था। इंजीनियर VictoriaMetrics को डाउनलोड कर सकते थे, वास्तविक प्रोडक्शन वर्कलोड्स उस पर चला सकते थे और स्वयं परिणामों की तुलना कर सकते थे। हमें उन्हें यह बताने की जरूरत नहीं थी कि यह तेज़ या अधिक कुशल है। वे स्वयं इसे माप सकते थे।

यह इन्फ्रास्ट्रक्चर सॉफ़्टवेयर बनाने का सबसे अच्छा तरीका है। यदि तकनीक अच्छी है, तो इंजीनियर स्वयं इसे सिद्ध कर सकें।

ऑब्ज़र्वेबिलिटी लागतें चुपचाप कंपनी के क्लाउड बिल का एक महत्वपूर्ण हिस्सा बन सकती हैं। ये लागतें आमतौर पर कहाँ नियंत्रण से बाहर हो जाती हैं, और कौन से आर्किटेक्चर या खरीद निर्णय इंजीनियरिंग टीमें अक्सर गलत करती हैं?

मैं पहले कार्डिनैलिटी को देखूँगा।

मान लीजिए आप एक उचित मेट्रिक से शुरू करते हैं, फिर संभावित मानों के साथ एक लेबल जोड़ते हैं। अचानक, एक मेट्रिक हजारों या लाखों अनोखी टाइम‑सीरीज़ में बदल जाता है। सिस्टम को अब अधिक डेटा को इनजेस्ट, इंडेक्स, स्टोर और क्वेरी करना पड़ता है, जिससे अधिक CPU, मेमोरी और स्टोरेज की आवश्यकता होती है।

कठिन हिस्सा यह है कि यह इसलिए नहीं होता क्योंकि किसी ने एक बुरा निर्णय लिया। यह धीरे‑धीरे होता है। अधिक सेवाएँ, K8s पॉड, ग्राहक और लेबल जोड़ें, और लागत कई गुना बढ़ जाती है।

दूसरी समस्या यह है कि सब कुछ समान रेज़ॉल्यूशन पर समान अवधि के लिए स्टोर करना। सभी ऑब्ज़र्वेबिलिटी डेटा का मूल्य समान नहीं होता। अलर्ट या SLO के लिए आवश्यक मेट्रिक्स उच्च‑वॉल्यूम डायग्नोस्टिक टेलीमेट्री से अलग होते हैं, जिसे आप किसी घटना के दौरान एक बार देख सकते हैं।

यदि आप सभी डेटा को समान रूप से मानते हैं, तो आप उन डेटा के लिए प्रीमियम इन्फ्रास्ट्रक्चर या SaaS कीमतें चुकाते हैं, जिन्हें इसकी आवश्यकता नहीं होती।

इसीलिए कुछ कंपनियाँ ऑब्ज़र्वेबिलिटी को एक खरीद समस्या के रूप में देखती हैं, यह पूछते हुए कि आज कौन सा प्लेटफ़ॉर्म सबसे आसान है। मैं ऐसे प्रश्न पूछता हूँ, “जब टेलीमेट्री की मात्रा 10 गुना बढ़ती है तो क्या होता है? कार्डिनैलिटी का क्या होता है? हम क्या स्टोर कर रहे हैं? कितने समय तक? और लागत का क्या होता है?”

इन समस्याओं के लिए इंजीनियरिंग समाधान मौजूद हैं। उदाहरण के लिए, स्ट्रीमिंग एग्रीगेशन के साथ, आप प्रत्येक कच्ची टाइम‑सीरीज़ को बाद में एग्रीगेट करने के बजाय स्टोरेज तक पहुँचने से पहले मेट्रिक्स को एग्रीगेट कर सकते हैं। आप हाई‑कार्डिनैलिटी वर्कलोड्स को बिज़नेस‑क्रिटिकल मॉनिटरिंग से अलग कर सकते हैं। आप डेटा के मूल्य के आधार पर विभिन्न रिटेंशन और रेज़ॉल्यूशन नीतियों का भी उपयोग कर सकते हैं।

उद्देश्य यथासंभव कम टेलीमेट्री एकत्र करना नहीं है। आपको यह समझने के लिए पर्याप्त जानकारी चाहिए कि आपके सिस्टम क्या कर रहे हैं।

उद्देश्य यह है कि संसाधनों को डेटा एकत्र करने, प्रोसेस करने और स्टोर करने में इस तरह खर्च करने से बचा जाए जो आपको अतिरिक्त मूल्य नहीं देता।

ऑब्ज़र्वेबिलिटी एक इंजीनियरिंग सिस्टम है। इसकी लागत को भी इंजीनियर किया जाना चाहिए।

Grammarly ने कहा है कि VictoriaMetrics के साथ उनका प्रूफ़‑ऑफ़‑कॉन्सेप्ट 10 गुना कम AWS बिल में बदल गया। जब कंपनियाँ इस पैमाने पर बचत हासिल करती हैं, तो वास्तव में किन चीज़ों में परिवर्तन हो रहा है: डेटा संपीड़न, कंप्यूट आवश्यकताएँ, स्टोरेज आर्किटेक्चर, ऑपरेशनल जटिलता, या इन कारकों का कोई संयोजन?

यह एक संयोजन है, लेकिन संपीड़न और संसाधन फुटप्रिंट अधिकांश काम करते हैं। VictoriaMetrics टाइम‑सीरीज़ डेटा के लिए विशेष रूप से निर्मित संपीड़न का उपयोग करता है, इसलिए वही मेट्रिक्स सामान्य‑उद्देश्य डेटाबेस की तुलना में डिस्क स्पेस का केवल एक अंश लेते हैं। इसके अलावा, हम समान इनजेस्ट दर पर Prometheus की तुलना में RAM पर चार‑पाँच गुना हल्का चलाते हैं, और डिस्क पर दस गुना तक हल्का। जब Grammarly ने अपना प्रूफ़‑ऑफ़‑कॉन्सेप्ट चलाया, तो यह सीधे उनके AWS बिल में दिखा, क्योंकि वे केवल कम डेटा नहीं स्टोर कर रहे थे; वे इसे करने के लिए कम और छोटे इंस्टेंस चला रहे थे।

ऑपरेशनल जटिलता का पहलू भी महत्वपूर्ण है, लेकिन यह अधिक अप्रत्यक्ष है। कई टीमें ऑब्ज़र्वेबिलिटी लागतों की कीमत तय करते समय केवल स्टोरेज और कंप्यूट आइटम्स को देखती हैं और पाँच‑घटक Thanos स्टैक को एकल बाइनरी के मुकाबले चलाने में लगे इंजीनियरिंग घंटों को नजरअंदाज़ करती हैं। यह वास्तविक पैसा है; इसे संख्यात्मक रूप से व्यक्त करना कठिन है।

Prometheus क्लाउड‑नेटिव मॉनिटरिंग का मूलभूत हिस्सा बन गया है, फिर भी कुछ संगठन अंततः स्केलेबिलिटी या ऑपरेशनल सीमाओं का सामना करते हैं। आमतौर पर कौन सी स्थितियाँ कंपनी को पारंपरिक Prometheus डिप्लॉयमेंट से आगे देखने पर मजबूर करती हैं, और कब VictoriaMetrics एक तर्कसंगत विकल्प बन जाता है?

Prometheus उस चीज़ में उत्कृष्ट है जिसके लिए इसे बनाया गया था: एकल-नोड स्क्रैप और अलर्ट इंजन। टीमें आमतौर पर दो तरीकों से बाधा का सामना करती हैं: या तो उनकी कार्डिनैलिटी एकल Prometheus इंस्टेंस की मेमोरी क्षमता से अधिक हो जाती है, या उन्हें कई क्लस्टरों में दीर्घकालिक रिटेंशन और ग्लोबल क्वेरी की आवश्यकता होती है, जिसे Prometheus ने स्वयं के लिए कभी डिजाइन नहीं किया था। यही वह समय है जब लोग Thanos या Cortex जोड़ते हैं, जहाँ आमतौर पर ऑपरेशनल दर्द शुरू होता है। आप एक बाइनरी चलाने से एक वितरित सिस्टम चलाने तक पहुँच जाते हैं, जिसमें एक कंपैक्टर, एक क्वेरीयर, एक स्टोर गेटवे और कई अन्य घटक होते हैं जो सुबह 3 बजे टूट सकते हैं।

VictoriaMetrics अगला तर्कसंगत कदम बन जाता है क्योंकि यह एक ड्रॉप‑इन प्रतिस्थापन है, न कि पुनःआर्किटेक्चर। टीमें अपनी मौजूदा Prometheus स्क्रैप कॉन्फ़िगरेशन को VictoriaMetrics की ओर इंगित करती हैं और सभी Grafana डैशबोर्ड, अलर्ट और रिकॉर्डिंग नियम जिन्हें उन्होंने पहले बनाया है, बरकरार रखती हैं। माइग्रेशन केवल एक कॉन्फ़िगरेशन परिवर्तन है, कोई प्रोजेक्ट नहीं, और वे पाँच नए घटक जोड़े बिना ही स्केलेबिलिटी प्राप्त कर लेते हैं।

हम देख रहे हैं कि इंजीनियरिंग टीमें यह पुनर्विचार कर रही हैं कि क्या उन्हें बड़े, पूरी तरह प्रबंधित ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म की आवश्यकता है या वे ओपन‑सोर्स घटकों से अधिक कुशल स्टैक बना सकते हैं। क्या आप इसे ऑब्ज़र्वेबिलिटी बाजार में एक व्यापक संरचनात्मक बदलाव के रूप में देखते हैं, और ओपन‑सोर्स पारंपरिक मूल्य निर्धारण मॉडल पर कितना दबाव डाल रहा है?

यह संरचनात्मक है; किसी खराब बजट वर्ष की अस्थायी प्रतिक्रिया नहीं। ऑब्ज़र्वेबिलिटी विक्रेताओं ने ऐतिहासिक रूप से इनजेस्ट वॉल्यूम या होस्ट काउंट के आधार पर मूल्य निर्धारण किया है, और यह मॉडल ग्राहक के बढ़ते व्यवसाय के खिलाफ काम करता है। जितनी सफल कंपनी होती है, उतना ही अधिक वह भुगतान करती है, और कीमत का वास्तविक मूल्य प्रदान किए गए मूल्य से कोई संबंध नहीं होता। इंजीनियरिंग टीमें अब स्वयं गणना कर रही हैं, यह समझते हुए कि एक स्वयं‑होस्टेड, कुशल ओपन‑सोर्स स्टैक पूरी तरह से इस समीकरण को बदल देता है। ऐसा इसलिए है क्योंकि लागत उस इन्फ्रास्ट्रक्चर के साथ स्केल करती है जो वास्तव में चलाया जा रहा है, न कि विक्रेता द्वारा नियंत्रित मीटरिंग फ़ॉर्मूला के साथ।

यह मौजूदा मूल्य निर्धारण पर वास्तविक दबाव डालता है। जब कोई टीम अपनी मौजूदा स्क्रैप कॉन्फ़िगरेशन को एक ओपन‑सोर्स विकल्प की ओर इंगित कर सकती है और कार्यक्षमता खोए बिना बिल को 60 से 80 % तक घटा सकती है, तो यह आंतरिक रूप से कठिन चर्चा नहीं होती। जो विक्रेता अभी भी प्रति होस्ट या कस्टम मीट्रिक के आधार पर शुल्क ले रहे हैं, वे उन ग्राहकों को लगातार नुकसान पहुंचाते रहेंगे जो यह गणना नहीं करते।

AI इन्फ्रास्ट्रक्चर समीकरण में एक असामान्य रूप से महँगा नया संसाधन जोड़ता है: GPU। AI प्रशिक्षण या इन्फ़रेंस चलाने वाली कंपनियों को बुनियादी GPU उपयोगिता से आगे क्या मॉनिटर करना चाहिए, और बेहतर ऑब्ज़र्वेबिलिटी कहाँ सीधे AI इन्फ्रास्ट्रक्चर लागत को कम कर सकती है?

केवल GPU उपयोगिता पर्याप्त जानकारी नहीं देती।

आप डैशबोर्ड पर 90 % उपयोगिता देख सकते हैं और मान सकते हैं कि सब ठीक है। लेकिन वास्तव में आप यह जानना चाहते हैं: GPU क्या कर रहा है?

आपको और गहराई से देखना होगा। कौन से CUDA kernels चल रहे हैं? 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 ने क्लाउड प्रोवाइडर्स से राजस्व बचाने के लिए किया। VictoriaMetrics OSS आज Apache 2.0 है, और इसे बदलने की कोई योजना नहीं है।

हम यह तय करने का तरीका सरल है कि क्या ओपन सोर्स रहेगा: कोर इंजन, वह चीज़ जिसे इंजीनियर अपने प्रोडक्शन डेटा के साथ भरोसा करते हैं, ओपन रहता है। हम उन चीज़ों के लिए चार्ज करते हैं जो कंपनी को स्केल पर चलने के बाद किसी उत्तरदायी की आवश्यकता होती है: मल्टी‑टेनेन्सी, एंटरप्राइज़ ऑथेंटिकेशन, कंप्लायंस सपोर्ट, एक CVE SLA और कोड लिखने वाले इंजीनियरों तक सीधे पहुँच, न कि सपोर्ट कतार के माध्यम से। ग्राहक‑फंडेड होने का मतलब यह भी है कि रोडमैप उन चीज़ों से निर्धारित होता है जो लोग प्रोडक्शन में वास्तव में सामना कर रहे हैं, न कि पिच डेक में फंडेबल चीज़ों से।

जैसे-जैसे मीट्रिक्स, लॉग, ट्रेसेस, एआई एप्लिकेशन टेलीमेट्री, GPU मॉनिटरिंग और स्वचालित एनोमली डिटेक्शन अधिकाधिक एकीकृत हो रहे हैं, आप क्या सोचते हैं कि अगले कुछ वर्षों में ऑब्ज़रवबिलिटी स्टैक कैसा दिखेगा, और प्लेटफ़ॉर्म से इंजीनियरिंग टीमें क्या अपेक्षा रखेंगी जो प्रासंगिक बने रहना चाहें?

स्टैक ऑपरेशनल रूप से तब एकीकृत होता है जब वह एकल उत्पाद के रूप में नहीं, और यह अंतर महत्वपूर्ण है। अधिकांश टीमें एक मोनोलिथिक प्लेटफ़ॉर्म नहीं चाहतीं जिसमें एक ही UI सब कुछ लॉक कर दे। वे चाहते हैं कि मीट्रिक्स, लॉग और ट्रेसेस एक ही ऑपरेशनल मॉडल, एक ही विक्रेता और एक ही लाइसेंसिंग कहानी पर चलें, बिना उस क्षमता को छोड़े कि प्रत्येक सिग्नल को स्वतंत्र रूप से चलाया जा सके यदि किसी टीम को उसकी आवश्यकता हो। यही दिशा है जिसमें VictoriaMetrics निर्माण कर रहा है। हम सब कुछ एक ही बाइनरी में जोड़ने की कोशिश नहीं कर रहे हैं। हम यह सुनिश्चित करना चाहते हैं कि तीनों सिग्नल एक ही इंजन और समान दक्षता विशेषताओं को साझा करें, ताकि दूसरा या तीसरा सिग्नल जोड़ने से दूसरा या तीसरा ऑपरेशनल सिरदर्द न आए।

वे प्लेटफ़ॉर्म जो प्रासंगिक रहते हैं, वही हैं जो AI टेलीमेट्री और GPU मॉनिटरिंग को उसी मॉडल में बिना लागत वक्र टूटे समाहित कर सकते हैं। AI वर्कलोड्स ऐसी टेलीमेट्री उत्पन्न करते हैं जिसकी मात्रा के लिए लेगेसी प्रति‑मीट्रिक या प्रति‑होस्ट मूल्य निर्धारण कभी नहीं बनाया गया था। टीमें या तो आवश्यक डेटा एकत्र करना बंद कर देती हैं या उनका ऑब्ज़रवबिलिटी बिल AI निवेश की तुलना में तेज़ी से बढ़ जाता है जिसे वह मॉनिटर कर रहा है। इंजीनियरिंग टीमें यह अपेक्षा रखेंगी कि प्लेटफ़ॉर्म उस मात्रा को उसी तरह संभाले जैसा वे किसी भी इन्फ्रास्ट्रक्चर से स्केलिंग की उम्मीद करते हैं, बिना हर बार वर्कलोड बढ़ने पर उन्हें पुनः आर्किटेक्ट या पुनः बातचीत करने को कहा जाए।

उत्कृष्ट साक्षात्कार के लिए धन्यवाद, जो पाठक अधिक जानना चाहते हैं उन्हें VictoriaMetrics पर जाना चाहिए।