اسان ڳالهائي رهيا آهيون، يقينا، بابت . جيڪڏهن توهان تفصيل ۾ نه وڃو، ته پوءِ 30 سيپٽمبر ۽ 1 آڪٽوبر تي اسان ترقي، جاچ ۽ آپريشن جي عملن کي گڏ ڪرڻ تي هڪ ڪانفرنس منعقد ڪنداسين، ۽ جيڪڏهن توهان تفصيل ۾ وڃو، مهرباني ڪري، ٻلي هيٺ.
DevOps جي نقطه نظر جي اندر، منصوبي جي ٽيڪنالاجي ترقي جا سڀئي حصا هڪ ٻئي سان ڳنڍيل آهن، متوازي ۾ ٿين ٿا ۽ هڪ ٻئي تي اثر انداز ڪن ٿا. هتي خاص اهميت آهي خودڪار ترقي جي عملن جي پيدائش جيڪا حقيقي وقت ۾ تبديل، تخليق ۽ آزمائشي ٿي سگهي ٿي. هي توهان کي مارڪيٽ ۾ تبديلين کي فوري طور تي جواب ڏيڻ ۾ مدد ڪري ٿي.
ڪانفرنس ۾ اسان اهو ڏيکارڻ چاهيون ٿا ته اهو طريقو ڪيئن اثر انداز ٿئي ٿو پيداوار جي ترقي. ڪسٽمر لاءِ سسٽم جي اعتبار ۽ موافقت کي ڪيئن يقيني بڻايو وڃي ٿو. ڪيئن DevOps هڪ ڪمپني جي جوڙجڪ ۽ طريقي کي تبديل ڪري رهيو آهي ان جي ڪم جي عمل کي منظم ڪرڻ لاءِ.
پردي جي پويان
اهو ضروري آهي ته اسان لاءِ اهو ڄاڻڻ ضروري آهي ته نه رڳو مختلف ڪمپنيون ڇا ڪري رهيون آهن فريم ورڪ جي فريم ورڪ اندر DevOps اپروچ، پر اهو پڻ سمجهڻ ته اهو سڀ ڪجهه ڇو ڪيو ويو آهي. تنهن ڪري، اسان نه رڳو ماهرن کي پروگرام ڪميٽي ۾ شامل ٿيڻ جي دعوت ڏني، پر ماهرن جيڪي مختلف پوزيشن کان DevOps گفتگو کي ڏسندا آهن:
- سينئر انجنيئر؛
- ڊولپر
- ٽيم جي اڳواڻن؛
- سي ٽي او.
هڪ پاسي، هي مشڪلاتن ۽ تڪرار پيدا ڪري ٿو جڏهن رپورٽن جي درخواستن تي بحث ڪندي. جيڪڏهن هڪ انجنيئر ڪنهن وڏي حادثي جو تجزيو ڪرڻ ۾ دلچسپي رکي ٿو، ته پوءِ هڪ ڊولپر لاءِ اهو سمجهڻ وڌيڪ ضروري آهي ته اهو سافٽ ويئر ڪيئن ٺاهيو وڃي جيڪو بادل ۽ انفراسٽرڪچر ۾ ڪم ڪري. پر اتفاق ڪندي، اسان هڪ پروگرام ٺاهيندا آهيون جيڪو قيمتي ۽ دلچسپ هوندو هر ڪنهن لاءِ: انجنيئرن کان وٺي CTO تائين.
اسان جي ڪانفرنس جو مقصد صرف سڀ کان وڌيڪ hype رپورٽون چونڊڻ نه آهي، پر مجموعي تصوير پيش ڪرڻ آهي: ڪيئن DevOps طريقي سان عمل ۾ ڪم ڪري ٿو، نون عملن ڏانهن منتقل ٿيڻ وقت توهان ڪهڙي قسم جي ريڪ ۾ هلائي سگهو ٿا. ساڳئي وقت، اسان مواد جو حصو ٺاهيندا آهيون، ڪاروبار جي مسئلي کان مخصوص ٽيڪنالاجيز ڏانهن.
ڪانفرنس جا حصا ساڳيا ئي رهندا .
- انفراسٹرڪچر پليٽ فارم.
- بنيادي ڍانچي جي طور تي ڪوڊ.
- مسلسل پهچائڻ.
- رايا.
- DevOps ۾ آرڪيٽيڪچر، سي ٽي او لاءِ DevOps.
- SRE مشق.
- تربيت ۽ علم جو انتظام.
- سيڪيورٽي، DevSecOps.
- DevOps تبديلي.
ڪاغذن لاءِ ڪال ڪريو: اسان ڪهڙي قسم جون رپورٽون ڳولي رهيا آهيون
اسان مشروط طور تي ڪانفرنس جي امڪاني سامعين کي پنجن گروپن ۾ ورهايو: انجنيئر، ڊولپر، سيڪيورٽي ماهر، ٽيم ليڊز ۽ سي ٽي او. ڪانفرنس ۾ اچڻ لاءِ هر گروهه جو پنهنجو حوصلو آهي. ۽، جيڪڏهن توهان انهن پوزيشن مان DevOps کي ڏسو، توهان سمجهي سگهو ٿا ته توهان جي موضوع کي ڪيئن ڌيان ڏيڻ ۽ ڪٿي زور ڏيڻو آهي.
انجنيئرن لاءِ، جيڪي هڪ انفراسٽرڪچر پليٽ فارم ٺاهي رهيا آهن، اهو ضروري آهي ته موجوده رجحانن کي سمجهڻ، سمجهڻ لاءِ ته ڪهڙيون ٽيڪنالاجيون هاڻي سڀ کان وڌيڪ ترقي يافته آهن. اهي اهي ٽيڪنالاجيون استعمال ڪرڻ ۽ خيالن جي تبادلي ۾ حقيقي زندگي جي تجربي بابت سکڻ ۾ دلچسپي وٺندا. هڪ انجنيئر ڪجهه سخت حادثي جو تجزيو ڪندي رپورٽ ٻڌي خوش ٿيندو، ۽ اسان، بدلي ۾، اهڙي رپورٽ کي چونڊڻ ۽ پالش ڪرڻ جي ڪوشش ڪنداسين.
ڊولپرز لاء اهو ضروري آهي ته اهڙي تصور کي سمجهڻ لاء بادل جي اصلي ايپليڪيشن. اهو آهي، سافٽ ويئر ڪيئن ٺاهيو ته جيئن اهو بادل ۽ مختلف انفراسٽرڪچر ۾ ڪم ڪري. ڊولپر کي مسلسل سافٽ ويئر کان موٽ حاصل ڪرڻ جي ضرورت آهي. هتي اسان ڪيس ٻڌڻ چاهيون ٿا ته ڪمپنيون هن پروسيس کي ڪيئن ٺاهين ٿيون، سافٽ ويئر جي ڪارڪردگي جي نگراني ڪيئن ڪجي، ۽ پوري ترسيل عمل ڪيئن ڪم ڪري ٿي.
سائبر سيڪيورٽي ماهر اهو سمجهڻ ضروري آهي ته حفاظتي عمل کي ڪيئن سيٽ ڪيو وڃي ته جيئن اهو ڪمپني جي اندر ترقي ۽ تبديلي جي عمل کي روڪي نه ٿو. ضرورتن بابت موضوع جيڪي DevOps اهڙن ماهرن تي رکيا آهن اهي پڻ دلچسپ هوندا.
ٽيم جي اڳواڻي ڄاڻڻ چاهي ٿي، ڪيئن مسلسل ترسيل عمل ٻين ڪمپنين ۾ ڪم. ڪمپنيون هن کي حاصل ڪرڻ لاءِ ڪهڙو رستو اختيار ڪيون ، انهن DevOps اندر ترقي ۽ معيار جي يقين جي عمل کي ڪيئن ٺاهيو. ٽيم جي اڳواڻي پڻ دلچسپي رکن ٿا Cloud اصلي ۾. ۽ ٽيم جي اندر ۽ ترقي ۽ انجنيئرنگ ٽيمن جي وچ ۾ رابطي بابت پڻ سوال.
لاء CTO سڀ کان اهم شيء اهو معلوم ڪرڻ آهي ته انهن سڀني عملن کي ڪيئن ڳنڍجي ۽ انهن کي ڪاروباري ضرورتن سان ترتيب ڏيو. هن کي يقيني بڻائي ٿو ته ايپليڪيشن ڪاروبار ۽ ڪلائنٽ ٻنهي لاء قابل اعتماد آهي. ۽ هتي توهان کي سمجهڻ جي ضرورت آهي ته ڪهڙيون ٽيڪنالاجيون ڪم ڪنديون جن لاءِ ڪاروباري ڪم، ڪيئن ٺاهجي پوري عمل وغيره. سي ٽي او پڻ بجيٽ ڪرڻ جو ذميوار آهي. مثال طور، هن کي اهو سمجهڻ گهرجي ته ماهرن کي ٻيهر تربيت ڏيڻ تي ڪيترو رقم خرچ ڪرڻ جي ضرورت آهي ته جيئن اهي DevOps ۾ ڪم ڪري سگهن.
جيڪڏھن توھان کي انھن ڳالھين تي ڪجھ چوڻو آھي ته خاموش نه رھجو، . ڪاغذن لاءِ ڪال ڪرڻ جي آخري تاريخ 20 آگسٽ آهي. اڳ ۾ توهان رجسٽرڊ ڪيو، وڌيڪ وقت توهان کي پنهنجي رپورٽ کي حتمي شڪل ڏيڻ ۽ توهان جي پيشڪش لاء تيار ڪرڻو پوندو. تنهن ڪري، دير نه ڪريو.
خير، جيڪڏهن توهان کي عوامي طور تي ڳالهائڻ جي ضرورت ناهي، بس ۽ ساٿين سان ڳالھ ٻولھ ڪرڻ لاء سيپٽمبر 30 ۽ آڪٽوبر 1 تي اچو. اسان واعدو ڪيو ته اهو دلچسپ ۽ متاثر ڪندڙ هوندو.
اسان ڪيئن ڏسون ٿا DevOps
سمجھڻ لاءِ ته اسان جو مطلب ڇا آھي DevOps مان، مان سفارش ڪريان ٿو پڙھڻ (يا وري پڙھڻ) منھنجي رپورٽ“" مارڪيٽ جي لهرن ذريعي هلندي، مون ڏٺو ته ڪيئن DevOps جو خيال مختلف سائزن جي ڪمپنين ۾ تبديل ٿي رهيو آهي: هڪ نن Startup کان ملٽي نيشنل ڪمپنين تائين. رپورٽ ڪيترن ئي سوالن تي ٺهيل آهي، انهن جا جواب ڏيڻ سان توهان سمجهي سگهو ٿا ته ڇا توهان جي ڪمپني DevOps ڏانهن وڌي رهي آهي يا ڇا ڪنهن هنڌ مسئلا آهن.
DevOps هڪ پيچيده نظام آهي، ان ۾ شامل هجڻ گهرجي:
- ڊجيٽل پيداوار.
- ڪاروباري ماڊل جيڪي هن ڊجيٽل پيداوار کي ترقي ڪن ٿا.
- پراڊڪٽ ٽيمون جيڪي ڪوڊ لکن ٿيون.
- مسلسل پهچائڻ جا طريقا.
- پليٽ فارم هڪ خدمت جي طور تي.
- هڪ خدمت جي طور تي انفراسٽرڪچر.
- بنيادي ڍانچي جي طور تي ڪوڊ.
- اعتماد کي برقرار رکڻ لاءِ الڳ طريقا، DevOps ۾ ٺهيل.
- هڪ راءِ جو مشق جيڪو اهو سڀ بيان ڪري ٿو.
رپورٽ جي آخر ۾ هڪ ڊراگرام آهي جيڪو ڪمپني ۾ DevOps سسٽم جو خيال ڏئي ٿو. اهو توهان کي ڏسڻ جي اجازت ڏيندو ته توهان جي ڪمپني ۾ ڪهڙا عمل اڳ ۾ ئي منظم ڪيا ويا آهن ۽ جيڪي اڃا تائين تعمير ڪيا ويا آهن.
توهان رپورٽ جي وڊيو ڏسي سگهو ٿا .
۽ هاڻي اتي هڪ بونس ٿيندو: RIT++ 2019 کان ڪيترائي وڊيوز، جيڪي DevOps جي تبديلي جي سڀ کان عام مسئلن تي رابطو ڪن ٿا.
ڪمپني جي انفراسٽرڪچر هڪ پيداوار جي طور تي
Artyom Naumenko Skyeng ۾ DevOps ٽيم جي اڳواڻي ڪري ٿو ۽ پنهنجي ڪمپني جي انفراسٽرڪچر جي ترقي جو خيال رکي ٿو. هن ٻڌايو ته انفراسٽرڪچر SkyEng تي ڪاروباري عملن کي ڪيئن متاثر ڪري ٿو: ان لاءِ ROI کي ڪيئن ڳڻيو وڃي، حساب لاءِ ڪهڙا ميٽرڪ چونڊڻ گهرجن ۽ انهن کي بهتر ڪرڻ لاءِ ڪيئن ڪم ڪجي.
مائڪرو سروسز جي رستي تي
Nixys ڪمپني مصروف ويب منصوبن ۽ ورهايل سسٽم لاءِ مدد فراهم ڪري ٿي. ان جي ٽيڪنيڪل ڊائريڪٽر، بورس ايرشوف، ٻڌايو ته سافٽ ويئر پروڊڪٽس جو ترجمو ڪيئن ڪجي، جنهن جي ترقي 5 سال اڳ شروع ٿي (يا اڃا به وڌيڪ)، جديد پليٽ فارم تي.
ضابطي جي طور تي، اهڙيون منصوبا هڪ خاص دنيا آهن جتي انفراسٹرڪچر جي اهڙي اونداهي ۽ قديم ڪنڊون آهن جيڪي موجوده انجنيئر انهن جي باري ۾ نه ڄاڻندا آهن. ۽ فن تعمير ۽ ترقي جا طريقا جيڪي هڪ ڀيرو چونڊيا ويا هئا اهي پراڻا آهن ۽ ڪاروبار کي ترقي جي ساڳي رفتار ۽ نئين ورزن جي ڇڏڻ سان مهيا نٿا ڪري سگهن. نتيجي طور، هر پراڊڪٽ رليز هڪ ناقابل اعتماد جرئت ۾ بدلجي ٿو، جتي ڪجهه مسلسل بند ٿي ويندو آهي، ۽ سڀ کان وڌيڪ غير متوقع جڳهه ۾.
اهڙن منصوبن جي منتظمين کي لازمي طور تي سڀني ٽيڪنالاجي عملن کي تبديل ڪرڻ جي ضرورت آهي. هن جي رپورٽ ۾، بورس چيو:
- منصوبي لاءِ صحيح فن تعمير کي ڪيئن چونڊيو ۽ انفراسٽرڪچر کي ترتيب ۾ رکو؛
- ڪھڙا اوزار استعمال ڪرڻ ۽ تبديليءَ جي رستي ۾ ڪھڙا نقص پيش اچن ٿا؛
- اڳتي ڇا ڪجي.
رليز جي آٽوميشن يا جلدي ۽ بي دردي سان ڪيئن پهچائڻ
اليگزينڊر ڪوروٽڪوف CIAN ۾ CI/CD سسٽم جو هڪ معروف ڊولپر آهي. هن آٽوميشن ٽولز جي باري ۾ ڳالهايو جنهن اهو ممڪن ڪيو ته معيار کي بهتر بڻائڻ ۽ ڪوڊ پهچائڻ جو وقت 5 ڀيرا گھٽايو. پر اهڙا نتيجا صرف خودڪار طريقي سان حاصل نه ٿي سگهيا آهن، تنهنڪري اليگزينڊر پڻ ترقي جي عمل ۾ تبديلين ڏانهن ڌيان ڏنو.
حادثا توهان کي سکڻ ۾ ڪيئن مدد ڏين ٿا؟
Alexey Kirpichnikov 5 سالن کان SKB Kontur ۾ DevOps ۽ انفراسٽرڪچر لاڳو ڪري رهيو آهي. ٽن سالن جي عرصي دوران، تقريبن 1000 فيڪپس مختلف درجي جي ايپيڪيشن جي هن جي ڪمپني ۾ واقع ٿي. انهن مان، مثال طور، 36٪ پيداوار ۾ گهٽ معيار جي رليز کي رول ڪرڻ جي ڪري، ۽ 14٪ ڊيٽا سينٽر ۾ هارڊويئر جي سار سنڀال جي ڪم جي سبب هئا.
رپورٽن جو هڪ آرڪائيو (پوسٽ مارٽم) جنهن کي ڪمپني جا انجنيئر ڪيترن ئي سالن کان مسلسل برقرار رکيا آهن، اهو ممڪن بڻائي ٿو ته حادثن بابت اهڙي صحيح معلومات حاصل ڪرڻ. پوسٽ مارٽم ۾ ڊيوٽي تي موجود انجنيئر لکيو آهي، جنهن ايمرجنسي سگنل تي پهريون جواب ڏنو ۽ سڀ ڪجهه ٺيڪ ڪرڻ شروع ڪيو. انجنيئرن کي عذاب ڇو ٿا ڏين جيڪي رات جو فئڪس سان رپورٽون لکي جدوجهد ڪن ٿا؟ هي ڊيٽا توهان کي سڄي تصوير ڏسڻ جي اجازت ڏئي ٿي ۽ بنيادي ڍانچي جي ترقي کي صحيح هدايت ۾ منتقل ڪري ٿو.
پنهنجي تقرير ۾، اليڪسي ٻڌايو ته ڪيئن هڪ واقعي مفيد پوسٽ مارٽم لکڻ ۽ هڪ وڏي ڪمپني ۾ اهڙين رپورٽن جي عمل کي ڪيئن لاڳو ڪرڻ. جيڪڏهن توهان ڪهاڻيون پسند ڪندا آهيو ته ڪيئن ڪنهن کي خراب ڪيو، ڪارڪردگي جي وڊيو ڏسو.
اسان سمجھون ٿا ته توھان جو نظريو DevOps اسان سان نه ٿي سگھي. اهو ڄاڻڻ دلچسپ ٿيندو ته توهان ڪيئن ڏسو DevOps تبديلي. تبصرن ۾ هن موضوع جو پنهنجو تجربو ۽ نظريو حصيداري ڪريو.
اسان پروگرام ۾ ڪهڙيون رپورٽون قبول ڪيون آهن؟
هن هفتي پروگرام ڪميٽي 4 رپورٽون منظور ڪيون: سيڪيورٽي، انفراسٽرڪچر ۽ SRE عملن تي.
شايد DevOps جي تبديلي جو سڀ کان وڌيڪ ڏکوئيندڙ موضوع: ڪيئن پڪ ڪجي ته انفارميشن سيڪيورٽي ڊپارٽمينٽ جا ماڻهو ترقي، آپريشن ۽ انتظاميه جي وچ ۾ اڳ ۾ ئي ٺهيل رابطن کي تباهه نه ڪن. ڪجھ ڪمپنيون بغير معلومات جي حفاظت واري کاتي جي انتظام ڪن ٿيون. ڪيئن هن معاملي ۾ معلومات سيڪيورٽي کي يقيني بڻائڻ لاء؟ ان بابت مونا آرخپووا sudo.su کان. هن جي رپورٽ مان اسان سکندا آهيون:
- ڇا کي بچائڻ جي ضرورت آهي ۽ ڪنهن کان؛
- روزاني حفاظتي عمل ڇا آهن؛
- آئي ٽي ۽ انفارميشن سيڪيورٽي جا عمل ڪيئن هڪ ٻئي سان ملن ٿا؛
- CIS CSC ڇا آهي ۽ ان کي ڪيئن لاڳو ڪجي؛
- ڪيئن ۽ ڪھڙي اشارن سان باقاعدي معلومات جي حفاظتي چڪاس ڪرڻ لاءِ.
ايندڙ رپورٽ ڪوڊ جي طور تي بنيادي ڍانچي جي ترقي جو خدشو آهي. دستي معمول جي مقدار کي گھٽايو ۽ سڄي منصوبي کي افراتفري ۾ نه ڦيرايو، ڇا اهو ممڪن آهي؟ هن سوال ڏانهن ميڪسم Kostrikin Ixtens کان. هن جي ڪمپني استعمال ڪري ٿي ٽرافيف AWS انفراسٽرڪچر سان ڪم ڪرڻ لاءِ. اوزار آسان آهي، پر سوال اهو آهي ته ڪوڊ جو هڪ وڏو بلاڪ ٺاهڻ کان ڪيئن بچجي جڏهن ان کي استعمال ڪيو وڃي. اهڙي وراثت جي سار سنڀال هر سال وڌيڪ ۽ وڌيڪ مهانگو ٿيندو.
ميڪسم ڏيکاريندو ته ڪوڊ پليسمينٽ جا نمونا ڪيئن ڪم ڪن ٿا، جنهن جو مقصد آٽوميشن ۽ ڊولپمينٽ کي آسان ڪرڻ آهي.
ٻيو اسان انفراسٹرڪچر بابت ٻڌندا سين Playkey کان Vladimir Ryabov. هتي اسان انفراسٹرڪچر پليٽ فارم بابت ڳالهائينداسين، ۽ اسان سکنداسين:
- ڪيئن سمجهڻ ته ڇا اسٽوريج جي جاء کي مؤثر طريقي سان استعمال ڪيو پيو وڃي؛
- ڪئين سئو استعمال ڪندڙ 10 TB مواد حاصل ڪري سگھن ٿا جيڪڏهن صرف 20 TB اسٽوريج استعمال ڪئي وڃي.
- ڪئين ڊيٽا کي 5 ڀيرا دٻايو ۽ ان کي صارفين کي حقيقي وقت ۾ مهيا ڪريو؛
- ڪيترن ئي ڊيٽا سينٽرن جي وچ ۾ پرواز تي ڊيٽا کي هم وقت سازي ڪيئن ڪجي؛
- هڪ ٻئي تي استعمال ڪندڙن جي ڪنهن به اثر کي ڪيئن ختم ڪجي جڏهن هڪ ورچوئل مشين کي ترتيب وار استعمال ڪيو وڃي.
هن جادو جو راز ٽيڪنالاجي آهي ZFS مفت بي ايس ڊي لاءِ ۽ ان جو تازو ڪانٽو ZFS لينڪس تي. ولاديمير Playkey کان ڪيس شيئر ڪندو.
Matvey Kukuy Amixr.IO کان زندگي جي مثالن سان تيار ، ڇا ٿيو آهي SRE ۽ اهو ڪيئن مدد ڪري ٿو قابل اعتماد سسٽم ٺاهڻ ۾. Amixr.IO ڪلائنٽ جي واقعن کي پنهنجي پس منظر ذريعي گذري ٿو؛ دنيا جي ڪيترن ئي آن ڊيوٽي ٽيمن اڳ ۾ ئي 150 هزار ڪيسن کي ڊيل ڪيو آهي. ڪانفرنس ۾، Matvey انهن انگن اکرن ۽ بصيرت کي حصيداري ڪندو جيڪي هن جي ڪمپني کي گراهڪن جي مسئلن کي حل ڪرڻ ۽ ناڪامين جو تجزيو ڪندي گڏ ڪيو آهي.
هڪ ڀيرو ٻيهر آئون توهان کي گذارش ڪريان ٿو ته لالچ نه ٿيو ۽ پنهنجو تجربو حصيداري ڪريو DevOps ساموري جي طور تي. خدمت ڪرڻ هڪ رپورٽ لاءِ، ۽ توهان ۽ مون وٽ هڪ بهترين تقرير تيار ڪرڻ لاءِ 2,5 مهينا هوندا. جيڪڏهن توهان ٻڌندڙ ٿيڻ چاهيو ٿا، پروگرام جي تازه ڪارين سان نيوز ليٽر ڏانهن ۽ وقت کان اڳ ٽڪيٽن جي بکنگ بابت سنجيدگي سان سوچيو، ڇاڪاڻ ته اهي ڪانفرنس جي تاريخن جي ويجهو وڌيڪ قيمتي ٿي ويندا.
جو ذريعو: www.habr.com