क्रिस्टिन आइज़क, स्ट्रूडल के सीईओ और सह-संस्थापक – साक्षात्कार श्रृंखला

क्रिस्टिन आइज़क, स्ट्रूडल के सीईओ और सह-संस्थापक एक अनुभवी उद्यम प्रौद्योगिकी नेता हैं जिन्होंने लिंक्डइन, यूडेमी, ईएसपीएन और डिज़नी में वरिष्ठ पदों पर कार्य किया है और फिर स्ट्रूडल लॉन्च किया है। वह अब सॉफ्टवेयर संगठनों में सबसे बड़े घर्षण बिंदुओं में से एक को हल करने पर ध्यान केंद्रित कर रही हैं: ग्राहक सहायता और इंजीनियरिंग के बीच की खाई। स्ट्रूडल में, वह एक एआई-ड्राइवन प्लेटफ़ॉर्म बना रही है जो तकनीकी सहायता टीमों को जटिल मुद्दों को तेजी से हल करने में मदद करती है bằng cách सहायता अनुरोधों को सीधे इंजीनियरिंग बुद्धिमत्ता से जोड़ती है। उनकी टीमों को स्केल करने, गो-टू-मार्केट रणनीतियों को बनाने और वैश्विक संगठनों में विकास को बढ़ावा देने का अनुभव स्ट्रूडल की तेजी से शुरुआती गति और उद्यम एआई और डेवलपर टूल्स बाजार में मजबूत स्थिति को आकार देने में मदद करता है।

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

आप लिंक्डइन, यूडेमी और डिज़नी जैसे संगठनों में नेतृत्व की भूमिकाएं रखते हैं और फिर 2025 में स्ट्रूडल की स्थापना की। उन भूमिकाओं से कौन से अनुभव आपको यह महसूस कराते हैं कि इंजीनियरिंग टीमों को एक नए प्रकार के एआई-संचालित “इंजीनियरिंग इंटेलिजेंस” प्लेटफ़ॉर्म की आवश्यकता है, और यह अंतर्दृष्टि स्ट्रूडल की स्थापना को कैसे आकार देती है?

हर कंपनी में एक ही समस्या का एक अलग संस्करण था। डिज़नी में, दांव बहुत बड़े थे – यदि एक स्ट्रीमिंग प्लेटफ़ॉर्म एक प्रमुख लॉन्च के दौरान नीचे चला जाता है, तो यह केवल एक राजस्व हिट नहीं था, यह एक ब्रांड पल था। लिंक्डइन में, स्केल निरंतर था। हज़ारों सेवाएं सभी शोर पैदा कर रही थीं, और यहां तक ​​कि सर्वश्रेष्ठ टीमें इसे बनाए रखने के लिए संघर्ष कर रही थीं। यूडेमी में, मैंने एक पतली टीम को सीमित टूलिंग के साथ नायकत्व करते हुए देखा।

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

मैंने सोचा कि इसमें एक चतुर तरीका होना चाहिए जो वास्तव में क्या मायने रखता है जब यह मायने रखता है। यह वास्तव में स्ट्रूडल का बीज है।

कई कंपनियां डाउनटाइम के वित्तीय प्रभाव को खोए हुए राजस्व या एसएलए दंड के रूप में मापती हैं। आपके अनुभव में, बाहर निकलने के कम दिखाई देने वाले लागत क्या हैं जिन्हें संगठन लगातार कम आंकते हैं?

राजस्व संख्या बोर्ड डेक में जाती है, लेकिन तुरंत राजस्व प्रभाव केवल उस प्रभाव का एक अंश है जो बाहर निकलता है। जिन लोगों को मैंने देखा है कि संगठन लगातार याद करते हैं वे कुछ बकेट में गिरते हैं।

पहला ग्राहक विश्वास है। एसएलए दंड एक कानूनी निर्माण हैं – वे उस ग्राहक को नहीं पकड़ते हैं जो शांति से छोड़ देता है, या जो उद्यम प्रत्याशी ने गलत समय पर अपना स्टेटस पेज देखा और एक प्रतियोगी को चुना। उस नुकसान धीमी, अदृश्य है, और एक तरह से स्थायी है जो एक रिफंड चेक केवल नहीं है।

