سچ پوچھیں تو، ایوان اکثر مانیٹرنگ ڈیپارٹمنٹ کے اپنے ساتھیوں کی فضول کوششوں پر ہنستا تھا۔ انہوں نے ان میٹرکس کو نافذ کرنے کی بھرپور کوششیں کیں جو کمپنی کی انتظامیہ نے انہیں حاصل کرنے کا حکم دیا تھا۔ وہ اتنے مصروف تھے کہ وہ نہیں چاہتے تھے کہ کوئی اور کچھ کرے۔
لیکن انتظامیہ کے لیے یہ کافی نہیں تھا - انہوں نے مسلسل زیادہ سے زیادہ نئے میٹرکس کا آرڈر دیا، جو پہلے کیا جا چکا تھا اسے استعمال کرنا بہت جلد بند کر دیا۔
حال ہی میں، ہر کوئی لیڈ ٹائم کے بارے میں بات کر رہا ہے - کاروباری خصوصیات کی فراہمی کا وقت۔ میٹرک نے ایک پاگل نمبر دکھایا - ایک کام کی فراہمی کے لیے 200 دن۔ کس طرح سب نے آہ بھری اور آسمان کی طرف ہاتھ اٹھائے!
کچھ دیر بعد شور آہستہ آہستہ ختم ہو گیا اور انتظامیہ کو ایک اور میٹرک بنانے کا حکم ملا۔
یہ ایوان پر بالکل واضح تھا کہ نیا میٹرک بالکل اسی طرح خاموشی سے ایک تاریک کونے میں مر جائے گا۔
درحقیقت، ایوان نے سوچا، نمبر جاننے سے کسی کو کچھ بھی نہیں بتایا جاتا۔ 200 دن یا 2 دن - کوئی فرق نہیں ہے، کیونکہ تعداد کے ذریعہ وجہ کا تعین کرنا اور یہ سمجھنا ناممکن ہے کہ یہ اچھا ہے یا برا۔
یہ میٹرکس کا ایک عام جال ہے: ایسا لگتا ہے کہ ایک نیا میٹرک وجود کا جوہر بتائے گا اور کچھ خفیہ راز کی وضاحت کرے گا۔ ہر کوئی اس سے بہت امیدیں رکھتا ہے لیکن کسی نہ کسی وجہ سے کچھ نہیں ہوتا۔ جی ہاں، کیونکہ راز میٹرکس میں نہیں ملنا چاہیے!
آئیون کے لیے یہ ایک گزرا ہوا مرحلہ تھا۔ وہ سمجھ گیا کہ پیمائش کے لیے، اور تمام رازوں کو تلاش کرنا ضروری ہے۔ ، یعنی یہ ہے کہ یہ میٹرک بنتا ہے۔
ایک آن لائن اسٹور کے لیے، اثر و رسوخ کا مقصد اس کے کلائنٹس ہوں گے جو پیسہ لاتے ہیں، اور DevOps کے لیے، یہ وہ ٹیمیں ہوں گی جو پائپ لائن کا استعمال کرتے ہوئے ڈسٹری بیوشنز تخلیق اور رول آؤٹ کرتی ہیں۔
ایک دن، ہال میں ایک آرام دہ کرسی پر بیٹھا، ایوان نے غور سے سوچنے کا فیصلہ کیا کہ وہ DevOps میٹرکس کو کس طرح دیکھنا چاہتا ہے، اس حقیقت کو مدنظر رکھتے ہوئے کہ اثر و رسوخ کا مقصد ٹیمیں ہیں۔
DevOps میٹرکس کا مقصد
یہ واضح ہے کہ ہر کوئی ڈیلیوری کا وقت کم کرنا چاہتا ہے۔ 200 دن یقیناً اچھا نہیں ہے۔
لیکن کیسے، یہ سوال ہے؟
کمپنی سیکڑوں ٹیموں کو ملازمت دیتی ہے، اور ہزاروں ڈسٹری بیوشنز روزانہ ڈیو اوپس پائپ لائن سے گزرتی ہیں۔ اصل ترسیل کا وقت تقسیم کے طور پر ظاہر ہوگا۔ ہر ٹیم کا اپنا وقت اور اس کی اپنی خصوصیات ہوں گی۔ آپ اس گندگی کے درمیان کچھ کیسے تلاش کر سکتے ہیں؟
جواب فطری طور پر پیدا ہوا - ہمیں مسئلہ ٹیموں کو تلاش کرنے اور یہ معلوم کرنے کی ضرورت ہے کہ ان کے ساتھ کیا ہو رہا ہے اور اس میں اتنا وقت کیوں لگ رہا ہے، اور "اچھی" ٹیموں سے سیکھیں کہ ہر چیز کو تیزی سے کیسے کرنا ہے۔ اور ایسا کرنے کے لیے، آپ کو ٹیموں کے ہر DevOps اسٹینڈ پر گزارے گئے وقت کی پیمائش کرنے کی ضرورت ہے:
"سسٹم کا مقصد ٹیموں کا انتخاب اس وقت کی بنیاد پر کرنا ہوگا جب وہ اسٹینڈز سے گزرتے ہیں، یعنی نتیجے کے طور پر، ہمیں منتخب وقت کے ساتھ کمانڈز کی فہرست ملنی چاہیے، نہ کہ نمبر۔
اگر ہمیں پتہ چل جائے کہ اسٹینڈ پر مجموعی طور پر کتنا وقت صرف کیا گیا اور اسٹینڈز کے درمیان ڈاؤن ٹائم پر کتنا وقت صرف کیا گیا، تو ہم ٹیموں کو تلاش کر سکتے ہیں، انہیں کال کر سکتے ہیں اور وجوہات کو مزید تفصیل سے سمجھ سکتے ہیں اور انہیں ختم کر سکتے ہیں،" ایوان نے سوچا۔
DevOps کے لیے ڈیلیوری کے وقت کا حساب کیسے لگائیں۔
اس کا حساب لگانے کے لیے، DevOps کے عمل اور اس کے جوہر کو تلاش کرنا ضروری تھا۔
کمپنی محدود تعداد میں سسٹم استعمال کرتی ہے، اور معلومات صرف ان سے حاصل کی جا سکتی ہیں اور کہیں نہیں۔
کمپنی کے تمام کام جیرا میں رجسٹرڈ تھے۔ جب کوئی کام لیا گیا تو اس کے لیے ایک برانچ بنائی گئی، اور اس پر عمل درآمد کے بعد، بٹ بکٹ اور پل ریکوئسٹ کا عہد کیا گیا۔ جب PR (Pull Request) کو قبول کیا گیا تو، ایک تقسیم خود بخود بنائی گئی اور Nexus ریپوزٹری میں محفوظ ہو گئی۔
اس کے بعد، رول آؤٹ، خودکار اور دستی جانچ کی درستگی کو جانچنے کے لیے جینکنز کا استعمال کرتے ہوئے کئی اسٹینڈز پر تقسیم کی گئی:
ایوان نے بتایا کہ اسٹینڈ پر وقت کا حساب لگانے کے لیے کن سسٹمز سے معلومات لی جا سکتی ہیں:
- Nexus سے - تقسیم کی تخلیق کا وقت اور فولڈر کا نام جس میں کمانڈ کوڈ تھا۔
- جینکنز سے - ہر کام کے آغاز کا وقت، دورانیہ اور نتیجہ، اسٹینڈ کا نام (نوکری کے پیرامیٹرز میں)، مراحل (ملازمت کے مراحل)، Nexus میں تقسیم سے لنک۔
- آئیون نے پائپ لائن میں جیرا اور بٹ بکٹ کو شامل نہ کرنے کا فیصلہ کیا، کیونکہ... ان کا زیادہ تعلق ترقی کے مرحلے سے تھا، اور اسٹینڈز پر تیار شدہ تقسیم کو رول آؤٹ کرنے سے نہیں۔
دستیاب معلومات کی بنیاد پر، درج ذیل خاکہ تیار کیا گیا تھا:
یہ جانتے ہوئے کہ تقسیم کو بنانے میں کتنا وقت لگتا ہے اور ان میں سے ہر ایک پر کتنا وقت صرف ہوتا ہے، آپ پوری DevOps پائپ لائن (مکمل سائیکل) سے گزرنے کے کل اخراجات کا آسانی سے حساب لگا سکتے ہیں۔
آئیون کے ساتھ ختم ہونے والے DevOps میٹرکس یہ ہیں:
- تخلیق کردہ تقسیم کی تعداد
- تقسیم کا حصہ جو اسٹینڈ پر "آیا" اور "پاس" ہوا۔
- اسٹینڈ پر گزارا ہوا وقت (اسٹینڈ سائیکل)
- مکمل سائیکل (تمام اسٹینڈز کے لیے کل وقت)
- ملازمت کی مدت
- اسٹینڈز کے درمیان ڈاؤن ٹائم
- ایک ہی اسٹینڈ پر ملازمت کے آغاز کے درمیان ڈاؤن ٹائم
ایک طرف، میٹرکس نے DevOps پائپ لائن کو وقت کے لحاظ سے بہت اچھی طرح سے نمایاں کیا، دوسری طرف، انہیں بہت آسان سمجھا جاتا تھا۔
اچھے کام سے مطمئن، ایوان نے ایک پریزنٹیشن دی اور اسے انتظامیہ کے سامنے پیش کرنے چلا گیا۔
وہ اداس اور ہاتھ نیچے کیے واپس آیا۔
"یہ ایک ناکامی ہے، بھائی،" ستم ظریفی ساتھی مسکرایا...
مضمون میں مزید پڑھیں "'.
ماخذ: www.habr.com