स्टैंडअप से पहले पूरा, स्वचालित एरर ट्रायेज

Okou एक AI DevOps एजेंट है जो रोज़ाना एरर ट्रायेज को ऑटोमेट करता है। हर सुबह यह Sentry और Axiom से अनसुलझे एरर खींचता है, दोनों स्रोतों में उन्हें डीडुप्लिकेट करता है, और स्टैंडअप से पहले पूरे स्टैक ट्रेस के साथ असाइन किए गए GitHub issues दर्ज करता है, जिससे इंजीनियरों के 20 से 30 मिनट की मैनुअल समीक्षा बचती है।

Okou जुड़ता है:SentryAxiomGitHub

एरर ट्रायेज क्या है?

एरर ट्रायेज, जिसे bug triage या incident triage भी कहा जाता है, प्रोडक्शन एरर को समूहबद्ध करने, प्राथमिकता देने, और असाइन करने की प्रक्रिया है ताकि इंजीनियरों को पता हो कि पहले क्या ठीक करना है। Okou, Sentry, Axiom, और GitHub में एक AI SRE एजेंट की तरह काम करता है: यह एरर डीडुप्लिकेट करता है, थ्रेशोल्ड लागू करता है, स्टैक ट्रेस अटैच करता है, और कोड मालिकों को असाइन करता है। नतीजा कम अलर्ट थकान वाला एक सुसंगत रोज़ाना एरर ट्रायेज ऑटोमेशन है।

मैनुअल एरर ट्रायेज अलर्ट थकान क्यों पैदा करता है

हर सुबह, किसी इंजीनियर को Sentry खोलना पड़ता है, अनसुलझे Sentry अलर्ट स्कैन करने पड़ते हैं, Axiom से क्रॉस-चेक करना पड़ता है, यह पहचानना पड़ता है कि क्या नया है या डुप्लिकेट है, तय करना पड़ता है कि क्या गंभीर है, GitHub issues खोलनी पड़ती हैं, और सही मालिक ढूँढना पड़ता है। यह दोहराव वाला पहला दौर 20 से 30 मिनट का केंद्रित इंजीनियरिंग समय खर्च करता है और असली काम शुरू होने से पहले ही अलर्ट थकान पैदा करता है। Okou सुबह 8:45 बजे चलता है और किसी के लैपटॉप खोलने से पहले वही ट्रायेज पूरा कर देता है।

Okou रोज़ाना एरर ट्रायेज को कैसे ऑटोमेट करता है

चरण 1: अपने tools कनेक्ट करें

Sentry
Sentry
ज़रूरी
Okou का Sentry इंटीग्रेशन अनसुलझे प्रोडक्शन एरर, स्टैक ट्रेस, इवेंट गिनती, और environment टैग को क्वेरी करता है।
जोड़ें
GitHub
GitHub
ज़रूरी
Sentry GitHub इंटीग्रेशन पूरे एरर विवरण के साथ संरचित issues दर्ज करता है और उन्हें कोड मालिकों को असाइन करता है।
जोड़ें
Axiom
Axiom
वैकल्पिक
Okou, Sentry के निष्कर्षों के साथ क्रॉस-रेफरेंस और डीडुप्लिकेट करने के लिए एरर लॉग हेतु Axiom को क्वेरी करता है। वैकल्पिक लेकिन सुझाया गया।
जोड़ें

चरण 2: Okou से पूछें

Okou, Sentry और Axiom से अनसुलझे एरर खींचता है
Okou, आपकी तय की गई समय विंडो के भीतर अनसुलझे एरर के लिए Sentry और Axiom दोनों को क्वेरी करता है, फिर आपका occurrence threshold लागू करता है ताकि कम-सिग्नल वाला शोर छन जाए और सिर्फ़ बड़े पैमाने पर हो रहे एरर ही आगे आएं।
डुप्लिकेट एरर Sentry और Axiom में मर्ज होते हैं
एक ही एरर अक्सर Sentry और Axiom दोनों में अलग-अलग फ़ॉर्मैटिंग के साथ दिखता है। Okou उन्हें एक ही रिकॉर्ड में डीडुप्लिकेट करता है जो दोनों स्रोतों का डेटा जोड़ता है, ताकि आप हर असली समस्या का ट्रायेज एक ही बार करें।
GitHub issues दर्ज होकर कोड मालिकों को असाइन होते हैं
हर अनोखे, योग्य एरर के लिए, Okou पूरे स्टैक ट्रेस, occurrence गिनती, और पहली व आख़िरी बार दिखने के टाइमस्टैम्प के साथ एक संरचित GitHub issue खोलता है, फिर इसे उस इंजीनियर को असाइन करता है जो कोड के उस हिस्से का मालिक है — Sentry-से-GitHub हैंडऑफ़, सिरे से सिरे तक स्वचालित।

