ولې انجینران د غوښتنلیک نظارت ته پاملرنه نه کوي؟

جمعه دې ټولو ته مبارک وي! ملګرو، نن ورځ موږ کورس ته وقف شوي خپرونو لړۍ ته دوام ورکوو "DevOps کړنې او وسیلې"ځکه چې د کورس لپاره په نوي ګروپ کې ټولګي به د راتلونکې اونۍ په پای کې پیل شي. نو، راځئ چې پیل وکړو!

ولې انجینران د غوښتنلیک نظارت ته پاملرنه نه کوي؟

څارنه ده یوازې. دا یو پیژندل شوی حقیقت دی. ناګیوس راوړئ، په ریموټ سیسټم کې NRPE چل کړئ، په NRPE TCP پورټ 5666 کې ناګیوس ترتیب کړئ او تاسو څارنه لرئ.

دا دومره اسانه ده چې په زړه پورې نده. اوس تاسو د CPU وخت، ډیسک سبسیسټم، RAM لپاره بنسټیز میټریکونه لرئ، چې د ډیفالټ لخوا ناګیوس او NRPE ته چمتو شوي. مګر دا په حقیقت کې داسې "څارنه" نه ده. دا یوازې پیل دی.

(معمولا دوی PNP4Nagios، RRDtool او Thruk نصبوي، په سلیک کې خبرتیاوې تنظیموي او مستقیم ناجیوس ایکسچینج ته ځي، مګر راځئ چې دا د اوس لپاره پریږدو).

ښه څارنه واقعیا خورا پیچلې ده ، تاسو واقعیا اړتیا لرئ د هغه غوښتنلیک داخلي پیژنئ چې تاسو یې څارئ.

ایا څارنه ستونزمنه ده؟

هر سرور، دا لینوکس یا وینډوز وي، د تعریف له مخې به یو څه هدف پوره کړي. اپاچي، سامبا، ټامکاټ، د فایل ذخیره، LDAP - دا ټول خدمتونه په یو یا ډیرو برخو کې لږ یا لږ ځانګړي دي. هر یو خپل فعالیت لري، خپل ځانګړتیاوې لري. د میټریکونو ترلاسه کولو لپاره مختلفې لارې شتون لري، KPIs (د فعالیت کلیدي شاخصونه)، چې ستاسو لپاره په زړه پورې دي کله چې سرور د بار لاندې وي.

ولې انجینران د غوښتنلیک نظارت ته پاملرنه نه کوي؟
د عکس لیکوال لوک چیسر په خلاصول

(کاش چې زما ډشبورډونه نیون نیلي وای - په خوب کې ژاړي -... هوم...)

هر هغه سافټویر چې خدمتونه وړاندې کوي باید د میټریکونو راټولولو لپاره میکانیزم ولري. اپاچی یو ماډل لري mod-status، د سرور حالت پاڼه ښکاره کول. Nginx لري - stub_status. Tomcat JMX یا دودیز ویب غوښتنلیکونه لري چې کلیدي میټریکونه ښیې. MySQL یو کمانډ لري "نړیوال حالت وښایاست" وغيره.
نو ولې پراختیا کونکي په هغه غوښتنلیکونو کې ورته میکانیزمونه نه رامینځته کوي چې دوی یې رامینځته کوي؟

ایا یوازې پراختیا کونکي دا کوي؟

د میټریک امبیډینګ ته د بې پامۍ یوه ځانګړې کچه د پراختیا کونکو پورې محدوده نه ده. ما په شرکتونو کې کار کړی چیرې چې دوی د Tomcat په کارولو سره غوښتنلیکونه رامینځته کړي او خپل هیڅ میټریکونه ندي چمتو کړي ، د خدماتو فعالیت لاګونه ندي ، پرته د عمومي ټامکاټ خطا لاګونو پرته. ځینې ​​پراختیا کونکي ډیری لاګونه رامینځته کوي چې د سیسټم مدیر ته هیڅ معنی نلري څوک چې د سهار په 3:15 کې لوستلو لپاره کافي بدبخته وي.

ولې انجینران د غوښتنلیک نظارت ته پاملرنه نه کوي؟
د عکس لیکوال ټیم ګو په خلاصول

