ګډوډي انجینري: د قصدي ویجاړولو هنر. 2 برخه

نوټ. ژباړه: دا مقاله د AWS ټیکنالوژۍ انجیل اډرین هورنسبي څخه د مقالو عالي لړۍ ته دوام ورکوي ، څوک چې په ساده او روښانه ډول د IT سیسټمونو کې د ناکامیو پایلو کمولو لپاره د تجربې اهمیت تشریح کوي.

"که تاسو د پلان په چمتو کولو کې پاتې راغلي، نو تاسو د ناکامۍ پلان لرئ." - بنیامین فرانکلین

В لومړی برخه د مقالو په دې لړۍ کې، ما د ګډوډ انجینرۍ مفهوم معرفي کړ او تشریح یې کړه چې دا څنګه په سیسټم کې د نیمګړتیاو موندلو او سمولو کې مرسته کوي مخکې لدې چې دوی د تولید ناکامۍ لامل شي. دې په دې هم بحث وکړ چې څنګه ګډوډي انجینري په سازمانونو کې مثبت کلتوري بدلون ته وده ورکوي.

د لومړۍ برخې په پای کې، ما ژمنه وکړه چې "په سیسټمونو کې د ناکامۍ معرفي کولو لپاره د وسیلو او میتودونو" په اړه وغږیږم. افسوس، زما سر په دې اړه خپل پلانونه درلودل، او په دې مقاله کې به زه هڅه وکړم چې ترټولو مشهوره پوښتنې ته ځواب ووایم چې د خلکو په منځ کې راپورته کیږي چې غواړي ګډوډي انجینري ته لاړ شي: لومړی څه مات کړئ؟

عالي پوښتنه! په هرصورت ، داسې نه بریښي چې هغه په ​​ځانګړي ډول د دې پانډا لخوا ځوریدلی وي ...

د ګډوډ پانډا سره ګډوډي مه کوئ!

لنډ ځواب: د غوښتنې په لاره کې مهم خدمتونه په نښه کړئ.

اوږد مګر روښانه ځواب: د دې لپاره چې پوه شئ له کوم ځای څخه د ګډوډۍ تجربه پیل کړئ، دریو برخو ته پام وکړئ:

1. وګوره د حادثې تاریخ او نمونې وپیژني
2. پریکړه وکړئ انتقادي انحصار;
3. د تش په نامه کارول د ډیر باور اغیز.

دا مسخره ده، مګر دا برخه په اسانۍ سره ویل کیدی شي "د ځان موندنې او روښانتیا لپاره سفر". په دې کې به موږ د ځینې ښایسته وسیلو سره "لوبې" پیل کړو.

1. ځواب په تیرو کې دی

که تاسو په یاد ولرئ، په لومړۍ برخه کې ما د تېروتنې د سمون (COE) مفهوم معرفي کړ - هغه طریقه چې موږ یې په ټیکنالوژۍ، پروسې یا سازمان کې خپلې تېروتنې تحلیل کوو - د دې لپاره چې د دوی لاملونه وپیژنو او مخنیوی وکړو. په راتلونکي کې تکرار په عمومي توګه، دا هغه ځای دی چې تاسو باید پیل کړئ.

"د اوسني پوهیدو لپاره، تاسو اړتیا لرئ چې تیر وپیژنئ." – کارل ساګن

د ناکامیو تاریخ وګورئ، په COE یا پوسټ مارټم کې یې ولیکئ او طبقه بندي یې کړئ. عام نمونې په ګوته کړئ چې ډیری وختونه ستونزې رامینځته کوي، او د هر COE لپاره، له ځانه لاندې پوښتنه وکړئ:

"آیا دا وړاندوینه شوې وه او له همدې امله د غلط انجیکشن لخوا مخنیوی کیدی شي؟"

زه د خپل مسلک په پیل کې یوه ناکامي یادوم. دا په اسانۍ سره مخنیوی کیدی شي که چیرې موږ یو څو ساده ګډوډي تجربې ترسره کړې وای:

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

په هرصورت، هرڅه د یو څه وخت لپاره سم وو.

بیا، دمخه د فشار لرونکي شرایطو لاندې، یو له هغو مواردو څخه چې د غیر مهم، منظم ETL کرون دندې اجرا کول پیل کړل. د لوړ ترافیک او کرونجوب ترکیب د CPU کارول نږدې 100٪ ته اړولي. د CPU اوورلوډ د روغتیا چکونو ته ځوابونه نور هم ورو کړل، تر دې چې ELB پریکړه وکړه چې مثال د فعالیت ستونزې تجربه کوي. لکه څنګه چې تمه کیده، بیلانسر دې ته د ټرافیک توزیع بنده کړه، کوم چې په پایله کې، په ګروپ کې په پاتې مواردو کې د بار زیاتوالي المل شو.

