DevOpsDays ماسڪو ڪانفرنس جو جائزو: 6 رپورٽن مان بصيرت

ٽين ڪانفرنس 7 ڊسمبر تي ٿي DevOpsDays ماسڪو، Mail.ru Cloud Solutions جي سهڪار سان ماسڪو DevOps ڪميونٽي پاران منظم ڪيل. معروف DevOps عملي جي پيشڪشن کان علاوه، شرڪت ڪندڙ مختصر حوصلہ افزائي لائٽنگنگ ڳالهين، ورڪشاپس ۽ کليل جڳهن ۾ گفتگو ڪري سگھن ٿا.

اسان ڇهن تقريرن ​​مان اهم بصيرت گڏ ڪئي ۽ ڪيترن ئي ڳالهائيندڙن سان انٽرويو ڪيو ته جيئن رپورٽن جي پويان ڇا رهجي ويو.

اندر:

1. باروچ سدوگورسڪي، جي فروگ: ”سوفٽ ويئر کي وهڻ ڏيو وينڊر کان صارف تائين مائع وانگر“
2. Pavel Selivanov، Southbridge: "ديو ۽ اوپس هڪ عام ڪم آهي - هڪ پيداوار ٺاهڻ جيڪو ڪم ڪري ٿو"
3. ولاديمير Utratenko، X5 پرچون گروپ: "انٽرپرائز ۾ DevOps درد ۽ باهه کان سواء ترقي آهي"
4. سرجي پوزيريف، فيسبوڪ: "پيداوار انجنيئر مجموعي طور تي خدمت جي باري ۾ خيال رکندو آهي: انهي ڪري ٻنهي صارفين ۽ ڊولپرز کي سٺو وقت آهي"
5. ميخائل چنڪوف، AMBOSS: "هڪ ڊپارٽمينٽ DevOps جي رستي تي عمل نٿو ڪري سگهي، سڄي ڪمپني کي ان جي پيروي ڪرڻ گهرجي"
6. Rosbank جي DevOps حوصلا افزائي: "1000 ڏينهن هڪ خوني ڪاروبار ۾ DevOps کي لاڳو ڪرڻ لاء"

1. Baruch Sadogursky، JFrog: "سافٽ ويئر کي وينڊر کان صارف ڏانهن وهڻ ڏيو جيئن مائع"

سافٽ ويئر اپڊيٽ جي ناڪامي هر ڪلاڪ ۽ هر ڪنهن لاءِ ٿيندي آهي. هتي تقرير مان صرف هڪ خوفناڪ ڪهاڻي آهي: نائيٽ ڪيپيٽل هڪ ڪلاڪ ۾ 440 ملين ڊالر وڃائي ڇڏيو هڪ ناڪام تازه ڪاري کانپوءِ.

باروچ مسلسل تازه ڪارين جي DevOps نمونن بابت ڳالهايو جيڪي ناڪامين ۽ صارف جي نفرت کان بچڻ ۾ مدد ڪندا:

مقامي واپسي - سافٽ ويئر جي پوئين ورزن کي توهان جي ڊوائيس تي رکو ته جيئن ڪجهه ٿئي ها. اهو توهان جي حفاظت ڪندو جيڪڏهن شيون ايترو خراب ٿي وڃن ته توهان هوا تي پيچ نه موڪلي سگهو.

هوائي اپڊيٽ جي مٿان - بهتر مسلسل. ٻي صورت ۾، اهو جيگوار ڊولپرز وانگر ٿيندو: برڪ سسٽم ۾ هڪ بگ جي ڪري، جيڪو هوا تي اپڊيٽ نه ٿي سگهيو، ڪارن کي وڪرو ڪرڻ کان واپس وٺڻو پوندو. اهو دردناڪ ۽ قيمتي هو.

