"ڈیوپس کو کیسے نافذ کیا جائے" کا سوال برسوں سے جاری ہے، لیکن اس میں بہت سے اچھے مواد نہیں ہیں۔ بعض اوقات آپ غیر ذہین کنسلٹنٹس کے اشتہارات کا شکار ہوجاتے ہیں جنہیں اپنا وقت بیچنا پڑتا ہے، چاہے وہ کیسے بھی ہو۔ بعض اوقات یہ مبہم، انتہائی عام الفاظ ہوتے ہیں کہ کس طرح میگا کارپوریشنز کے جہاز کائنات کی وسعتوں کو جوتتے ہیں۔ سوال یہ پیدا ہوتا ہے کہ اس سے ہمیں کیا فرق پڑتا ہے؟ محترم مصنف، کیا آپ واضح طور پر اپنے خیالات کو فہرست میں ترتیب دے سکتے ہیں؟
یہ سب اس حقیقت سے پیدا ہوتا ہے کہ کمپنی کی ثقافت کی تبدیلیوں کے نتائج کے بارے میں بہت زیادہ حقیقی مشق اور سمجھ جمع نہیں ہوئی ہے۔ ثقافت میں تبدیلیاں طویل المدتی چیزیں ہیں، جن کے نتائج ایک ہفتے یا ایک مہینے میں ظاہر نہیں ہوں گے۔ ہمیں کسی ایسے شخص کی ضرورت ہے جس نے دیکھا ہو کہ کمپنیاں کس طرح بنائی گئی ہیں اور سالوں میں ناکام رہی ہیں۔
جان ولس - DevOps کے باپوں میں سے ایک۔ جان کو کئی دہائیوں کی کمپنیوں کے ساتھ کام کرنے کا تجربہ ہے۔ حال ہی میں، جان نے ان مخصوص نمونوں کو دیکھنا شروع کیا جو ان میں سے ہر ایک کے ساتھ کام کرتے وقت رونما ہوتے ہیں۔ ان آرکیٹائپس کو استعمال کرتے ہوئے، جان کمپنیوں کو DevOps تبدیلی کے حقیقی راستے پر رہنمائی کرتا ہے۔ DevOops 2018 کانفرنس سے ان کی رپورٹ کے ترجمہ میں ان آثار قدیمہ کے بارے میں مزید پڑھیں۔
اسپیکر کے بارے میں:
آئی ٹی مینجمنٹ میں 35 سال سے زیادہ، کینونیکل میں اوپن کلاؤڈ کے پیشرو کی تخلیق میں حصہ لیا، 10 اسٹارٹ اپس میں حصہ لیا، جن میں سے دو ڈیل اور ڈوکر کو فروخت کیے گئے۔ فی الحال وہ SJ Technologies میں DevOps اور ڈیجیٹل پریکٹسز کے نائب صدر ہیں۔
آگے یوحنا کے نقطہ نظر سے کہانی ہے۔
میرا نام جان ولس ہے اور مجھے ڈھونڈنے کی سب سے آسان جگہ ٹویٹر پر ہے، . میرے پاس Gmail اور GitHub پر ایک ہی عرف ہے۔ اے آپ ان کے لیے میری رپورٹس اور پیشکشوں کی ویڈیو ریکارڈنگ تلاش کر سکتے ہیں۔
میری مختلف بڑی کمپنیوں کے CIOs کے ساتھ بہت سی ملاقاتیں ہیں۔ وہ اکثر شکایت کرتے ہیں کہ وہ سمجھ نہیں پا رہے ہیں کہ DevOps کیا ہے، اور جو بھی انہیں سمجھانے کی کوشش کرتا ہے وہ کچھ مختلف کے بارے میں بات کر رہا ہے۔ ایک اور عام شکایت یہ ہے کہ DevOps کام نہیں کرتا ہے، حالانکہ ایسا لگتا ہے کہ ڈائریکٹرز سب کچھ کر رہے ہیں جیسا کہ انہیں بتایا گیا ہے۔ ہم بڑی کمپنیوں کے بارے میں بات کر رہے ہیں جو سو سال سے زیادہ پرانی ہیں۔ ان کے ساتھ بات کرنے کے بعد، میں اس نتیجے پر پہنچا کہ بہت سے مسائل کے لیے یہ اعلیٰ ٹیکنالوجی نہیں ہے جو سب سے زیادہ موزوں ہے، بلکہ نسبتاً کم ٹیکنالوجی کے حل ہیں۔ ہفتوں تک میں نے صرف مختلف محکموں کے لوگوں سے بات کی۔ پوسٹ کی پہلی تصویر میں جو آپ کو نظر آرہا ہے وہ میرا آخری پروجیکٹ ہے، تین دن کے کام کے بعد کمرہ ایسا ہی نظر آیا۔
DevOps کیا ہے؟
درحقیقت، اگر آپ 10 مختلف لوگوں سے پوچھیں، تو وہ 10 مختلف جواب دیں گے۔ لیکن یہاں دلچسپ بات یہ ہے کہ ان میں سے دس جوابات درست ہوں گے۔ یہاں کوئی غلط جواب نہیں ہے۔ میں تقریباً 10 سالوں سے DevOps میں کافی گہرا تھا، اور پہلے DevOpsDay میں پہلا امریکی تھا۔ میں یہ نہیں کہوں گا کہ میں DevOps میں شامل ہر ایک سے زیادہ ہوشیار ہوں، لیکن شاید ہی کوئی ایسا ہو جس نے اس پر زیادہ محنت کی ہو۔ مجھے یقین ہے کہ DevOps اس وقت ہوتا ہے جب انسانی سرمایہ اور ٹیکنالوجی اکٹھے ہوتے ہیں۔ ہم اکثر انسانی جہت کے بارے میں بھول جاتے ہیں، حالانکہ ہم ہر طرح کی ثقافتوں کے بارے میں بہت بات کرتے ہیں۔
اب ہمارے پاس بہت سا ڈیٹا ہے، پانچ سال کی تعلیمی تحقیق، صنعتی پیمانے پر نظریات کی جانچ۔ یہ مطالعات ہمیں جو بتاتے ہیں وہ یہ ہے کہ اگر آپ تنظیمی ثقافت میں کچھ رویے کے نمونوں کو یکجا کرتے ہیں، تو آپ 2000x کی رفتار حاصل کر سکتے ہیں۔ یہ سرعت استحکام میں مساوی بہتری سے مماثل ہے۔ یہ اس فائدے کی ایک مقداری پیمائش ہے جو DevOps کسی بھی کمپنی کو لا سکتی ہے۔ کچھ سال پہلے، میں ایک Fortune 5000 کمپنی کے CEO سے DevOps کے بارے میں بات کر رہا تھا۔ جب میں پریزنٹیشن کی تیاری کر رہا تھا تو میں بہت گھبرایا ہوا تھا کیونکہ مجھے 5 منٹ میں اپنے سالوں کے تجربے کا خلاصہ کرنا تھا۔
آخر میں میں نے مندرجہ ذیل دیا DevOps کی تعریف: یہ طریقوں اور نمونوں کا ایک مجموعہ ہے جو انسانی سرمائے کو اعلیٰ کارکردگی والے تنظیمی سرمائے میں تبدیل کرنے کے قابل بناتا ہے۔ ایک مثال ٹویوٹا نے گزشتہ 50 یا 60 سالوں سے جس طرح سے کام کیا ہے۔
(اس کے بعد، اس طرح کے خاکے بطور حوالہ مواد نہیں بلکہ مثال کے طور پر فراہم کیے گئے ہیں۔ ہر نئی کمپنی کے لیے ان کا مواد مختلف ہوگا۔ تاہم، تصویر کو الگ سے دیکھا اور بڑا کیا جا سکتا ہے۔
سب سے زیادہ کامیاب اس طرح کے طریقوں میں سے ایک ہے قیمت سٹریم کا ملاپ. اس بارے میں کئی اچھی کتابیں لکھی جاچکی ہیں جن میں سب سے کامیاب کتاب کیرن مارٹن کی ہے۔ لیکن پچھلے ایک سال کے دوران، میں اس نتیجے پر پہنچا ہوں کہ یہ نقطہ نظر بھی بہت ہائی ٹیک ہے۔ اس کے یقیناً بہت سے فوائد ہیں اور میں نے اسے بہت استعمال کیا ہے۔ لیکن جب سی ای او آپ سے پوچھتا ہے کہ اس کی کمپنی نئی ریلوں پر کیوں نہیں جا سکتی، تو ویلیو سٹریم میپنگ کے بارے میں بات کرنا بہت جلدی ہے۔ اور بھی بہت سے بنیادی سوالات ہیں جن کا جواب پہلے دینا ضروری ہے۔
میرے خیال میں میرے بہت سے ساتھیوں سے غلطی یہ ہوتی ہے کہ وہ کمپنی کو صرف پانچ نکاتی گائیڈ دیتے ہیں اور پھر چھ ماہ بعد واپس آتے ہیں اور دیکھتے ہیں کہ کیا ہوا۔ یہاں تک کہ ویلیو سٹریم میپنگ جیسی اچھی اسکیم میں بھی، بلائنڈ اسپاٹس ہیں۔ مختلف کمپنیوں کے ڈائریکٹرز کے ساتھ سینکڑوں انٹرویوز کے بعد، میں نے ایک خاص نمونہ تیار کیا ہے جو ہمیں اس مسئلے کو اس کے اجزاء میں تقسیم کرنے کی اجازت دیتا ہے، اور اب ہم ان اجزاء میں سے ہر ایک پر ترتیب سے بات کریں گے۔ کسی بھی تکنیکی حل کو لاگو کرنے سے پہلے، میں اس پیٹرن کو استعمال کرتا ہوں، اور اس کے نتیجے میں، میری تمام دیواریں خاکوں سے ڈھکی ہوئی ہیں۔ حال ہی میں میں ایک میوچل فنڈ کے ساتھ کام کر رہا تھا اور میں نے اس طرح کی 100-150 اسکیمیں ختم کیں۔
خراب ثقافت ناشتے کے لیے اچھے طریقے کھاتی ہے۔
بنیادی خیال یہ ہے: اگر تنظیم کا کلچر خود خراب ہے تو Lean, Agile, SAFE اور DevOps کی کوئی مقدار مدد نہیں کرے گی۔ یہ سکوبا گیئر کے بغیر گہرائی میں غوطہ لگانے یا ایکس رے کے بغیر کام کرنے جیسا ہے۔ دوسرے لفظوں میں، ڈرکر اور ڈیمنگ کو بیان کرنے کے لیے: ایک برا تنظیمی کلچر کسی بھی اچھے نظام کو گھٹن کے بغیر نگل جائے گا۔
اس اہم مسئلے کو حل کرنے کے لیے، آپ کو درج ذیل اقدامات کرنے کی ضرورت ہے۔
- تمام کام کو مرئی بنائیں: آپ کو تمام کام کو ظاہر کرنے کی ضرورت ہے. اس معنی میں نہیں کہ یہ ضروری طور پر کسی اسکرین پر ظاہر ہونا چاہیے، بلکہ اس معنی میں کہ یہ قابل مشاہدہ ہونا چاہیے۔
- کنسولیڈیٹڈ ورک مینجمنٹ سسٹمز: انتظامی نظام کو مضبوط کرنے کی ضرورت ہے۔ "قبائلی" علم اور ادارہ جاتی علم کے مسئلے میں، 9 میں سے 10 معاملات میں رکاوٹ لوگ ہیں۔ کتاب میں مسئلہ ایک واحد شخص، برینٹ کے ساتھ تھا، جس کی وجہ سے یہ منصوبہ مقررہ وقت سے تین سال پیچھے رہ گیا۔ اور میں ہر جگہ ان "برینٹ" میں بھاگتا ہوں۔ ان رکاوٹوں کو حل کرنے کے لیے، میں اپنی فہرست میں اگلی دو اشیاء استعمال کرتا ہوں۔
- تھیوری آف کنسٹرائنٹس میتھولوجی: پابندیوں کا نظریہ
- تعاون ہیکس: تعاون ہیکس.
- ٹویوٹا کاٹا (): میں ٹویوٹا کاٹا کے بارے میں زیادہ بات نہیں کروں گا۔ اگر دلچسپی ہے تو، میرے گیتھب پر ان موضوعات میں سے تقریباً ہر ایک پر۔
- مارکیٹ پر مبنی تنظیم: مارکیٹ پر مبنی تنظیم.
- شفٹ بائیں آڈیٹرز: سائیکل کے ابتدائی مراحل میں آڈٹ.
میں ایک تنظیم کے ساتھ کام کرنا شروع کرتا ہوں: میں کمپنی میں جاتا ہوں اور ملازمین سے بات کرتا ہوں۔ جیسا کہ آپ دیکھ سکتے ہیں، کوئی اعلی ٹیکنالوجی نہیں ہے. آپ کو بس کچھ لکھنے کی ضرورت ہے۔ میں ایک کمرے میں کئی ٹیموں کو اکٹھا کرتا ہوں اور اپنے 7 آثار قدیمہ کے نقطہ نظر سے تجزیہ کرتا ہوں کہ وہ مجھے کیا بتاتے ہیں۔ اور پھر میں انہیں خود ایک مارکر دیتا ہوں اور ان سے کہتا ہوں کہ بورڈ پر وہ سب کچھ لکھیں جو انہوں نے اب تک بلند آواز میں کہا ہے۔ عام طور پر اس قسم کی ملاقاتوں میں ایک شخص ہوتا ہے جو سب کچھ لکھ دیتا ہے، اور زیادہ سے زیادہ وہ 10% بحث لکھ سکتا ہے۔ میرے طریقہ کار سے، اس اعداد و شمار کو تقریباً 40 فیصد تک بڑھایا جا سکتا ہے۔
(اس مثال کو الگ سے دیکھا جا سکتا ہے۔ )
میرا نقطہ نظر ولیم شنائیڈر کے کام پر مبنی ہے۔ )۔ نقطہ نظر اس خیال پر مبنی ہے کہ کسی بھی تنظیم کو چار مربعوں میں تقسیم کیا جاسکتا ہے۔ میرے لیے یہ اسکیم عام طور پر ان سینکڑوں دیگر اسکیموں کے ساتھ کام کرنے کا نتیجہ ہے جو کسی تنظیم کا تجزیہ کرتے وقت پیدا ہوتی ہیں۔ فرض کریں کہ ہمارے پاس ایک تنظیم ہے جس کا کنٹرول اعلی سطح پر ہے، لیکن کم اہلیت کے ساتھ۔ یہ ایک انتہائی ناپسندیدہ آپشن ہے: جب ہر کوئی لائن پر کھڑا ہوتا ہے، لیکن کوئی نہیں جانتا کہ کیا کرنا ہے۔
کسی حد تک بہتر آپشن وہ ہے جس میں اعلیٰ سطح کا کنٹرول اور قابلیت ہو۔ اگر ایسی کمپنی منافع بخش ہے، تو شاید اسے DevOps کی ضرورت نہیں ہے۔ ایسی کمپنی کے ساتھ کام کرنا سب سے زیادہ دلچسپ ہے جس میں اعلیٰ سطح کا کنٹرول، کم اہلیت اور تعاون ہو، لیکن ساتھ ہی ساتھ ثقافت (کاشت کاری) کی اعلیٰ سطح بھی ہو۔ اس کا مطلب یہ ہے کہ کمپنی کے پاس بہت سارے لوگ ہیں جو وہاں کام کرنا پسند کرتے ہیں اور مزدوری کا کاروبار کم ہے۔
(اس مثال کو الگ سے دیکھا جا سکتا ہے۔ )
مجھے ایسا لگتا ہے کہ سخت رہنما خطوط کے ساتھ طریقے حقیقت کے حصول کی راہ میں رکاوٹ بنتے ہیں۔ خاص طور پر ویلیو سٹریم میپنگ میں، اس بارے میں بہت سے اصول ہیں کہ معلومات کو کس طرح ترتیب دیا جانا چاہیے۔ کام کے ابتدائی مراحل میں، جس کے بارے میں میں اب بات کر رہا ہوں، کسی کو بھی ان اصولوں کی ضرورت نہیں ہے۔ اگر کوئی شخص جس کے ہاتھ میں مارکر ہے بورڈ پر کمپنی کی اصل صورتحال بیان کرتا ہے، تو یہ صورتحال کو سمجھنے کا بہترین طریقہ ہے۔ ایسی معلومات ڈائریکٹرز تک نہیں پہنچتی ہیں۔ اس وقت، اس شخص کو روکنا اور یہ کہنا کہ اس نے کوئی تیر غلط طریقے سے نکالا ہے، یہ حماقت ہے۔ اس مرحلے پر، آسان اصولوں کا استعمال کرنا بہتر ہے، مثال کے طور پر: ملٹی لیول تجرید کو صرف ملٹی کلر مارکر استعمال کرکے بنایا جا سکتا ہے۔
میں دہراتا ہوں، کوئی اعلی ٹیکنالوجی نہیں۔ بلیک مارکر معروضی حقیقت کو ظاہر کرتا ہے کہ سب کچھ کیسے کام کرتا ہے۔ سرخ مارکر کے ساتھ، لوگ نشان زد کرتے ہیں کہ وہ موجودہ حالات کے بارے میں کیا پسند نہیں کرتے۔ یہ ضروری ہے کہ وہ یہ لکھیں، میں نہیں۔ جب میں میٹنگ کے بعد CIO کے پاس جاتا ہوں، تو میں 10 چیزوں کی فہرست پیش نہیں کرتا ہوں جنہیں درست کرنے کی ضرورت ہے۔ میں کمپنی کے لوگ جو کچھ کہہ رہے ہیں اور موجودہ ثابت شدہ نمونوں کے درمیان تعلق تلاش کرنے کی کوشش کرتا ہوں۔ آخر میں، نیلے رنگ کا مارکر مسئلے کے ممکنہ حل تجویز کرتا ہے۔
(اس مثال کو الگ سے دیکھا جا سکتا ہے۔ )
اس نقطہ نظر کی ایک مثال اب اوپر دی گئی ہے۔ اس سال کے آغاز میں میں نے ایک بینک میں کام کیا۔ وہاں کے سیکورٹی والے اس بات پر قائل تھے کہ انہیں ڈیزائن اور ضرورت کے جائزے کے لیے نہیں آنا چاہیے۔
(اس مثال کو الگ سے دیکھا جا سکتا ہے۔ )
اور پھر ہم نے دوسرے محکموں کے لوگوں سے بات کی اور معلوم ہوا کہ تقریباً 8 سال پہلے، سافٹ ویئر ڈویلپرز نے سیکورٹی ورکرز کو اس لیے نکال دیا کہ وہ کام سست کر رہے تھے۔ اور پھر یہ پابندی میں بدل گیا، جس کو قدر کی نگاہ سے دیکھا گیا۔ حالانکہ حقیقت میں کوئی پابندی نہیں تھی۔
ہماری میٹنگ انتہائی مبہم انداز میں آگے بڑھی: تقریباً تین گھنٹے تک پانچ مختلف ٹیمیں مجھے یہ نہیں بتا سکیں کہ کوڈ اور اسمبلی کے درمیان کیا ہو رہا ہے۔ اور یہ سب سے آسان چیز معلوم ہوگی۔ زیادہ تر DevOps کنسلٹنٹس سامنے فرض کرتے ہیں کہ ہر کوئی اسے پہلے سے جانتا ہے۔
پھر آئی ٹی گورننس کا انچارج شخص، جو چار گھنٹے تک خاموش رہا، جب ہم اس کے موضوع پر پہنچے تو اچانک جان آئی، اور کافی دیر تک ہم پر قابض رہے۔ آخر میں میں نے ان سے پوچھا کہ وہ ملاقات کے بارے میں کیا سوچتے ہیں، اور میں ان کا جواب کبھی نہیں بھولوں گا۔ اس نے کہا: "میں سوچتا تھا کہ ہمارے بینک کے پاس سافٹ ویئر فراہم کرنے کے صرف دو طریقے ہیں، لیکن اب میں جانتا ہوں کہ ان میں سے پانچ ہیں، اور میں تین کے بارے میں بھی نہیں جانتا تھا۔"
(اس مثال کو الگ سے دیکھا جا سکتا ہے۔ )
اس بینک میں آخری ملاقات سرمایہ کاری سافٹ ویئر ٹیم کے ساتھ ہوئی تھی۔ اس کے ساتھ ہی یہ پتہ چلا کہ کاغذ کی شیٹ پر مارکر کے ساتھ خاکہ لکھنا بورڈ سے بہتر ہے، اور سمارٹ بورڈ سے بھی بہتر ہے۔
جو تصاویر آپ دیکھ رہے ہیں وہ ہماری میٹنگ کے چوتھے دن ہوٹل کے کانفرنس روم کی طرح نظر آتی تھیں۔ اور ہم نے ان اسکیموں کو پیٹرن یعنی آثار قدیمہ کی تلاش کے لیے استعمال کیا۔
لہذا، میں کارکنوں سے سوالات پوچھتا ہوں، وہ تین رنگوں (سیاہ، سرخ اور نیلے) کے مارکر کے ساتھ جواب لکھتے ہیں۔ میں آثار قدیمہ کے لیے ان کے جوابات کا تجزیہ کرتا ہوں۔ اب آئیے ترتیب کے ساتھ تمام آثار قدیمہ پر تبادلہ خیال کریں۔
1. تمام کام کو مرئی بنائیں: کام کو مرئی بنائیں
زیادہ تر کمپنیاں جن کے ساتھ میں کام کرتا ہوں ان میں نامعلوم کام کی شرح بہت زیادہ ہے۔ مثال کے طور پر، یہ تب ہوتا ہے جب ایک ملازم دوسرے کے پاس آتا ہے اور بس کچھ کرنے کو کہتا ہے۔ بڑی تنظیموں میں، 60% غیر منصوبہ بند کام ہو سکتا ہے۔ اور 40% تک کام کسی بھی طرح سے دستاویزی نہیں ہے۔ اگر یہ بوئنگ ہوتا تو میں اپنی زندگی میں دوبارہ کبھی ان کے جہاز میں سوار نہ ہوتا۔ اگر صرف آدھے کام کو دستاویزی شکل دی جائے تو پتہ نہیں چلتا کہ یہ کام صحیح طریقے سے ہو رہا ہے یا نہیں۔ دوسرے تمام طریقے بیکار نکلے - کسی بھی چیز کو خودکار کرنے کی کوشش کرنے کا کوئی فائدہ نہیں ہے، کیونکہ معلوم 50% کام کا سب سے زیادہ مربوط اور واضح حصہ ہو سکتا ہے، جس کا آٹومیشن بہت اچھے نتائج نہیں دے گا، اور تمام بدترین چیزیں پوشیدہ نصف میں ہیں. دستاویزات کی عدم موجودگی میں، ہر قسم کے ہیکس اور چھپے ہوئے کام کو تلاش کرنا ناممکن ہے، نہ کہ رکاوٹوں کو تلاش کرنا، وہ "برینٹ" جن کے بارے میں میں پہلے ہی بات کر چکا ہوں۔ Dominica DeGrandis کی ایک شاندار کتاب ہے۔ . وہ انکشاف کرتی ہے۔ پانچ مختلف "ٹائم لیک" (وقت کے چور):
- عمل میں بہت زیادہ کام (WIP)
- نامعلوم انحصار
- غیر منصوبہ بند کام
- متضاد ترجیحات
- نظرانداز کام
یہ بہت قیمتی تجزیہ ہے اور کتاب بہت اچھی ہے، لیکن یہ تمام مشورے بیکار ہیں اگر صرف 50% ڈیٹا ہی نظر آئے۔ ڈومینیکا کے تجویز کردہ طریقے استعمال کیے جا سکتے ہیں اگر 90% سے اوپر کی درستگی حاصل ہو جائے۔ میں ان حالات کے بارے میں بات کر رہا ہوں جہاں باس ایک ماتحت کو 15 منٹ کا کام دیتا ہے، لیکن اس میں اسے تین دن لگتے ہیں۔ لیکن باس واقعی نہیں جانتا کہ یہ ماتحت چار یا پانچ دوسرے لوگوں پر منحصر ہے۔
فینکس پروجیکٹ ایک ایسے پروجیکٹ کے بارے میں ایک حیرت انگیز کہانی ہے جو تین سال بہت دیر سے تھا۔ اس کی وجہ سے ایک کردار کو برخاستگی کا سامنا کرنا پڑتا ہے اور وہ دوسرے کردار سے ملتا ہے جسے سقراط کی طرح پیش کیا جاتا ہے۔ وہ یہ جاننے میں مدد کرتا ہے کہ اصل میں کیا غلط ہوا ہے۔ معلوم ہوا کہ کمپنی کا ایک سسٹم ایڈمنسٹریٹر ہے، جس کا نام برینٹ ہے، اور تمام کام کسی نہ کسی طرح اس کے ذریعے ہی ہوتے ہیں۔ ایک میٹنگ میں، ماتحتوں میں سے ایک سے پوچھا جاتا ہے: ہر آدھے گھنٹے کے کام میں ایک ہفتہ کیوں لگتا ہے؟ جواب قطار نظریہ اور لٹل کے قانون کی ایک بہت ہی آسان پیشکش ہے، اور اس پریزنٹیشن میں یہ پتہ چلتا ہے کہ 90% قبضے میں، کام کے ہر گھنٹے میں 9 گھنٹے لگتے ہیں۔ ہر کام کو سات دوسرے لوگوں کو بھیجنے کی ضرورت ہے، تاکہ وہ گھنٹہ 63 گھنٹے، 7 گنا 9 بن جائے۔ میں جو کہہ رہا ہوں وہ یہ ہے کہ لٹل کے قانون یا کسی بھی پیچیدہ قطار کے نظریے کو استعمال کرنے کے لیے، آپ کے پاس کم از کم ڈیٹا ہونا ضروری ہے۔
لہذا جب میں مرئیت کے بارے میں بات کرتا ہوں، میرا مطلب یہ نہیں ہے کہ سب کچھ اسکرین پر ہے، لیکن یہ کہ آپ کے پاس کم از کم ڈیٹا موجود ہے۔ جب وہ کرتے ہیں، تو اکثر یہ پتہ چلتا ہے کہ غیر منصوبہ بند کام کی ایک بہت بڑی مقدار ہے جسے کسی نہ کسی طرح برینٹ بھیجا جا رہا ہے جب اس کی کوئی ضرورت نہیں ہے۔ اور برینٹ ایک عظیم آدمی ہے، وہ کبھی نہیں کہے گا، لیکن وہ کسی کو نہیں بتاتا کہ وہ اپنا کام کیسے کرتا ہے۔
جب کام نظر آتا ہے، تو ڈیٹا کو صاف ستھرا درجہ بندی کیا جا سکتا ہے (تصویر میں ڈومینیکا یہی کر رہی ہے)، پانچ وقت کے لیک کے تجرید کو لاگو کیا جا سکتا ہے، اور آٹومیشن کو لاگو کیا جا سکتا ہے۔
2. کام کے انتظام کے نظام کو مضبوط کریں: ٹاسک مینجمنٹ
میں جن آثار قدیمہ کے بارے میں بات کر رہا ہوں وہ ایک قسم کا اہرام ہیں۔ اگر پہلا صحیح طریقے سے کیا گیا ہے، تو دوسرا پہلے سے ہی ایک قسم کا اضافہ ہے۔ ان میں سے بہت سے اسٹارٹ اپس کے لیے کام نہیں کرتے، انہیں فارچیون 5000 جیسی بڑی کمپنیوں کے لیے ذہن میں رکھنے کی ضرورت ہے۔ آخری کمپنی جس کے لیے میں نے کام کیا تھا اس میں ٹکٹنگ کے 10 سسٹم تھے۔ ایک ٹیم کے پاس Remedy تھی، دوسری نے اپنا اپنا سسٹم لکھا تھا، تیسرے نے Jira کا استعمال کیا تھا، اور کچھ نے ای میل کے ذریعے کیا تھا۔ ایک ہی مسئلہ پیدا ہوتا ہے اگر کمپنی کے پاس 30 مختلف پائپ لائنیں ہیں، لیکن میرے پاس ایسے تمام معاملات پر بات کرنے کا وقت نہیں ہے۔
میں لوگوں کے ساتھ اس بات پر بات کرتا ہوں کہ ٹکٹ کیسے بنتے ہیں، ان کے ساتھ کیا ہوتا ہے، اور ان کو کیسے روکا جاتا ہے۔ سب سے دلچسپ بات یہ ہے کہ ہماری میٹنگز میں لوگ کافی خلوص سے بات کرتے ہیں۔ میں نے پوچھا کہ کتنے لوگ ٹکٹوں پر "معمولی / کوئی اثر نہیں" ڈالتے ہیں جن کو حقیقت میں "بڑا اثر" دیا جانا چاہئے۔ معلوم ہوا کہ تقریباً ہر کوئی ایسا کرتا ہے۔ میں مذمت میں شامل نہیں ہوں اور ہر ممکن طریقے سے کوشش کرتا ہوں کہ لوگوں کی شناخت نہ کروں۔ جب وہ خلوص دل سے مجھ سے کسی بات کا اقرار کرتے ہیں، تو میں اس شخص کو نہیں دیتا۔ لیکن جب تقریباً ہر کوئی سسٹم کو نظرانداز کرتا ہے، تو اس کا مطلب ہے کہ تمام سیکیورٹی بنیادی طور پر ونڈو ڈریسنگ ہے۔ اس لیے اس نظام کے ڈیٹا سے کوئی نتیجہ اخذ نہیں کیا جا سکتا۔
ٹکٹ کے مسئلے کو حل کرنے کے لیے، آپ کو ایک اہم نظام کا انتخاب کرنا ہوگا۔ اگر آپ جیرا استعمال کرتے ہیں تو اسے جیرا رکھیں۔ اگر کوئی متبادل ہے تو اسے صرف ایک ہی رہنے دیں۔ سب سے اہم بات یہ ہے کہ ٹکٹوں کو ترقی کے عمل میں ایک اور قدم کے طور پر دیکھا جانا چاہیے۔ ہر عمل کا ایک ٹکٹ ہونا ضروری ہے، جو ترقیاتی کام کے فلو سے گزرنا چاہیے۔ ٹیم کو ٹکٹ بھیجے جاتے ہیں، جو انہیں اسٹوری بورڈ پر پوسٹ کرتی ہے اور پھر ان کی ذمہ داری لیتی ہے۔
یہ تمام محکموں پر لاگو ہوتا ہے، بشمول انفراسٹرکچر اور آپریشنز۔ اس صورت میں، یہ ممکن ہے کہ کم از کم حالات کے بارے میں کچھ قابل فہم خیال پیدا کیا جا سکے۔ ایک بار جب یہ عمل قائم ہو جاتا ہے، تو اچانک یہ شناخت کرنا آسان ہو جاتا ہے کہ ہر درخواست کے لیے کون ذمہ دار ہے۔ کیونکہ اب ہم 50% نہیں بلکہ 98% نئی خدمات حاصل کرتے ہیں۔ اگر یہ بنیادی عمل کام کرتا ہے، تو پورے نظام میں درستگی بہتر ہو جاتی ہے۔
سروسز پائپ لائن
یہ دوبارہ صرف بڑی کارپوریشنوں پر لاگو ہوتا ہے۔ اگر آپ کسی نئے شعبے میں نئی کمپنی ہیں، تو اپنی آستینیں لپیٹیں اور اپنے Travis CI یا CircleCI کے ساتھ کام کریں۔ جب بات فارچیون 5000 کمپنیوں کی ہو تو، ایک ایسا معاملہ جو اس بینک میں ہوا جہاں میں کام کرتا تھا۔ گوگل ان کے پاس آیا اور انہیں پرانے آئی بی ایم سسٹم کے خاکے دکھائے گئے۔ گوگل والوں نے الجھن میں پوچھا - اس کا سورس کوڈ کہاں ہے؟ لیکن کوئی سورس کوڈ نہیں ہے، یہاں تک کہ GUI بھی نہیں۔ یہ وہ حقیقت ہے جس سے بڑی تنظیموں کو نمٹنا پڑتا ہے: ایک قدیم مین فریم پر 40 سالہ پرانے بینک ریکارڈ۔ میرے کلائنٹس میں سے ایک سرکٹ بریکر پیٹرن کے ساتھ Kubernetes کنٹینرز استعمال کرتا ہے، نیز Chaos Monkey، سبھی KeyBank ایپلیکیشن کے لیے۔ لیکن یہ کنٹینرز بالآخر COBOL ایپلی کیشن سے جڑ جاتے ہیں۔
گوگل کے لڑکوں کو پورا یقین تھا کہ وہ میرے کلائنٹ کے تمام مسائل حل کر دیں گے، اور پھر انہوں نے سوال پوچھنا شروع کر دیا: IBM ڈیٹا پائپ کیا ہے؟ انہیں کہا جاتا ہے: یہ ایک کنیکٹر ہے۔ یہ کس چیز سے جڑتا ہے؟ سپیری سسٹم کو۔ اور وہ کیا ہے؟ اور اسی طرح. پہلی نظر میں ایسا لگتا ہے: وہاں کس قسم کے DevOps ہوسکتے ہیں؟ لیکن حقیقت میں، یہ ممکن ہے. ڈیلیوری کے ایسے نظام موجود ہیں جو آپ کو ورک فلو ڈیلیوری ٹیموں کے حوالے کرنے کی اجازت دیتے ہیں۔
3. تھیوری آف کنسٹرائنٹس: تھیوری آف کنسٹرائنٹس
آئیے تیسری آرکی ٹائپ کی طرف چلتے ہیں: ادارہ جاتی/"قبائلی" علم۔ ایک اصول کے طور پر، کسی بھی تنظیم میں بہت سے لوگ ہیں جو سب کچھ جانتے ہیں اور ہر چیز کا انتظام کرتے ہیں. یہ وہ لوگ ہیں جو تنظیم میں سب سے زیادہ عرصے تک رہے ہیں اور جو تمام کاموں کو جانتے ہیں۔
جب یہ خاکہ پر آتا ہے، تو میں خاص طور پر ایسے لوگوں کو مارکر کے ساتھ دائرہ بناتا ہوں: مثال کے طور پر، یہ پتہ چلتا ہے کہ تمام میٹنگز میں ایک مخصوص لو موجود ہوتا ہے۔ اور یہ میرے لیے واضح ہے: یہ مقامی برینٹ ہے۔ جب CIO میرے درمیان ٹی شرٹ اور جوتے میں اور IBM کے ایک سوٹ والے لڑکے کا انتخاب کرتا ہے، تو مجھے اس لیے منتخب کیا جاتا ہے کیونکہ میں ڈائریکٹر کو وہ باتیں بتا سکتا ہوں جو دوسرا آدمی نہیں بتائے گا اور یہ کہ ڈائریکٹر شاید سننا پسند نہ کریں۔ . میں انہیں بتاتا ہوں کہ ان کی کمپنی میں رکاوٹ فریڈ نامی کوئی ہے اور لو نام کا کوئی۔ اس رکاوٹ کو کھولنے کی ضرورت ہے، ان کا علم ان سے کسی نہ کسی طریقے سے حاصل کرنا ہوگا۔
اس قسم کے مسئلے کو حل کرنے کے لیے، میں مثال کے طور پر Slack استعمال کرنے کا مشورہ دے سکتا ہوں۔ ایک ہوشیار ڈائریکٹر پوچھے گا - کیوں؟ عام طور پر، ایسے معاملات میں، DevOps کنسلٹنٹس جواب دیتے ہیں: کیونکہ ہر کوئی یہ کر رہا ہے۔ اگر ڈائریکٹر واقعی ہوشیار ہے، تو وہ کہے گا: تو کیا؟ اور یہیں پر مکالمہ ختم ہوتا ہے۔ اور اس کا میرا جواب ہے: کیونکہ کمپنی میں چار رکاوٹیں ہیں، فریڈ، لو، سوسی اور جین۔ اپنے علم کو ادارہ جاتی بنانے کے لیے، سب سے پہلے سلیک کو متعارف کرانا چاہیے۔ آپ کی تمام وکی مکمل بکواس ہیں کیونکہ ان کے وجود کے بارے میں کوئی نہیں جانتا۔ اگر انجینئرنگ ٹیم فرنٹ اینڈ اور بیک اینڈ ڈیولپمنٹ میں شامل ہے اور ہر کسی کو یہ جاننے کی ضرورت ہے کہ وہ فرنٹ اینڈ ڈیولپمنٹ ٹیم یا انفراسٹرکچر ٹیم سے سوالات کے ساتھ رابطہ کر سکتے ہیں۔ اس وقت لو یا فریڈ کے پاس ویکی میں شامل ہونے کا وقت ہو گا۔ اور پھر Slack میں کوئی پوچھ سکتا ہے کہ کیوں، کہیے، مرحلہ 5 کام نہیں کر رہا ہے۔ اور پھر Lou یا Fred ویکی پر دی گئی ہدایات کو درست کریں گے۔ اگر آپ اس عمل کو قائم کریں گے تو بہت ساری چیزیں اپنے آپ پر گر جائیں گی۔
یہ میرا بنیادی نکتہ ہے: کسی بھی اعلیٰ ٹیکنالوجی کی سفارش کرنے کے لیے، آپ کو سب سے پہلے ان کے لیے فاؤنڈیشن کو ترتیب دینا چاہیے، اور یہ حال ہی میں بیان کیے گئے کم تکنیکی حل کے ساتھ کیا جا سکتا ہے۔ اگر آپ اعلی ٹیکنالوجی کے ساتھ شروع کرتے ہیں اور یہ نہیں بتاتے ہیں کہ ان کی ضرورت کیوں ہے، تو، ایک اصول کے طور پر، یہ اچھی طرح سے ختم نہیں ہوتا. ہمارے کلائنٹس میں سے ایک Azure ML استعمال کرتا ہے، جو ایک بہت ہی سستا اور آسان حل ہے۔ ان کے تقریباً 30% سوالات کے جوابات خود سیکھنے والی مشین نے دیے۔ اور یہ چیز آپریٹرز نے لکھی تھی جو ڈیٹا سائنس، شماریات یا ریاضی میں شامل نہیں تھے۔ یہ اہم ہے۔ اس طرح کے حل کی قیمت کم سے کم ہے۔
4. تعاون ہیکس: تعاون ہیکس
چوتھی آرکیٹائپ تنہائی کا مقابلہ کرنے کی ضرورت ہے۔ زیادہ تر لوگ پہلے ہی یہ جانتے ہیں: تنہائی دشمنی کو جنم دیتی ہے۔ اگر ہر شعبہ اپنی منزل پر ہو، اور لوگ لفٹ کے علاوہ کسی بھی طرح سے ایک دوسرے سے نہ ملیں، تو ان کے درمیان دشمنی بہت آسانی سے پیدا ہو جاتی ہے۔ لیکن اگر، اس کے برعکس، لوگ ایک دوسرے کے ساتھ ایک ہی کمرے میں ہیں، وہ فوری طور پر چھوڑ دیتا ہے. جب کوئی عام الزام لگاتا ہے، مثال کے طور پر، فلاں اور فلاں انٹرفیس کبھی کام نہیں کرتا، تو اس طرح کے الزام کو ڈی کنسٹرکٹ کرنا آسان کچھ نہیں ہے۔ انٹرفیس لکھنے والے پروگرامرز کو صرف مخصوص سوالات پوچھنا شروع کرنے کی ضرورت ہے، اور یہ جلد ہی واضح ہو جائے گا کہ، مثال کے طور پر، صارف صرف اس ٹول کو غلط طریقے سے استعمال کر رہا تھا۔
تنہائی پر قابو پانے کے بہت سے طریقے ہیں۔ مجھے ایک بار آسٹریلیا میں ایک بینک سے مشورہ کرنے کو کہا گیا، لیکن میں نے ایسا کرنے سے انکار کر دیا کیونکہ میرے دو بچے اور ایک بیوی ہے۔ میں ان کی مدد کرنے کے لیے صرف تصویری کہانی سنانے کی سفارش کر سکتا تھا۔ یہ ایسی چیز ہے جو کام کرنے کے لئے ثابت ہے. ایک اور دلچسپ طریقہ دبلی پتلی کافی میٹنگز ہے۔ ایک بڑی تنظیم میں، یہ علم کو پھیلانے کے لیے ایک بہترین آپشن ہے۔ اس کے علاوہ، آپ اندرونی ڈیوپس ڈے، ہیکاتھون وغیرہ کر سکتے ہیں۔
5. کوچنگ کاتا
جیسا کہ میں نے شروع میں ہی خبردار کیا تھا، میں آج اس کے بارے میں بات نہیں کروں گا۔ اگر آپ دلچسپی رکھتے ہیں، تو آپ ایک نظر ڈال سکتے ہیں۔ .
مائیک روتھر سے اس موضوع پر ایک اچھی گفتگو بھی ہے:
6. مارکیٹ اورینٹڈ: مارکیٹ پر مبنی تنظیم
یہاں مختلف مسائل ہیں۔ مثال کے طور پر، "I" لوگ، "T" لوگ اور "E" لوگ۔ "میں" لوگ وہ ہیں جو صرف ایک کام کرتے ہیں۔ عام طور پر وہ الگ تھلگ محکموں والی تنظیموں میں موجود ہوتے ہیں۔ "T" تب ہوتا ہے جب کوئی شخص ایک چیز میں اچھا ہوتا ہے لیکن کچھ دوسری چیزوں میں بھی اچھا ہوتا ہے۔ "ای" یا یہاں تک کہ "کنگھی" تب ہوتی ہے جب ایک شخص کے پاس بہت سی مہارتیں ہوتی ہیں۔
کونوے کا قانون یہاں کام کرتا ہے ()، جسے سب سے آسان شکل میں اس طرح بیان کیا جا سکتا ہے: اگر تین ٹیمیں کمپائلر پر کام کرتی ہیں، تو نتیجہ تین حصوں کا کمپائلر ہوگا۔ لہٰذا، اگر کسی تنظیم کے اندر تنہائی کی اعلیٰ سطح ہے، تو یہاں تک کہ اس تنظیم میں Kubernetes، سرکٹ بریکر، API کی توسیع پذیری اور دیگر فینسی چیزوں کو بھی اسی طرح ترتیب دیا جائے گا جس طرح تنظیم خود کرتی ہے۔ سختی سے کانوے کے مطابق اور آپ تمام نوجوان گیکس کے باوجود۔
اس مسئلے کا حل کئی بار بیان کیا جا چکا ہے۔ مثال کے طور پر، فرنینڈو فرنانڈیز کے ذریعہ بیان کردہ تنظیمی آثار ہیں۔ وہ مشکل فن تعمیر جس کے بارے میں میں نے ابھی بات کی ہے، تنہائی کے ساتھ، ایک فنکشن پر مبنی فن تعمیر ہے۔ دوسری قسم سب سے خراب ہے، میٹرکس فن تعمیر، باقی دو کی گڑبڑ۔ تیسرا وہ ہے جو زیادہ تر سٹارٹ اپس میں دیکھا جاتا ہے، اور بڑی کمپنیاں بھی اس قسم سے ملنے کی کوشش کر رہی ہیں۔ یہ ایک مارکیٹ پر مبنی تنظیم ہے۔ یہاں ہم کسٹمر کی درخواستوں پر تیز ترین جواب حاصل کرنے کے لیے بہتر بناتے ہیں۔ اسے کبھی کبھی فلیٹ تنظیم کہا جاتا ہے۔
بہت سے لوگ اس ساخت کو مختلف طریقوں سے بیان کرتے ہیں، مجھے الفاظ پسند ہیں۔ ٹیمیں بنائیں/چلائیں۔، ایمیزون پر وہ اسے کہتے ہیں۔ دو پیزا ٹیمیں. اس ڈھانچے میں، تمام قسم کے "I" لوگوں کو ایک سروس کے ارد گرد گروپ کیا جاتا ہے، اور آہستہ آہستہ وہ "T" ٹائپ کرنے کے قریب ہو جاتے ہیں، اور اگر صحیح انتظام موجود ہے، تو وہ "E" بھی بن سکتے ہیں۔ یہاں پہلا جواب یہ ہے کہ اس طرح کے ڈھانچے میں غیر ضروری عناصر ہوتے ہیں۔ اگر آپ کے پاس ٹیسٹرز کا ایک خاص شعبہ ہو سکتا ہے تو آپ کو ہر شعبہ میں ٹیسٹر کی ضرورت کیوں ہے؟ جس کا میں جواب دیتا ہوں: اس معاملے میں اضافی اخراجات پوری تنظیم کے مستقبل میں قسم "E" بننے کی قیمت ہیں۔ اس ڈھانچے میں، ٹیسٹر آہستہ آہستہ نیٹ ورکس، فن تعمیر، ڈیزائن وغیرہ کے بارے میں سیکھتا ہے۔ نتیجے کے طور پر، تنظیم میں ہر شریک ہر چیز سے پوری طرح واقف ہے جو تنظیم میں ہوتا ہے. اگر آپ جاننا چاہتے ہیں کہ یہ اسکیم انڈسٹری میں کیسے کام کرتی ہے تو پڑھیں .
7. شفٹ-بائیں آڈیٹرز: سائیکل میں ابتدائی آڈٹ۔ ڈسپلے پر حفاظتی قواعد کی تعمیل
یہ تب ہوتا ہے جب آپ کے اعمال بدبو کے امتحان میں کامیاب نہیں ہوتے ہیں، تو بات کریں۔ جو لوگ آپ کے لیے کام کرتے ہیں وہ بیوقوف نہیں ہیں۔ اگر، جیسا کہ اوپر کی مثال میں، انہوں نے ہر جگہ معمولی/کوئی اثر نہیں ڈالا، یہ تین سال تک جاری رہا، اور کسی نے کچھ نہیں دیکھا، تو ہر کوئی بخوبی جانتا ہے کہ نظام کام نہیں کرتا۔ یا ایک اور مثال - ایک تبدیلی کا مشاورتی بورڈ، جہاں رپورٹس کو ہر بدھ کو جمع کروانے کی ضرورت ہوتی ہے۔ وہاں کام کرنے والے لوگوں کا ایک گروپ ہے (بہت زیادہ معاوضہ نہیں، ویسے) جنہیں نظریہ طور پر یہ معلوم ہونا چاہیے کہ نظام مجموعی طور پر کیسے کام کرتا ہے۔ اور پچھلے پانچ سالوں میں، آپ نے شاید محسوس کیا ہوگا کہ ہمارے سسٹمز ناقابل یقین حد تک پیچیدہ ہیں۔ اور پانچ یا چھ لوگوں کو ایک ایسی تبدیلی کے بارے میں فیصلہ کرنا ہے جو انہوں نے نہیں کیا اور جس کے بارے میں وہ کچھ نہیں جانتے ہیں۔
یقینا، یہ نقطہ نظر کام نہیں کرتا. مجھے ایسی چیزوں سے جان چھڑانی ہے کیونکہ یہ لوگ نظام کی حفاظت نہیں کر رہے۔ فیصلہ ٹیم کو خود کرنا ہوگا، کیونکہ ٹیم کو اس کی ذمہ داری ادا کرنی ہوگی۔ دوسری صورت میں، ایک متضاد صورتحال پیدا ہوتی ہے جب ایک مینیجر جس نے اپنی زندگی میں کبھی کوڈ نہیں لکھا وہ پروگرامر کو بتاتا ہے کہ کوڈ لکھنے میں کتنا وقت لگنا چاہیے۔ ایک کمپنی جس کے ساتھ میں نے کام کیا اس میں 7 مختلف بورڈز تھے جو ہر تبدیلی کا جائزہ لیتے تھے، بشمول ایک آرکیٹیکچر بورڈ، ایک پروڈکٹ بورڈ وغیرہ۔ یہاں تک کہ ایک لازمی انتظار کی مدت بھی تھی، حالانکہ ایک ملازم نے مجھے بتایا کہ دس سال کے کام میں، اس لازمی مدت کے دوران اس شخص کی طرف سے کی گئی تبدیلی کو کبھی کسی نے مسترد نہیں کیا۔
آڈیٹرز کو ہمارے ساتھ شامل ہونے کے لئے مدعو کرنے کی ضرورت ہے، اور ان سے چھٹکارا حاصل کرنے کی ضرورت نہیں ہے۔ انہیں بتائیں کہ آپ ناقابل تغیر بائنری کنٹینرز لکھتے ہیں، اگر وہ تمام ٹیسٹ پاس کر لیتے ہیں، تو ہمیشہ کے لیے ناقابل تغیر رہیں گے۔ انہیں بتائیں کہ آپ کے پاس کوڈ کے طور پر ایک پائپ لائن ہے اور اس کا مطلب بتائیں۔ انہیں درج ذیل اسکیم دکھائیں: ایک کنٹینر میں ایک ناقابل تبدیلی صرف پڑھنے کے لیے بائنری جو تمام خطرات کے ٹیسٹ پاس کرتی ہے۔ اور پھر نہ صرف اسے کوئی نہیں چھوتا بلکہ وہ اس نظام کو بھی نہیں چھوتا جو پائپ لائن بناتا ہے، کیونکہ یہ بھی متحرک طور پر بنائی گئی ہے۔ میرے پاس کلائنٹس ہیں، کیپیٹل ون، جو بلاک چین جیسی چیز بنانے کے لیے والٹ کا استعمال کر رہے ہیں۔ آڈیٹر کو شیف سے "ترکیبیں" دکھانے کی ضرورت نہیں ہے؛ بلاک چین کو دکھانے کے لیے یہ کافی ہے، جس سے یہ واضح ہوتا ہے کہ پروڈکشن میں جیرا ٹکٹ کا کیا ہوا اور اس کا ذمہ دار کون ہے۔
کے مطابق سوناٹائپ کے ذریعہ 2018 میں تخلیق کیا گیا، 2017 میں 87 بلین OSS ڈاؤن لوڈ کی درخواستیں تھیں۔
کمزوریوں کی وجہ سے ہونے والے نقصانات ممنوع ہیں۔ مزید یہ کہ، جو اعداد و شمار اب آپ اوپر دیکھ رہے ہیں ان میں مواقع کی قیمتیں شامل نہیں ہیں۔ DevSecOps مختصراً کیا ہے؟ میں فوراً کہہ دوں کہ مجھے یہ بات کرنے میں کوئی دلچسپی نہیں کہ یہ نام کتنا کامیاب ہے۔ بات یہ ہے کہ چونکہ DevOps بہت کامیاب رہا ہے، ہمیں اس پائپ لائن میں سیکیورٹی شامل کرنے کی کوشش کرنی چاہیے۔
اس سلسلے کی ایک مثال:
یہ مخصوص مصنوعات کے لیے تجویز نہیں ہے، حالانکہ میں ان سب کو پسند کرتا ہوں۔ میں نے یہ دکھانے کے لیے ایک مثال کے طور پر ان کا حوالہ دیا کہ DevOps، جو ابتدا میں صنعت میں تنظیمی نمونے پر مبنی تھا، آپ کو کسی پروڈکٹ پر کام کے ہر مرحلے کو خودکار کرنے کی اجازت دیتا ہے۔
اور اس کی کوئی وجہ نہیں ہے کہ ہم سیکیورٹی کے حوالے سے ایک جیسا طریقہ اختیار نہ کر سکے۔
کل
ایک نتیجہ کے طور پر، میں DevSecOps کے لیے کچھ تجاویز دوں گا۔ آپ کو اپنے سسٹم بنانے کے عمل میں آڈیٹرز کو شامل کرنے اور انہیں تعلیم دینے میں وقت گزارنے کی ضرورت ہے۔ آپ کو آڈیٹرز کے ساتھ تعاون کرنے کی ضرورت ہے۔ اگلا، آپ کو جھوٹے مثبتات کے خلاف بالکل بے رحم جنگ لڑنے کی ضرورت ہے۔ انتہائی مہنگے خطرے سے متعلق سکیننگ ٹول کے ساتھ بھی، آپ اپنے ڈویلپرز کے درمیان انتہائی بری عادتیں پیدا کر سکتے ہیں اگر آپ نہیں جانتے کہ آپ کا سگنل ٹو شور کا تناسب کیا ہے۔ ڈویلپرز واقعات سے مغلوب ہو جائیں گے اور انہیں آسانی سے حذف کر دیں گے۔ اگر آپ نے Equifax کہانی کے بارے میں سنا ہے، تو وہاں ایسا ہی ہوا، جہاں سب سے زیادہ الرٹ لیول کو نظر انداز کیا گیا تھا۔ اس کے علاوہ، کمزوریوں کو اس طرح بیان کرنے کی ضرورت ہے جس سے یہ واضح ہو کہ وہ کس طرح کاروبار پر اثر انداز ہوتے ہیں۔ مثال کے طور پر، آپ کہہ سکتے ہیں کہ یہ وہی کمزوری ہے جو Equifax کہانی میں ہے۔ سیکیورٹی کی کمزوریوں کو سافٹ ویئر کے دیگر مسائل کی طرح ہی سمجھا جانا چاہیے، یعنی انہیں ڈی او اوپس کے مجموعی عمل میں شامل کیا جانا چاہیے۔ آپ کو جیرا، کنبن وغیرہ کے ذریعے ان کے ساتھ کام کرنے کی ضرورت ہے۔ ڈویلپرز کو یہ نہیں سوچنا چاہئے کہ کوئی اور ایسا کرے گا - اس کے برعکس، سب کو یہ کرنا چاہئے۔ آخر میں، آپ کو لوگوں کی تربیت پر توانائی خرچ کرنے کی ضرورت ہے۔
کارآمد ویب سائٹس
یہاں DevOops کانفرنس کی چند باتیں ہیں جو آپ کو کارآمد لگ سکتی ہیں:
- Sergey Berdnikov، Artyom Kalichkin - کامیابی کی کہانی، یا "Dev+DevOps+Ops" (, )
- Baruch Sadogursky، Leonid Igolnik - DevOps on a Scale: a Greek tragedy in three acts (, )
- الیگزینڈر ٹائٹوف، کیرل ٹولکاچیف -
- ٹموتھی لسٹر -
میں دیکھو DevOops 2020 ماسکو - وہاں بہت ساری دلچسپ چیزیں بھی ہیں۔
ماخذ: www.habr.com