ناڅاپه، نورې ټولې پیښې هم د روغتیا معاینه ناکامي پیل کړه.

د نوي مثال پیل کول د کڅوړو ډاونلوډ او نصبولو ته اړتیا لري او د ELB په پرتله خورا ډیر وخت نیولی ترڅو دوی غیر فعال کړي - یو په یو - په اتوماتیک ګروپ کې. دا څرګنده ده چې ډیر ژر ټوله پروسه یو مهم پړاو ته ورسیده او غوښتنلیک خراب شو.

بیا موږ د تل لپاره لاندې ټکي درک کړل:

• د سافټویر نصب کول کله چې د نوي مثال رامینځته کول ډیر وخت نیسي؛ دا غوره ده چې بدلیدونکي چلند ته لومړیتوب ورکړئ او گولډن AMI.
• په پیچلو حاالتو کې، د روغتیا معاینې او ELBs ته ځوابونه باید لومړیتوب ولري - وروستی شی چې تاسو یې غواړئ د پاتې پیښو لپاره ژوند پیچلی کړئ.
• د روغتیایی چکونو ځایی کیچ کول ډیره مرسته کوي (حتی د څو ثانیو لپاره).
• په ستونزمن حالت کې، د کرون دندې او نور غیر مهم پروسې مه کوئ - د خورا مهم کارونو لپاره سرچینې خوندي کړئ.
• کله چې اتوماتیک کول، کوچني مثالونه وکاروئ. د 10 کوچنیو نمونو یوه ډله د 4 لویو نمونو څخه غوره ده؛ که یوه بیلګه ناکامه شي، په لومړي حالت کې به د ټرافیک 10٪ په 9 نقطو ویشل شي، په دویمه کې - 25٪ ټرافیک په دریو ټکو کې.

او همداسې، ایا دا وړاندوینه شوې وه، او له همدې امله د ستونزې په معرفي کولو سره مخنیوی شوی؟

چې، او په څو لارو کې.

لومړی، د وسیلو په کارولو سره د لوړ CPU کارولو سمولو له لارې لکه stress-ng او یا cpuburn:

❯ stress-ng --matrix 1 -t 60s

فشار- ng

دوهم، د مثال په زیاتولو سره wrk او ورته نورې اسانتیاوې:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

تجربې نسبتا ساده دي، مګر کولی شي د فکر لپاره یو څه ښه خواړه چمتو کړي پرته له دې چې د ریښتینې ناکامۍ فشار ته لاړ شي.

په هرصورت، هلته مه درېږه. هڅه وکړئ حادثه د ازموینې چاپیریال کې بیا تولید کړئ او پوښتنې ته خپل ځواب وګورئ "ایا دا وړاندوینه شوې وه او له همدې امله د غلطۍ په معرفي کولو سره مخنیوی کیدی شي؟" دا د انګیرنې ازموینې لپاره د ګډوډي تجربې دننه د کوچني ګډوډي تجربه ده ، مګر د ناکامۍ سره پیل کیږي.

ایا دا یو خوب و، یا دا واقعا واقع شو؟

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

بیا د لوی رینج سره خورا عام نمونو ته لاړشئ.

2. د انحصار نقشه جوړه کړئ

د خپل غوښتنلیک په اړه فکر کولو لپاره یوه شیبه واخلئ. ایا د دې انحصار روښانه نقشه شتون لري؟ ایا تاسو پوهیږئ چې د ناکامۍ په صورت کې به دوی څه اغیزه ولري؟

که تاسو د خپل اپلیکیشن کوډ سره ډیر آشنا نه یاست یا دا خورا لوی شوی ، نو دا به ستونزمن وي چې پوه شئ چې کوډ څه کوي او د هغې انحصار څه دی. د دې انحصاراتو پوهیدل او په غوښتنلیک او کاروونکو باندې د دوی احتمالي اغیزې پوهیدل د دې لپاره خورا مهم دي چې پوه شي چیرې د ګډوډي انجینرۍ سره پیل شي: د پیل نقطه هغه برخه ده چې د خورا لوی تاثیر وړ وړانګې لري.

