DevOps اور IaC کا موضوع بہت مقبول ہے اور تیزی سے بڑھ رہا ہے۔ تاہم، زیادہ تر مصنفین راستے میں خالصتاً تکنیکی مسائل سے نمٹتے ہیں۔ میں ایک بڑی کمپنی کے لیے مخصوص مسائل بیان کروں گا۔ میرے پاس کوئی حل نہیں ہے - مسائل، عام طور پر، مہلک ہیں اور بیوروکریسی، آڈٹ، اور "سافٹ سکلز" کے میدان میں جھوٹ بولتے ہیں۔
چونکہ مضمون کا عنوان ایسا ہی ہے، اس لیے ڈینریز ایک بلی کے طور پر کام کریں گے، انٹرپرائز کی طرف جانے کے بعد
بلاشبہ اب پرانے اور نئے کا تصادم ہے۔ اور اکثر ان تصادم میں نہ صحیح ہوتا ہے نہ غلط۔ بس ایسا ہی ہوا۔ لیکن، بے بنیاد نہ ہونے کے لیے، ہم اس اسکرین سے شروع کریں گے:
یہ نام نہاد تبدیلی کی درخواست ہے۔ آپ تقریباً ایک تہائی فیلڈز دیکھتے ہیں جنہیں مختلف ڈائریکٹریز سے پُر کرنے کی ضرورت ہے، باقی فیلڈز دیگر ٹیبز میں ہیں۔ اسکرپٹ کو پروڈکشن سرور پر لاگو کرنے، یا نئی فائلیں اپ لوڈ کرنے اور عام طور پر، کچھ تبدیل کرنے کے لیے ایسی دستاویز کو پُر کرنا ضروری ہے۔
فیلڈز کی تعداد اتنی ہے کہ میں نے ان فیلڈز کو بھرنے کے لیے اپنی چھوٹی آٹومیشن لکھی۔ مزید یہ کہ یہ صفحہ اس طرح لکھا گیا ہے کہ کوئی بھی آٹومیشن ٹولز اس کے فیلڈز کو نہیں دیکھتا، اور واحد ممکنہ حل یہ تھا کہ AutoIt کو ماؤس کے ساتھ کوآرڈینیٹس کو بے وقوفانہ طریقے سے مارنے کے لیے استعمال کیا جائے۔ اس پر فیصلہ کرنے کے لیے مایوسی کی ڈگری کا اندازہ لگائیں:
لہذا، آپ جینکنز، شیف، ٹیرافارم، گٹھ جوڑ وغیرہ لیں، اور یہ سب خوشی خوشی اپنے دیو پر لگا دیں۔ لیکن یہ QA، UAT اور PROD کو بھیجنے کا وقت ہے۔ آپ کے پاس Nexus آرٹفیکٹ ہے اور آپ کو DBA سے کچھ اس طرح کا خط موصول ہوتا ہے:
قابل احترام ،
سب سے پہلے، آپ کا گٹھ جوڑ آپ تصور کر سکتے ہیں کہ مجھے آپ کے گٹھ جوڑ تک رسائی حاصل نہیں ہے۔
دوم، تمام تبدیلیاں تبدیلی کی درخواست کے طور پر درج کی جانی چاہئیں۔
آپ کو Nexus سے SQL اسکرپٹس کو الگ کرنے اور انہیں تبدیلی کی درخواست سے منسلک کرنے کی ضرورت ہے۔
اگر تبدیلی ایمرجنسی نہیں ہے تو اسے ریلیز کے 7 دنوں کے اندر کیا جانا چاہیے (خصوصی طور پر ویک اینڈ پر)
جب آپ کی تبدیلی کی درخواست کو لوگوں کے ایک گروپ سے منظور کیا جاتا ہے، تو DBA آپ کے اسکرپٹ پر عمل درآمد کرے گا اور میل کے ذریعے نتیجہ کا اسکرین شاٹ بھی بھیجے گا۔مخلص، آپ کا DBA، جو مین فریم سے یہاں کام کر رہا ہے۔
کیا آپ جانتے ہیں کہ یہ مجھے کیا یاد دلاتا ہے؟ سیمی آٹومیشن: روبوٹ فریم کو پکڑتا ہے، اور کارکن اسے سلیج ہتھوڑے سے مارتا ہے۔ ٹھیک ہے، واقعی، اس گٹھ جوڑ کا کیا فائدہ، اگر سب کچھ مکمل طور پر دستی طور پر کیا جائے؟
لیکن اس کے لیے انٹرپرائز پر الزام نہ لگائیں! یہ بلاشبہ خونی ہے، لیکن تبدیلی کی درخواستوں کے ساتھ یہ ساری بیوروکریسی مجبور ہے اور آڈیٹرز کی طرف سے آتی ہے۔ انٹرپرائز کو اس طرح کام کرنا ہے، مدت۔ وہ کسی اور طریقے سے نہیں کر سکتا۔ اور آڈٹ بہت قدامت پسند چیز ہے۔ مثال کے طور پر، اس حقیقت کے بارے میں کتنا کہا گیا ہے کہ لمبے سیوڈو کمپلیکس اور بار بار تبدیل کیے جانے والے پاس ورڈز خراب ہیں، لیکن کاروباری ادارے اسے تبدیل کرنے کی آخری جگہ ہوں گے۔ تعیناتی اور ہر چیز کے ساتھ بھی۔
ویسے، میں نے ایک وقت میں ٹیرافارم کے لیے فائل بنانے کی کوشش کی، لیکن میں کامیاب نہیں ہوا۔ میں نے 'پروجیکٹ اکاؤنٹنگ بلنگ کوڈ' ٹیگ کے معنی کے بارے میں ٹھوکر کھائی، جس کا میں کبھی پتہ نہیں لگا سکا - میرے پاس اتنی نرم مہارتیں نہیں تھیں۔
میں غیر فعال لڈزم کا موضوع بھی نہیں لیتا - اوہ، آپ کی آٹومیشن سے میری ملازمت کی حفاظت کو خطرہ ہے، میں کچھ نیا نہیں سیکھنا چاہتا، اس لیے میں خاموشی سے سبوتاژ کروں گا۔
تو، حل کیا ہو سکتا ہے؟ ITSM سسٹم میں خود بخود دستاویزات تیار کرنے کے لیے ایک انتہائی قدیم API ہے۔ اور عام طور پر، ان میں سے زیادہ تر سسٹم مین فریم کے دنوں سے آتے ہیں۔ ہوسکتا ہے کہ کوئی واقعی جدید ITSM سسٹم کو جانتا ہو؟ ہوسکتا ہے کہ کسی کو جدید ڈی او اوپس اور بیوروکریسی کو مربوط کرنے کا کامیاب تجربہ ہو؟ یہ، یقیناً، خالصتاً بدعنوان سائٹس کے بارے میں نہیں ہے، جہاں اسے واقعی ہر روز تعینات کیا جا سکتا ہے، لیکن، مثال کے طور پر، بینکنگ سیکٹر، جو آڈیٹرز کے زیر اثر ہے اور اعلیٰ ماحول کی بہت مضبوط تنہائی ہے۔
بس یہ نہ بھولیں کہ آپ کی تمام فنتاسییں آڈیٹنگ تک محدود ہیں۔ اور یہ سب کچھ بدل دیتا ہے۔ تبصروں میں آپ کا انتظار رہے گا!
ماخذ: www.habr.com