क्या डेवलपर्स को उत्पादन डेटाबेस को क्वेरी करने में सक्षम होना चाहिए?


162

क्या डेवलपर्स को SELECTउत्पादन डेटाबेस को क्वेरी ( / केवल पढ़ने) की अनुमति दी जानी चाहिए ? पिछली जगह मैंने काम किया, विकास टीम की db_datareaderभूमिका थी; जहां मैं अब काम करता हूं, वहां विकास टीम भी उत्पादन के उदाहरण से नहीं जुड़ सकती है।

परीक्षण उदाहरणों में से एक एक सप्ताह में एक बार उत्पादन बैकअप से बहाल उत्पादन की एक प्रति है, इसलिए डेवलपर्स को वास्तव में डेटा देखने के साथ कोई समस्या नहीं है।

डेवलपर्स को क्वेरी उत्पादन की अनुमति नहीं देने के लिए क्या अच्छे कारण हैं (केवल संवेदनशील डेटा को पढ़ने के लिए उपयोग करने के लिए नहीं चाहते हैं) को छोड़कर?


25
सबसे पहले, हमें बताएं कि डेवलपर्स उत्पादन से क्यों जुड़ना चाहते हैं।
निक चामास

6
मैं एक प्रोडक्शन मुद्दे की जांच करने की कोशिश कर रहा हूं। संबंधित डेटा आज उत्पादन में लोड किया गया था और अभी तक परीक्षण उदाहरण (जहां मेरी पहुंच नहीं है) में है।
टॉम हंटर

जवाबों:


152

यह वास्तव में इस बात पर निर्भर करता है कि डेवलपर के पास कोई समर्थन जिम्मेदारियां हैं या नहीं। यदि वे तीसरी पंक्ति के समर्थन के लिए हुक पर हैं तो उन्हें ऐसा करने के लिए संभवतः उत्पादन डेटाबेस को देखना होगा।

आम तौर पर यह एक प्रोडक्शन सर्वर पर कुछ भी करने के लिए एक बुरा विचार है जब तक कि यह वास्तव में वहां करने के लिए आवश्यक नहीं है।

अधिकांश विकास उद्देश्यों के लिए, उत्पादन डेटाबेस के दर्पण या स्नैपशॉट पर्याप्त होंगे, और संभवतः लाइव उत्पादन डेटाबेस से बेहतर होगा। यदि आप एकीकरण से संबंधित कुछ भी कर रहे हैं तो आप स्थिर डेटाबेस वातावरण चाहते हैं जहां आप नियंत्रित कर सकते हैं कि उनमें क्या है। सामंजस्य से संबंधित कुछ भी समय में एक नियंत्रित बिंदु को देखने की क्षमता की आवश्यकता होगी।

यदि समस्या यह है कि आपके पास उत्पादन दर्पण वातावरण या किसी भी तरह से अपने डेवलपर्स के लिए उत्पादन डेटा की एक प्रति डालने का कोई साधन नहीं है, तो यह एक अलग सवाल है। उस स्थिति में आपके डेवलपर्स को वास्तव में कम से कम एक दर्पण वातावरण की आवश्यकता होती है। यदि आप यह नहीं देख सकते हैं कि डेटा में क्या समस्या है तो इसका निवारण करना कठिन है।


57
Generally it's a bad idea to do anything on a production server unless it's really necessary to do it there.सबूत के बोझ के लिए +1 (बोलने के लिए) पहुंच देने के औचित्य पर होना चाहिए, इससे इनकार करने का कोई औचित्य नहीं है।
जेएनके

135

नहीं।

