Shënim. përkth.: Autorja e këtij materiali është Cindy Sridharan, një inxhiniere në imgix, e specializuar në zhvillimin e API-ve dhe, në veçanti, testimin e mikroservisit. Në këtë material, ajo ndan vizionin e saj të detajuar të problemeve aktuale në fushën e gjurmimit të shpërndarë, ku, sipas saj, mungojnë mjete vërtet efektive për zgjidhjen e problemeve urgjente.
[Ilustrimi i marrë nga rreth gjurmimit të shpërndarë.]
Besohet se vështirë për t'u zbatuar, dhe kthimi në të . Ka shumë arsye pse gjurmimi është problematik, shpesh duke përmendur punën e përfshirë në konfigurimin e secilit komponent të sistemit për të transmetuar titujt e duhur me secilën kërkesë. Edhe pse ky problem ekziston, ai nuk është aspak i pakapërcyeshëm. Nga rruga, nuk shpjegon pse zhvilluesit nuk e pëlqejnë vërtet gjurmimin (edhe kur ai tashmë funksionon).
Sfida kryesore me gjurmimin e shpërndarë nuk është mbledhja e të dhënave, standardizimi i formateve për shpërndarjen dhe prezantimin e rezultateve, ose përcaktimi se kur, ku dhe si të bëhet kampionimi. Nuk po mundohem të imagjinoj i parëndësishëm këto "probleme të kuptueshmërisë" janë, në fakt, mjaft të rëndësishme teknike dhe (nëse po shqyrtojmë me të vërtetë Burimin e Hapur) ) sfidat politike që duhen kapërcyer në mënyrë që këto probleme të konsiderohen të zgjidhura.
Megjithatë, nëse imagjinojmë se të gjitha këto probleme janë zgjidhur, ka një probabilitet të lartë që asgjë të mos ndryshojë ndjeshëm në aspektin e përvojën e përdoruesit përfundimtar. Gjurmimi mund të mos jetë ende i dobishëm në skenarët më të zakonshëm të korrigjimit - edhe pasi të jetë vendosur.
Një gjurmë kaq e ndryshme
Gjurmimi i shpërndarë përfshin disa komponentë të ndryshëm:
- pajisja e aplikacioneve dhe programeve të mesme me mjete kontrolli;
- transferimi i kontekstit të shpërndarë;
- grumbullimi i gjurmëve;
- ruajtja e gjurmëve;
- nxjerrja dhe vizualizimi i tyre.
Shumë biseda rreth gjurmimit të shpërndarë priren ta trajtojnë atë si një lloj operacioni unar qëllimi i vetëm i të cilit është të ndihmojë në diagnostikimin e plotë të sistemit. Kjo është kryesisht për shkak të mënyrës se si janë formuar historikisht idetë për gjurmimin e shpërndarë. NË , e bërë kur u hapën burimet Zipkin, u përmend se ai [Zipkin] e bën Twitter më të shpejtë. Ofertat e para tregtare për gjurmim u promovuan gjithashtu si .
Shënim. përkth.: Për ta bërë më të lehtë për t'u kuptuar tekstin e mëtejshëm, le të përcaktojmë dy terma bazë sipas :
- Hapësirë — elementi bazë i gjurmimit të shpërndarë. Është një përshkrim i një fluksi të caktuar pune (për shembull, një pyetje në bazën e të dhënave) me një emër, oraret e fillimit dhe përfundimit, etiketat, regjistrat dhe kontekstin.
- Hapësirat zakonisht përmbajnë lidhje me hapësira të tjera, duke lejuar që hapësira të shumta të kombinohen në gjurmë — vizualizimi i jetës së një kërkese ndërsa lëviz nëpër një sistem të shpërndarë.
Gjurmët përmbajnë të dhëna tepër të vlefshme që mund të ndihmojnë me detyra të tilla si testimi i prodhimit, testimi i rikuperimit nga fatkeqësitë, testimi i injektimit të gabimeve, etj. Në fakt, disa kompani tashmë përdorin gjurmimin për qëllime të ngjashme. Le të fillojmë me ka përdorime të tjera përveç thjesht lëvizjes së hapësirave në sistemin e ruajtjes:
- Për shembull, Uber gjurmimi i rezultateve për të bërë dallimin midis trafikut testues dhe trafikut të prodhimit.
- Facebook gjurmë të dhënash për analizën kritike të rrugës dhe për ndërrimin e trafikut gjatë testeve të rregullta të rikuperimit nga fatkeqësitë.
- Gjithashtu rrjeti social Fletoret Jupyter që lejojnë zhvilluesit të kryejnë pyetje arbitrare për rezultatet e gjurmimit.
- Ndjekësit (Injeksion dështimi i drejtuar nga linja) gjurmë të shpërndara për testim me injeksion gabimi.
Asnjë nga opsionet e listuara më sipër nuk zbatohet tërësisht për skenarin debug, gjatë së cilës inxhinieri përpiqet të zgjidhë problemin duke parë gjurmën.
Kur vjen ende arrin skriptin e korrigjimit, ndërfaqja kryesore mbetet diagrami traceview (edhe pse disa e quajnë edhe atë "Grafiku Gantt" ose "diagrami i ujëvarës"). Nën traceview я të gjitha hapësirat dhe meta të dhënat shoqëruese që së bashku përbëjnë gjurmën. Çdo sistem gjurmimi me burim të hapur, si dhe çdo zgjidhje gjurmuese komerciale, ofron a traceview ndërfaqja e përdoruesit për vizualizimin, detajimin dhe filtrimin e gjurmëve.
Problemi me të gjitha sistemet e gjurmimit që kam parë deri më tani është se rezulton vizualizimi (pamje gjurmësh) pothuajse plotësisht pasqyron veçoritë e procesit të gjenerimit të gjurmëve. Edhe kur propozohen vizualizime alternative: hartat e nxehtësisë, topologjitë e shërbimit, histogramet e vonesës, ato ende në fund zbresin në traceview.
Në të kaluarën unë që shumica e "risive" në gjurmimin e UI/UX duket se janë të kufizuara në meta të dhëna shtesë në gjurmim, duke investuar në to informacion me kardinalitet të lartë (kardinalitet i lartë) ose ofrimi i aftësisë për të shpuar në hapësira specifike ose për të drejtuar pyetje ndër- dhe intra-gjurmë... Ku traceview mbetet mjeti kryesor i vizualizimit. Për sa kohë që kjo gjendje vazhdon, gjurmimi i shpërndarë (në rastin më të mirë) do të zërë vendin e 4-të si mjet korrigjimi, pas metrikës, shkrimeve dhe gjurmëve të stivës, dhe në rastin më të keq do të rezultojë të jetë humbje parash dhe kohe.
Problem me traceview
fat traceview — të sigurojë një pamje të plotë të lëvizjes së një kërkese të vetme në të gjithë komponentët e sistemit të shpërndarë me të cilin lidhet. Disa sisteme gjurmimi më të avancuara ju lejojnë të shponi në hapësira individuale dhe të shikoni një avari me kalimin e kohës brenda një proces (kur hapësirat kanë kufij funksionalë).
Premisa bazë e arkitekturës së mikroshërbimeve është ideja se struktura organizative rritet me nevojat e kompanisë. Përkrahësit e mikroshërbimeve argumentojnë se shpërndarja e detyrave të ndryshme të biznesit në shërbime individuale u lejon ekipeve të vogla, autonome të zhvillimit të kontrollojnë të gjithë ciklin jetësor të shërbimeve të tilla, duke u dhënë atyre mundësinë për të ndërtuar, testuar dhe shpërndarë në mënyrë të pavarur ato shërbime. Megjithatë, disavantazhi i kësaj shpërndarjeje është humbja e informacionit se si çdo shërbim ndërvepron me të tjerët. Në kushte të tilla, gjurmimi i shpërndarë pretendon të jetë një mjet i domosdoshëm për të debug ndërveprimet komplekse ndërmjet shërbimeve.
Nëse vërtet , atëherë asnjë person i vetëm nuk është në gjendje ta mbajë atë në kokën e tij i plotë Foto. Në fakt, zhvillimi i një mjeti të bazuar në supozimin se është madje i mundur është diçka si një anti-model (një qasje joefektive dhe joproduktive). Në mënyrë ideale, korrigjimi kërkon një mjet që ndihmon ngushtoni zonën tuaj të kërkimit, në mënyrë që inxhinierët të mund të fokusohen në një nëngrup dimensionesh (shërbime/përdorues/host, etj.) që lidhen me skenarin e problemit që po shqyrtohet. Kur përcaktojnë shkakun e një dështimi, inxhinierëve nuk u kërkohet të kuptojnë se çfarë ndodhi gjatë të gjitha shërbimet në të njëjtën kohë, pasi një kërkesë e tillë do të binte ndesh me vetë idenë e arkitekturës së mikroshërbimit.
Megjithatë, traceview është domethënë Kjo. Po, disa sisteme gjurmimi ofrojnë pamje të ngjeshur të gjurmës kur numri i hapësirave në gjurmë është aq i madh sa nuk mund të shfaqen në një vizualizim. Megjithatë, për shkak të sasisë së madhe të informacionit që përmban edhe një vizualizim kaq i zhveshur, inxhinierët ende i detyruar "Shosh" atë, duke e ngushtuar manualisht përzgjedhjen në një grup shërbimesh që janë burime problemesh. Fatkeqësisht, në këtë fushë, makinat janë shumë më të shpejta se njerëzit, më pak të prirur ndaj gabimeve dhe rezultatet e tyre janë më të përsëritshme.
Një arsye tjetër që mendoj se traceview është e gabuar është sepse nuk është i mirë për korrigjimin e drejtuar nga hipoteza. Në thelbin e tij, korrigjimi është përsëritëse një proces që fillon me një hipotezë, i ndjekur nga verifikimi i vëzhgimeve dhe fakteve të ndryshme të marra nga sistemi përgjatë vektorëve të ndryshëm, përfundime/përgjithësime dhe vlerësimi i mëtejshëm i së vërtetës së hipotezës.
mundësi të shpejtë dhe të lirë testimi i hipotezave dhe përmirësimi i modelit mendor në përputhje me rrethanat është gur themeli korrigjimi Çdo mjet korrigjimi duhet të jetë interaktive dhe ngushtoni hapësirën e kërkimit ose, në rastin e një drejtimi të rremë, lejoni përdoruesin të kthehet dhe të fokusohet në një zonë tjetër të sistemit. Mjeti i përsosur do ta bëjë këtë në mënyrë proaktive, duke tërhequr menjëherë vëmendjen e përdoruesit në zonat e mundshme problematike.
Mjerisht, traceview nuk mund të quhet një mjet me një ndërfaqe interaktive. Më e mira për të cilën mund të shpresoni kur e përdorni është të gjeni një burim të vonesës së shtuar dhe të shikoni të gjitha etiketat dhe regjistrat e mundshëm që lidhen me të. Kjo nuk e ndihmon inxhinierin të identifikojë modele në trafik, të tilla si specifikat e shpërndarjes së vonesës, ose zbulojnë korrelacionet midis matjeve të ndryshme. mund të ndihmojë për të kapërcyer disa nga këto probleme. Vërtet, analiza e suksesshme duke përdorur mësimin e makinerive për të identifikuar hapësirat anormale dhe për të identifikuar një nëngrup etiketash që mund të shoqërohen me sjellje anormale. Sidoqoftë, nuk kam parë ende vizualizime bindëse të gjetjeve të mësimit të makinerive ose të nxjerrjes së të dhënave të aplikuara në hapësira që janë dukshëm të ndryshme nga një pamje gjurmuese ose një DAG (grafiku i drejtuar jociklik).
Hapësirat janë në nivel shumë të ulët
Problemi themelor me traceview është se shtrihet janë primitivë të nivelit shumë të ulët për analizën e vonesës dhe analizën e shkakut rrënjësor. Është njësoj si analizimi i komandave individuale të procesorit për t'u përpjekur për të zgjidhur një përjashtim, duke ditur se ka mjete të nivelit shumë më të lartë si backtrace, me të cilat janë shumë më të përshtatshme për të punuar.
Për më tepër, unë do të marr guximin të pohoj sa vijon: në mënyrë ideale, ne nuk kemi nevojë foto e plotë ka ndodhur gjatë ciklit jetësor të kërkesës, i cili përfaqësohet nga mjetet moderne të gjurmimit. Në vend të kësaj, kërkohet një formë e abstraksionit të nivelit më të lartë që përmban informacion rreth asaj shkoi keq (i ngjashëm me gjurmët prapa), së bashku me disa kontekst. Në vend që të shikoj të gjithë gjurmën, unë preferoj ta shoh atë часть, ku ndodh diçka interesante ose e pazakontë. Aktualisht, kërkimi kryhet me dorë: inxhinieri merr gjurmën dhe analizon në mënyrë të pavarur hapësirat në kërkim të diçkaje interesante. Qasja e njerëzve që shikojnë hapësirat në gjurmë individuale me shpresën për të zbuluar aktivitet të dyshimtë nuk përshkallëzohet fare (veçanërisht kur duhet të kuptojnë të gjitha meta të dhënat e koduara në hapësira të ndryshme, si p.sh. span ID, emri i metodës RPC, kohëzgjatja e hapësirës 'a, regjistrat, etiketat, etj.).
Alternativat për traceview
Rezultatet e gjurmimit janë më të dobishme kur ato mund të vizualizohen në një mënyrë që ofron një pasqyrë jo të parëndësishme për atë që po ndodh në pjesët e ndërlidhura të sistemit. Derisa të ndodhë kjo, procesi i korrigjimit mbetet kryesisht inerte dhe varet nga aftësia e përdoruesit për të vërejtur korrelacionet e duhura, për të kontrolluar pjesët e duhura të sistemit ose për të vendosur pjesët e enigmës së bashku - në krahasim me instrument, duke ndihmuar përdoruesin të formulojë këto hipoteza.
Unë nuk jam një dizajner vizual ose specialist UX, por në seksionin tjetër dua të ndaj disa ide se si mund të duken këto vizualizime.
Përqendrohuni në shërbime specifike
Në një kohë kur industria po konsolidohet rreth ideve , duket e arsyeshme që ekipet individuale duhet të kenë prioritet për t'u siguruar që shërbimet e tyre janë në përputhje me këto synime. Nga kjo rrjedh se i orientuar nga shërbimi vizualizimi është më i përshtatshmi për ekipe të tilla.
Gjurmët, veçanërisht pa marrjen e mostrave, janë një thesar informacioni për secilin komponent të një sistemi të shpërndarë. Ky informacion mund t'i jepet një procesori dinak që do të furnizojë përdoruesit i orientuar nga shërbimi gjetjet. Ato mund të identifikohen paraprakisht - edhe para se përdoruesi të shikojë gjurmët:
- Diagramet e shpërndarjes së vonesës vetëm për kërkesa shumë të spikatura (kërkesa të jashtme);
- Diagramet e shpërndarjes së vonesave për rastet kur qëllimet e SLO të shërbimit nuk janë arritur;
- Etiketat më "të zakonshme", "interesante" dhe "të çuditshme" në pyetjet që më shpesh janë përsëritur;
- Zbërthimi i vonesës për rastet kur зависимости shërbimet nuk i arrijnë qëllimet e tyre SLO;
- Ndarja e vonesës për shërbime të ndryshme në rrjedhën e poshtme.
Disa nga këto pyetje thjesht nuk marrin përgjigje nga metrikat e integruara, duke i detyruar përdoruesit të shqyrtojnë hapësirat. Si rezultat, ne kemi një mekanizëm jashtëzakonisht armiqësor ndaj përdoruesit.
Kjo ngre pyetjen: po në lidhje me ndërveprimet komplekse midis shërbimeve të ndryshme të kontrolluara nga ekipe të ndryshme? A nuk është ajo traceview nuk konsiderohet mjeti më i përshtatshëm për të evidentuar një situatë të tillë?
Zhvilluesit celularë, pronarët e shërbimeve pa shtetësi, pronarët e shërbimeve shtetërore të menaxhuara (si bazat e të dhënave) dhe pronarët e platformave mund të jenë të interesuar për diçka tjetër prezantim sistemi i shpërndarë; traceview është një zgjidhje shumë e përgjithshme për këto nevoja thelbësisht të ndryshme. Edhe në një arkitekturë shumë komplekse mikroshërbimi, pronarët e shërbimeve nuk kanë nevojë për njohuri të thella për më shumë se dy ose tre shërbime në rrjedhën e sipërme dhe të poshtme. Në thelb, në shumicën e skenarëve, përdoruesit duhet t'u përgjigjen vetëm pyetjeve në lidhje me grup i kufizuar shërbimesh.
Është si të shikosh një nëngrup të vogël shërbimesh përmes një xham zmadhues për hir të shqyrtimit të tij. Kjo do t'i lejojë përdoruesit të bëjë pyetje më të ngutshme në lidhje me ndërveprimet komplekse midis këtyre shërbimeve dhe varësive të tyre të menjëhershme. Kjo është e ngjashme me prapavijën në botën e shërbimeve, ku inxhinieri e di që gabim, dhe gjithashtu ka njëfarë kuptimi të asaj që po ndodh në shërbimet përreth për të kuptuar pse.
Qasja që unë po promovoj është saktësisht e kundërta e qasjes nga lart-poshtë, bazuar në pamjen e gjurmëve, ku analiza fillon me të gjithë gjurmën dhe më pas shkon gradualisht deri në shtrirje individuale. Në të kundërt, një qasje nga poshtë lart fillon duke analizuar një zonë të vogël afër shkakut të mundshëm të incidentit dhe më pas zgjeron hapësirën e kërkimit sipas nevojës (me potencialin e sjelljes së ekipeve të tjera për të analizuar një gamë më të gjerë shërbimesh). Qasja e dytë është më e përshtatshme për testimin e shpejtë të hipotezave fillestare. Pasi të merren rezultate konkrete, do të jetë e mundur të kalohet në një analizë më të fokusuar dhe më të detajuar.
Ndërtimi i një topologjie
Pamjet specifike të shërbimit mund të jenë tepër të dobishme nëse përdoruesi e di që një shërbim ose grup shërbimesh është përgjegjës për rritjen e vonesës ose shkaktimin e gabimeve. Megjithatë, në një sistem kompleks, identifikimi i shërbimit ofendues mund të jetë një detyrë jo e parëndësishme gjatë një dështimi, veçanërisht nëse nuk raportohen mesazhe gabimi nga shërbimet.
Ndërtimi i një topologjie shërbimi mund të jetë një ndihmë e madhe për të kuptuar se cili shërbim po përjeton një rritje të shkallës së gabimit ose një rritje të vonesës që po bën që shërbimi të degradohet dukshëm. Kur flas për ndërtimin e një topologjie, nuk e kam fjalën harta e shërbimeve, duke shfaqur çdo shërbim të disponueshëm në sistem dhe të njohur për të . Kjo pamje nuk është më e mirë se gjurmimi i bazuar në një grafik aciklik të drejtuar. Në vend të kësaj do të doja të shihja Topologjia e shërbimit të gjeneruar në mënyrë dinamike, bazuar në disa atribute të tilla si shkalla e gabimit, koha e përgjigjes ose ndonjë parametër i përcaktuar nga përdoruesi që ndihmon në sqarimin e situatës me shërbime specifike të dyshimta.
Le të marrim një shembull. Le të imagjinojmë një faqe hipotetike lajmesh. Shërbimi i faqes kryesore (faqja e parë) shkëmben të dhëna me Redis, me një shërbim rekomandimi, me një shërbim reklamimi dhe një shërbim video. Shërbimi video merr video nga S3 dhe meta të dhëna nga DynamoDB. Shërbimi i rekomandimit merr meta të dhëna nga DynamoDB, ngarkon të dhëna nga Redis dhe MySQL dhe i shkruan mesazhe Kafkës. Shërbimi i reklamave merr të dhëna nga MySQL dhe i shkruan mesazhe Kafkës.
Më poshtë është një paraqitje skematike e kësaj topologjie (shumë programe rutimi komerciale ndërtojnë topologjinë). Mund të jetë e dobishme nëse keni nevojë të kuptoni varësitë e shërbimit. Megjithatë, gjatë debug, kur një shërbim i caktuar (të themi, një shërbim video) shfaq rritje të kohës së përgjigjes, një topologji e tillë nuk është shumë e dobishme.
Diagrami i shërbimit të një faqeje lajmesh hipotetike
Diagrami më poshtë do të ishte më i përshtatshëm. Ka një problem me shërbimin (Video) përshkruar pikërisht në qendër. Përdoruesi e vëren menjëherë. Nga ky vizualizim, bëhet e qartë se shërbimi i videos po funksionon në mënyrë jonormale për shkak të rritjes së kohës së përgjigjes S3, gjë që ndikon në shpejtësinë e ngarkimit të një pjese të faqes kryesore.
Topologjia dinamike që shfaq vetëm shërbime "interesante".
Topologjitë e gjeneruara në mënyrë dinamike mund të jenë më efikase se hartat statike të shërbimit, veçanërisht në infrastrukturat elastike, me shkallëzim automatik. Aftësia për të krahasuar dhe kontrastuar topologjitë e shërbimit i lejon përdoruesit të bëjë pyetje më të rëndësishme. Pyetjet më të sakta rreth sistemit kanë më shumë gjasa të çojnë në një kuptim më të mirë se si funksionon sistemi.
Shfaqja krahasuese
Një tjetër vizualizim i dobishëm do të ishte një shfaqje krahasuese. Aktualisht gjurmët nuk janë shumë të përshtatshme për krahasime krah për krah, kështu që krahasimet janë zakonisht shtrihet. Dhe ideja kryesore e këtij artikulli është pikërisht se hapësirat janë shumë të ulëta për të nxjerrë informacionin më të vlefshëm nga rezultatet e gjurmës.
Krahasimi i dy gjurmëve nuk kërkon vizualizime thelbësisht të reja. Në fakt, diçka si një histogram që përfaqëson të njëjtin informacion si një pamje gjurmuese është e mjaftueshme. Çuditërisht, edhe kjo metodë e thjeshtë mund të sjellë shumë më tepër fryt sesa thjesht studimi i dy gjurmëve veç e veç. Edhe më e fuqishme do të ishte mundësia vizualizoj krahasimi i gjurmëve Në total. Do të ishte jashtëzakonisht e dobishme të shihet se si një ndryshim i konfigurimit të bazës së të dhënave të vendosur së fundi për të aktivizuar GC (mbledhja e mbeturinave) ndikon në kohën e përgjigjes së një shërbimi në rrjedhën e poshtme në një shkallë prej disa orësh. Nëse kjo që po përshkruaj këtu tingëllon si një analizë A/B e ndikimit të ndryshimeve në infrastrukturë në shumë shërbime duke përdorur rezultatet e gjurmës, atëherë nuk jeni shumë larg së vërtetës.
Përfundim
Unë nuk e vë në dyshim dobinë e vetë gjurmimit. Unë sinqerisht besoj se nuk ka asnjë metodë tjetër për mbledhjen e të dhënave aq të pasura, kauzale dhe kontekstuale sa ajo që përmban një gjurmë. Megjithatë, unë gjithashtu besoj se të gjitha zgjidhjet e gjurmimit i përdorin këto të dhëna jashtëzakonisht joefikase. Për sa kohë që mjetet e gjurmimit mbeten të mbërthyera në paraqitjen e pamjes së gjurmës, ato do të jenë të kufizuara në aftësinë e tyre për të shfrytëzuar sa më shumë informacionin e vlefshëm që mund të nxirret nga të dhënat e përfshira në gjurmë. Përveç kësaj, ekziston rreziku i zhvillimit të mëtejshëm të një ndërfaqe vizuale krejtësisht jo miqësore dhe jointuitive që do të kufizojë ndjeshëm aftësinë e përdoruesit për të zgjidhur gabimet në aplikacion.
Korrigjimi i sistemeve komplekse, edhe me mjetet më të fundit, është tepër i vështirë. Mjetet duhet të ndihmojnë zhvilluesin të formulojë dhe testojë një hipotezë, duke siguruar në mënyrë aktive informacionet përkatëse, duke identifikuar pikat e jashtme dhe duke vënë në dukje veçoritë në shpërndarjen e vonesave. Që gjurmimi të bëhet mjeti i zgjedhur për zhvilluesit kur zgjidhin problemet e dështimeve të prodhimit ose zgjidhjen e problemeve që përfshijnë shërbime të shumta, nevojiten ndërfaqe origjinale të përdoruesit dhe vizualizime që janë më në përputhje me modelin mendor të zhvilluesve që krijojnë dhe operojnë ato shërbime.
Do të duhen përpjekje të konsiderueshme mendore për të hartuar një sistem që do të përfaqësojë sinjalet e ndryshme të disponueshme në rezultatet e gjurmës në një mënyrë që të jetë e optimizuar për lehtësinë e analizës dhe përfundimit. Ju duhet të mendoni se si të abstragoni topologjinë e sistemit gjatë korrigjimit në një mënyrë që e ndihmon përdoruesin të kapërcejë pikat e verbëra pa shikuar gjurmët ose hapësirat individuale.
Ne kemi nevojë për aftësi të mira abstraksioni dhe shtresimi (veçanërisht në UI). Ato që do të përshtateshin mirë në një proces korrigjimi të drejtuar nga hipoteza, ku mund të bëni pyetje në mënyrë të përsëritur dhe të testoni hipoteza. Ata nuk do të zgjidhin automatikisht të gjitha problemet e vëzhgimit, por do t'i ndihmojnë përdoruesit të mprehin intuitën e tyre dhe të formulojnë pyetje më të zgjuara. Unë bëj thirrje për një qasje më të menduar dhe inovative ndaj vizualizimit. Këtu ka një perspektivë reale për të zgjeruar horizontet.
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «'.
Burimi: www.habr.com