انجنيئرز ايپليڪيشن مانيٽرنگ جي پرواهه ڇو نٿا ڪن؟

جمعه مبارڪ سڀني کي! دوستو، اڄ اسان ڪورس لاءِ وقف ڪيل اشاعتن جو سلسلو جاري رکون ٿا "DevOps طريقا ۽ اوزار"، ڇاڪاڻ ته ڪورس لاءِ نئين گروپ ۾ ڪلاس ايندڙ هفتي جي آخر ۾ شروع ٿيندا. سو، اچو ته شروع ڪريون!

انجنيئرز ايپليڪيشن مانيٽرنگ جي پرواهه ڇو نٿا ڪن؟

نگراني آهي بس. هي هڪ معلوم حقيقت آهي. ناگيوس کي آڻيو، ريموٽ سسٽم تي NRPE هلائي، NRPE TCP پورٽ 5666 تي ناگيوس کي ترتيب ڏيو ۽ توھان جي نگراني آھي.

اهو ايترو آسان آهي ته اهو دلچسپ ناهي. ھاڻي توھان وٽ CPU وقت، ڊسڪ سبسسٽم، RAM، ناگيوس ۽ NRPE کي ڊفالٽ طور تي مهيا ڪيل بنيادي ميٽرڪس آھن. پر اهو اصل ۾ "مانيٽرنگ" نه آهي جيئن. هي صرف شروعات آهي.

(عام طور تي اهي انسٽال ڪندا آهن PNP4Nagios، RRDtool ۽ Thruk، Slack ۾ نوٽيفڪيشن سيٽ ڪريو ۽ سڌو وڃو nagiosexchange، پر اچو ته ان کي ڇڏي ڏيو هاڻي).

سٺي نگراني اصل ۾ ڪافي پيچيده آهي، توهان کي واقعي ڄاڻڻ جي ضرورت آهي اندروني ايپليڪيشنن کي جيڪو توهان مانيٽر ڪري رهيا آهيو.

ڇا مانيٽرنگ ڏکيو آهي؟

ڪو به سرور، اهو لينڪس هجي يا ونڊوز، تعريف سان ڪجهه مقصد جي خدمت ڪندو. Apache، Samba، Tomcat، فائل اسٽوريج، LDAP - اهي سڀئي خدمتون هڪ يا وڌيڪ احترام ۾ گهٽ يا گهٽ منفرد آهن. هر هڪ پنهنجي فنڪشن آهي، ان جي پنهنجي خاصيتون. ميٽرڪ حاصل ڪرڻ جا مختلف طريقا آهن، KPIs (اهم ڪارڪردگي جا اشارا)، جيڪي توهان لاءِ دلچسپ آهن جڏهن سرور لوڊ هيٺ آهي.

انجنيئرز ايپليڪيشن مانيٽرنگ جي پرواهه ڇو نٿا ڪن؟
تصوير جو مصنف لوقا شيسر تي ناپسند

(مان چاهيان ٿو ته منهنجا ڊيش بورڊ نيون نيرو هجن - sighing dreamily -... hmm...)

ڪو به سافٽ ويئر جيڪو مهيا ڪري ٿو خدمتون مهيا ڪري ميٽرڪ گڏ ڪرڻ لاء هڪ ميکانيزم هجڻ گهرجي. Apache هڪ ماڊل آهي mod-status, ڏيکاريندي سرور اسٽيٽس صفحو. Nginx آهي - stub_status. Tomcat وٽ JMX يا ڪسٽم ويب ايپليڪيشنون آهن جيڪي ڏيکارين ٿيون اهم ميٽرڪس. MySQL هڪ حڪم آهي "شو گلوبل اسٽيٽس" وغيره.
پوء ڇو ڊولپرز انهن ايپليڪيشنن ۾ هڪجهڙائي ميڪانيزم ٺاهي نٿا ڪن جيڪي اهي ٺاهي رهيا آهن؟

ڇا صرف ڊولپرز اهو ڪري رهيا آهن؟