चरण 3: इसे और आगे ले जाएँ

थ्रेशोल्ड समायोजित करें
शोर कम करने या ज़्यादा issues पकड़ने के लिए occurrence फ़िल्टर बदलें।
इसे अपने सुबह के ब्रीफ़ में जोड़ें
एरर ट्रायेज को उस प्रोडक्ट हेल्थ ब्रीफ़िंग में मिलाएं जिसे आपकी टीम पहले से पढ़ती है।
डिप्लॉय के बाद सुरक्षा जांच
प्रोडक्शन डिप्लॉय के तुरंत बाद ट्रायेज चलाएं ताकि रिग्रेशन अगली सुबह नहीं बल्कि कुछ ही मिनटों में सामने आ जाएं।

एरर ट्रायेज के लिए Sentry, GitHub और Axiom इंटीग्रेशन

यह वर्कफ़्लो बीच में एक एजेंट के साथ चलने वाला Sentry-GitHub इंटीग्रेशन है: Okou Sentry से पढ़ता है, उसी समय-सीमा को Axiom में मिलाकर देखता है, और GitHub में लिखता है। हर कनेक्टर अलग से अनुमति लेता है और सिर्फ़ उतने तक सीमित रहता है जितना वर्कफ़्लो सचमुच इस्तेमाल करता है, इसलिए आपके एरर डेटा तक पढ़ने की पहुँच का मतलब कभी भी आपकी रिपॉज़िटरी में लिखने की पहुँच नहीं होता।

Sentry

Sentry इंटीग्रेशन: Okou कौन-से एरर पढ़ता है

ज़रूरी

Okou आपकी Sentry एरर ट्रैकिंग को issues API के ज़रिए पढ़ता है और आपके बताए हुए एनवायरनमेंट में अनसुलझे एरर की क्वेरी करता है, जो फ़्रीक्वेंसी के क्रम में आते हैं। हर एरर के लिए वह शीर्षक और culprit, इवेंट की संख्या और प्रभावित यूज़र, लेवल, तथा पहली और आख़िरी बार दिखने का समय पढ़ता है, फिर पूरा स्टैक ट्रेस और उसके रिलीज़ व एनवायरनमेंट टैग पाने के लिए सबसे नया इवेंट लाता है। ट्रायेज के फ़ैसले के लिए जो चाहिए वह इससे पूरा हो जाता है: क्या टूटा, कितनी बार, कहाँ और कब से। इस वर्कफ़्लो में Sentry इंटीग्रेशन सिर्फ़ पढ़ने के लिए है। Okou आपके Sentry issues को न हल करता है, न मर्ज करता है, न दोबारा असाइन करता है; वह जो रिकॉर्ड लिखता है वह GitHub में जाता है।

GitHub

GitHub इंटीग्रेशन: Okou कौन-से issues बनाता है

ज़रूरी

आपकी तय सीमा पार करने वाला हर एरर उस रिपॉज़िटरी में GitHub issue बन जाता है जो आप Okou को बताते हैं। उस issue में एरर का शीर्षक, स्टैक ट्रेस, कितनी बार हुआ और कितने यूज़र प्रभावित हुए, पहली और आख़िरी बार दिखने का समय, और Sentry issue का लिंक होता है ताकि मूल डेटा एक क्लिक दूर रहे। Okou आपके बताए लेबल लगाता है और स्टैक ट्रेस में आई फ़ाइलों के code owner को असाइन करता है। लिखने की पहुँच सिर्फ़ उन्हीं रिपॉज़िटरी तक सीमित है जिनकी आप अनुमति देते हैं, और issue बनाने के अलावा वह कुछ नहीं करता: न कमिट, न पुल रिक्वेस्ट, न रिपॉज़िटरी सेटिंग्स।