مسلسل اپڊيٽ - سافٽ ويئر کي مسلسل اپڊيٽ ڪريو جيئن ئي نئون فيچر تيار ٿئي. ناياب تازه ڪارين سان، خاصيتون گڏ ڪيون ويون آهن؛ هڪ نازڪ تازه ڪاري غير نازڪ ماڻهن جو انتظار ڪري سگهي ٿي. وانگر Tesla ۾، هڪ تازه ڪاري جيڪا بي ترتيب واري برڪنگ کي درست ڪرڻ لاء هئي، شطرنج جي راند جي تازه ڪاري جي انتظار ۾ هئي.

خودڪار لڳائڻ - ماڻهن کي مشين سان تبديل ڪريو، ڇاڪاڻ ته ماڻهو معمول جي ڪمن کي انجام ڏيڻ ۾ خراب آهن.

بار بار اپڊيٽ - توهان کي عادت پيدا ڪرڻ ۽ خوف کان نجات حاصل ڪرڻ ۾ مدد ڪريو. ناياب اپڊيٽ ايمرجنسي واقعن ۾ تبديل ٿي.

ڊوائيس جي حالت کي ڄاڻڻ - تازه ڪاري ٽيسٽ، شروع کان انسٽاليشن نه. اهو ضروري آهي ڇو ته تازه ڪاري ٿي سگھي ٿي مختلف طريقي سان ڊوائيس جي حالت جي لحاظ سان.

ڪينري رليز - استعمال ڪندڙن جي ٿورڙي تعداد ۾ تازه ڪاريون جاري ڪريو ۽ مشاهدو ڪريو. اهو نقصان گھٽائي ٿو جيڪڏهن ڪجهه غلط ٿي وڃي.

بغير دستيابي جي تازه ڪاري - گراهڪن کي صرف نون خصوصيتن کي نوٽيس ڏيو، ۽ ڪيترن ئي هفتن تائين خدمت کان سواء نه رهجي وڃو جڏهن توهان هڪ تازه ڪاري جاري ڪريو.

اسان Baruch Sadogursky سان ڳالهايو ته روسي ۽ مغربي آئي ٽي ۾ DevOps تي نظر ڪيئن مختلف آهي، ڇا Cloud جلد ئي اسان لاء سڀ ڪجهه ڪندو ۽ ڇا سڀ سافٽ ويئر خدمتون AAS اسڪيم ۾ سلائڊ ٿينديون - انٽرويو ڏسو:

2. Pavel Selivanov، Southbridge: "ديو ۽ اوپس ھڪڙو عام ڪم آھي - ھڪڙو پراڊڪٽ ٺاهڻ جيڪو ڪم ڪري ٿو"

Kubernetes کي لاڳو ڪرڻ ۾ مدد نه ملندي DevOps حاصل ڪرڻ، ۽ ان جي برعڪس، اهو سڀ ڪجهه ٽوڙي سگهي ٿو. Pavel وضاحت ڪئي ته ٽيڪنالاجي (جيتوڻيڪ بهترين) توهان جا سڀئي مسئلا حل نٿا ڪري سگهن:

منصوبي جي پيچيدگي ڪوڊ کان ٻاهر نڪري وئي آهي. اڳي، اتي هڪ پيچيده ايپليڪيشن هئي: منصوبي جي اندر رابطي ۽ پيچيده ترقي، پر هڪ سادي جوڙجڪ - منتظم ان کي مقرر ڪيو، هر شي ڪم ڪري ٿو. اسان microservices ڏانهن منتقل ڪيو: هر خدمت هڪ سادي ايپليڪيشن آهي، مواصلاتي معياري پروٽوڪول استعمال ڪندي ۽ تيز ترقي، پر منصوبي جي جوڙجڪ وڌيڪ پيچيده ٿي چڪي آهي. هڪ منصوبي جي پيچيدگي هڪ microservice فن تعمير سان پري نه ويو آهي - اهو ڪوڊ کان ٻاهر نڪري ويو آهي. هاڻي DevOps انجنيئر ان لاء ذميوار آهي.

