आज कई DBA को DevOps कल्चर में योगदान करने के लिए कहा जा रहा है। मुझे पता है कि एक डीबीए ने मुझे हाल ही में उनकी कंपनी के पुनर्गठन की कहानी सुनाई और जब उन्होंने नया संगठन चार्ट भेजा, तो उसका शीर्षक वास्तव में डीबीए से बदलकर देवओप्स इंजीनियर कर दिया गया था। अब वह क्या करता है जो पहले से अलग है? खैर यह पता चला ... ज्यादा नहीं। अब वह जो कुछ भी करता है, उसमें से अधिकांश अभी भी वही है। लेकिन उनका कक्ष अभी DevOps के लिए शून्य है, इसलिए वह इस नए शीर्षक को बहुत गंभीरता से ले रहे हैं।
यहाँ सच्चाई है - DBA काफी हद तक हमेशा DevOps का हिस्सा रहे हैं। ऐसा इसलिए है क्योंकि अधिकांश पहले से ही देव कार्य करते हैं। SQL लिखना, SQL सर्वर प्रदर्शन ट्यूनिंग, ऑब्जेक्ट विश्लेषण और रिपोर्टिंग जैसी चीजें और वे पहले से ही Ops कार्य करते हैं जैसे सर्वर को कॉन्फ़िगर करना, बैकअप चलाना और पुनर्स्थापित करना, और OS, नेटवर्क और स्टोरेज को ट्यून करना।
मुख्य परिवर्तन यह है कि DevOps अक्सर एप्लिकेशन डेवलपर्स को स्थिरता और प्रदर्शन के मुद्दों पर बुनियादी ढांचा टीमों के खिलाफ खड़ा करता है। Dev और Ops की अलग-अलग प्राथमिकताएँ होती हैं, जिनके लिए ठीक संतुलन बनाने की आवश्यकता होती है।
इस कहानी के दो पहलू हैं। देव घर के किनारे को इस बात से मापा जाता है कि वे उत्पादन में कितनी जल्दी और मज़बूती से बदलाव ला सकते हैं। उनका लक्ष्य है जितनी जल्दी हो सके विशिष्ट कोड विकसित करना, इसे उत्पादन में लाना और उन परिवर्तनों को आते रहना।
ऑप्स यह सुनिश्चित करने से संबंधित है कि जब आप उनसे नज़रें हटाते हैं तो चीजें टूटती नहीं हैं। यह उन सभी बुनियादी बातों के बारे में है जो रोशनी और डेटा को चालू रखते हैं।
Dev और Ops के विलय में DBA की बड़ी भूमिका होती है। वास्तव में, यह DBA के लिए DevOps इंजीनियर की इस उभरती भूमिका में विकसित होने का एक बड़ा अवसर है, जिसमें SQL सर्वर प्रदर्शन की निगरानी और अनुकूलन शामिल है।
अधिकांश DevOps आदर्श वाक्य पर आधारित है, "अक्सर विफल, तेजी से विफल।" छोटे, वृद्धिशील परिवर्तन करें और उन्हें उत्पादन में धकेलें। यदि वे कोई समस्या उत्पन्न करते हैं या यदि वे ग्राहकों की अपेक्षा के अनुरूप नहीं हैं, तो उन्हें जल्दी से वापस रोल करें, उनकी मरम्मत करें और उन्हें जल्दी से उत्पादन में वापस लाएं।
फिर भी यह वास्तविक जोखिम प्रस्तुत करता है…
किसी प्रदर्शन या स्थिरता की समस्या के मूल कारण को समझना हमेशा आसान नहीं होता है। एप्लिकेशन या बुनियादी ढांचे में किए गए किसी बदलाव और डेटाबेस वर्कलोड और प्रदर्शन पर इसके प्रभाव के बीच बिंदुओं को जोड़ने में काफी खुदाई होती है।
ये अवधारणाएं डीबीए के लिए थोड़ी नई हैं और देवओप्स संस्कृति में भाग लेने के लिए बीच में मिलने का कार्य थोड़ा भारी लग सकता है। लेकिन, आपको कहीं से शुरुआत करनी होगी। कई संगठन SQL सर्वर के प्रदर्शन के मुद्दों को एक अलग लेंस से देखने और निगरानी के एक अलग तरीके को लागू करने का तरीका अपना रहे हैं।
क्या होगा यदि आपके पास अपने SQL सर्वर वातावरण के स्वास्थ्य में दृश्यता है जो प्रदर्शन के मुद्दों को लगातार हल करने के लिए आवश्यक है ... इससे पहले कि वे आपके व्यवसाय को गंभीरता से प्रभावित करें? क्या होगा यदि आप प्रदर्शन में गिरावट को जल्दी से पहचान सकें, कारण को अलग कर सकें और भविष्य में इसी तरह के मुद्दों को रोकने के लिए विश्लेषण और ट्यून कर सकें?
ओह, और क्या होगा यदि आप यह सब सब्सक्रिप्शन के आधार पर प्राप्त कर सकते हैं? बिना किसी अतिरिक्त हार्डवेयर के, कोई सॉफ्टवेयर नहीं, कोई रखरखाव लागत नहीं है और किसी भी डिवाइस पर कहीं से भी, कभी भी इसे एक्सेस करने में सक्षम हैं?
स्पॉटलाइट क्लाउड के साथ, आप कर सकते हैं! यह साइन अप जितना आसान है। दाखिल करना। हल करें।
SQL सर्वर के लिए बेजोड़ क्लाउड होस्टेड डेटाबेस मॉनिटरिंग और डायग्नोस्टिक्स के लिए स्पॉटलाइट क्लाउड के साथ आरंभ करें। यह अपने आप को तत्काल पदोन्नति देने जैसा है!