د انحصارونو پیژندلو او مستند کولو ته ویل کیږي "د انحصار نقشه جوړول» (د انحصار نقشه کول). دا عموما د کوډ پروفایل کولو وسیلو په کارولو سره د لوی کوډ بیس سره غوښتنلیکونو لپاره ترسره کیږي. (د کوډ پروفایل کول) او وسیلې (آلې). تاسو کولی شئ د شبکې ترافیک نظارت کولو سره نقشه هم جوړه کړئ.

په هرصورت، ټول انحصارونه یو شان ندي (کوم چې پروسه نوره هم پیچلې کوي). ځینې انتقادينور - ثانوي (لږترلږه په تیوري کې، ځکه چې حادثې اکثرا د انحصارونو سره د ستونزو له امله پیښیږي چې غیر مهم ګڼل کیږي).

د جدي انحصار پرته، خدمت نشي کولی کار وکړي. غیر جدي انحصار "نه باید» د سقوط په صورت کې د خدماتو اغیزمن کول. د انحصاراتو د پوهیدو لپاره، تاسو اړتیا لرئ د APIs روښانه پوهه ولرئ چې ستاسو د غوښتنلیک لخوا کارول کیږي. دا د دې په پرتله خورا ډیر ستونزمن کیدی شي - لږترلږه د لوی غوښتنلیکونو لپاره.

د ټولو APIs له لارې پیل کړئ. ډیری یې روښانه کړئ مهم او مهم. واخله د د کوډ ذخیره څخه، دا وګورئ د پیوستون لاګ، بیا وګورئ اسناد (البته، که دا شتون ولري - که نه نو تاسو لاهم لرئоلویې ستونزې). د وسایلو څخه کار واخلئ پروفایل کول او تعقیب کول، بهرنۍ زنګونه فلټر کړئ.

تاسو کولی شئ داسې پروګرامونه وکاروئ netstat - د کمانډ لاین یوټیلیټ چې په سیسټم کې د ټولو شبکې اتصالونو (فعال ساکټونو) لیست ښیې. د مثال په توګه، د ټولو اوسنیو اړیکو لیست کولو لپاره، ټایپ کړئ:

❯ netstat -a | more 

په AWS کې تاسو کارولی شئ جریان log VPC یو میتود دی چې تاسو ته اجازه درکوي د IP ترافیک په اړه معلومات راټول کړئ چې په VPC کې د شبکې انٹرفیس ته ځي یا راځي. دا ډول لاګونه کولی شي د نورو کارونو سره هم مرسته وکړي - د بیلګې په توګه، د دې پوښتنې ځواب موندل چې ولې ځینې ټرافیک مثال ته نه رسیږي.

تاسو هم کارولی شئ AWS X-ray. ایکس رے تاسو ته اجازه درکوي تفصيلي، "حتمی" ترلاسه کړئ (نور بس دی) د غوښتنو عمومي کتنه لکه څنګه چې دوی د غوښتنلیک له لارې حرکت کوي، او همدارنګه د غوښتنلیک د اصلي برخو نقشه جوړوي. خورا اسانه که تاسو اړتیا لرئ د انحصار پیژندلو ته اړتیا ولرئ.

د AWS ایکس ری کنسول

د شبکې انحصار نقشه یوازې یو اړخیز حل دی. هو، دا ښیې چې کوم غوښتنلیک له کوم سره اړیکه لري، مګر نور انحصارونه شتون لري.

ډیری غوښتنلیکونه د انحصارونو سره وصل کیدو لپاره DNS کاروي ، پداسې حال کې چې نور ممکن د خدماتو کشف یا حتی د تنظیم کولو فایلونو کې سخت کوډ شوي IP پتې وکاروي (د مثال په توګه /etc/hosts).

د مثال په توګه، تاسو کولی شئ جوړ کړئ د DNS بلیک هول له لارې iptables او وګورئ چې څه ماتیږي. د دې کولو لپاره، لاندې کمانډ دننه کړئ:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

د DNS تور سوراخ

که په /etc/hosts یا د نورو ترتیباتو فایلونو سره، تاسو به د IP پتې ومومئ چې تاسو یې په اړه هیڅ نه پوهیږئ (هو، له بده مرغه، دا هم پیښیږي)، تاسو کولی شئ بیا د ژغورنې لپاره راشي. iptables. راځئ چې ووایو تاسو کشف کړی 8.8.8.8 او نه پوهیږم چې دا د ګوګل عامه DNS سرور پته ده. په کارولو iptables تاسو کولی شئ د لاندې کمانډونو په کارولو سره دې پتې ته د راتلو او وتلو ترافیک بند کړئ:

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

