Not. werger.: Nivîskarê vê materyalê Cindy Sridharan e, endezyarek li imgix-ê ku di pêşveçûna API-ê de û, bi taybetî, ceribandina mîkroservisê pispor e. Di vê materyalê de, ew nêrîna xwe ya berfireh a pirsgirêkên heyî yên di warê şopandina belavkirî de parve dike, ku, bi dîtina wê, kêmbûna amûrên bi rastî bi bandor ji bo çareserkirina pirsgirêkên zextê heye.
[Wêne ji hatî girtin li ser şopandina belavkirî.]
Ew bawer e ku pêkanîna zehmet, û vegera li ser wê . Gelek sedem hene ku çima şopandin pirsgirêk e, bi gelemperî keda ku di mîhengkirina her perçeyek pergalê de têkildar e vedibêje da ku bi her daxwazê re sernavên guncan veguhezîne. Her çiqas ev pirsgirêk hebe jî, ew bi tu awayî nayê çareser kirin. Bi awayê, ew rave nake ka çima pêşdebiran bi rastî ji şopandinê hez nakin (tevî ku ew jixwe kar dike).
Pirsgirêka sereke ya bi şopandina belavkirî ne berhevkirina daneyan, standardkirina formatên ji bo belavkirin û pêşkêşkirina encaman, an destnîşankirina kengê, li ku, û çawa nimûne ye. Ez hewl nadim ku xeyal bikim trivial ev "pirsgirêkên têgihîştinê", bi rastî, teknîkî pir girîng in û (heke em bi rastî Çavkaniya Vekirî bifikirin) ) Pirsgirêkên siyasî yên ku ji bo çareser kirina van pirsgirêkan divê werin derbas kirin.
Lêbelê, heke em xeyal bikin ku ev hemî pirsgirêk têne çareser kirin, îhtîmalek mezin heye ku di warê pirsgirêkê de tiştek girîng neyê guhertin. tecrubeya bikarhênerê dawî. Dibe ku şopandin hîn jî di senaryoyên nerastkirina herî gelemperî de ne bikêrhatî be - tewra piştî ku hate bicîh kirin.
Şopeke wisa cuda
Şopandina belavbûyî çend hêmanên cihêreng vedihewîne:
- pêvekirina sepanan û navgîniyê bi amûrên kontrolê;
- veguherîna çarçoveya belavkirî;
- berhevkirina şopan;
- depokirina şopê;
- derxistin û dîtina wan.
Pir axaftin di derbarê şopandina belavbûyî de meyldar e ku wê wekî celebek operasyonek yekane ya ku yekane armanca wê ew e ku alîkariya bi tevahî teşhîskirina pergalê bike derman bike. Ev bi piranî ji ber wê yekê ye ku ramanên li ser şopandina belavbûyî di dîrokê de çawa hatine damezrandin. LI , dema ku çavkaniyên Zipkin hatin vekirin, hate gotin ku ew [Zipkin] Twitter zûtir dike. Pêşniyarên bazirganî yên yekem ên ji bo şopandinê jî wekî hatin pêşve xistin .
Not. werger.: Ji bo ku metnek din hêsantir were fam kirin, em li gorî du têgînên bingehîn diyar bikin :
- span - hêmana bingehîn a şopandina belavbûyî. Ew ravekirina karek diyarkirî ye (mînak, pirsek databasê) bi navek, demên destpêk û dawiyê, etîket, têketin û çarçoveyê.
- Spans bi gelemperî girêdanên bi qonaxên din ve dihewîne, ku dihêle ku pir span tê de bêne hev kirin Trace - dîtbarîkirina jiyana daxwazek ku ew di nav pergalek belavbûyî de dimeşe.
Şop daneyên pir hêja dihewîne ku dikare di karên wekî ceribandina hilberînê, ceribandina başkirina karesatê, ceribandina derzîlêdana xeletiyê, hwd de bibe alîkar. Bi rastî, hin pargîdan jixwe ji bo mebestên wekhev şopandinê bikar tînin. Ka em dest pê bikin ji bilî veguheztina peldankan ber bi pergala hilanînê ve, karanîna din jî hene:
- Mînakî, Uber encamên şopandinê da ku di navbera seyrûsefera ceribandinê û seyrûsefera hilberînê de cûda bikin.
- facebook Daneyên şopandinê ji bo analîza riya krîtîk û ji bo veguheztina trafîkê di dema ceribandinên birêkûpêk vegerandina karesatê de.
- Her weha tora civakî Notebookên Jupyter ku destûrê didin pêşdebiran ku li ser encamên şopandinê pirsên keyfî bimeşînin.
- Followers (Lineage Driven Failure Injection) şopên ji bo ceribandinê bi derziyê çewtiyê belav kirin.
Yek ji vebijarkên ku li jor hatine destnîşan kirin bi tevahî ji senaryoyê re derbas nabe debugging, di dema ku endezyar hewl dide ku pirsgirêkê bi dîtina şopê çareser bike.
Dema ku tê hîn digihîje skrîpta xeletkirinê, navbeyna bingehîn diagram dimîne traceview (her çend hinek jê jî dibêjin "Gantt chart" an "şeyara avê"). Binê traceview я hemî dever û metadata pê re ku bi hev re şopê pêk tînin. Her pergala şopandina çavkaniya vekirî, û her weha her çareseriya şopandina bazirganî, a traceview navrûya bikarhêner ji bo dîtin, hûrgulî û fîlterkirina şopan.
Pirsgirêka hemî pergalên şopandinê ku min heya nuha dîtiye ev e ku encam e dîtbarî (şopandin) hema hema bi tevahî taybetmendiyên pêvajoya nifşa şopê nîşan dide. Tewra gava ku dîmenên alternatîf têne pêşniyar kirin: nexşeyên germ, topolojiyên karûbar, histogramên derengiyê, ew hîn jî di dawiyê de têne traceview.
Di berê de I ku pir "nûvekirin" di şopandina UI / UX de bi sînor xuya dike metadaneyên zêde di şopê de, veberhênana li ser wan agahdariya bi kardînalîteya bilind (kardinalîteya bilind) an peydakirina kapasîteya ku di nav deverên taybetî de dakêşin an lêpirsînan bimeşînin nav- û nav-şopa... Ku tê de traceview amûra dîtbarî ya bingehîn dimîne. Heya ku ev rewş bidome, şopandina belavkirî dê (bi çêtirîn) wekî amûrek xeletkirinê, piştî metrîk, têketin û şopên stûyê cîhê 4-an bigire, û ya herî xirab ew ê bibe windakirina drav û wextê.
Pirsgirêka traceview
Armanca traceview - wêneyek bêkêmasî ya tevgera daxwazek yekane li seranserê hemî pêkhateyên pergala belavkirî ya ku ew pê ve girêdayî ye peyda bikin. Hin pergalên şopandinê yên pêşkeftî dihêlin ku hûn di nav deverên kesane de bişopînin û bi demê re veqetînek bibînin hundur yek pêvajo (gava ku span sînorên fonksiyonel hene).
Bingeha bingehîn a mîmariya mîkroxizmetan ev raman e ku strukturên rêxistinî bi hewcedariyên pargîdaniyê mezin dibe. Alîgirên karûbarên mîkro amaje dikin ku belavkirina peywirên karsaziyê yên cihêreng di nav karûbarên kesane de dihêle ku tîmên pêşkeftinê yên piçûk, xweser tevaya jiyana van karûbaran kontrol bikin, û ji wan re kapasîteya ku serbixwe wan karûbaran ava bikin, ceribandin û bicîh bikin. Lêbelê, kêmasiya vê belavkirinê windakirina agahdariya li ser ka her karûbar bi yên din re çawa têkilî dike. Di şert û mercên weha de, şopandina belavkirinê îdia dike ku ji bo amûrek pêdivî ye debugging danûstendinên tevlihev di navbera karûbaran de.
Heke hûn bi rastî , wê demê yek kes nikare wê di serê xwe de bihêle tevî sûret. Di rastiyê de, pêşxistina amûrek li ser bingeha texmîna ku ew gengaz e jî tiştek dij-patternek e (nêzîkatiyek bêbandor û nehilber). Bi îdeal, debugging amûrek ku arîkar dike hewce dike qada lêgerîna xwe teng bikin, da ku endezyar dikarin balê bikişînin ser binkeyek pîvanan (xizmet / bikarhêner / mêvandar, hwd.) yên ku bi senaryoya pirsgirêkê ve girêdayî ne. Dema ku sedema têkçûnê diyar dike, ji endezyaran ne hewce ye ku fêm bikin ka di dema bûyerê de çi qewimî hemû xizmetên yekcar, ji ber ku pêdivîyek wusa dê bi ramana mîmariya mîkroxizmetê re dijberî bike.
Lêbelê, traceview e nameyê Ev. Erê, hin pergalên şopandinê dema ku jimara palên di şopê de ew qas mezin be ku ew nikaribin di yek dîtbarî de werin xuyang kirin şopên pêçandî pêşkêş dikin. Lêbelê, ji ber jimarek mezin a agahdariya ku di dîmenek wusa jêhatî de jî heye, endezyar hîn jî mecbûr kirin "sift" bike, bi destan vebijarkê li komek karûbarên ku çavkaniyên pirsgirêkan in teng bike. Mixabin, di vî warî de, makîneyên ji mirovan pir bileztir in, ji xeletiyan kêmtir in, û encamên wan dubaretir in.
Sedemek din ku ez difikirim traceview xelet e ev e ku ew ji bo xeletkirina hîpotez-rêveber ne baş e. Di bingeha wê de, debugging e iterative pêvajoyek ku bi hîpotezekê dest pê dike, dûv re verastkirina çavdêriyên cihêreng û rastiyên ku ji pergalê bi vektorên cihêreng hatine wergirtin, encam / giştîkirin û bêtir nirxandina rastiya hîpotezê.
Fersend bi lez û erzan ceribandina hîpotezan û li gorî wê başkirina modela derûnî ye kevirê quncikê debugging Divê her amûrek xeletkirinê hebe bihevra û cîhê lêgerînê teng bikin an jî, di doza rêberiyek derewîn de, destûrê bidin bikarhêner ku vegere û li deverek cûda ya pergalê hûr bibe. Amûra bêkêmasî dê vê yekê bike bi proaktîv, tavilê bala bikarhêner dikişîne ser qadên pirsgirêka potansiyel.
Heyf, traceview nikare wekî amûrek bi navgînek înteraktîf were gotin. Ya çêtirîn ku hûn dikarin dema karanîna wê hêvî bikin ev e ku hûn çavkaniyek derengiya zêde bibînin û li hemî nîşan û têketinên gengaz ên ku pê re têkildar in binihêrin. Ev yek ji endezyar re alîkarî nake ku nas bike qalibên di seyrûseferê de, wek taybetîyên belavkirina derengmayînê, an têkiliyên di navbera pîvandinên cihêreng de kifş bikin. dibe alîkar ku hin ji van pirsgirêkan li dora xwe bigirin. Bicî, analîzek serketî bi karanîna fêrbûna makîneyê tê bikar anîn da ku qonaxên anormal nas bike û binekomek etîketan ku dibe ku bi behremendiya anormal re têkildar be nas bike. Lêbelê, min hîn nedîtiye ku dîmenên berbiçav ên fêrbûna makîneyê an vedîtinên derxistina daneyê yên ku li ser qonaxên ku ji şopek an DAG-ek (grafika asîklîk a rêvekirî) bi girîngî cûda ne, têne sepandin.
Spans pir kêm in
Pirsgirêka bingehîn a traceview ew e spans hem ji bo analîza derengbûnê û hem jî ji bo analîza sedema bingehîn primitivesên pir nizm in. Mîna parskirina fermanên pêvajoyek kesane ye ku meriv hewl bide ku îstisnayek çareser bike, zanibin ku amûrên pir astek bilindtir ên mîna paşnavê hene ku meriv bi wan re pir hêsantir dixebitin.
Wekî din, ez ê azadiya xwe bipejirînim: Bi îdeal, em ne hewce ne wêneya tevahî di dema çerxa jiyanê ya daxwaznameyê de, ku ji hêla amûrên şopandina nûjen ve têne destnîşan kirin, qewimî. Di şûna wê de, hin formek abstrakasyona asta bilind hewce ye ku agahdariya li ser çi heye xelet çû (wek paşverû), digel hin çarçoveyek. Li şûna temaşekirina tevahiya şopê, ez tercîh dikim ku wê bibînim parçeyek, cihê ku tiştek balkêş an neasayî diqewime. Heya nuha, lêgerîn bi destan tê kirin: endezyar şopê distîne û di lêgerîna tiştek balkêş de bi rengek serbixwe vekolan dike. Nêzîkatiya mirovên ku li şopên kesane dinihêrin bi hêviya ku çalakiya gumanbar tespît bikin, qet pîvan nade (nemaze gava ku ew neçar in ku hemî metadatayên ku di qonaxên cihêreng de hatine kod kirin, wekî nasnama span, navê rêbaza RPC, dirêjahiya paşîn fêm bikin. 'a, têketin, tag, hwd.).
Alternatîfên traceview
Encamên şopandinê pir bikêr in dema ku ew dikarin bi rengekî ku têgihîştinek ne-tiştandî li ser tiştên ku di beşên bi hev ve girêdayî yên pergalê de diqewimin peyda bikin. Heya ku ev diqewime, pêvajoya debugging bi piranî dimîne bêhêz û bi şiyana bikarhêner ve girêdayî ye ku têkiliyên rast bibîne, parçeyên rast ên pergalê kontrol bike, an perçeyên puzzle-ê li hev bicivîne - berevajî alet, ji bikarhêner re dibe alîkar ku van hîpotezan formule bike.
Ez ne sêwiranerek dîtbar an pisporek UX me, lê di beşa pêş de ez dixwazim çend ramanan li ser ka ev dîtbarî çawa xuya dikin parve bikim.
Li ser karûbarên taybetî bisekinin
Di demekê de ku pîşesazî li dora ramanan hevgirtî ye , maqûl xuya dike ku tîmên takekesî pêşî lê bigirin ku karûbarên xwe bi van armancan re hevaheng in. Li pey wê ye xizmetkar dîtbarî ji bo tîmên weha çêtirîn e.
Şop, nemaze bêyî nimûne, xezîneyek agahdarî li ser her pêkhateyek pergalek belavkirî ye. Ev agahdarî dikare ji bo pêvajoyek bikêrhatî ya ku dê bikarhêneran peyda bike were xwarin xizmetkar vedîtin Ew dikarin di pêş de bêne nas kirin - tewra berî ku bikarhêner li şopan binêre:
- Diagramên belavkirina derengiyê tenê ji bo daxwazên pir girîng (daxwazên derveyî);
- Diagramên belavkirina derengiyê ji bo rewşên ku armancên SLO yên karûbarê bi dest neketin;
- Etîketên herî "hevbeş", "balkêş" û "ecêb" di pirsnameyên ku pir caran de ne têne dubare kirin;
- Dabeşkirina derengiyê ji bo rewşên ku girêdayîbûna karûbar bigihîjin armancên xwe yên SLO;
- Dabeşkirina derengiyê ji bo karûbarên cûda yên jêrîn.
Hin ji van pirsan bi tenê ji hêla metrîkên çêkirî ve nayên bersivandin, ku bikarhêneran neçar dikin ku li ser dirêjan bişopînin. Wekî encamek, me mekanîzmayek zehf-bikarhêner-dijmin heye.
Ev pirsê derdixe pêş: li ser danûstendinên tevlihev ên di navbera karûbarên cihêreng ên ku ji hêla tîmên cihê ve têne kontrol kirin de çi ye? Ma ne wisa ye traceview ji bo ronîkirina rewşek wiha amûra herî guncaw nayê dîtin?
Pêşdebirên mobîl, xwedan karûbarên bêdewlet, xwedan karûbarên dewletparêz ên rêvebirinî (mîna databases) û xwedan platforman dibe ku bi tiştek din re eleqedar bibin pêşkêşî sîstema belavkirî; traceview Ji bo van hewcedariyên cûda yên bingehîn çareseriyek pir gelemperî ye. Tewra di mîmariya mîkroxizmetek pir tevlihev de, xwedan karûbar ne hewceyî zanîna kûr a ji du an sê karûbarên jorîn û jêrîn in. Di bingeh de, di pir senaryoyan de, bikarhêner tenê hewce ne ku bersiva pirsan bidin set sînorkirî yên xizmetên.
Mîna ku ji bo vekolîna wê bi pîvazek mezin li jêrkomek piçûk a karûbaran binêre. Ev ê bihêle ku bikarhêner di derheqê danûstendinên tevlihev ên di navbera van karûbaran û girêdanên wan ên tavilê de bêtir pirsên bikêr bipirse. Ev di cîhana karûbaran de, ku endezyar pê dizane, mîna paşverû ye ku xelet e, û di heman demê de hin têgihîştina tiştê ku di karûbarên derdorê de diqewime heye ku fêm bike çima.
Nêzîkatiya ku ez pêþkêþ dikim tam berevajiyê nêzîkatiya ji jor-xwarê, li ser bingeha şopandinê ye, ku analîz bi tevahî şopê dest pê dike û dûv re hêdî hêdî berbi ferdên kesane ve diçe. Berevajî vê, nêzîkatiyek jêrîn-jor bi analîzkirina deverek piçûk a nêzî sedema potansiyela bûyerê dest pê dike, û dûv re cîhê lêgerînê li gorî hewcedariyê berfireh dike (bi potansiyela anîna tîmên din ji bo analîzkirina cûrbecûr karûbaran). Nêzîkatiya duyemîn ji bo ceribandina zû hîpotezên destpêkê çêtir e. Dema ku encamên berbiçav werin bidestxistin, dê gengaz be ku meriv ber bi analîzek hûr û hûrtir ve biçin.
Avakirina topolojiyê
Ger bikarhêner zanibe dîtinên karûbar-taybet dikarin pir bikêr bin kî ye karûbarek an komek karûbar ji zêdekirina derengbûnê an sedema xeletiyan berpirsiyar e. Lêbelê, di pergalek tevlihev de, destnîşankirina karûbarê sûcdar dibe ku di dema têkçûnekê de karekî ne-tawan be, nemaze heke ji karûbaran peyamên xeletiyê nehatin ragihandin.
Avakirina topolojiya karûbarê dikare bibe alîkariyek mezin di fêhmkirina ka kîjan karûbar di rêjeyên xeletiyê de an zêdebûnek derengbûnê ya ku dibe sedem ku karûbar bi rengek berbiçav kêm bibe diceribîne. Dema ku ez behsa avakirina topolojiyê dikim, mebesta min ne nexşeya xizmetê, her karûbarê ku di pergalê de heye û bi wê tê zanîn nîşan dide . Ev nêrîn ji traceview-ê ku li ser bingeha grafiyek acyclic rêvekirî ne çêtir e. Li şûna wê ez dixwazim bibînim topolojiya karûbarê dînamîkî hatî çêkirin, li ser bingeha hin taybetmendiyên wekî rêjeya xeletiyê, dema bersivê, an her pîvanek diyarkirî ji hêla bikarhêner ve ku ji bo zelalkirina rewşê bi karûbarên taybetî yên gumanbar re dibe alîkar.
Werin em mînakek bidin. Werin em malperek nûçeyan a hîpotetîk bifikirin. Xizmeta rûpela malê (rûpela pêşîn) bi Redis re, bi karûbarek pêşniyarê, bi karûbarek reklam û karûbarek vîdyoyê re daneyan diguhezîne. Karûbarê vîdyoyê vîdyoyên ji S3 û metadata ji DynamoDB digire. Karûbarê pêşniyarê metadata ji DynamoDB distîne, daneyan ji Redis û MySQL bar dike, û ji Kafka re peyaman dinivîse. Xizmeta reklamê daneyan ji MySQL distîne û ji Kafka re peyaman dinivîse.
Li jêr nûnertiyek şematîkî ya vê topolojiyê heye (gelek bernameyên rêwîtiyê yên bazirganî topolojiyê ava dikin). Heke hûn hewce ne ku girêdanên karûbarê fêm bikin ew dikare kêrhatî be. Lêbelê, di dema debugging, dema ku karûbarek diyarkirî (bibêjin, karûbarek vîdyoyê) dema bersivê zêde nîşan dide, topolojîyek wusa ne pir bikêr e.
Diagrama karûbarê malpera nûçeyek hîpotetîk
Diagrama jêrîn dê çêtir be. Pirsgirêka xizmetê heye (video) rast di navendê de tê xuyang kirin. Bikarhêner wê di cih de ferq dike. Ji vê dîtbariyê, diyar dibe ku karûbarê vîdyoyê ji ber zêdebûna dema bersivdana S3, ku bandorê li leza barkirina beşek ji rûpela sereke dike, ne asayî dixebite.
Topolojiya dînamîk tenê karûbarên "balkêş" nîşan dide
Topolojiyên ku bi dînamîk têne hilberandin dikarin ji nexşeyên karûbarê statîk bikêrtir bin, nemaze di binesaziyên elastîk, pîvazkirina otomatîkî de. Kapasîteya berhevkirin û berevajîkirina topolojiyên karûbarê dihêle ku bikarhêner pirsên têkildar zêdetir bipirse. Pirsên rasttir ên derbarê pergalê de îhtîmal e ku bibin sedema têgihiştinek çêtir ka pergalê çawa dixebite.
Nîşandana berawirdî
Dîmenek din a kêrhatî dê dîmenek berawirdî be. Heya nuha şop ji bo danberhevên kêlek-alî ne pir maqûl in, ji ber vê yekê berhevdan bi gelemperî ne spans. Û ramana sereke ya vê gotarê bi rastî ev e ku pêlav pir nizm in ku agahdariya herî hêja ji encamên şopandinê derxînin.
Berawirdkirina du şopan bi bingehîn dîmenên nû hewce nake. Bi rastî, tiştek mîna histogramek ku heman agahdariyê wekî şopek nîşan dide, bes e. Ecêb e, tewra ev rêbaza sade jî ji xwendina du şopan ji hev veqetandî pir bêtir fêkî dide. Dê îhtîmalek hîn bihêztir be dîtbarî kirin berhevdana şopan Bi tevayî. Dê pir bikêr be ku hûn bibînin ka guheztina mîhengê databasê ya ku vê dawiyê hatî bicîh kirin ji bo çalakkirina GC (komkirina çopê) çawa bandorê li dema bersivdana karûbarek jêrîn li ser pîvanek çend demjimêran dike. Ger tiştê ku ez li vir diyar dikim wekî analîzek A/B ya bandora guhertinên binesaziyê xuya dike di gelek xizmetan de bi karanîna encamên şopandinê, wê hingê hûn ji rastiyê pir ne dûr in.
encamê
Ez bikêrhatina şopandinê bixwe napirsim. Ez ji dil bawer dikim ku ji bo berhevkirina daneyan bi qasî ya ku di şopekê de tê de heye, rêbazek din tune ye. Lêbelê, ez di heman demê de bawer dikim ku hemî çareseriyên şopandinê vê daneyê pir bêkêmasî bikar tînin. Heya ku amûrên şopandinê li ser nûnertiya traceview asê bimînin, ew ê di şiyana xwe de sînordar bin ku herî zêde agahdariya hêja ku dikarin ji daneyên ku di şopan de têne derxistin bikar bînin. Digel vê yekê, metirsiya pêşdebirina pêvekek dîtbarî ya bi tevahî nedostane û nexwestî heye ku dê şiyana bikarhêner ji bo çareserkirina xeletiyên di serîlêdanê de bi tundî sînordar bike.
Dabeşkirina pergalên tevlihev, tewra bi amûrên herî dawî re, pir dijwar e. Pêdivî ye ku amûr ji pêşdebir re bibe alîkar ku hîpotezek formule bike û ceribandin, bi awayekî çalak pêşkêş dikin agahdariya têkildar, tespîtkirina derdor û balkişandina taybetmendiyên di belavkirina derengiyan de. Ji bo ku şopandin bibe amûra bijarte ji bo pêşdebiran dema ku xeletiyên hilberînê çareser bikin an pirsgirêkên ku gelek karûbaran vedigirin çareser bikin, pêwendiya bikarhênerê ya orîjînal û dîtbarî hewce ne ku bi modela derûnî ya pêşdebiran re ku wan karûbaran diafirînin û dixebitin re hevaheng in.
Dê hewildanek derûnî ya girîng bigire ku meriv pergalek dîzayn bike ku dê nîşaneyên cihêreng ên ku di encamên şopandinê de peyda dibin bi rengek ku ji bo hêsan analîz û encamdanê xweşbînkirî temsîl bike. Pêdivî ye ku hûn bifikirin ka meriv çawa di dema debugkirinê de topolojiya pergalê abstrak dike ku ji bikarhêner re dibe alîkar ku bêyî ku li şop û paçikên kesane binihêre deqên kor derbas bike.
Pêdiviya me bi kapasîteyên razber û qatkirina baş heye (bi taybetî di UI de). Yên ku dê di pêvajoyek xeletkirina hîpotez-rêveberiyê de baş bi cih bibin ku hûn dikarin dubare pirsan bipirsin û hîpotezan biceribînin. Ew ê bixweber hemî pirsgirêkên çavdêriyê çareser nekin, lê ew ê ji bikarhêneran re bibin alîkar ku têgihîştina xwe tûj bikin û pirsên jîrtir formule bikin. Ez bang dikim ku ji bo dîtbarîkirinê nêzîkatiyek bihizir û nûjentir. Li vir perspektîfek rastîn heye ku asoyê berfireh bike.
PS ji wergêr
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «".
Source: www.habr.com