روس 2020 میں DevOps کی ریاست

کسی چیز کی حالت کو کیسے سمجھیں؟

آپ اپنی رائے پر بھروسہ کر سکتے ہیں، جو معلومات کے مختلف ذرائع سے بنائی گئی ہے، مثال کے طور پر، ویب سائٹس یا تجربے پر اشاعتیں۔ آپ اپنے ساتھیوں، جاننے والوں سے پوچھ سکتے ہیں۔ ایک اور آپشن یہ ہے کہ کانفرنسوں کے موضوعات کو دیکھیں: پروگرام کمیٹی صنعت کے فعال نمائندے ہیں، اس لیے ہم متعلقہ عنوانات کے انتخاب میں ان پر بھروسہ کرتے ہیں۔ ایک الگ شعبہ تحقیق اور رپورٹس ہے۔ لیکن ایک مسئلہ ہے۔ ڈی او اوپس کی حالت پر دنیا میں ہر سال تحقیق کی جاتی ہے، رپورٹیں غیر ملکی کمپنیاں شائع کرتی ہیں، اور روسی ڈی او اوپس کے بارے میں تقریباً کوئی معلومات نہیں ہیں۔

لیکن وہ دن آ گیا ہے جب اس طرح کا مطالعہ کیا گیا تھا، اور آج ہم نتائج کے بارے میں بات کریں گے. روس میں DevOps کی حالت کا مشترکہ طور پر کمپنیوں نے مطالعہ کیا تھا۔ایکسپریس 42"اور"اونٹیکو" Express 42 ٹیکنالوجی کمپنیوں کو DevOps طریقوں اور ٹولز کو نافذ کرنے اور تیار کرنے میں مدد کرتا ہے اور وہ روس میں DevOps کے بارے میں بات کرنے والے پہلے لوگوں میں سے ایک تھا۔ مطالعہ کے مصنفین، Igor Kurochkin اور Vitaly Khabarov، ایکسپریس 42 میں تجزیہ اور مشاورت میں مصروف ہیں، جبکہ مختلف کمپنیوں میں آپریشن اور تجربہ کا تکنیکی پس منظر رکھتے ہیں۔ 8 سالوں سے، ساتھیوں نے درجنوں کمپنیوں اور پروجیکٹس کو دیکھا ہے - اسٹارٹ اپ سے لے کر انٹرپرائزز تک - مختلف مسائل کے ساتھ ساتھ مختلف ثقافتی اور انجینئرنگ کی پختگی کے ساتھ۔

اپنی رپورٹ میں، ایگور اور وٹالی نے بتایا کہ تحقیق کے عمل میں کیا مسائل تھے، انہوں نے انہیں کیسے حل کیا، ساتھ ہی ڈی او اوپس کی تحقیق اصولی طور پر کیسے کی جاتی ہے اور ایکسپریس 42 نے خود ہی کرنے کا فیصلہ کیوں کیا۔ ان کی رپورٹ دیکھی جا سکتی ہے۔ یہاں.

ڈی او اوپس ریسرچ

گفتگو کا آغاز Igor Kurochkin نے کیا۔

ہم DevOps کانفرنسوں میں سامعین سے باقاعدگی سے پوچھتے ہیں، "کیا آپ نے اس سال کے لیے DevOps اسٹیٹس رپورٹ پڑھی ہے؟" کچھ لوگ اپنے ہاتھ اٹھاتے ہیں، اور ہمارے مطالعے سے پتہ چلتا ہے کہ صرف ایک تہائی ان کا مطالعہ کرتا ہے۔ اگر آپ نے ایسی رپورٹس کبھی نہیں دیکھی ہیں تو فوراً کہہ دیتے ہیں کہ وہ سب بہت ملتے جلتے ہیں۔ اکثر ایسے جملے ہوتے ہیں جیسے: "گزشتہ سال کے مقابلے..."

یہاں ہمارے پاس پہلا مسئلہ ہے، اور اس کے بعد دو اور:

1. ہمارے پاس پچھلے سال کا ڈیٹا نہیں ہے۔ روس میں DevOps کی حالت کسی کے لیے دلچسپی نہیں رکھتی۔
2. طریقہ کار. یہ واضح نہیں ہے کہ مفروضوں کی جانچ کیسے کی جائے، سوالات کیسے بنائے جائیں، تجزیہ کیسے کریں، نتائج کا موازنہ کریں، کنکشن تلاش کریں۔
3. اصطلاحات تمام رپورٹس انگریزی میں ہیں، ترجمہ درکار ہے، ایک مشترکہ DevOps فریم ورک ابھی تک ایجاد نہیں ہوا ہے اور ہر کوئی اپنا اپنا لے کر آتا ہے۔

آئیے اس پر ایک نظر ڈالتے ہیں کہ پوری دنیا میں DevOps ریاستی تجزیے کیسے کیے گئے ہیں۔

تاریخی معلومات

DevOps تحقیق 2011 سے کی گئی ہے۔ کٹھ پتلی، کنفیگریشن مینجمنٹ سسٹمز کا ایک ڈویلپر، ان کا انعقاد کرنے والا پہلا شخص تھا۔ اس وقت، یہ بنیادی ڈھانچے کو کوڈ کی شکل میں بیان کرنے کا ایک اہم ذریعہ تھا۔ 2013 تک، یہ مطالعات صرف بند سروے تھے اور کوئی عوامی رپورٹ نہیں تھی۔

2013 میں، IT Revolution نمودار ہوا، جو DevOps پر تمام بڑی کتابوں کا پبلشر ہے۔ Puppet کے ساتھ مل کر، انہوں نے پہلی اسٹیٹ آف DevOps اشاعت تیار کی، جہاں پہلی بار 4 کلیدی میٹرکس نمودار ہوئے۔ اگلے سال، ThoughtWorks، ایک مشاورتی فرم جو صنعت کے طریقوں اور آلات پر اپنے باقاعدہ ٹیکنالوجی کے ریڈار کے لیے مشہور ہے، اس میں شامل ہو گئی۔ اور 2015 میں، طریقہ کار کے ساتھ ایک سیکشن شامل کیا گیا، اور یہ واضح ہو گیا کہ وہ کس طرح تجزیہ کرتے ہیں۔