د لاسرسي بندول

لومړی قاعده د ګوګل د عامه DNS څخه ټول پاکټونه پریږدي: ping کار کوي، مګر پاکټونه بیرته نه راځي. دوهم قاعده ټول پاکټونه ستاسو د سیسټم څخه د ګوګل عامه DNS په لور راوباسي - په ځواب کې ping موږ ترلاسه کوو د عملیاتو اجازه نشته.

یادونه: پدې ځانګړي حالت کې دا به غوره وي چې وکاروئ whois 8.8.8.8، مګر دا یوازې یو مثال دی.

موږ کولی شو د خرگوش سوري ته حتی ژور لاړ شو، ځکه چې هرڅه چې TCP او UDP کاروي په حقیقت کې په IP پورې اړه لري. په ډیرو مواردو کې، IP د ARP سره تړلی دی. د اور وژنې په اړه مه هېروئ ...

که تاسو سور ګولۍ وخورئ، تاسو په وندرلینډ کې پاتې شئ، او زه به تاسو ته وښیم چې د خرگوش سوری څومره ژور دی."

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

د انحصار نقشه جوړول اکثرا یو ډیر اوږد کار دی. ما پدې وروستیو کې د یو پیرودونکي سره خبرې وکړې چې نږدې 2 کاله یې د یوې وسیلې رامینځته کولو کې تیر کړل چې په نیمه اتوماتیک ډول د سلګونو مایکرو خدماتو او امرونو لپاره د انحصار نقشې رامینځته کوي.

په هرصورت، پایله خورا په زړه پورې او ګټوره ده. تاسو به د خپل سیسټم، د هغې د انحصار او عملیاتو په اړه ډیر څه زده کړئ. یوځل بیا، صبر وکړئ: دا پخپله سفر دی چې خورا مهم دی.

3. د ډیر باور څخه ځان وساتئ

"څوک چې د څه خوب ویني، په هغه باور لري." – ډیموستینیز

ایا تاسو کله هم اوریدلي دي د ډیر باور اغیز?

د ویکیپیډیا په وینا، د ډیر باور اغیز "یو ادراکي تعصب دی چې په هغه کې د یو شخص باور د دوی په کړنو او پریکړو کې د دې قضاوتونو د هدف دقت څخه خورا ډیر دی، په ځانګړې توګه کله چې د باور کچه نسبتا لوړه وي."

د جبلت او تجربې پر بنسټ ...

زما په تجربه کې، دا تحریف یو ښه اشاره ده چې د ګډوډ انجینرۍ سره چیرته پیل شي.

د ډیر باوري چلونکي څخه ځان وساتئ:

چارلي: "دا شی په پنځو کلونو کې نه دی راوتلی، هرڅه سم دي!"
حادثه: "انتظار ... زه به ژر هلته ځم!"

د ډیر باور په پایله کې تعصب یو خطرناک او حتی خطرناک شی دی چې د مختلفو عواملو له امله چې دا اغیزه کوي. دا په ځانګړې توګه ریښتیا ده کله چې د ټیم غړو خپل زړونه په ټیکنالوژۍ کې اچولي وي یا ډیر وخت یې په "فکس کولو" کې تیر کړی وي.

لنډیز

د ګډوډۍ انجینرۍ لپاره د پیل ټکي لټون تل د تمې څخه ډیرې پایلې راوړي ، او هغه ټیمونه چې ډیر ګړندي شیان ماتوي د (افراتفري) ډیر نړیوال او په زړه پوري جوهر له لاسه ورکوي.انجینری - تخلیقي کارول ساینسي میتودونه и تجربوي شواهد د (سافټویر) سیسټمونو ډیزاین، پراختیا، عملیات، ساتنې او ښه کولو لپاره.

دا دویمه برخه پای ته رسوي. مهرباني وکړئ بیاکتنې ولیکئ، نظرونه شریک کړئ یا یوازې خپل لاسونه ولیکئ منځني. په راتلونکې برخه کې زه رښتیا زه به په سیسټمونو کې د ناکامیو معرفي کولو لپاره وسیلې او میتودونه په پام کې ونیسم. تر څو!

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

• «ګډوډي انجینري: د قصدي ویجاړولو هنر. 1 برخه»
• «په Kubernetes کې د لوړ شتون ترلاسه کولو څرنګوالی»
• «څارنه او کبرنیټس (بیاکتنه او ویډیو راپور)»
• «په Kubernetes کې د کیوب پراکسي او نوډ نه شتون سره تجربه کول".

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