Axiom

Axiom इंटीग्रेशन: Okou कौन-से Axiom लॉग मिलाता है

वैकल्पिक

Axiom वैकल्पिक है और डीडुप्लिकेशन में अपनी जगह बनाता है। अगर आपका लॉग मैनेजमेंट पहले से Axiom पर है, तो Okou उसे उसी पास में पढ़ लेता है: वह आपके चुने डेटासेट पर APL क्वेरी चलाता है, वही समय-सीमा रखते हुए जो Sentry से पढ़ने में इस्तेमाल हुई, और उन Axiom लॉग को पहले से मौजूद एरर सिग्नेचर से मिलाता है। इससे वह मामला पकड़ में आता है जहाँ एक ही ख़राबी अलग-अलग फ़ॉर्मैट में दो बार दिखती है, और साथ में रिक्वेस्ट-स्तर का वह संदर्भ जुड़ता है जो अकेला Sentry इवेंट नहीं देता। Axiom के बिना भी वर्कफ़्लो पूरा चलता है, और तब डीडुप्लिकेशन सिर्फ़ Sentry के डेटा पर टिकता है।

Okou बनाम मैनुअल ट्रायेज बनाम Sentry अलर्ट नियम

रोज़ाना एरर ट्रायेज स्वचालित incident response की पहली परत है। टीमें Okou के साथ Sentry से GitHub तक ऑटोमेट करती हैं, और किसी समस्या के व्यापक AI incident management की ज़रूरत पड़ने से पहले ही दोहराव वाला पहला दौर पूरा कर लेती हैं।

मैनुअल ट्रायेज

एक इंजीनियर Sentry और Axiom की समीक्षा करता है, डुप्लिकेट पहचानता है, गंभीरता तय करता है, issues खोलता है, और एक मालिक ढूँढता है। यह लचीला है, पर हर सुबह वही 20 से 30 मिनट का काम दोहराता है।

Sentry अलर्ट नियम

थ्रेशोल्ड पार होने पर नियम टीम को सूचित करते हैं। ये पहचान के लिए उपयोगी हैं, पर टीम को अब भी लॉग को सहसंबंधित करना, एरर डीडुप्लिकेट करना, GitHub issues बनाना, और मालिक असाइन करना पड़ता है।

Okou का Sentry वर्कफ़्लो ऑटोमेशन

Okou, Sentry ऑटोमेशन को सिरे से सिरे तक चलाता है: क्वेरी, क्रॉस-स्रोत डीडुप्लिकेशन, थ्रेशोल्डिंग, issue बनाना, स्टैक-ट्रेस अटैचमेंट, और कोड-मालिक असाइनमेंट। मांग-पर और डिप्लॉय-के-बाद के रन उसी वर्कफ़्लो का इस्तेमाल करते हैं।

बेहतर परिणामों के लिए सुझाव

issue गिनती को संभालने योग्य रखने के लिए एक occurrence threshold सेट करें। 5+ एक अच्छी शुरुआत है; अपने वॉल्यूम के आधार पर समायोजित करें।
Okou की क्वेरी को Sentry environments या प्रोजेक्ट टैग का इस्तेमाल करके production तक सीमित करें, ताकि staging एरर कभी ट्रायेज कतार तक न पहुँचें।
रोज़ाना ट्रायेज को डिप्लॉय के बाद की जांचों के साथ चेन करें ताकि एक दिनचर्या हल्के-फुल्के स्वचालित incident response में बदल जाए, और इसे 9:00 की प्रोडक्ट हेल्थ ब्रीफ़ के साथ जोड़ें ताकि टीम एरर और स्थिति एक ही जगह देखे।

अक्सर पूछे जाने वाले सवाल

Sentry एरर का ट्रायेज करके उन्हें GitHub issues में कैसे बदलें?

Sentry से अपने आप GitHub issues बनाने के लिए, Sentry और GitHub को Okou से जोड़ें, फिर इसे एक शेड्यूल या मांग-पर प्रॉम्प्ट दें। Okou अनसुलझे एरर को क्वेरी करता है, occurrence और environment फ़िल्टर लागू करता है, हर योग्य एरर के लिए एक issue बनाता है, स्टैक ट्रेस और टाइमस्टैम्प अटैच करता है, और एक कोड मालिक को असाइन करता है।