ڊولپر ڊي اوپس کي لاڳو ڪرڻ کان پوءِ تبديليون نٿا چاهين. نتيجي طور، ڪبرنيٽس سان ڪم جي وهڪري جاري رهي ٿي ديو کان اوپس تائين ڪمن کي ڀت جي مٿان اڇلڻ وانگر، نه رڳو هڪ استعاري هڪ - گٽ اهڙي ڀت بڻجي وڃي ٿي. ڊولپر اتي ڪوڊ رکي ٿو ۽ اڳي وانگر ڪم ڪري ٿو، ۽ منتظمين وٽ Kubernetes، CI/CD ۽ ٻيو سڀ ڪجهه آهي.

بهرحال، ڊولپرز کي تبديلين کي قبول ڪرڻ جي ضرورت آهي. اها صورتحال جڏهن ڊولپرز کي خبر ناهي ته ايڊمن ڇا ڪري رهيا آهن، ۽ منتظمين کي خبر ناهي ته ڊولپرز سان ڇا ٿي رهيو آهي، مسئلا پيدا ڪري ٿي.

جيڪڏهن ڊولپرز لاء ڪجھ به تبديل نه ڪيو آهي، انهن کي اهو احساس نه آهي ته ايپليڪيشن جو آپريشن انهن جي ذميواري آهي - مختلف ٽيڪنيڪل چالون ڪم نه ڪندا.

DevOps ۽ Kubernetes جي اچڻ سان، ترقي ۾ تمام گهڻو تبديل ٿيندو. Devs لازمي طور تي اوپس ۽ ان جي برعڪس ۾ قابل هوندو. انهن ماهرن وٽ پنهنجون مخصوص صلاحيتون آهن، پر انهن کي هڪ ٻئي جي ڪم کان واقف هجڻ گهرجي. ڪبرنيٽس کي لاڳو ڪرڻ کان پهريان ديو ۽ اوپس کي دوست ٿيڻ جي ضرورت آهي، ٻي صورت ۾ توهان کي ٽوڙي ڇڏيندو جيڪو توهان وٽ آهي.

Pavel Selivanov بابت ٻڌايو ته 5 سالن ۾ ڪبرنيٽس جو ڇا ٿيندو ۽ ڪهڙي جديد شروعات کي ٽيڪنالاجي اسٽيڪ تي تعمير ڪرڻ گهرجي - انٽرويو ڏسو:

3. Vladimir Utratenko، X5 پرچون گروپ: "انٽرپرائز ۾ DevOps درد ۽ باهه کان سواء ترقي آهي"

ڪمپنيون DevOps جي تبديليءَ تي اينديون آهن جڏهن انهن کي احساس هوندو آهي ته ترقي تمام سست آهي ۽ حقيقتن کي پورا نه ڪندي آهي، انهن کي بهتر ترقي ڪرڻ ۽ تيزيءَ سان رول آئوٽ ڪرڻ جي خواهش هوندي آهي.

ولاديمير وضاحت ڪئي ته اهو ڪيئن ٿئي ٿو ۽ پڪڙي ڇا آهي:

1. پهرين، ڪمپنيون هڪ DevOps انجنيئر ڪرائي. هي هڪ سينئر سسٽم ايڊمنسٽريٽر آهي، هو پيداوار لاءِ رليز کي ترتيب ڏيڻ، ترقياتي ماحول کي معياري بڻائڻ، انفراسٽرڪچر قائم ڪرڻ، مختلف مسئلن کي ڳولڻ ۽ حل ڪرڻ، خودڪار عمل ۽ ٻين فني ڪمن ۾ شامل آهي.
2. پوءِ هڪ DevOps انجنيئر هاڻي ڪافي نه رهيو آهي، ۽ ڪمپني هڪ DevOps ٽيم کي ڀرتي ڪري ٿي. هي هڪ قابليت جو مرڪز آهي جيڪو مختلف انجنيئرن جي ڪوششن کي منظم ڪري ٿو ۽ انهن کي هڪ طرف متمرکز ٿيڻ جي اجازت ڏئي ٿو.
3. حقيقت ۾، DevOps انجنيئر ۽ DevOps ٽيمون DevOps تبديليءَ جا مخالف نمونا آهن. جيئن ته DevOps طريقن ۽ ثقافت بابت آهي، ان کان علاوه، ٽيڪنالاجي ڪمپنيون (SRE، پيداوار انجنيئرنگ) ۾ DevOps جي عمل درآمد آهن.