2016 میں، مطالعہ کے مصنفین نے، اپنی کمپنی DORA (DevOps ریسرچ اینڈ اسیسمنٹ) بنائی، ایک سالانہ رپورٹ شائع کی۔ اگلے سال، DORA اور Puppet نے اپنی آخری مشترکہ رپورٹ جاری کی۔

اور پھر کچھ دلچسپ شروع ہوا:

2018 میں، کمپنیاں الگ ہوگئیں اور دو آزاد رپورٹیں جاری کی گئیں: ایک پپیٹ سے، دوسری گوگل کے ساتھ DORA کی طرف سے۔ DORA نے کلیدی میٹرکس، پرفارمنس پروفائلز، اور انجینئرنگ پریکٹسز کے ساتھ اپنے طریقہ کار کا فائدہ اٹھانا جاری رکھا ہے جو کلیدی میٹرکس اور کمپنی کی وسیع کارکردگی کو متاثر کرتے ہیں۔ اور کٹھ پتلی نے عمل کی تفصیل اور ڈی او اوپس کے ارتقاء کے ساتھ اپنا نقطہ نظر پیش کیا۔ لیکن کہانی جڑ نہیں پکڑی، 2019 میں کٹھ پتلی نے اس طریقہ کار کو ترک کر دیا اور رپورٹس کا ایک نیا ورژن جاری کیا، جس میں کلیدی طریقوں کی فہرست دی گئی تھی اور وہ اپنے نقطہ نظر سے DevOps کو کیسے متاثر کرتے ہیں۔ پھر ایک اور واقعہ پیش آیا: گوگل نے ڈورا خریدا، اور انہوں نے مل کر ایک اور رپورٹ جاری کی۔ آپ نے اسے دیکھا ہوگا۔

اس سال، چیزیں پیچیدہ ہوگئیں۔ کٹھ پتلی نے اپنا سروے شروع کیا ہے۔ انہوں نے یہ ہم سے ایک ہفتہ پہلے کیا تھا، اور یہ پہلے ہی ختم ہو چکا ہے۔ ہم نے اس میں حصہ لیا اور دیکھا کہ وہ کن موضوعات میں دلچسپی رکھتے ہیں۔ اب کٹھ پتلی اپنا تجزیہ کر رہا ہے اور رپورٹ شائع کرنے کی تیاری کر رہا ہے۔

لیکن ڈورا اور گوگل کی طرف سے ابھی تک کوئی اعلان نہیں ہوا ہے۔ مئی میں، جب سروے عام طور پر شروع ہوا، معلومات آئی کہ نکول فورسگرین، DORA کے بانیوں میں سے ایک، دوسری کمپنی میں منتقل ہو گئی ہیں۔ لہذا، ہم نے فرض کیا کہ اس سال DORA کی طرف سے کوئی تحقیق اور رپورٹ نہیں آئے گی۔

روس میں حالات کیسے ہیں؟

ہم نے DevOps تحقیق نہیں کی ہے۔ ہم نے کانفرنسوں میں بات کی، دوسرے لوگوں کے نتائج کو دوبارہ بیان کیا، اور Raiffeisenbank نے 2019 کے لیے "State of DevOps" کا ترجمہ کیا (آپ ان کا اعلان Habré پر دیکھ سکتے ہیں)، ان کا بہت شکریہ۔ اور یہ سب ہے.

لہذا، ہم نے روس میں DORA کے طریقہ کار اور نتائج کا استعمال کرتے ہوئے اپنی تحقیق کی۔ ہم نے اپنی تحقیق کے لیے Raiffeisenbank کے ساتھیوں کی رپورٹ کا استعمال کیا، بشمول اصطلاحات اور ترجمے کی ہم آہنگی کے لیے۔ اور صنعت سے متعلقہ سوالات DORA رپورٹس اور اس سال کے Puppet سوالنامے سے لیے گئے تھے۔

تحقیقی عمل

رپورٹ صرف آخری حصہ ہے۔ تحقیق کا پورا عمل چار بڑے مراحل پر مشتمل ہے:

تیاری کے مرحلے کے دوران، ہم نے صنعت کے ماہرین سے انٹرویو کیا اور مفروضوں کی ایک فہرست تیار کی۔ ان کی بنیاد پر سوالات مرتب کیے گئے اور پورے اگست کے لیے ایک سروے شروع کیا گیا۔ پھر ہم نے خود تجزیہ کیا اور رپورٹ تیار کی۔ DORA کے لیے، اس عمل میں 6 ماہ لگتے ہیں۔ ہماری ملاقات 3 ماہ کے اندر ہوئی، اور اب ہم سمجھتے ہیں کہ ہمارے پاس بمشکل ہی کافی وقت تھا: صرف تجزیہ کرنے سے ہی آپ سمجھ سکتے ہیں کہ آپ کو کون سے سوالات پوچھنے کی ضرورت ہے۔

شرکاء

تمام غیر ملکی رپورٹیں شرکاء کے پورٹریٹ سے شروع ہوتی ہیں اور ان میں سے زیادہ تر کا تعلق روس سے نہیں ہے۔ روسی جواب دہندگان کی فیصد میں سال بہ سال 5 اور 1% کے درمیان اتار چڑھاؤ آتا ہے، اور یہ کوئی نتیجہ اخذ کرنے کی اجازت نہیں دیتا ہے۔

ایکسلریٹ اسٹیٹ آف ڈی او اوپس 2019 کی رپورٹ سے نقشہ:

اپنے مطالعے میں، ہم 889 لوگوں کے انٹرویو کرنے میں کامیاب ہوئے - یہ بہت زیادہ ہے (DORA اپنی رپورٹوں میں سالانہ ایک ہزار لوگوں کے بارے میں سروے کرتا ہے) اور یہاں ہم نے ہدف حاصل کیا ہے:

سچ ہے، ہمارے تمام شرکاء اختتام کو نہیں پہنچے: تکمیل کا فیصد نصف سے تھوڑا کم نکلا۔ لیکن یہ بھی نمائندہ نمونہ حاصل کرنے اور تجزیہ کرنے کے لیے کافی تھا۔ DORA اپنی رپورٹوں میں فل فی صد ظاہر نہیں کرتا، اس لیے یہاں کوئی موازنہ نہیں ہے۔