दूसरा इंजीनियर छोड़ने और जलन है। ऑन-कॉल थकान वास्तविक है। जब आपके सर्वश्रेष्ठ इंजीनियर बार-बार उच्च-तनाव वाली घटनाओं में खींचे जाते हैं – विशेष रूप से उन लोगों को जिन्हें रोका जा सकता था – वे यह पूछना शुरू करते हैं कि क्या यह उनके करियर को बनाने के लिए सही जगह है। एक वरिष्ठ इंजीनियर को बदलना एक से दो गुना उनके वार्षिक वेतन के बीच होता है जब आप भर्ती, ऑनबोर्डिंग और खोए हुए संस्थागत ज्ञान को ध्यान में रखते हैं। कोई भी इसे मरणोपरांत में नहीं डालता है।

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

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

यह उनकी इंजीनियरिंग टीम की क्षमता पर एक कर लगाता है। हर टीम के पास एक सीमित मात्रा में बैंडविथ है, और जब उस बैंडवidth का एक महत्वपूर्ण हिस्सा लगातार घटनाओं में पुनर्निर्देशित किया जाता है, तो उत्पाद विकास पर समग्र प्रभाव गंभीर है। रोडमैप प्रतिबद्धताएं याद की जाती हैं। तकनीकी ऋण का भुगतान नहीं किया जाता है। सुविधाएं कम जोर के साथ शिप की जाती हैं क्योंकि खोए हुए समय की भरपाई के लिए दबाव होता है।

जो विशेष रूप से हानिकारक है वह इसकी अप्रत्याशितता है। एक टीम अपने स्प्रिंट की योजना बना सकती है अच्छी मंशा के साथ, और फिर एक प्रमुख घटना मंगलवार को फट जाती है और सब कुछ द्वितीयक हो जाता है। इस तरह की स्थायी अप्रत्याशितता गहरे काम की संस्कृति का निर्माण करना लगभग असंभव बना देती है – जो अंततः सर्वश्रेष्ठ इंजीनियरिंग परिणामों को चलाता है।

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

स्ट्रूडल ग्राहक सहायता डेटा, लॉग, उत्पादन प्रणाली और कोड रिपॉजिटरी को जोड़ती है ताकि मूल कारणों की पहचान तेजी से की जा सके। पारंपरिक निगरानी उपकरणों के विपरीत एआई इन विभिन्न तकनीकी संकेतों को एक साथ कैसे लाता है?

पारंपरिक निगरानी उपकरण मूल रूप से अलर्ट प्रणाली हैं। वे किसी सीमा को पार करने वाली किसी चीज़ को बताने में बहुत अच्छे हैं – एक देरी स्पाइक, एक त्रुटि दर बढ़ रही है, एक पॉड क्रैश हो रहा है। लेकिन वे डोमेन के पार नहीं सोच सकते हैं।

वे यह नहीं जानते कि आपकी भुगतान सेवा में त्रुटि दर में वृद्धि आपके एक निर्भरता में तैनाती के चार मिनट बाद हुई, और एक ग्राहक सहायता टिकट जिसमें चेकआउट विफलताओं का उल्लेख किया गया था लगभग उसी समय आया, और पिछली बार यह पैटर्न आपके लॉग में दिखाई दिया था छह महीने पहले एक डेटाबेस माइग्रेशन के दौरान।

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

आप स्ट्रूडल को “इंजीनियरिंग इंटेलिजेंस” के रूप में वर्णित करते हैं। यह अवधारणा का क्या अर्थ है और यह पारंपरिक दृश्यता या एआईओपीएस प्लेटफ़ॉर्म से कैसे अलग है?

क्रिस्टिन: दृश्यता मूल रूप से उपकरण और दृश्यता के बारे में है – सुनिश्चित करना कि टेलीमेट्री वहाँ है और टीमें इसे पूछ सकती हैं। एआईओपीएस, इसके अधिकांश वर्तमान कार्यान्वयन में, अलर्ट शोर को कम करने के लिए एमएल-आधारित संबंध और असामान्यता का पता लगाने के बारे में है। दोनों वास्तव में मूल्यवान हैं, और हम उनके साथ एकीकृत करते हैं।