डेवलपर्स के पास निम्न कारणों से उत्पादन डेटाबेस सिस्टम तक पहुंच नहीं होनी चाहिए :

  1. उपलब्धता और प्रदर्शन : किसी डेटाबेस के लिए केवल-पढ़ने का अधिकार होना हानिरहित नहीं है । एक खराब लिखित प्रश्न यह कर सकता है:

    1. अन्य महत्वपूर्ण प्रक्रियाओं को अवरुद्ध करते हुए तालिकाओं को बंद करें।
    2. अपने डेटा कैश को ट्रैश करें, डिस्क से डेटा को फिर से पढ़ने के लिए अन्य प्रक्रियाओं को मजबूर करें।
    3. अपनी भंडारण परत को टैक्स दें, जो उस भंडारण को साझा करने वाली अन्य सेवाओं को प्रभावित करती है।
  2. सुरक्षा : आपके उत्पादन डेटाबेस में संवेदनशील जानकारी हो सकती है जैसे:

    • पासवर्ड हैश
    • बिलिंग जानकारी
    • अन्य व्यक्तिगत रूप से पहचान योग्य जानकारी

    केवल वे लोग जिन्हें इस जानकारी तक पहुंच की आवश्यकता है, उनके पास यह होना चाहिए। एक सुव्यवस्थित कंपनी में, डेवलपर्स उन लोगों में से नहीं हैं। इसके अलावा, आपकी कंपनी पीसीआई और एसओएक्स अनुपालन को विफल कर देगी यदि इसके डेवलपर्स इस डेटा के साथ उत्पादन प्रणालियों का उपयोग कर सकते हैं।

    इसके कारण स्पष्ट हैं। एक डेवलपर का विकास कार्य कई हाथों से गुजरता है इससे पहले कि वह जीवित हो जाए। अपने उत्पादन डेटा को चुराने या अपने डेटाबेस को अपने घुटनों पर लाने से प्रत्यक्ष उत्पादन पहुंच के साथ एक दुर्भावनापूर्ण डेवलपर को रोकने के लिए क्या है?

    "लेकिन वह डीबीए के लिए भी जाता है! वे ऐसा कर सकते थे!" ठीक ठीक। आप के रूप में कुछ सुपरयुजर चाहते हैं जिम्मेदारी से संभव है।

हाँ।

डेवलपर्स के पास उत्पादन प्रणालियों तक पहुंच होनी चाहिए

मेरी कंपनी में हमारे पास चार टीमें हैं जो उत्पादन डेटाबेस से संबंधित हैं। वो हैं:

  1. डेवलपर्स , जो डेटाबेस के लिए स्कीमा और कोड को डिज़ाइन और लिखते हैं। उत्पादन में डेटाबेस तक उनकी पहुंच नहीं है। वे, हालांकि, कभी-कभी प्रशासकों या सहायता लोगों के साथ बैठते हैं और उन्हें लाइव में कुछ देखने में मदद करते हैं।
  2. व्यवस्थापक , जो उत्पादन में डेटाबेस की तैनाती, निगरानी और प्रबंधन करते हैं।
  3. लोगों का समर्थन करें , जो समय-संवेदनशील उत्पादन समस्याओं की जांच करते हैं और डेवलपर्स को प्रतिक्रिया प्रदान करते हैं ताकि वे सुधार विकसित कर सकें।
  4. बिजनेस इंटेलिजेंस लोग , जो उन डेटाबेस की नियमित रूप से ताज़ा प्रतियां या सावधानीपूर्वक लिखित और क्यूए-एड अर्क (आमतौर पर प्रशासकों द्वारा डिज़ाइन किए गए) का उपयोग करके प्रोडक्शंस डेटाबेस से डेटा निकालते हैं।

जब आप इन अन्य समूहों में कुछ कमियां हैं, तो अपने डेवलपर्स उत्पादन पहुंच प्रदान करना उचित है।

उदाहरण के लिए:

  • आपके पास कोई सपोर्ट टीम नहीं है। उस समय-संवेदनशील उत्पादन समस्या को डीबग करने के लिए किसे पता होना चाहिए? आपके डेवलपर्स। उन्हें " ग्लास तोड़ो " एक्सेस प्रदान करें।
  • आपके पास कोई बीआई टीम नहीं है। रिपोर्ट या अर्क के साथ आपके प्रवेश करने या करने के लिए कुछ भी नहीं करना चाहते हैं। हर सुबह आपकी रिपोर्ट देखने वाली रिपोर्ट का निवारण कौन करता है? आपके डेवलपर्स। इन रिपोर्ट और अर्क को डीबग करने के लिए उन्हें सीमित पहुंच प्रदान करें।
  • आपके पास कोई व्यवस्थापक टीम नहीं है। आप एक बहुत छोटी या स्टार्टअप कंपनी में हैं, इसलिए "आकस्मिक DBA" को नमस्ते कहें। आपके डेवलपर्स आपके प्रशासक के रूप में दोगुना हो जाते हैं, और इस प्रकार उत्पादन के लिए पूर्ण पहुंच की आवश्यकता होती है।

78

प्रदर्शन एक बड़ा कारण होगा।

सिर्फ इसलिए कि वे डेटा को बदल नहीं सकते हैं इसका मतलब यह नहीं है कि वे सर्वर को प्रभावित नहीं कर सकते हैं। खराब लिखित क्वेरी उत्पादन वातावरण को अपने घुटनों तक ले जा सकती है, और संभावित रूप से अन्य मुद्दों (जैसे टेम्पर्ड ओवरफ्लो) का कारण बन सकती है:

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