صنعتیں اور عہدے

ہمارے جواب دہندگان ایک درجن صنعتوں کی نمائندگی کرتے ہیں۔ انفارمیشن ٹیکنالوجی میں آدھا کام۔ اس کے بعد مالیاتی خدمات، تجارت، ٹیلی کمیونیکیشن اور دیگر شامل ہیں۔ عہدوں میں ماہرین (ڈیولپر، ٹیسٹر، آپریشن انجینئر) اور انتظامی عملہ (ٹیموں کے سربراہان، گروپس، علاقوں، ڈائریکٹرز):

دو میں سے ایک درمیانے درجے کی کمپنی کے لیے کام کرتا ہے۔ ہر تیسرا شخص بڑی کمپنیوں میں کام کرتا ہے۔ زیادہ تر 9 افراد تک کی ٹیموں میں کام کرتے ہیں۔ الگ الگ، ہم نے اہم سرگرمیوں کے بارے میں پوچھا، اور اکثریت کسی نہ کسی طرح آپریشن سے متعلق ہے، اور تقریباً 40% ترقی میں مصروف ہیں:

لہذا ہم نے مختلف صنعتوں، کمپنیوں، ٹیموں کے نمائندوں کے موازنہ اور تجزیہ کے لیے معلومات اکٹھی کیں۔ میرا ساتھی Vitaly Khabarov تجزیہ کے بارے میں بتائے گا.

تجزیہ اور موازنہ

Vitaly Khabarov: تمام شرکاء کا بہت شکریہ جنہوں نے ہمارا سروے مکمل کیا، سوالنامے پُر کیے اور ہمیں اپنے مفروضوں کے مزید تجزیہ اور جانچ کے لیے ڈیٹا فراہم کیا۔ اور اپنے گاہکوں اور گاہکوں کا شکریہ، ہمارے پاس بہت زیادہ تجربہ ہے جس نے صنعت کے خدشات کی نشاندہی کرنے اور ان مفروضوں کو وضع کرنے میں مدد کی ہے جن کا ہم نے اپنی تحقیق میں تجربہ کیا ہے۔

بدقسمتی سے، آپ صرف ایک طرف سوالات کی فہرست اور دوسری طرف ڈیٹا نہیں لے سکتے، کسی طرح ان کا موازنہ کریں، کہیں: "ہاں، سب کچھ ایسا ہی کام کرتا ہے، ہم ٹھیک تھے" اور منتشر ہو جائیں۔ نہیں، ہمیں اس بات کا یقین کرنے کے لیے طریقہ کار اور شماریاتی طریقوں کی ضرورت ہے کہ ہم غلط نہ ہوں اور ہمارے نتائج قابل اعتماد ہوں۔ پھر ہم ان اعداد و شمار کی بنیاد پر اپنا مزید کام بنا سکتے ہیں:

کلیدی میٹرکس

ہم نے DORA کے طریقہ کار کو ایک بنیاد کے طور پر لیا، جسے انہوں نے کتاب "ایکسلریٹ اسٹیٹ آف ڈی او اوپس" میں تفصیل سے بیان کیا ہے۔ ہم نے چیک کیا کہ آیا کلیدی میٹرکس روسی مارکیٹ کے لیے موزوں ہیں، کیا انہیں اسی طرح استعمال کیا جا سکتا ہے جیسا کہ DORA اس سوال کا جواب دینے کے لیے استعمال کرتا ہے: "روس میں صنعت غیر ملکی صنعت سے کیسے مطابقت رکھتی ہے؟"

کلیدی میٹرکس:

1. تعیناتی کی تعدد۔ ایپلیکیشن کا نیا ورژن کتنی بار پروڈکشن ماحول میں لگایا جاتا ہے (منصوبہ بند تبدیلیاں، ہاٹ فکسز اور واقعے کے ردعمل کو چھوڑ کر)؟
2. ڈیلیوری کا وقت۔ تبدیلی کرنے (کوڈ کے طور پر فعالیت لکھنے) اور تبدیلی کو پیداواری ماحول میں تعینات کرنے کے درمیان اوسط وقت کیا ہے؟
3. ٹھیک ہونے کا وقت. کسی واقعے، سروس کے انحطاط، یا ایپلیکیشن کے صارفین کو متاثر کرنے والے بگ کی دریافت کے بعد کسی ایپلیکیشن کو پیداواری ماحول میں بحال کرنے میں اوسطاً کتنا وقت لگتا ہے؟
4. ناکام تبدیلیاں۔ پیداواری ماحول میں تعیناتیوں کا کتنا فیصد ایپلی کیشن میں کمی یا واقعات کا باعث بنتا ہے اور تدارک کی ضرورت ہوتی ہے (تبدیلیوں کا رول بیک، ہاٹ فکس یا پیچ کی ترقی)؟

DORA نے اپنی تحقیق میں ان میٹرکس اور تنظیمی کارکردگی کے درمیان تعلق پایا ہے۔ ہم اپنے مطالعے میں بھی اس کی جانچ کرتے ہیں۔

لیکن اس بات کو یقینی بنانے کے لیے کہ چار کلیدی میٹرکس کسی چیز پر اثر انداز ہو سکتے ہیں، آپ کو سمجھنے کی ضرورت ہے - کیا وہ کسی طرح ایک دوسرے سے متعلق ہیں؟ DORA نے ایک انتباہ کے ساتھ اثبات میں جواب دیا: ناکام تبدیلیوں (تبدیلی کی ناکامی کی شرح) اور تین دیگر میٹرکس کے درمیان تعلق قدرے کمزور ہے۔ ہمیں اسی تصویر کے بارے میں ملا۔ اگر ڈیلیوری کا وقت، تعیناتی کی فریکوئنسی، اور بحالی کا وقت ایک دوسرے کے ساتھ منسلک ہوتے ہیں (ہم نے پیئرسن ارتباط اور چاڈاک اسکیل کے ذریعے اس ارتباط کو قائم کیا)، تو ناکام تبدیلیوں کے ساتھ ایسا کوئی مضبوط تعلق نہیں ہے۔

