Banki.ru پورٽل جي آپريشنز ڊائريڪٽر اينڊريو نيڪولسڪي گذريل سال جي ڪانفرنس ۾ ڳالهايو يتيم خدمتن بابت: انفراسٽرڪچر ۾ يتيم کي ڪيئن سڃاڻڻ، ڇو يتيم خدمتون خراب آهن، انهن سان ڇا ڪجي، ۽ ڇا ڪجي جيڪڏهن ڪجهه به مدد نه ڪري.
هيٺ ڏنل ڪٽ جي رپورٽ جو متن نسخو آهي.
هيلو ساٿيو! منهنجو نالو اينڊريو آهي، مان Banki.ru تي آپريشن ڪريان ٿو.
اسان وٽ وڏيون خدمتون آهن، اهي اهڙيون هڪجهڙائي واريون خدمتون آهن، وڌيڪ طبقاتي معنى ۾ خدمتون آهن، ۽ تمام ننڍيون آهن. مزدور هارين جي اصطلاح ۾ مان چوان ٿو ته جيڪڏهن ڪا خدمت سادو ۽ ننڍي آهي ته پوءِ اها مائڪرو آهي، ۽ جيڪڏهن اها تمام سادي ۽ ننڍڙي نه آهي ته پوءِ اها صرف هڪ خدمت آهي.
خدمتن جا فائدا
مان جلدي وڃندس خدمتن جي فائدن تي.
پهرين اسڪيلنگ آهي. توھان جلدي ڪري سگھوٿا خدمت تي ڪجھ ڪم ۽ پيداوار شروع ڪريو. توھان کي ٽرئفڪ ملي آھي، توھان خدمت کي ڪلون ڪيو آھي. توهان وٽ وڌيڪ ٽرئفڪ آهي، توهان ان کي ڪلون ڪيو آهي ۽ ان سان گڏ رهندا آهيو. اهو هڪ سٺو بونس آهي، ۽، اصول ۾، جڏهن اسان شروع ڪيو، اهو اسان لاء سڀ کان اهم شيء سمجهيو ويو، ڇو ته اسان اهو سڀ ڪجهه ڪري رهيا آهيون.
ٻيو، الڳ ٿيل ترقي، جڏهن توهان وٽ ڪيترائي ترقياتي ٽيمون آهن، هر ٽيم ۾ ڪيترائي مختلف ڊولپر، ۽ هر ٽيم پنهنجي خدمت ٺاهي ٿي.
ٽيمن سان گڏ هڪ nuance آهي. ڊولپر مختلف آهن. ۽ اهڙا آهن، مثال طور، . مون اهو پهريون ڀيرو ميڪسم ڊوروفيف سان ڏٺو. ڪڏهن ڪڏهن برفاني ماڻهو ڪجهه ٽيمن تي آهن ۽ ٻين تي نه. هي ٺاهي ٿو مختلف خدمتن کي سڄي ڪمپني ۾ استعمال ٿيل ٿورڙو اڻ برابر.
تصوير ڏسو: هي هڪ سٺو ڊولپر آهي، هن وٽ وڏا هٿ آهن، هو گهڻو ڪجهه ڪري سگهي ٿو. بنيادي مسئلو اهو آهي ته اهي هٿ ڪٿان اچن ٿا.
خدمتون مختلف پروگرامنگ ٻولين کي استعمال ڪرڻ ممڪن بڻائين ٿيون جيڪي مختلف ڪمن لاءِ وڌيڪ موزون آهن. ڪجھ خدمت گو ۾ آھي، ڪجھ ارلنگ ۾ آھي، ڪجھ روبي ۾ آھي، ڪجھ پي ايڇ ۾ آھي، ڪجھ پيٿون ۾ آھي. عام طور تي، توهان تمام وڏي پيماني تي وڌائي سگهو ٿا. هتي پڻ nuances آهن.
خدمت تي مبني فن تعمير بنيادي طور تي ڊيوپس بابت آهي. اھو آھي، جيڪڏھن توھان وٽ آٽوميشن نه آھي، اتي ڪو به ٺاھڻ وارو عمل نه آھي، جيڪڏھن توھان ان کي دستي طور تي ترتيب ڏيو، توھان جون ترتيبون تبديل ٿي سگھن ٿيون خدمت مثال کان مثال، ۽ توھان کي اتي وڃڻو پوندو ڪجھھ ڪرڻ لاء، پوء توھان دوزخ ۾ آھيو.
مثال طور، توهان وٽ 20 خدمتون آهن ۽ توهان کي هٿ سان ترتيب ڏيڻ جي ضرورت آهي، توهان وٽ 20 ڪنسولز آهن، ۽ توهان هڪ ئي وقت ننجا وانگر ”انٽر“ کي دٻايو. اهو تمام سٺو ناهي.
جيڪڏهن توهان وٽ ٽيسٽنگ کان پوءِ هڪ خدمت آهي (جيڪڏهن اتي جاچ آهي ، يقينا) ۽ توهان کي اڃا تائين ان کي فائل سان ختم ڪرڻ جي ضرورت آهي ته جيئن اهو پيداوار ۾ ڪم ڪري ، مون وٽ توهان لاءِ خراب خبر پڻ آهي.
جيڪڏهن توهان مخصوص Amazon خدمتن تي ڀروسو ڪريو ٿا ۽ روس ۾ ڪم ڪريو ٿا، ته پوءِ ٻه مهينا اڳ توهان وٽ به ”هر شيءِ باهه تي آهي، مان ٺيڪ آهيان، سڀ ڪجهه ٿڌو آهي.
اسان استعمال ڪريون ٿا جوابي ترتيب ڏيڻ لاءِ خودڪار ڪرڻ لاءِ، پپٽ لاءِ ڪنورجينس، بانس کي خودڪار ڪرڻ لاءِ، ۽ ڪنفلوئنس استعمال ڪريون ٿا ڪنهن نه ڪنهن طرح ان کي بيان ڪرڻ لاءِ.
مان ان تي تفصيل سان نه ڳالهائيندس، ڇاڪاڻ ته اها رپورٽ رابطي جي عملن بابت وڌيڪ آهي، ۽ ٽيڪنيڪل عمل جي باري ۾ نه.
مثال طور، اسان کي مسئلا ٿيا آهن جتي سرور تي Puppet روبي 2 سان ڪم ڪري ٿو، پر ڪجهه ايپليڪيشن روبي 1.8 لاءِ لکيل آهي، ۽ اهي گڏجي ڪم نٿا ڪن. اتي ڪجهه غلط ٿئي ٿو. ۽ جڏهن توهان کي هڪ مشين تي روبي جي ڪيترن ئي نسخن کي هلائڻ جي ضرورت آهي، توهان کي عام طور تي مسئلا ٿيڻ شروع ڪيو.
مثال طور، اسان هر ڊولپر کي هڪ پليٽ فارم ڏيون ٿا جنهن تي لڳ ڀڳ هر شيءِ آهي جيڪا اسان وٽ آهي، اهي سڀئي خدمتون جيڪي ترقي ڪري سگهجن ٿيون، ته جيئن هن وٽ هڪ الڳ ماحول هجي، هو ان کي ٽوڙي سگهي ٿو ۽ جيئن چاهي ٿو ٺاهي سگهي.
اهو ٿئي ٿو ته توهان کي ڪجهه خاص طور تي مرتب ڪيل پيڪيج جي ضرورت آهي اتي ڪنهن شيءِ جي مدد سان. اهو ڪافي سخت آهي. مون هڪ رپورٽ ٻڌو جتي ڊاڪر تصوير جو وزن 45 GB آهي. لينڪس ۾، يقينا، اهو آسان آهي، هر شيء اتي ننڍڙو آهي، پر اڃا تائين، ڪافي جاء نه هوندي.
خير، اتي متضاد انحصار آهن، جڏهن پروجيڪٽ جو هڪ ٽڪرو هڪ نسخي جي لائبريري تي منحصر هوندو آهي، منصوبي جو ٻيو ٽڪرو ٻئي نسخي تي منحصر هوندو آهي، ۽ لائبريريون گڏ نه هوندا آهن.
اسان وٽ PHP 5.6 ۾ سائيٽون ۽ خدمتون آهن، اسان انهن تي شرمسار آهيون، پر اسان ڇا ڪري سگهون ٿا؟ هي اسان جي هڪ سائيٽ آهي. PHP 7 تي سائيٽون ۽ خدمتون موجود آهن، انهن مان وڌيڪ آهن، اسان انهن کان شرمسار ناهيون. ۽ هر ڊولپر جو پنهنجو بنياد آهي جتي هو خوشيءَ سان ڏٺو.
جيڪڏهن توهان هڪ ڪمپني ۾ هڪ ٻوليء ۾ لکندا آهيو، پوء ٽي مجازي مشينون في ڊولپر عام آواز آهن. جيڪڏهن توهان وٽ مختلف پروگرامنگ ٻوليون آهن، ته صورتحال خراب ٿي ويندي.
توھان وٽ ھن تي سائيٽون ۽ خدمتون آھن، ھن تي، پوءِ ٻي سائيٽ Go لاءِ، ھڪڙي سائيٽ Ruby لاءِ، ۽ ڪجھ ٻيون Redis پاسي تي. نتيجي طور، هي سڀ مدد لاء هڪ وڏي ميدان ۾ بدلجي ٿو، ۽ هر وقت ان مان ڪجهه ڀڄي سگهي ٿو.
تنهن ڪري، اسان مختلف فريم ورڪ جي استعمال سان پروگرامنگ ٻولي جي فائدن کي تبديل ڪيو، ڇاڪاڻ ته PHP فريم ورڪ بلڪل مختلف آهن، انهن ۾ مختلف صلاحيتون، مختلف برادريون، ۽ مختلف سپورٽ آهن. ۽ توهان هڪ خدمت لکي سگهو ٿا ته جيئن توهان وٽ اڳ ۾ ئي ان لاءِ ڪجهه تيار آهي.
هر خدمت جي پنهنجي ٽيم آهي
اسان جو بنيادي فائدو، جيڪو ڪيترن ئي سالن کان مٿي ڪيو ويو آهي، اهو آهي ته هر خدمت جي پنهنجي ٽيم آهي. اهو هڪ وڏي پروجيڪٽ لاءِ آسان آهي، توهان دستاويزن تي وقت بچائي سگهو ٿا، مينيجر پنهنجي پروجيڪٽ کي چڱيءَ طرح ڄاڻن ٿا.
توھان آساني سان مدد کان ڪم جمع ڪري سگھو ٿا. مثال طور، انشورنس سروس ڀڄي وئي. ۽ فوري طور تي ٽيم جيڪا انشورنس سان معاملو ڪري ٿي ان کي درست ڪرڻ لاءِ وڃي ٿي.
نيون خاصيتون جلدي ٺاهي رهيا آهن، ڇاڪاڻ ته جڏهن توهان وٽ هڪ ايٽمي خدمت آهي، توهان تڪڙو ڪري سگهو ٿا ان ۾ ڪا شيءِ.
۽ جڏھن توھان پنھنجي خدمت کي ٽوڙيو، ۽ اھو ناگزير طور تي ٿئي ٿو، توھان ٻين ماڻھن جي خدمتن کي متاثر نه ڪيو، ۽ ٻين ٽيمن مان ڊولپرز بٽ سان توھان ڏانھن ڊوڙندا نه اچن ۽ چوندا آھن: "اي-اي، ائين نه ڪريو."
هميشه وانگر، اتي nuances آهن. اسان وٽ مستحڪم ٽيمون آهن، مئنيجر ٽيم ۾ شامل آهن. واضح دستاويز موجود آهن، مينيجر هر شيء کي ويجهي نگراني ڪن ٿا. مينيجر سان گڏ هر ٽيم ڪيترن ئي خدمتون آهن، ۽ هڪ خاص نقطو صلاحيت آهي.
جيڪڏهن ٽيمون سچل آهن (اسان ڪڏهن ڪڏهن هن کي استعمال ڪندا آهيون)، اتي هڪ سٺو طريقو آهي جنهن کي "اسٽار نقشو" سڏيو ويندو آهي.
توهان وٽ خدمتن ۽ ماڻهن جي هڪ فهرست آهي. هڪ ستاري جو مطلب آهي ته ماڻهو هن خدمت ۾ هڪ ماهر آهي، هڪ ڪتاب جو مطلب آهي ته ماڻهو هن خدمت جو مطالعو ڪري رهيو آهي. ماڻهوءَ جو ڪم آهي ڪتابي شڪل کي تبديل ڪرڻ لاءِ ستاري. ۽ جيڪڏهن خدمت جي سامهون ڪجهه به نه لکيو ويو آهي، ته پوء مسئلا شروع ٿي ويندا آهن، جن بابت آئون اڳتي هلي ڳالهائيندس.
يتيم جون خدمتون ڪيئن ظاهر ٿيون؟
پهريون مسئلو، توهان جي انفراسٽرڪچر ۾ يتيم خدمت حاصل ڪرڻ جو پهريون طريقو ماڻهن کي باهه ڏيڻ آهي. ڪمن جو جائزو وٺڻ کان پهريان ڪنهن کي ڪڏهن ڪاروبار ملڻ جي آخري تاريخ ملي آهي؟ ڪڏهن ڪڏهن اهو ٿئي ٿو ته آخري وقت تنگ آهن ۽ دستاويز لاء ڪافي وقت نه آهي. "اسان کي خدمت جي پيداوار جي حوالي ڪرڻ جي ضرورت آهي، پوء اسان ان کي شامل ڪنداسين."
جيڪڏهن ٽيم ننڍڙي آهي، اهو ٿئي ٿو ته اتي هڪ ڊولپر آهي جيڪو سڀ ڪجهه لکي ٿو، باقي ونگن ۾ آهن. "مون بنيادي فن تعمير لکيو، اچو ته انٽرفيس شامل ڪريو." پوءِ ڪجهه نقطي تي مينيجر، مثال طور، پنن. ۽ هن عرصي دوران، جڏهن مئنيجر ڇڏي ويو آهي ۽ هڪ نئون اڃا تائين مقرر نه ڪيو ويو آهي، ڊولپر پاڻ فيصلو ڪيو ته خدمت ڪٿي وڃي رهي آهي ۽ اتي ڇا ٿي رهيو آهي. ۽ جيئن اسان ڄاڻون ٿا (چلو ڪجهه سلائڊ واپس وڃو)، ڪجهه ٽيمن ۾ برفاني ماڻهو آهن، ڪڏهن ڪڏهن هڪ برفاني ٽيم ٽيم ليڊر. پوءِ هو ڇڏي ٿو، ۽ اسان کي يتيم جي خدمت ملي ٿي.
ساڳئي وقت، مدد ۽ ڪاروبار کان ڪم غائب نه ٿيندا آهن؛ اهي پٺتي پيل ۾ ختم ٿي ويندا آهن. جيڪڏهن خدمت جي ترقي دوران ڪي تعميراتي غلطيون هيون، اهي پڻ پٺتي پيل ۾ ختم ٿي وڃن ٿيون. خدمت آهستي آهستي خراب ٿي رهي آهي.
يتيم جي سڃاڻپ ڪيئن ڪجي؟
هي فهرست صورتحال کي چڱي طرح بيان ڪري ٿو. انهن جي انفراسٽرڪچر بابت ڪير ڪجهه سکيو؟
دستاويزي ڪم جي باري ۾: اتي هڪ خدمت آهي ۽، عام طور تي، اهو ڪم ڪري ٿو، ان ۾ هڪ ٻن صفحن جو دستور آهي ته ان سان ڪيئن ڪم ڪجي، پر ڪنهن کي به خبر ناهي ته اهو اندر ڪيئن ڪم ڪري ٿو.
يا، مثال طور، ڪجهه قسم جو لنڪ شارٽنر آهي. مثال طور، اسان وٽ هن وقت ٽي لنڪ شارٽنر آهن جيڪي مختلف خدمتن ۾ مختلف مقصدن لاءِ استعمال ۾ آهن. اهي صرف نتيجا آهن.
هاڻي مان ظاهر جو ڪپتان ٿيندس. ڇا ڪرڻ گهرجي؟ پهرين، اسان کي خدمت منتقل ڪرڻ جي ضرورت آهي ٻئي مينيجر ڏانهن، ٻي ٽيم. جيڪڏهن توهان جي ٽيم جي اڳواڻي اڃا تائين نه ڇڏي آهي، ته پوء هن ٻي ٽيم ۾، جڏهن توهان سمجهي رهيا آهيو ته خدمت هڪ يتيم وانگر آهي، توهان کي ڪنهن کي شامل ڪرڻ جي ضرورت آهي جيڪو گهٽ ۾ گهٽ ان بابت ڪجهه سمجهي.
مکيه شيء: توهان کي رت ۾ لکيل منتقلي جي طريقيڪار هجڻ ضروري آهي. اسان جي حالت ۾، آئون اڪثر ڪري هن جي نگراني ڪندو آهيان، ڇو ته مون کي اهو سڀ ڪم ڪرڻ جي ضرورت آهي. مينيجرز کي ان کي جلدي پهچائڻ جي ضرورت آهي، ۽ ان کي بعد ۾ ڇا ٿئي ٿو هاڻي انهن لاء اهم ناهي.
يتيم بنائڻ جو ايندڙ طريقو آهي ”اسان ان کي آئوٽ سورس ڪنداسين، اهو تيز ٿيندو، ۽ پوءِ ان کي ٽيم جي حوالي ڪنداسين. اهو واضح آهي ته هرڪو ٽيم ۾ ڪجهه منصوبا آهن، هڪ موڙ. گهڻو ڪري هڪ ڪاروباري گراهڪ سوچيندو آهي ته آئوٽ سورس اهو ئي ڪم ڪندو جيئن ٽيڪنيڪل ڊپارٽمينٽ جيڪو ڪمپني وٽ آهي. جيتوڻيڪ انهن جا محرڪ مختلف آهن. اتي عجيب ٽيڪنالاجي حل آهن ۽ آئوٽ سورسنگ ۾ عجيب الورورٿمڪ حل.
مثال طور، اسان وٽ هڪ خدمت هئي جيڪا مختلف غير متوقع هنڌن تي اسفنڪس هئي. مان توهان کي بعد ۾ ٻڌائيندس ته مون کي ڇا ڪرڻو هو.
آئوٽ سورسرز وٽ خود لکيل فريم ورڪ آهن. هي صرف هڪ پوئين پروجيڪٽ کان ڪاپي پيسٽ سان بيئر پي ايڇ پي آهي، جتي توهان هر قسم جون شيون ڳولي سگهو ٿا. ڊيپلائيمينٽ اسڪرپٽ هڪ وڏي خرابي آهي جڏهن توهان کي ڪجهه فائلن ۾ ڪيترن ئي لائينن کي تبديل ڪرڻ لاءِ ڪجهه پيچيده بش اسڪرپٽ استعمال ڪرڻ جي ضرورت آهي، ۽ اهي ترتيب ڏيڻ واري اسڪرپٽ کي ڪجهه ٽئين اسڪرپٽ سان سڏيو ويندو آهي. نتيجي طور، توهان ترتيب ڏيڻ واري نظام کي تبديل ڪريو، ٻيو ڪجهه چونڊيو، هاپ ڪريو، پر توهان جي خدمت ڪم نه ڪندي. ڇاڪاڻ ته اتي مختلف فولڊرن جي وچ ۾ 8 وڌيڪ لنڪس رکڻ ضروري هو. يا ائين ٿئي ٿو ته هڪ هزار رڪارڊ ڪم ڪن ٿا، پر هڪ لک هاڻي ڪم نه ٿا ڪن.
مان ڪپتاني جاري رکندس. هڪ آئوٽ سورس سروس قبول ڪرڻ هڪ لازمي طريقو آهي. ڇا ڪنهن وٽ ڪڏهن هڪ آئوٽ سورس سروس آئي آهي ۽ ڪٿي به قبول نه ڪئي وئي آهي؟ اهو مشهور نه آهي، يقينا، هڪ يتيم خدمت جي طور تي، پر اڃا تائين.
خدمت کي جانچڻ جي ضرورت آهي، خدمت کي نظرثاني ڪرڻ جي ضرورت آهي، پاسورڊ تبديل ڪرڻ جي ضرورت آهي. اسان وٽ هڪ ڪيس هو جڏهن انهن اسان کي هڪ خدمت ڏني، اتي هڪ منتظم پينل آهي “جيڪڏهن لاگ ان == 'منتظم' ۽& پاس ورڊ == 'ايڊمن'..."، اهو صحيح ڪوڊ ۾ لکيل آهي. اسان ويٺا آهيون ۽ سوچيو ٿا، ۽ ماڻهو هن کي 2018 ۾ لکندا آهن؟
اسٽوريج جي صلاحيت جي جانچ پڻ هڪ ضروري شيء آهي. توهان کي ڏسڻ جي ضرورت آهي ته هڪ لک رڪارڊ تي ڇا ٿيندو، ان کان اڳ جو توهان هن خدمت کي پيداوار ۾ ڪنهن جاء تي رکون.
بهتري لاءِ خدمت موڪلڻ ۾ ڪو به شرم نه ٿيڻ گهرجي. جڏهن توهان چئو: "اسان هن خدمت کي قبول نه ڪنداسين، اسان وٽ 20 ڪم آهن، اهي ڪريو، پوء اسان قبول ڪنداسين،" اهو عام آهي. توهان جي ضمير کي ان حقيقت سان ڏک نه ٿيڻ گهرجي ته توهان مينيجر قائم ڪري رهيا آهيو يا اهو ڪاروبار پئسا ضايع ڪري رهيو آهي. ڪاروبار پوءِ وڌيڪ خرچ ڪندو.
اسان وٽ هڪ ڪيس هو جڏهن اسان هڪ پائلٽ پروجيڪٽ کي آئوٽ سورس ڪرڻ جو فيصلو ڪيو.
اهو وقت تي پهچايو ويو، ۽ اهو صرف معيار جو معيار هو. ان ڪري اسان هڪ ٻيو پائلٽ پروجيڪٽ ٺاهيو، جيڪو هاڻي پائلٽ نه هو. اهي خدمتون قبول ڪيون ويون، ۽ انتظامي ذريعن ذريعي انهن چيو، هي آهي توهان جو ڪوڊ، هتي آهي ٽيم، هتي توهان جو مينيجر آهي. خدمتون اصل ۾ منافعو ٺاهڻ شروع ڪري ڇڏيون آهن. ساڳي ئي وقت، حقيقت ۾، اهي اڃا تائين يتيم آهن، ڪو به نه ٿو سمجهي ته اهي ڪيئن ڪم ڪن ٿا، ۽ مينيجر پنهنجن ڪمن کي رد ڪرڻ لاء بهترين ڪوشش ڪندا آهن.
اتي هڪ ٻيو عظيم تصور آهي - گوريلا ترقي. جڏهن ڪجهه ڊپارٽمينٽ، عام طور تي مارڪيٽنگ ڊپارٽمينٽ، هڪ مفروضي کي جانچڻ چاهيندو آهي ۽ سڄي سروس کي آئوٽ سورس ڪرڻ جو حڪم ڏئي ٿو. ٽريفڪ ان ۾ وهڻ شروع ٿئي ٿي، اهي دستاويز بند ڪن ٿا، ڪانٽريڪٽر سان دستاويزن تي دستخط ڪن ٿا، آپريشن ۾ اچن ٿا ۽ چون ٿا: ”يار، اسان وٽ هتي هڪ سروس آهي، ان ۾ اڳي ئي ٽريفڪ آهي، اهو اسان وٽ پئسا آڻي ٿو، اچو ته قبول ڪريون. اسان وانگر هئاسين، "اوپا، اهو ڪيئن ٿي سگهي ٿو."
۽ يتيم جي خدمت حاصل ڪرڻ جو هڪ ٻيو طريقو: جڏهن ڪجهه ٽيم اوچتو پاڻ کي لوڊ ٿيل محسوس ڪري ٿي، انتظاميه چوي ٿو: "اچو ته هن ٽيم جي خدمت کي ٻي ٽيم ڏانهن منتقل ڪيو وڃي، اهو ننڍڙو لوڊ آهي." ۽ پوءِ اسان ان کي ٽئين ٽيم ڏانهن منتقل ڪنداسين ۽ مئنيجر کي تبديل ڪنداسين. ۽ آخر ۾ اسان وٽ وري يتيم آهي.
يتيمن جو ڪهڙو مسئلو آهي؟
ڪير نه ٿو ڄاڻي، هي ويڙهاڪ جهاز واسا سويڊن ۾ اٿاريو ويو آهي، ان حقيقت لاءِ مشهور آهي ته اها لانچ ٿيڻ کان 5 منٽن کانپوءِ ٻڏي وئي. ۽ سويڊن جي بادشاهه، رستي ۾، هن لاء ڪنهن کي قتل نه ڪيو. اهو انجنيئرن جي ٻن نسلن پاران ٺاهيو ويو، جن کي خبر نه هئي ته اهڙيون ٻيڙيون ڪيئن ٺاهيون. قدرتي اثر.
ٻيڙي ٻڏي سگھي ٿي، رستي ۾، وڌيڪ خراب طريقي سان، مثال طور، جڏھن بادشاھ اڳ ۾ ئي ڪنھن طوفان ۾ ان تي سوار ھو. ۽ ائين، هو فوري طور تي غرق ٿي ويو، Agile جي مطابق اهو سٺو آهي ته جلدي ناڪام ٿي.
جيڪڏهن اسان شروعاتي ناڪام ٿي، عام طور تي ڪو مسئلو ناهي. مثال طور، قبوليت دوران ان کي نظرثاني لاء موڪليو ويو. پر جيڪڏهن اسان اڳ ۾ ئي پيداوار ۾ ناڪام ٿي ويا آهيون، جڏهن پئسو لڳايو ويندو آهي، پوء مسئلا ٿي سگهن ٿيون. نتيجي ۾، جيئن اهي ڪاروبار ۾ سڏيندا آهن.
ڇو يتيم خدمتون خطرناڪ آهن:
- خدمت اوچتو ڀڃي سگھي ٿو.
- خدمت جي مرمت ڪرڻ لاء هڪ ڊگهو وقت وٺندو آهي يا مڪمل طور تي مرمت نه ڪئي وئي آهي.
- حفاظتي مسئلا.
- بهتري ۽ اپڊيٽ سان مسئلا.
- جيڪڏهن هڪ اهم خدمت ختم ٿئي ٿي، ڪمپني جي شهرت متاثر ٿئي ٿي.
يتيم جي خدمتن سان ڇا ڪجي؟
مان ٻيهر ورجائيندس ته ڇا ڪجي. پهرين، اتي دستاويز هجڻ ضروري آهي. Banki.ru تي 7 سال مون کي سيکاريو ته ٽيسٽرن کي ڊولپرز جو لفظ نه وٺڻ گهرجي، ۽ آپريشن کي هر ڪنهن جو لفظ نه وٺڻ گهرجي. اسان کي چيڪ ڪرڻ جي ضرورت آهي.
ٻيو، اهو ضروري آهي ته رابطي جي ڊراگرام لکڻ لاء، ڇاڪاڻ ته اهو ٿئي ٿو ته خدمتون جيڪي تمام سٺو وصول نه ڪيا ويا آهن انهن تي انحصار آهي جنهن بابت ڪنهن به نه چيو آهي. مثال طور، ڊولپرز سروس کي انسٽال ڪيو انهن جي ڪنجي تي ڪجهه Yandex.Maps يا Dadata. توهان آزاديءَ جي حد کان ٻاهر نڪري چڪا آهيو، سڀ ڪجهه ڀڄي ويو آهي، ۽ توهان کي خبر ناهي ته ڇا ٿيو آهي. اهڙيون سڀئي ريڪون بيان ڪرڻ گهرجن: خدمت استعمال ڪري ٿي Dadata، ايس ايم ايس، ٻيو ڪجهه.
ٽيون، ٽيڪنيڪل قرض سان ڪم ڪرڻ. جڏهن توهان ڪنهن قسم جي ڪچري يا خدمت قبول ڪندا آهيو ۽ چوندا آهن ته ڪجهه ڪرڻ جي ضرورت آهي، توهان کي پڪ ڪرڻ جي ضرورت آهي ته اهو ٿي چڪو آهي. ڇو ته پوءِ اهو ٿي سگهي ٿو ته اهو ننڍڙو سوراخ ايترو ننڍڙو نه آهي، ۽ توهان ان جي ذريعي ڪري سگهو ٿا.
تعميراتي ڪمن سان، اسان وٽ اسفنڪس بابت هڪ ڪهاڻي هئي. ھڪڙي خدمتن مان ھڪڙي فهرستن ۾ داخل ڪرڻ لاءِ Sphinx استعمال ڪيو. صرف هڪ صفحي جي فهرست، پر اهو هر رات ٻيهر ترتيب ڏنو ويو. ان کي ٻن انگن اکرن مان گڏ ڪيو ويو: ھڪڙو وڏو انگ ھر رات ٺاھيو ويندو ھو، ۽ ھڪڙو ننڍڙو انڊيڪس پڻ ھو، جيڪو ان کي خراب ڪيو ويو. هر روز، بم ڌماڪي يا نه ٿيڻ جي 50 سيڪڙو امڪان سان، انڊيڪس ڳڻپ دوران خراب ٿي ويو، ۽ اسان جون خبرون مکيه صفحي تي اپڊيٽ ٿيڻ بند ٿي ويون. انڊيڪس کي ٻيهر انڊيڪس ٿيڻ ۾ پهريان 5 منٽ لڳا، پوءِ انڊيڪس وڌيو، ۽ ڪجهه وقت تي انڊيڪس کي ري-انڊيڪس ٿيڻ ۾ 40 منٽ لڳي ويا. جڏهن اسان هن کي ڪٽي ڇڏيو، اسان راحت جو ساهه کنيو، ڇاڪاڻ ته اهو واضح هو ته ٿورو وڌيڪ وقت گذري ويندو ۽ اسان جي انڊيڪس مڪمل وقت تي ٻيهر ترتيب ڏني ويندي. اها اسان جي پورٽل جي ناڪامي ٿيندي، اٺن ڪلاڪن تائين ڪا خبر ناهي - اهو ئي آهي، ڪاروبار بند ٿي ويو آهي.
يتيم جي خدمت سان ڪم ڪرڻ جو منصوبو
حقيقت ۾، اهو ڪرڻ تمام ڏکيو آهي، ڇاڪاڻ ته ڊيوپس مواصلات بابت آهي. توهان چاهيو ٿا ته توهان جي ساٿين سان سٺيون شرطون هجن، ۽ جڏهن توهان پنهنجن ساٿين ۽ مينيجرن کي ضابطن سان سر تي ڌڪايو ٿا، انهن کي انهن ماڻهن جي لاء متضاد جذبات هوندا جيڪي اهو ڪندا آهن.
انهن سڀني نقطن کان علاوه، هڪ ٻيو اهم شيء آهي: مخصوص ماڻهن کي هر مخصوص خدمت لاء ذميوار هجڻ گهرجي، مقرري جي طريقيڪار جي هر مخصوص حصي لاء. جڏهن ماڻهو نه هوندا آهن ۽ توهان کي ڪجهه ٻين ماڻهن کي هن سڄي معاملي کي پڙهڻ لاء راغب ڪرڻو پوندو، اهو ڏکيو ٿي ويندو آهي.
جيڪڏهن اهو سڀ ڪجهه مدد نه ڪيو، ۽ توهان جي يتيم خدمت اڃا تائين هڪ يتيم آهي، ڪو به ان کي وٺڻ نه چاهيندو آهي، دستاويز نه لکيل آهي، ٽيم جنهن کي هن خدمت ۾ سڏيو ويو هو ڪجهه به ڪرڻ کان انڪار ڪري، هڪ سادي طريقو آهي - ٻيهر ڪرڻ لاء سڀ ڪجهه.
اهو آهي، توهان خدمت جي گهرج کي نئين سر وٺو ۽ هڪ نئين خدمت لکو، بهتر، بهتر پليٽ فارم تي، عجيب ٽيڪنالاجي حلن کان سواءِ. ۽ توهان ان ڏانهن لڏپلاڻ ڪري رهيا آهيو.
اسان کي اها حالت هئي جڏهن اسان Yii 1 تي هڪ خدمت ورتي ۽ محسوس ڪيو ته اسان ان کي وڌيڪ ترقي نه ٿا ڪري سگهون، ڇاڪاڻ ته اسان وٽ ڊولپرز کان ٻاهر ڀڄي ويا جيڪي Yii 1 تي سٺو لکي سگهندا هئا. سڀئي ڊولپر سمفوني XNUMX تي سٺو لکندا هئا. ڇا ڪجي؟ اسان وقت مختص ڪيو، هڪ ٽيم مختص ڪئي، هڪ مينيجر کي مختص ڪيو، منصوبي کي ٻيهر لکيو ۽ آسانيء سان ان ڏانهن ٽرئفڪ کي تبديل ڪيو.
ان کان پوء، پراڻي خدمت کي ختم ڪري سگهجي ٿو. هي منهنجو پسنديده طريقو آهي، جڏهن توهان کي ترتيب ڏيڻ واري انتظاماتي نظام مان ڪجهه خدمت وٺڻ ۽ صاف ڪرڻ جي ضرورت آهي ۽ پوء ان ذريعي وڃو ۽ ڏسو ته پيداوار ۾ سڀ ڪارٽون غير فعال ٿي ويون آهن، انهي ڪري ته ڊولپرز وٽ ڪو نشان نه بچيو آهي. مخزن Git ۾ رهي ٿو.
اهو سڀ ڪجهه آهي جنهن بابت مان ڳالهائڻ چاهيان ٿو، مان بحث ڪرڻ لاءِ تيار آهيان، موضوع هوليور آهي، ڪيترائي ان ۾ ترسيا آهن.
سلائيڊ چيو ته توهان ٻولين کي متحد ڪيو. هڪ مثال تصويرن جي ريزائزنگ هئي. ڇا واقعي ان کي سختيءَ سان هڪ ٻوليءَ تائين محدود ڪرڻ ضروري آهي؟ ڇو ته PHP ۾ تصوير جي ريزائيزنگ، سٺو، اصل ۾ گولانگ ۾ ٿي سگهي ٿو.
حقيقت ۾، اهو اختياري آهي، سڀني طريقن وانگر. شايد، ڪجهه حالتن ۾، اهو پڻ ناپسنديده آهي. پر توهان کي اهو سمجهڻ جي ضرورت آهي ته جيڪڏهن توهان وٽ 50 ماڻهن جي ڪمپني ۾ ٽيڪنيڪل ڊپارٽمينٽ آهي، انهن مان 45 PHP ماهر آهن، ٻيا 3 ڊيوپس آهن جيڪي ڄاڻن ٿا پٿون، جوابي، پپٽ ۽ ڪجهه اهڙي قسم جي، ۽ انهن مان صرف هڪ ڪجهه لکي ٿو. ٻولي جو قسم. ڪجهه گو تصوير کي ٻيهر ڏيڻ جي خدمت، پوءِ جڏهن اها ڇڏي ٿي، ماهر ان سان گڏ هلي ٿو. ۽ ساڳئي وقت، توهان کي مارڪيٽ جي مخصوص ڊولپر کي ڳولڻ جي ضرورت پوندي جيڪو هن ٻولي ڄاڻي ٿو، خاص طور تي جيڪڏهن اهو نادر آهي. اهو آهي، هڪ تنظيمي نقطي نظر کان، اهو مسئلو آهي. ڊيوپس جي نقطي نظر کان، توهان کي صرف ڪجهه تيار ڪيل راندين جي سيٽن کي ڪلون ڪرڻ جي ضرورت ناهي جيڪا توهان خدمتن کي ترتيب ڏيڻ لاء استعمال ڪندا آهيو، پر توهان کي انهن سڀني کي ٻيهر لکڻو پوندو.
اسان هن وقت Node.js تي هڪ خدمت ٺاهي رهيا آهيون، ۽ اهو صرف هڪ پليٽ فارم هوندو ويجھو هر ڊولپر لاءِ الڳ ٻولي سان. پر اسان ويٺاسين ۽ سوچيو ته راند شمع جي لائق هئي. اھو آھي، اھو ھڪڙو سوال آھي توھان لاءِ ويھڻ ۽ سوچڻ لاءِ.
توهان پنهنجي خدمتن جي نگراني ڪيئن ڪندا آهيو؟ توهان ڪئين گڏ ڪندا آهيو ۽ لاگ ان جي نگراني ڪندا آهيو؟
اسان Elasticsearch ۾ لاگ گڏ ڪندا آهيون ۽ انهن کي ڪبانا ۾ رکون ٿا، ۽ ان تي منحصر آهي ته ڇا اهو پيداوار آهي يا ٽيسٽ ماحول، اتي مختلف ڪليڪٽر استعمال ڪيا ويندا آهن. ڪٿي لمبرجڪ، ڪٿي ٻيو ڪجهه، مون کي ياد ناهي. ۽ اڃا تائين ڪجھ جڳھون آھن ڪجھ خاص خدمتن ۾ جتي اسان ٽيليگراف کي انسٽال ڪريون ٿا ۽ ٻي جاءِ ڌار ڌار شوٽ ڪريون ٿا.
هڪ ئي ماحول ۾ ڪٺ پتلي ۽ جوابدار سان ڪيئن رهجي؟
حقيقت ۾، اسان وٽ هاڻي ٻه ماحول آهن، هڪ Puppet آهي، ٻيو جواب ڏيڻ وارو آهي. اسان ان کي هائبرڊائيز ڪرڻ لاء ڪم ڪري رهيا آهيون. جوابي شروعاتي سيٽ اپ لاءِ هڪ سٺو فريم ورڪ آهي، پپٽ شروعاتي سيٽ اپ لاءِ هڪ خراب فريم ورڪ آهي ڇاڪاڻ ته ان لاءِ هٿ سان ڪم ڪرڻ جي ضرورت آهي سڌو پليٽ فارم تي، ۽ پپٽ ڪنفيگريشن ڪنورجنسي کي يقيني بڻائي ٿي. هن جو مطلب اهو آهي ته پليٽ فارم پاڻ کي هڪ تازه ترين حالت ۾ برقرار رکي ٿو، ۽ ترتيب ڏيڻ واري مشين کي تاريخ تائين رکڻ لاء، توهان کي هر وقت ڪجهه تعدد سان ان تي راند بڪ هلائڻ جي ضرورت آهي. اهو ئي فرق آهي.
توهان مطابقت ڪيئن برقرار رکون ٿا؟ ڇا توهان وٽ جوابي ۽ پوپٽ ٻنهي ۾ ترتيب آهن؟
اهو اسان جو وڏو درد آهي، اسان پنهنجي هٿن سان مطابقت برقرار رکون ٿا ۽ اهو سوچيو ته هاڻي هن سڀني مان ڪيئن اڳتي وڌون. اهو ظاهر ٿئي ٿو ته Puppet پيڪيجز کي رول ڪري ٿو ۽ اتي ڪجهه لنڪس کي برقرار رکي ٿو، ۽ جواب ڏيڻ وارو، مثال طور، ڪوڊ کي رول ڪري ٿو ۽ اتي جديد ايپليڪيشن ترتيبن کي ترتيب ڏئي ٿو.
پريزنٽيشن روبي جي مختلف ورزن بابت هئي. ڪهڙو حل؟
اسان ان کي هڪ جاءِ تي محسوس ڪيو، ۽ اسان کي اهو هر وقت پنهنجي سرن ۾ رکڻو پوندو. اسان صرف اهو حصو بند ڪيو جيڪو روبي تي هلندو هو جيڪو ايپليڪيشنن سان مطابقت نه رکندو هو ۽ ان کي الڳ رکيو.
هن سال جي ڪانفرنس 7 ڊسمبر تي Technopolis ۾ ٿيندي. اسان 11 نومبر تائين رپورٽن لاءِ درخواستون قبول ڪري رهيا آهيون. اسان کي جيڪڏهن توهان ڳالهائڻ چاهيو ٿا.
شرڪت ڪندڙن لاءِ رجسٽريشن کليل آهي، اسان سان شامل ٿيو!
جو ذريعو: www.habr.com