लेकिन इंजीनियरिंग इंटेलिजेंस एक परत ऊपर है। हम जो एआईओपीएस करता है उस पर विस्तार कर रहे हैं। जहां एआईओपीएस आपको बताता है कि कुछ गलत है, इंजीनियरिंग इंटेलिजेंस आपको बताता है कि यह गलत क्यों है, यह कहां से शुरू हुआ, और इसके बारे में क्या करना है – आपके पूरे स्टैक के संकेतों को खींचते हुए, जिसमें पारंपरिक एआईओपीएस टूल देखते हैं उन लोगों को छोड़कर, जैसे ग्राहक सहायता टिकट या कोड परिवर्तन। लक्ष्य केवल शोर को कम करना नहीं है। यह आपकी टीम को एक पूर्ण, कार्रवाई योग्य चित्र देना है ताकि वे समस्या को तेजी से हल कर सकें और निर्माण में वापस जा सकें।

इसे एक स्मोक डिटेक्टर और एक आग जांचकर्ता के बीच के अंतर के रूप में सोचें। दृश्यता और एआईओपीएस स्मोक डिटेक्टर हैं – आवश्यक, लेकिन वे अलार्म पर रुक जाते हैं। इंजीनियरिंग इंटेलिजेंस वह है जो उसके बाद आता है: यह क्या हुआ, यह क्यों हुआ, यह कहां से शुरू हुआ।

एआई एजेंटों को जटिल तकनीकी कार्यों को स्वचालित करने के लिए तेजी से तैनात किया जा रहा है। अगले पांच वर्षों में, सॉफ्टवेयर घटनाओं का निदान और समाधान करने में एआई एजेंटों की भूमिका क्या होगी?

मुझे लगता है कि अधिक दिलचस्प प्रश्न यह नहीं है कि एजेंट क्या करेंगे – यह है कि इंजीनियर क्या बंद कर देंगे। सर्वश्रेष्ठ इंजीनियर जिन्हें मैंने काम किया है उन्होंने रात के बीच में अलर्ट को ट्राइएज करने या लॉग के माध्यम से एक कॉन्फ़िगरेशन परिवर्तन की तलाश करने के लिए अपने जीवन में नहीं मिला है। यही कारण है कि वे अपने काम में अच्छे हैं।

अगले पांच वर्षों में, मुझे लगता है कि एजेंट उस पीस को लेते हैं – पुनरावृत्ति, पैटर्न-मिलान, संदर्भ-विधानसभा का काम जो महत्वपूर्ण है लेकिन जहां वरिष्ठ इंजीनियरिंग प्रतिभा को खर्च नहीं किया जाना चाहिए। वहां से मुक्त होने से लोगों को जटिल समस्याओं, वास्तुकला निर्णयों, चीजों पर ध्यान केंद्रित करने की अनुमति मिलती है जो वास्तव में मानव निर्णय लेने की आवश्यकता होती है।

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

बाहर निकलने का स्रोत अक्सर छोटे बग या कॉन्फ़िगरेशन परिवर्तन होते हैं जो परीक्षण से गुजर जाते हैं। एआई सिस्टम कोड, लॉग या बुनियादी ढांचे के संकेतों में सूक्ष्म पैटर्न की पहचान करने के लिए कैसे बड़ी घटनाओं को रोकने के लिए पर्याप्त जल्दी हो सकते हैं?

सावधानी से तैयार किए गए एआई के पास यहाँ एक वास्तविक लाभ है, और यह यह नहीं है कि यह आपके इंजीनियरों से चतुर है – यह है कि यह कभी भी भूलता नहीं है और कभी सोता नहीं है। एक मानव आज एक सूक्ष्म लॉग पैटर्न को छह महीने पहले एक अलग हिस्से में हुई किसी चीज़ से जोड़ सकता है। एआई कर सकता है। यह सब कुछ देख रहा है, हर समय, और इसकी एक बहुत लंबी और व्यापक स्मृति है जितनी कि आपकी टीम में किसी भी व्यक्ति की है।

हालांकि, जो कुछ हम ग्राहकों से बहुत सुनते हैं वह यह है: रोकथाम केवल तभी अच्छी है जब नीचे का डेटा है। यदि आपके लॉग असंगत, अधूरे या एक दर्जन उपकरणों में विभाजित हैं जो एक दूसरे से बात नहीं करते हैं, तो एआई एक खंडित चित्र के साथ काम कर रहा है। कचरा में, कचरा बाहर – यह अभी भी सच है। हम ग्राहकों के साथ बहुत समय बिताते हैं ताकि वे डेटा गुणवत्ता और उपकरणों के बारे में सोच सकें।