ڇا ڪجي؟ هڪ عارضي DevOps ٽيم کي ڀرتي ڪريو جيڪا DevOps جي تبديلي کي لاڳو ڪرڻ ۾ مدد ڪندي، عمل کي انجام ڏيڻ، ترقي جي ثقافت ۽ ٽيڪنالاجي ڪلچر کي وڌائڻ ۾ مدد ڪندي.

جڏهن هڪ ڪاروبار راند ۾ اچي ٿو ۽ DevOps ۾ سيڙپ ڪري ٿو، ڪيترن ئي منظرنامي ممڪن آهن: هر شي ٽيڪ آف تي ڌار ٿي ويندي؛ SRE/Production Engineering يا Embedded Ops طور رھندو؛ BizOps ڏانھن منتقل ٿيندو، جڏھن عمل ڪاروباري ميٽرڪ تي ٻڌل آھن.

Vladimir Utratenko اسان کي ٻڌايو ته ڪيئن "خوني" DevOps هڪ ڪمپني ۾ واقعي آهي ۽ ڪئين طريقا وڏي پرچون ۾ لاڳو ٿين ٿا - انٽرويو ڏسو:

4. سرجي پوزيريف، فيسبوڪ: "پيداوار انجنيئر مجموعي طور تي خدمت جو خيال رکندو آهي: انهي ڪري ته صارفين ۽ ڊولپر ٻنهي کي سٺو وقت هجي"

Facebook هڪ وڏي ڪمپني آهي، جنهن ۾ گهڻن حصن، سرورز، ماڻهن ۽ ڊيٽا سينٽرن سان گڏ آهي. ان جي وڏي سائيز جي باوجود، اهو تمام تيز آهي - ڊولپرز هڪ ڏينهن ۾ ڪيترائي ڀيرا خدمتون سرانجام ڏئي سگهن ٿا. انهي سان گڏ، Facebook تيزي سان وڌي رهيو آهي، ۽ اهو صرف نه رڳو صارفين ۽ سرورز جو تعداد وڌي رهيو آهي، ڊولپرز جو تعداد پڻ وڌي رهيو آهي، جيڪو عمل کي وڌيڪ پيچيده بڻائي ٿو.

سرجي ٻڌايو ته ڇا هڪ پروڊڪشن انجنيئر Facebook تي ڪندو آهي:

1. هڪ پروڊڪشن انجنيئر تمام گهڻو ڪوڊ ڪري ٿو، هن کي سسٽم جي ڄاڻ هجڻ گهرجي: آپريٽنگ سسٽم، فائيل سسٽم، ڊيٽابيس، نيٽ ورڪ ۽ جهڙوڪ. ورهايل سسٽم ۽ قابل اعتماد انجنيئرنگ سان ڪم ڪرڻ جو تجربو هجڻ گهرجي، اهو آهي، پيداوار جي اعتماد جي حمايت ڪندي. اهو لازمي طور تي آن ڪال هجڻ گهرجي، اهو آهي، ڪنهن به وقت ڪال ڪرڻ لاءِ دستياب آهي.
2. پيداواري انجنيئر سافٽ ويئر انجنيئر کان مختلف آهي آپريشن ۾ اعليٰ صلاحيتن سان، پر حقيقت ۾، سافٽ ويئر انجنيئر جو هڪ ذيلي قسم آهي. سافٽ ويئر انجنيئرز وڌيڪ ڪوڊ؛ انهن وٽ شايد اضافي صلاحيتون هجن، مثال طور، ڊيٽا پروسيسنگ سان. فيس بوڪ تي، اهڙن ماهرن کي به آن ڪال هجڻ گهرجي، جيڪو ڪيترن ئي لاءِ اڻ وڻندڙ ​​تعجب جي طور تي اچي ٿو.
3. هڪ ڪمپني ۾ هڪ پيداوار انجنيئر جي ضرورتن جي ضرورتن جي نگراني سرورز ۽ انهن جي زندگي جي چڪر سان شروع ٿئي ٿي، اهو آهي، نئين هارڊويئر حاصل ڪرڻ، ان کي ترتيب ڏيڻ، ان کي هلائڻ ۾. ايندڙ سطح خدمت جي سطح تي ساڳيو آهي: نگراني خدمتون ۽ انهن جي زندگي جي چڪر. پوءِ اچي ٿو بيحد اسڪيلنگ ۽ جديد نگراني. سروس لائف چڪر خودڪار ٿيڻ کان پوءِ اھي آٽو اسڪيلنگ ڏانھن ويندا آھن. ۽ آخر ۾، ٽيوننگ ڪرڻ ضروري آهي ته جيئن اسڪيلنگ اثرائتو آهي ۽ ڪمپني پئسا ۽ وسيلن کي بچائيندو آهي.