ميٽرڪس ايمبيڊنگ جي بي حسي جي هڪ خاص سطح ڊولپرز تائين محدود ناهي. مون انهن ڪمپنين ۾ ڪم ڪيو جتي انهن Tomcat استعمال ڪندي ايپليڪيشنون ڊولپ ڪيون آهن ۽ انهن جو پنهنجو ڪو به ميٽرڪ مهيا نه ڪيو آهي، نه سروس سرگرمي جو ڪو لاگ، سواءِ عام Tomcat غلطي جي لاگن جي. ڪجھ ڊولپر تمام گھڻا لاگ ٺاھيندا آھن جن جو مطلب سسٽم ايڊمنسٽريٽر لاءِ ڪجھ به نه ھوندو آھي جيڪو انھن کي صبح جو 3:15 تي پڙھڻ لاءِ ناخوش آھي.

انجنيئرز ايپليڪيشن مانيٽرنگ جي پرواهه ڇو نٿا ڪن؟
تصوير جو مصنف تيم گو تي ناپسند

سسٽم انجنيئر جيڪي اهڙي پروڊڪٽس کي جاري ڪرڻ جي اجازت ڏين ٿا انهن کي پڻ صورتحال جي ذميواري کڻڻ گهرجي. ڪجھ سسٽم انجنيئرن وٽ وقت يا خيال آھي لاگز مان بامعني ميٽرڪ ڪڍڻ جي ڪوشش ڪرڻ جي، انھن ميٽرڪس جي حوالي سان ۽ انھن کي ايپليڪيشن سرگرمي جي روشني ۾ تشريح ڪرڻ جي صلاحيت جي بغير. ڪجھ نه سمجھندا آھن ته اھي ان مان ڪيئن فائدو حاصل ڪري سگھن ٿا، ٻيو ته "ڪجهه في الحال آھي (يا جلد ٿيندو) غلط" اشارا.

ميٽرڪس جي ضرورت جي حوالي سان سوچ ۾ تبديلي نه رڳو ڊولپرز جي وچ ۾، پر سسٽم انجنيئرن جي وچ ۾ پڻ.

ڪنهن به سسٽم انجنيئر لاءِ جنهن کي نه رڳو نازڪ واقعن جو جواب ڏيڻ جي ضرورت آهي، پر اهو پڻ يقيني بڻائڻ گهرجي ته اهي نه ٿين، ميٽرڪ جي کوٽ عام طور تي ائين ڪرڻ ۾ رڪاوٽ آهي.

جڏهن ته، سسٽم انجنيئر عام طور تي ڪوڊ سان ٽڪر نه ڪندا آهن انهن جي ڪمپني لاء پئسا ڪمائڻ لاء. انهن کي ليڊ ڊولپرز جي ضرورت آهي جيڪي سسٽم انجنيئر جي ذميواري جي اهميت کي سمجهن ٿا مسئلن جي نشاندهي ڪرڻ، ڪارڪردگي جي مسئلن جي شعور کي وڌائڻ، ۽ جهڙوڪ.

هي شيء کي ختم ڪري ٿو

ديوپ ذهنيت ترقي (dev) ۽ آپريشن (ops) سوچ جي وچ ۾ هم آهنگ بيان ڪري ٿي. ڪا به ڪمپني جيڪا دعوي ڪري ٿي ته "ڊيوپس" ڪرڻ گهرجي:

  1. اهي شيون جيڪي چوندا آهن اهي شايد نه هجن (راجکماري دلہن جي يادگيري ڏانهن اشارو ڪندي - "مان نه ٿو سمجهان ته ان جو مطلب اهو آهي ته توهان سوچيو ته ان جو مطلب!")
  2. مسلسل پيداوار جي بهتري جي رويي جي حوصلا افزائي ڪريو.