वह आपदा का नुस्खा है। ध्यान दें कि यह एक कार्टेशियन उत्पाद है जिसके द्वारा ऑर्डर दिया गया है, जिसका अर्थ है कि यह टेम्पपीडीबी में सॉर्ट किया जाएगा।


33

सिद्धांत "कम से कम विशेषाधिकार" और "जानने की आवश्यकता है": क्या डेवलपर्स इस परीक्षा को पास करते हैं?
खासकर जब ऑडिटर या सर्बनेस-ऑक्सले दस्तक देते हैं।

फिर, मेरी अगली धारणा: डेवलपर्स बेवकूफ हैं। इसलिए अगर उन्हें तीसरी पंक्ति के समर्थन के लिए कहने की आवश्यकता है, तो किसकी जरूरत है? वेब बंदर आमतौर पर डेटाबेस को हाँ नहीं करते हैं, अगर उनसे समर्थन की उम्मीद की जाती है।

फिर, स्थायी रूप से एक्सेस की आवश्यकता है? उनके पास SQL ​​लॉगिन या वैकल्पिक विंडोज खाते का उपयोग करके "ब्रेक ग्लास" एक्सेस हो सकता है जिसके लिए साइन ऑफ की आवश्यकता होती है। हमारे मामले में, यह डेटा स्वामी (कुछ तकनीकी जानकार व्यवसायी उम्मीद से) और आईटी प्रबंधक इसे अनुमोदित करने के लिए था।

मैंने उत्पादन पर प्रश्नों के खिलाफ डेवलपर्स को देखा है या अज्ञानता के कारण इसे नीचे ले जाता है । यह कहते हुए कि, डेवलपर्स को अपने कार्यों की जिम्मेदारी लेनी चाहिए: यदि वे एक सर्वर को नीचे ले जाते हैं, तो उन्हें तदनुसार पीड़ित होना चाहिए। मैं एक घटना के बाद किसी को डिमोट कर दिया ...

ये निश्चित रूप से एक निश्चित आकार की दुकान मानते हैं। अधिक टोपी लोक कर्तव्यों की कम जुदाई पहनते हैं जो आपके पास हो सकते हैं

इसके अलावा, क्या ऐसा माहौल है कि डेवलपर्स हाल के आंकड़ों के खिलाफ प्रश्न चला सकते हैं? मेरी आखिरी दुकान में, इसे प्रदान करने के लिए प्रत्येक रात परीक्षण सर्वर को ठेस पहुंचाई गई थी।


20

मुझे लगता है कि इसका जवाब है, जैसे कि कई चीजों के साथ, "यह निर्भर करता है"।

संवेदनशील कंपनी और ग्राहक जानकारी के साथ एक विशाल ईआरपी डेटाबेस? शायद नहीं (सुरक्षा और प्रदर्शन दोनों कारणों से)।

एक्सेस फ्रंट-एंड के साथ एक विभागीय 5 एमबी डेटाबेस जो डोनट और पिज्जा फंड में योगदान देता है? कम से कम पठन-पाठन के लिए कम-से-कम बहुत फर्क तो नहीं पड़ेगा।

दी गई, पहला उदाहरण दूसरे की तुलना में बहुत अधिक सामान्य है, लेकिन ये ऐसे अंतर हैं जिनसे आपको अवगत होना चाहिए यदि आप इस प्रकार के नीतिगत निर्णय लेने के प्रभारी हैं। लेकिन फ्लिप-साइड पर, यह आश्चर्यजनक है कि कितनी जल्दी 5 एमबी डोनट-और-पिज्जा-फंड डेटाबेस 50 जीबी पार्ट-नंबर / ग्राहक-क्रेडिट-कार्ड-नंबर / कौन-कौन-क्या-क्या-क्या कर सकता है यदि आप इसे करते हैं तो डेटाबेस।


20

सामान्य 24/7 ओएलटीपी वातावरण में एक सामान्य डेवलपर को उत्पादन में अनुमति नहीं दी जानी चाहिए। अवधि! यदि, समय-समय पर, एक विशेष कारण प्रकट होता है, तो अनुरोध पर अनुमति दी जा सकती है। लेकिन एक सामान्य आधार पर नहीं।