اصولی طور پر، زیادہ تر جواب دہندگان جواب دیتے ہیں کہ ان کی پیداوار میں واقعات کی تعداد بہت کم ہے۔ اگرچہ ہم بعد میں دیکھیں گے کہ ناکام تبدیلیوں کے لحاظ سے جواب دہندگان کے گروپوں کے درمیان اب بھی ایک اہم فرق ہے، ہم ابھی تک اس تقسیم کے لیے اس میٹرک کو استعمال نہیں کر سکتے۔

ہم اسے اس حقیقت سے منسوب کرتے ہیں کہ (جیسا کہ یہ ہمارے کچھ صارفین کے ساتھ تجزیہ اور بات چیت کے دوران ہوا) اس کے تصور میں تھوڑا سا فرق ہے جسے ایک واقعہ سمجھا جاتا ہے۔ اگر ہم تکنیکی ونڈو کے دوران اپنی سروس کی کارکردگی کو بحال کرنے میں کامیاب ہو گئے تو کیا اسے ایک واقعہ سمجھا جا سکتا ہے؟ شاید نہیں، کیونکہ ہم نے سب کچھ ٹھیک کر دیا، ہم عظیم ہیں۔ کیا ہم اسے ایک واقعہ سمجھ سکتے ہیں اگر ہمیں اپنی درخواست کو 10 بار ایک عام، مانوس موڈ میں دوبارہ رول کرنا پڑے؟ ایسا نہیں لگتا۔ لہذا، دیگر میٹرکس کے ساتھ ناکام تبدیلیوں کے تعلق کا سوال کھلا رہتا ہے۔ ہم اسے مزید بہتر کریں گے۔

یہاں اہم بات یہ ہے کہ ہمیں ڈیلیوری کے اوقات، بازیابی کے اوقات، اور تعیناتی کی تعدد کے درمیان ایک اہم ارتباط ملا۔ لہذا، ہم نے جواب دہندگان کو کارکردگی کے گروپوں میں مزید تقسیم کرنے کے لیے ان تین میٹرکس کو لیا۔

گرام میں کتنا لٹکنا ہے؟

ہم نے درجہ بندی کے کلسٹر تجزیہ کا استعمال کیا:

• ہم جواب دہندگان کو ایک n-جہتی جگہ پر تقسیم کرتے ہیں، جہاں ہر جواب دہندہ کا کوآرڈینیٹ ان کے سوالات کے جوابات ہوتا ہے۔
• ہر جواب دہندہ کو ایک چھوٹا کلسٹر قرار دیا جاتا ہے۔
• ہم ایک دوسرے کے قریب ترین دو کلسٹرز کو ایک بڑے کلسٹر میں جوڑ دیتے ہیں۔
• ہم کلسٹرز کا اگلا جوڑا ڈھونڈتے ہیں اور انہیں ایک بڑے کلسٹر میں جوڑ دیتے ہیں۔

اس طرح ہم اپنے تمام جواب دہندگان کو ان کلسٹروں کی تعداد میں گروپ کرتے ہیں جن کی ہمیں ضرورت ہے۔ ڈینڈروگرام (کلسٹروں کے درمیان روابط کا درخت) کی مدد سے ہم دو پڑوسی کلسٹروں کے درمیان فاصلہ دیکھتے ہیں۔ ہمارے لیے صرف یہ ہے کہ ان جھرمٹوں کے درمیان فاصلہ کی ایک مخصوص حد مقرر کی جائے اور کہا جائے: "یہ دونوں گروہ ایک دوسرے سے بالکل ممتاز ہیں کیونکہ ان کے درمیان فاصلہ بہت بڑا ہے۔"

لیکن یہاں ایک پوشیدہ مسئلہ ہے: ہمارے پاس کلسٹرز کی تعداد پر کوئی پابندی نہیں ہے - ہم 2، 3، 4، 10 کلسٹر حاصل کرسکتے ہیں۔ اور پہلا خیال یہ تھا کہ کیوں نہ ہمارے تمام جواب دہندگان کو 4 گروپوں میں تقسیم کیا جائے، جیسا کہ DORA کرتا ہے۔ لیکن ہم نے پایا کہ ان گروہوں کے درمیان اختلافات غیر معمولی ہو جاتے ہیں، اور ہم اس بات کا یقین نہیں کر سکتے کہ جواب دہندہ واقعی اس کے گروہ سے تعلق رکھتا ہے، نہ کہ پڑوسی سے۔ ہم ابھی تک روسی مارکیٹ کو چار گروپوں میں تقسیم نہیں کر سکتے۔ لہذا، ہم نے تین پروفائلز طے کیے جن کے درمیان شماریاتی لحاظ سے اہم فرق ہے:

اگلا، ہم نے کلسٹرز کے ذریعے پروفائل کا تعین کیا: ہم نے ہر گروپ کے لیے ہر میٹرک کے لیے میڈین لیا اور پرفارمنس پروفائلز کا ایک جدول مرتب کیا۔ درحقیقت، ہمیں ہر گروپ میں اوسط شریک کی کارکردگی کے پروفائلز ملے۔ ہم نے کارکردگی کے تین پروفائلز کی نشاندہی کی ہے: کم، درمیانے، اعلی:

یہاں ہم نے اپنے مفروضے کی تصدیق کی کہ 4 کلیدی میٹرکس کارکردگی کے پروفائل کا تعین کرنے کے لیے موزوں ہیں، اور وہ مغربی اور روسی دونوں بازاروں میں کام کرتے ہیں۔ گروپوں کے درمیان فرق ہے اور یہ شماریاتی لحاظ سے اہم ہے۔ میں اس بات پر زور دیتا ہوں کہ اوسط کے لحاظ سے ناکام تبدیلیوں کے میٹرک کے لحاظ سے کارکردگی کے پروفائلز کے درمیان ایک اہم فرق ہے، حالانکہ ہم نے ابتدائی طور پر جواب دہندگان کو اس پیرامیٹر سے تقسیم نہیں کیا تھا۔

