बर्फ का एक गीत (खूनी उद्यम) और आग (DevOps और IaC)

DevOps और IaC का विषय बहुत लोकप्रिय है और तेजी से विकसित हो रहा है। हालाँकि, अधिकांश लेखक इस पथ पर विशुद्ध रूप से तकनीकी समस्याओं से निपटते हैं। मैं एक बड़ी कंपनी की विशिष्ट समस्याओं का वर्णन करूंगा। मेरे पास कोई समाधान नहीं है - समस्याएँ, सामान्य तौर पर, घातक हैं और नौकरशाही, ऑडिटिंग और "सॉफ्ट स्किल्स" के क्षेत्र में हैं।

चूँकि लेख का शीर्षक इस प्रकार है, डेनेरीज़, जो एंटरप्राइज़ के पक्ष में चला गया है, बिल्ली के रूप में कार्य करेगा।

निःसंदेह अब नये और पुराने का टकराव चल रहा है। और अक्सर इन टकरावों में न तो सही होता है और न ही ग़लत। ऐसा ही हुआ. लेकिन, निराधार न होने के लिए, हम इस स्क्रीन से शुरुआत करेंगे:

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

फ़ील्ड की संख्या इतनी है कि मैंने इन फ़ील्ड को भरने के लिए अपना स्वयं का छोटा स्वचालन लिखा है। इसके अलावा, यह पृष्ठ इस तरह से लिखा गया है कि कोई भी स्वचालन उपकरण इसके फ़ील्ड को नहीं देख सकता है, और एकमात्र संभावित समाधान माउस के साथ निर्देशांक पर मूर्खतापूर्ण क्लिक करने के लिए AutoIt का उपयोग करना था। ऐसा करने के लिए अपनी हताशा के स्तर का आकलन करें:

तो, आप जेनकींस, शेफ, टेराफॉर्म, नेक्सस इत्यादि लेते हैं, और ख़ुशी से इसे अपने डेव पर तैनात करते हैं। लेकिन इसे QA, UAT और PROD को भेजने का समय आ गया है। आपके पास एक नेक्सस आर्टिफैक्ट है और आपको डीबीए से कुछ इस तरह एक पत्र प्राप्त होता है:

प्रिय,

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

सादर, आपका डीबीए जो मेनफ्रेम के दिनों से यहां काम कर रहा है।

क्या आप जानते हैं कि यह मुझे किसकी याद दिलाता है? अर्ध-स्वचालन: रोबोट फ्रेम को पकड़ता है, और कार्यकर्ता इसे स्लेजहैमर से मारता है। खैर, वास्तव में, इस नेक्सस का क्या मतलब है अगर सब कुछ पूरी तरह से मैन्युअल रूप से किया जाता है?

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

वैसे, एक समय मैंने टेराफ़ॉर्म के लिए एक फ़ाइल बनाने का प्रयास किया था, लेकिन यह काम नहीं कर सका। मैं 'प्रोजेक्ट अकाउंटिंग बिलिंग कोड' टैग के अर्थ पर अचंभित हो गया, जिसे मैं कभी पता नहीं लगा सका - मेरे पास पर्याप्त सॉफ्ट स्किल नहीं थी।

मैं निष्क्रिय लुडिज्म का विषय भी नहीं ले रहा हूं - ओह, आपके स्वचालन से मेरी नौकरी की सुरक्षा को खतरा है, मैं कुछ भी नया नहीं सीखना चाहता, इसलिए मैं चुपचाप इसे नष्ट कर दूंगा।

खैर, सैद्धांतिक तौर पर समाधान क्या हो सकता है? आईटीएसएम प्रणाली में स्वचालित रूप से दस्तावेज़ तैयार करने के लिए एक अत्यंत आदिम एपीआई है। और सामान्य तौर पर, इनमें से अधिकतर सिस्टम मेनफ्रेम के समय से आते हैं। क्या कोई सचमुच आधुनिक आईटीएसएम सिस्टम जानता है? क्या किसी के पास आधुनिक DevOps और नौकरशाही को एकीकृत करने का सफल अनुभव है? बेशक, हम पूरी तरह से बिक्री साइटों के बारे में बात नहीं कर रहे हैं, जहां वास्तव में हर दिन तैनाती हो सकती है, लेकिन, उदाहरण के लिए, बैंकिंग क्षेत्र, जो लेखा परीक्षकों के अधीन है और उच्च वातावरण में बहुत मजबूत अलगाव है।

बस यह मत भूलिए कि आपकी सभी कल्पनाएँ ऑडिट तक ही सीमित हैं। और वह सब कुछ बदल देता है. मैं टिप्पणियों में आपका इंतजार कर रहा हूं!

स्रोत: www.habr.com