DevOps جي تعريف تمام پيچيده آهي، تنهنڪري اسان کي هر وقت ان بابت بحث شروع ڪرڻو پوندو. اڪيلي Habré تي هن موضوع تي هڪ هزار اشاعتون آهن. پر جيڪڏهن توهان هن کي پڙهي رهيا آهيو، توهان شايد ڄاڻو ٿا ته DevOps ڇا آهي. ڇاڪاڻ ته مان نه آهيان. هيلو منهنجو نالو آهي اليگزينڊر ٽيتوف (@)، ۽ اسان صرف DevOps بابت ڳالهائينداسين ۽ مان پنهنجو تجربو شيئر ڪندس.
مان هڪ ڊگهي وقت کان سوچي رهيو آهيان ته منهنجي ڪهاڻي کي ڪارائتو ڪيئن بڻايو وڃي، تنهن ڪري هتي ڪيترائي سوال هوندا - اهي جيڪي آئون پاڻ کان پڇان ٿو ۽ اهي جيڪي آئون پنهنجي ڪمپني جي گراهڪن کان پڇان ٿو. انهن سوالن جا جواب ڏيڻ سان، سمجهه بهتر ٿي ويندي آهي. مان توهان کي ٻڌايان ٿو ته منهنجي نقطي نظر کان DevOps جي ضرورت ڇو آهي، اهو ڇا آهي، ٻيهر، منهنجي نقطي نظر کان، ۽ ڪيئن سمجهي ته توهان منهنجي نقطي نظر کان DevOps ڏانهن وڌي رهيا آهيو. آخري نقطو سوالن ذريعي ٿيندو. انهن کي پنهنجو پاڻ لاءِ جواب ڏيڻ سان، توهان سمجهي سگهو ٿا ته ڇا توهان جي ڪمپني DevOps ڏانهن وڌي رهي آهي يا ڇا ڪجهه طريقي سان مسئلا آهن.
ڪنهن زماني ۾ مان ضم ٿيڻ ۽ حاصل ڪرڻ جي موج ۾ سوار هوس. پهرين، مون Qik نالي هڪ ننڍڙي اسٽارٽ اپ لاءِ ڪم ڪيو، پوءِ اهو Skype نالي هڪ ٿوري وڏي ڪمپني طرفان خريد ڪيو ويو، جنهن کي پوءِ Microsoft نالي هڪ ٿوري وڏي ڪمپني خريد ڪيو. ان وقت، مون ڏسڻ شروع ڪيو ته ڪيئن مختلف سائز جي ڪمپنين ۾ DevOps جو خيال تبديل ٿي رهيو هو. ان کان پوء، مون کي مارڪيٽ جي نقطي نظر کان DevOps ڏسڻ ۾ دلچسپي پيدا ٿي، ۽ منهنجي ساٿين ۽ مون ڪمپني ايڪسپريس 42 جو بنياد وڌو. 6 سالن کان هاڻي اسان مارڪيٽ جي موج سان گڏ هلي رهيا آهيون.
ٻين شين مان، مان هڪ آهيان DevOps ماسڪو ڪميونٽي جي آرگنائيزر ۽ DevOps-Days 2017 جو آرگنائيزر، پر مون 2018 کي منظم نه ڪيو. ايڪسپريس 42 ڪيترن ئي ڪمپنين سان ڪم ڪري ٿو. اسان اتي وڌون ٿا DevOps، ڏسو ته اهو ڪيئن ٿئي ٿو، نتيجو ڪڍو، تجزيو ڪيو، سڀني کي اسان جي نتيجن کي ٻڌايو، ۽ ماڻهن کي DevOps طريقن ۾ تربيت ڏيو. عام طور تي، اسان ان سلسلي ۾ اسان جي تجربي ۽ صلاحيت کي وڌائڻ لاء اسان جي بهترين ڪوشش ڪري رهيا آهيون.
ڇو DevOps
پهريون سوال جيڪو سڀني کي پريشان ڪري ٿو ۽ هميشه آهي - ڇو؟ ڪيترن ئي ماڻهن جو خيال آهي ته DevOps صرف آٽوميشن يا ساڳي شيءِ آهي جيڪا هر ڪمپني اڳ ۾ ئي هئي.
- اسان وٽ مسلسل انٽيگريشن هو - ان جو مطلب آهي ته اسان وٽ اڳ ۾ ئي DevOps هئا، ۽ اهو سڀ سامان ڇو گهربل آهي؟ اهي ٻاهرين ملڪ ۾ مزو ڪري رهيا آهن، پر اهي اسان کي ڪم ڪرڻ کان روڪي رهيا آهن!
9 سالن کان وڌيڪ ڪميونٽي جي ترقي ۽ طريقيڪار، اهو اڳ ۾ ئي واضح ٿي چڪو آهي ته اهو اڃا تائين مارڪيٽنگ جي چمڪندڙ ناهي، پر اهو اڃا تائين مڪمل طور تي واضح ناهي ته اهو ڇو ضروري آهي. ڪنهن به اوزار ۽ عمل وانگر، DevOps وٽ خاص مقصد آهن جيڪي اهو آخرڪار حاصل ڪري ٿو.
اهو سڀ ڪجهه ان حقيقت جو سبب آهي ته دنيا بدلجي رهي آهي. هو انٽرپرائز جي نقطه نظر کان پري هليو وڃي ٿو، جڏهن ڪمپنيون سڌو سنئون هڪ خواب ڏانهن هلن ٿيون، جيئن اسان جي سينٽ پيٽرسبرگ جي ڪلاسيڪل گيت، پوائنٽ A کان پوائنٽ B تائين هڪ خاص حڪمت عملي جي مطابق، ان لاءِ ٺهيل هڪ خاص ڍانچي سان.
اصول ۾، آئي ٽي ۾ هر شي کي هن طريقي جي مطابق تعمير ڪيو وڃي. هتي آئي ٽي خاص طور تي خودڪار طريقي سان عمل ڪرڻ لاء استعمال ڪيو ويندو آهي.
خودڪار طريقي سان تبديل نه ڪندو آهي، ڇاڪاڻ ته جڏهن هڪ ڪمپني هڪ سٺي نموني هيٺ ٿي وڃي ٿي، اتي ڇا تبديلي آهي؟ اهو ڪم ڪري ٿو - ان کي هٿ نه ڪريو. هاڻي دنيا ۾ طريقا تبديل ٿي رهيا آهن، ۽ جنهن کي Agile سڏيو وڃي ٿو اهو مشورو ڏئي ٿو ته آخري نقطو B فوري طور تي نظر نٿو اچي.
جڏهن ڪا ڪمپني مارڪيٽ مان گذري ٿي، هڪ ڪلائنٽ سان ڪم ڪري ٿي، اها مسلسل مارڪيٽ کي ڳولي ٿي ۽ آخري نقطي B کي تبديل ڪري ٿي. ان کان علاوه، گهڻو ڪري ڪمپني پنهنجو رخ بدلائي ٿو، وڌيڪ ڪامياب آهي آخر ۾، ڇاڪاڻ ته اها وڌيڪ مارڪيٽ چونڊيندي آهي. niches.
حڪمت عملي هڪ دلچسپ ڪمپني پاران ظاهر ڪئي وئي آهي جنهن بابت مون تازو سکيو آهي. One Box Shave هڪ سبسڪرپشن ترسيل سروس آهي ريزر ۽ شيونگ لوازمات لاءِ هڪ باڪس ۾. اهي ڄاڻن ٿا ته انهن جي "باڪس" کي مختلف گراهڪن لاء ڪيئن ترتيب ڏيڻ. اهو هڪ خاص سافٽ ويئر طرفان ڪيو ويندو آهي، جيڪو پوء آرڊر موڪلي ٿو ڪورين فيڪٽري ڏانهن جيڪو پيداوار پيدا ڪري ٿو.
هي پراڊڪٽ يونيليور طرفان 1 بلين ڊالر ۾ خريد ڪيو ويو. اهو هاڻي Gillette سان مقابلو ڪري ٿو ۽ آمريڪي مارڪيٽ ۾ صارفين جو هڪ اهم حصو ورتو آهي. هڪ باڪس شيو چوي ٿو:
- 4 بلڊ؟ ڇا توهان سنجيده آهيو؟ توھان کي ھن جي ضرورت ڇو آھي - اھو ڇانو جي معيار کي بھتر نٿو ڪري. هڪ خاص طور تي چونڊيل ڪريم، خوشبو ۽ هڪ اعليٰ معيار جو ريزر ٻن بليڊن سان انهن بيوقوف 4 گليٽ بليڊن کان وڌيڪ مسئلا حل ڪري ٿو! ڇا اسان جلد ئي 10 تائين پهچي ويندا؟
اهڙيءَ طرح دنيا بدلجي ٿي. يونيليور دعويٰ ڪري ٿو ته انهن وٽ هڪ بهترين آئي ٽي سسٽم آهي جيڪو توهان کي اهو ڪرڻ جي اجازت ڏئي ٿو. آخر ۾ اهو هڪ تصور وانگر ڏسڻ ۾ اچي ٿو وقت جي بازار ۾، جنهن جي باري ۾ ڪنهن به اڳ ۾ ئي نه ڳالهايو آهي.
وقت کان مارڪيٽ جو نقطو اهو ناهي ته اسان ڪيترا ڀيرا ترتيب ڏيون ٿا. توھان اڪثر ڪري سگھوٿا، پر ڇڏڻ واري چڪر ڊگھي ٿيندي. جيڪڏهن ٽن مهينن جي رليز سائيڪلن کي هڪ ٻئي تي سپرد ڪيو وڃي ٿو، انهن کي هڪ هفتي تائين منتقل ڪندي، اهو ظاهر ٿئي ٿو ته ڪمپني هفتي ۾ هڪ ڀيرو ترتيب ڏيڻ لڳي ٿي. ۽ خيال کان حتمي عمل درآمد تائين 3 مهينا لڳن ٿا.
وقت کان مارڪيٽ خيال کان حتمي عمل درآمد تائين وقت کي گھٽائڻ بابت آهي.
انهي صورت ۾، سافٽ ويئر مارڪيٽ سان رابطو ڪري ٿو. هي ڪيئن آهي One Box Shave ويب سائيٽ ڪلائنٽ سان لهه وچڙ ۾. انهن وٽ وڪرو ڪندڙ ماڻهو نه آهن - صرف هڪ ويب سائيٽ جتي دورو ڪندڙ ڪلڪ ڪندا آهن ۽ خواهشون ڇڏيندا آهن. انهي جي مطابق، ڪجهه نئين سائيٽ تي مسلسل پوسٽ ڪيو وڃي ۽ خواهش جي مطابق اپڊيٽ ڪيو وڃي. مثال طور، ڏکڻ ڪوريا ۾، اهي روس جي ڀيٽ ۾ مختلف طور تي ڇڪيندا آهن، ۽ اهي خوشبو پسند ڪن ٿا پائن جي نه، پر، مثال طور، گاجر ۽ وينلا جي.
جيئن ته سائيٽ جي مواد کي جلدي تبديل ڪرڻ ضروري آهي، سافٽ ويئر ڊولپمينٽ تمام گهڻو تبديل ڪري ٿي. سافٽ ويئر ذريعي اسان کي اهو معلوم ڪرڻو پوندو ته ڪلائنٽ ڇا ٿو چاهي. اڳي، اسان اهو سکيو ڪجهه گولاباٽ طريقن ذريعي، مثال طور، ڪاروباري انتظام ذريعي. پوءِ اسان ان کي ڊزائين ڪيو، آئي ٽي سسٽم ۾ گهرجون پوريون ڪيون، ۽ سڀ ڪجھ ٿڌو هو. هاڻي اهو مختلف آهي - سافٽ ويئر هر ڪنهن طرفان ٺاهيو ويو آهي جيڪو پروسيس ۾ شامل آهي، انجنيئرن سميت، ڇاڪاڻ ته ٽيڪنيڪل وضاحتن ذريعي اهي سکندا آهن ته مارڪيٽ ڪيئن ڪم ڪري ٿي ۽ ڪاروبار سان پنهنجون بصيرتون پڻ شيئر ڪن.
مثال طور، Qik تي اوچتو اسان کي معلوم ٿيو ته ماڻهو واقعي پسند ڪندا آهن رابطي جي فهرستن کي سرور تي اپلوڊ ڪرڻ، ۽ انهن اسان کي هڪ ايپليڪيشن فراهم ڪئي. شروعات ۾ اسان ان بابت نه سوچيو. هڪ کلاسک ڪمپني ۾، هرڪو اهو فيصلو ڪري ها ته اهو هڪ بگ آهي، ڇاڪاڻ ته اها وضاحت نه هئي ته اهو تمام سٺو ڪم ڪرڻ گهرجي ۽ عام طور تي گوڏن تي لاڳو ڪيو ويو آهي، انهن خصوصيت کي بند ڪري ڇڏيو ۽ چيو: "ڪنهن کي به ضرورت ناهي، سڀ کان اهم شيء اها آهي ته مکيه ڪارڪردگي ڪم ڪري ٿي." . ۽ ٽيڪنالاجي ڪمپني هن کي هڪ موقعو طور ڏسي ٿو ۽ انهي جي مطابق سافٽ ويئر کي تبديل ڪرڻ شروع ڪري ٿو.
1968 ۾، هڪ بصيرت انسان، ميلون ڪنوي، هيٺ ڏنل خيال کي ترتيب ڏنو.
اهو تنظيم جيڪو سسٽم ٺاهي ٿو اهو هڪ ڊزائن طرفان محدود آهي جيڪو انهي تنظيم جي مواصلاتي جوڙجڪ کي نقل ڪري ٿو.
وڌيڪ تفصيل ۾، مختلف قسم جي سسٽم پيدا ڪرڻ لاء، توهان وٽ پڻ هڪ مختلف قسم جي ڪمپني جي اندر مواصلاتي جوڙجڪ هجڻ گهرجي. جيڪڏهن توهان جي ڪميونيڪيشن جو ڍانچو اعليٰ درجي وارو آهي، ته پوءِ اهو توهان کي سسٽم ٺاهڻ جي اجازت نه ڏيندو جيڪي هڪ تمام اعليٰ وقت کان مارڪيٽ اشارو مهيا ڪري سگھن.
پڙهو سگهن ٿا . اھو ضروري آھي سمجھڻ لاءِ DevOps ڪلچر يا فلسفو ڇاڪاڻ ته واحد شيء جيڪا بنيادي طور تي DevOps ۾ تبديل ٿئي ٿي ٽيمن جي وچ ۾ رابطي جي جوڙجڪ آهي.
عمل جي نقطي نظر کان، DevOps کان اڳ، سڀئي مرحلا: تجزياتي، ترقي، جاچ، آپريشن، لڪير هئا.
DevOps جي صورت ۾، اهي سڀئي عمل هڪ ئي وقت ۾ ٿين ٿا.
وقت کان مارڪيٽ جو واحد طريقو آهي جيڪو اهو ڪري سگهجي ٿو. انهن ماڻهن لاءِ جيڪي پراڻي عمل ۾ ڪم ڪندا هئا، اهو ڏسڻ ۾ اچي ٿو ڪنهن حد تائين ڪائناتي، ۽ عام طور تي ائين.
پوءِ توهان کي DevOps جي ضرورت ڇو آهي؟
ڊجيٽل پيداوار جي ترقي لاء. جيڪڏهن توهان جي ڪمپني وٽ ڊجيٽل پيداوار نه آهي، DevOps جي ضرورت ناهي - اهو تمام ضروري آهي.
DevOps ترتيب واري سافٽ ويئر جي پيداوار جي رفتار جي حدن کي ختم ڪري ٿو. ان ۾ سڀ عمل هڪ ئي وقت ٿين ٿا.
ڏکيائي وڌي ٿي. جڏهن DevOps مبشر توهان کي ٻڌائين ٿا ته اهو توهان لاءِ سافٽ ويئر ڇڏڻ آسان بڻائي ڇڏيندو ، هي بيوقوفي آهي.
DevOps سان، شيون صرف وڌيڪ پيچيده ٿي وينديون.
ڪانفرنس ۾ Avito اسٽينڊ تي، توهان ڏسي سگهو ٿا ته اهو ڇا هو ڊاکر ڪنٽينر کي ترتيب ڏيڻ - هڪ غير حقيقي ڪم. پيچيدگي ممنوع ٿي ويندي آهي؛ توهان کي هڪ ئي وقت ڪيترن ئي بالن کي ڇڪڻو پوندو.
DevOps مڪمل طور تي ڪمپني ۾ عمل ۽ تنظيم کي تبديل ڪري ٿو - وڌيڪ واضح طور تي، اهو DevOps نه آهي جيڪو تبديل ڪري ٿو، پر ڊجيٽل پيداوار. DevOps ڏانھن اچڻ لاءِ، توھان کي اڃا تائين ھن عمل کي مڪمل طور تي تبديل ڪرڻو پوندو.
هڪ ماهر لاء سوال
توهان وٽ ڇاآهي؟ سوال جيڪي توهان پنهنجي پاڻ کان پڇي سگهو ٿا جڏهن هڪ ڪمپني ۾ ڪم ڪندي ۽ هڪ ماهر جي حيثيت سان ترقي ڪندي.
ڇا توهان وٽ ڊجيٽل پراڊڪٽ ٺاهڻ جي حڪمت عملي آهي؟ جيڪڏهن اتي آهي، اهو اڳ ۾ ئي سٺو آهي. ان جو مطلب آهي توهان جي ڪمپني DevOps ڏانهن وڌي رهي آهي.
ڇا توهان جي ڪمپني اڳ ۾ ئي هڪ ڊجيٽل پيداوار ٺاهيندي آهي؟ ان جو مطلب اهو آهي ته توهان هڪ ٻي سطح بلند ڪري سگهو ٿا ۽ شيون وڌيڪ دلچسپ طريقي سان ڪري سگهو ٿا - ٻيهر هڪ DevOps نقطي نظر کان. مان صرف هن نقطي نظر کان ڳالهائي رهيو آهيان.
ڇا توهان جي ڪمپني ڊجيٽل پراڊڪٽ جي جڳهه ۾ مارڪيٽ جي اڳواڻن مان هڪ آهي؟ Spotify، Yandex، Uber اهي ڪمپنيون آهن جيڪي هاڻي ٽيڪنالاجي ترقي جي چوٽي تي آهن.
پنهنجو پاڻ کان پڇو اهي سوال، ۽ جيڪڏهن سڀئي جواب نه آهن، ته شايد توهان کي هن ڪمپني ۾ DevOps نه ڪرڻ گهرجي. جيڪڏهن DevOps جو موضوع واقعي توهان لاءِ دلچسپ آهي، شايد... توهان کي ڪنهن ٻئي ڪمپني ڏانهن وڃڻ گهرجي؟ جيڪڏهن توهان جي ڪمپني DevOps ۾ وڃڻ چاهي ٿي، پر توهان سڀني سوالن جو جواب ڏنو ”نه“، پوءِ اهو ان خوبصورت گينڊا جهڙو آهي جيڪو ڪڏهن به تبديل نه ٿيندو.
تنظيم
جيئن مون چيو، ڪنوي جي قانون موجب، ڪمپني جي تنظيم تبديل ٿي. مان ان سان شروع ڪندس جيڪو DevOps کي تنظيمي نقطي نظر کان ڪمپني جي اندر داخل ٿيڻ کان روڪي ٿو.
”کوهه“ جو مسئلو
انگريزي لفظ "Silo" هتي روسي ۾ ترجمو ڪيو ويو آهي " well". هن مسئلي جو نقطو اهو آهي ٽيمن جي وچ ۾ معلومات جي ڪا به مٽائي نه آهي. هر ٽيم پنهنجي ماهريت ۾ گهڻي کوٽائي ڪري ٿي، بغير ويجهڙائيءَ لاءِ هڪ عام نقشو ٺاهي.
ڪجهه طريقن سان اهو مون کي هڪ شخص جي ياد ڏياريندو آهي جيڪو صرف ماسڪو ۾ آيو آهي ۽ اڃا تائين نه ڄاڻيو آهي ته ميٽرو نقشي کي ڪيئن نيويگيٽ ڪجي. Muscovites عام طور تي پنهنجي علائقي کي چڱي طرح ڄاڻن ٿا، ۽ سڄي ماسڪو ۾ اهي ميٽرو نقشو استعمال ڪندي نيويگيٽ ڪري سگهن ٿا. جڏهن توهان پهريون ڀيرو ماسڪو ۾ آيا آهيو، توهان وٽ اها مهارت نه آهي، ۽ توهان صرف مايوس ٿي رهيا آهيو.
DevOps مشوري جي هن لمحي مان گذرڻ جو مشورو ڏئي ٿو ۽ سڀني شعبن کي گڏجي ڪم ڪرڻ لاءِ گڏيل رابطي جو نقشو ٺاهيو.
ٻه عنصر ان ۾ رڪاوٽ آهن.
ڪارپوريٽ مئنيجمينٽ سسٽم جو نتيجو. اهو الڳ hierarchical "کوهه" ۾ ٺهيل آهي. مثال طور، ڪي پي آئيز ڪمپنيون آهن جيڪي هن سسٽم کي سپورٽ ڪن ٿيون. ٻئي طرف، ڪنهن ماڻهوءَ جو دماغ، جنهن کي پنهنجي مهارت جي حدن کان ٻاهر وڃڻ ۽ سڄي نظام کي هلائڻ ۾ ڏکيائي محسوس ٿئي ٿي. اهو صرف اڻ وڻندڙ آهي. تصور ڪريو ته توهان بئنڪاڪ ايئرپورٽ تي آهيو - توهان کي جلدي پنهنجو رستو نه ملندو. DevOps پڻ نيويگيٽ ڪرڻ ڏکيو آهي، ۽ اهو ئي سبب آهي ته ماڻهو چون ٿا ته توهان کي اتي وڃڻ لاء هڪ گائيڊ ڳولڻ جي ضرورت آهي.
پر سڀ کان اهم ڳالهه اها آهي ته ”ڪوهه“ جو مسئلو هڪ انجنيئر لاءِ جيڪو DevOps جي جذبي سان متاثر آهي، جنهن Fowler ۽ ٻين ڪتابن جو هڪ مجموعو پڙهيو آهي، ان جو اظهار هن حقيقت ۾ ڪيو ويو آهي ته. "کوهه" توهان کي "واضح" شيون ڪرڻ جي اجازت نه ڏيندا آهن. اسين اڪثر ماسڪو DevOps کان پوءِ گڏ ٿيندا آهيون، هڪ ٻئي سان ڳالهايو، ۽ ماڻهو شڪايت ڪندا آهيون:
- اسان صرف CI شروع ڪرڻ چاهيون ٿا، پر اهو ظاهر ٿيو ته انتظاميا کي ان جي ضرورت ناهي.
ائين ئي ٿئي ٿو ڇاڪاڻ ته CI и مسلسل پهچائڻ جو عمل ڪيترن ئي امتحانن جي سرحد تي آهن. بس تنظيمي سطح تي ”ڪوهه“ جي مسئلي تي قابو پائڻ کان سواءِ، توهان اڳتي وڌڻ جي قابل نه هوندا، چاهي توهان ڇا ڪيو ۽ ڪيترو به اداس ڇو نه هجي.
ڪمپني ۾ پروسيس ۾ هر حصو وٺندڙ: پس منظر ۽ فرنٽ اينڊ ڊولپرز، ٽيسٽنگ، ڊي بي اي، آپريشن، نيٽ ورڪ، پنهنجي هدايت ۾ کڄي ٿو، ۽ مئنيجر کانسواءِ ڪنهن وٽ به عام نقشو ناهي، جيڪو ڪنهن نه ڪنهن طريقي سان انهن کي مانيٽر ڪري ٿو ۽ انهن کي ”ورهائي“ استعمال ڪندي منظم ڪري ٿو. ۽ فتح" جو طريقو.
ماڻهو ڪجهه ستارن يا پرچمن لاءِ وڙهندا رهيا آهن، هر ڪو پنهنجي ماهر جي کوٽائي ڪري رهيو آهي.
نتيجي طور، جڏهن انهن سڀني ڳالهين کي پاڻ ۾ ڳنڍڻ ۽ هڪ گڏيل پائيپ لائين ٺاهڻ جو ڪم اچي ٿو، ۽ ستارن ۽ جھنڊن لاءِ وڙهڻ جي ڪا به ضرورت نه رهي آهي، تڏهن سوال اهو ٿو پيدا ٿئي ته آخر ڇا ڪجي؟ اسان کي ڪنهن به طرح هڪ معاهدو ڪرڻ جي ضرورت آهي، پر ڪنهن به اسان کي اسڪول ۾ اهو ڪيئن نه سيکاريو. اسان کي اسڪول کان وٺي سيکاريو ويو آهي: اٺين گريڊ - واهه! - ستين درجي جي مقابلي ۾! هتي به ائين ئي آهي.
ڇا اهو توهان جي ڪمپني ۾ ساڳيو آهي؟
ھن کي جانچڻ لاءِ، توھان پنھنجو پاڻ کان ھيٺ ڏنل سوال پڇي سگھو ٿا.
ڇا ٽيمون عام اوزار استعمال ڪندا آھن ۽ انھن عام اوزارن ۾ تبديلين ۾ حصو وٺندا آھن؟
ڪيتريون ئي ٽيمون ٻيهر منظم ڪن ٿيون- ڪجهه ماهر هڪ ٽيم مان ٻي ٽيم ڏانهن منتقل ڪن ٿا؟ اهو هڪ DevOps ماحول ۾ آهي ته اهو عام ٿي وڃي ٿو، ڇاڪاڻ ته ڪڏهن ڪڏهن هڪ ماڻهو صرف سمجهي نه ٿو سگهي ته ماهر جو ٻيو علائقو ڇا ڪري رهيو آهي. هو ٻئي ڊپارٽمينٽ ۾ وڃي ٿو، اتي ٻن هفتن تائين ڪم ڪري ٿو ته جيئن پاڻ لاءِ هن ڊپارٽمينٽ سان واقفيت ۽ رابطي جو نقشو ٺاهي.
ڇا اهو ممڪن آهي ته هڪ تبديلي ڪميٽي ٺاهي ۽ شيون تبديل ڪن؟ يا ان لاءِ اعليٰ انتظام ۽ هدايت جي مضبوط هٿ جي ضرورت آهي؟ مون تازو ئي Facebook تي لکيو آهي ته ڪيئن هڪ ننڍڙي سڃاتل بئنڪ آرڊر ذريعي اوزارن کي لاڳو ڪري رهي آهي: اسان هڪ آرڊر لکون ٿا، اسان ان کي هڪ سال تائين لاڳو ڪريون ٿا، ۽ ڏسو ته ڇا ٿئي ٿو. اهو، يقينا، ڊگهو ۽ اداس آهي.
مينيجرز لاءِ ڪمپني جي ڪاميابين تي غور ڪرڻ کان سواءِ ذاتي ڪاميابيون حاصل ڪرڻ ڪيترو اهم آهي؟
جيڪڏھن توھان انھن سوالن جا جواب پاڻ لاءِ ڏيو، اھو واضح ٿي ويندو ته ڇا توھان وٽ توھان جي ڪمپني ۾ ھڪڙو مسئلو آھي.
بنيادي ڍانچي جي طور تي ڪوڊ
هن مسئلي کي منظور ٿيڻ کان پوء، پهريون اهم مشق، جنهن کان سواء DevOps ۾ اڳتي وڌڻ ڏکيو آهي، آهي بنيادي ڍانچي جي طور تي ڪوڊ.
گهڻو ڪري، بنيادي ڍانچي کي ڪوڊ طور سمجهيو ويندو آهي جيئن ته:
- اچو ته بش ۾ هر شي کي خودڪار ڪريون، پاڻ کي اسڪرپٽ سان ڍڪيو ته جيئن منتظمين کي گهٽ دستي ڪم هجي!
پر اهو سچ ناهي.
بنيادي ڍانچي جي طور تي ڪوڊ جو مطلب آهي ته توهان بيان ڪريو IT سسٽم جنهن سان توهان ڪم ڪيو ٿا ڪوڊ جي صورت ۾ ان جي حالت کي مسلسل سمجهڻ لاءِ.
ٻين ٽيمن سان گڏ، توهان ڪوڊ جي صورت ۾ هڪ نقشو ٺاهيو جنهن کي هرڪو سمجهي سگهي ٿو ۽ نيويگيٽ ڪري سگهي ٿو. اهو مسئلو ناهي ته اهو ڇا ڪيو ويو آهي - شيف، جوابي، لوڻ، يا ڪبرنيٽس ۾ YAML فائلون استعمال ڪندي - ڪو به فرق ناهي.
ڪانفرنس ۾، 2GIS جي هڪ ساٿي ٻڌايو ته ڪيئن انهن ڪبرنيٽس لاءِ پنهنجو اندروني شيءِ ٺاهيو، جيڪو انفرادي نظام جي جوڙجڪ کي بيان ڪري ٿو. 500 سسٽم کي بيان ڪرڻ لاء، انهن کي هڪ الڳ اوزار جي ضرورت آهي جيڪا هي وضاحت ٺاهي ٿي. جڏهن هي بيان آهي، هرڪو هڪ ٻئي سان چيڪ ڪري سگهي ٿو، تبديلين جي نگراني ڪري ٿو، ان کي ڪيئن تبديل ڪرڻ ۽ ان کي بهتر ڪرڻ، ڇا غائب آهي.
متفق، انفرادي بش اسڪرپٽ عام طور تي هي سمجھ مهيا نه ڪندا آهن. هڪ ڪمپنيءَ ۾ جتي مون ڪم ڪيو، اتي ”صرف لکو“ اسڪرپٽ جو نالو به هو - جڏهن ته اسڪرپٽ لکيو وڃي ٿو، پر هاڻي ان کي پڙهڻ ممڪن ناهي. مان سمجهان ٿو ته اهو توهان کي پڻ واقف آهي.
انفراسٽرڪچر جيئن ته ڪوڊ آهي ڪوڊ جيڪو بنيادي ڍانچي جي موجوده حالت کي بيان ڪري ٿو. ڪيتريون ئي پراڊڪٽ، انفراسٽرڪچر، ۽ سروس ٽيمون گڏجي هن ڪوڊ تي ڪم ڪن ٿيون، ۽ سڀ کان اهم، انهن سڀني کي اهو سمجهڻ جي ضرورت آهي ته هي ڪوڊ اصل ۾ ڪيئن ڪم ڪري ٿو.
ڪوڊ برقرار رکيو ويو آهي بهترين ڪوڊ جي عملن جي مطابقگڏيل ترقي، ڪوڊ جو جائزو، XP-پروگرامنگ، ٽيسٽنگ، پل درخواستون، سي آءِ ڪوڊ انفراسٽرڪچر لاءِ - هي سڀ موزون آهي ۽ استعمال ڪري سگهجي ٿو.
ڪوڊ سڀني انجنيئرن لاءِ عام ٻولي بڻجي وڃي ٿو.
ڪوڊ ۾ انفراسٽرڪچر تبديل ڪرڻ گهڻو وقت نه وٺندو آهي. ها، انفراسٽرڪچر ڪوڊ ۾ ٽيڪنيڪل قرض پڻ ٿي سگهي ٿو. عام طور تي ٽيمون ان سان اڌ سال پوءِ سامهون اينديون آهن جڏهن اهي ”انفراسٽرڪچر ايز ڪوڊ“ تي عمل ڪرڻ شروع ڪنديون آهن ”انفراسٽرڪچر ايز ڪوڊ“ لکت جي هڪ گروپ جي صورت ۾ يا جوابي طور تي، جنهن کي هو اسپگيٽي ڪوڊ وانگر لکندا آهن، ۽ اهي بش اسڪرپٽ کي به ملائي ڇڏيندا آهن!
اهم: جيڪڏهن توهان اڃا تائين هي سامان نه آزمايو آهي، ياد رکو جواب ڏيڻ وارو نه آهي! دستاويز کي احتياط سان پڙهو، پڙهو ته اهي ان بابت ڇا لکندا آهن.
انفراسٽرڪچر ڪوڊ جي طور تي انفراسٽرڪچر ڪوڊ کي الڳ الڳ تہن ۾ الڳ ڪرڻ آهي.
اسان جي ڪمپني ۾، اسان 3 بنيادي تہن ۾ فرق ڪريون ٿا، جيڪي بلڪل صاف ۽ سادي آھن، پر انھن مان وڌيڪ ٿي سگھي ٿو. توهان پنهنجي انفراسٽرڪچر ڪوڊ کي ڏسي سگهو ٿا ۽ ٻڌائي سگهو ٿا ته توهان وٽ اها حالت آهي يا نه. جيڪڏهن ڪو به تہه نمايان نه ڪيو ويو آهي، ته پوء توهان کي ڪجهه وقت وٺڻ جي ضرورت آهي ۽ ٿورڙي ريڪٽر ڪرڻ جي ضرورت آهي.
بنيادي پرت - هي ڪيئن او ايس، بيڪ اپ ۽ ٻيون هيٺين سطح جون شيون ترتيب ڏنل آهن، مثال طور، ڪبرنيٽس کي بنيادي سطح تي ڪيئن لڳايو ويو آهي.
خدمت جي سطح - اھي خدمتون آھن جيڪي توھان ڊولپر کي مهيا ڪندا آھيو: خدمت جي طور تي لاگنگ، ھڪڙي خدمت جي طور تي نگراني، ھڪڙي خدمت جي طور تي ڊيٽابيس، ھڪڙي خدمت جي طور تي بيلنس، ھڪڙي خدمت جي طور تي قطار، ھڪڙي خدمت جي طور تي مسلسل پهچائڻ - خدمتن جو ھڪڙو گروپ جيڪو انفرادي ٽيمون ترقي لاء مهيا ڪري سگهو ٿا. اهو سڀ ڪجهه توهان جي تشڪيل مينيجمينٽ سسٽم ۾ الڳ الڳ ماڊلز ۾ بيان ڪرڻ جي ضرورت آهي.
پرت جتي ايپليڪيشنون ڪيون وينديون آهن ۽ بيان ڪري ٿو ته اهي پوئين ٻن تہن جي چوٽي تي ڪيئن ظاهر ٿيندا.
ڪنٽرول سوال
ڇا توهان جي ڪمپني وٽ هڪ عام انفراسٽرڪچر مخزن آهي؟ ڇا توهان پنهنجي زيربناء ۾ ٽيڪنيڪل قرض جو انتظام ڪري رهيا آهيو؟ ڇا توهان بنيادي ڍانچي جي ذخيري ۾ ترقياتي طريقا استعمال ڪندا آهيو؟ ڇا توهان جو انفراسٹرڪچر تہن ۾ سلائي ڇڏيو آهي؟ توھان چيڪ ڪري سگھو ٿا Base-service-APP ڊراگرام. تبديلي ڪرڻ ڪيترو ڏکيو آهي؟
جيڪڏهن توهان تجربو ڪيو آهي ته اهو هڪ ڏينهن ۽ اڌ ۾ تبديل ڪرڻ ۾ ورتو، ان جو مطلب اهو آهي ته توهان وٽ ٽيڪنيڪل قرض آهي ۽ ان سان ڪم ڪرڻ جي ضرورت آهي. توهان صرف توهان جي انفراسٽرڪچر ڪوڊ ۾ هڪ ٽيڪنيڪل قرض ريڪ تي ڌڪيو آهي. مون کي ڪيتريون ئي اهڙيون ڪهاڻيون ياد آهن جڏهن، ڪجهه سي سي ٽي ايل کي تبديل ڪرڻ لاءِ، توهان کي انفراسٽرڪچر ڪوڊ جو اڌ ٻيهر لکڻو پوندو، ڇاڪاڻ ته تخليقيت ۽ هر شيءِ کي خودڪار ڪرڻ جي خواهش ان حقيقت جو سبب بڻي آهي ته هر شيءِ هر هنڌ خراب ٿي وئي آهي، سڀئي هٿ هٽايا ويا آهن، ۽ اهو refactor ڪرڻ ضروري آهي.
مسلسل پهچائڻ
اچو ته ڊيبٽ جو ڪريڊٽ سان مقابلو ڪريون. پهرين اچي ٿو انفراسٽرڪچر جو تفصيل، جيڪو ڪافي بنيادي ٿي سگهي ٿو. توهان کي هر شي کي تفصيل سان بيان ڪرڻ جي ضرورت ناهي، پر ڪجهه بنيادي وضاحت گهربل آهي تنهنڪري توهان ان سان ڪم ڪري سگهو ٿا. ٻي صورت ۾، اهو واضح ناهي ته اڳتي هلي مسلسل پهچائڻ سان ڇا ڪجي. اهي سڀئي طريقا هڪ ئي وقت ظاهر ٿيندا آهن جڏهن توهان DevOps تي ايندا آهيو، پر اهو سمجهڻ شروع ٿئي ٿو ته توهان وٽ ڇا آهي ۽ ان کي ڪيئن منظم ڪجي. اهو بنيادي طور تي بنيادي طور تي ڪوڊ جي طور تي بنيادي طور تي عمل آهي.
هڪ دفعو اهو واضح ٿي وڃي ٿو ته توهان وٽ آهي ۽ ان کي ڪيئن منظم ڪجي، توهان اهو سمجهڻ شروع ڪيو ته ڊولپر ڪوڊ کي جلدي جلدي پيداوار ڏانهن ڪيئن موڪليو. منهنجو مطلب آهي ڊولپر سان گڏ - اسان کي "ڪوهه" جي مسئلي جي باري ۾ ياد آهي، اهو آهي، اهو انفرادي ماڻهو نه آهي جيڪي هن سان گڏ ايندا آهن، پر هڪ ٽيم.
جڏهن اسان سان گڏ آهيون وانيا Evtukhovich پهريون ڪتاب ڏٺو جيز عاجز ۽ ليکڪن جا گروپ "مسلسل پهچائڻ"، جيڪو 2009 ۾ جاري ڪيو ويو، اسان هڪ ڊگهي وقت تائين سوچيو ته ڪيئن ان جي عنوان کي روسي ۾ ترجمو ڪيو وڃي. اهي ان کي ترجمو ڪرڻ چاهيندا هئا "مسلسل پهچائڻ"، پر، بدقسمتي سان، اهو ترجمو ڪيو ويو "مسلسل پهچائڻ". مون کي لڳي ٿو ته اسان جي نالي ۾ ڪجهه روسي آهي، دٻاء سان.
مسلسل پهچائڻ جو مطلب
ڪوڊ جيڪو پراڊڪٽ جي مخزن ۾ آهي هميشه پيداوار لاءِ ڊائون لوڊ ڪري سگهجي ٿو. هو شايد مايوس نه ٿئي، پر هو هميشه ان لاءِ تيار آهي. انهي جي مطابق، توهان هميشه پنهنجي tailbone هيٺ ڪجهه پريشاني جي سخت وضاحت سان ڪوڊ لکندا آهيو. اهو اڪثر ظاهر ٿئي ٿو جڏهن توهان رول آئوٽ انفراسٽرڪچر ڪوڊ. ڪجهه پريشاني جو اهو احساس موجود هجڻ گهرجي - اهو دماغي عمل کي متحرڪ ڪري ٿو جيڪو توهان کي ڪوڊ لکڻ جي اجازت ڏئي ٿو ٿورو مختلف. اهو ترقي جي اندر اندر ضابطن ۾ رڪارڊ ڪيو وڃي.
مسلسل پهچائڻ لاءِ، توهان کي هڪ آرٽيڪل فارميٽ جي ضرورت آهي جيڪا هڪ انفراسٽرڪچر پليٽ فارم تي هلندي آهي. جيڪڏهن توهان هڪ انفراسٽرڪچر پليٽ فارم تي مختلف فارميٽ جي ”زندگيءَ جي بربادي“ کي اُڇليو ٿا، ته پوءِ اهو متحد ٿي وڃي ٿو، ان کي برقرار رکڻ مشڪل آهي، ۽ ٽيڪنيڪل قرض جو مسئلو پيدا ٿئي ٿو. آرٽيڪل جي شڪل کي ترتيب ڏيڻ جي ضرورت آهي - اهو پڻ هڪ اجتماعي ڪم آهي: اسان سڀني کي گڏ ٿيڻ جي ضرورت آهي، پنهنجي دماغ کي ڇڪڻ ۽ هن فارميٽ سان گڏ اچو.
آرٽيڪل لاڳيتو بهتر ٿي رهيو آهي ۽ پيداوار جي ماحول کي ترتيب ڏيڻ لاءِ تبديليون اچي رهيون آهن جيئن اهو ترسيل پائپ لائن ذريعي هلندو آهي. جڏهن ڪو نمونو پائيپ لائين سان گڏ هلندو آهي، اهو مسلسل ان لاءِ ڪجهه تڪليف ڏيندڙ شين کي منهن ڏيندو آهي، جيڪي توهان جي پيداوار جي مقابلي ۾ ٺاهيل آرٽيڪل سان ملندڙ جلندڙ هونديون آهن. جيڪڏهن ڪلاسيڪل ڊولپمينٽ ۾ اهو هڪ سسٽم ايڊمنسٽريٽر طرفان ڪيو ويندو آهي جيڪو رول آئوٽ ڪري ٿو، پوءِ DevOps جي عمل ۾ اهو هر وقت ٿئي ٿو: هتي انهن ان کي ڪجهه تجربن سان آزمايو، هتي انهن ان کي ڪبرنيٽس ڪلستر ۾ اڇلايو، جيڪو گهٽ يا گهٽ ساڳيو آهي. پيداوار ڏانهن، پوء اوچتو انهن لوڊ جاچ شروع ڪيو.
اهو ڪجهه حد تائين ياد ڏياريندڙ آهي Pac-Man راند - آرٽيڪل ڪجهه قسم جي ڪهاڻي ذريعي وڃي ٿو. ساڳئي وقت، اهو ڪنٽرول ڪرڻ ضروري آهي ته ڇا ڪوڊ اصل ۾ ڪهاڻي ذريعي وڃي ٿو ۽ ڇا اهو ڪنهن به طرح سان توهان جي پيداوار سان لاڳاپيل آهي. پيداوار کان ڪهاڻيون مسلسل پهچائڻ واري عمل ۾ ڇڪي سگھجن ٿيون: اهو هن طرح هو جڏهن ڪجهه ٿي ويو، هاڻي اچو ته صرف سسٽم جي اندر هن منظر کي پروگرام ڪريو. هر دفعي ڪوڊ به هن منظرنامي مان گذرندو، ۽ توهان کي ايندڙ وقت هن مسئلي کي منهن نه ڏيندو. توهان ان جي باري ۾ گهڻو اڳ سکندا ته اهو توهان جي ڪلائنٽ تائين پهچندو.
مختلف ترتيب ڏيڻ واريون حڪمت عمليون. مثال طور، توهان مختلف ڪلائنٽ تي ڪوڊ کي مختلف طريقي سان جانچڻ لاءِ AB ٽيسٽنگ يا ڪينري ڊيپلائيمينٽ استعمال ڪندا آهيو، معلومات حاصل ڪريو ته ڪوڊ ڪيئن ڪم ڪندو آهي، ۽ ان کان گهڻو اڳ جڏهن اهو 100 ملين صارفين تائين پهچايو ويندو آهي.
"مسلسل طور تي پهچائڻ" هن وانگر ڏسڻ ۾ اچي ٿو.
پهچائڻ وارو عمل Dev, CI, Test, PreProd, Prod ڪو الڳ ماحول نه آهي، اهي مرحلا يا اسٽيشنون آهن جن ۾ فائر پروف رقمون آهن جن جي ذريعي توهان جو نمونو گذري ٿو.
جيڪڏهن توهان وٽ انفراسٽرڪچر ڪوڊ آهي جنهن کي بيان ڪيو ويو آهي بيس سروس APP پوءِ اها مدد ڪري ٿي سڀ اسڪرپٽ نه وساريو, ۽ انهن کي هن نموني لاء ڪوڊ طور لکو، artifact کي فروغ ڏيڻ ۽ ان کي تبديل ڪريو جيئن توهان وڃو.
خود جاچ لاءِ سوال
فيچر جي وضاحت کان وٺي 95 سيڪڙو ڪيسن ۾ پيداوار ۾ ڇڏڻ جو وقت هڪ هفتي کان گهٽ آهي؟ ڇا پائپ لائن جي هر مرحلي تي نموني جي معيار کي بهتر بڻائي ٿو؟ ڇا ڪا ڪهاڻي آهي جنهن مان گذري ٿو؟ ڇا توھان استعمال ڪندا آھيو مختلف ترتيب ڏيڻ واري حڪمت عملي؟
جيڪڏهن سڀئي جواب ها آهن، ته پوء توهان ناقابل يقين حد تائين ٿڌو آهيو! تبصرن ۾ پنهنجا جواب لکو - مان خوش ٿيندس).
Обратная связь
اهو سڀ کان وڌيڪ ڏکيو مشق آهي. DevOpsConf ڪانفرنس ۾، Infobip کان هڪ ساٿي، ان بابت ڳالهائيندي، هن جي لفظن ۾ ٿورو پريشان هو، ڇاڪاڻ ته اهو حقيقت جي باري ۾ هڪ تمام پيچيده مشق آهي ته توهان کي هر شيء جي نگراني ڪرڻ جي ضرورت آهي!
مثال طور، هڪ ڊگهو وقت اڳ، جڏهن مون Qik تي ڪم ڪيو ۽ اسان محسوس ڪيو ته اسان کي هر شيء جي نگراني ڪرڻ جي ضرورت آهي. اسان اهو ڪيو، ۽ اسان وٽ هاڻي زيبڪس ۾ 150 شيون آهن، جيڪي مسلسل نگراني ڪندا آهن. اهو خوفناڪ هو، ٽيڪنيڪل ڊائريڪٽر پنهنجي آڱر کي پنهنجي مندر ڏانهن موڙي ڇڏيو:
- دوست، توهان سرور کي غير واضح شيء سان ڇو ريپ ڪري رهيا آهيو؟
پر پوءِ هڪ واقعو پيش آيو جنهن ظاهر ڪيو ته اها واقعي هڪ تمام سٺي حڪمت عملي آهي.
خدمتن مان هڪ مسلسل حادثو ٿيڻ لڳو. شروعات ۾، اهو حادثو نه ٿيو، جيڪو دلچسپ آهي، ڪوڊ اتي شامل نه ڪيو ويو آهي، ڇاڪاڻ ته اهو هڪ بنيادي بروکر هو، جنهن ۾ عملي طور تي ڪابه ڪاروباري ڪارڪردگي نه هئي - اهو صرف انفرادي خدمتن جي وچ ۾ پيغام موڪلي ٿو. سروس 4 مهينن تائين تبديل نه ڪئي، ۽ اوچتو اهو "سيگمينٽيشن غلطي" جي غلطي سان حادثو ٿيڻ لڳو.
اسان حيران ٿي ويا، زبڪس ۾ اسان جا چارٽ کوليا، ۽ اهو ظاهر ٿيو ته هڪ هفتي ۽ اڌ اڳ، API سروس ۾ درخواستن جو رويو جيڪو هي بروکر استعمال ڪري ٿو تمام گهڻو تبديل ٿي ويو. اڳيون اسان ڏٺو ته هڪ خاص قسم جي پيغام موڪلڻ جي تعدد تبديل ٿي وئي هئي. بعد ۾ اسان کي معلوم ٿيو ته اهي اينڊرائيڊ ڪلائنٽ هئا. اسان پڇيو:
- دوستو، توهان کي هڪ اڌ هفتو اڳ ڇا ٿيو هو؟
جواب ۾، اسان هڪ دلچسپ ڪهاڻي ٻڌو ته ڪيئن انهن UI کي ٻيهر ڊزائين ڪيو هو. اهو ممڪن ناهي ته ڪو به فوري طور تي چوندو ته انهن HTTP لائبريري کي تبديل ڪيو. Android ڪلائنٽ لاء، اهو غسل خاني ۾ صابن کي تبديل ڪرڻ وانگر آهي - اهي صرف ياد نه ڪندا آهن. نتيجي طور، 40 منٽن جي گفتگو کان پوء، اسان کي معلوم ٿيو ته انهن HTTP لائبريري کي تبديل ڪيو آهي، ۽ ان جي ڊفالٽ ٽائيم تبديل ٿي چڪي هئي. انهي جي نتيجي ۾ API سرور تي ٽرئفڪ جي رويي کي تبديل ڪيو ويو، جنهن جي نتيجي ۾ هڪ اهڙي صورتحال پيدا ڪئي جيڪا بروکر جي اندر هڪ نسل پيدا ڪئي، ۽ اهو حادثو شروع ڪيو.
وڏي نگراني کان سواءِ ان کي کولڻ عام طور تي ناممڪن آهي. جيڪڏهن تنظيم اڃا تائين "ڪوهه" جو مسئلو آهي، جڏهن هرڪو هڪ ٻئي تي پئسا اڇلائي، اهو سالن تائين رهي سگهي ٿو. توهان صرف سرور کي ٻيهر شروع ڪيو ڇو ته اهو مسئلو حل ڪرڻ ناممڪن آهي. جڏهن توهان مانيٽر ڪريو، ٽريڪ ڪريو، انهن سڀني واقعن کي ٽريڪ ڪريو جيڪي توهان وٽ آهن، ۽ مانيٽرنگ کي جانچ جي طور تي استعمال ڪريو - ڪوڊ لکو ۽ فوري طور تي اشارو ڪيو ته ان کي مانيٽر ڪيئن ڪجي، پڻ ڪوڊ جي صورت ۾ (اسان وٽ اڳ ۾ ئي بنيادي ڍانچي آهي ڪوڊ)، سڀ ڪجهه واضح ٿي ويندو ته ڪيئن. کجيءَ تي. جيتوڻيڪ اهڙا پيچيده مسئلا آساني سان ٽريڪ ٿيل آهن.
سڀني معلومات گڏ ڪريو ته ڇا ٿئي ٿو آرٽيڪل کي پهچائڻ واري عمل جي هر مرحلي تي - پيداوار ۾ نه.
اپلوڊ ڪريو مانيٽرنگ کي سي آءِ، ۽ ڪجھ بنيادي شيون اتي ئي نظر اينديون. بعد ۾ توهان انهن کي ٽيسٽ، پروڊ پروڊ، ۽ لوڊ جاچ ۾ ڏسندا. سڀني مرحلن تي معلومات گڏ ڪريو، نه رڳو ميٽرڪس، انگ اکر، پر لاگ پڻ: ايپليڪيشن ڪيئن ٺهڪي اچي ٿي، غير معموليات - سڀ ڪجهه گڏ ڪريو.
ٻي صورت ۾ ان کي سمجهڻ ڏکيو ٿيندو. مون اڳ ۾ ئي چيو آهي ته DevOps وڌيڪ پيچيده آهي. هن پيچيدگي کي منهن ڏيڻ لاء، توهان کي عام تجزيي جي ضرورت آهي.
پاڻ سنڀالڻ لاءِ سوال
ڇا توھان جي نگراني ۽ لاگنگ توھان لاءِ ترقي وارو اوزار آھي؟ ڪوڊ لکڻ وقت، ڇا توھان سميت توھان جا ڊولپر، سوچيندا آھن ته ان جي نگراني ڪيئن ڪجي؟
ڇا توهان گراهڪن کان مسئلن بابت ٻڌو ٿا؟ ڇا توهان ڪلائنٽ کي بهتر سمجهي رهيا آهيو مانيٽرنگ ۽ لاگنگ کان؟ ڇا توھان سسٽم کي مانيٽرنگ ۽ لاگنگ کان بھتر سمجھو ٿا؟ ڇا توھان سسٽم کي صرف ان ڪري تبديل ڪيو آھي جو توھان ڏٺو آھي ته سسٽم ۾ رجحان وڌي رھيو آھي ۽ توھان سمجھو ٿا ته ٻين 3 ھفتن ۾ سڀ ڪجھ مري ويندو؟
هڪ دفعو توهان وٽ اهي ٽي حصا آهن، توهان سوچيو ٿا ته توهان جي ڪمپني ۾ ڪهڙي قسم جي انفراسٽرڪچر پليٽ فارم آهي.
انفراسٹرڪچر پليٽ فارم
نقطي اهو ناهي ته اهو مختلف اوزارن جو هڪ سيٽ آهي جيڪو هر ڪمپني وٽ آهي.
هڪ انفراسٽرڪچر پليٽ فارم جو نقطو اهو آهي ته سڀئي ٽيمون اهي اوزار استعمال ڪن ٿيون ۽ انهن کي گڏجي ترقي ڪن ٿيون.
اهو واضح آهي ته اتي الڳ الڳ ٽيمون آهن جيڪي انفراسٽرڪچر پليٽ فارم جي انفرادي ٽڪرن جي ترقي لاء ذميوار آهن. پر ساڳئي وقت، هر انجنيئر کي انفراسٽرڪچر پليٽ فارم جي ترقي، ڪارڪردگي، ۽ واڌاري جي ذميواري آهي. اندروني سطح تي اهو هڪ عام اوزار بڻجي ويندو آهي.
سڀئي ٽيمون انفراسٽرڪچر پليٽ فارم کي ترقي ڪن ٿيون ۽ ان کي احتياط سان پنهنجو IDE سمجھن ٿيون. توهان جي IDE ۾ توهان مختلف پلگ ان انسٽال ڪريو ٿا ته هر شي کي سٺي ۽ تيز ڪرڻ لاءِ، ۽ هاٽ ڪيز کي ترتيب ڏيو. جڏهن توهان Sublime، Atom يا Visual Studio ڪوڊ کوليو ٿا، ڪوڊ ۾ غلطيون اچي رهيون آهن ۽ توهان محسوس ڪيو ته اهو هرگز ڪم ڪرڻ ناممڪن آهي، توهان فوري طور تي اداس محسوس ڪندا آهيو ۽ توهان پنهنجي IDE کي درست ڪرڻ لاءِ ڊوڙندا آهيو.
توهان جي انفراسٽرڪچر پليٽ فارم کي ساڳئي طريقي سان علاج ڪريو. جيڪڏهن توهان سمجھو ٿا ته ان ۾ ڪجهه غلط آهي، هڪ درخواست ڇڏي ڏيو جيڪڏهن توهان ان کي پاڻ درست نٿا ڪري سگهو. جيڪڏهن ڪا شيءِ سادو آهي، ته ان کي پاڻ ايڊٽ ڪريو، هڪ ڇڪڻ جي درخواست موڪليو، ماڻهو ان تي غور ڪندا ۽ ان کي شامل ڪندا. هي ڊولپر جي سر ۾ انجنيئرنگ اوزار لاء ٿورو مختلف طريقو آهي.
انفراسٽرڪچر پليٽ فارم معيار ۾ مسلسل بهتري سان ترقي کان ڪلائنٽ ڏانهن آرٽيڪل جي منتقلي کي يقيني بڻائي ٿو. IP ڪهاڻين جي هڪ سيٽ سان پروگرام ڪيو ويو آهي جيڪا پيداوار ۾ ڪوڊ سان ٿئي ٿي. ترقيءَ جي سالن ۾، ڪيتريون ئي ڪهاڻيون آهن، انهن مان ڪي منفرد آهن ۽ صرف توهان سان واسطو رکن ٿيون - اهي گوگل نه ٿي سگهن ٿيون.
هن موقعي تي، انفراسٹرڪچر پليٽ فارم توهان جي مقابلي جو فائدو بڻجي ٿو، ڇاڪاڻ ته ان ۾ ڪجهه ٺهيل آهي جيڪا مقابلي جي اوزار ۾ نه آهي. توهان جو IP جيترو اونهو هوندو، اوترو وڌيڪ توهان جي مقابلي جو فائدو وقت کان مارڪيٽ جي لحاظ کان. هتي ظاهر ٿئي ٿو وڪرو ڪندڙ تالا مسئلو: توهان ڪنهن ٻئي جو پليٽ فارم وٺي سگهو ٿا، پر ڪنهن ٻئي جي تجربي کي استعمال ڪندي، توهان سمجهي نه سگهندا ته اهو توهان سان ڪيترو لاڳاپيل آهي. ها، هر ڪمپني نه ٺاهي سگهي ٿي پليٽ فارم وانگر Amazon. هي هڪ مشڪل لائن آهي جتي ڪمپني جو تجربو مارڪيٽ ۾ ان جي پوزيشن سان لاڳاپيل آهي، ۽ توهان اتي وينڊر لاڪ استعمال نٿا ڪري سگهو. اهو پڻ سوچڻ ضروري آهي.
هي منصوبو
هي هڪ انفراسٽرڪچر پليٽ فارم جو هڪ بنيادي خاڪو آهي جيڪو توهان کي DevOps ڪمپني ۾ سڀني عملن ۽ عملن کي ترتيب ڏيڻ ۾ مدد ڪندو.
اچو ته ڏسو ته اهو ڇا تي مشتمل آهي.
ريسورس آرڪيسٽريشن سسٽم، جيڪو مهيا ڪري ٿو سي پي يو، ميموري، ڊسڪ کي ايپليڪيشنون ۽ ٻيون خدمتون. ان جي مٿان - گھٽ سطح جون خدمتون: مانيٽرنگ، لاگنگ، CI/CD انجڻ، آرٽيڪل اسٽوريج، انفراسٽرڪچر جيئن سسٽم ڪوڊ.
اعلي سطحي خدمتون: ڊيٽابيس هڪ خدمت جي طور تي، قطار هڪ خدمت جي طور تي، هڪ خدمت جي طور تي لوڊ بيلنس، هڪ خدمت جي طور تي تصوير جي ماپ، خدمت جي طور تي بگ ڊيٽا فيڪٽري. ان جي مٿان - پائپ لائن جيڪا توهان جي ڪلائنٽ کي مسلسل تبديل ٿيل ڪوڊ فراهم ڪري ٿي.
توهان کي معلومات ملي ٿي ته توهان جو سافٽ ويئر ڪلائنٽ لاءِ ڪيئن ڪم ڪري ٿو، ان کي تبديل ڪريو، هي ڪوڊ ٻيهر فراهم ڪريو، معلومات حاصل ڪريو - ۽ پوءِ توهان مسلسل انفراسٽرڪچر پليٽ فارم ۽ توهان جي سافٽ ويئر ٻنهي کي ترقي ڪري رهيا آهيو.
ڊراگرام ۾، ترسيل پائپ لائن ڪيترن ئي مرحلن تي مشتمل آهي. پر هي هڪ اسڪيمي ڊراگرام آهي جيڪو مثال طور ڏنو ويو آهي - ان کي هڪ هڪ ڪري ورجائڻ جي ضرورت ناهي. مرحلا خدمتن سان رابطو ڪن ٿا ڄڻ ته اهي خدمتون آهن- پليٽ فارم جي هر اينٽ پنهنجي ڪهاڻي رکي ٿي: ڪئين وسيلا مختص ڪيا ويا، ايپليڪيشن ڪيئن شروع ڪئي وئي، وسيلن سان ڪم ڪيو، مانيٽر ڪيو ويو، ۽ تبديليون.
اهو سمجهڻ ضروري آهي ته پليٽ فارم جو هر حصو هڪ ڪهاڻي رکي ٿو، ۽ پنهنجو پاڻ کان پڇو ته هي سر ڪهڙي ڪهاڻي آهي، ٿي سگهي ٿو ته ان کي اڇلايو وڃي ۽ ٽئين پارٽي جي خدمت سان تبديل ڪيو وڃي. مثال طور، ڇا ان کي نصب ڪرڻ ممڪن آهي Okmeter بدران هڪ اينٽ؟ ٿي سگهي ٿو ته ماڻهو اڳ ۾ ئي هن صلاحيت کي اسان جي ڀيٽ ۾ تمام گهڻو ترقي ڪري چڪو آهي. پر شايد نه - شايد اسان وٽ منفرد صلاحيت آهي، اسان کي Prometheus انسٽال ڪرڻ ۽ ان کي اڳتي وڌائڻ جي ضرورت آهي.
پليٽ فارم جي ٺهڻ
هي هڪ پيچيده رابطي وارو عمل آهي. جڏهن توهان وٽ بنيادي طريقا آهن، توهان مختلف انجنيئرن ۽ ماهرن جي وچ ۾ رابطو شروع ڪندا آهن جيڪي گهرجون ۽ معيار ٺاهيندا آهن، ۽ مسلسل انهن کي مختلف اوزارن ۽ طريقن ۾ تبديل ڪندا آهن. ڪلچر جيڪو اسان وٽ آهي DevOps ۾ هتي اهم آهي.
ثقافت سان هر شيء بلڪل سادو آهي - اهو تعاون ۽ رابطي جي باري ۾ آهياهو آهي، هڪ ٻئي سان گڏ هڪ عام فيلڊ ۾ ڪم ڪرڻ جي خواهش، هڪ اوزار گڏ ڪرڻ جي خواهش. هتي ڪو به راڪيٽ سائنس ناهي - هر شيء بلڪل سادي آهي، عام. مثال طور، اسان سڀ داخلا ۾ رهون ٿا ۽ ان کي صاف رکون ٿا - ثقافت جي اهڙي سطح.
توهان وٽ ڇاآهي؟
ٻيهر، سوال توهان پاڻ کان پڇي سگهو ٿا.
ڇا انفراسٹرڪچر پليٽ فارم وقف آهي؟ ان جي ترقي جو ذميوار ڪير آهي؟ ڇا توھان سمجھو ٿا پنھنجي انفراسٽرڪچر پليٽ فارم جي مقابلي واري فائدن کي؟
توهان کي مسلسل پاڻ کان انهن سوالن کان پڇڻ جي ضرورت آهي. جيڪڏهن ڪا شيءِ ٽئين پارٽي جي خدمتن ڏانهن منتقل ٿي سگهي ٿي، ان کي منتقل ڪرڻ گهرجي؛ جيڪڏهن ٽئين پارٽي جي خدمت توهان جي حرڪت کي بلاڪ ڪرڻ شروع ڪري ٿي، ته پوءِ توهان کي پنهنجي اندر هڪ نظام ٺاهڻ جي ضرورت آهي.
تنهن ڪري، DevOps ...
... هي هڪ پيچيده نظام آهي، اهو هجڻ گهرجي:
- ڊجيٽل پيداوار.
- ڪاروباري ماڊل جيڪي هن ڊجيٽل پيداوار کي ترقي ڪن ٿا.
- پراڊڪٽ ٽيمون جيڪي ڪوڊ لکن ٿيون.
- مسلسل پهچائڻ جا طريقا.
- پليٽ فارم هڪ خدمت جي طور تي.
- هڪ خدمت جي طور تي انفراسٽرڪچر.
- بنيادي ڍانچي جي طور تي ڪوڊ.
- اعتماد کي برقرار رکڻ لاءِ الڳ طريقا، DevOps ۾ ٺهيل.
- هڪ راءِ جو مشق جيڪو اهو سڀ بيان ڪري ٿو.
توھان ھي ڊاگرام استعمال ڪري سگھو ٿا، ان ۾ نمايان ڪري سگھو ٿا جيڪي توھان وٽ اڳ ۾ ئي آھي توھان جي ڪمپني ۾ ڪجھ فارم ۾: ڇا اھو ترقي ڪئي آھي يا اڃا تائين ترقي ڪرڻ جي ضرورت آھي.
اهو ڪجهه هفتن ۾ ختم ٿي ويندو . RIT ++ جي حصي جي طور تي. ڪانفرنس ۾ اچو، جتي توهان مسلسل ترسيل، بنيادي ڍانچي جي طور تي ڪوڊ ۽ DevOps تبديلي بابت ڪيتريون ئي سٺيون رپورٽون ڳوليندا. ، آخري قيمت جي آخري تاريخ مئي 20 آهي
جو ذريعو: www.habr.com