نوټ. ژباړه: د دې موادو لیکوال سنډي سریداران دی، په imgix کې انجینر چې د API پراختیا او په ځانګړي توګه د مایکرو سرویس ازموینې کې تخصص لري. په دې موادو کې، هغه د ویشل شوي تعقیب په برخه کې د اوسنیو ستونزو په اړه خپل مفصل لید شریکوي، چیرې چې د هغې په اند، د فشار د ستونزو د حل لپاره د ریښتینې اغیزمنو وسیلو نشتوالی شتون لري.
[ له انځور څخه اخیستل شوی د توزیع شوي تعقیب په اړه.]
داسې ویل کیږي چې پلي کول ستونزمن دي، او بیرته راستنیدل . ډیری دلیلونه شتون لري چې ولې تعقیب ستونزمن دی، ډیری وختونه د هرې غوښتنې سره د مناسب سرلیکونو لیږدولو لپاره د سیسټم د هرې برخې په ترتیب کولو کې ښکیل کار ته اشاره کوي. که څه هم دا ستونزه شتون لري، دا په هیڅ ډول د حل وړ نه ده. په لاره کې، دا نه تشریح کوي چې ولې پراختیا کونکي واقعیا تعقیب نه خوښوي (حتی کله چې دا دمخه کار کوي).
د توزیع شوي تعقیب سره اصلي ننګونه د معلوماتو راټولول ، د پایلو توزیع او وړاندې کولو لپاره د فارمیټونو معیاري کول ، یا دا مشخص کول چې کله ، چیرې ، او څنګه نمونه وي. زه د تصور کولو هڅه نه کوم وړه دا "د پوهیدو ستونزې" په حقیقت کې خورا مهم تخنیکي دي او (که موږ واقعیا خلاصې سرچینې په پام کې ونیسو) ) سیاسي ننګونې چې د دې ستونزو د حل کولو لپاره باید بریالي شي.
په هرصورت، که موږ تصور وکړو چې دا ټولې ستونزې حل شوي، نو ډیر احتمال شتون لري چې هیڅ شی به په شرایطو کې د پام وړ بدلون ومومي. د کارونکي پای تجربه. تعقیب ممکن لاهم د ډیبګ کولو خورا عام سناریو کې عملي کار نه وي — حتی وروسته له دې چې ځای په ځای شوی وي.
دا ډول مختلف نښې
توزیع شوي تعقیب کې ډیری متفاوت برخې شاملې دي:
- د کنټرول وسیلو سره د غوښتنلیکونو او مینځنیو وسایلو سمبالول؛
- د توزیع شوي شرایطو لیږد؛
- د نښو ټولګه؛
- ټریس ذخیره کول
- د دوی استخراج او لید.
د توزیع شوي تعقیب په اړه ډیری خبرې دا د یو ډول غیر منظم عملیاتو په توګه چلند کوي چې یوازینی هدف یې د سیسټم بشپړ تشخیص کې مرسته کول دي. دا په لویه کچه د دې له امله دی چې څنګه د توزیع شوي تعقیب په اړه نظرونه په تاریخي ډول رامینځته شوي. IN ، کله چې د زپکین سرچینې خلاصې شوې ، دا یادونه شوې دا [زپکین] ټویټر ګړندی کوي. د تعقیب لپاره لومړی سوداګریز وړاندیزونه هم په توګه هڅول شوي .
نوټ. ژباړه: د دې لپاره چې نور متن په اسانۍ پوه شي، راځئ چې دوه بنسټیز اصطلاحات تعریف کړو :
- Span - د توزیع شوي تعقیب بنسټیز عنصر. دا د یو ځانګړي کاري فلو توضیح دی (د مثال په توګه ، د ډیټابیس پوښتنې) د نوم ، پیل او پای وختونو ، ټاګونو ، لاګونو او شرایطو سره.
- سپانونه عموما د نورو سپنونو سره اړیکې لري، څو څو سپانونو ته اجازه ورکوي چې یوځای شي ټریس - د غوښتنې ژوند لید لکه څنګه چې دا د توزیع شوي سیسټم له لارې حرکت کوي.
ټریسونه په زړه پورې ارزښتناکه ډیټا لري چې کولی شي د دندو سره مرسته وکړي لکه د تولید ازموینه ، د ناورین بیا رغونه ازموینه ، د غلط انجیکشن ازموینه ، او داسې نور. په حقیقت کې ، ځینې شرکتونه دمخه د ورته موخو لپاره تعقیب کاروي. راځئ چې پیل وکړو د ذخیره کولو سیسټم ته د سپانونو حرکت کولو سربیره نورې کارونې لري:
- د مثال په توګه، Uber د ټیسټ ترافیک او تولید ترافیک ترمینځ توپیر لپاره د پایلو تعقیب کول.
- فیسبوک د ناورین د بیا رغونې منظم ازموینې په جریان کې د جدي لارې تحلیل او د ترافیک بدلولو لپاره ډیټا تعقیب کړئ.
- همدارنګه ټولنیز شبکه د جوپېټر نوټ بوکونه چې پراختیا کونکو ته اجازه ورکوي د ټریس پایلو په اړه خپلمنځي پوښتنې پرمخ وړي.
- پیروان (د نسب چلول ناکامي انجکشن) د غلطۍ انجیکشن سره د ازموینې لپاره توزیع شوي نښې.
پورته لیست شوي هیڅ یو اختیار په بشپړ ډول سناریو ته نه پلي کیږي ډیبګ، چې په جریان کې انجینر هڅه کوي د ټریس په لیدو سره ستونزه حل کړي.
کله چې راځي تراوسه د ډیبګ کولو سکریپټ ته رسي ، لومړني انٹرفیس ډیاګرام پاتې کیږي traceview (که څه هم ځینې یې دا هم بولي "ګانټ چارټ" او یا "د آبشار انځور"). لاندې traceview я ټول سپانونه او ورسره مل میټاډاټا چې یوځای ټریس جوړوي. د خلاصې سرچینې تعقیب سیسټم ، په بیله بیا د هر سوداګریز تعقیب حل وړاندیز کوي a traceview د لید لید ، توضیحاتو او فلټر کولو نښو لپاره د کارن انٹرفیس.
د ټولو تعقیب سیسټمونو سره ستونزه چې ما تر دې دمه لیدلې هغه پایله ده لید لید (د لید لید) تقریبا په بشپړه توګه د ټریس تولید پروسې ځانګړتیاوې منعکس کوي. حتی کله چې بدیل لید وړاندیز کیږي: د تودوخې نقشه ، د خدماتو توپولوژی ، د ځنډ هسټوګرامونه ، دوی لاهم په نهایت کې ښکته راځي traceview.
په تیرو وختونو کې I چې په UI/UX تعقیب کې ډیری "نوښتونه" داسې ښکاري چې محدود وي په ټریس کې اضافي میټاډاټا، په دوی کې د لوړ کارډینالیټي معلوماتو سره پانګه اچونه (لوړ شخصیت) یا د ځانګړو سپینو یا چلولو پوښتنو ته د ډرل کولو وړتیا چمتو کول انټر- او انټر ټریس... په کوم کې traceview د لید اصلي وسیله پاتې کیږي. تر هغه چې دا حالت دوام ومومي، توزیع شوي تعقیب به (په غوره توګه) د ډیبګ کولو وسیلې په توګه څلورم ځای ونیسي، د میټریکونو، لاګونو او سټیک ټریسونو وروسته، او په بدترین ډول به د پیسو او وخت ضایع کول وي.
د Traceview سره ستونزه
موخه traceview - د ویشل شوي سیسټم په ټولو برخو کې د یوې غوښتنې حرکت بشپړ انځور چمتو کړئ چې دا ورسره تړاو لري. ځینې نور پرمختللي ټریسینګ سیسټمونه تاسو ته اجازه درکوي په انفرادي سپانونو کې ډرل کړئ او د وخت په تیریدو سره خرابي وګورئ دننه یوه پروسه (کله چې سپان فعال حدود ولري).
د مایکرو خدماتو جوړښت بنسټیز اساس دا نظر دی چې سازماني جوړښت د شرکت اړتیاو سره وده کوي. د مایکرو خدماتو پلویان استدلال کوي چې په انفرادي خدماتو کې د مختلف سوداګریزو دندو ویش کول کوچني، خپلواکه پراختیایی ټیمونو ته اجازه ورکوي چې د ورته خدماتو ټول ژوند کنټرول کړي، دوی ته دا وړتیا ورکوي چې په خپلواکه توګه دا خدمتونه جوړ کړي، ازموینه وکړي او ځای پرځای کړي. په هرصورت، د دې ویش نیمګړتیا د معلوماتو له لاسه ورکول دي چې څنګه هر خدمت د نورو سره تعامل کوي. په داسې شرایطو کې ، توزیع شوي تعقیب ادعا کوي چې د دې لپاره لازمي وسیله ده ډیبګ د خدماتو ترمنځ پیچلې تعامل.
که تاسو واقعیا نو بیا هیڅ یو سړی نشي کولی دا په خپل سر کې وساتي بشپړ انځور په حقیقت کې، د یوې وسیلې رامینځته کول د انګیرنې پراساس چې دا حتی ممکنه ده د ضد نمونې یو څه دی (یو غیر مؤثر او غیر ګټور چلند). په عین حال کې، ډیبګ کول داسې وسیله ته اړتیا لري چې مرسته کوي ستاسو د لټون ساحه محدوده کړئد دې لپاره چې انجینران وکولی شي د ابعادو (خدمتونو/کاروونکي/میزبان او داسې نور) باندې تمرکز وکړي چې د ستونزې سناریو پورې اړوند وي. کله چې د ناکامۍ لامل وټاکئ، انجنیرانو ته اړتیا نشته چې پوه شي چې په جریان کې څه پیښ شوي ټول خدمات په یو وخت، ځکه چې دا ډول اړتیا به د مایکرو سرویس معمارۍ خورا مفکورې سره مخالفت وکړي.
په هرصورت، Traceview ده په دا. هو، د ټریسنګ ځینې سیسټمونه فشار شوي ټریس ویو وړاندیز کوي کله چې په ټریس کې د سپینو شمیر دومره لوی وي چې دوی نشي کولی په یوه لید کې ښودل شي. په هرصورت، د ډیرو معلوماتو له امله چې حتی په داسې پټ شوي لید کې شتون لري، انجنیران لاهم مجبور دا "چاپ" کړئ، په لاسي ډول انتخاب د خدماتو یوې سیټ ته محدودوي چې د ستونزو سرچینې دي. له بده مرغه، په دې برخه کې، ماشینونه د انسانانو په پرتله خورا ګړندي دي، د غلطیو لپاره لږ خطر لري، او د دوی پایلې ډیر تکرار وړ دي.
بل دلیل چې زه فکر کوم ټریس ویو غلط دی ځکه چې دا د فرضیې لخوا پرمخ وړل شوي ډیبګ کولو لپاره ښه ندي. په اصل کې، ډیبګ کول دي تکراري یوه پروسه چې د فرضیې سره پیل کیږي، وروسته بیا د سیسټم څخه د بیلابیلو ویکتورونو، پایلو/عمومي کولو او د فرضیې د حقیقت نور ارزونه سره د مختلفو مشاهدو او حقایقو تصدیق کول.
فرصت چټک او ارزانه د فرضیو ازموینه او د هغې مطابق ذهني ماډل ته وده ورکول دي د بنسټ ډبره ډیبګ کول هر ډول debugging وسیله باید وي متقابل او د لټون ځای محدود کړئ یا د غلط لیډ په حالت کې، کارونکي ته اجازه ورکړئ چې بیرته لاړ شي او د سیسټم په مختلف ساحه تمرکز وکړي. کامل وسیله به دا کار وکړي په فعاله توګه، سمدلاسه د احتمالي ستونزو ساحو ته د کارونکي پام راجلبوي.
افسوس، traceview د متقابل انٹرفیس سره وسیله نشي ویل کیدی. ترټولو غوره چې تاسو یې د کارولو په وخت کې تمه کولی شئ د زیاتوالي ځنډ ځینې سرچینې ومومئ او د دې سره تړلي ټول ممکنه ټاګونه او لاګونه وګورئ. دا د انجنیر سره د پیژندلو کې مرسته نه کوي نمونې په ټرافیک کې، لکه د ځنډ ویش ځانګړتیاوې، یا د مختلف اندازه کولو ترمنځ ارتباط کشف کړئ. کیدای شي د دې ځینو ستونزو په حل کې مرسته وکړي. رښتیا، د ماشین زده کړې په کارولو سره بریالي تحلیلونه د غیر معمولي سپینو پیژندلو او د ټګونو فرعي سیټ پیژندلو لپاره چې ممکن د غیر معمولي چلند سره تړاو ولري. په هرصورت، ما تر اوسه د ماشین زده کړې یا د ډیټا کان کیندنې موندنو په اړه زړه راښکونکي لیدونه لیدلي چې په سپانونو کې پلي شوي چې د ټریس ویو یا DAG (هدایت شوي اسیلیک ګراف) څخه د پام وړ توپیر لري.
سپان خورا ټیټ دی
د Traceview سره بنسټیزه ستونزه دا ده سپین دواړه د ځنډ تحلیل او د اصلي لامل تحلیل لپاره خورا ټیټې کچې لومړني دي. دا د انفرادي پروسیسر قوماندې پارس کولو په څیر دی چې د استثنا د حل کولو هڅه وکړي ، پدې پوهیدل چې د بیکټریس په څیر خورا لوړې کچې وسیلې شتون لري چې د کار کولو لپاره خورا اسانه دي.
سربیره پردې ، زه به د لاندې ادعا کولو آزادي واخلم: په مثالي توګه ، موږ اړتیا نلرو بشپړ انځور د غوښتنې د ژوند دورې په جریان کې پیښ شوي ، کوم چې د عصري تعقیب وسیلو لخوا نمایش کیږي. پرځای یې، د لوړې کچې خلاصون ځینې ډولونه اړین دي چې د هغه څه په اړه معلومات لري غلط شو (د بیکټریس سره ورته)، د ځینو شرایطو سره. د دې پرځای چې ټول ټریس وګورم، زه غوره ګڼم چې وګورم د، چیرې چې یو څه په زړه پوري یا غیر معمولي پیښیږي. اوس مهال ، لټون په لاسي ډول ترسره کیږي: انجینر ټریس ترلاسه کوي او په خپلواکه توګه د یو څه په زړه پوري لټون کې سپان تحلیل کوي. د شکمنو فعالیتونو د موندلو په هیله د انفرادي نښو په اوږدو کې د سپانونو په لټه کې د خلکو چلند په هیڅ ډول اندازه نه کوي (په ځانګړې توګه کله چې دوی باید په مختلفو سپینو کې کوډ شوي ټول میټاډاټا احساس کړي، لکه د span ID، RPC میتود نوم، د مودې موده 'a، logs، tags، etc.).
د تعقیب لپاره بدیلونه
د ټریس پایلې خورا ګټورې دي کله چې دوی په داسې طریقه لیدل کیدی شي چې د سیسټم په تړلو برخو کې څه پیښیږي په اړه غیر معمولي بصیرت چمتو کوي. تر هغه چې دا پیښ شي، د ډیبګ کولو پروسه په لویه کچه پاتې ده غیر فعال او د کارونکي په وړتیا پورې اړه لري چې سمې اړیکې په پام کې ونیسي، د سیسټم سمې برخې وګوري، یا د پزل ټوټې سره یوځای کړي - لکه څنګه چې مخالف وسیلهد دې فرضیې په جوړولو کې د کارونکي سره مرسته کوي.
زه یو بصری ډیزاینر یا د UX متخصص نه یم، مګر په راتلونکې برخه کې زه غواړم یو څو نظرونه شریک کړم چې دا لیدونه څنګه ښکاري.
په ځانګړو خدماتو تمرکز وکړئ
په داسې وخت کې چې صنعت د نظرونو شاوخوا راټولیږي ، دا مناسب ښکاري چې انفرادي ټیمونه باید لومړیتوب ورکړي ترڅو ډاډ ترلاسه کړي چې د دوی خدمات د دې اهدافو سره سمون لري. دا هغه تعقیبوي د خدمت پر بنسټ لید د داسې ټیمونو لپاره غوره مناسب دی.
نښې، په ځانګړې توګه پرته له نمونې اخیستل، د ویشل شوي سیسټم د هرې برخې په اړه د معلوماتو خزانه ده. دا معلومات یو چالاک پروسیسر ته ورکول کیدی شي چې کاروونکو ته به یې وړاندې کړي د خدمت پر بنسټ موندنې. دوی دمخه پیژندل کیدی شي - حتی مخکې له دې چې کاروونکي نښې وګوري:
- د ځنډ ویش ډیاګرام یوازې د خورا مشهور غوښتنو لپاره (بې ځایه غوښتنې);
- د هغو قضیو لپاره د ځنډ ویش ډیاګرام چې د خدماتو SLO اهداف نه وي ترلاسه شوي؛
- په پوښتنو کې ترټولو "عام"، "په زړه پورې" او "عجیب" ټګونه چې ډیری وختونه تکرار شوي دي;
- د قضیو لپاره د ځنډ ماتول چیرې چې د خدمتونه خپل SLO اهداف نه ترلاسه کوي؛
- د مختلف زیرمو خدماتو لپاره د ځنډ ماتول.
د دې پوښتنو څخه ځینې په ساده ډول د جوړ شوي میټریکونو لخوا ځواب نه ورکول کیږي، کاروونکي مجبوروي چې د سپانسونو ارزونه وکړي. د پایلې په توګه، موږ یو خورا ډیر کاروونکي دښمن میکانیزم لرو.
دا پوښتنه راپورته کوي: د مختلف ټیمونو لخوا کنټرول شوي مختلف خدماتو ترمینځ پیچلي تعاملات څه دي؟ همداسي نه ده traceview د داسې حالت د روښانه کولو لپاره ترټولو مناسب وسیله نه ګڼل کیږي؟
د ګرځنده پراختیا کونکي ، د بې ریاست خدماتو مالکین ، د مدیریت شوي دولتي خدماتو مالکین (لکه ډیټابیسونه) او د پلیټ فارم مالکین ممکن بل څه سره علاقه ولري پریزنټیشن ویشل شوی سیسټم؛ traceview د دې بنسټیزو مختلفو اړتیاو لپاره خورا عام حل دی. حتی په خورا پیچلي مایکرو سرویس جوړښت کې، د خدماتو مالکین د دوه یا دریو څخه زیات د پورته او ښکته خدماتو ژورې پوهې ته اړتیا نلري. په لازمي ډول، په ډیری سناریوګانو کې، کاروونکي یوازې د پوښتنو ځوابونو ته اړتیا لري محدود خدمتونه.
دا د دې د ارزونې لپاره د میګنیفاینګ شیشې له لارې د خدماتو کوچنۍ فرعي سیټ ته د کتلو په څیر دی. دا به کارونکي ته اجازه ورکړي چې د دې خدماتو او د دوی سمدستي انحصارونو ترمینځ پیچلي تعاملاتو په اړه ډیرې پوښتنې وکړي. دا د خدماتو نړۍ کې بیکټریس ته ورته دی، چیرې چې انجنیر پوهیږي چې غلط، او همدارنګه د پوهیدو لپاره په شاوخوا خدماتو کې څه پیښیږي یو څه پوهه لري ولې.
هغه طریقه چې زه یې هڅوم د پورته څخه ښکته، د ټریس ویو پر بنسټ چلند سره سم مخالف دی، چیرې چې تحلیل د ټول ټریس سره پیل کیږي او بیا په تدریجي ډول د انفرادي سپانونو لپاره کار کوي. په مقابل کې، د ښکته پورته طریقه د پیښې احتمالي لامل ته نږدې د یوې کوچنۍ ساحې تحلیل کولو سره پیل کیږي، او بیا د اړتیا سره سم د لټون ځای پراخوي (د خدماتو پراخه لړۍ تحلیل کولو لپاره د نورو ټیمونو د راوستلو احتمال سره). دوهمه طریقه د لومړنیو فرضیو د چټک ازموینې لپاره غوره ده. یوځل چې کانکریټ پایلې ترلاسه شي ، نو دا به ممکنه وي چې ډیر هدف لرونکي او مفصل تحلیل ته لاړشئ.
د توپولوژي جوړول
د خدماتو ځانګړي لیدونه په ناقانونه توګه ګټور کیدی شي که چیرې کاروونکي پوهیږي کوم یو خدمت یا د خدماتو ډله د ځنډ د زیاتوالي یا د غلطیو لامل کیږي. په هرصورت، په یوه پیچلي سیسټم کې، د سرغړونکي خدمت پیژندل ممکن د ناکامۍ په وخت کې یو غیر معمولي کار وي، په ځانګړې توګه که چیرې د خدماتو څخه د غلطۍ پیغام نه وي راپور شوی.
د خدماتو ټوپولوژي رامینځته کول د دې په موندلو کې لویه مرسته کیدی شي چې کوم خدمت د غلطۍ نرخونو کې زیاتوالی یا د ځنډ زیاتوالی تجربه کوي چې د خدماتو د پام وړ تخریب لامل کیږي. کله چې زه د ټوپولوژي جوړولو په اړه خبرې کوم، زما مطلب نه دی د خدماتو نقشه، په سیسټم کې موجود هر خدمت ښیې او د دې لپاره پیژندل شوی . دا لید د لارښود شوي اسیکلیک ګراف پراساس د ټریس ویو څخه غوره ندی. پرځای یې زه غواړم وګورم په متحرک ډول تولید شوي خدمت ټوپولوژيد ځانګړو ځانګړتیاو پر بنسټ لکه د غلطۍ کچه، د غبرګون وخت، یا د کارونکي لخوا ټاکل شوي پیرامیټر چې د ځانګړو شکمنو خدماتو سره د وضعیت روښانه کولو کې مرسته کوي.
راځئ چې یو مثال واخلو. راځئ چې د فرضي خبري سایټ تصور وکړو. د کور پاڼې خدمت (د مخی صفحه) د ریډیس سره ډیټا تبادله کوي ، د سپارښتنې خدمت سره ، د اعلاناتو خدمت او ویډیو خدمت سره. د ویډیو خدمت د S3 څخه ویډیوګانې او د DynamoDB څخه میټاډاټا اخلي. د سپارښتنې خدمت د DynamoDB څخه میټاډاټا ترلاسه کوي، د Redis او MySQL څخه ډاټا باروي، او کافکا ته پیغامونه لیکي. د اعلاناتو خدمت د MySQL څخه ډاټا ترلاسه کوي او کافکا ته پیغامونه لیکي.
لاندې د دې ټوپولوژي سکیماتیک نمایش دی (ډیری سوداګریزې لارې پروګرامونه ټوپولوژي جوړوي). دا ګټور کیدی شي که تاسو اړتیا لرئ د خدماتو انحصار پوه شئ. په هرصورت، په جریان کې ډیبګ، کله چې یو ځانګړی خدمت (وایی ، د ویډیو خدمت) د غبرګون وخت ډیروالی ښیې ، دا ډول ټوپولوژي خورا ګټوره نه ده.
د فرضي خبر سایټ خدمت ډیاګرام
لاندې انځور به غوره وي. په خدمت کې ستونزه ده (ویډیو) په مرکز کې سم انځور شوی. کارونکي سمدلاسه ورته پام کوي. د دې لید څخه، دا روښانه کیږي چې د ویډیو خدمت د S3 غبرګون وخت زیاتوالي له امله په غیر معمولي توګه کار کوي، کوم چې د اصلي پاڼې د برخې د بارولو سرعت اغیزه کوي.
متحرک ټوپولوژي یوازې "په زړه پوري" خدمتونه ښیې
په متحرک ډول تولید شوي ټوپولوژی د جامد خدماتو نقشو په پرتله خورا اغیزمن کیدی شي، په ځانګړې توګه په لچکدار، اتوماتیک اندازه کولو زیربنا کې. د خدماتو ټوپولوژیو پرتله کولو او برعکس کولو وړتیا کارونکي ته اجازه ورکوي چې نور اړوند پوښتنې وکړي. د سیسټم په اړه ډیرې دقیقې پوښتنې ډیر احتمال لري چې د سیسټم کار کولو څرنګوالي په اړه ښه پوهه رامینځته کړي.
مقایسه ښکاره کول
یو بل ګټور لید به د پرتله کولو نندارتون وي. اوس مهال نښې د یو بل سره پرتله کولو لپاره خورا مناسب ندي ، نو پرتله کول معمولا وي سپین. او د دې مقالې اصلي مفکوره دقیقا دا ده چې سپانونه خورا ټیټه کچه دي ترڅو د ټریس پایلو څخه خورا ارزښتناک معلومات راوباسي.
د دوو نښو پرتله کول په بنسټیز ډول نوي لیدونو ته اړتیا نلري. په حقیقت کې، د هسټوګرام په څیر یو څه چې د ټریس ویو په څیر ورته معلومات استازیتوب کوي کافي دي. په حیرانتیا سره، حتی دا ساده طریقه کولی شي په جلا توګه د دوو نښو مطالعې په پرتله ډیره میوه راوړي. حتی ډیر پیاوړی به احتمال وي لیدل د نښو پرتله کول په مجموع کې. دا به خورا ګټور وي چې وګورئ چې څنګه د GC (د کثافاتو راټولول) د فعالولو لپاره په دې وروستیو کې ګمارل شوي ډیټابیس ترتیب بدلون د څو ساعتونو په پیمانه د ښکته جریان خدماتو غبرګون وخت اغیزه کوي. که هغه څه چې زه یې دلته تشریح کوم د زیربنا د بدلونونو اغیزې د A/B تحلیل په څیر ښکاري په ډیری خدماتو کې د ټریس پایلو په کارولو سره ، نو تاسو له حقیقت څخه ډیر لرې نه یاست.
پایلې
زه پخپله د تعقیب ګټورتوب پوښتنه نه کوم. زه په صادقانه توګه باور لرم چې د بډایه، علت او شرایطو په څیر د معلوماتو راټولولو لپاره بله لاره نشته لکه څنګه چې په ټریس کې شتون لري. په هرصورت، زه دا هم باور لرم چې د تعقیب ټول حلونه دا ډاټا په خورا غیر موثر ډول کاروي. تر هغه چې د تعقیب وسیلې د ټریس ویو نمایش کې پاتې وي ، دوی به د دوی وړتیا کې محدود وي چې خورا ارزښتناک معلومات رامینځته کړي چې په ټریسونو کې موجود ډیټا څخه استخراج کیدی شي. سربیره پردې ، د بشپړ غیر دوستانه او غیر شعوري لید انٹرفیس رامینځته کولو خطر شتون لري چې دا به په غوښتنلیک کې د غلطیو حل کولو لپاره د کارونکي وړتیا په جدي ډول محدود کړي.
د پیچلو سیسټمونو ډیبګ کول، حتی د وروستي وسیلو سره، په حیرانتیا سره ستونزمن کار دی. وسیلې باید د پراختیا کونکي سره د فرضیې په جوړولو او ازموینې کې مرسته وکړي ، په فعاله توګه چمتو کوي اړونده معلومات، د بهرنیانو پیژندل او د ځنډونو په ویش کې د ځانګړتیاوو یادونه. د دې لپاره چې تعقیب د پراختیا کونکو لپاره د انتخاب وسیله شي کله چې د تولید ناکامیو ستونزې حل کول یا د ډیری خدماتو پراخه کولو ستونزې حل کول ، اصلي کارونکي انٹرفیسونه او لیدونه اړین دي چې د پراختیا کونکو ذهني ماډل سره ډیر مطابقت لري چې دا خدمات رامینځته کوي او چلوي.
دا به د یو سیسټم ډیزاین کولو لپاره د پام وړ ذهني هڅې وکړي چې د ټریس پایلو کې موجود مختلف سیګنالونه په داسې طریقه نمایندګي وکړي چې د تحلیل او تحلیل اسانه کولو لپاره مطلوب وي. تاسو اړتیا لرئ د دې په اړه فکر وکړئ چې څنګه د ډیبګ کولو پرمهال د سیسټم ټوپولوژي خلاص کړئ په داسې طریقه چې کارونکي سره مرسته کوي د انفرادي نښو یا سپینو لیدو پرته ړانده ځایونو باندې بریالي شي.
موږ ښه خلاصون او پرت کولو وړتیاو ته اړتیا لرو (په ځانګړي توګه په UI کې). هغه چې د فرضیې لخوا پرمخ وړل شوي ډیبګ کولو پروسې کې به ښه فټ شي چیرې چې تاسو په تکراري ډول پوښتنې کولی شئ او فرضیې ازموینه کولی شئ. دوی به په اوتومات ډول د مشاهدې ټولې ستونزې حل نکړي، مګر دوی به د کاروونکو سره مرسته وکړي چې د دوی انګیزه ګړندۍ کړي او هوښیار پوښتنې رامینځته کړي. زه د لید لید لپاره د ډیر فکري او نوښت لرونکي چلند غوښتنه کوم. دلته د افق پراخولو لپاره ریښتینی امکان شتون لري.
PS د ژباړونکي څخه
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «".
سرچینه: www.habr.com