5. ميخائل چنڪوف، AMBOSS: "هڪ ڊپارٽمينٽ DevOps جي رستي تي عمل نٿو ڪري سگهي، سڄي ڪمپني کي ان جي پيروي ڪرڻ گهرجي"

ميخائل مڃي ٿو ته DevOps مسلسل ترقي آهي. توھان ڪجھ اوزار متعارف نه ٿا ڪري سگھو ۽ اتي روڪي. ڪھڙا مسئلا ڪمپنين کي DevOps ٿيڻ کان روڪيندا آھن ۽ طريقا ڪيئن لاڳو ڪندا آھن؟

DevOps کي سمجهڻ ۾ فرق. Canonical devops، جيئن مبشرين ان کي ڏسندا آهن، 5 ٿنڀن تي ٻڌل آهن:

• ثقافت - ماڻهن ۽ تعاون تي ڌيان ڏيڻ؛
• آٽوميشن - ڪم جي فلو ڏانهن معمول جو وفد؛
• لين - استعمال ڪندڙ کي قيمت پهچائڻ تي زور؛
• حصيداري - علم جي مسلسل تبادلي؛
• ميٽرڪ ۽ انهن کي استعمال ڪندي موٽ حاصل ڪرڻ.

ڪمپنيون عام طور تي صرف آٽوميشن تي ڌيان ڏين ٿيون ۽ صارف کي قدر پهچائڻ. پر ثقافت، علم جي حصيداري، ۽ ترقي کي ٽريڪ ڪرڻ لاء DevOps ميٽرڪ پس منظر ۾ ڦهليل آهي.

DevOps معياري ڪرڻ جا چئلينجز. پيداوار جا مقصد مڙني ڪمپنين لاءِ مختلف آهن ۽ معياري نٿا ٿي سگهن. هڪ ڪمپني ۾ DevOps جي حالت خود ڪمپني تي منحصر آهي، پر ڪيترائي اهو نه ٿا سمجهن ۽ يقين ڪن ٿا ته اهو ڪافي آهي DevOps انجنيئر کي ڀرتي ڪرڻ لاءِ.

اسان اڃا تائين DevOps ڇو نه آهيون؟ اتي ٻه اهم مسئلا آهن. انٽرپرائز ۾ تنظيم جي سست ترقي آهي، هزارين ملازمن جي ذهنن ۾ ویکٹر کي تبديل ڪرڻ ۾ مشڪلات. شروعاتن ۾، علم جي ذريعن جي کوٽ آهي ۽ تبديلي لاءِ وسيلا مختص ڪرڻ ۾ مسئلو آهي.

هڪ ڪمپني ۾ DevOps ترقي جا مرحلا:

• پهرين ڪلائوڊ ۾ انفراسٽرڪچر آهي، پر ڪنهن کي به خبر ناهي ته اهو ڪيئن ڪم ڪري ٿو سواءِ هڪ يا ٻن منتظمن جي؛
• ٻيو، انفراسٽرڪچر شفاف ۽ سڀني انجنيئرن لاءِ سمجھ ۾ اچي ٿو، پر عمل سڌريل نه آھن؛
• ٽيون - انجنيئر آزاد طور تي لائيو سروسز لانچ ۽ مرمت ڪرڻ؛
• چوٿون - انجنيئر اختياري طور تي بنيادي انفراسٽرڪچر، ڪلائوڊ ۾ شفاف ڪوڊ، بٽڻ ذريعي ترتيب ڏيڻ ۾ حصو وٺندا.