پھر سوال یہ پیدا ہوتا ہے کہ یہ سب کیسے استعمال کیا جائے؟

استعمال کرنے کا طریقہ

اگر ہم کوئی بھی ٹیم، 4 کلیدی میٹرکس لیتے ہیں اور اسے ٹیبل پر لاگو کرتے ہیں، تو 85% کیسز میں ہمیں مکمل میچ نہیں ملے گا - یہ صرف ایک اوسط شریک ہے، نہ کہ حقیقت میں کیا ہے۔ ہم سب (اور ہر ٹیم) قدرے مختلف ہیں۔

ہم نے چیک کیا: ہم نے اپنے جواب دہندگان اور DORA کی کارکردگی کا پروفائل لیا، اور دیکھا کہ کتنے جواب دہندگان اس یا اس پروفائل پر فٹ ہیں۔ ہم نے پایا کہ صرف 16% جواب دہندگان یقینی طور پر پروفائلز میں سے ایک میں گرے۔ باقی سب بیچ میں کہیں بکھرے پڑے ہیں:

اس کا مطلب ہے کہ کارکردگی کی پروفائل کا دائرہ محدود ہے۔ یہ سمجھنے کے لیے کہ آپ پہلے قربت میں کہاں ہیں، آپ اس جدول کا استعمال کر سکتے ہیں: "اوہ، ایسا لگتا ہے کہ ہم درمیانے یا اعلی کے قریب ہیں!" اگر آپ سمجھتے ہیں کہ آگے کہاں جانا ہے تو یہ کافی ہو سکتا ہے۔ لیکن اگر آپ کا مقصد مستقل، مسلسل بہتری ہے، اور آپ یہ جاننا چاہتے ہیں کہ کہاں ترقی کرنی ہے اور کیا کرنا ہے، تو اضافی فنڈز کی ضرورت ہے۔ ہم نے انہیں کیلکولیٹر کہا:

• ڈورا کیلکولیٹر
• کیلکولیٹر ایکسپریس 42* (ترقی میں)
• اپنی ترقی (آپ اپنا اندرونی کیلکولیٹر بنا سکتے ہیں)۔

ان کی کیا ضرورت ہے؟ سمجھنا:

• کیا ہماری تنظیم کے اندر موجود ٹیم ہمارے معیار کے مطابق ہے؟
• اگر نہیں، تو کیا ہم اس کی مدد کر سکتے ہیں، ہماری کمپنی کی مہارت کے فریم ورک کے اندر اسے تیز کر سکتے ہیں؟
• اگر ایسا ہے تو کیا ہم اس سے بھی بہتر کر سکتے ہیں؟

آپ ان کا استعمال کمپنی کے اندر اعداد و شمار جمع کرنے کے لیے بھی کر سکتے ہیں:

• ہمارے پاس کون سی ٹیمیں ہیں؟
• ٹیموں کو پروفائلز میں تقسیم کریں۔
• دیکھیں: اوہ، یہ کمانڈز کم کارکردگی کا مظاہرہ کر رہے ہیں (وہ تھوڑا سا نہیں نکالتے ہیں)، لیکن یہ بہت اچھے ہیں: وہ ہر روز تعینات کرتے ہیں، بغیر کسی غلطی کے، ان کا لیڈ ٹائم ایک گھنٹے سے بھی کم ہوتا ہے۔

اور پھر آپ یہ جان سکتے ہیں کہ ہماری کمپنی کے اندر ان ٹیموں کے لیے ضروری مہارت اور آلات موجود ہیں جو ابھی تک برابر نہیں ہیں۔

یا، اگر آپ سمجھتے ہیں کہ آپ کمپنی کے اندر بہت اچھا محسوس کرتے ہیں، آپ بہت سے لوگوں سے بہتر ہیں، تو آپ تھوڑا سا وسیع نظر آ سکتے ہیں۔ یہ صرف روسی صنعت ہے: کیا ہم خود کو تیز کرنے کے لیے روسی صنعت میں ضروری مہارت حاصل کر سکتے ہیں؟ ایکسپریس 42 کیلکولیٹر یہاں مدد کرے گا (یہ ترقی کے مراحل میں ہے)۔ اگر آپ نے روسی مارکیٹ کو پیچھے چھوڑ دیا ہے، تو پھر دیکھو ڈورا کیلکولیٹر اور عالمی منڈی میں۔

ٹھیک. اور اگر آپ DORA کیلکولیٹر پر ایلیٹ گروپ میں ہیں، تو آپ کو کیا کرنا چاہیے؟ یہاں کوئی اچھا حل نہیں ہے۔ آپ غالباً صنعت میں سب سے آگے ہیں، اور مزید تیزرفتاری اور قابل اعتماد اندرونی R&D اور مزید وسائل خرچ کرنے سے ممکن ہے۔

آئیے سب سے پیارے موازنہ کی طرف چلتے ہیں۔

مقابلے

ہم شروع میں روسی صنعت کا مغربی صنعت سے موازنہ کرنا چاہتے تھے۔ اگر ہم براہ راست موازنہ کریں، تو ہم دیکھتے ہیں کہ ہمارے پاس پروفائلز کم ہیں، اور وہ ایک دوسرے کے ساتھ کچھ زیادہ گھل مل گئے ہیں، سرحدیں کچھ زیادہ دھندلی ہیں:

ہمارے ایلیٹ اداکار اعلیٰ اداکاروں میں چھپے ہوئے ہیں، لیکن وہ وہاں موجود ہیں - یہ وہ اشرافیہ، ایک تنگاوالا ہیں جو اہم بلندیوں پر پہنچ چکے ہیں۔ روس میں، ایلیٹ پروفائل اور ہائی پروفائل کے درمیان فرق ابھی کافی اہم نہیں ہے۔ ہمارا خیال ہے کہ مستقبل میں یہ علیحدگی انجینئرنگ کلچر میں اضافے، انجینئرنگ کے طریقوں کے نفاذ کے معیار اور کمپنیوں کے اندر مہارت کی وجہ سے ہو گی۔

