Заўв. перав.: Аўтар гэтага матэрыялу - Cindy Sridharan, інжынер з кампаніі imgix, якая займаецца пытаннямі распрацоўкі API і, у прыватнасці, тэсціравання мікрасэрвісаў. У гэтым матэрыяле яна дзеліцца сваім разгорнутым бачаннем актуальных праблем у галіне размеркаванай трасіроўкі, дзе, на яе думку, назіраецца недахоп па-сапраўднаму эфектыўных інструментаў для вырашэння надзённых задач.
[Ілюстрацыя запазычана з пра размеркаваную трасіроўку.]
Лічыцца, што складана ўкараняць, ды і аддача ад яе . "Праблемнасць" трасіроўкі тлумачаць мноствам чыннікаў, пры гэтым часта спасылаюцца на працаёмкасць налады кожнага кампанента сістэмы для перадачы адпаведных загалоўкаў разам з кожным запытам. Хаця гэтая праблема сапраўды мае месца, яе зусім нельга назваць непераадольнай. Яна, дарэчы, не тлумачыць, чаму распрацоўшчыкі не вельмі любяць трасіроўку (нават ужо якая функцыянуе).
Галоўная цяжкасць з размеркаванай трасіроўкай - гэта не збор дадзеных, не стандартызацыя фарматаў распаўсюджвання і прадстаўлення вынікаў і не вызначэнне таго, калі, дзе і як вырабляць выбарку. Я зусім не спрабую ўявіць трывіяльнымі гэтыя "праблемы з засваяльнасцю" - на самай справе, існуюць даволі значныя тэхнічныя і (калі мы разглядаем па-сапраўднаму Open Source'ныя ) палітычныя выклікі, якія неабходна пераадолець, каб дадзеныя праблемы можна было лічыць вырашанымі.
Аднак, калі ўявіць, што ўсе гэтыя праблемы вырашаны, высокая верагоднасць, што нішто істотна не зменіцца з пункту гледжання. вопыту канчатковага карыстальніка. Трасіроўка па-ранейшаму можа не прыносіць практычную карысць у самых распаўсюджаных сцэнарах адладкі - нават пасля таго, як яна разгорнута.
Такая непадобная трасіроўка
Размеркаваная трасіроўка ўключае ў сябе некалькі разрозненых кампанентаў:
- абсталяванне прыкладанняў і middleware сродкамі кантролю;
- перадача размеркаванага кантэксту;
- збор трасіровак;
- захоўванне трасіровак;
- іх выманне і візуалізацыя.
Мноства размоў аб размеркаванай трасіроўцы зводзяцца да таго, каб разглядаць яе як нейкую ўнарную аперацыю, адзінай мэтай якой з'яўляецца дапамога ў поўнай дыягностыцы сістэмы. У многім гэта звязана з тым, як гістарычна фарміраваліся ўяўленні аб размеркаванай трасіроўцы. У , зробленай, калі адкрываліся зыходнікі Zipkin, згадвалася, што ён [Zipkin] робіць Twitter хутчэй. Першыя камерцыйныя прапановы для трасіроўкі таксама прасоўваліся як .
Заўв. перав.: Каб далейшы тэкст успрымаўся лепш, вызначым два базавыя тэрміны паводле :
- пралёт - базавы элемент размеркаванай трасіроўкі. Уяўляе сабой апісанне нейкага працоўнага працэсу (напрыклад, запыту да базы дадзеных) з назвай, часам пачатку і канчаткі, тэгамі, логамі і кантэкстам.
- Span'ы звычайна ўтрымоўваюць спасылкі на іншыя span'ы, што дазваляе аб'ядноўваць мноства span'ов у Прасочваць - Візуалізацыю жыцця запыту ў працэсе яго перамяшчэння па размеркаванай сістэме.
Trace'ы змяшчаюць неверагодна каштоўныя дадзеныя, здольныя дапамагчы ў такіх задачах, як: тэсціраванне ў production, правядзенне тэстаў аварыйнага аднаўлення, тэсціраванне з укараненнем памылак і г.д. Насамрэч некаторыя кампаніі ўжо выкарыстоўваюць трасіроўку для падобных мэт. Пачнём з таго, што мае і іншыя ўжыванні апроч простага пераносу span'ов у сістэму захоўвання:
- Напрыклад, Uber вынікі трасіроўкі для размежавання тэставага трафіку і production-трафіку.
- Facebook дадзеныя trace'аў для аналізу крытычнага шляху і для пераключэння трафіку падчас рэгулярных тэстаў аварыйнага аднаўлення.
- Таксама сацсетка нататнікі Jupyter, якія дазваляюць распрацоўнікам выконваць адвольныя запыты на выніках трасіроўкі.
- Прыхільнікі (Lineage Driven Failure Injection) размеркаваныя trace'ы для тэсціравання з укараненнем памылак.
Ніводны з пералічаных вышэй варыянтаў не ставіцца цалкам да сцэнара адладкі, Падчас якога інжынер спрабуе вырашыць праблему, гледзячы на trace.
Калі справа ўсё ж даходзіць да сцэнара адладкі, першасным інтэрфейсам застаецца дыяграма traceview (хоць некаторыя таксама называюць яе "дыяграмай Ганта" або "каскаднай дыяграмай"). Пад traceview я усе span'ы і спадарожныя метададзеныя, якія разам складаюць trace. Кожная сістэма трасіроўкі з адкрытым зыходным кодам, а таксама кожнае камерцыйнае рашэнне для трасіроўкі прапануе заснаваны на traceview карыстацкі інтэрфейс для візуалізацыі, дэталізацыі і фільтраванні trace'ов.
Праблема са ўсімі сістэмамі трасіроўкі, з якімі мне давялося азнаёміцца на дадзены момант, складаецца ў тым, што выніковая візуалізацыя (traceview) практычна цалкам адлюстроўвае асаблівасці працэсу генерацыі trace'а. Нават калі прапануюцца альтэрнатыўныя візуалізацыі: карты інтэнсіўнасці (heatmap), тапалогіі сэрвісаў, гістаграмы затрымак (latency), – у канчатковым выніку яны ўсё роўна зводзяцца да traceview.
У мінулым я на тое, што большасць «інавацый» у вобласці трасіроўкі ў стаўленні UI/UX, здаецца, абмяжоўваюцца дадатковых метададзеных у trace, укладаннем у іх інфармацыі з высокай кардынальнасцю (high-cardinality) або прадастаўленнем магчымасці дэталізаваць канкрэтныя span'ы ці выконваць запыты між- і ўнутры-trace. Пры гэтым traceview застаецца асноўным сродкам візуалізацыі. Пакуль будзе захоўвацца падобнае становішча рэчаў, размеркаваная трасіроўка будзе (у лепшым выпадку) займаць 4-е месца ў якасці адладкавай прылады, услед за метрыкамі, логамі і stack trace'амі, а ў горшым — апынецца пустой стратай грошай і чакай.
Праблема з traceview
прызначэнне traceview - прадастаўляць поўную карціну перамяшчэння асобнага запыту па ўсіх кампанентах размеркаванай сістэмы, да якіх ён мае дачыненне. Некаторыя больш прасунутыя сістэмы трасіроўкі дазваляюць дэталізаваць асобныя span'ы і праглядаць разбіўку па часе. ўнутры аднаго працэсу (калі span'ы маюць функцыянальныя межы).
Базавай перадумовай архітэктуры мікрасэрвісаў з'яўляецца ідэя аб тым, што арганізацыйная структура расце разам з патрэбамі кампаніі. Прыхільнікі мікрасэрвісаў сцвярджаюць, што размеркаванне розных бізнэс-задач па асобных сэрвісах дазваляе невялікім, аўтаномным камандам распрацоўнікаў кантраляваць увесь жыццёвы цыкл такіх сэрвісаў, даючы ім магчымасць незалежнай выявай ствараць, тэставаць і разгортваць гэтыя сэрвісы. Аднак недахопам падобнага размеркавання з'яўляецца страта інфармацыі аб тым, як кожны сэрвіс узаемадзейнічае з іншымі. У такіх умовах размеркаваная трасіроўка прэтэндуе на ролю незаменнай прылады для адладкі складаных узаемадзеянняў паміж сэрвісамі.
Калі ў вас сапраўды , то ні адзін чалавек не здольны ўтрымаць у галаве яе поўную карціну. Насамрэч распрацоўка прылады зыходзячы са здагадкі, што гэта наогул магчыма, з'яўляецца чымсьці накшталт антыпатэрна (неэфектыўным і непрадуктыўным падыходам). У ідэале для адладкі патрабуецца інструмент, які дапамагае звузіць зону пошуку, Каб інжынеры маглі засяродзіцца на падмностве вымярэнняў (сэрвісах / карыстальніках / хастах і т. п.), якія маюць дачыненне да разгляданага сцэнары праблемы. Пры высвятленні прычыны збою інжынеры не павінны разбірацца ў тым, што адбывалася ва ўсіх сэрвісах адразу, паколькі такое патрабаванне супярэчыла б самай ідэі мікрасэрвіснай архітэктуры.
Аднак traceview уяўляе сабой менавіта гэта. Так, некаторыя сістэмы трасіроўкі прапануюць сціснутыя traceview, калі лік span'ов у trace настолькі вялікі, што іх немагчыма адлюстраваць у рамках адной візуалізацыі. Аднак з-за вялікага аб'ёму інфармацыі, якая змяшчаецца нават у такой зрэзанай візуалізацыі, інжынеры ўсё роўна вымушаныя «прасейваць» яе, уручную звужаючы выбарку да набору сэрвісаў-крыніц праблем. Нажаль, на гэтай ніве машыны значна хутчэй чалавека, меней схільныя памылкам, а іх вынікі больш паўтараныя.
Яшчэ адна прычына, па якой я лічу метад traceview няправільным, звязана з тым, што ен дрэнна падыходзіць для адладкі на аснове гіпотэз. У сваёй аснове адладка - гэта ітэратыўны працэс, які пачынаецца з гіпотэзы, за якой ідуць праверка розных назіранняў і фактаў, атрыманых ад сістэмы па розных вектарах, высновы / абагульненні і далейшая ацэнка праўдзівасці гіпотэзы.
Магчымасць хутка і танна тэсціраваць гіпотэзы і адпаведным чынам паляпшаць ментальную мадэль з'яўляецца краевугольным каменем адладкі. Любая адладачная прылада павінна быць інтэрактыўным і звужаць прастору пошуку або, у выпадку ілжывага следу, дазваляць карыстачу вярнуцца назад і сфакусавацца на іншай вобласці сістэмы. Ідэальны інструмент будзе рабіць гэта з апярэджаннем, адразу прыцягваючы ўвагу карыстальніка да патэнцыйна праблемных абласцей.
На жаль, traceview нельга назваць прыладай з інтэрактыўным інтэрфейсам. Лепшае, на што можна спадзявацца пры ім выкарыстанні, - гэта выявіць нейкую крыніцу падвышаных затрымак і прагледзець разнастайныя тэгі і логі, злучаныя з ім. Гэта не дапамагае інжынеру выявіць заканамернасці у трафіку, такія як спецыфіка размеркавання затрымак, або выявіць карэляцыі паміж рознымі вымярэннямі. можа дапамагчы абыйсці некаторыя з гэтых праблем. Сапраўды, паспяховага аналізу з выкарыстаннем машыннага навучання па выяўленні анамальных span'аў і ідэнтыфікацыі падмноства тэгаў, якія могуць быць злучаны з анамальным паводзінамі. Тым не менш, мне пакуль не сустракаліся пераканаўчыя візуалізацыі знаходак, зробленых з дапамогай машыннага навучання ці аналізу дадзеных, ужытых да span'ам, якія б значна адрозніваліся ад traceview ці DAG (накіраванага ацыклічнага графа).
Span'ы занадта нізкаўзроўневыя
Фундаментальная праблема з traceview у тым, што span'ы з'яўляюцца занадта нізкаўзроўневымі прымітывамі як для аналізу затрымак (latency), так і для аналізу зыходных прычын. Гэта ўсё роўна што аналізаваць асобныя каманды працэсара ў спробе ўхіліць выключэнне, ведаючы, што існуюць значна больш высокаўзроўневыя прылады накшталт backtrace, працаваць з якімі значна зручней.
Больш за тое, я вазьму на сябе смеласць сцвярджаць наступнае: у ідэале нам зусім не патрэбна поўная карціна які адбыўся падчас жыццёвага цыклу запыту, якую ўяўляюць сучасныя прылады для трасіроўкі. Замест гэтага патрабуецца нейкая форма абстракцыі больш высокага ўзроўню, якая змяшчае звесткі аб тым, што пайшло не так (па аналогіі з backtrace), разам з некаторым кантэкстам. Замест таго, каб назіраць увесь trace, я аддаю перавагу бачыць яго частка, дзе адбываецца нешта цікавае ці незвычайнае. У наш час пошук ажыццяўляецца ўручную: інжынер атрымлівае trace і самастойна аналізуе span'ы ў пошуках чаго-небудзь цікавага. Падыход, калі людзі вытарэшчваюцца на span'ы ў асобных trace'ах у надзеі выявіць падазроную актыўнасць, абсалютна не маштабуецца (асабліва калі ім даводзіцца асэнсоўваць усе метададзеныя, закадаваныя ў розных span'ах, такія як span ID, імя метаду RPC, працягласць span Та, логі, тэгі і г.д.).
Альтэрнатывы traceview
Вынікі трасіроўкі найболей карысныя, калі іх можна візуалізаваць такім чынам, каб атрымаць нетрывіяльнае ўяўленне пра тое, што адбываецца ва ўзаемазлучаных частках сістэмы. Да таго часу, пакуль гэтага няма, працэс адладкі шмат у чым застаецца інэртным і залежыць ад здольнасці карыстальніка прыкмячаць правільныя карэляцыі, правяраць правільныя часткі сістэмы або збіраць кавалачкі мазаікі разам - у адрозненне ад інструмента, Які дапамагае карыстачу фармуляваць гэтыя гіпотэзы.
Я не візуальны дызайнер і не спецыяліст у галіне UX, аднак у наступным раздзеле хачу падзяліцца некалькімі ідэямі аб тым, як могуць выглядаць падобныя візуалізацыі.
Фокус на канкрэтных сэрвісах
Ва ўмовах, калі галіна кансалідуецца вакол ідэй , здаецца разумным, што асобныя каманды павінны ў першую чаргу сачыць за адпаведнасцю іх сэрвісаў гэтым мэтам. З гэтага вынікае, што арыентаваная на сэрвіс візуалізацыя лепш за ўсё падыходзіць для такіх каманд.
Trace'ы, асабліва без выбаркі, з'яўляюцца скарбніцай інфармацыі аб кожным кампаненце размеркаванай сістэмы. Гэтую інфармацыю можна скарміць хітраму апрацоўшчыку, які будзе пастаўляць карыстальнікам арыентаваныя на сэрвіс знаходкі.Яны могуць быць выяўлены загадзя - яшчэ да таго, як карыстач зірнуў на trace'ы:
- Дыяграмы размеркавання затрымак толькі для моцна якія вылучаюцца запытаў (outlier requests);
- Дыяграмы размеркавання затрымак для выпадкаў, калі SLO-мэты сэрвісу не дасягаюцца;
- Самыя "агульныя", "цікавыя" і "дзіўныя" тэгі ў запытах, якія часцей за ўсё паўтараюцца;
- Разбіўка затрымак для выпадкаў, калі залежнасці сэрвісу не дасягаюць пастаўленых SLO-мэт;
- Разбіўка затрымак па розных ніжэйстаячых (downstream) сэрвісах.
На некаторыя з гэтых пытанняў убудаваныя метрыкі проста не могуць адказаць, прымушаючы карыстальнікаў старанна вывучаць span'ы. У выніку мы маем надзвычай варожы да карыстача механізм.
У сувязі з гэтым узнікае пытанне: як наконт комплексных узаемадзеянняў паміж разнастайнымі сэрвісамі, якія кантралююцца рознымі камандамі? Хіба traceview не лічыцца найболей падыходнай прыладай для асвятлення падобнай сітуацыі?
Мабільныя распрацоўшчыкі, уладальнікі stateless-сэрвісаў, уладальнікі кіраваных stateful-сэрвісаў (накшталт баз дадзеных) і ўладальнікі платформаў могуць быць зацікаўлены ў іншым прадстаўленні размеркаванай сістэмы; traceview - Гэта занадта ўніверсальнае рашэнне для гэтых у корані выдатных патрэб. Нават у вельмі складанай мікрасэрвіснай архітэктуры ўладальнікам сэрвісу не патрэбныя глыбокія веды больш за двух-трох upstream- і downstream-сэрвісаў. У сутнасці, у большасці сцэнараў карыстальнікам дастаткова адказваць на пытанні, якія тычацца абмежаванага набору сэрвісаў.
Гэта падобна на разглядванне невялікага падмноства сэрвісаў праз павелічальнае шкло дзеля скрупулёзнага вывучэння. Гэта дазволіць карыстачу задаваць больш надзённыя пытанні, датычныя комплекснага ўзаемадзеяння паміж гэтымі сэрвісамі і іх непасрэднымі залежнасцямі. Гэта аналагічна backtrace'у ў свеце сэрвісаў, дзе інжынер ведае, што не так, а таксама мае некаторае ўяўленне аб тым, што адбываецца ў навакольных сэрвісах, каб зразумець, чаму.
Прасоўваны мною падыход - гэта поўная супрацьлегласць да падыходу "зверху ўніз", заснаванаму на traceview, калі аналіз пачынаецца з усяго trace'а, а затым паступова спускаецца да асобных span'аў. Наадварот, падыход "знізу ўверх" пачынаецца з аналізу невялікага ўчастку, блізкага да патэнцыйнай прычыны інцыдэнту, а затым прастора пошуку пашыраецца пры неабходнасці (з магчымым прыцягненнем іншых каманд для аналізу шырэйшага спектру сэрвісаў). Другі падыход лепш прыстасаваны для хуткай праверкі пачатковых гіпотэз. Пасля атрымання канкрэтных вынікаў можна будзе пераходзіць да больш мэтанакіраванага і падрабязнага аналізу.
Пабудова тапалогіі
Прывязаныя да канкрэтнага сэрвісу прадстаўлення могуць быць неверагодна карысныя, калі карыстач ведае, какой сэрвіс або група сэрвісаў вінаватая ў павелічэнні затрымак або з'яўляецца крыніцай памылак. Аднак у складанай сістэме вызначэнне сэрвісу-парушальніка можа аказацца нетрывіяльнай задачай падчас збою, асабліва калі паведамленні аб памылках ад сэрвісаў не паступалі.
Пабудова тапалогіі сэрвісаў можа моцна дапамагчы пры высвятленні, які сэрвіс дэманструе ўсплёск частаты памылак ці павелічэнне затрымкі, якія прыводзяць да прыкметнага пагаршэння працы сэрвісу. Гаворачы аб пабудове тапалогіі, я маю на ўвазе не карту сэрвісаў, якая адлюстроўвае кожны наяўны ў сістэме сэрвіс і вядомую сваімі . Такое паданне нічым не лепшае, чым traceview на аснове накіраванага ацыклічнага графа. Замест гэтага мне хацелася б бачыць дынамічна генераваная тапалогія сэрвісаў, заснаваную на пэўных атрыбутах, такіх як частата памылак, час водгуку або на любым зададзеным карыстальнікам параметры, які дапамагае растлумачыць сітуацыю з канкрэтнымі падазронымі сэрвісамі.
Давайце звернемся да прыкладу. Уявім сабе нейкі гіпатэтычны навінавы сайт. Сэрвіс галоўнай старонкі (front page) абменьваецца дадзенымі з Redis, з сэрвісам рэкамендацый, з рэкламным сэрвісам і відэасэрвісам. Відэасервіс бярэ відэаролікі з S3, а метададзеныя – з DynamoDB. Сэрвіс рэкамендацый атрымлівае метададзеныя з DynamoDB, загружае дадзеныя з Redis і MySQL, піша паведамленні ў Kafka. Рэкламны сэрвіс атрымлівае дадзеныя з MySQL і піша паведамленні ў Kafka.
Ніжэй прыведзена схематычны малюнак гэтай тапалогіі (тапалогію будуюць шматлікія камерцыйныя праграмы для трасіроўкі). Яно можа спатрэбіцца, калі неабходна разабрацца ў залежнасцях сэрвісаў. Аднак падчас адладкі, Калі нейкі сэрвіс (скажам, відэасэрвіс) дэманструе павялічаны час водгуку, падобная тапалогія не занадта карысная.
Схема сэрвісаў гіпатэтычнага навінавага сайта
Лепш падышла б дыяграма, намаляваная ніжэй. На ёй праблемны сэрвіс (Відэа) намаляваны прама ў цэнтры. Карыстальнік адразу яго заўважае. З дадзенай візуалізацыі становіцца зразумела, што відэа-сэрвіс працуе анамальна з-за павелічэння часу водгуку S3, што ўплывае на хуткасць загрузкі часткі галоўнай старонкі.
Дынамічная тапалогія, якая адлюстроўвае толькі «цікавыя» сэрвісы
Дынамічна генераваныя тапалагічныя схемы могуць апынуцца больш эфектыўнымі, чым статычныя карты сэрвісаў, асабліва ў эластычных, аўтамаштабаваных інфраструктурах. Магчымасць параўноўваць і супастаўляць тапалогіі сэрвісаў дазваляе карыстачу задаваць больш актуальныя пытанні. Больш дакладныя пытанні аб сістэме з большай верагоднасцю прыводзяць да лепшага разумення таго, як сістэма працуе.
Параўнальнае адлюстраванне
Яшчэ адной карыснай візуалізацыяй будзе параўнальнае адлюстраванне. У цяперашні час trace'ы не занадта добра падыходзяць для параўнання бок аб бок, таму звычайна параўноўваюцца span'ы. А асноўная ідэя гэтага артыкула як раз і складаецца ў тым, што span'ы занадта нізкаўзроўневыя, каб здабываць найболей каштоўную інфармацыю з вынікаў трасіроўкі.
Параўнанне двух trace'аў не патрабуе прынцыпова новых візуалізацый. Насамрэч дастаткова чагосьці накшталт гістаграмы, якая прадстаўляе тую ж інфармацыю, што і traceview. Дзіўна, але нават гэты просты метад можа прынесці значна больш пладоў, чым простае вывучэнне двух trace'аў па асобнасці. Яшчэ больш магутнай стала б магчымасць візуалізаваць параўнанне trace'аў у сукупнасці. Было б вельмі карысна ўбачыць, як нядаўна разгорнутая змена канфігурацыі базы дадзеных з уключэннем GC (зборкі смецця) уплывае на час водгуку downstream-сэрвісу ў маштабе некалькіх гадзін. Калі тое, што я апісваю тут, здаецца падобным на А/У-аналіз уплыву інфраструктурных змен у мностве сэрвісаў з дапамогай вынікаў трасіроўкі, то вы не занадта далёкія ад ісціны.
Заключэнне
Я не падвяргаю сумневу карыснасць самой трасіроўкі. Шчыра веру, што няма іншага метаду збіраць настолькі ж багатыя, казуальныя і кантэкстуальныя дадзеныя, як тыя, што змяшчаюцца ў trace'е. Аднак я таксама лічу, што ўсе рашэнні для трасіроўкі выкарыстоўваюць гэтыя даныя надзвычай неэфектыўна. Датуль, пакуль прылады для трасіроўкі будуць зацыкленыя на traceview-паказе, яны будуць абмежаваныя ў магчымасці па максімуме выкарыстаць каштоўную інфармацыю, якую можна атрымаць з дадзеных, якія змяшчаюцца ў trace'ах. Акрамя таго, існуе рызыка далейшага развіцця зусім недружалюбнага і неінтуітыўна візуальнага інтэрфейсу, які моцна абмяжуе здольнасць карыстальніка ўстараняць памылкі ў дадатку.
Адладка складаных сістэм, нават з выкарыстаннем найноўшых прылад, неверагодна складаная. Інструменты павінны дапамагаць распрацоўніку фармуляваць і правяраць гіпотэзу, актыўна падаючы рэлевантную інфармацыю, выяўляючы выкіды і прыкмячаючы асаблівасці ў размеркаванні затрымак. Для таго, каб трасіроўка стала пераважнай прыладай распрацоўнікаў пры ўхіленні збояў у production ці рашэнні праблем, якія ахопліваюць розныя сэрвісы, неабходны арыгінальныя карыстацкія інтэрфейсы і візуалізацыі, у большай ступені адпаведныя ментальнай мадэлі распрацоўнікаў, якія ствараюць і эксплуатуюць гэтыя сэрвісы.
Спатрэбяцца сур'ёзныя разумовыя намаганні, каб спраектаваць сістэму, якая будзе прадстаўляць розныя сігналы, даступныя ў выніках трасіроўкі, спосабам, аптымізаваным для палягчэння аналізу і высноў. Неабходна прадумаць, як абстрагаваць тапалогію сістэмы падчас адладкі такім чынам, каб дапамагаць карыстачу пераадольваць сляпыя зоны, не зазіраючы ў асобныя trace'ы ці span'ы.
Нам патрэбныя добрыя магчымасці па абстрагаванні і разбіццю на ўзроўні (асабліва ў UI). Такія, якія добра ўпішуцца ў працэс адладкі на аснове гіпотэз, дзе можна ітэрацыйна задаваць пытанні і правяраць гіпотэзы. Яны не вырашаць усе праблемы з назіральнасцю аўтаматычна, аднак будуць дапамагаць карыстальнікам навострываць інтуіцыю і фармуляваць больш узважаныя пытанні. Я заклікаю да больш удумлівага і інавацыйнага падыходу ў галіне візуалізацыі. Тут ёсць рэальная перспектыва пашырыць гарызонты.
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «.
Крыніца: habr.com