Skip to content
AV
Contact
Tech

मेरा स्कीमा माइग्रेशन यह जांचे बिना क्यों चलता है कि डिप्लॉय की गई सेवाएं उसे झेल पाएंगी?

83

अवसर

जब आप किसी प्रोडक्शन डेटाबेस में स्कीमा बदलाव पुश करते हैं, तो माइग्रेशन उससे पहले ही चल जाता है कि कोई टूल यह जांचे कि फिलहाल चल रहे सेवा संस्करण नई शेप को पढ़-लिख सकते हैं। कोई छूटा हुआ कॉलम या बदला हुआ फील्ड डेटाबेस तक तब पहुंच जाता है जब पुराने पॉड्स अभी ड्रेन हो रहे होते हैं, और रोलबैक स्कीमा तो बहाल कर देता है लेकिन नए संस्करण द्वारा इस बीच लिखे गए डेटा को नहीं। ORM टूल्स डिफ से SQL जनरेट करते हैं लेकिन डिप्लॉयमेंट टोपोलॉजी, एक साथ चल रहे सेवा संस्करणों या लाइव रीड-राइट पैटर्न के बारे में कुछ नहीं मॉडल करते। टीमें विकी और परंपरागत ज्ञान में दर्ज expand-contract रिचुअल से काम चलाती हैं, न कि टूलिंग द्वारा लागू किए गए तरीके से। एक गलत क्रमित कदम ने मल्टी-सर्विस कैस्केडिंग फेलियर और पिछले वर्ष अकेले $4.5 मिलियन का दस्तावेज किया गया इंसिडेंट पैदा किया।

यह क्यों मायने रखता है

एक प्री-फ्लाइट कम्पैटिबिलिटी चेक जो आपकी लाइव सर्विस टोपोलॉजी को मॉडल करे, डिप्लॉयमेंट के सबसे जोखिम भरे कदम को ऐसी चीज में बदल देगी जिसके बारे में आप apply दबाने से पहले ठीक से सोच सकते हैं।

मैं अवसर को कैसे आंकता हूं

Opportunity Score मेरा अपना आकलन है, कोई माप नहीं: यह कितना तकलीफदेह है, कितनी बार परेशान करता है, और आज इसे हल करने के लिए कितना कम मौजूद है। जितना ज़्यादा स्कोर, उतना ज़्यादा मुझे लगता है कि इसे बनाना सार्थक है।

गंभीरता9/10

जब यह सामने आता है तो कितनी तकलीफ देता है।

आवृत्ति8/10

लोग वास्तव में कितनी बार इससे टकराते हैं।

व्हाइटस्पेस7/10

आज इसके लिए कितने कम अच्छे टूल मौजूद हैं।

और हल करने लायक समस्याएं