مثالي اسڪيم اهو آهي ته هر ڪنهن کي بنيادي ڍانچي تائين ساڳي رسائي آهي، سڀني انجنيئرن کي پيداوار تائين رسائي آهي ۽ سمجهي رهيا آهن ته اهي ڇا ڪري رهيا آهن.

سڀني ثقافتي ۽ ٽيڪنيڪل گيسٽلٽس کي بند ڪرڻ سان، ڪمپني جي DevOps جي تبديلي ڪاروبار ۽ پليٽ فارم جي ميٽرڪ جي حساب سان موٽ ۾ وٺندي.

6. Rosbank جي DevOps حوصلا افزائي: "هڪ خوني ڪاروبار ۾ DevOps کي لاڳو ڪرڻ لاءِ 1000 ڏينهن"

Rosbank مان يوري بليچ، ڊينا مالسيوا، ايجيني پينڪوف ٻڌايو ته اهي ڪيئن ٽن سالن ۾ DevOps ۾ آيا. اتي ٻه مقصد هئا: مخصوص ٽيمن ۾ مخصوص مسئلن کي حل ڪرڻ ۽ مرڪزي اوزار کي لاڳو ڪرڻ.

هتي حاصل ڪيل نتيجا آهن:

پراڊڪٽ ٽيمن لاءِ نتيجا: 30 ڀيرا تيز اسيمبلي، 6 ڀيرا تيز تنصيب، مڪمل چڪر تي 30٪ بچت تائين. اسان وٽ هاڻي هڪ بٽڻ کي دٻائڻ جي صلاحيت آهي پيداوار ڏانهن وڃڻ لاءِ

پليٽ فارم جي حڪمن جا نتيجا: 10 ڀيرا تيز اسيمبلي ۽ تنصيب، 87٪ اضافو تعداد تنصيب، 46٪ آٽو ٽيسٽ ڪوريج. انٽيگريشن ٽيم هاڻي ڪا رڪاوٽ نه رهي آهي

تنهن ڪري، خوني ڪاروبار ۾ DevOps طريقن کي ڪيئن لاڳو ڪجي؟

پهرين هڪ پائلٽ پروجيڪٽ تي عمل ڪريو: ٽيمون منتخب ڪريو، فيصلو ڪريو ته فن تعمير کي ڪيئن لاڳو ڪجي، ۽ اوزار چونڊيو. اسان هڪ کليل لائسنس سان اوزار چونڊيو، بينڪ ۾ تنصيب ۽ انهن سان ڪم ڪرڻ ۾ ماهر. Rosbank هڪ ئي وقت ۾ DevOps پليٽ فارم سان گڏ هڪ خانگي بادل کي ترتيب ڏنو، ۽ هن شروعات ۾ مدد ڪئي. بادل ۾، 15 منٽن ۾ هڪ بٽڻ استعمال ڪندي ضروري وسيلن کي حاصل ڪرڻ ممڪن هو؛ اڳ ۾، اهڙي عمل هڪ هفتي وٺي سگهي ٿي.

بينڪن ۽ ٻين ادارن ۾، ضروري آهي ته اڳ ۾ پابنديون ڪم ڪرڻ لاء معلومات سيڪيورٽي ٽيم سان گڏ ۽ هڪ حل ڳوليو جيڪو تبديلين کي لاڳو ڪرڻ جي اجازت ڏيندو.

پائلٽ کان پوء، ڪامياب حل کي وڌائڻ جي ضرورت آهي.