Sentry और Axiom में एरर को कैसे डीडुप्लिकेट करें?

हाँ। Okou, Sentry और Axiom में एरर सिग्नेचर, स्टैक ट्रेस, संदेश, और समय की तुलना करता है, फिर मिलती-जुलती घटनाओं को एक ही ट्रायेज रिकॉर्ड में मर्ज करता है। हर अंतर्निहित स्रोत जांच के लिए लिंक बना रहता है।

एरर मॉनिटरिंग से होने वाली अलर्ट थकान को कैसे कम करें?

ट्रायेज को production तक सीमित करें, एक occurrence threshold सेट करें, विभिन्न टूल में एक ही एरर को डीडुप्लिकेट करें, और issue बनाने के बजाय कम-वॉल्यूम एरर को एक सारांश में भेजें। इससे कतार उन्हीं एरर पर केंद्रित रहती है जिन पर कार्रवाई ज़रूरी है।

क्या Okou हर डिप्लॉय के बाद एरर ट्रायेज चला सकता है?

हाँ। एक ऐसा ऑटोमेशन बनाएं जो डिप्लॉय या main में मर्ज के बाद एरर ट्रायेज वर्कफ़्लो शुरू करे, वैकल्पिक रूप से एक छोटी अवलोकन विंडो का इंतज़ार करे, फिर नए प्रोडक्शन एरर के लिए Sentry जांचे और योग्य issues दर्ज करे।

एरर ट्रायेज ऑटोमेशन को किन टूल की ज़रूरत होती है?

Sentry और GitHub आवश्यक हैं: Sentry एरर डेटा देता है और GitHub असाइन किए गए issues प्राप्त करता है। Axiom वैकल्पिक है, पर यह लॉग संदर्भ जोड़ता है और क्रॉस-स्रोत डीडुप्लिकेशन को बेहतर बनाता है।

Sentry-GitHub इंटीग्रेशन को कौन-सी अनुमतियाँ चाहिए?

Sentry को उन प्रोजेक्ट्स के issues और इवेंट पर पढ़ने की पहुँच चाहिए जिनका आप ट्रायेज करते हैं। GitHub को उन रिपॉज़िटरी में issue लिखने की अनुमति चाहिए जिन्हें issues मिलने हैं। Axiom का इस्तेमाल करें तो उसे बताए गए डेटासेट पर क्वेरी की पहुँच चाहिए। हर कनेक्टर की अनुमति Okou में अलग से दी जाती है, और एक को वापस लेने पर बाक़ी वैसे ही बने रहते हैं।

क्या Okou एक से ज़्यादा GitHub रिपॉज़िटरी में issues बना सकता है?

हाँ। बता दीजिए कि कौन-सी सेवा या प्रोजेक्ट किस रिपॉज़िटरी से जुड़ी है, Okou उसी के हिसाब से हर issue भेजेगा: फ़्रंटएंड के एरर आपके वेब रिपॉज़िटरी में और API के एरर बैकएंड वाले में। यह मैपिंग प्रॉम्प्ट में रहती है, इसलिए GitHub कनेक्टर को दोबारा सेट किए बिना आप इसे बदल सकते हैं।

क्या Okou Sentry में कुछ बदलता है?

नहीं। यहाँ Sentry इंटीग्रेशन सिर्फ़ पढ़ने के लिए है: Okou issues और इवेंट की क्वेरी करता है और वापस कुछ नहीं लिखता। आपके issue की स्थिति, असाइनमेंट और समाधान का इतिहास ठीक वैसे ही रहते हैं जैसे आपकी टीम ने छोड़े थे। Okou सिर्फ़ GitHub issue बनाता है।

अपना पहला Sentry ट्रायेज चलाएं

Sentry, GitHub, और वैकल्पिक रूप से Axiom को जोड़ें। उसी रोज़ाना ट्रायेज प्रॉम्प्ट का इस्तेमाल करके वर्कफ़्लो को हाथ से दोबारा बनाए बिना काम करते देखें।

Help me with: स्टैंडअप से पहले पूरा, स्वचालित एरर ट्रायेज