मैंने इसके कई कारण देखे हैं:

  • एक प्रमुख तालिका से * का चयन करें:

    • प्रदर्शन के मुद्दे (कार्टेशियन उत्पाद);
    • उन मुद्दों को रोकना जो अंततः साइट को घुटनों तक ले आए;
    • अवरुद्ध श्रृंखला जो प्रतिकृति को लटका देती है;
    • TempDB ड्राइव को भरने वाले डेटा के बड़े सेट का आदेश दिया गया है .. जो क्या है? पूर्ण पागलपन का कारण बनता है :-)!
    • उस रात उत्पादन के प्रभारी डीबीए के लिए उच्च रक्तचाप;
  • संवेदनशील डेटा की रीडिंग (एक डेवलपर को क्रेडिट कार्ड की जानकारी नहीं होनी चाहिए..किसी भी उपयोगकर्ता के व्यक्तिगत विवरण);

मुझे यकीन है कि और भी कारण हैं।


19
  • सुरक्षा: संवेदनशील जानकारी हो सकती है जो डेवलपर्स के लिए उपलब्ध होने पर स्वच्छता हो।
  • व्यामोह: कुछ लोग सोच सकते हैं कि आप अभी भी केवल चुनिंदा पहुंच के साथ डेटा को गड़बड़ कर सकते हैं।
  • प्रदर्शन: एक क्वेरी प्रदर्शन करने के लिए कुछ संसाधन लेता है, और जब आप कोड लिखते हैं तो आप मुझे बता नहीं सकते कि आपके डेवलपर्स एकदम सही हैं।

16

विचार करने के लिए मदों की जोड़ी

  • क्या डेटा संवेदनशील है?
  • क्या प्रोग्रामर एक कोर विश्वसनीय टीम या कुछ ऑफशोर टीम का हिस्सा हैं?
  • प्रदर्शन को प्रभावित करने के मामले में डेटा के पैमाने को किस आधार पर देखा जा रहा है?
  • परियोजना या डॉलर के पैमाने क्या है?
  • अपटाइम कितना महत्वपूर्ण है?

छोटे डॉलर को कम प्रक्रिया की आवश्यकता होती है, विकास के तेज प्रवाह की आवश्यकता होती है।

बड़े डॉलर को अधिक प्रक्रिया की आवश्यकता होती है जो विकास प्रथाओं के सख्त मानकों की आवश्यकता होती है।

आप जो कर रहे हैं, उसमें अपनी प्रथाओं को अपनाएँ।


14

मैं एक बहुत बड़ी कंपनी के लिए एक डेवलपर के रूप में काम करता हूं। हमारे सभी डेवलपर्स जो किसी भी प्रकार का समर्थन कर रहे हैं (मूल रूप से उन सभी) की प्रासंगिक उत्पादन डेटाबेस तक पहुंच है। मैं केवल अपनी विशिष्ट टीम के लिए बोल सकता हूं, लेकिन मैं आपको बताऊंगा कि हमारी पहुंच क्यों है ।

  1. हमें अपने दैनिक प्रसंस्करण पर नजर रखने के लिए वास्तविक समय तक पहुंच की आवश्यकता है। (जबकि हमारे पास एक डैशबोर्ड है, हमें चीजों पर गहराई से नज़र रखने में सक्षम होना चाहिए। जबकि हमारे डैशबोर्ड पर यह सुविधा होना अच्छा होगा, हमने पाया है कि यह अव्यावहारिक है।)
  2. हमें किसी भी उत्पादन विफलताओं की जांच करने के लिए रियलटाइम एक्सेस की आवश्यकता है क्योंकि देरी का बहुत बड़ा प्रभाव हो सकता है। (मैं यहाँ पर अपनी विफलताओं पर चर्चा नहीं करने जा रहा हूँ। वे सभी प्रकार से आते हैं)
  3. हमें अक्सर व्यापार उपयोगकर्ताओं के लिए कस्टम रिपोर्ट करने की आवश्यकता होती है और इस जानकारी को अद्यतित होना चाहिए। (dba के पास ऐसा करने का समय नहीं है और हमारे पास उनके लिए प्रतीक्षा करने का समय नहीं है। गैर-आदर्श, निश्चित रूप से इसके लिए)।
  4. हमें उत्पादन डीडीएल / डीएमएल तैनाती / पैच का सत्यापन करने की आवश्यकता है। (डीबीए उन्हें तैनात करते हैं, लेकिन केवल हम जानते हैं कि इसे कैसे संरचित किया जाना चाहिए। हम डीबीए की तुलना में हमारे डेटाबेस संरचना के बारे में अधिक जानते हैं। हम यहां अजीब हो सकते हैं, लेकिन बाहर डेटाबेस बहुत जटिल है क्योंकि हमारा व्यवसाय बहुत जटिल है।)