توهان هڪ پيداوار کي بهتر نه ٿا ڪري سگهو ۽ ڄاڻو ته اهو بهتر ڪيو ويو آهي جيڪڏهن توهان کي خبر ناهي ته اهو ڪيئن ڪم ڪري ٿو. توهان کي خبر ناهي ته هڪ پراڊڪٽ ڪيئن ڪم ڪري ٿو جيڪڏهن توهان نٿا سمجهو ته ان جا حصا ڪيئن ڪم ڪن ٿا، خدمتون جيڪي ان تي منحصر آهن، ان جا بنيادي درد پوائنٽ ۽ رڪاوٽون.
جيڪڏهن توهان امڪاني رڪاوٽن لاءِ نه ڏسندا آهيو، توهان پوسٽ مارٽم لکڻ دوران Five Whys ٽيڪنڪ تي عمل ڪرڻ جي قابل نه هوندا. توهان هر شي کي هڪ اسڪرين تي رکڻ جي قابل نه هوندا ته ڏسو ته هڪ پراڊڪٽ ڪيئن ڪم ڪري ٿي يا ڄاڻو ته اهو "عام ۽ خوش" وانگر نظر اچي ٿو.

کاٻي پاسي ڦيرايو، کاٻي، مون چيو ليئي-

مون لاء، Devops جي اهم اصولن مان هڪ آهي "شفٽ کاٻي". هن حوالي سان کاٻي پاسي شفٽ ڪرڻ جو مطلب آهي امڪان کي ڦيرائڻ (ڪابه ذميواري، پر صرف صلاحيتون) اهي شيون ڪرڻ لاءِ جيڪي سسٽم انجنيئرن کي عام طور تي خيال رکندا آهن، جهڙوڪ ڪارڪردگي ميٽرڪ ٺاهڻ، لاگز کي وڌيڪ موثر طريقي سان استعمال ڪرڻ وغيره، سافٽ ويئر ڊليوري لائف سائيڪل ۾ کاٻي پاسي.

انجنيئرز ايپليڪيشن مانيٽرنگ جي پرواهه ڇو نٿا ڪن؟
تصوير جو مصنف ميڪر پاران اين اي ايس اي تي ناپسند

سافٽ ويئر ڊولپرز کي مانيٽرنگ ٽولز استعمال ڪرڻ ۽ ڄاڻڻ جي قابل هجڻ گھرجي جيڪي ڪمپني استعمال ڪري ٿي مانيٽرنگ ڪرڻ لاءِ ان جي سڀني شڪلن، ميٽرڪس، لاگنگ، مانيٽرنگ انٽرفيس ۽، سڀ کان اهم، ڏسو ته ڪيئن انهن جي پيداوار پيداوار ۾ ڪم ڪري ٿي. توهان ڊولپرز کي مانيٽرنگ ۾ ڪوشش ۽ وقت سيڙائڻ لاءِ نه ٿا حاصل ڪري سگهو جيستائين اهي ميٽرڪس ڏسي سگهن ۽ اثر انداز ٿين ته اهي ڪيئن نظر اچن ٿا، ڪيئن پراڊڪٽ مالڪ انهن کي ايندڙ بريفنگ تي CTO کي پيش ڪري ٿو، وغيره.