اگر ہم روسی صنعت کے اندر براہ راست موازنہ پر جائیں تو ہم دیکھ سکتے ہیں کہ ہائی پروفائل ٹیمیں ہر لحاظ سے بہتر ہیں۔ ہم نے اپنے مفروضے کی بھی تصدیق کی کہ ان میٹرکس اور تنظیمی کارکردگی کے درمیان تعلق ہے: ہائی پروفائل ٹیموں کے نہ صرف اہداف حاصل کرنے کا امکان بہت زیادہ ہوتا ہے، بلکہ ان سے تجاوز بھی ہوتا ہے۔
آئیے ہائی پروفائل ٹیمیں بنیں اور یہیں نہیں رکیں:

لیکن یہ سال خاص ہے، اور ہم نے یہ چیک کرنے کا فیصلہ کیا کہ کمپنیاں وبائی مرض میں کیسے کام کر رہی ہیں: ہائی پروفائل ٹیمیں صنعت کی اوسط سے کہیں بہتر اور بہتر محسوس کر رہی ہیں:

• نئی مصنوعات جاری کرنے کا امکان 1,5-2 گنا زیادہ،
• ایپلی کیشن کے بنیادی ڈھانچے کی وشوسنییتا اور/یا کارکردگی کو بہتر بنانے کا امکان 2 گنا زیادہ ہے۔

یعنی وہ قابلیت جو پہلے ہی ان کی مدد کر چکی تھی تیزی سے ترقی کرنے، نئی مصنوعات شروع کرنے، موجودہ مصنوعات میں ترمیم کرنے، اس طرح نئی منڈیوں اور نئے صارفین کو فتح کرنے میں:

ہماری ٹیموں کو اور کیا مدد ملی؟

انجینئرنگ کے طریقوں

میں آپ کو ہر ایک مشق کے لیے اہم نتائج کے بارے میں بتاؤں گا جس کا ہم نے تجربہ کیا۔ شاید کسی اور چیز نے ٹیموں کی مدد کی، لیکن ہم DevOps کے بارے میں بات کر رہے ہیں۔ اور DevOps کے اندر، ہم مختلف پروفائلز کی ٹیموں میں فرق دیکھتے ہیں۔

پلیٹ فارم بطور سروس

ہمیں پلیٹ فارم کی عمر اور ٹیم پروفائل کے درمیان کوئی اہم تعلق نہیں ملا: پلیٹ فارم کم ٹیموں اور اعلی ٹیموں دونوں کے لیے تقریباً ایک ہی وقت میں نمودار ہوئے۔ لیکن بعد کے لیے، پلیٹ فارم پروگرام کوڈ کے ذریعے کنٹرول کے لیے اوسطاً زیادہ خدمات اور مزید پروگرامنگ انٹرفیس فراہم کرتا ہے۔ اور پلیٹ فارم ٹیمیں اپنے ڈویلپرز اور ٹیموں کو پلیٹ فارم استعمال کرنے، ان کے مسائل اور پلیٹ فارم سے متعلقہ واقعات کو زیادہ کثرت سے حل کرنے، اور دوسری ٹیموں کو تعلیم دینے میں زیادہ امکان رکھتی ہیں۔

بنیادی ڈھانچہ بطور کوڈ

یہاں سب کچھ بہت معیاری ہے۔ ہمیں بنیادی ڈھانچے کے کوڈ کے کام کے آٹومیشن اور انفراسٹرکچر کے ذخیرے کے اندر کتنی معلومات محفوظ کی جاتی ہیں کے درمیان ایک تعلق ملا۔ ہائی پروفائل کمانڈز ریپوزٹریز میں مزید معلومات کو محفوظ کرتی ہیں: یہ ہے انفراسٹرکچر کنفیگریشن، CI/CD پائپ لائن، ماحولیات کی ترتیبات اور تعمیراتی پیرامیٹرز۔ وہ اس معلومات کو زیادہ کثرت سے ذخیرہ کرتے ہیں، انفراسٹرکچر کوڈ کے ساتھ بہتر کام کرتے ہیں، اور انفراسٹرکچر کوڈ کے ساتھ کام کرنے کے لیے مزید عمل اور کاموں کو خودکار بناتے ہیں۔

دلچسپ بات یہ ہے کہ ہم نے انفراسٹرکچر ٹیسٹ میں کوئی خاص فرق نہیں دیکھا۔ میں اس کو اس حقیقت سے منسوب کرتا ہوں کہ ہائی پروفائل ٹیموں میں عام طور پر زیادہ ٹیسٹ آٹومیشن ہوتی ہے۔ شاید ان کو انفراسٹرکچر ٹیسٹوں سے الگ نہیں ہونا چاہئے، بلکہ وہ ٹیسٹ جن کے ساتھ وہ ایپلی کیشنز کو چیک کرتے ہیں، اور ان کی بدولت وہ پہلے ہی دیکھتے ہیں کہ وہ کیا اور کہاں ٹوٹ چکے ہیں۔

انضمام اور ترسیل

سب سے بورنگ سیکشن، کیونکہ ہم نے تصدیق کی ہے کہ آپ کے پاس جتنی زیادہ آٹومیشن ہوگی، آپ کوڈ کے ساتھ جتنا بہتر کام کریں گے، آپ کے بہتر نتائج حاصل کرنے کے امکانات اتنے ہی زیادہ ہوں گے۔

فن تعمیر

ہم یہ دیکھنا چاہتے تھے کہ مائیکرو سروسز کارکردگی کو کیسے متاثر کرتی ہیں۔ حقیقت میں، وہ ایسا نہیں کرتے، کیونکہ مائیکرو سروسز کا استعمال کارکردگی کے اشارے میں اضافے سے وابستہ نہیں ہے۔ مائیکرو سروسز ہائی پروفائل کمانڈز اور لو پروفائل کمانڈز دونوں کے لیے استعمال ہوتی ہیں۔

لیکن جو بات اہم ہے وہ یہ ہے کہ اعلیٰ ٹیموں کے لیے، مائیکرو سروس فن تعمیر میں منتقلی انہیں آزادانہ طور پر اپنی خدمات تیار کرنے اور رول آؤٹ کرنے کی اجازت دیتی ہے۔ اگر فن تعمیر ڈویلپرز کو ٹیم کے کسی بیرونی فرد کا انتظار کیے بغیر، خود مختاری سے کام کرنے کی اجازت دیتا ہے، تو یہ رفتار بڑھانے کے لیے ایک اہم قابلیت ہے۔ اس صورت میں، مائیکرو سروسز مدد کرتی ہیں۔ اور صرف ان کا نفاذ کوئی بڑا کردار ادا نہیں کرتا۔