तो उत्तर दोनों है: हाँ, एआई पहले से ही पकड़ सकता है और मानवों को याद दिला सकता है। लेकिन जो टीमें इसका सबसे अधिक मूल्य प्राप्त करती हैं वे वे हैं जिन्होंने यह काम किया है कि उनका डेटा वास्तव में तर्कसंगत होने लायक है।

कंपनियां अक्सर पता लगाने वाले उपकरणों में भारी निवेश करती हैं लेकिन फिर भी माध्य समय तक समाधान करने में संघर्ष करती हैं। संगठनों को घटना का पता लगाने और वास्तविक मूल कारण के समाधान के बीच की खाई को बंद करने से रोकने वाली सबसे बड़ी बाधाएं क्या हैं?

पता लगाना मूल रूप से एक हल किया गया समस्या है। अधिकांश टीमों के पास अलर्ट हैं। वे जानते हैं कि कुछ गलत है। अंतर यह है कि घटना के बाद क्या होता है।

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

उत्पादन डेटा, कोडबेस और संचालन लॉग का विश्लेषण करते समय एआई सिस्टम को तैनात करते समय इंजीनियरिंग टीमों को किन शासन या सुरक्षा विचारों पर विचार करना चाहिए?

मैं जिस बात पर सबसे ज्यादा जोर देता हूं वह यह है: मानवों को अभी भी उत्पादन में जाने वाले कोड की समीक्षा करनी चाहिए।

मैंने कई इंजीनियरों से इस बारे में बात की है, और एक बात जो मैं बार-बार सुनता हूं वह यह है कि एआई कुशलता से और चतुराई से बग लिखता है। वास्तव में चतुराई से, वास्तव में। एक तरह से जो वास्तव में पकड़ना मुश्किल हो सकता है – यहां तक ​​कि वरिष्ठ इंजीनियरों के लिए भी जो कोड की समीक्षा कर रहे हैं। बग हमेशा स्पष्ट नहीं होते हैं। वे एक नज़र में पूरी तरह से तर्कसंगत दिख सकते हैं।

ईमानदारी से? यह एक कारण है कि मुझे लगता है कि स्ट्रूडल के लिए मामला समय के साथ और भी मजबूत होता जाता है। यदि अधिक बग उत्पादन में बने रहते हैं, तो उन्हें तेजी से खोजने और हल करने की क्षमता और भी महत्वपूर्ण हो जाती है। शासन प्रश्न न केवल डेटा एक्सेस नियंत्रण और अनुमतियों के बारे में है – हालांकि वे महत्वपूर्ण हैं और टीमों को उनके बारे में सावधानी से सोचना चाहिए। यह उत्पादन को छूने वाली किसी भी चीज़ के आसपास मानवों को सही जांच-बिंदुओं पर रखने के बारे में है।

आगे देखते हुए, क्या आप सोचते हैं कि विश्वसनीयता इंजीनियरिंग का भविष्य एआई-पहले बुनियादी ढांचे की ओर बढ़ेगा, जहां स्वायत्त प्रणाली निगरानी करती हैं, निदान करती हैं और यहां तक ​​कि मानव जागरूकता से पहले मुद्दों को हल करती हैं? यदि ऐसा है, तो इंजीनियरों के लिए क्या कार्य प्रवाह दिखता है?

मुझे लगता है कि हम उस दिशा में जा रहे हैं, लेकिन मैं समयसीमा के बारे में व्यावहारिक हूं। पूरी तरह से स्वायत्त प्रणाली जो उत्पादन घटनाओं को मानव जागरूकता के बिना हल करती हैं – यह वह नहीं है जहां हम हैं, और मुझे लगता है कि यह अगले कुछ वर्षों में नहीं होगा। और मुझे लगता है कि यह ठीक है।

मैं जो भविष्य देखता हूं वह यह है कि लूप बहुत तंग और बहुत कम दर्दनाक हो जाता है। भविष्य जो मैं उत्साहित हूं वह नहीं है जहां मानवों को समीकरण से हटा दिया जाता है – यह है जहां मानवों को प्रक्रिया में एकीकृत किया जाता है जो वास्तव में उन्हें आवश्यक बनाता है। निर्णय। नए स्थितियां। एक घटना जिसे आपने पहले नहीं देखा है। एआई पैटर्न-मिलान, संदर्भ-विधानसभा, नियमित त्रुटि को संभालता है। इंजीनियर निर्णय लेते हैं।

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

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