سلام، حبر! زه د لسو کلونو لپاره د Highload IT سیسټمونو ملاتړ کوم. زه به پدې مقاله کې د 1000+ RPS حالت یا نورو تخنیکي شیانو کې کار کولو لپاره د نګینکس تنظیم کولو ستونزو په اړه ونه لیکم. زه به په پروسو کې د ستونزو په اړه خپل نظرونه شریک کړم چې د داسې سیسټمونو په ملاتړ او فعالیت کې رامینځته کیږي.
څارنه
تخنیکي ملاتړ تر هغه وخته پورې انتظار نه کوي چې غوښتنې ته د مینځپانګې سره راشي "څه ولې ... سایټ بیا کار نه کوي؟" د سایټ له غورځیدو وروسته د یوې دقیقې دننه ، ملاتړ باید دمخه ستونزه وګوري او حل یې پیل کړي. مګر سایټ د یخ برګ سر دی. د دې شتون یو له لومړیو څخه دی چې څارل کیږي.
د وضعیت سره څه وکړي کله چې د آنلاین پلورنځي پاتې توکي نور د ERP سیسټم څخه نه راځي؟ یا آیا د CRM سیسټم چې د پیرودونکو لپاره تخفیف محاسبه کوي ځواب ورکول بند کړي؟ داسې ښکاري چې سایټ کار کوي. مشروط زیبکس خپل 200 ځواب ترلاسه کوي. د وظیفې بدلون د څارنې څخه هیڅ خبرتیا نه ده ترلاسه کړې او په خوښۍ سره د گیم آف تھرونز نوي فصل لومړۍ برخه ګوري.
نظارت اکثرا یوازې د حافظې حالت ، RAM او سرور پروسیسر بار اندازه کولو پورې محدود وي. مګر د سوداګرۍ لپاره دا خورا مهم دی چې په ویب پا onه کې د محصول شتون ترلاسه کړئ. په کلستر کې د یو مجازی ماشین مشروط ناکامي به د دې حقیقت لامل شي چې ترافیک به دې ته مخه کړي او په نورو سرورونو بار به ډیر شي. شرکت به پیسې له لاسه ورنکړي.
له همدې امله ، په سرورونو کې د عملیاتي سیسټمونو تخنیکي پیرامیټونو نظارت کولو سربیره ، تاسو اړتیا لرئ د سوداګرۍ میټریک تنظیم کړئ. هغه میترونه چې په مستقیم ډول پیسې اغیزه کوي. د بهرني سیسټمونو سره مختلف تعاملات (CRM، ERP او نور). د یوې ټاکلې مودې لپاره د امرونو شمیر. بریالي یا ناکام پیرودونکي واکونه او نور معیارونه.
د بهرنیو سیسټمونو سره تعامل
هره ویب پاڼه یا ګرځنده اپلیکیشن د یو ملیارد روبلو څخه ډیر کلني تبادلې سره د بهرني سیسټمونو سره اړیکه لري. د پورته ذکر شوي CRM او ERP څخه پیل کول او د پیرود تحلیل لپاره بهرني لوی ډیټا سیسټم ته د پلور ډیټا لیږدولو سره پای ته رسیدل او پیرودونکي ته یو محصول وړاندیز کوي چې هغه به خامخا واخلي (په حقیقت کې نه). هر دا ډول سیسټم خپل ملاتړ لري. او ډیری وختونه د دې سیسټمونو سره اړیکه د درد لامل کیږي. په ځانګړي توګه کله چې ستونزه نړیواله وي او تاسو اړتیا لرئ دا په مختلف سیسټمونو کې تحلیل کړئ.
ځینې سیسټمونه د دوی مدیرانو لپاره د تلیفون شمیره یا ټیلګرام چمتو کوي. چیرې چې تاسو اړتیا لرئ مدیرانو ته لیکونه ولیکئ یا د دې بهرني سیسټمونو بګ ټریکرانو ته لاړشئ. حتی د یو لوی شرکت په شرایطو کې، مختلف سیسټمونه اکثرا د مختلف غوښتنلیک حساب ورکولو سیسټمونو کې کار کوي. ځینې وختونه د غوښتنلیک حالت تعقیب کول ناممکن کیږي. تاسو په یوه مشروط جیره کې غوښتنه ترلاسه کوئ. بیا د دې لومړۍ جرګې په تبصره کې تاسو په بله جرګه کې د مسلې لینک واچوئ. په غوښتنلیک کې په دویمه جرګه کې، یو څوک لا دمخه یو نظر لیکي چې تاسو اړتیا لرئ د مسلې حل کولو لپاره مشروط مدیر اندري ته زنګ ووهئ. او هم
د دې ستونزې غوره حل به د اړیکو لپاره یو واحد ځای رامینځته کړي، د بیلګې په توګه په سلیک کې. د بهرني سیسټمونو عملیاتي پروسې کې ټولو ګډون کونکو ته د ګډون لپاره بلنه ورکول. او یو واحد ټریکر هم ترڅو غوښتنلیکونه نقل نشي. غوښتنلیکونه باید په یو ځای کې تعقیب شي ، د څارنې خبرتیاو څخه په راتلونکي کې د بګ حلونو محصول پورې. تاسو به ووایاست چې دا غیر واقعیت دی او دا په تاریخي توګه پیښ شوي چې موږ په یو ټریکر کې کار کوو، او دوی په بل کې کار کوي. مختلف سیسټمونه راښکاره شول، دوی خپل خپلواک IT ټیمونه درلودل. زه موافق یم، او له همدې امله ستونزه باید له پورته څخه د CIO یا د محصول د مالک په کچه حل شي.
هر سیسټم چې تاسو ورسره اړیکه لرئ باید د یو روښانه SLA سره د خدماتو په توګه مالتړ چمتو کړئ ترڅو مسلې د لومړیتوب له مخې حل کړي. او نه کله چې مشروط مدیر اندری ستاسو لپاره یوه دقیقه ولري.
خنډ سړی
ایا په پروژه (یا محصول) کې هرڅوک یو څوک لري چې په رخصتۍ کې د دوی د لوړ پوړو چارواکو تر مینځ د اختلال لامل کیږي؟ دا کیدی شي د ډیوپس انجینر، شنونکی یا پراختیا کونکی وي. په هرصورت ، یوازې د ډیوپس انجینر پوهیږي چې کوم سرورونه لري کوم کانټینرونه نصب شوي ، د ستونزې په صورت کې کانټینر څنګه ریبوټ کړئ ، او په عموم کې ، کومه پیچلې ستونزه د هغه پرته نشي حل کیدی. شنونکی یوازینی څوک دی چې پوهیږي چې ستاسو پیچلي میکانیزم څنګه کار کوي. کوم ډیټا جریان چیرته ځي. د غوښتنو د کوم پیرامیټرونو لاندې کوم خدماتو ته ، کوم چې موږ به ځوابونه ترلاسه کړو.
څوک به ژر پوه شي چې ولې په لاګونو کې تېروتنې شتون لري او په سمدستي توګه په محصول کې یو جدي بګ حل کړي؟ البته ورته پراختیا کونکی. نور هم شتون لري، مګر یوازې د ځینو دلیلونو لپاره هغه پوهیږي چې څنګه د سیسټم مختلف ماډلونه کار کوي.
د دې ستونزې ریښه د اسنادو نشتوالی دی. په هرصورت، که ستاسو د سیسټم ټول خدمتونه بیان شوي وي، نو دا به ممکن وي چې پرته له شنونکي سره د ستونزې سره معامله وشي. که devops د خپل مصروف مهال ویش څخه څو ورځې وخت ونیسي او د عادي ستونزو د حل لپاره ټول سرورونه، خدمات او لارښوونې بیان کړي، نو د هغه په نه شتون کې ستونزه د هغه پرته حل کیدی شي. تاسو اړتیا نلرئ د رخصتۍ پرمهال په ساحل کې خپل بیر ژر تر ژره پای ته ورسوئ او د ستونزې حل کولو لپاره وائی فای وګورئ.
د ملاتړ کارمندانو وړتیا او مسؤلیت
په لویو پروژو کې، شرکتونه د پراختیا کونکو معاشونو کې کمښت نه کوي. دوی د ورته پروژو څخه د ګران منځنۍ یا مشرانو په لټه کې دي. د ملاتړ سره وضعیت یو څه توپیر لري. دوی هڅه کوي له هرې ممکنې لارې دغه لګښتونه کم کړي. شرکتونه ارزانه پرون د Enikey کارګران استخدام کوي او په زړورتیا سره جګړې ته ځي. دا ستراتیژي ممکنه ده که چیرې موږ په زیلینوګراد کې د نبات د سوداګرۍ کارت ویب پاڼې په اړه وغږیږو.
که موږ د لوی آنلاین پلورنځي په اړه وغږیږو ، نو د کم وخت هر ساعت د اینکي مدیر میاشتني معاش څخه ډیر لګښت لري. راځئ چې د پیل ټکي په توګه د کلني تبادلې 1 ملیارد روبله واخلو. دا د درجه بندي څخه د هر آنلاین پلورنځي لږترلږه بدلون دی . دا اندازه په کال کې د ساعتونو په شمیر سره تقسیم کړئ او له 100 روبلو څخه ډیر خالص زیانونه ترلاسه کړئ. او که تاسو د شپې ساعتونه نه حساب کوئ، تاسو کولی شئ په خوندي توګه اندازه دوه برابره کړئ.
مګر پیسې اصلي شی نه دی، سمه ده؟ (نه، البته اصلي شی) د شهرت زیانونه هم شتون لري. د یو مشهور آنلاین پلورنځي سقوط کولی شي په ټولنیزو شبکو کې د بیاکتنې څپې او په موضوعي رسنیو کې خپرونو دواړه لامل شي. او په پخلنځي کې د ملګرو خبرو اترو په سټایل کې "هلته هیڅ شی مه اخلئ ، د دوی ویب پا inه تل ښکته وي" په هیڅ ډول اندازه نشي کیدی.
اوس مسؤلیت ته. زما په عمل کې، داسې قضیه وه کله چې د وظیفې مدیر د سایټ د نه شتون په اړه د څارنې سیسټم څخه خبرتیا ته په وخت ځواب ونه ویل. د جمعې په ماښام د دوبي په خوښۍ سره، په مسکو کې د یو مشهور آنلاین پلورنځي ویب پاڼه په خاموشۍ کې پروت وه. د شنبې په سهار، د دې سایټ د محصول مدیر نه پوهیده چې ولې سایټ نه خلاصیږي، او په سلیک کې د ملاتړ او بیړني خبرتیا چیټونو کې چوپتیا وه. دا ډول تېروتنې موږ ته د شپږو ارقامو لګښت ورکړ، او دا دنده افسر خپله دنده.
مسؤلیت د پراختیا لپاره یو ستونزمن مهارت دی. یا یو څوک لري یا نه. له همدې امله، د مرکو په جریان کې، زه هڅه کوم چې د مختلفو پوښتنو سره د هغې شتون وپیژنم چې په غیر مستقیم ډول وښيي چې ایا یو څوک د مسؤلیت اخیستلو عادت دی. که یو سړی ځواب ووایي چې پوهنتون یې د دې لپاره غوره کړی چې مور او پلار یې ورته وویل یا یې دنده بدله کړه ځکه چې میرمن یې وویل چې کافي عاید نه لري، نو دا به غوره وي چې د داسې خلکو سره ښکیل نه وي.
د پرمختیایي ټیم سره اړیکه
کله چې کاروونکي د عملیاتو په جریان کې د محصول سره ساده ستونزې سره مخ کیږي ، ملاتړ یې پخپله حل کوي. هڅه کوي ستونزه بیا تولید کړي، لاګونه تحلیل کړي، او داسې نور. مګر څه باید وکړو کله چې په محصول کې بګ څرګند شي؟ پدې حالت کې ، ملاتړ پراختیا کونکو ته دنده ګماري او دا هغه ځای دی چې ساتیري پیل کیږي.
پراختیا کونکي په دوامداره توګه ډیریږي. دوی نوي ځانګړتیاوې رامینځته کوي. د پلور سره د کیګونو حل کول خورا په زړه پوري فعالیت ندی. د راتلونکي سپرینټ بشپړولو لپاره نیټې نیټې ته نږدې دي. او بیا د ملاتړ څخه ناخوښه خلک راځي او وايي: "هر څه سمدلاسه پریږدئ، موږ ستونزې لرو." د داسې کارونو لومړیتوب لږ تر لږه دی. په ځانګړي توګه کله چې ستونزه خورا جدي نه وي او د سایټ اصلي فعالیت کار کوي ، او کله چې د خوشې کولو مدیر د سترګو په شاوخوا کې نه ګرځي او لیکي: "په عاجل ډول دا دنده راتلونکي ریلیز یا هاټ فکس ته اضافه کړئ."
د نورمال یا ټیټ لومړیتوب مسلې له خوشې کیدو څخه خوشې کیدو ته لیږدول کیږي. دې پوښتنې ته چې "کار به کله بشپړ شي؟" تاسو به په دې ډول ځوابونه ترلاسه کړئ: "بښنه غواړم، همدا اوس ډیری دندې شتون لري، د خپل ټیم مشرانو څخه پوښتنه وکړئ یا مدیر خوشې کړئ."
د تولید ستونزې د نویو بڼو د جوړولو په پرتله لوړ لومړیتوب لري. بد بیاکتنې به په راتلو کې اوږده نه وي که چیرې کاروونکي په دوامداره توګه د کیګونو سره ټکر وکړي. زیانمن شوی شهرت بیرته راګرځول ستونزمن دي.
د پراختیا او ملاتړ تر مینځ د متقابل عمل مسلې د DevOps لخوا حل کیږي. دا لنډیز اکثرا د یو ځانګړي کس په توګه کارول کیږي چې د پراختیا لپاره د ازموینې چاپیریال رامینځته کولو کې مرسته کوي ، د CICD پایپ لاینونه رامینځته کوي او په چټکۍ سره تولید ته ازمول شوي کوډ راوړي. DevOps د سافټویر پراختیا ته یوه لاره ده کله چې په پروسه کې ټول ګډون کونکي له یو بل سره نږدې اړیکه ونیسي او د سافټویر محصولاتو او خدماتو په چټکۍ سره رامینځته کولو او تازه کولو کې مرسته وکړي. زما مطلب شنونکي، پراختیا کونکي، ازموینه کونکي او ملاتړ دي.
په دې طریقه کې، ملاتړ او پراختیا د خپلو اهدافو او اهدافو سره مختلف څانګې ندي. پراختیا په عملیاتو کې ښکیل ده او برعکس. د توزیع شوي ټیمونو مشهوره جمله: "ستونزه زما په طرف نه ده" نور ډیر ځله په چیټونو کې نه ښکاري، او پای کاروونکي یو څه خوشحاله کیږي.
سرچینه: www.habr.com