Tandaan. transl.: Ang may-akda ng materyal na ito ay si Cindy Sridharan, isang inhinyero sa imgix na dalubhasa sa pagbuo ng API at, sa partikular, pagsubok ng microservice. Sa materyal na ito, ibinahagi niya ang kanyang detalyadong pananaw sa mga kasalukuyang problema sa larangan ng distributed tracing, kung saan, sa kanyang opinyon, may kakulangan ng tunay na epektibong mga tool para sa paglutas ng mga problema sa pagpindot.
[Ilustrasyon na kinuha mula sa tungkol sa distributed tracing.]
Ito ay pinaniniwalaan na mahirap ipatupad, at ang pagbabalik dito . Maraming dahilan kung bakit may problema ang pagsubaybay, kadalasang binabanggit ang labor na kasangkot sa pag-configure ng bawat bahagi ng system upang maihatid ang naaangkop na mga header sa bawat kahilingan. Kahit na ang problemang ito ay umiiral, ito ay hindi nangangahulugang hindi malulutas. Sa pamamagitan ng paraan, hindi nito ipinapaliwanag kung bakit hindi talaga gusto ng mga developer ang pagsubaybay (kahit na gumagana na ito).
Ang pangunahing hamon sa distributed tracing ay hindi pagkolekta ng data, pag-standardize ng mga format para sa pamamahagi at pagpapakita ng mga resulta, o pagtukoy kung kailan, saan, at kung paano magsampol. Hindi ko sinusubukang isipin walang kuwenta ang mga "problema sa pag-unawa" na ito ay, sa katunayan, medyo makabuluhang teknikal at (kung isasaalang-alang namin ang tunay na Open Source) ) mga hamon sa pulitika na kailangang lagpasan upang ang mga problemang ito ay maituturing na lutasin.
Gayunpaman, kung akala natin na ang lahat ng mga problemang ito ay malulutas, may mataas na posibilidad na walang makabuluhang pagbabago sa mga tuntunin ng karanasan ng end user. Maaaring hindi pa rin praktikal ang pagsubaybay sa mga pinakakaraniwang sitwasyon sa pag-debug—kahit na matapos na itong i-deploy.
Parang ibang bakas
Kasama sa ibinahagi na pagsubaybay ang ilang magkakaibang bahagi:
- equipping application at middleware na may control tool;
- distributed context transfer;
- koleksyon ng mga bakas;
- imbakan ng bakas;
- kanilang pagkuha at visualization.
Ang maraming usapan tungkol sa distributed tracing ay may posibilidad na ituring ito bilang isang uri ng unary operation na ang tanging layunin ay tumulong sa ganap na pag-diagnose ng system. Ito ay higit sa lahat dahil sa kung paano nabuo ang mga ideya tungkol sa distributed tracing. SA , na ginawa noong binuksan ang mga mapagkukunan ng Zipkin, nabanggit na pinapabilis nito [Zipkin] ang Twitter. Ang mga unang komersyal na handog para sa pagsubaybay ay na-promote din bilang .
Tandaan. transl.: Upang gawing mas madaling maunawaan ang karagdagang teksto, tukuyin natin ang dalawang pangunahing termino ayon sa :
- Maikling panahon — ang pangunahing elemento ng distributed tracing. Ito ay isang paglalarawan ng isang tiyak na daloy ng trabaho (halimbawa, isang query sa database) na may pangalan, oras ng pagsisimula at pagtatapos, mga tag, log at konteksto.
- Ang mga span ay karaniwang naglalaman ng mga link sa iba pang mga span, na nagpapahintulot sa maramihang mga span na pagsamahin Kopyahin o sipiin sa pamamagitan ng pag-aninag — visualization ng buhay ng isang kahilingan habang ito ay gumagalaw sa isang distributed system.
Naglalaman ang mga bakas ng hindi kapani-paniwalang mahalagang data na maaaring makatulong sa mga gawain tulad ng pagsubok sa produksyon, pagsubok sa pagbawi ng kalamidad, pagsubok sa pag-iniksyon ng error, atbp. Sa katunayan, ang ilang mga kumpanya ay gumagamit na ng pagsubaybay para sa mga katulad na layunin. Magsimula tayo sa ay may iba pang gamit bukod sa simpleng paglipat ng mga span sa storage system:
- Halimbawa, Uber pagsubaybay sa mga resulta upang matukoy ang pagkakaiba sa pagitan ng pansubok na trapiko at trapiko ng produksyon.
- Facebook trace data para sa critical path analysis at para sa traffic switching sa panahon ng mga regular na pagsubok sa pagbawi ng kalamidad.
- Gayundin ang social network Mga Jupyter notebook na nagpapahintulot sa mga developer na magpatakbo ng mga arbitrary na query sa mga resulta ng pagsubaybay.
- Mga tagasunod (Lineage Driven Failure Injection) namamahagi ng mga bakas para sa pagsubok na may error na iniksyon.
Wala sa mga opsyon na nakalista sa itaas ang ganap na nalalapat sa senaryo pag-debug, kung saan sinusubukan ng inhinyero na lutasin ang problema sa pamamagitan ng pagtingin sa bakas.
Pagdating pa umabot sa debugging script, ang pangunahing interface ay nananatiling diagram traceview (bagaman tinatawag din ito ng ilan "Gantt chart" o "diagram ng talon"). Sa ilalim traceview я lahat ng mga span at kasamang metadata na magkasamang bumubuo sa bakas. Ang bawat open source tracing system, gayundin ang bawat commercial tracing solution, ay nag-aalok ng traceview user interface para sa paggunita, pagdedetalye at pag-filter ng mga bakas.
Ang problema sa lahat ng mga sistema ng pagsubaybay na nakita ko sa ngayon ay ang resulta visualization (traceview) halos ganap na sumasalamin sa mga tampok ng proseso ng pagbuo ng bakas. Kahit na iminungkahi ang mga alternatibong visualization: mga heatmap, mga topolohiya ng serbisyo, mga histogram ng latency, bumababa pa rin ang mga ito sa huli. traceview.
Noong nakaraan I na ang karamihan sa mga "makabagong ideya" sa pagsubaybay sa UI/UX ay tila limitado sa karagdagang metadata sa bakas, pamumuhunan sa kanila ng impormasyon na may mataas na cardinality (high-cardinality) o pagbibigay ng kakayahang mag-drill down sa mga partikular na saklaw o magpatakbo ng mga query inter- at intra-trace... Kung saan traceview nananatiling pangunahing visualization tool. Hangga't nagpapatuloy ang estadong ito, ang distributed tracing ay (sa pinakamaganda) ay kukuha ng ika-4 na puwesto bilang isang tool sa pag-debug, pagkatapos ng mga sukatan, log at stack trace, at sa pinakamasama ito ay magiging isang pag-aaksaya ng pera at oras.
Problema sa traceview
Layunin traceview — magbigay ng kumpletong larawan ng paggalaw ng isang kahilingan sa lahat ng bahagi ng ipinamamahaging sistema kung saan ito nauugnay. Nagbibigay-daan sa iyo ang ilang mas advanced na tracing system na mag-drill down sa mga indibidwal na saklaw at tingnan ang breakdown sa paglipas ng panahon sa loob isang proseso (kapag may functional boundaries ang mga span).
Ang pangunahing saligan ng arkitektura ng microservices ay ang ideya na ang istraktura ng organisasyon ay lumalaki sa mga pangangailangan ng kumpanya. Ang mga tagapagtaguyod ng mga microservice ay nangangatwiran na ang pamamahagi ng iba't ibang mga gawain sa negosyo sa mga indibidwal na serbisyo ay nagbibigay-daan sa maliliit, nagsasarili na mga development team na kontrolin ang buong lifecycle ng mga naturang serbisyo, na nagbibigay sa kanila ng kakayahang mag-isa na bumuo, sumubok, at mag-deploy ng mga serbisyong iyon. Gayunpaman, ang kawalan ng pamamahagi na ito ay ang pagkawala ng impormasyon tungkol sa kung paano nakikipag-ugnayan ang bawat serbisyo sa iba. Sa ganitong mga kundisyon, ang ipinamahagi na pagsubaybay ay sinasabing isang kailangang-kailangan na tool para sa pag-debug kumplikadong pakikipag-ugnayan sa pagitan ng mga serbisyo.
Kung ikaw talaga , kung gayon walang sinumang tao ang makapag-iingat nito sa kanyang isipan kumpleto larawan. Sa katunayan, ang pagbuo ng isang tool batay sa pag-aakalang posible pa nga ito ay isang anti-pattern (isang hindi epektibo at hindi produktibong diskarte). Sa isip, ang pag-debug ay nangangailangan ng tool na makakatulong paliitin ang iyong lugar sa paghahanap, para makapag-focus ang mga inhinyero sa isang subset ng mga dimensyon (mga serbisyo/user/host, atbp.) na nauugnay sa sitwasyong problema na isinasaalang-alang. Kapag tinutukoy ang sanhi ng isang pagkabigo, ang mga inhinyero ay hindi kinakailangang maunawaan kung ano ang nangyari sa panahon ng lahat ng serbisyo nang sabay-sabay, dahil ang naturang pangangailangan ay sasalungat sa mismong ideya ng arkitektura ng microservice.
Gayunpaman, ang traceview ay lalo Ito. Oo, nag-aalok ang ilang tracing system ng mga naka-compress na traceview kapag ang bilang ng mga span sa trace ay napakalaki kaya hindi sila maipapakita sa isang visualization. Gayunpaman, dahil sa malaking halaga ng impormasyong nakapaloob kahit na sa naturang stripped-down visualization, inhinyero pa rin pinilit "isahan" ito, manu-manong pinapaliit ang pagpili sa isang hanay ng mga serbisyo na pinagmumulan ng mga problema. Sa kasamaang palad, sa larangang ito, ang mga makina ay mas mabilis kaysa sa mga tao, hindi gaanong madaling kapitan ng mga pagkakamali, at ang kanilang mga resulta ay mas nauulit.
Ang isa pang dahilan sa tingin ko ay mali ang traceview ay dahil hindi ito maganda para sa pag-debug na batay sa hypothesis. Sa kaibuturan nito, ang pag-debug ay umuulit isang proseso na nagsisimula sa isang hypothesis, na sinusundan ng pag-verify ng iba't ibang mga obserbasyon at katotohanan na nakuha mula sa system kasama ang iba't ibang mga vectors, mga konklusyon/generalization at karagdagang pagtatasa ng katotohanan ng hypothesis.
Pagkakataon mabilis at mura pagsubok ng mga hypotheses at pagpapabuti ng mental na modelo nang naaayon ay batong panulok pag-debug Anumang tool sa pag-debug ay dapat na interactive at paliitin ang espasyo sa paghahanap o, sa kaso ng maling lead, payagan ang user na bumalik at tumuon sa ibang bahagi ng system. Gagawin ito ng perpektong tool proactively, agad na iginuhit ang atensyon ng gumagamit sa mga potensyal na lugar ng problema.
Naku, traceview ay hindi matatawag na tool na may interactive na interface. Ang pinakamahusay na maaasahan mo kapag ginagamit ito ay ang maghanap ng ilang pinagmulan ng tumaas na latency at tingnan ang lahat ng posibleng mga tag at log na nauugnay dito. Hindi ito nakakatulong sa engineer na makilala mga pattern sa trapiko, gaya ng mga detalye ng pamamahagi ng pagkaantala, o makakita ng mga ugnayan sa pagitan ng iba't ibang mga sukat. maaaring makatulong sa paglutas ng ilan sa mga problemang ito. Talaga, matagumpay na pagsusuri gamit ang machine learning para matukoy ang mga anomalyang span at tumukoy ng subset ng mga tag na maaaring nauugnay sa maanomalyang gawi. Gayunpaman, wala pa akong nakikitang nakakahimok na visualization ng machine learning o data mining na mga natuklasan na inilapat sa mga span na makabuluhang naiiba sa isang traceview o isang DAG (directed acyclic graph).
Ang mga span ay masyadong mababa ang antas
Ang pangunahing problema sa traceview ay iyon sumasaklaw ay masyadong mababang antas ng mga primitive para sa parehong latency analysis at root cause analysis. Ito ay tulad ng pag-parse ng mga indibidwal na utos ng processor upang subukang lutasin ang isang pagbubukod, alam na mayroong mas mataas na antas ng mga tool tulad ng backtrace na mas maginhawang gamitin.
Bukod dito, gagawin ko ang kalayaan na igiit ang mga sumusunod: sa isip, hindi natin kailangan buong larawan naganap sa panahon ng lifecycle ng kahilingan, na kinakatawan ng mga modernong tool sa pagsubaybay. Sa halip, kinakailangan ang ilang anyo ng mas mataas na antas ng abstraction na naglalaman ng impormasyon tungkol sa kung ano nagkamali (katulad ng backtrace), kasama ang ilang konteksto. Sa halip na panoorin ang buong bakas, mas gusto kong makita ito часть, kung saan may nangyayaring kawili-wili o hindi pangkaraniwang bagay. Sa kasalukuyan, ang paghahanap ay isinasagawa nang manu-mano: natatanggap ng inhinyero ang bakas at nakapag-iisa na sinusuri ang mga span sa paghahanap ng isang bagay na kawili-wili. Ang diskarte ng mga taong tumitingin sa mga span sa mga indibidwal na bakas sa pag-asang maka-detect ng kahina-hinalang aktibidad ay hindi gaanong sukat (lalo na kapag kailangan nilang maunawaan ang lahat ng metadata na naka-encode sa iba't ibang span, gaya ng span ID, pangalan ng paraan ng RPC, tagal ng span 'a, mga tala, mga tag, atbp.).
Mga alternatibo sa traceview
Ang mga resulta ng pagsubaybay ay pinaka-kapaki-pakinabang kapag ang mga ito ay maipapakita sa paraang nagbibigay ng walang kabuluhang insight sa kung ano ang nangyayari sa magkakaugnay na bahagi ng system. Hanggang sa mangyari ito, nananatili ang proseso ng pag-debug hindi gumagalaw at depende sa kakayahan ng user na mapansin ang mga tamang ugnayan, suriin ang mga tamang bahagi ng system, o pagsama-samahin ang mga piraso ng puzzle - kumpara sa tool, na tumutulong sa user na bumalangkas ng mga hypotheses na ito.
Hindi ako visual designer o UX specialist, ngunit sa susunod na seksyon gusto kong magbahagi ng ilang ideya kung ano ang maaaring hitsura ng mga visualization na ito.
Tumutok sa mga partikular na serbisyo
Sa panahon na ang industriya ay nagsasama-sama sa paligid ng mga ideya , tila makatwiran na dapat unahin ng mga indibidwal na koponan ang pagtiyak na ang kanilang mga serbisyo ay naaayon sa mga layuning ito. Sinusundan nito iyon nakatuon sa serbisyo Ang visualization ay pinakaangkop para sa mga naturang koponan.
Ang mga bakas, lalo na nang walang sampling, ay isang kayamanan ng impormasyon tungkol sa bawat bahagi ng isang distributed system. Ang impormasyong ito ay maaaring ibigay sa isang tusong processor na magbibigay ng mga user nakatuon sa serbisyo mga natuklasan. Maaari silang matukoy nang maaga - bago pa man tingnan ng gumagamit ang mga bakas:
- Ang mga diagram ng pamamahagi ng latency ay para lamang sa mga kilalang kahilingan (mga outlier na kahilingan);
- Mga diagram ng pamamahagi ng pagkaantala para sa mga kaso kapag hindi nakamit ang mga layunin ng SLO ng serbisyo;
- Ang pinaka-"karaniwan", "kawili-wili" at "kakaiba" na mga tag sa mga query na pinakamadalas ay paulit-ulit;
- Latency breakdown para sa mga kaso kung saan dependencies hindi nakakamit ng mga serbisyo ang kanilang mga layunin sa SLO;
- Latency breakdown para sa iba't ibang downstream na serbisyo.
Ang ilan sa mga tanong na ito ay hindi sinasagot ng mga built-in na sukatan, na pumipilit sa mga user na suriing mabuti ang mga saklaw. Bilang isang resulta, mayroon kaming isang mekanismo na lubhang pagalit ng gumagamit.
Ibinabangon nito ang tanong: kumusta naman ang mga kumplikadong pakikipag-ugnayan sa pagitan ng magkakaibang serbisyo na kinokontrol ng iba't ibang team? di ba traceview ay hindi itinuturing na pinakaangkop na tool upang i-highlight ang ganoong sitwasyon?
Ang mga mobile developer, mga may-ari ng stateless na serbisyo, mga may-ari ng mga pinamamahalaang stateful na serbisyo (tulad ng mga database) at mga may-ari ng platform ay maaaring interesado sa ibang bagay pagtatanghal ibinahagi na sistema; traceview ay masyadong generic na solusyon para sa mga pangunahing pangangailangang ito. Kahit na sa isang napakakomplikadong microservice architecture, ang mga may-ari ng serbisyo ay hindi nangangailangan ng malalim na kaalaman sa higit sa dalawa o tatlong upstream at downstream na serbisyo. Sa pangkalahatan, sa karamihan ng mga senaryo, kailangan lang sagutin ng mga user ang mga tanong tungkol sa limitadong hanay ng mga serbisyo.
Ito ay tulad ng pagtingin sa isang maliit na subset ng mga serbisyo sa pamamagitan ng isang magnifying glass para sa kapakanan ng pagsusuri dito. Ito ay magbibigay-daan sa user na magtanong ng higit pang pagpindot sa mga tanong tungkol sa mga kumplikadong pakikipag-ugnayan sa pagitan ng mga serbisyong ito at ng kanilang mga agarang dependency. Ito ay katulad ng backtrace sa mundo ng mga serbisyo, kung saan alam ng engineer na mali, at mayroon ding ilang pag-unawa sa kung ano ang nangyayari sa mga nakapaligid na serbisyo upang maunawaan bakit.
Ang diskarte na aking isinusulong ay ang eksaktong kabaligtaran ng top-down, traceview-based na diskarte, kung saan ang pagsusuri ay nagsisimula sa buong bakas at pagkatapos ay unti-unting gumagana hanggang sa mga indibidwal na tagal. Sa kabaligtaran, nagsisimula ang isang bottom-up na diskarte sa pamamagitan ng pagsusuri sa isang maliit na lugar na malapit sa potensyal na sanhi ng insidente, at pagkatapos ay palawakin ang espasyo sa paghahanap kung kinakailangan (na may potensyal na magdala ng iba pang mga koponan upang suriin ang isang mas malawak na hanay ng mga serbisyo). Ang pangalawang diskarte ay mas angkop para sa mabilis na pagsubok ng mga paunang hypotheses. Sa sandaling makuha ang mga konkretong resulta, magiging posible na lumipat sa isang mas naka-target at detalyadong pagsusuri.
Pagbuo ng topology
Ang mga view na partikular sa serbisyo ay maaaring maging lubhang kapaki-pakinabang kung alam ng user ano ang isang serbisyo o pangkat ng mga serbisyo ay may pananagutan para sa pagtaas ng latency o magdulot ng mga error. Gayunpaman, sa isang kumplikadong sistema, ang pagtukoy sa nakakasakit na serbisyo ay maaaring isang hindi maliit na gawain sa panahon ng pagkabigo, lalo na kung walang mga mensahe ng error na naiulat mula sa mga serbisyo.
Ang pagbuo ng topology ng serbisyo ay maaaring maging isang malaking tulong sa pag-alam kung aling serbisyo ang nakakaranas ng pagtaas ng mga rate ng error o pagtaas ng latency na nagiging sanhi ng kapansin-pansing pagbaba ng serbisyo. Kapag pinag-uusapan ko ang pagbuo ng isang topology, hindi ko ibig sabihin mapa ng mga serbisyo, na ipinapakita ang bawat serbisyong magagamit sa system at kilala sa mga ito . Ang view na ito ay hindi mas mahusay kaysa sa traceview batay sa isang nakadirekta na acyclic graph. Sa halip ay gusto kong makita dynamic na nabuong topology ng serbisyo, batay sa ilang partikular na katangian gaya ng rate ng error, oras ng pagtugon, o anumang parameter na tinukoy ng user na tumutulong na linawin ang sitwasyon sa mga partikular na kahina-hinalang serbisyo.
Kumuha tayo ng isang halimbawa. Isipin natin ang isang hypothetical na site ng balita. Serbisyo sa home page (unang pahina) nakikipagpalitan ng data sa Redis, sa isang serbisyo ng rekomendasyon, sa isang serbisyo sa advertising at isang serbisyo ng video. Ang serbisyo ng video ay kumukuha ng mga video mula sa S3 at metadata mula sa DynamoDB. Ang serbisyo ng rekomendasyon ay tumatanggap ng metadata mula sa DynamoDB, naglo-load ng data mula sa Redis at MySQL, at nagsusulat ng mga mensahe sa Kafka. Ang serbisyo sa advertising ay tumatanggap ng data mula sa MySQL at nagsusulat ng mga mensahe sa Kafka.
Nasa ibaba ang isang eskematiko na representasyon ng topology na ito (maraming mga komersyal na programa sa pagruruta ang bumubuo ng topology). Maaari itong maging kapaki-pakinabang kung kailangan mong maunawaan ang mga dependency ng serbisyo. Gayunpaman, sa panahon ng pag-debug, kapag ang isang partikular na serbisyo (sabihin, isang serbisyo ng video) ay nagpapakita ng mas mataas na oras ng pagtugon, ang naturang topology ay hindi masyadong kapaki-pakinabang.
Service diagram ng isang hypothetical na site ng balita
Ang diagram sa ibaba ay magiging mas angkop. May problema sa serbisyo (Video) inilalarawan mismo sa gitna. Napansin agad ito ng user. Mula sa visualization na ito, nagiging malinaw na ang serbisyo ng video ay gumagana nang abnormal dahil sa pagtaas ng oras ng pagtugon ng S3, na nakakaapekto sa bilis ng paglo-load ng bahagi ng pangunahing pahina.
Dynamic na topology na nagpapakita lamang ng "kawili-wiling" mga serbisyo
Ang mga dynamic na nabuong topologies ay maaaring maging mas mahusay kaysa sa mga static na mapa ng serbisyo, lalo na sa nababanat, awtomatikong pag-scale ng mga imprastraktura. Ang kakayahang maghambing at mag-contrast ng mga topolohiya ng serbisyo ay nagbibigay-daan sa gumagamit na magtanong ng mas may kaugnayang mga katanungan. Ang mas tumpak na mga tanong tungkol sa system ay mas malamang na humantong sa isang mas mahusay na pag-unawa sa kung paano gumagana ang system.
Pagpapakita ng paghahambing
Ang isa pang kapaki-pakinabang na visualization ay isang comparative display. Sa kasalukuyan, ang mga bakas ay hindi masyadong angkop para sa magkatabing paghahambing, kaya karaniwan ay ang mga paghahambing sumasaklaw. At ang pangunahing ideya ng artikulong ito ay tiyak na ang mga span ay masyadong mababa ang antas upang kunin ang pinakamahalagang impormasyon mula sa mga resulta ng bakas.
Ang paghahambing ng dalawang bakas ay hindi nangangailangan ng panimula ng mga bagong visualization. Sa katunayan, ang isang bagay tulad ng isang histogram na kumakatawan sa parehong impormasyon bilang isang traceview ay sapat na. Nakakagulat, kahit na ang simpleng paraan na ito ay maaaring magdulot ng higit na bunga kaysa sa simpleng pag-aaral ng dalawang bakas nang magkahiwalay. Mas malakas pa ang posibilidad mag-visualize paghahambing ng mga bakas Sa kabuuan. Magiging lubhang kapaki-pakinabang na makita kung paano naaapektuhan ng isang kamakailang na-deploy na pagbabago sa configuration ng database upang paganahin ang GC (pagkolekta ng basura) sa oras ng pagtugon ng isang downstream na serbisyo sa isang sukat na ilang oras. Kung ang inilalarawan ko dito ay parang A/B analysis ng epekto ng mga pagbabago sa imprastraktura sa maraming serbisyo gamit ang mga resulta ng bakas, kung gayon hindi ka masyadong malayo sa katotohanan.
Konklusyon
Hindi ko kinukuwestiyon ang pagiging kapaki-pakinabang ng pagsubaybay mismo. Taos-puso akong naniniwala na walang ibang paraan para sa pagkolekta ng data na kasingyaman, sanhi at konteksto gaya ng nasa isang bakas. Gayunpaman, naniniwala din ako na ang lahat ng mga solusyon sa pagsubaybay ay gumagamit ng data na ito nang labis na hindi epektibo. Hangga't nananatili ang mga tool sa pagsubaybay sa representasyon ng traceview, malilimitahan ang mga ito sa kanilang kakayahang sulitin ang mahahalagang impormasyon na maaaring makuha mula sa data na nilalaman ng mga bakas. Bilang karagdagan, may panganib na higit pang bumuo ng isang ganap na hindi palakaibigan at hindi intuitive na visual na interface na lubos na maglilimita sa kakayahan ng user na i-troubleshoot ang mga error sa application.
Ang pag-debug ng mga kumplikadong system, kahit na may mga pinakabagong tool, ay napakahirap. Ang mga tool ay dapat makatulong sa developer na bumalangkas at sumubok ng hypothesis, aktibong nagbibigay may-katuturang impormasyon, pagtukoy ng mga outlier at pagpuna sa mga tampok sa pamamahagi ng mga pagkaantala. Para sa pagsubaybay upang maging tool ng pagpili para sa mga developer kapag nag-troubleshoot ng mga pagkabigo sa produksyon o paglutas ng mga problema na sumasaklaw sa maraming serbisyo, kailangan ang mga orihinal na user interface at visualization na mas pare-pareho sa mental na modelo ng mga developer na gumagawa at nagpapatakbo ng mga serbisyong iyon.
Mangangailangan ng makabuluhang pagsisikap sa pag-iisip upang magdisenyo ng isang sistema na kakatawan sa iba't ibang mga signal na magagamit sa mga resulta ng bakas sa isang paraan na na-optimize para sa kadalian ng pagsusuri at paghihinuha. Kailangan mong pag-isipan kung paano i-abstract ang topology ng system sa panahon ng pag-debug sa paraang makakatulong sa user na malampasan ang mga blind spot nang hindi tumitingin sa mga indibidwal na bakas o span.
Kailangan namin ng mahusay na abstraction at layering na mga kakayahan (lalo na sa UI). Mga bagay na akma sa isang proseso ng pag-debug na batay sa hypothesis kung saan maaari kang paulit-ulit na magtanong at sumubok ng mga hypotheses. Hindi nila awtomatikong malulutas ang lahat ng problema sa pagmamasid, ngunit tutulungan nila ang mga user na patalasin ang kanilang intuwisyon at bumuo ng mas matalinong mga tanong. Tumawag ako para sa isang mas maalalahanin at makabagong diskarte sa visualization. Mayroong isang tunay na pag-asa dito upang palawakin ang mga abot-tanaw.
PS mula sa tagasalin
Basahin din sa aming blog:
- «";
- «";
- «'.
Pinagmulan: www.habr.com