نن Shortڙي ڳالھ

  1. پنھنجي گھوڙي کي پاڻي ڏانھن وٺي. ڊولپرز کي ڏيکاريو ته هو پنهنجي لاءِ ڪيتري تڪليف کان بچي سگهن ٿا، انهن جي ايپليڪيشنن لاءِ صحيح KPIs ۽ ميٽرڪس جي نشاندهي ڪرڻ ۾ مدد ڪن ته جيئن پروڊڪٽ جي مالڪ کان گهٽ رڙ نه ٿئي جنهن تي CTO پاران چيل آهي. انھن کي روشنيءَ ۾ آڻيو، آرام سان ۽ آرام سان. جيڪڏهن اهو ڪم نٿو ڪري، ته پوءِ رشوت ڏيو، ڌمڪيون ڏيو، ۽ انهن کي يا پراڊڪٽ جي مالڪ کي لاڳو ڪرڻ لاءِ انهن ميٽرڪس کي ايپليڪيشنن مان جيترو جلدي ممڪن ٿي سگهي حاصل ڪرڻ لاءِ، ۽ پوءِ ڊراگرام ٺاھيو. اهو مشڪل هوندو ڇو ته ان کي ترجيح طور نه ڏٺو ويندو ۽ پراڊڪٽ روڊ ميپ ۾ ڪيترائي آمدني پيدا ڪرڻ وارا منصوبا التوا ۾ هوندا. تنهن ڪري، توهان کي هڪ ڪاروباري ڪيس جي ضرورت پوندي ته جيئن پروڊڪٽ ۾ نگراني کي لاڳو ڪرڻ ۾ خرچ ڪيل وقت ۽ خرچ جو جواز پيش ڪجي.
  2. سسٽم انجنيئرن کي سٺي رات جي ننڊ ۾ مدد ڪريو. انهن کي ڏيکاريو ته ڪنهن به پراڊڪٽ جي جاري ٿيڻ لاءِ ”چلو رليز“ چيڪ لسٽ استعمال ڪرڻ سٺي شيءِ آهي. ۽ يقيني بڻائڻ ته پيداوار ۾ سڀئي ايپليڪيشنون ميٽرڪس سان ڍڪيل آهن توهان کي رات جو بهتر ننڊ ۾ مدد ڪندي ڊولپرز کي اهو ڏسڻ جي اجازت ڏيندي ته ڇا غلط ٿي رهيو آهي ۽ ڪٿي. بهرحال، ڪنهن به ڊولپر، پراڊڪٽ مالڪ، يا CTO کي ناراض ڪرڻ ۽ مايوس ڪرڻ جو صحيح طريقو آهي جاري رهڻ ۽ مزاحمت ڪرڻ. اهو رويو ڪنهن به پراڊڪٽ جي رليز جي تاريخ تي اثر انداز ٿيندو جيڪڏهن توهان ٻيهر آخري منٽ تائين انتظار ڪريو، پوءِ ٻيهر کاٻي پاسي ڦيرايو ۽ انهن مسئلن کي جلد کان جلد پنهنجي منصوبي جي منصوبي ۾ شامل ڪريو. جيڪڏهن ضروري هجي ته، پيداوار جي گڏجاڻين ڏانهن پنهنجو رستو ٺاهيو. هڪ جعلي مونچھون پائڻ ۽ محسوس ڪيو يا ڪجهه، اهو ڪڏهن به ناڪام نه ٿيندو. پنھنجا خدشا بيان ڪريو، واضح فائدن جو مظاهرو ڪريو، ۽ تبليغ ڪريو.
  3. پڪ ڪريو ته ترقي (dev) ۽ آپريشن (ops) ٻنهي جي معنيٰ ۽ نتيجي کي سمجھن ٿا پراڊڪٽ ميٽرڪس جي ريڊ زون ۾ منتقل ٿيڻ. Ops کي پراڊڪٽ جي صحت جي واحد نگهبان طور نه ڇڏيو، پڪ ڪريو ته ڊولپر به ملوث آهن (#productsquads).
  4. لاگز هڪ عظيم شيء آهي، پر ميٽرڪ پڻ آهن. انهن کي گڏ ڪريو ۽ توهان جي لاگن کي بيڪار جي وڏي ٻرندڙ بال ۾ ڪچرو ٿيڻ نه ڏيو. وضاحت ڪريو ۽ ڊولپرز کي ڏيکاريو ڇو ٻيو ڪو به سندن لاگن کي سمجھي نه سگھندو، انھن کي ڏيکاريو ته اھو ڪھڙو آھي بيڪار لاگ ڏسڻ لاءِ صبح جو 3:15 تي.

انجنيئرز ايپليڪيشن مانيٽرنگ جي پرواهه ڇو نٿا ڪن؟
تصوير جو مصنف مارڪو هورواٽ تي ناپسند

اهو ئي سڀ ڪجهه آهي. نئون مواد ايندڙ هفتي جاري ڪيو ويندو. جيڪڏهن توهان ڪورس بابت وڌيڪ سکڻ چاهيندا، اسان توهان کي دعوت ڏيون ٿا کليل ڏينهن، جيڪو سومر تي ٿيندو. ۽ هاڻي اسان روايتي طور تي توهان جي راين جو انتظار ڪري رهيا آهيون.

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

تبصرو شامل ڪريو