د سیسټم انجنیران چې د دې ډول محصولاتو خوشې کولو توان لري باید د وضعیت لپاره یو څه مسؤلیت هم په غاړه واخلي. د سیسټمونو لږ شمیر انجینران وخت یا پاملرنه لري چې هڅه وکړي د لاګونو څخه معنی لرونکي میټریکونه استخراج کړي ، پرته لدې چې د دې میټریکونو شرایطو او د غوښتنلیک فعالیت په رڼا کې د دوی تشریح کولو وړتیا. ځینې ​​​​نه پوهیږي چې دوی څنګه له دې څخه ګټه پورته کولی شي، پرته له دې چې "یو څه اوس مهال (یا ډیر ژر به) غلط وي" شاخصونه.

د میټریکونو اړتیا په اړه په فکر کې بدلون باید نه یوازې د پراختیا کونکو تر مینځ ، بلکه د سیسټم انجینرانو ترمینځ هم واقع شي.

د هر سیسټم انجینر لپاره چې اړتیا لري نه یوازې جدي پیښو ته ځواب ووایی ، بلکه دا هم ډاډه کوي چې دوی نه پیښیږي ، د میټریک نشتوالی معمولا د دې کولو لپاره یو خنډ وي.

په هرصورت، د سیسټم انجنیران معمولا د خپل شرکت لپاره پیسې ګټلو لپاره د کوډ سره ټینکر نه کوي. دوی مخکښ پراختیا کونکو ته اړتیا لري چې د ستونزو پیژندلو ، د فعالیت مسلو په اړه د پوهاوي لوړولو او ورته نورو کې د سیسټم انجینر مسؤلیت اهمیت درک کړي.

دا شی له منځه وړي

د ډیوپس ذهنیت د پراختیا (dev) او عملیاتو (ops) فکر ترمنځ همغږي تشریح کوي. هر هغه شرکت چې ادعا کوي د "ډیوپس" کولو ادعا کوي باید:

  1. هغه شیان ویل چې دوی شاید نه وي (د شهزادګۍ ناوې میم ته اشاره کوي - "زه فکر نه کوم چې دا هغه څه معنی لري چې تاسو فکر کوئ دا معنی لري!")
  2. د دوامداره محصول ښه کولو چلند هڅول.

تاسو نشئ کولی محصول ته وده ورکړئ او پوه شئ چې دا ښه شوی که تاسو نه پوهیږئ دا اوس څنګه کار کوي. تاسو نه پوهیږئ چې محصول څنګه کار کوي که تاسو نه پوهیږئ چې د هغې برخې څنګه کار کوي، هغه خدمات چې دا پورې اړه لري، د درد اصلي ټکي او خنډونه.
که تاسو د احتمالي خنډونو لپاره ونه ګورئ، نو تاسو به د پوسټ مارټم لیکلو په وخت کې د پنځو ولې تخنیک تعقیب نه کړئ. تاسو به نشئ کولی هرڅه په یوه سکرین کې واچوئ ترڅو وګورئ چې محصول څنګه کار کوي یا پوه شئ چې دا د "عادي او خوښ" په څیر څه ښکاري.

کیڼ لور ته واړوه، ما وویل لیی-

زما لپاره ، د دیوپس یو له کلیدي اصولو څخه "کیڼ اړخ ته بدلون" دی. په دې شرایطو کې پریښودل د امکان بدلول معنی لري (هیڅ مسؤلیت نشته، مګر یوازې وړتیاوې) د هغه شیانو ترسره کولو لپاره چې د سیسټم انجینران عموما ورته پاملرنه کوي ، لکه د فعالیت میټریک رامینځته کول ، د لاګونو کارول په ډیر مؤثره توګه ، او داسې نور.

ولې انجینران د غوښتنلیک نظارت ته پاملرنه نه کوي؟
د عکس لیکوال NESA د جوړونکو لخوا په خلاصول

د سافټویر پراختیا کونکي باید د دې وړتیا ولري چې د څارنې وسیلې وکاروي او پوه شي چې شرکت یې په ټولو ډولونو ، میټریکونو ، لاګنګ ، نظارت انٹرفیسونو او خورا مهم کې د څارنې ترسره کولو لپاره کاروي. وګورئ چې څنګه د دوی محصول په تولید کې کار کوي. تاسو نشئ کولی پراختیا کونکي په نظارت کې هڅې او وخت پانګونه وکړي تر هغه چې دوی میټریکونه وګوري او اغیزه وکړي چې دوی څنګه ګوري ، د محصول مالک څنګه دوی په راتلونکي لنډیز کې CTO ته وړاندې کوي ، او داسې نور.