1. اهو ضروري آهي ته پائپ لائن کي ممڪن طور تي "سڌو" ڪرڻ، ان مان غير ضروري لنڪس کي ختم ڪرڻ، قدر فراهم ڪندڙ کي اجاگر ڪرڻ، ۽ باقي اجزاء کي هٽائڻ. Intermediates antipatterns آهن. مثال طور، Rosbank تي، ٽيمن جو هڪ انگ اندروني ترقي نه ڪيو، صرف خارجي ترقي ڇڏي. اهو هڪ وقف DevOps ٽيم جي اڀرڻ جو سبب بڻيو، جنهن ڪوڊ جي منتقلي کي خارجي کان اندروني ڊولپرز کي يقيني بڻايو. اهو مسئلو خارجي ترقي کي CI/CD ۾ ضم ڪرڻ سان حل ڪيو ويو، ته جيئن اهي نه صرف ڪوڊ کي پاڻ کان بئنڪ ڏانهن منتقل ڪن، پر ان جي ڪاميابي جا ذميوار پڻ هوندا.
2. پختگي جي ماڊل ۾ DevOps جي عملن جا عنصر، فهرست ڏنل اوزار، ۽ خارجي سپلائرز سان ڪم ڪرڻ جي خاصيتن کي شامل ڪيو ويو - مستقبل ۾، ھن نئين ٽيمن ۾ انھن کي لاڳو ڪرڻ وقت ڪمن جي پٺڀرائي کي جلدي گھٽائڻ ۾ مدد ڪئي.
3. اسان کي گورننس جي ضرورت آهي نرم ڪنٽرول ۽ سفارشن جي صورت ۾. هڪ DevOps هينڊ بڪ جيڪو سٺو ڪم ڪري ٿو تنظيمي ۽ ٽولنگ خاصيتن جو هڪ سيٽ آهي جيڪو ٽيمن کي پليٽ فارم کي صحيح طريقي سان استعمال ڪرڻ ۾ مدد ڪري ٿو.
4. توهان کي فوري طور تي ثقافت ڏانهن ڌيان ڏيڻ گهرجي، پوء ڪيتريون ئي تبديليون تيز ۽ آسان ٿي وينديون. پنھنجي اندروني ڪميونٽي کي وڌايو، گڏجاڻيون، ٽيڪنيڪل ورڪشاپون، تربيتون، ۽ تفريحي سرگرميون. هي ميوو ڏئي ٿو: ماڻهو عملن کي حصيداري ڪن ٿا، ڏسو ڪنهن ڇا ڪيو، ڄاڻو ته ڪٿي ڦيرايو، ڪمپني جي اندر هائپ ۽ صحتمند مقابلو آهي.
5. انهن سان ڪم ڪرڻ جو ڪو به مقصد ناهي جيڪي عمل ۾ شامل نه آهن، ٽيمن سان جيڪي پختو نه ٿيا آهن؛ اهو بهتر آهي ته دلچسپي ٽيمن ۽ وفادار ماڻهن ۾ سيڙپڪاري ڪرڻ.
6. چونڊيل حل انهن انجنيئرن لاءِ آسان هجڻ گهرجي جيڪي ان کي استعمال ڪن ٿا.
7. بيروني ترقي ڪا رڪاوٽ نه آهي؛ اتي پڻ عمل ڪري سگهجي ٿو، بنيادي شيء اها آهي ته ٽيم پاڻ کي خواهش آهي.

ٿورو وڌيڪ فائدو

ڪتابن جي فهرست جيڪي انهن لاء پڙهڻ جي قابل آهن DevOps ۾، اليگزينڊر چستياڪوف، vdsina.ru کان:

1. ارينا يڪوتينڪو "مرضي ۽ خود سنڀال."
2. دانيال Kahneman "سوچڻ، تيز ۽ سست".
3. باربرا اوکلي "نمبرن لاء هڪ دماغ".
4. ميڪسم Dorofeev "Jedi ٽيڪنالاجي".
5. Viktor Frankl "انسان جي معني جي ڳولا".

نظر رکيو

اسان کي به پيار آهي DevOps. سيريز جي اعلانن تي عمل ڪريو @DevOps ۽ @Kubernetes، گڏوگڏ ٻيا Mail.ru Cloud Solutions واقعا، اسان جي ٽيليگرام چينل ۾: t.me/k8s_mail

جو ذريعو: www.habr.com