کیا DevOps کے بارے میں بات کرتے وقت اہم نکتے کو سمجھنا مشکل ہے؟ ہم نے آپ کے لیے واضح تشبیہات، حیرت انگیز فارمولیشنز اور ماہرین کے مشورے جمع کیے ہیں جو غیر ماہرین کو بھی بات تک پہنچنے میں مدد کریں گے۔ آخر میں، بونس Red Hat ملازمین کے اپنے DevOps ہیں۔
ڈی او اوپس کی اصطلاح 10 سال پہلے شروع ہوئی تھی اور ٹویٹر ہیش ٹیگ سے آئی ٹی کی دنیا میں ایک طاقتور ثقافتی تحریک کی طرف چلی گئی ہے، یہ ایک حقیقی فلسفہ ہے جو ڈویلپرز کو چیزوں کو تیزی سے انجام دینے، تجربہ کرنے اور دوبارہ آگے بڑھانے کی ترغیب دیتا ہے۔ DevOps ڈیجیٹل تبدیلی کے تصور کے ساتھ جڑے ہوئے ہیں۔ لیکن جیسا کہ اکثر آئی ٹی اصطلاحات کے ساتھ ہوتا ہے، پچھلے دس سالوں میں DevOps نے اپنے بارے میں بہت سی تعریفیں، تشریحات اور غلط فہمیاں حاصل کی ہیں۔
لہذا، آپ اکثر ڈیو اوپس کے بارے میں سوالات سن سکتے ہیں جیسے، کیا یہ فرتیلی کی طرح ہے؟ یا یہ کوئی خاص طریقہ کار ہے؟ یا یہ لفظ "تعاون" کا صرف ایک اور مترادف ہے؟
DevOps میں بہت سے مختلف تصورات شامل ہیں (مسلسل ترسیل، مسلسل انضمام، آٹومیشن، وغیرہ)، اس لیے جو اہم ہے اسے ڈسٹل کرنا مشکل ہو سکتا ہے، خاص طور پر جب آپ اس موضوع کے بارے میں پرجوش ہوں۔ تاہم، یہ ہنر بہت مفید ہے، چاہے آپ اپنے خیالات کو اپنے اعلیٰ افسران تک پہنچانے کی کوشش کر رہے ہوں یا اپنے خاندان یا دوستوں میں سے کسی کو اپنے کام کے بارے میں بتا رہے ہوں۔ لہذا، آئیے ابھی کے لیے DevOps کی اصطلاحی باریکیوں کو ایک طرف رکھیں اور بڑی تصویر پر توجہ مرکوز کریں۔
DevOps کیا ہے: 6 تعریفیں اور تشبیہات
ہم نے ماہرین سے کہا کہ وہ DevOps کے جوہر کو جتنا ممکن ہو آسان اور مختصر طور پر بیان کریں تاکہ اس کی قدر کسی بھی سطح تکنیکی معلومات کے حامل قارئین کے لیے واضح ہو جائے۔ ان مکالموں کے نتائج کی بنیاد پر، ہم نے انتہائی حیران کن تشبیہات اور شاندار فارمولیشنز کا انتخاب کیا ہے جو آپ کو DevOps کے بارے میں اپنی کہانی بنانے میں مدد کریں گے۔
1. DevOps ایک ثقافتی تحریک ہے۔
"DevOps ایک ثقافتی تحریک ہے جس میں دونوں فریقین (سافٹ ویئر ڈویلپرز اور آئی ٹی سسٹم آپریشن کے ماہرین) تسلیم کرتے ہیں کہ سافٹ ویئر اس وقت تک حقیقی فائدے نہیں لاتا جب تک کہ کوئی اسے استعمال کرنا شروع نہ کرے: گاہک، کلائنٹ، ملازمین، نہ کہ اہم،" سینئر ریسرچ ایولین اوہرلچ کہتی ہیں۔ ڈی او اوپس انسٹی ٹیوٹ کے تجزیہ کار۔ "لہذا، یہ دونوں فریق مشترکہ طور پر سافٹ ویئر کی تیز رفتار اور اعلیٰ معیار کی فراہمی کو یقینی بناتے ہیں۔"
2. DevOps ڈویلپرز کو بااختیار بنانے کے بارے میں ہے۔
"DevOps ڈویلپرز کو اختیار دیتا ہے کہ وہ ایپلیکیشنز کے مالک ہوں، انہیں چلائیں، اور شروع سے آخر تک ڈیلیوری کا انتظام کریں۔"
انشورنس کمپنی لبرٹی میوچل میں DevOps پلیٹ فارمز کے ڈائریکٹر Jai Schniepp کہتے ہیں، "عام طور پر، DevOps کے بارے میں بات کی جاتی ہے کہ وہ پروڈکشن میں ایپلی کیشنز کی ترسیل کو تیز کرنے کے لیے خودکار پراسیسز کی تعمیر اور عمل درآمد کر سکے۔" "لیکن میرے لیے یہ بہت زیادہ بنیادی چیز ہے۔" DevOps ڈویلپرز کو اختیار دیتا ہے کہ وہ ایپلیکیشنز یا سافٹ ویئر کے مخصوص ٹکڑوں کے مالک ہوں، انہیں چلائیں، اور شروع سے آخر تک ان کی ترسیل کا انتظام کریں۔ DevOps ذمہ داری کی الجھن کو ختم کرتا ہے اور ایک خودکار، ڈویلپر سے چلنے والا انفراسٹرکچر بنانے میں شامل ہر فرد کی رہنمائی کرتا ہے۔
3. DevOps ایپلی کیشنز بنانے اور ڈیلیور کرنے میں تعاون کے بارے میں ہے۔
BMC میں ڈیجیٹل بزنس آٹومیشن کے صدر اور سربراہ گر سٹاف کہتے ہیں، "سادہ لفظوں میں، DevOps سافٹ ویئر کی تیاری اور ترسیل کے لیے ایک نقطہ نظر ہے جہاں سب مل کر کام کرتے ہیں۔"
4. DevOps ایک پائپ لائن ہے۔
"کنویئر اسمبلی صرف اسی صورت میں ممکن ہے جب تمام حصے ایک ساتھ فٹ ہوں۔"
"میں DevOps کا موازنہ کار اسمبلی لائن سے کروں گا،" گور سٹاف جاری رکھتا ہے۔ - خیال یہ ہے کہ تمام پرزوں کو پہلے سے ڈیزائن اور بنانا ہے تاکہ ان کو انفرادی ایڈجسٹمنٹ کے بغیر جمع کیا جا سکے۔ کنویئر اسمبلی صرف اس صورت میں ممکن ہے جب تمام حصے ایک ساتھ فٹ ہوں۔ جو لوگ انجن کو ڈیزائن اور بناتے ہیں انہیں اس بات پر غور کرنا چاہیے کہ اسے باڈی یا فریم پر کیسے لگایا جائے۔ بریک لگانے والوں کو پہیوں وغیرہ کے بارے میں سوچنا چاہیے۔ سافٹ ویئر کے ساتھ بھی ایسا ہی ہونا چاہئے۔
کاروباری منطق یا صارف انٹرفیس بنانے والے ایک ڈویلپر کو اس ڈیٹا بیس کے بارے میں سوچنا چاہیے جو صارف کی معلومات کو ذخیرہ کرتا ہے، صارف کے ڈیٹا کی حفاظت کے لیے حفاظتی اقدامات، اور یہ سب کیسے کام کرے گا جب سروس ایک بڑے، شاید ملٹی ملین ڈالر کے صارف سامعین کو پیش کرنا شروع کر دے گی۔ "
"لوگوں کو کام کے ان حصوں کے بارے میں تعاون کرنے اور سوچنے پر مجبور کرنا جو دوسرے کر رہے ہیں، بجائے اس کے کہ صرف اپنے کاموں پر توجہ مرکوز کریں، اس پر قابو پانے کی سب سے بڑی رکاوٹ ہے۔ اگر آپ یہ کر سکتے ہیں، تو آپ کے پاس ڈیجیٹل تبدیلی کا ایک بہترین موقع ہے،" گور سٹاف نے مزید کہا۔
5. DevOps لوگوں، عمل اور آٹومیشن کا صحیح امتزاج ہے۔
ڈی او اوپس انسٹی ٹیوٹ کے ایگزیکٹو ڈائریکٹر جین گرول نے ڈی او اوپس کی وضاحت کے لیے ایک بہترین تشبیہ پیش کی۔ اس کے الفاظ میں، "DevOps اجزاء کی تین اہم اقسام کے ساتھ ایک ترکیب کی طرح ہے: لوگ، عمل اور آٹومیشن۔ ان میں سے زیادہ تر اجزاء دوسرے علاقوں اور ذرائع سے لیے جا سکتے ہیں: دبلی پتلی، چست، SRE، CI/CD، ITIL، قیادت، ثقافت، اوزار۔ DevOps کا راز، کسی بھی اچھی ترکیب کی طرح، یہ ہے کہ ایپلی کیشنز بنانے اور جاری کرنے کی رفتار اور کارکردگی کو بڑھانے کے لیے ان اجزاء کا صحیح تناسب اور مکس کیسے کیا جائے۔"
6. DevOps وہ ہوتا ہے جب پروگرامرز فارمولا 1 ٹیم کی طرح کام کرتے ہیں۔
"دوڑ شروع سے ختم کرنے کی منصوبہ بندی نہیں کی جاتی ہے، لیکن اس کے برعکس، ختم سے شروع تک."
Red Hat میں کلاؤڈ پلیٹ فارم مارکیٹنگ کے سینئر مینیجر اور DevOps'ish نیوز لیٹر کے ناشر Chris Short کہتے ہیں، "جب میں DevOps اقدام سے کیا توقع رکھ سکتا ہوں، تو میں NASCAR یا فارمولا 1 ریسنگ ٹیم کے بارے میں ایک مثال کے طور پر سوچتا ہوں۔" - ایسی ٹیم کے لیڈر کا ایک ہی مقصد ہوتا ہے: ٹیم کے لیے دستیاب وسائل اور اس سے پیش آنے والے چیلنجز کو مدنظر رکھتے ہوئے ریس کے اختتام پر سب سے زیادہ ممکنہ مقام حاصل کرنا۔ اس صورت میں، ریس شروع سے ختم کرنے کی منصوبہ بندی نہیں کی جاتی ہے، لیکن اس کے برعکس، ختم سے شروع تک. سب سے پہلے، ایک مہتواکانکشی ہدف مقرر کیا جاتا ہے، اور پھر اسے حاصل کرنے کے طریقے طے کیے جاتے ہیں. پھر انہیں ذیلی کاموں میں تقسیم کیا جاتا ہے اور ٹیم کے ممبروں کو سونپ دیا جاتا ہے۔
"ٹیم ریس سے پہلے پورا ہفتہ گڑھے کو روکنے میں صرف کرتی ہے۔ وہ سخت دوڑ کے دن کے لیے شکل میں رہنے کے لیے طاقت کی تربیت اور کارڈیو کرتا ہے۔ ریس کے دوران پیدا ہونے والے کسی بھی مسائل کو حل کرنے کے لیے مل کر کام کرنے کی مشقیں۔ اسی طرح، ترقیاتی ٹیم کو نئے ورژن کو کثرت سے جاری کرنے کی مہارت کی تربیت دینی چاہیے۔ اگر آپ کے پاس اس طرح کی مہارتیں ہیں اور ایک اچھی طرح سے کام کرنے والا سیکیورٹی سسٹم ہے تو، پروڈکشن میں نئے ورژن کا آغاز بھی اکثر ہوتا ہے۔ اس عالمی نظریہ میں، رفتار میں اضافے کا مطلب ہے حفاظت میں اضافہ،" شارٹ کہتے ہیں۔
"یہ 'صحیح کام' کرنے کے بارے میں نہیں ہے،" مختصر کہتے ہیں، "یہ زیادہ سے زیادہ چیزوں کو ختم کرنے کے بارے میں ہے جو مطلوبہ نتائج کی راہ میں حائل ہیں۔ آپ کو حقیقی وقت میں موصول ہونے والے تاثرات کی بنیاد پر تعاون اور موافقت کریں۔ بے ضابطگیوں کے لیے تیار رہیں اور معیار کو بہتر بنانے کے لیے کام کریں تاکہ اپنے مقصد کی جانب پیش رفت پر ان کے اثرات کو کم سے کم کیا جا سکے۔ ڈی او اوپس کی دنیا میں یہی ہمارا انتظار کر رہا ہے۔
DevOps کی پیمائش کیسے کریں: ماہرین کے 10 نکات
یہ صرف اتنا ہے کہ DevOps اور mass DevOps بالکل مختلف چیزیں ہیں۔ ہم آپ کو بتائیں گے کہ پہلی سے دوسری تک راستے میں آنے والی رکاوٹوں کو کیسے دور کیا جائے۔
بہت سی تنظیموں کے لیے، DevOps کا سفر آسانی سے اور خوشگوار طریقے سے شروع ہوتا ہے۔ چھوٹی پرجوش ٹیمیں بنتی ہیں، پرانے عمل کو نئی سے بدل دیا جاتا ہے، اور پہلی کامیابیاں آنے میں زیادہ دیر نہیں لگتی۔
کنسلٹنسی نارتھ ہائی لینڈ کے منیجنگ ڈائریکٹر اور ڈیجیٹل کے سربراہ بین گرنیل کا کہنا ہے کہ افسوس، یہ محض ایک جھوٹی چمک ہے، ترقی کا وہم ہے۔ ابتدائی جیت یقینی طور پر حوصلہ افزا ہے، لیکن وہ پوری تنظیم میں DevOps کو وسیع پیمانے پر اپنانے کے حتمی مقصد کو حاصل کرنے میں مدد نہیں کرتی ہیں۔
یہ دیکھنا آسان ہے کہ نتیجہ "ہم" اور "ان" کے درمیان تقسیم کا کلچر ہے۔
بین گرنیل بتاتے ہیں، "اکثر، تنظیمیں یہ سوچے سمجھے منصوبے شروع کرتی ہیں کہ وہ مین اسٹریم DevOps کے لیے راہ ہموار کریں گے، اس بات پر غور کیے بغیر کہ دوسرے اس راستے پر چلنے کے قابل ہوں گے یا تیار ہوں گے،" بین گرنیل بتاتے ہیں۔ - اس طرح کے منصوبوں کو لاگو کرنے کے لیے ٹیمیں عام طور پر خود اعتمادی والے "Varangians" سے بھرتی کی جاتی ہیں جنہوں نے پہلے ہی دوسری جگہوں پر کچھ ایسا ہی کیا ہے، لیکن وہ آپ کی تنظیم میں نئے ہیں۔ ایک ہی وقت میں، انہیں ان قوانین کو توڑنے اور تباہ کرنے کی ترغیب دی جاتی ہے جو باقی سب پر پابند رہتے ہیں۔ یہ دیکھنا آسان ہے کہ نتیجہ "ہم" اور "ان" کی ثقافت ہے جو علم اور مہارت کی منتقلی کو روکتا ہے۔
"اور یہ ثقافتی مسئلہ صرف ایک وجہ ہے کہ DevOps کی پیمائش کرنا مشکل ہے۔ ڈی او اوپس ٹیموں کو بڑھتے ہوئے تکنیکی چیلنجوں کا سامنا ہے جو تیزی سے ترقی کرنے والی آئی ٹی فرسٹ کمپنیوں کی طرح ہیں، "اسکیلر کے بانی اور چیئرمین اسٹیو نیومین نے کہا۔
"جدید دنیا میں، ضرورت پڑتے ہی خدمات بدل جاتی ہیں۔ اسٹیو نیومین کا مزید کہنا ہے کہ مسلسل نئی خصوصیات کو نافذ کرنا اور ان پر عمل درآمد کرنا بہت اچھا ہے، لیکن اس عمل کو مربوط کرنا اور پیدا ہونے والے مسائل کو ختم کرنا ایک حقیقی سر درد ہے۔ - بہت تیزی سے ترقی کرنے والی تنظیموں میں، کراس فنکشنل ٹیموں کے انجینئرز تبدیلی اور اس سے پیدا ہونے والے انحصاری سطح کے جھرنے والے اثرات میں مرئیت کو برقرار رکھنے کے لیے جدوجہد کرتے ہیں۔ مزید برآں، انجینئرز اس موقع سے محروم ہونے پر خوش نہیں ہوتے اور اس کے نتیجے میں ان کے لیے پیدا ہونے والے مسائل کے جوہر کو سمجھنا مشکل ہو جاتا ہے۔
اوپر بیان کردہ ان چیلنجوں پر کیسے قابو پایا جائے اور بڑے ادارے میں DevOps کو بڑے پیمانے پر اپنانے کی طرف کیسے جائیں؟ ماہرین صبر کی تلقین کرتے ہیں، چاہے آپ کا حتمی مقصد آپ کے سافٹ ویئر ڈویلپمنٹ سائیکل اور کاروباری عمل کو تیز کرنا ہو۔
1. یاد رکھیں کہ ثقافت کی تبدیلی میں وقت لگتا ہے۔
جین گرول، ایگزیکٹو ڈائریکٹر، ڈی او اوپس انسٹی ٹیوٹ: "میری رائے میں، DevOps کی توسیع اتنی ہی بڑھی ہوئی اور تکراری ہونی چاہیے جتنی فرتیلی ترقی (اور ثقافت کو بھی اتنا ہی چھونے والی)۔ Agile اور DevOps چھوٹی ٹیموں پر زور دیتے ہیں۔ لیکن جیسا کہ یہ ٹیمیں تعداد اور انضمام میں بڑھتی ہیں، ہمارے پاس کام کرنے کے نئے طریقے اختیار کرنے والے زیادہ سے زیادہ لوگ ہوتے ہیں، اور اس کے نتیجے میں ایک بڑے پیمانے پر ثقافتی تبدیلی ہوتی ہے۔"
2. منصوبہ بندی کرنے اور پلیٹ فارم کا انتخاب کرنے میں کافی وقت صرف کریں۔
ایرن کنزبرونر، پرفیکٹو میں لیڈ ٹیکنیکل مبشر: "کام کرنے کے لیے اسکیلنگ کے لیے، DevOps ٹیموں کو پہلے روایتی عمل، ٹولز، اور مہارتوں کو یکجا کرنا سیکھنا چاہیے، اور پھر آہستہ آہستہ DevOps کے ہر انفرادی مرحلے کی پرورش اور استحکام کرنا چاہیے۔ یہ سب صارف کی کہانیوں اور ویلیو اسٹریمز کی محتاط منصوبہ بندی کے ساتھ شروع ہوتا ہے، اس کے بعد ٹرنک پر مبنی ڈیولپمنٹ یا برانچنگ اور انضمام کوڈ کے لیے موزوں ترین طریقے استعمال کرتے ہوئے سافٹ ویئر اور ورژن کنٹرول لکھنا۔
"پھر انضمام اور جانچ کا مرحلہ آتا ہے، جہاں آٹومیشن کے لیے ایک قابل توسیع پلیٹ فارم کی ضرورت ہے۔ یہ وہ جگہ ہے جہاں DevOps ٹیموں کے لیے صحیح پلیٹ فارم کا انتخاب کرنا ضروری ہے جو ان کی مہارت کی سطح اور پروجیکٹ کے آخری اہداف کے مطابق ہو۔
اگلا مرحلہ پیداوار میں تعیناتی ہے اور اسے آرکیسٹریشن ٹولز اور کنٹینرز کا استعمال کرتے ہوئے مکمل طور پر خودکار ہونا چاہیے۔ DevOps (پروڈکشن سمیلیٹر، QA ماحول، اور اصل پیداواری ماحول) کے تمام مراحل پر ورچوئلائزڈ ماحول کا ہونا ضروری ہے اور متعلقہ نتائج حاصل کرنے کے لیے ہمیشہ ٹیسٹوں کے لیے صرف تازہ ترین ڈیٹا استعمال کریں۔ تجزیات کو ہوشیار اور تیز اور قابل عمل تاثرات کے ساتھ بڑے ڈیٹا پر کارروائی کرنے کے قابل ہونا چاہیے۔
3. جرم کو ذمہ داری سے نکالیں۔
گورڈن ہاف، ریڈ ہیٹ مبشر: "ایک ایسا نظام اور ماحول بنانا جو تجربات کی اجازت دیتا ہے اور اس کی حوصلہ افزائی کرتا ہے اس کی اجازت دیتا ہے جسے فرتیلی سافٹ ویئر کی ترقی میں کامیاب ناکامیوں کے طور پر جانا جاتا ہے۔ اس کا مطلب یہ نہیں کہ ناکامیوں کا ذمہ دار کوئی اور نہیں ہے۔ درحقیقت، ذمہ دار کون ہے اس کی شناخت کرنا اور بھی آسان ہو جاتا ہے، کیونکہ "ذمہ دار ہونے" کا مطلب اب "حادثے کا سبب بننا" نہیں ہے۔ یعنی ذمہ داری کا جوہر خوبی سے بدل جاتا ہے۔ چار عوامل اہم ہو جاتے ہیں: رکاوٹ کی حد، نقطہ نظر، پیداوار کے عمل اور مراعات۔ (آپ ان عوامل کے بارے میں گورڈن ہف کے مضمون "DevOps اسباق: صحت مند تجربات کے 4 پہلو" میں پڑھ سکتے ہیں۔)
4. آگے کا راستہ صاف کریں۔
بین گرنیل، منیجنگ ڈائریکٹر اور کنسلٹنسی نارتھ ہائی لینڈ میں ڈیجیٹل کے سربراہ: "پیمانہ حاصل کرنے کے لیے، میں ایک "پاتھ کلیئرنگ" پروگرام شروع کرنے کی تجویز کرتا ہوں جو ایک اہم پروجیکٹ کے ساتھ ہیں۔ اس پروگرام کا مقصد اس کوڑے کو صاف کرنا ہے جسے DevOps کے علمبردار اپنے پیچھے چھوڑتے ہیں، جیسے کہ فرسودہ قوانین اور اس طرح کی چیزیں، تاکہ آگے کا راستہ صاف رہے۔"
"لوگوں کو مواصلات کے ذریعے تنظیمی مدد اور رفتار فراہم کریں جو کام کرنے کے نئے طریقوں کی کامیابیوں کو بڑے پیمانے پر منا کر پیش قدمی کرنے والے گروپ سے آگے بڑھے۔ ان لوگوں کو کوچ کریں جو DevOps پروجیکٹس کی اگلی لہر میں شامل ہیں اور پہلی بار DevOps استعمال کرنے سے گھبرائے ہوئے ہیں۔ اور یاد رکھیں کہ یہ لوگ علمبرداروں سے بہت مختلف ہیں۔
5. ٹولز کو جمہوری بنانا
سٹیو نیومین، سکالر کے بانی اور چیئرمین: "آلات کو لوگوں سے چھپایا نہیں جانا چاہئے، اور ان کو سیکھنے میں نسبتاً آسان ہونا چاہئے ہر اس شخص کے لئے جو وقت میں رکھنا چاہتا ہو۔ اگر لاگز سے استفسار کرنے کی اہلیت کسی ٹول کو استعمال کرنے کے لیے "مصدقہ" تین افراد تک محدود ہے، تو آپ کے پاس ہمیشہ زیادہ سے زیادہ تین افراد اس مسئلے کو ہینڈل کرنے کے لیے دستیاب ہوں گے، چاہے آپ کے پاس کمپیوٹنگ کا بہت بڑا ماحول ہو۔ دوسرے الفاظ میں، یہاں ایک رکاوٹ ہے جو سنگین (کاروباری) نتائج کا باعث بن سکتی ہے۔
6. ٹیم ورک کے لیے مثالی حالات پیدا کریں۔
ITV میں کامن پلیٹ فارم کے سربراہ ٹام کلارک: "آپ کچھ بھی کر سکتے ہیں، لیکن سب کچھ ایک ساتھ نہیں۔ لہذا بڑے اہداف طے کریں، چھوٹی شروعات کریں، اور تیزی سے تکرار میں آگے بڑھیں۔ وقت گزرنے کے ساتھ، آپ چیزوں کو انجام دینے کے لیے شہرت پیدا کریں گے، اس لیے دوسرے بھی آپ کے طریقے استعمال کرنا چاہیں گے۔ اور ایک انتہائی موثر ٹیم بنانے کی فکر نہ کریں۔ اس کے بجائے، لوگوں کو کام کے مثالی حالات فراہم کریں اور کارکردگی اس کی پیروی کرے گی۔"
7. Conway's Law اور Kanban بورڈز کے بارے میں مت بھولنا
Logan Daigle، CollabNetVersionOne میں سافٹ ویئر ڈیلیوری اور DevOps حکمت عملی کے ڈائریکٹر: "کونوے کے قانون کے نتائج کو سمجھنا ضروری ہے۔ میرے ڈھیلے جملے میں، یہ قانون یہ بتاتا ہے کہ جو پروڈکٹس ہم بناتے ہیں اور جو عمل ہم ایسا کرنے کے لیے استعمال کرتے ہیں، بشمول DevOps، ہماری تنظیم کی طرح ہی ساختہ ہوتے ہیں۔"
"اگر کسی تنظیم میں بہت زیادہ سائلوز موجود ہیں، اور سافٹ ویئر کی منصوبہ بندی، تعمیر اور جاری کرتے وقت کنٹرول کئی بار تبدیل ہوتا ہے، تو اسکیلنگ کا اثر صفر یا قلیل المدت ہوگا۔ اگر کوئی تنظیم ایسی مصنوعات کے ارد گرد کراس فنکشنل ٹیمیں بناتی ہے جن کی مالی اعانت مارکیٹ پر مرکوز ہوتی ہے، تو کامیابی کے امکانات ڈرامائی طور پر بڑھ جاتے ہیں۔"
"اسکیلنگ کا ایک اور اہم پہلو کنبن بورڈز پر جاری تمام کام (WIP، workinprogress) کو ظاہر کرنا ہے۔ جب کسی تنظیم کے پاس ایسی جگہ ہوتی ہے جہاں لوگ ان چیزوں کو دیکھ سکتے ہیں، تو یہ تعاون کی حوصلہ افزائی کرتا ہے، جس کا اسکیلنگ پر مثبت اثر پڑتا ہے۔"
8. پرانے نشانات تلاش کریں۔
Manuel Pais، DevOps کنسلٹنٹ اور ٹیم Topologies کے شریک مصنف: "DevOps کے طریقوں کو خود Dev اور Ops سے آگے لے جانا اور انہیں دوسرے فنکشنز پر لاگو کرنے کی کوشش کرنا شاید ہی ایک بہترین طریقہ ہے۔ یہ یقینی طور پر کچھ اثر ڈالے گا (مثال کے طور پر، خودکار دستی کنٹرول کے ذریعے)، لیکن اگر ہم ڈیلیوری اور فیڈ بیک کے عمل کو سمجھنے کے ساتھ شروع کریں تو بہت کچھ حاصل کیا جا سکتا ہے۔"
"اگر کسی تنظیم کے آئی ٹی سسٹم میں پرانے داغ ہیں - طریقہ کار اور انتظامی طریقہ کار جو ماضی کے واقعات کے نتیجے میں لاگو کیا گیا تھا، لیکن وہ اپنی مطابقت کھو چکے ہیں (مصنوعات، ٹیکنالوجیز یا عمل میں تبدیلیوں کی وجہ سے) - تو انہیں یقینی طور پر ہٹانے کی ضرورت ہے۔ یا غیر موثر یا غیر ضروری عمل کو خودکار بنانے کے بجائے ہموار کر دیا گیا۔"
9. DevOps کے اختیارات کی افزائش نہ کریں۔
اینتھونی ایڈورڈز، بینگن میں آپریشنز کے ڈائریکٹر: "DevOps ایک بہت ہی مبہم اصطلاح ہے، لہذا ہر ٹیم کا اختتام DevOps کے اپنے ورژن کے ساتھ ہوتا ہے۔ اور اس سے بدتر کوئی بات نہیں ہے جب کسی تنظیم کے پاس اچانک ڈی او اوپس کی 20 قسمیں ہوں جو آپس میں اچھی طرح سے نہیں ملتی ہیں۔ تینوں ترقیاتی ٹیموں میں سے ہر ایک کے لیے ترقی اور مصنوعات کے انتظام کے درمیان اپنا، خصوصی انٹرفیس ہونا ناممکن ہے۔ اور نہ ہی جب پروڈکشن سمیلیٹر کو منتقل کیا جاتا ہے تو آراء کو سنبھالنے کے لیے مصنوعات کی اپنی منفرد توقعات نہیں ہونی چاہئیں۔ بصورت دیگر، آپ کبھی بھی DevOps کی پیمائش نہیں کر پائیں گے۔
10. DevOps کی کاروباری قدر کی تبلیغ کریں۔
سٹیو نیومین، سکالر کے بانی اور چیئرمین: "DevOps کی قدر کو پہچاننے کے لیے کام کریں۔ جانیں اور جو کچھ آپ کرتے ہیں اس کے فوائد کے بارے میں بلا جھجھک بات کریں۔ DevOps ایک ناقابل یقین وقت اور پیسہ بچانے والا ہے (ذرا سوچیں: کم ڈاؤن ٹائم، بحالی کا کم وقت)، اور DevOps ٹیموں کو کاروباری کامیابی کے لیے ان اقدامات کی اہمیت پر انتھک زور دینا چاہیے (اور تبلیغ) کرنا چاہیے۔ اس طرح آپ پیروکاروں کے حلقے کو بڑھا سکتے ہیں اور تنظیم میں DevOps کے اثر و رسوخ کو بڑھا سکتے ہیں۔"
بونس
پر ہمارے اپنے DevOps 13 ستمبر کو پہنچیں گے - ہاں، Red Hat، ایک سافٹ ویئر بنانے والے کے طور پر، اس کی اپنی DevOps ٹیمیں اور مشقیں ہیں۔
ہمارا انجینئر مارک برگر، جو پوری تنظیم میں دوسرے گروپس کے لیے اندرونی آٹومیشن سروسز تیار کرتا ہے، اپنی کہانی واضح روسی زبان میں بتائے گا - کہ کس طرح Red Hat DevOps ٹیم نے Hat Virtualization ورچوئل ماحول سے ایپلی کیشنز کو Ansible کے زیر انتظام مکمل کنٹینر فارمیٹ میں منتقل کیا۔ اوپن شفٹ پلیٹ فارم۔
لیکن یہ سب کچھ نہیں ہے:
ایک بار جب تنظیمیں کام کے بوجھ کو کنٹینرز میں منتقل کر دیتی ہیں، تو ہو سکتا ہے روایتی ایپلیکیشن مانیٹرنگ کے طریقے کام نہ کریں۔ دوسری گفتگو میں ہم لاگ ان کرنے کے طریقے کو تبدیل کرنے کے لیے اپنے محرک کی وضاحت کریں گے اور اس راستے کا تسلسل دکھائیں گے جس نے ہمیں لاگنگ اور نگرانی کے جدید طریقوں کی طرف لے جایا۔
ماخذ: www.habr.com