प्रदर्शन एक चिंता का विषय है। हमारे पास डेवलपर्स की मंदी के कारण होते हैं। हालाँकि, ये अलग-थलग उदाहरण हैं और हमारा SQL इतना प्रदर्शन संचालित है कि यह दुर्लभ है हमारे डेवलपर्स अपने प्रश्नों के प्रभाव को नहीं समझते हैं।


2
यह ठेस पहुंच का औचित्य नहीं है। नंबर 4: स्क्रिप्ट को सही तरीके से तैयार करने के लिए लाल गेट जैसे टूल का उपयोग करें। 3: गैर-उत्पादों पर एक दिन पुराने डेटा का उपयोग करें 1. क्या कोई रिपोर्टिंग या डैशबोर्ड?
gbn

@ जीबी, 4) हमें अभी भी सत्यापन की आवश्यकता है। 3) यह दिन पुराना नहीं हो सकता।
user606723

11

पूछे जाने वाले इस सवाल के लिए किसी को यह मानना ​​होगा कि वर्तमान में उनकी पहुंच नहीं है। यदि किसी का संगठन सॉफ़्टवेयर विकसित कर रहा है और यह ग्राहक समस्या के निवारण के लिए है और ग्राहक अपने डेटाबेस की एक प्रति प्रदान करता है, तो 'हाँ'। अन्यथा मैं डेवलपर्स को उत्पादन से दूर रखने की वकालत करूंगा और वैकल्पिक रूप से उनकी शोध आवश्यकताओं के लिए बनाए गए वातावरण का निर्माण करूंगा। एक बार जब टूथपेस्ट ट्यूब से बाहर हो जाता है, तो इसे वापस अंदर लाना मुश्किल होता है।


10

मैं मानता हूं कि औचित्य का बोझ पहुंच वाले लोगों पर होना चाहिए। आमतौर पर ऐसे वातावरण में जहां मैंने परामर्श दिया है, मुझे उत्पादन प्रणालियों तक पहुंच मिली है जहां यह एक छोटा वातावरण था और मैं समर्थन व्यक्ति था। मेरे पास बैकअप आदि की पहुंच है, जहां मुझे समर्थन के लिए समर्थन था, और उत्पादन डेटा के लिए अप्रत्यक्ष पहुंच (एक समर्पित समर्थन डेवलपर के माध्यम से)।

बड़ी बात यह है: आपको इस पहुंच की आवश्यकता होती है जब आप सब कुछ सुचारू रूप से चलाने के लिए हुक पर होते हैं और आपको काम नहीं करने के बारे में वित्त आदमी के सवाल का जवाब देना होगा। आप हमेशा उस स्थिति में भी पुराने डेटा से काम नहीं कर सकते। दूसरी ओर, यह जितना अधिक खराब है, उतनी ही अधिक पहुंच है। आमतौर पर एक सलाहकार के रूप में मैं इस तरह की पहुंच प्राप्त करने से बचता हूं जब तक कि इसकी आवश्यकता न हो। चूंकि मैं वित्तीय डेटाबेस पर काम कर रहा हूं, इसलिए मैं चाहता हूं कि मेरे खुद के चालान दर्ज करने का आरोप लगाया जाए :-D।

