Nodyn. traws.: Awdur y deunydd hwn yw Cindy Sridharan, peiriannydd yn imgix sy'n arbenigo mewn datblygu API ac, yn benodol, profi microservice. Yn y deunydd hwn, mae'n rhannu ei gweledigaeth fanwl o broblemau cyfredol ym maes olrhain gwasgaredig, lle, yn ei barn hi, mae diffyg offer gwirioneddol effeithiol ar gyfer datrys problemau dybryd.
[Darlun a gymerwyd o am olrhain dosranedig.]
Credir bod anodd ei weithredu, a'r elw arno . Mae yna lawer o resymau pam mae olrhain yn broblemus, gan gyfeirio'n aml at y llafur sy'n gysylltiedig â ffurfweddu pob cydran system i drosglwyddo'r penawdau priodol gyda phob cais. Er bod y broblem hon yn bodoli, nid yw'n anorchfygol o bell ffordd. Gyda llaw, nid yw'n esbonio pam nad yw datblygwyr yn hoff iawn o olrhain (hyd yn oed pan mae eisoes yn gweithredu).
Y brif her gydag olrhain gwasgaredig yw peidio â chasglu data, safoni fformatau ar gyfer dosbarthu a chyflwyno canlyniadau, na phenderfynu pryd, ble, a sut i samplu. Dydw i ddim yn ceisio dychmygu dibwys mae'r "problemau dealladwy" hyn, mewn gwirionedd, yn dechnegol eithaf arwyddocaol ac (os ydym yn ystyried Ffynhonnell Agored wirioneddol) ) heriau gwleidyddol y mae angen eu goresgyn er mwyn ystyried datrys y problemau hyn.
Fodd bynnag, os dychmygwn fod yr holl broblemau hyn yn cael eu datrys, mae tebygolrwydd uchel na fydd dim yn newid yn sylweddol o ran profiad defnyddiwr terfynol. Mae'n bosibl na fydd olrhain yn ymarferol o hyd yn y senarios dadfygio mwyaf cyffredin - hyd yn oed ar ôl iddo gael ei ddefnyddio.
Olion mor wahanol
Mae olrhain gwasgaredig yn cynnwys sawl cydran wahanol:
- rhoi offer rheoli i gymwysiadau a nwyddau canol;
- trosglwyddo cyd-destun gwasgaredig;
- casglu olion;
- storio olion;
- eu hechdynnu a delweddu.
Mae llawer o sôn am olrhain gwasgaredig yn tueddu i'w drin fel math o weithrediad unari a'i unig ddiben yw helpu i wneud diagnosis llawn o'r system. Mae hyn yn bennaf oherwydd sut y ffurfiwyd syniadau am olrhain gwasgaredig yn hanesyddol. YN , a wnaed pan agorwyd y ffynonellau Zipkin, crybwyllwyd hynny mae [Zipkin] yn gwneud Twitter yn gyflymach. Hyrwyddwyd hefyd y cynigion masnachol cyntaf ar gyfer olrhain fel .
Nodyn. traws.: I wneud testun pellach yn haws i'w ddeall, gadewch inni ddiffinio dau derm sylfaenol yn ôl :
- Rhychwant — elfen sylfaenol olrhain gwasgaredig. Mae'n ddisgrifiad o lif gwaith penodol (er enghraifft, ymholiad cronfa ddata) gydag enw, amseroedd cychwyn a gorffen, tagiau, logiau a chyd-destun.
- Mae rhychwantau fel arfer yn cynnwys cysylltiadau â rhychwantau eraill, gan ganiatáu cyfuno rhychwantau lluosog i mewn Olrhain — delweddu oes cais wrth iddo symud trwy system ddosbarthedig.
Mae olion yn cynnwys data hynod werthfawr a all helpu gyda thasgau fel profi cynhyrchu, profion adfer mewn trychineb, profion chwistrellu gwall, ac ati. Mewn gwirionedd, mae rhai cwmnïau eisoes yn defnyddio olrhain at ddibenion tebyg. Gadewch i ni ddechrau mae ganddo ddefnyddiau eraill ar wahân i symud rhychwantau i'r system storio:
- Er enghraifft, Uber olrhain canlyniadau i wahaniaethu rhwng traffig prawf a thraffig cynhyrchu.
- Facebook olrhain data ar gyfer dadansoddi llwybrau critigol ac ar gyfer newid traffig yn ystod profion adfer ar ôl trychineb rheolaidd.
- Hefyd rhwydwaith cymdeithasol Llyfrau nodiadau Jupyter sy'n caniatáu i ddatblygwyr redeg ymholiadau mympwyol ar ganlyniadau olrhain.
- Ymlynwyr (Chwistrelliad Methiant a yrrir gan Lineage) olion dosbarthu i'w profi gyda chwistrelliad gwall.
Nid yw'r un o'r opsiynau a restrir uchod yn berthnasol yn gyfan gwbl i'r senario debug, yn ystod y mae'r peiriannydd yn ceisio datrys y broblem trwy edrych ar yr olrhain.
Pan ddaw eto yn cyrraedd y sgript dadfygio, y rhyngwyneb cynradd yw'r diagram o hyd olrheiniad (er bod rhai hefyd yn ei alw "Siart Gantt" neu "diagram rhaeadr"). Dan olrheiniad я yr holl rychwantau a'r metadata cysylltiedig sydd gyda'i gilydd yn ffurfio'r olin. Mae pob system olrhain ffynhonnell agored, yn ogystal â phob datrysiad olrhain masnachol, yn cynnig a olrheiniad rhyngwyneb defnyddiwr ar gyfer delweddu, manylu a hidlo olion.
Y broblem gyda'r holl systemau olrhain rydw i wedi'u gweld hyd yn hyn yw'r canlyniad delweddu (golwg olrhain) bron yn gyfan gwbl yn adlewyrchu nodweddion y broses cynhyrchu hybrin. Hyd yn oed pan gynigir delweddu amgen: mapiau gwres, topolegau gwasanaeth, histogramau hwyrni, maent yn dal i ddod i lawr i olrheiniad.
Yn y gorffennol dwi y mae'n ymddangos bod y mwyafrif o "arloesi" mewn olrhain UI / UX yn gyfyngedig iddynt metadata ychwanegol mewn hybrin, gan fuddsoddi ynddynt gwybodaeth gyda cardinality uchel (cardinality uchel) neu ddarparu'r gallu i dreiddio i rychwantau penodol neu redeg ymholiadau rhyng- a mewn-olrhain... Lle olrheiniad yn parhau i fod y prif offeryn delweddu. Cyn belled â bod y sefyllfa hon yn parhau, bydd olrhain gwasgaredig (ar y gorau) yn cymryd y 4ydd lle fel offeryn dadfygio, ar ôl metrigau, boncyffion ac olion stacio, ac ar y gwaethaf bydd yn wastraff arian ac amser.
Problem gyda traceview
Pwrpas olrheiniad — darparu darlun cyflawn o symudiad cais unigol ar draws holl gydrannau'r system ddosbarthedig y mae'n perthyn iddi. Mae rhai systemau olrhain mwy datblygedig yn eich galluogi i ddrilio i mewn i rychwantau unigol a gweld dadansoddiad dros amser y tu mewn un broses (pan fo gan rhychwantau ffiniau swyddogaethol).
Cynsail sylfaenol pensaernïaeth microservices yw'r syniad bod y strwythur sefydliadol yn tyfu gydag anghenion y cwmni. Mae cynigwyr microwasanaethau yn dadlau bod dosbarthu tasgau busnes amrywiol i wasanaethau unigol yn caniatáu i dimau datblygu bach, ymreolaethol reoli cylch bywyd cyfan gwasanaethau o'r fath, gan roi'r gallu iddynt adeiladu, profi a defnyddio'r gwasanaethau hynny'n annibynnol. Fodd bynnag, anfantais y dosbarthiad hwn yw colli gwybodaeth am sut mae pob gwasanaeth yn rhyngweithio ag eraill. Mewn amodau o'r fath, mae olrhain dosranedig yn honni ei fod yn arf anhepgor ar gyfer debug rhyngweithio cymhleth rhwng gwasanaethau.
Os ydych yn wir , yna nid oes un person yn gallu ei gadw yn ei ben cyflawn llun. Mewn gwirionedd, mae datblygu offeryn sy'n seiliedig ar y rhagdybiaeth ei fod hyd yn oed yn bosibl yn rhywbeth gwrth-batrwm (dull aneffeithiol ac anghynhyrchiol). Yn ddelfrydol, mae dadfygio yn gofyn am offeryn sy'n helpu culhau eich ardal chwilio, fel y gall peirianwyr ganolbwyntio ar is-set o ddimensiynau (gwasanaethau/defnyddwyr/gwestewyr, ac ati) sy'n berthnasol i'r senario problemus sy'n cael ei hystyried. Wrth bennu achos methiant, nid yw'n ofynnol i beirianwyr ddeall beth ddigwyddodd yn ystod y holl wasanaethau ar unwaith, gan y byddai gofyniad o'r fath yn gwrth-ddweud yr union syniad o bensaernïaeth microwasanaeth.
Fodd bynnag, mae traceview yn sef hwn. Ydy, mae rhai systemau olrhain yn cynnig traceviews cywasgedig pan fo nifer y rhychwantau yn yr olin mor fawr fel na ellir eu harddangos mewn un delweddiad. Fodd bynnag, oherwydd y swm mawr o wybodaeth a gynhwysir hyd yn oed mewn delweddu o'r fath wedi'i dynnu i lawr, mae peirianwyr yn dal i fod gorfodi ei “hidlo”, gan gyfyngu'r dewis â llaw i set o wasanaethau sy'n ffynonellau problemau. Yn anffodus, yn y maes hwn, mae peiriannau'n llawer cyflymach na bodau dynol, yn llai tueddol o gael gwallau, ac mae eu canlyniadau'n fwy ailadroddadwy.
Rheswm arall rwy'n meddwl bod traceview yn anghywir yw oherwydd nad yw'n dda ar gyfer dadfygio a yrrir gan ddamcaniaeth. Yn greiddiol iddo, mae dadfygio iterus proses sy'n dechrau gyda rhagdybiaeth, wedi'i dilyn gan ddilysu arsylwadau a ffeithiau amrywiol a gafwyd o'r system ar hyd gwahanol fectorau, casgliadau/cyffredinoli ac asesiad pellach o wirionedd y ddamcaniaeth.
Cyfle cyflym a rhad profi damcaniaethau a gwella'r model meddyliol yn unol â hynny yw conglfaen dadfygio Dylai unrhyw offeryn debugging fod rhyngweithiol a chulhau'r gofod chwilio neu, yn achos arweiniol ffug, caniatáu i'r defnyddiwr fynd yn ôl a chanolbwyntio ar faes gwahanol o'r system. Bydd yr offeryn perffaith yn gwneud hyn yn rhagweithiol, gan dynnu sylw'r defnyddiwr ar unwaith at feysydd problem posibl.
Ysywaeth, olrheiniad Ni ellir ei alw'n offeryn gyda rhyngwyneb rhyngweithiol. Y gorau y gallwch chi obeithio amdano wrth ei ddefnyddio yw dod o hyd i ryw ffynhonnell o hwyrni cynyddol ac edrych ar yr holl dagiau a logiau posibl sy'n gysylltiedig ag ef. Nid yw hyn yn helpu'r peiriannydd i adnabod patrymau mewn traffig, megis manylion y dosbarthiad oedi, neu ganfod cydberthynas rhwng gwahanol fesuriadau. gall helpu i fynd o gwmpas rhai o'r problemau hyn. Yn wir, dadansoddiad llwyddiannus gan ddefnyddio dysgu peirianyddol i nodi rhychwantau anomalaidd a nodi is-set o dagiau a allai fod yn gysylltiedig ag ymddygiad afreolaidd. Fodd bynnag, nid wyf eto wedi gweld delweddu cymhellol o ddysgu peirianyddol neu ganfyddiadau cloddio data yn cael eu cymhwyso i rychwantau sy'n sylweddol wahanol i olrhain golwg neu DAG (graff acyclic cyfeiriedig).
Mae rhychwantau yn rhy isel
Y broblem sylfaenol gyda traceview yw hynny rhychwantu sy'n gyntefig lefel isel ar gyfer dadansoddi cuddni a dadansoddi gwraidd y broblem. Mae fel dosrannu gorchmynion prosesydd unigol i geisio datrys eithriad, gan wybod bod yna offer lefel uwch o lawer fel olrhain ôl sy'n llawer mwy cyfleus i weithio gyda nhw.
Ar ben hynny, byddaf yn cymryd y rhyddid o haeru'r canlynol: yn ddelfrydol, nid oes angen inni llun llawn digwydd yn ystod cylch bywyd y cais, a gynrychiolir gan offer olrhain modern. Yn lle hynny, mae angen rhyw fath o dyniad lefel uwch sy'n cynnwys gwybodaeth am beth aeth o'i le (tebyg i ôl-olrhain), ynghyd â pheth cyd-destun. Yn lle gwylio'r olrhain cyfan, mae'n well gen i ei weld rhan o, lle mae rhywbeth diddorol neu anarferol yn digwydd. Ar hyn o bryd, mae'r chwiliad yn cael ei wneud â llaw: mae'r peiriannydd yn derbyn yr olrhain ac yn dadansoddi'r rhychwantau yn annibynnol i chwilio am rywbeth diddorol. Nid yw’r dull o bobl sy’n syllu ar rychwantau mewn olion unigol gyda’r gobaith o ganfod gweithgarwch amheus yn cynyddu o gwbl (yn enwedig pan fydd yn rhaid iddynt wneud synnwyr o’r holl fetadata sydd wedi’u hamgodio mewn rhychwantau gwahanol, fel ID rhychwant, enw dull RPC, hyd rhychwant 'a, logiau, tagiau, etc.).
Dewisiadau eraill yn lle traceview
Mae canlyniadau olrhain yn fwyaf defnyddiol pan ellir eu delweddu mewn ffordd sy'n rhoi mewnwelediad nad yw'n ddibwys i'r hyn sy'n digwydd mewn rhannau rhyng-gysylltiedig o'r system. Hyd nes y bydd hyn yn digwydd, mae'r broses ddadfygio i raddau helaeth yn parhau anadweithiol ac mae'n dibynnu ar allu'r defnyddiwr i sylwi ar y cydberthnasau cywir, gwirio'r rhannau cywir o'r system, neu roi darnau'r pos at ei gilydd - yn hytrach na offeryn, gan helpu'r defnyddiwr i lunio'r damcaniaethau hyn.
Dydw i ddim yn ddylunydd gweledol nac yn arbenigwr UX, ond yn yr adran nesaf rwyf am rannu ychydig o syniadau ar sut olwg fyddai ar y delweddau hyn.
Canolbwyntiwch ar wasanaethau penodol
Ar adeg pan fo'r diwydiant yn cydgrynhoi o amgylch syniadau , mae’n ymddangos yn rhesymol y dylai timau unigol flaenoriaethu sicrhau bod eu gwasanaethau’n cyd-fynd â’r nodau hyn. Mae'n dilyn hynny gwasanaeth-ganolog delweddu sydd fwyaf addas ar gyfer timau o'r fath.
Mae olion, yn enwedig heb samplu, yn drysorfa o wybodaeth am bob cydran o system ddosbarthedig. Gellir bwydo'r wybodaeth hon i brosesydd cyfrwys a fydd yn cyflenwi defnyddwyr gwasanaeth-ganolog Gellir eu hadnabod ymlaen llaw - hyd yn oed cyn i'r defnyddiwr edrych ar yr olion:
- Diagramau dosbarthu hwyrni dim ond ar gyfer ceisiadau amlwg iawn (ceisiadau allanol);
- Diagramau o ddosbarthiad oedi ar gyfer achosion pan na chyflawnir nodau SLO gwasanaeth;
- Y tagiau mwyaf “cyffredinol”, “diddorol” a “rhyfedd” mewn ymholiadau sydd amlaf yn cael eu hailadrodd;
- Dadansoddiad hwyrni ar gyfer achosion lle dibyniaethau nid yw gwasanaethau'n cyflawni eu nodau SLO;
- Dadansoddiad hwyrni ar gyfer gwasanaethau amrywiol i lawr yr afon.
Yn syml, nid yw rhai o'r cwestiynau hyn yn cael eu hateb gan fetrigau adeiledig, gan orfodi defnyddwyr i graffu ar rhychwantau. O ganlyniad, mae gennym fecanwaith hynod o elyniaethus i ddefnyddwyr.
Mae hyn yn codi’r cwestiwn: beth am ryngweithio cymhleth rhwng gwasanaethau amrywiol a reolir gan dimau gwahanol? Onid yw olrheiniad onid yw'n cael ei ystyried fel yr arf mwyaf priodol i amlygu sefyllfa o'r fath?
Efallai y bydd gan ddatblygwyr ffonau symudol, perchnogion gwasanaethau heb wladwriaeth, perchnogion gwasanaethau gwladwriaethol a reolir (fel cronfeydd data) a pherchnogion llwyfannau ddiddordeb mewn rhywbeth arall cyflwyniad system ddosbarthedig; olrheiniad yn ateb rhy generig ar gyfer yr anghenion sylfaenol gwahanol hyn. Hyd yn oed mewn pensaernïaeth microwasanaeth cymhleth iawn, nid oes angen gwybodaeth ddofn ar berchnogion gwasanaethau am fwy na dau neu dri o wasanaethau i fyny'r afon ac i lawr yr afon. Yn y bôn, yn y rhan fwyaf o senarios, dim ond cwestiynau yn ymwneud â nhw y mae angen i ddefnyddwyr eu hateb set gyfyngedig o wasanaethau.
Mae fel edrych ar is-set fach o wasanaethau trwy chwyddwydr er mwyn craffu arno. Bydd hyn yn galluogi'r defnyddiwr i ofyn cwestiynau pwysicach ynghylch y rhyngweithio cymhleth rhwng y gwasanaethau hyn a'u dibyniaethau uniongyrchol. Mae hyn yn debyg i ôl-olion yn y byd gwasanaethau, lle mae'r peiriannydd yn gwybod y anghywir, ac mae ganddo hefyd rywfaint o ddealltwriaeth o'r hyn sy'n digwydd yn y gwasanaethau cyfagos i'w ddeall pam.
Yr ymagwedd rwy'n ei hyrwyddo yw'r union gyferbyn â'r dull o'r brig i'r gwaelod, sy'n seiliedig ar olion golwg, lle mae'r dadansoddiad yn dechrau gyda'r olrhain cyfan ac yna'n gweithio'n raddol i rychwantau unigol. Mewn cyferbyniad, mae dull o'r gwaelod i fyny yn dechrau trwy ddadansoddi ardal fach yn agos at achos posibl y digwyddiad, ac yna'n ehangu'r gofod chwilio yn ôl yr angen (gyda'r potensial o ddod â thimau eraill i mewn i ddadansoddi ystod ehangach o wasanaethau). Mae'r ail ddull yn fwy addas ar gyfer profi damcaniaethau cychwynnol yn gyflym. Unwaith y ceir canlyniadau pendant, bydd yn bosibl symud ymlaen i ddadansoddiad mwy manwl a manwl.
Adeiladu topoleg
Gall safbwyntiau gwasanaeth-benodol fod yn hynod ddefnyddiol os yw'r defnyddiwr yn gwybod beth mae gwasanaeth neu grŵp o wasanaethau yn gyfrifol am gynyddu hwyrni neu achosi gwallau. Fodd bynnag, mewn system gymhleth, gall nodi'r gwasanaeth troseddwyr fod yn dasg nad yw'n ddibwys yn ystod methiant, yn enwedig os na adroddwyd am unrhyw negeseuon gwall gan y gwasanaethau.
Gall adeiladu topoleg gwasanaeth fod yn help mawr i ddarganfod pa wasanaeth sy'n profi cynnydd sydyn mewn cyfraddau gwallau neu gynnydd mewn hwyrni sy'n achosi i'r gwasanaeth ddirywio'n amlwg. Pan fyddaf yn siarad am adeiladu topoleg, nid wyf yn ei olygu map gwasanaethau, yn arddangos pob gwasanaeth sydd ar gael yn y system ac yn adnabyddus am ei . Nid yw'r olygfa hon yn ddim gwell na traceview yn seiliedig ar graff acyclic cyfeiriedig. Yn lle hynny hoffwn weld topoleg gwasanaeth a gynhyrchir yn ddeinamig, yn seiliedig ar nodweddion penodol megis cyfradd gwallau, amser ymateb, neu unrhyw baramedr a ddiffinnir gan y defnyddiwr sy'n helpu i egluro'r sefyllfa gyda gwasanaethau amheus penodol.
Gadewch i ni gymryd enghraifft. Gadewch i ni ddychmygu safle newyddion damcaniaethol. Gwasanaeth tudalen gartref (tudalen flaen) cyfnewid data gyda Redis, gyda gwasanaeth argymell, gyda gwasanaeth hysbysebu a gwasanaeth fideo. Mae'r gwasanaeth fideo yn cymryd fideos o S3 a metadata o DynamoDB. Mae'r gwasanaeth argymell yn derbyn metadata gan DynamoDB, yn llwytho data o Redis a MySQL, ac yn ysgrifennu negeseuon i Kafka. Mae'r gwasanaeth hysbysebu yn derbyn data gan MySQL ac yn ysgrifennu negeseuon i Kafka.
Isod mae cynrychiolaeth sgematig o'r dopoleg hon (mae llawer o raglenni llwybro masnachol yn adeiladu'r topoleg). Gall fod yn ddefnyddiol os oes angen i chi ddeall dibyniaethau gwasanaeth. Fodd bynnag, yn ystod debug, pan fydd gwasanaeth penodol (dyweder, gwasanaeth fideo) yn arddangos mwy o amser ymateb, nid yw topoleg o'r fath yn ddefnyddiol iawn.
Diagram gwasanaeth o wefan newyddion damcaniaethol
Byddai'r diagram isod yn fwy addas. Mae problem gyda'r gwasanaeth (fideo) darlunio reit yn y canol. Mae'r defnyddiwr yn sylwi arno ar unwaith. O'r delweddu hwn, daw'n amlwg bod y gwasanaeth fideo yn gweithio'n annormal oherwydd cynnydd yn amser ymateb S3, sy'n effeithio ar gyflymder llwytho rhan o'r brif dudalen.
Topoleg ddeinamig yn dangos gwasanaethau “diddorol” yn unig
Gall topolegau a gynhyrchir yn ddeinamig fod yn fwy effeithlon na mapiau gwasanaeth statig, yn enwedig mewn seilwaith elastig, graddio auto. Mae'r gallu i gymharu a chyferbynnu topolegau gwasanaeth yn galluogi'r defnyddiwr i ofyn cwestiynau mwy perthnasol. Mae cwestiynau mwy manwl gywir am y system yn fwy tebygol o arwain at well dealltwriaeth o sut mae'r system yn gweithio.
Arddangosfa gymharol
Delweddu defnyddiol arall fyddai arddangosfa gymharol. Ar hyn o bryd nid yw olion yn addas iawn ar gyfer cymariaethau ochr yn ochr, felly mae cymariaethau fel arfer rhychwantu. A phrif syniad yr erthygl hon yn union yw bod rhychwantau yn rhy isel ar lefel i dynnu'r wybodaeth fwyaf gwerthfawr o'r canlyniadau olrhain.
Nid oes angen delweddu sylfaenol newydd i gymharu dau olin. Mewn gwirionedd, mae rhywbeth fel histogram sy'n cynrychioli'r un wybodaeth ag olrhain golwg yn ddigonol. Yn syndod, gall hyd yn oed y dull syml hwn ddod â llawer mwy o ffrwythau na dim ond astudio dau olion ar wahân. Hyd yn oed yn fwy pwerus fyddai'r posibilrwydd delweddu cymhariaeth o olion Mewn Cyfanswm. Byddai'n hynod ddefnyddiol gweld sut mae newid cyfluniad cronfa ddata a ddefnyddiwyd yn ddiweddar i alluogi GC (casglu sbwriel) yn effeithio ar amser ymateb gwasanaeth i lawr yr afon ar raddfa o sawl awr. Os yw'r hyn rwy'n ei ddisgrifio yma yn swnio fel dadansoddiad A/B o effaith newidiadau seilwaith mewn llawer o wasanaethau gan ddefnyddio'r canlyniadau olrhain, yna nid ydych yn rhy bell oddi wrth y gwir.
Casgliad
Nid wyf yn amau defnyddioldeb yr olrhain ei hun. Credaf yn ddiffuant nad oes unrhyw ddull arall ar gyfer casglu data mor gyfoethog, achosol a chyd-destunol â’r hyn a geir mewn olin. Fodd bynnag, credaf hefyd fod yr holl atebion olrhain yn defnyddio'r data hwn yn hynod aneffeithlon. Cyn belled â bod offer olrhain yn aros yn sownd ar y cynrychioliad o olrheinion, byddant yn gyfyngedig yn eu gallu i wneud y gorau o'r wybodaeth werthfawr y gellir ei thynnu o'r data a gynhwysir yn yr olion. Yn ogystal, mae risg o ddatblygu ymhellach ryngwyneb gweledol cwbl anghyfeillgar ac anreddfol a fydd yn cyfyngu'n ddifrifol ar allu'r defnyddiwr i ddatrys gwallau yn y rhaglen.
Mae dadfygio systemau cymhleth, hyd yn oed gyda'r offer diweddaraf, yn anhygoel o anodd. Dylai offer helpu'r datblygwr i lunio a phrofi rhagdybiaeth, darparu'n weithredol gwybodaeth berthnasol, nodi allgleifion a nodi nodweddion yn nosbarthiad yr oedi. Er mwyn i olrhain ddod yn offeryn o ddewis i ddatblygwyr wrth ddatrys methiannau cynhyrchu neu ddatrys problemau sy'n rhychwantu gwasanaethau lluosog, mae angen rhyngwynebau defnyddwyr gwreiddiol a delweddiadau sy'n fwy cyson â model meddyliol y datblygwyr sy'n creu ac yn gweithredu'r gwasanaethau hynny.
Bydd yn cymryd ymdrech feddyliol sylweddol i ddylunio system a fydd yn cynrychioli'r gwahanol signalau sydd ar gael yn y canlyniadau olrhain mewn ffordd sydd wedi'i optimeiddio er hwylustod dadansoddi a dod i gasgliad. Mae angen i chi feddwl am sut i haniaethu topoleg y system yn ystod dadfygio mewn ffordd sy'n helpu'r defnyddiwr i oresgyn mannau dall heb edrych ar olion neu rhychwantau unigol.
Mae arnom angen galluoedd tynnu a haenu da (yn enwedig yn yr UI). Rhai a fyddai'n cyd-fynd yn dda â phroses ddadfygio sy'n cael ei gyrru gan ddamcaniaeth lle gallwch ofyn cwestiynau yn ailadroddus a rhoi prawf ar ddamcaniaethau. Ni fyddant yn datrys yr holl broblemau arsylwi yn awtomatig, ond byddant yn helpu defnyddwyr i hogi eu greddf a llunio cwestiynau callach. Galwaf am ddull mwy meddylgar ac arloesol o ddelweddu. Mae gobaith gwirioneddol yma i ehangu gorwelion.
PS gan y cyfieithydd
Darllenwch hefyd ar ein blog:
- «";
- «";
- «'.
Ffynhonnell: hab.com