په لنډ ډول خبرې کول

  1. خپل آس اوبو ته رهبري کړئ. پراختیا کونکو ته وښایاست چې دوی د ځان لپاره څومره ستونزې لرې کولی شي ، له دوی سره د دوی غوښتنلیکونو لپاره سم KPIs او میټریکونو پیژندلو کې مرسته وکړي ترڅو د محصول مالک څخه لږ چیغې وي چې د CTO لخوا ورته ویل کیږي. دوی په نرمۍ او آرامۍ سره رڼا ته راوړئ. که دا کار ونکړي، نو بیا دوی یا د محصول مالک ته رشوت ورکړئ، ګواښ کړئ او کاجول وکړئ ترڅو ژر تر ژره د غوښتنلیکونو څخه دا میټریکونه ترلاسه کړي، او بیا ډیاګرام رسم کړئ. دا به ستونزمن وي ځکه چې دا به د لومړیتوب په توګه ونه لیدل شي او د محصول سړک نقشه به د عاید تولید ډیری پروژې پاتې وي. له همدې امله، تاسو به د سوداګرۍ قضیې ته اړتیا ولرئ ترڅو د محصول د څارنې پلي کولو لپاره مصرف شوي وخت او لګښت توجیه کړي.
  2. د سیسټم انجینرانو سره د شپې ښه خوب کولو کې مرسته وکړئ. دوی ته وښایاست چې د هر محصول خوشې کولو لپاره د "راځئ خوشې کړئ" چک لیست کارول یو ښه شی دی. او ډاډ ترلاسه کول چې په تولید کې ټول غوښتنلیکونه د میټریکونو سره پوښل شوي به تاسو سره د شپې په ښه خوب کې مرسته وکړي ترڅو پراختیا کونکو ته اجازه ورکړي چې وګوري څه غلط کیږي او چیرې. په هرصورت، د هر پراختیا کونکي، د محصول مالک، یا CTO د خپګان او مایوس کولو سمه لاره دوام او مقاومت دی. دا چلند به د هر محصول د خوشې کولو نیټه اغیزه وکړي که تاسو بیا تر وروستۍ دقیقې پورې انتظار وکړئ، نو بیا کیڼ لور ته واړوئ او دا مسلې ژر تر ژره ستاسو د پروژې پلان کې ترلاسه کړئ. که اړتیا وي، د محصول غونډو ته لاره پیدا کړئ. جعلي برچه واغوندئ او احساس وکړئ یا یو څه ، دا به هیڅکله ناکام نشي. خپلې اندیښنې شریک کړئ، روښانه ګټې وښایئ، او تبلیغ وکړئ.
  3. ډاډ ترلاسه کړئ چې دواړه پراختیا (dev) او عملیات (ops) د محصول میټریکونو په معنی او پایله پوهیږي چې سور زون ته حرکت کوي. Ops د محصول روغتیا یوازینۍ ساتونکي په توګه مه پریږدئ، ډاډ ترلاسه کړئ چې پراختیا کونکي هم دخیل دي (#productsquads).
  4. لاګز یو ښه شی دی، مګر میټریکونه هم دي. دوی سره یوځای کړئ او مه پریږدئ چې ستاسو لاګونه د بیکارۍ په لوی سوځیدونکي بال کې کثافات شي. پراختیا کونکو ته تشریح کړئ او وښایاست چې ولې بل څوک به د دوی لاګونه نه پوهیږي، دوی ته وښایاست چې د سهار په 3:15 کې بې ګټې لاګونو ته کتل څه ډول دي.

ولې انجینران د غوښتنلیک نظارت ته پاملرنه نه کوي؟
د عکس لیکوال مارکو هوروات په خلاصول

بس نور څه نه. نوي مواد به راتلونکې اونۍ خپاره شي. که تاسو غواړئ د کورس په اړه نور معلومات زده کړئ، موږ تاسو ته بلنه درکوو د خلاصون ورځ، چې د دوشنبې په ورځ به ترسره شي. او اوس موږ په دودیز ډول ستاسو نظرونو ته انتظار یو.

سرچینه: www.habr.com

Add a comment