سوال "ڪيئن ڊيوپس کي لاڳو ڪرڻ" جي چوڌاري سالن تائين آهي، پر اتي تمام سٺو مواد نه آهن. ڪڏهن ڪڏهن توهان غير سمارٽ صلاحڪارن جي اشتهارن جو شڪار ٿي ويندا آهيو جن کي پنهنجو وقت وڪڻڻ جي ضرورت آهي، ڪابه پرواهه ناهي. ڪڏهن ڪڏهن اهي مبهم، انتهائي عام لفظ آهن ته ڪيئن ميگا ڪارپوريشن جا جهاز ڪائنات جي وسعت کي هلڪو ڪن ٿا. سوال ٿو پيدا ٿئي ته: هي اسان لاءِ ڇا آهي؟ پيارا ليکڪ، ڇا توهان واضح طور تي پنهنجي خيالن کي هڪ فهرست ۾ ٺاهي سگهو ٿا؟
اهو سڀ ڪجهه ان حقيقت مان نڪرندو آهي ته ڪمپني جي ڪلچر جي تبديليءَ جي نتيجي ۾ گهڻو حقيقي مشق ۽ سمجهه جمع نه ٿي آهي. ثقافت ۾ تبديليون ڊگهي مدي واريون شيون آهن، جن جا نتيجا هڪ هفتي يا مهيني ۾ ظاهر نه ٿيندا. اسان کي ڪنهن وڏي عمر جي ضرورت آهي ته ڏٺو وڃي ته ڪمپنيون ڪيئن ٺاهيا ويا آهن ۽ سالن کان ناڪام ٿي ويا آهن.
جان ويليس - DevOps جي ابن ڏاڏن مان هڪ. جان کي ڪيترن ئي ڪمپنين سان ڪم ڪرڻ جو ڏهاڪن جو تجربو آهي. تازو، جان مخصوص نمونن کي نوٽيس ڪرڻ شروع ڪيو جيڪي انهن مان هر هڪ سان ڪم ڪرڻ وقت وٺن ٿا. انهن آرڪٽائپس کي استعمال ڪندي، جان ڪمپنين کي هدايت ڪري ٿو DevOps تبديلي جي حقيقي رستي تي. انهن آرڪيائپس بابت وڌيڪ پڙهو هن جي رپورٽ جي ترجمي ۾ DevOops 2018 ڪانفرنس.
اسپيڪر بابت:
آئي ٽي مئنيجمينٽ ۾ 35 سالن کان وڌيڪ، ڪيننيڪل ۾ OpenCloud جي اڳڪٿي جي پيدائش ۾ حصو ورتو، 10 شروعاتن ۾ حصو ورتو، جن مان ٻه ڊيل ۽ ڊڪر کي وڪرو ڪيا ويا. في الحال هو ايس جي ٽيڪنالاجيز ۾ DevOps ۽ ڊجيٽل مشق جو نائب صدر آهي.
جان جي نقطي نظر کان ايندڙ ڪهاڻي آهي.
منهنجو نالو جان وليس آهي ۽ مون کي ڳولڻ لاءِ سڀ کان آسان جڳهه Twitter تي آهي، . مون وٽ ساڳيو عرف 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 ٿي وڃي ٿو. مان جيڪو نقطو ٺاهي رهيو آهيان اهو اهو آهي ته Little's Law يا ڪنهن پيچيده قطار واري نظريي کي استعمال ڪرڻ لاء، توهان وٽ گهٽ ۾ گهٽ ڊيٽا جي ضرورت آهي.
تنهن ڪري جڏهن مان ڏيک جي باري ۾ ڳالهائيندو آهيان، منهنجو مطلب اهو ناهي ته هر شي اسڪرين تي آهي، پر اهو ته توهان وٽ گهٽ ۾ گهٽ ڊيٽا آهي. جڏهن اهي ڪندا آهن، اهو اڪثر ڪري ٻاهر نڪرندو آهي ته اتي هڪ تمام وڏي مقدار ۾ غير منصوبابندي ڪيل ڪم آهي جيڪو ڪنهن نه ڪنهن طريقي سان برنٽ ڏانهن موڪليو ويندو آهي جڏهن ان جي ڪا ضرورت ناهي. ۽ برنٽ هڪ عظيم ماڻهو آهي، هو ڪڏهن به نه چوندو، پر هو ڪنهن کي به نٿو ٻڌائي ته هو پنهنجو ڪم ڪيئن ڪري ٿو.
جڏهن ڪم نظر اچي ٿو، ڊيٽا کي صاف طور تي درجه بندي ڪري سگهجي ٿو (اهو ئي آهي جيڪو ڊومينيڪا فوٽو ۾ ڪري رهيو آهي)، پنجن وقت جي ليڪ جو خلاصو لاڳو ڪري سگهجي ٿو، ۽ خودڪار طريقي سان لاڳو ٿي سگهي ٿو.
2. ڪم مينيجمينٽ سسٽم کي مضبوط ڪريو: ٽاسڪ مئنيجمينٽ
آرڪي ٽائپس جن جي باري ۾ آئون ڳالهائي رهيو آهيان هڪ قسم جو پرامڊ آهي. جيڪڏهن پهريون صحيح طريقي سان ڪيو ويو آهي، ته پوء ٻيو هڪ اڳ ۾ ئي هڪ قسم جو اضافو آهي. انهن مان گهڻا شروعاتي لاءِ ڪم نه ڪندا آهن، انهن کي وڏين ڪمپنين لاءِ ذهن ۾ رکڻ جي ضرورت آهي جهڙوڪ Fortune 5000. آخري ڪمپني جنهن لاءِ مون ڪم ڪيو ان وٽ 10 ٽڪيٽنگ سسٽم هئا. هڪڙي ٽيم وٽ Remedy هئي، ٻئي ڪنهن قسم جو پنهنجو سسٽم لکيو، ٽيون استعمال ڪيو Jira، ۽ ڪجهه ڪيو اي ميل سان. ساڳيو مسئلو پيدا ٿئي ٿو جيڪڏهن ڪمپني وٽ 30 مختلف پائپ لائنون آهن، پر مون وٽ وقت نه آهي ته انهن سڀني ڪيسن تي بحث ڪرڻ لاء.
مان ماڻهن سان بحث ڪريان ٿو ته ڪيئن ٽڪيٽون ٺاهيا وڃن ٿا، انهن سان ڇا ٿئي ٿو، ۽ انهن کي ڪيئن روڪيو وڃي ٿو. سڀ کان وڌيڪ دلچسپ ڳالهه اها آهي ته اسان جي گڏجاڻين ۾ ماڻهو ڏاڍي خلوص سان ڳالهائيندا آهن. مون پڇيو ته ڪيترا ماڻهو ٽڪيٽن تي "معمولي / ڪو اثر نه" رکندا آهن جن کي اصل ۾ "وڏي اثر" ڏنو وڃي. اهو ظاهر ٿيو ته تقريبا هرڪو اهو ڪري ٿو. مان مذمت ۾ مشغول نه آهيان ۽ هر ممڪن طريقي سان ڪوشش ڪريان ٿو ته ماڻهن جي سڃاڻپ نه ڪريان. جڏهن اهي خلوص سان مون وٽ ڪجهه اقرار ڪن ٿا، مان ان شخص کي نه ڏيندس. پر جڏهن تقريبن هرڪو سسٽم کي نظرانداز ڪري ٿو، ان جو مطلب اهو آهي ته سڀ سيڪيورٽي لازمي طور تي ونڊو ڊريسنگ آهي. تنهن ڪري، هن نظام جي ڊيٽا مان ڪو به نتيجو ڪڍي نه ٿو سگهجي.
ٽڪيٽ جي مسئلي کي حل ڪرڻ لاء، توهان کي هڪ مکيه سسٽم چونڊڻ جي ضرورت آهي. جيڪڏهن توهان جيرا استعمال ڪريو، ان کي رکو. جيڪڏهن ڪو متبادل آهي، ته اهو صرف هڪ آهي. هيٺئين لائن اها آهي ته ٽڪيٽن کي ڏسڻ گهرجي ترقي جي عمل ۾ هڪ ٻيو قدم. هر عمل کي لازمي طور تي هڪ ٽڪيٽ هجڻ گهرجي، جيڪو ترقياتي ڪم جي فلو ذريعي وهڻ گهرجي. ٽڪيٽون ٽيم ڏانهن موڪليا ويا آهن، جيڪي انهن کي ڪهاڻي بورڊ تي پوسٽ ڪري ٿو ۽ پوء انهن جي ذميواري وٺندو آهي.
اهو سڀني شعبن تي لاڳو ٿئي ٿو، بشمول انفراسٽرڪچر ۽ آپريشن. انهي حالت ۾، اهو ممڪن آهي ته گهٽ ۾ گهٽ حالتن جي حالت بابت ڪجهه معقول خيال ٺاهي. هڪ دفعو اهو عمل قائم ٿئي ٿو، اوچتو اهو سڃاڻڻ آسان ٿي وڃي ٿو ته هر درخواست لاء ذميوار ڪير آهي. ڇو ته هاڻي اسان 50 سيڪڙو نه، پر 98 سيڪڙو نيون خدمتون حاصل ڪندا آهيون. جيڪڏهن اهو بنيادي عمل ڪم ڪري ٿو، پوء درستگي سڄي سسٽم ۾ بهتر ٿي.
سروس پائپ لائن
اهو وري صرف وڏي ڪارپوريشن تي لاڳو ٿئي ٿو. جيڪڏهن توهان هڪ نئين فيلڊ ۾ هڪ نئين ڪمپني آهيو، پنهنجي آستين کي رول ڪريو ۽ توهان جي ٽريس سي آء يا CircleCI سان ڪم ڪريو. جڏهن اهو اچي ٿو فارچون 5000 ڪمپنيون، هڪ ڪيس ان نقطي ۾ جيڪو بينڪ تي ٿيو جتي مون ڪم ڪيو. گوگل وٽن آيو ۽ کين پراڻي IBM سسٽم جا ڊاگرام ڏيکاريا ويا. گوگل وارن مونجهاري ۾ پڇيو - هن جو سورس ڪوڊ ڪٿي آهي؟ پر ڪو به سورس ڪوڊ ناهي، نه ئي هڪ GUI. اها حقيقت آهي ته وڏي تنظيمن سان معاملو ڪرڻو پوندو: 40 سال پراڻي بئنڪ رڪارڊ هڪ قديم مين فريم تي. منهنجو هڪ گراهڪ ڪبرنيٽس ڪنٽينر استعمال ڪري ٿو سرڪٽ بريڪر جي نمونن سان، گڏوگڏ Chaos Monkey، سڀ KeyBank ايپليڪيشن لاءِ. پر اهي ڪنٽينر آخرڪار هڪ COBOL ايپليڪيشن سان ڳنڍيندا آهن.
گوگل جا ماڻهو مڪمل طور تي يقين رکندا هئا ته اهي منهنجي ڪلائنٽ جا سڀئي مسئلا حل ڪندا، ۽ پوءِ انهن سوال پڇڻ شروع ڪيا: IBM ڊيٽا پائپ ڇا آهي؟ انهن کي چيو ويندو آهي: هي هڪ ڳنڍيندڙ آهي. اهو ڇا سان ڳنڍيل آهي؟ اسپري سسٽم ڏانهن. ۽ اهو ڇا آهي؟ ۽ ايئن. پهرين نظر ۾ اهو لڳي ٿو: ڪهڙي قسم جي DevOps ٿي سگهي ٿي؟ پر حقيقت ۾، اهو ممڪن آهي. اتي ترسيل نظام آھن جيڪي توھان کي ڪم جي فلو کي پهچائڻ جي ٽيمن کي ڏيڻ جي اجازت ڏين ٿا.
3. رڪاوٽن جو نظريو: پابندين جو نظريو
اچو ته ٽين آرڪيٽائپ ڏانھن وڃو: ادارتي/"قبائلي" علم. ضابطي جي طور تي، ڪنهن به تنظيم ۾ ڪيترائي ماڻهو آهن جيڪي سڀ ڪجهه ڄاڻن ٿا ۽ هر شيء کي منظم ڪن ٿا. اهي اهي آهن جيڪي تنظيم ۾ تمام گهڻي عرصي کان رهيا آهن ۽ جيڪي ڄاڻن ٿا سڀ ڪم ڪار.
جڏهن هي ڊراگرام تي اچي ٿو، آئون خاص طور تي اهڙن ماڻهن کي نشانن سان گول ڪري ٿو: مثال طور، اهو ظاهر ٿئي ٿو ته هڪ خاص لو سڀني گڏجاڻين ۾ موجود آهي. ۽ اهو مون لاء واضح آهي: هي مقامي برنٽ آهي. جڏهن CIO مون جي وچ ۾ هڪ ٽي شرٽ ۽ سنيڪرز ۽ هڪ سوٽ ۾ IBM جو ماڻهو چونڊيندو آهي، مون کي چونڊيو ويو آهي ڇاڪاڻ ته مان ڊائريڪٽر کي اهي شيون ٻڌائي سگهان ٿو جيڪو ٻيو ماڻهو نه ٻڌائيندو ۽ اهو شايد ڊائريڪٽر ٻڌڻ پسند نه ڪندو. . مان انهن کي ٻڌايان ٿو ته انهن جي ڪمپني ۾ رڪاوٽ ڪنهن جو نالو فريڊ آهي ۽ ڪنهن جو نالو لو. هن رڪاوٽ کي ختم ڪرڻ جي ضرورت آهي، انهن جي ڄاڻ حاصل ڪرڻ جي ضرورت آهي انهن کان ڪنهن نه ڪنهن طريقي سان.
هن قسم جي مسئلي کي حل ڪرڻ لاء، مان ڪري سگهان ٿو، مثال طور، استعمال ڪرڻ جي صلاح ڏيو Slack. هڪ هوشيار ڊائريڪٽر پڇندو - ڇو؟ عام طور تي، اهڙين حالتن ۾، DevOps صلاحڪار جواب ڏين ٿا: ڇاڪاڻ ته هرڪو اهو ڪري رهيو آهي. جيڪڏهن ڊائريڪٽر واقعي هوشيار آهي، ته هو چوندو: پوء ڇا. ۽ اهو آهي جتي ڳالهه ٻولهه ختم ٿي. ۽ هن جو منهنجو جواب آهي: ڇاڪاڻ ته ڪمپني ۾ چار رڪاوٽون آهن، فريڊ، لو، سوسي ۽ جين. انهن جي ڄاڻ کي ادارتي بڻائڻ لاء، هڪ کي پهريان متعارف ڪرائڻ گهرجي Slack. توهان جون سڀئي وڪيون مڪمل بيڪار آهن ڇو ته انهن جي وجود جي ڪنهن کي به خبر ناهي. جيڪڏهن انجنيئرنگ ٽيم فرنٽ اينڊ ۽ پٺئين ترقي ۾ ملوث آهي ۽ هر ڪنهن کي ڄاڻڻ جي ضرورت آهي ته اهي سوالن سان فرنٽ اينڊ ڊولپمينٽ ٽيم يا انفراسٽرڪچر ٽيم سان رابطو ڪري سگهن ٿا. اهو آهي جڏهن لو يا فريڊ کي شايد وڪي ۾ شامل ٿيڻ جو وقت هوندو. ۽ پوءِ Slack ۾ ڪو پڇي سگھي ٿو ڇو، چئو، قدم 5 ڪم نه ڪري رهيو آهي. ۽ پوءِ لو يا فريڊ وڪي تي ڏنل هدايتن کي درست ڪندا. جيڪڏهن توهان هن عمل کي قائم ڪيو، ته پوءِ ڪيتريون ئي شيون پنهنجي جاءِ تي اچي وينديون.
هي منهنجو بنيادي نقطو آهي: ڪنهن به اعلي ٽيڪنالاجي جي سفارش ڪرڻ لاء، توهان کي پهريان انهن لاء بنياد رکڻو پوندو، ۽ اهو صرف بيان ڪيل گهٽ ٽيڪنالاجي حلن سان ڪري سگهجي ٿو. جيڪڏهن توهان اعلي ٽيڪنالاجي سان شروع ڪيو ۽ وضاحت نه ڪندا ته انهن جي ضرورت ڇو آهي، پوء، ضابطي جي طور تي، اهو سٺو ختم نٿو ٿئي. اسان جي گراهڪن مان هڪ استعمال ڪري ٿو Azure ML، هڪ تمام سستو ۽ سادو حل. اٽڪل 30 سيڪڙو انهن جي سوالن جا جواب سيلف لرننگ مشين پاڻ ڏنا. ۽ اها شيءِ آپريٽرز طرفان لکيل هئي جيڪي ڊيٽا سائنس، شماريات يا رياضي ۾ شامل نه هئا. هي اهم آهي. اهڙي حل جي قيمت گهٽ ۾ گهٽ آهي.
4. تعاون هيڪس: تعاون هيڪس
چوٿين آرڪيٽائپ اڪيلائي کي منهن ڏيڻ جي ضرورت آهي. گهڻا ماڻهو اڳ ۾ ئي ڄاڻن ٿا: اڪيلائي نسل دشمني. جيڪڏهن هر ڊپارٽمينٽ پنهنجي پنهنجي منزل تي هجي ۽ ماڻهو لفٽ کان سواءِ ڪنهن به طريقي سان هڪ ٻئي سان ٽڪراءُ نه ڪن ته پوءِ انهن جي وچ ۾ دشمني ڏاڍي آسانيءَ سان پيدا ٿئي ٿي. پر جيڪڏهن، ان جي ابتڙ، ماڻهو هڪ ٻئي سان ساڳئي ڪمري ۾ آهن، هوء فوري طور تي ڇڏي ٿي. جڏهن ڪو ماڻهو ڪجهه عام الزام ڪڍي ٿو، مثال طور، اهڙي ۽ اهڙي انٽرفيس ڪڏهن به ڪم نه ڪندو آهي، اهڙي الزام کي ختم ڪرڻ لاء ڪجھ به آسان ناهي. پروگرامر جيڪي انٽرفيس لکيا آهن انهن کي صرف مخصوص سوال پڇڻ شروع ڪرڻ جي ضرورت آهي، ۽ اهو جلد واضح ٿي ويندو ته، مثال طور، صارف صرف اوزار کي غلط استعمال ڪري رهيو هو.
اڪيلائي کي ختم ڪرڻ جا ڪيترائي طريقا آهن. مون کي هڪ ڀيرو چيو ويو ته آسٽريليا ۾ هڪ بئنڪ لاءِ صلاح ڏيو، پر مون اهو ڪرڻ کان انڪار ڪيو ڇو ته مون کي ٻه ٻار ۽ هڪ زال آهي. انهن جي مدد ڪرڻ لاءِ مان صرف ڪري سگهان ٿو گرافڪ ڪهاڻي ٻڌائڻ جي سفارش ڪرڻ. اهو ڪجهه آهي جيڪو ڪم ڪرڻ لاء ثابت ٿيو آهي. ٻيو دلچسپ طريقو لين ڪافي گڏجاڻيون آهي. هڪ وڏي تنظيم ۾، هي علم کي ڦهلائڻ لاء هڪ بهترين اختيار آهي. اضافي طور تي، توهان منظم ڪري سگهو ٿا اندروني ڊيوپس ڏينهن، هيڪاٿون، وغيره.
5. ڪوچنگ ڪتا
جيئن مون شروعات ۾ خبردار ڪيو هو، مان اڄ ان بابت نه ڳالهائيندس. جيڪڏهن توهان دلچسپي رکو ٿا، توهان هڪ نظر وٺي سگهو ٿا .
مائڪ روٿر کان پڻ هن موضوع تي سٺي ڳالهه ٻولهه آهي:
6. مارڪيٽ تي مبني: مارڪيٽ تي مبني تنظيم
هتي مختلف مسئلا آهن. مثال طور، "I" ماڻهو، "T" ماڻهو ۽ "E" ماڻهو. ”مان“ ماڻهو اهي آهن جيڪي صرف هڪ ڪم ڪن ٿا. عام طور تي اهي الڳ الڳ شعبن سان تنظيمن ۾ موجود آهن. "T" اهو آهي جڏهن هڪ شخص هڪ شيء تي سٺو آهي پر ڪجهه ٻين شين ۾ پڻ سٺو آهي. "اي" يا اڃا به "ڪنگ" آهي جڏهن هڪ شخص وٽ ڪيتريون ئي صلاحيتون آهن.
ڪنوي جو قانون هتي ڪم ڪري ٿو ()، جنهن کي سڀ کان وڌيڪ آسان فارم ۾ هن ريت بيان ڪري سگهجي ٿو: جيڪڏهن ٽي ٽيمون ڪمپلر تي ڪم ڪن ٿيون، پوء نتيجو ٽن حصن جو هڪ مرتب ڪندڙ هوندو. تنهن ڪري، جيڪڏهن ڪنهن تنظيم جي اندر هڪ اعلي سطحي اڪيلائي آهي، ته پوء به هن تنظيم ۾ ڪبرنيٽس، سرڪٽ بريڪر، API جي توسيع ۽ ٻيون فينسي شيون ساڳئي طريقي سان ترتيب ڏني وينديون آهن جيئن تنظيم پاڻ. سختي سان Conway جي مطابق ۽ توهان سڀني نوجوان geeks کي ناراض ڪرڻ لاء.
هن مسئلي جو حل ڪيترائي ڀيرا بيان ڪيو ويو آهي. هتي آهن، مثال طور، فرننڊو فرنينڊز پاران بيان ڪيل تنظيمي آثار. اهو مشڪلاتي فن تعمير جنهن بابت مون صرف ڳالهايو آهي، اڪيلائي سان، هڪ فنڪشنل آرڪيٽيڪچر آهي. ٻيو قسم بدترين، ميٽرڪس آرڪيٽيڪچر، ٻين ٻن جي گندگي آهي. ٽيون اهو آهي جيڪو اڪثر شروعاتن ۾ ڏٺو ويندو آهي، ۽ وڏيون ڪمپنيون پڻ هن قسم سان ملائڻ جي ڪوشش ڪري رهيا آهن. اهو هڪ بازار تي مبني تنظيم آهي. هتي اسان ڪسٽمر جي درخواستن تي تيز ترين جواب حاصل ڪرڻ لاءِ بهتر بڻايون ٿا. اهو ڪڏهن ڪڏهن سڏيو ويندو آهي فليٽ تنظيم.
ڪيترائي ماڻهو هن ساخت کي مختلف طريقن سان بيان ڪن ٿا، مون کي لفظ پسند آهي ٽيمون ٺاهي / هلائڻ، Amazon تي اهي ان کي سڏين ٿا ٻه پيزا ٽيمون. هن ڍانچي ۾، سڀني قسمن جي "I" ماڻهن کي هڪ خدمت جي چوڌاري گروپ ڪيو ويو آهي، ۽ آهستي آهستي اهي "T" ٽائيپ جي ويجهو ٿي ويندا آهن، ۽ جيڪڏهن صحيح انتظام پنهنجي جاء تي آهي، اهي پڻ "E" بڻجي سگهن ٿا. هتي پهريون ضد اهو آهي ته اهڙي جوڙجڪ ۾ غير ضروري عناصر آهن. توهان کي هر ڊپارٽمينٽ ۾ ٽيسٽر جي ضرورت ڇو آهي جيڪڏهن توهان وٽ ٽيسٽرز جو هڪ خاص ڊپارٽمينٽ هجي؟ جنهن جو آئون جواب ڏيان ٿو: هن معاملي ۾ اضافي قيمتون پوري تنظيم جي مستقبل ۾ قسم “اي” ٿيڻ جي قيمت آهن. هن ڍانچي ۾، ٽيسٽ ڪندڙ آهستي آهستي نيٽ ورڪ، فن تعمير، ڊيزائن وغيره بابت سکندو آهي. نتيجي طور، تنظيم ۾ هر شرڪت ڪندڙ هر شيء کان مڪمل طور تي واقف آهي جيڪو تنظيم ۾ ٿئي ٿو. جيڪڏهن توهان ڄاڻڻ چاهيو ٿا ته هي اسڪيم ڪيئن ڪم ڪري ٿو صنعت ۾، پڙهو .
7. شفٽ-کاٻي آڊيٽر: آڊٽ شروعاتي چڪر ۾. ڊسپلي تي حفاظت جي ضابطن سان تعميل
اهو آهي جڏهن توهان جا عمل بوء جي امتحان پاس نٿا ڪن، تنهنڪري ڳالهائڻ لاء. جيڪي ماڻهو توهان لاءِ ڪم ڪن ٿا اهي بيوقوف نه آهن. جيڪڏهن، جيئن مٿي ڏنل مثال ۾، اهي هر جڳهه تي معمولي / ڪو به اثر مقرر ڪن ٿا، اهو ٽن سالن تائين هليو، ۽ ڪنهن به ڪجهه به نه ڏٺو، پوء هرڪو چڱي طرح ڄاڻي ٿو ته سسٽم ڪم نٿو ڪري. يا ٻيو مثال - هڪ تبديلي صلاحڪار بورڊ، جتي رپورٽون پيش ڪرڻ گهرجن هر، چئو، اربع. اتي ڪم ڪندڙ ماڻھن جو ھڪڙو گروپ آھي (تمام سٺو ادا نه ڪيو ويو، رستي ۾) جن کي، نظريي ۾، ڄاڻڻ گھرجي ته سسٽم مڪمل طور تي ڪيئن ڪم ڪري ٿو. ۽ گذريل پنجن سالن کان، توهان شايد محسوس ڪيو آهي ته اسان جا سسٽم ناقابل يقين حد تائين پيچيده آهن. ۽ پنجن يا ڇهن ماڻهن کي هڪ اهڙي تبديليءَ بابت فيصلو ڪرڻو پوندو، جيڪا هنن نه ڪئي هئي ۽ جنهن بابت کين ڪجهه به خبر ناهي.
يقينا، هي طريقو ڪم نٿو ڪري. مون کي اهڙين شين مان جان ڇڏائڻي آهي ڇو ته اهي ماڻهو نظام جي حفاظت نٿا ڪن. فيصلو ٽيم کي پاڻ ڪرڻ گهرجي، ڇو ته ٽيم کي ان جي ذميواري هجڻ گهرجي. ٻي صورت ۾، هڪ متضاد صورتحال پيدا ٿئي ٿي جڏهن هڪ مئنيجر جنهن پنهنجي زندگيء ۾ ڪڏهن به ڪوڊ نه لکيو آهي، پروگرامر کي ٻڌائي ٿو ته ڪوڊ لکڻ ۾ ڪيترو وقت گهرجي. هڪ ڪمپني جنهن سان مون ڪم ڪيو ان وٽ 7 مختلف بورڊ هئا جيڪي هر تبديلي جو جائزو وٺندا هئا، بشمول هڪ آرڪيٽيڪچر بورڊ، هڪ پراڊڪٽ بورڊ وغيره. اتي به هڪ لازمي انتظار جو عرصو هو، جيتوڻيڪ هڪ ملازم مون کي ٻڌايو ته ڪم جي ڏهن سالن ۾، ڪنهن به هن لازمي عرصي دوران هن شخص طرفان ڪيل تبديلي کي رد نه ڪيو آهي.
آڊيٽرن کي اسان سان شامل ٿيڻ جي دعوت ڏيڻ جي ضرورت آهي، ۽ انهن کي هٽائڻ نه گهرجي. انھن کي ٻڌايو ته توھان لکندا آھيو غير بدلائيندڙ بائنري ڪنٽينرز جيڪي، جيڪڏھن اھي سڀ امتحان پاس ڪن، ھميشه لاءِ ناقابل تبديلي رھندا. انھن کي ٻڌايو ته توھان وٽ ھڪڙي پائپ لائن آھي ڪوڊ ۽ وضاحت ڪريو ان جو مطلب ڇا آھي. انھن کي ھيٺ ڏنل اسڪيم ڏيکاريو: ھڪڙي غير تبديل ٿيندڙ صرف پڙھڻ واري بائنري ھڪڙي ڪنٽينر ۾ جيڪا سڀني خطرن جا امتحان پاس ڪري ٿي؛ ۽ پوءِ نه رڳو ان کي ڪو به هٿ نه ٿو لڳائي، اهي ان سسٽم کي به هٿ نه ٿا ڪن جيڪو پائپ لائن ٺاهي ٿو، ڇاڪاڻ ته اهو پڻ متحرڪ طور تي ٺاهيو ويو آهي. مون وٽ گراهڪ آهن، ڪيپيٽل ون، جيڪي استعمال ڪري رهيا آهن والٽ ٺاهڻ لاءِ هڪ بلاڪچين وانگر. آڊيٽر کي شيف کان "ترڪيبون" ڏيکارڻ جي ضرورت ناهي؛ اهو ڪافي آهي بلاڪ چين ڏيکارڻ، جنهن مان اهو واضح ٿئي ٿو ته پيداوار ۾ جيرا ٽڪيٽ کي ڇا ٿيو ۽ ڪير ان جو ذميوار آهي.
جي مطابق 2018 ۾ سونيٽائپ پاران ٺاهي وئي، 2017 ۾ 87 بلين OSS ڊائون لوڊ درخواستون هيون.
خطرن جي ڪري ٿيندڙ نقصان ممنوع آھن. ان کان علاوه، انگ اکر جيڪي توھان ھاڻي مٿي ڏسندا آھن انھن ۾ موقعي جي قيمت شامل نه آھي. مختصر ۾ DevSecOps ڇا آهي؟ مون کي فوري طور تي چوڻ ڏيو ته مون کي ڳالهائڻ ۾ دلچسپي نه آهي ته اهو نالو ڪيترو ڪامياب آهي. نقطي اهو آهي ته جڏهن کان DevOps ڪامياب ٿي چڪو آهي، اسان کي انهي پائپ لائن تي سيڪيورٽي شامل ڪرڻ جي ڪوشش ڪرڻ گهرجي.
هن تسلسل جو هڪ مثال:
هي خاص پروڊڪٽس لاءِ سفارش ناهي، جيتوڻيڪ آئون انهن سڀني کي پسند ڪريان ٿو. مون انهن کي هڪ مثال طور بيان ڪيو ته ڏيکاريو ته DevOps، جيڪو شروعاتي طور تي صنعت ۾ تنظيمي نموني تي ٻڌل هو، توهان کي اجازت ڏئي ٿو ته توهان هڪ پيداوار تي ڪم جي هر مرحلي کي خودڪار ڪرڻ.
۽ ڪو به سبب ناهي ته اسان سيڪيورٽي لاءِ ساڳيو طريقو نه وٺي سگهياسين.
نتيجو
نتيجي طور، مان ڏيندس ڪجهه تجويزون DevSecOps لاءِ. توهان کي پنهنجي سسٽم ٺاهڻ جي عمل ۾ آڊيٽرز کي شامل ڪرڻ ۽ انهن کي تعليم ڏيڻ ۾ وقت گذارڻ جي ضرورت آهي. توهان کي آڊيٽرن سان تعاون ڪرڻ جي ضرورت آهي. اڳيون، توهان کي غلط مثبت جي خلاف بلڪل بي رحم جنگ ڪرڻ جي ضرورت آهي. ايستائين جو سڀ کان مهانگو نقصانڪار اسڪيننگ اوزار سان، توهان ختم ڪري سگهو ٿا انتهائي خراب عادتون توهان جي ڊولپرز جي وچ ۾ جيڪڏهن توهان کي خبر ناهي ته توهان جي سگنل کان شور جو تناسب ڇا آهي. ڊولپرز واقعن سان حيران ٿي ويندا ۽ صرف انهن کي حذف ڪندا. جيڪڏهن توهان ٻڌو آهي Equifax ڪهاڻي بابت، اهو تمام گهڻو آهي جيڪو اتي ٿيو، جتي سڀ کان وڌيڪ خبرداري جي سطح کي نظرانداز ڪيو ويو. ان کان علاوه، ڪمزورين کي هڪ طريقي سان بيان ڪرڻ جي ضرورت آهي جيڪا واضح ڪري ٿي ته اهي ڪاروبار ڪيئن اثر انداز ڪن ٿا. مثال طور، توهان چئي سگهو ٿا ته اهو ساڳيو ئي نقصان آهي جيئن Equifax ڪهاڻي ۾. سيڪيورٽي خطرات کي ٻين سافٽ ويئر مسئلن وانگر ساڳيو علاج ڪيو وڃي، اهو آهي، انهن کي مجموعي DevOps عمل ۾ شامل ڪيو وڃي. توھان کي انھن سان گڏ ڪم ڪرڻ جي ضرورت آھي جيرا، ڪنبن وغيره. ڊولپرز اهو نه سوچڻ گهرجي ته ڪو ٻيو اهو ڪندو - ان جي برعڪس، هرڪو اهو ڪرڻ گهرجي. آخرڪار، توهان کي ماڻهن جي تربيت تي توانائي خرچ ڪرڻ جي ضرورت آهي.
ڪارآمد لنڪ
ھتي ڪجھ ڳالھيون آھن DevOops ڪانفرنس مان جيڪي توھان کي مفيد ملن ٿيون:
- سرجي برڊنيڪوف، آرٽيوم ڪليچڪن - ڪاميابي جي ڪهاڻي، يا "ديو + ڊي اوپس + اوپس" (, )
- باروچ سدوگورسڪي، ليونڊ ايگولنڪ - ڊي اوپس هڪ پيماني تي: هڪ يوناني سانحو ٽن عملن ۾ (, )
- اليگزينڊر Titov، Kirill Tolkachev -
- تيموٿي ليسٽر -
۾ ڏس DevOops 2020 ماسڪو - اتي پڻ ڪيتريون ئي دلچسپ شيون آھن.
جو ذريعو: www.habr.com