ہم نے یہ سب کیسے دریافت کیا؟

ہمارے پاس DORA کے طریقہ کار کو مکمل طور پر نقل کرنے کا ایک پرجوش منصوبہ تھا، لیکن وسائل کی کمی تھی۔ اگر DORA بہت زیادہ اسپانسرشپ استعمال کرتا ہے اور ان کی تحقیق میں آدھا سال لگتا ہے، تو ہم نے اپنی تحقیق بہت کم وقت میں کی۔ ہم ایک DevOps ماڈل بنانا چاہتے تھے جیسا کہ DORA کرتا ہے، اور ہم مستقبل میں ایسا کریں گے۔ اب تک ہم نے خود کو گرمی کے نقشوں تک محدود رکھا ہے:

ہم نے ہر پروفائل میں ٹیموں میں انجینئرنگ کے طریقوں کی تقسیم کو دیکھا اور پایا کہ ہائی پروفائل ٹیمیں، اوسطاً، انجینئرنگ کے طریقوں کو استعمال کرنے کا زیادہ امکان رکھتی ہیں۔ آپ اس سب کے بارے میں مزید پڑھ سکتے ہیں۔ رپورٹ.

ایک تبدیلی کے لیے، آئیے پیچیدہ اعدادوشمار سے سادہ اعداد و شمار پر جائیں۔

ہم نے اور کیا دریافت کیا ہے؟

فورم کے اوزار

ہم مشاہدہ کرتے ہیں کہ زیادہ تر کمانڈز لینکس فیملی کے OS کے ذریعے استعمال ہوتے ہیں۔ لیکن ونڈوز اب بھی رجحان میں ہے - ہمارے جواب دہندگان میں سے کم از کم ایک چوتھائی نے اس کے ایک یا دوسرے ورژن کے استعمال کو نوٹ کیا۔ ایسا لگتا ہے کہ مارکیٹ کو اس کی ضرورت ہے۔ لہذا، آپ ان صلاحیتوں کو فروغ دے سکتے ہیں اور کانفرنسوں میں پیشکشیں دے سکتے ہیں۔

آرکیسٹریٹرز میں، یہ کسی کے لیے راز نہیں ہے، Kubernetes سب سے آگے ہے (52%)۔ اگلا ان لائن آرکیسٹریٹر ڈوکر سوارم (تقریباً 12%) ہے۔ سب سے زیادہ مقبول سی آئی سسٹمز جینکنز اور گٹ لیب ہیں۔ سب سے زیادہ مقبول کنفیگریشن مینجمنٹ سسٹم Ansible ہے، اس کے بعد ہمارا پیارا شیل ہے۔

ایمیزون اس وقت کلاؤڈ ہوسٹنگ فراہم کرنے والا سرکردہ ادارہ ہے۔ روسی بادلوں کا حصہ آہستہ آہستہ بڑھ رہا ہے۔ اگلے سال یہ دیکھنا دلچسپ ہوگا کہ روسی کلاؤڈ فراہم کرنے والے کیسا محسوس کریں گے، آیا ان کا مارکیٹ شیئر بڑھے گا۔ وہ ہیں، انہیں استعمال کیا جا سکتا ہے، اور یہ اچھا ہے:

میں ایگور کو منزل دیتا ہوں، جو کچھ اور اعدادوشمار دے گا۔

طریقوں کی بازی

Igor Kurochkin: الگ سے، ہم نے جواب دہندگان سے کہا کہ وہ اس بات کی نشاندہی کریں کہ کمپنی میں انجینئرنگ کے سمجھے جانے والے طریقوں کو کس طرح تقسیم کیا جاتا ہے۔ زیادہ تر کمپنیوں میں، ایک مخلوط نقطہ نظر ہے، پیٹرن کے مختلف سیٹ پر مشتمل ہے، اور پائلٹ پروجیکٹ بہت مقبول ہیں. ہم نے پروفائلز کے درمیان تھوڑا سا فرق بھی دیکھا۔ ہائی پروفائل کے نمائندے اکثر "نیچے سے پہل" پیٹرن کا استعمال کرتے ہیں، جب ماہرین کی چھوٹی ٹیمیں کام کے طریقہ کار، ٹولز کو تبدیل کرتی ہیں اور دوسری ٹیموں کے ساتھ کامیاب طریقوں کا اشتراک کرتی ہیں۔ میڈیم میں، یہ ایک اوپر سے نیچے کی پہل ہے جو کمیونٹیز اور سنٹرز آف ایکسی لینس کی تخلیق کے ذریعے پوری کمپنی کو متاثر کرتی ہے:

فرتیلی اور ڈی او اوپس

Agile اور DevOps کے درمیان تعلق کا سوال اکثر انڈسٹری میں زیر بحث آتا ہے۔ یہ مسئلہ اسٹیٹ آف ایجائل رپورٹ برائے 2019/2020 میں بھی اٹھایا گیا ہے، لہذا ہم نے موازنہ کرنے کا فیصلہ کیا کہ کمپنیوں میں Agile اور DevOps کی سرگرمیاں کس طرح مربوط ہیں۔ ہم نے پایا کہ ایگیل کے بغیر DevOps نایاب ہے۔ جواب دہندگان میں سے نصف کے لیے، Agile کا پھیلاؤ بہت پہلے شروع ہوا، اور تقریباً 20% نے بیک وقت آغاز کا مشاہدہ کیا، اور کم پروفائل کی علامات میں سے ایک Agile اور DevOps طریقوں کی عدم موجودگی ہوگی:

کمانڈ ٹوپولاجی۔