दूसरी ओर, यदि आपको पहुँच की आवश्यकता नहीं है तो आपके पास यह नहीं होना चाहिए। मैं वास्तव में संवेदनशील डेटा तर्क नहीं खरीदता हूं क्योंकि डेवलपर शायद यह सुनिश्चित करने के लिए हुक पर है कि यह सही ढंग से संभाला है (और बग रिपोर्ट में आने पर वास्तव में जो कुछ संग्रहीत किया गया है, उसे देखे बिना यह सत्यापित करना बहुत कठिन है। यदि आप डेवलपर को उस डेटा को देखने के लिए डेवलपर पर भरोसा नहीं कर सकते हैं जो डेवलपर का ऐप स्टोर कर रहा है, तो आपको ऐप लिखने के लिए डेवलपर को काम पर नहीं रखना चाहिए। कई तरीके हैं जिनसे डेवलपर डेटा को बाधित कर सकता है और इसे ईमेल कर सकता है और आप कभी सुनिश्चित नहीं हो सकते। मैक नियंत्रण यहाँ मदद करते हैं लेकिन वे अभी भी लागू करने के लिए बहुत जटिल हैं।

मेरी ओर से बड़ा मुद्दा लेखन पहुंच के साथ है। यदि किसी डेवलपर के पास कोई पहुंच नहीं है, तो एक फोर्टियोरी, डेवलपर के पास कोई लिखित पहुंच नहीं है। यदि आप पुस्तकों की अखंडता को सत्यापित करना चाहते हैं, तो आप जितना संभव हो उतने लोगों तक पहुंच को लिखना चाहते हैं। यदि डेवलपर्स के पास कोई पहुंच नहीं है, तो ऑडिट ट्रेल्स को मान्य करना बहुत आसान है। यदि डेवलपर ने पहुंच को पढ़ा है, तो आपके पास हमेशा कुछ सवाल होते हैं कि क्या कुछ विशेषाधिकार संलग्नक संलग्न किए गए हैं जो लेखन एक्सेस दे सकते हैं (हो सकता है कि-इन-स्टोरेज प्रक्रिया एसक्यूएल इंजेक्शन?)। जब मैं स्टेजिंग वातावरण में पहुँचता हूं तो मुझे अक्सर क्लाइंट बिलिंग जानकारी तक पूर्ण पहुंच प्राप्त होती है। यदि कोई मंचन वातावरण है जो हालांकि काम करता है, तो मैं आमतौर पर सक्रिय रूप से उत्पादन तक पहुंच होने के लिए कहूंगा जब तक कि यह आवश्यक न हो।

तो यह बिल्कुल सही नहीं है। एक डेवलपर अभी भी एप्लिकेशन में बैक-डोर का निर्माण कर सकता है जो आसानी से पता लगाने योग्य नहीं हो सकता है, लेकिन यह दृष्टिकोण एक उचित दृष्टिकोण है, इस तथ्य को देखते हुए कि बैकअप डेटा एक दिन पहले से उपलब्ध है, मुझे लगता है कि यह उनकी चिंता है।

उम्मीद है की यह मदद करेगा।

संपादित करें: बस जिस बड़े वातावरण में मैंने काम किया है, उस पर जोड़ते हुए, मुझे अक्सर पूर्ण बैकअप डेटा तक पहुंच होती है, जो कुछ दिनों के पुराने से लेकर कुछ महीनों के वित्त व्यवस्था तक होती है। यह हमेशा मेरे काम के लिए काफी अच्छा रहा है और केवल यही समय टूट गया है जब वित्त लोगों को नए डेटा के साथ परीक्षण करने की क्षमता की आवश्यकता थी ताकि वे उत्पादन के खिलाफ मैच कर सकें।


9

एक्सेस न होना एक अच्छी बात है और डेवलपर्स और अन्य लोगों को गलती से डेटा को दूषित करने या इसे देखने से बचाने का एक तरीका है। यह कंपनियों को कानून तोड़ने से भी बचाता है (यानी हिपा उल्लंघन और गोपनीयता की चिंता)

एक डेवलपर को वास्तव में एक उत्पादन वातावरण तक पहुंच की आवश्यकता नहीं होती है यह डेवलपर्स के दृष्टिकोण से बस आसान है अगर एक कठिन बग को पुन: पेश नहीं किया जा सकता है।

हालांकि, एक डेवलपर मिनी-डंप या लॉग फ़ाइलों में डाल सकता है और बग को फिर से बनाने के लिए पीडीबी प्रतीक फ़ाइलों का उपयोग कर सकता है।

यदि डेटा को एक परीक्षण वातावरण में लाने की आवश्यकता है, तो डेटा को साफ़ करने के लिए किसी प्रकार की प्रक्रिया के लिए विशिष्ट है जो अतिरिक्त कार्य बना सकता है।

डेटाबेस सॉफ़्टवेयर पर निर्भर करता है कि आप किस उत्पादन में कॉल कर रहे हैं इसका उपयोग डेवलपर को डेटाबेस तक पहुंचने के लिए एक नया लाइसेंस की आवश्यकता हो सकती है, जो कि बस पढ़ने के लिए एक बड़ा खर्च है।

यदि आपकी कंपनी आपको डिबग या अनुसंधान उत्पादन मुद्दों के लिए उपकरण प्रदान नहीं कर रही है, तो ऐसा नहीं है क्योंकि आपके पास उत्पादन डेटा तक पहुंच नहीं है।

डेटा अधिकांश अनुप्रयोगों का सबसे मूल्यवान हिस्सा है!


8

प्रदर्शन इसका एक कारण हो सकता है।

डेवलपर प्रश्न अक्सर अक्षम हो सकते हैं, जिससे अत्यधिक लॉकिंग या संसाधन उपयोग हो सकता है जब तक कि वे ठीक से ट्यून न हों।

एक उत्पादन प्रणाली डेवलपर्स के लिए प्रयोग करने के लिए उपयुक्त जगह नहीं है।


8

यह डीबीए पर निर्भर करता है और वह डेवलपर के साथ कैसे विश्वास करता है। आमतौर पर डेवलपर्स को उत्पादन डेटाबेस के लिए क्वेरी (पढ़ें) विशेषाधिकार दिए जाते हैं। अंगूठे के एक नियम के रूप में, डेवलपर्स को केवल परीक्षण / देव डेटाबेस के साथ काम करना चाहिए


8

चुनौती यह है कि अधिकांश सॉफ़्टवेयर एप्लिकेशन डेटा चालित हैं। इसलिए जब आप एप्लिकेशन में किसी समस्या को ठीक करने का प्रयास कर रहे हैं, तो आपको वास्तव में उस डेटा को देखना होगा जो उसे चला रहा है। तो डेवलपर्स को वास्तव में कुछ प्रकार की पहुंच की आवश्यकता होती है।

एसक्यूएल लॉगिन का उपयोग करने के लिए केवल उन्हें पढ़ने के लिए केवल तालिकाओं का उपयोग महान है। लेकिन, क्या उन्हें 20 जोड़ के साथ एक क्वेरी बनाने से रोकता है या लाखों रिकॉर्ड के साथ एक मेज से चयन * कर रहा है? ये क्वेरी गलती से आपके डेटाबेस और स्टोरेज के प्रदर्शन को मार सकती हैं।

मेरी कंपनी Stackify ने इसे हल करने के लिए एक चतुर तरीका पेश किया। डेवलपर्स हमारे सॉफ़्टवेयर के माध्यम से क्वेरी चला सकते हैं और हम यह सुनिश्चित करने के लिए क्वेरी प्लान का उपयोग करते हैं कि यह सिर्फ एक सेलेक्ट स्टेटमेंट है और क्वेरी की अनुमानित लागत कम है और यह केवल कुछ रिकॉर्ड लौटाएगा। इस तरह वे ज्यादा नुकसान नहीं कर सकते। हम उन सभी प्रश्नों का भी ऑडिट करते हैं जो वे चलाते हैं।

यह हमारे द्वारा प्रदान की जाने वाली चीजों में से एक है। हमारे DevOps समर्थन समाधान के बारे में अधिक जानने के लिए http://www.Stackify.com पर हमें देखें ।


4
कुछ इसे स्पैम के रूप में मान सकते हैं क्योंकि इरादा केवल आपके उत्पाद को बढ़ावा देने के लिए लगता है। OTOH, यह सवाल के लिए प्रासंगिक है और ठीक से खुलासा है, इसलिए मुझे व्यक्तिगत रूप से लगता है कि यह सार्थक है।
जैक डगलस

एक महत्वपूर्ण बिंदु के रूप में, कम से कम PostgreSQL में क्वेरी प्लान यह जानने के लिए पर्याप्त नहीं है कि यह केवल-पढ़ने के लिए क्वेरी है।
क्रिस ट्रैवर्स

7

हाँ। कुछ मामलों में, यह उपयोगकर्ताओं के कुछ सबसेट को अनुमति देने के लिए समझ में आता है, जिसमें डेवलपर्स को क्वेरी उत्पादन डेटा तक पहुंच के कुछ स्तर शामिल हैं। हालांकि, दो कारणों से उचित सीमाएं होनी चाहिए। सबसे पहले, एक डीबीए के रूप में, आपको सभी उपयोगकर्ताओं द्वारा आवश्यक सेवा के स्तर का बीमा करने के लिए अपनी पूरी कोशिश करनी चाहिए। इसके अलावा, आप बड़े पैमाने पर विलोपन या व्यावसायिक नियमों के उल्लंघन जैसे अनजाने बुरे प्रश्नों को रोकना चाहते हैं। यह कहे बिना जाना चाहिए कि उचित सुरक्षा नियंत्रण होना चाहिए।

जो भी कारण आपके पास हो सकता है कि आप सीधे डेटाबेस तालिकाओं में तदर्थ प्रश्नों की अनुमति न दें, प्रश्नों और विचारों को संग्रहीत करने की अनुमति देने के लिए एक मामला हो सकता है। डेटाबेस अनुमतियों का उपयोग करते हुए, आप सीधे प्रश्नों को फिर से तालिकाओं को रोक सकते हैं और यहां तक ​​कि सीमाएं जो किसी दिए गए उपयोगकर्ता के विचारों और संग्रहीत प्रक्रियाओं तक पहुंचती हैं। न केवल यह विधि आपके उपयोगकर्ता आधार को लचीलापन देती है, यह सही ढंग से लागू होने पर आपके डेटा अखंडता और वास्तविकता की सुरक्षा भी करती है।


5

हमारी कंपनी में हम उत्पादन डेटाबेस के रीड-ओनली स्लेव्स बनाए रखते हैं जो उत्पादन सेवाओं पर निर्भर नहीं होते हैं। हम डेवलपर्स को उत्पादन डेटा तक पहुंच के लिए एक्सेस प्रदान करते हैं। यदि संवेदनशील डेटा (ग्राहक जानकारी, भुगतान जानकारी, आदि) है, तो हम उन तालिकाओं की प्रतिकृति को प्रतिबंधित करते हैं और स्लैब सर्वर पर एक नमूना डेटा तालिका बनाए रखते हैं।


1

नहीं कभी नहीं!!

यही कारण है कि हमारे पास विकास / परीक्षण / यूएटी सर्वर हैं। उत्पादन से डेटा को परीक्षण के वातावरण पर कॉपी किया जा सकता है और डेवलपर्स अपने परीक्षण के साथ आगे बढ़ सकते हैं। उत्पादन वातावरण के मामले में चुनिंदा क्वेरी बहुत हानिकारक हो सकती हैं। यह लोड बढ़ाता है और चरम समय पर पूरे प्रदर्शन को नीचे ला सकता है।

किसी भी जानकारी की जरूरत है उन्हें डीबीए के माध्यम से जाना चाहिए जो वे चला सकते हैं (चयन) और उन्हें परिणाम भेजना चाहते हैं। ऐसा हम अपने परिवेश में करते हैं।


-1

मुझे यकीन नहीं है कि हर कोई मानता है कि डेवलपर्स मूर्ख हैं और कुछ भी नहीं जानते हैं। मुझे अलग-अलग भूमिकाओं के एक टन का एक नमूना मिलता है जहां उन्होंने गड़बड़ की और "उत्पादन में" नहीं होना चाहिए। मैंने DBAs, Sys Admins, Network Admins, Developers, etc ... सब गड़बड़ कर दिया है।

कोई भी (देव, dba, sa) किसी भी वातावरण में किसी भी सर्वर या डेटाबेस तक सामान्य नेटवर्क लॉगिन के साथ नहीं पहुँच सकता है। वे सभी विशिष्ट "व्यवस्थापक" खाते हैं जिनका उपयोग किया जाना चाहिए। हां, आम तौर पर dba और sa अक्सर उनका उपयोग कर रहे हैं, लेकिन यहां तक ​​कि उन्हें हल्के ढंग से चलना चाहिए। मैं हर किसी के द्वारा जला दिया गया है।

इसलिए, एक अच्छे दिन पर, किसी भी आईटी भूमिका की आवश्यकता नहीं है। हालाँकि, sh! T पंखे से टकराता है, डेक पर सभी हाथ हैं और हमें समस्या को हल करने वाले सही लोगों की आवश्यकता है। यह आमतौर पर डेवलपर के नेतृत्व में होता है जो एप्लिकेशन को जानता है और कुछ बिंदुओं के लिए dba और sa का मार्गदर्शन करता है। यह सिर्फ अनावश्यक देरी या अनुरोध और अनुमोदन है।

इसके अलावा, अनुमोदन का पालन किसी भी प्रकार के ऑडिटिंग द्वारा कभी भी नहीं किया जाता है, इसलिए अनुमोदन का मतलब कुछ भी नहीं है।


2
यह निश्चित नहीं है कि आप किस वातावरण के बारे में बोल रहे हैं, लेकिन किसी भी कंपनी में जिसे उच्च स्तरीय पीसीआई, एसओएक्स, एसआईएसआर, आदि जैसे गंभीर नियमों का पालन करना पड़ता है, एसए स्तर लॉग इन करें और लॉग इन होने के लिए एनईईडीएस का उपयोग करें। हमारे मामले में, न केवल हम इसे लॉग करते हैं, लेकिन हम इसे स्प्लंक भी करते हैं ताकि कोई भी तथ्य के बाद इसे संपादित न कर सके।
अली रज़ेगी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.