گزشتہ سال کے آخر میں، کتابٹیم ٹوپولاجی۔"، جو کمانڈ ٹوپولاجیز کو بیان کرنے کے لیے ایک فریم ورک تجویز کرتا ہے۔ یہ ہمارے لیے دلچسپ ہو گیا کہ آیا یہ روسی کمپنیوں پر لاگو ہوتا ہے۔ اور ہم نے سوال پوچھا: "آپ کو کون سے نمونے ملتے ہیں؟"۔

جواب دہندگان میں سے نصف میں انفراسٹرکچر ٹیموں کا مشاہدہ کیا جاتا ہے، نیز ترقی، جانچ اور آپریشن کے لیے الگ الگ ٹیمیں۔ علیحدہ ڈی او اوپس ٹیموں نے 45 فیصد نوٹ کیا، جن میں ہائی کے نمائندے زیادہ عام ہیں۔ اس کے بعد کراس فنکشنل ٹیمیں آتی ہیں، جو ہائی میں بھی زیادہ عام ہیں۔ علیحدہ ایس آر ای کمانڈز ہائی، میڈیم پروفائلز میں ظاہر ہوتے ہیں اور کم پروفائل میں کم ہی نظر آتے ہیں:

DevQaOps تناسب

ہم نے فیس بک پر یہ سوال Skyeng پلیٹ فارم ٹیم کے ٹیم لیڈر سے دیکھا - وہ کمپنیوں میں ڈویلپرز، ٹیسٹرز اور ایڈمنسٹریٹرز کے تناسب میں دلچسپی رکھتا تھا۔ ہم نے اس سے پوچھا اور پروفائلز کی بنیاد پر جوابات کو دیکھا: ہائی پروفائل نمائندوں کے پاس ہر ڈویلپر کے لیے کم ٹیسٹ اور آپریشنز انجینئر ہوتے ہیں:

2021 کے منصوبے

اگلے سال کے منصوبوں میں، جواب دہندگان نے درج ذیل سرگرمیوں کو نوٹ کیا:

یہاں آپ DevOps Live 2020 کانفرنس کے ساتھ انٹرسیکشن دیکھ سکتے ہیں۔ ہم نے پروگرام کا بغور جائزہ لیا:

• بنیادی ڈھانچہ بطور مصنوعات
• DevOps تبدیلی
• DevOps طریقوں کی تقسیم
• DevSecOps
• کیس کلب اور مباحثے۔

لیکن ہماری پیشکش کا وقت تمام موضوعات کا احاطہ کرنے کے لیے کافی نہیں ہے۔ پردے کے پیچھے رہ گئے:

• پلیٹ فارم بطور سروس اور بطور پروڈکٹ؛
• بنیادی ڈھانچہ بطور کوڈ، ماحول اور بادل؛
• مسلسل انضمام اور ترسیل؛
• فن تعمیر؛
• DevSecOps پیٹرن؛
• پلیٹ فارم اور کراس فنکشنل ٹیمیں۔

رپورٹ کریں۔ ہمارے پاس 50 صفحات کا ایک بڑا حصہ ہے، اور آپ اسے مزید تفصیل سے دیکھ سکتے ہیں۔

اپ میزانی

ہم امید کرتے ہیں کہ ہماری تحقیق اور رپورٹ آپ کو ترقی، جانچ، اور آپریشنز کے لیے نئے طریقوں کے ساتھ تجربہ کرنے کی ترغیب دے گی، ساتھ ہی ساتھ آپ کو نیویگیٹ کرنے، مطالعہ میں دوسرے شرکاء کے ساتھ اپنا موازنہ کرنے، اور ان شعبوں کی نشاندہی کرنے میں مدد کرے گی جہاں آپ اپنے نقطہ نظر کو بہتر بنا سکتے ہیں۔

روس میں DevOps ریاست کے پہلے مطالعہ کے نتائج:

• کلیدی میٹرکس۔ ہم نے پایا ہے کہ کلیدی میٹرکس (ڈیلیوری کا وقت، تعیناتی کی فریکوئنسی، بحالی کا وقت، اور تبدیلی کی ناکامیاں) ترقی، جانچ، اور آپریشن کے عمل کی تاثیر کا تجزیہ کرنے کے لیے موزوں ہیں۔
• پروفائلز ہائی، میڈیم، لو۔ جمع کردہ اعداد و شمار کی بنیاد پر، ہم اعداد و شمار کے لحاظ سے اعلی، درمیانے، کم کے مختلف گروپوں کو میٹرکس، طریقوں، عمل اور ٹولز کے لحاظ سے مخصوص خصوصیات کے ساتھ الگ کر سکتے ہیں۔ ہائی پروفائل کے نمائندے کم سے بہتر نتائج دکھاتے ہیں۔ وہ اپنے اہداف کو حاصل کرنے اور اس سے زیادہ ہونے کا زیادہ امکان رکھتے ہیں۔
• اشارے، وبائی امراض اور 2021 کے منصوبے۔ اس سال ایک خاص اشارے یہ ہے کہ کمپنیوں نے وبائی مرض کا کیسے مقابلہ کیا۔ اعلیٰ نمائندوں نے بہتر کارکردگی کا مظاہرہ کیا، صارف کی بڑھتی ہوئی مصروفیت کا تجربہ کیا، اور کامیابی کی بنیادی وجوہات موثر ترقیاتی عمل اور مضبوط انجینئرنگ کلچر تھے۔
• DevOps طریقوں، اوزار اور ان کی ترقی. اگلے سال کے لیے کمپنیوں کے اہم منصوبوں میں DevOps طریقوں اور آلات کی ترقی، DevSecOps طریقوں کا تعارف، اور تنظیمی ڈھانچے میں تبدیلیاں شامل ہیں۔ اور DevOps طریقوں کا موثر نفاذ اور ترقی پائلٹ پروجیکٹس، کمیونٹیز اور سینٹرز آف ایکسی لینس کی تشکیل، کمپنی کی اوپری اور نچلی سطح پر اقدامات کی مدد سے کی جاتی ہے۔

ہم آپ کے تاثرات، کہانیاں، تاثرات سننا پسند کریں گے۔ ہم ہر ایک کا شکریہ ادا کرتے ہیں جنہوں نے مطالعہ میں حصہ لیا اور اگلے سال آپ کی شرکت کے منتظر ہیں۔

ماخذ: www.habr.com