Эскертүү. котормо.: Бул материалдын автору Синди Сридхаран, imgixтин инженери, API иштеп чыгуу жана, атап айтканда, микросервис тестирлөө боюнча адистешкен. Бул материалда ал бөлүштүрүлгөн трасса чөйрөсүндөгү актуалдуу көйгөйлөрдүн деталдуу көз карашы менен бөлүшөт, анын ою боюнча, актуалдуу көйгөйлөрдү чечүү үчүн чыныгы эффективдүү инструменттер жетишсиз.
[Иллюстрация алынган бөлүштүрүлгөн байкоо жөнүндө.]
Ойлонулууда ишке ашыруу кыйын, жана анын кайтарымы . Издөө көйгөйлүү болушунун көптөгөн себептери бар, көбүнчө ар бир сурам менен тиешелүү темаларды өткөрүү үчүн системанын ар бир компонентин конфигурациялоодо тартылган эмгекти мисал келтирет. Бул көйгөй бар болсо да, аны чечүү мүмкүн эмес. Айтмакчы, бул иштеп чыгуучулар эмне үчүн чалгындоону жактырбай турганын түшүндүрбөйт (ал мурунтан эле иштеп турганда да).
Бөлүштүрүлгөн байкоодогу негизги көйгөй маалыматтарды чогултуу, натыйжаларды таратуу жана көрсөтүү үчүн форматтарды стандартташтыруу же качан, кайда жана кантип тандап алууну аныктоо эмес. Мен элестеткенге аракет кылбайм арзыбаган бул "түшүнүктүүлүк көйгөйлөрү", чындыгында, абдан маанилүү техникалык жана (эгерде биз чындап Ачык булакты карап жатсак) ) бул проблемаларды чечуу учун жецуу керек болгон саясий проблемалар.
Бирок, эгерде бул көйгөйлөрдүн баары чечилди деп элестетсек, анда эч нерсе өзгөрбөшү ыктымал. акыркы колдонуучу тажрыйбасы. Издөө эң кеңири таралган мүчүлүштүктөрдү оңдоо сценарийлеринде иш жүзүндө колдонулбашы мүмкүн — ал орнотулгандан кийин да.
Мындай башкача из
Бөлүштүрүлгөн байкоо бир нече башка компоненттерди камтыйт:
- тиркемелерди жана орто программаларды башкаруу куралдары менен жабдуу;
- бөлүштүрүлгөн контекстти өткөрүп берүү;
- издерди чогултуу;
- из сактоо;
- аларды чыгаруу жана визуализациялоо.
Бөлүштүрүлгөн чалгындоо жөнүндө көп сөздөр аны системаны толук диагностикалоого жардам берүү максатын көздөгөн бирдиктүү операциянын бир түрү катары карашат. Бул негизинен бөлүштүрүлгөн трасса жөнүндөгү идеялардын тарыхый жактан калыптанганына байланыштуу. IN , Зипкин булактары ачылганда жасалган, деп айтылган ал [Zipkin] Twitterди тезирээк кылат. Издөө үчүн биринчи коммерциялык сунуштар да катары илгериледи .
Эскертүү. котормо.: Кийинки текстти түшүнүүнү жеңилдетүү үчүн, келгиле, эки негизги терминди аныктайлы :
- карыш — бөлүштүрүлгөн трассанын негизги элементи. Бул аты, башталышы жана аяктоо убактысы, тегдери, журналдары жана контексти менен белгилүү бир иш процессинин сүрөттөлүшү (мисалы, маалымат базасына суроо).
- Аралыктар адатта башка аралыктарга шилтемелерди камтыйт, бул бир нече аралыктарды бириктирүүгө мүмкүндүк берет Trace — бөлүштүрүлгөн система аркылуу өтүүчү суроо-талаптын жашоосун визуализациялоо.
Издерде өндүрүш тесттери, кырсыктан калыбына келтирүү тесттери, каталарды инъекциялоо тести ж.б. Чынында, кээ бир компаниялар ушуга окшош максаттар үчүн трассаны колдонушат. менен баштайлы жөн гана сактоо тутумуна аралыктарды жылдыруудан тышкары, башка максаттары бар:
- Мисалы, Uber сыноо трафиги менен өндүрүш трафигин айырмалоо үчүн жыйынтыктарды издөө.
- Facebook Критикалык жолду талдоо үчүн жана үзгүлтүксүз кырсыкты калыбына келтирүү сыноолорунун учурунда трафикти алмаштыруу үчүн маалыматтарды издөө.
- Ошондой эле социалдык тармак Иштеп чыгуучуларга издөө натыйжалары боюнча ыктыярдуу сурамдарды жүргүзүүгө мүмкүндүк берген Jupyter дептерлери.
- Жолдоочулар (Lineage Driven Failure Injection) ката инъекциясы менен тестирлөө үчүн бөлүштүрүлгөн издер.
Жогоруда саналган варианттардын бири да сценарийге толугу менен тиешелүү эмес мүчүлүштүктөрдү оңдоо, анын жүрүшүндө инженер изи карап маселени чечүүгө аракет кылат.
Качан келгенде баары бир мүчүлүштүктөрдү оңдоо скриптине жетет, негизги интерфейс диаграмма бойдон калат traceview (Бирок кээ бирлери аны да аташат "Гант диаграммасы" же "шаркыратма диаграммасы"). Under traceview я чогуу изди түзгөн бардык аралыктар жана коштолгон метадайындар. Ар бир ачык булак издөө тутуму, ошондой эле ар бир коммерциялык издөө чечими а traceview визуализациялоо, деталдаштыруу жана чыпкалоо үчүн колдонуучу интерфейси.
Мен буга чейин көргөн бардык издөө тутумдарындагы көйгөй - натыйжада визуализация (traceview) дээрлик толугу менен из генерациялоо процессинин өзгөчөлүктөрүн чагылдырат. Альтернативдик визуализациялар сунушталса да: жылуулук карталары, тейлөө топологиялары, күтүү гистограммалары, алар баары бир акыры traceview.
Өткөндө И UI/UX трассасындагы көпчүлүк "инновациялар" алар менен гана чектелип жаткандай кошумча метадайындарды издөө, аларга маалыматты жогорку кардиналдуулук менен инвестициялоо (жогорку кардиналдуулук) же белгилүү бир аралыктарга бургулоо же сурамдарды аткаруу мүмкүнчүлүгүн камсыз кылуу аралык жана ички из. Бул учурда, traceview негизги визуалдаштыруу куралы бойдон калууда. Мындай абал улана берсе, бөлүштүрүлгөн байкоо (эң жакшысы) метрикадан, журналдардан жана стек издеринен кийин мүчүлүштүктөрдү оңдоо куралы катары 4-орунду ээлейт, эң жаманы, бул акчаны жана убакытты текке кетирүү болуп калат.
Traceview менен көйгөй
тагдыр traceview — бөлүштүрүлгөн системанын бардык компоненттери боюнча бирдиктүү суроо-талаптын кыймылынын толук сүрөтүн камсыз кылуу. Кээ бир өркүндөтүлгөн чалгындоо системалары жеке аралыктарды бургулоого жана убакыттын өтүшү менен бузулууну көрүүгө мүмкүндүк берет ичинде бир процесс (аралыктардын функционалдык чектери болгондо).
Микросервистердин архитектурасынын негизги шарты - бул уюштуруу структурасы компаниянын керектөөлөрүнө жараша өсөт деген идея. Микросервистердин жактоочулары ар кандай бизнес-милдеттерди жеке кызматтарга бөлүштүрүү чакан, автономдуу иштеп чыгуу топторуна мындай кызматтардын бүткүл өмүр циклин көзөмөлдөөгө мүмкүндүк берип, аларга ошол кызматтарды өз алдынча куруу, сынап көрүү жана жайылтуу мүмкүнчүлүгүн берет деп ырасташат. Бирок, бул бөлүштүрүүнүн кемчилиги ар бир кызматтын башкалар менен кандай байланышы тууралуу маалыматтын жоголушу болуп саналат. Мындай шарттарда, бөлүштүрүлгөн байкоо үчүн зарыл курал болуп саналат деп ырастайт мүчүлүштүктөрдү оңдоо кызматтардын ортосундагы татаал өз ара аракеттенүү.
Эгер чын эле , анда бир да адам башына кармай албайт толук сүрөт. Чынында, ал тургай мүмкүн деген божомолдун негизинде куралды иштеп чыгуу анти-үлгү (натыйжасыз жана жемишсиз мамиле) болуп саналат. Идеалында, мүчүлүштүктөрдү оңдоо жардам берүүчү куралды талап кылат издөө аймагыңызды тарытуу, инженерлер каралып жаткан көйгөй сценарийине тиешелүү өлчөмдөрдүн бир бөлүгүнө (кызматтар/колдонуучулар/хосттор ж.б.) көңүл бурушу үчүн. Кырсыктын себебин аныктоодо, инженерлердин учурунда эмне болгонун түшүнүү талап кылынбайт бир эле учурда бардык кызматтар, анткени мындай талап микросервис архитектурасынын идеясына карама-каршы келет.
Бирок, traceview болуп саналат атап айтканда, Бул. Ооба, кээ бир чалгындоо тутумдары издеги аралыктардын саны ушунчалык чоң болгондуктан, аларды бир визуализацияда көрсөтүү мүмкүн эмес болгондо, кысылган трасса көрүнүштөрүн сунуштайт. Бирок, мындай чечкиндүү визуализацияда да камтылган маалыматтын чоң көлөмүнөн улам, инженерлер дагы деле мажбур Көйгөйлөрдүн булагы болуп саналган кызматтардын топтомун тандоону кол менен тарытуу менен, аны "элеп". Тилекке каршы, бул тармакта машиналар адамдарга караганда алда канча ылдамыраак, каталарга азыраак дуушар болушат жана алардын натыйжалары кайталануучураак.
Traceview туура эмес деп ойлоймун дагы бир себеби, ал гипотезага негизделген мүчүлүштүктөрдү оңдоо үчүн жакшы эмес. Анын өзөгүн оңдоо болуп саналат кайталануучу гипотезадан башталып, системадан алынган ар кандай байкоолорду жана фактыларды ар кандай векторлор боюнча текшерүү, тыянактар/жалпылоо жана гипотезанын чындыгын андан ары баалоо процесси.
мүмкүнчүлүк тез жана арзан гипотезаларды текшерүү жана ошого жараша психикалык моделди өркүндөтүү болуп саналат бурчтук таш мүчүлүштүктөрдү оңдоо Кандайдыр бир мүчүлүштүктөрдү оңдоо куралы болушу керек интерактивдүү жана издөө мейкиндигин тарытуу же жалган лидер болгон учурда, колдонуучуга артка кайтууга жана системанын башка аймагына көңүл бурууга мүмкүнчүлүк берет. Кемчиликсиз курал муну жасайт активдүү, колдонуучунун көңүлүн дароо мүмкүн болгон көйгөйлүү аймактарга бурат.
Аттиң, traceview интерактивдүү интерфейси бар курал деп атоого болбойт. Аны колдонууда сиз үмүт кыла турган эң жакшы нерсе, күтүү убактысынын көбөйгөн булагын табуу жана ага байланыштуу бардык мүмкүн болгон тегдерди жана журналдарды карап көрүү. Бул инженерге аныктоого жардам бербейт үлгүлөр трафикте, мисалы, кечиктирүүнү бөлүштүрүүнүн өзгөчөлүктөрү же ар кандай өлчөөлөрдүн ортосундагы корреляцияны аныктайт. бул көйгөйлөрдүн айрымдарын айланып өтүүгө жардам берет. Чынында, аномалдуу аралыктарды аныктоо жана аномалдуу жүрүм-турумга байланыштуу болушу мүмкүн болгон тегдердин бир бөлүгүн аныктоо үчүн машинаны үйрөнүүнү колдонуу менен ийгиликтүү талдоо. Бирок, мен машинаны үйрөнүүнүн же маалыматтарды казып алуунун ынандырарлык визуализациясын көрө элекмин, алар трассадан же DAGдан (багытталган ациклдик графиктен) олуттуу айырмаланган аралыктарга колдонулат.
Аралыктар өтө төмөн деңгээлде
Traceview менен негизги көйгөй болуп саналат аралыгы кечигүү анализи жана түпкү себептерди талдоо үчүн өтө төмөн деңгээлдеги примитивдер. Бул кайра иштетүү үчүн кыйла ыңгайлуу болгон backtrace сыяктуу бир топ жогорку деңгээлдеги куралдар бар экенин билип, өзгөчө кырдаалды чечүүгө аракет кылуу үчүн жеке процессор буйруктарын талдоо сыяктуу.
Андан тышкары, мен төмөнкүлөрдү ырастайм: идеалдуу, бизге кереги жок толук сүрөт Заманбап көзөмөлдөө куралдары менен берилген суроо-талаптын жашоо циклинде пайда болгон. Анын ордуна, эмне жөнүндө маалыматты камтыган жогорку деңгээлдеги абстракциянын кандайдыр бир түрү талап кылынат туура эмес кетти (backtrace окшош), кээ бир контекст менен бирге. Изди толугу менен көрүүнүн ордуна, мен аны көргүм келет бөлүк, кызыктуу же адаттан тыш нерсе болгон жерде. Азыркы учурда, издөө кол менен жүзөгө ашырылат: инженер изди кабыл алат жана өз алдынча кызыктуу бир нерсе издеп аралыктарды талдоо. Шектүү аракеттерди аныктоо үмүтү менен айрым издердеги аралыктарды караган адамдардын мамилеси такыр масштабдуу эмес (айрыкча, алар ар кандай мейкиндиктерде коддолгон бардык метаберилиштерди, мисалы, span ID, RPC методунун аталышы, аралыктын узактыгы сыяктуу маанисин түшүнүшү керек болгондо) 'a, журналдар, тегдер ж.б.).
Traceviewге альтернативалар
Издөө натыйжалары системанын бири-бири менен байланышкан бөлүктөрүндө эмне болуп жаткандыгы жөнүндө майда-чүйдө эмес түшүнүктү камсыз кылуучу жол менен визуализацияланганда абдан пайдалуу болот. Бул ишке ашмайынча, мүчүлүштүктөрдү оңдоо процесси негизинен кала берет инерттүү жана колдонуучунун туура корреляцияларды байкай алуу, системанын туура бөлүктөрүн текшерүү же табышмактын бөлүктөрүн бириктирүү жөндөмүнө жараша болот. аспап, колдонуучуга бул гипотезаларды түзүүгө жардам берүү.
Мен визуалдык дизайнер же UX адиси эмесмин, бирок кийинки бөлүмдө бул визуализациялар кандай болушу мүмкүн экендиги тууралуу бир нече идеялар менен бөлүшкүм келет.
Конкреттүү кызматтарга көңүл буруңуз
Индустрия идеялардын айланасында консолидацияланып жаткан учурда , жеке командалар өз кызматтарынын ушул максаттарга шайкеш келишин камсыз кылууга артыкчылык бериши акылга сыярлык. Ушундан улам келип чыгат кызмат багытталган визуализация мындай командалар үчүн эң ылайыктуу.
Издер, өзгөчө үлгүлөрдү алуусуз, бөлүштүрүлгөн системанын ар бир компоненти жөнүндө маалымат казынасы болуп саналат. Бул маалымат колдонуучуларды камсыз кыла турган куу процессорго берилиши мүмкүн кызмат багытталган Алар алдын ала аныкталышы мүмкүн - ал тургай, колдонуучу издерине карап:
- Өтө көрүнүктүү суроо-талаптар үчүн гана күтүү бөлүштүрүү диаграммалары (черээк суроо-талаптар);
- Кызматтын SLO максаттарына жетпеген учурлар үчүн кечиктирүүнү бөлүштүрүүнүн диаграммалары;
- Көбүнчө суроо-талаптардагы эң "кеңири таралган", "кызыктуу" жана "кызыктуу" тэгдер кайталанат;
- учурлар үчүн кечигүү бөлүштүрүү жараша кызматтар SLO максаттарына жетпейт;
- Ар кандай ылдый агым кызматтары үчүн кечигүү.
Бул суроолордун айрымдары жөн гана орнотулган метрика менен жооп бербейт, бул колдонуучуларды мейкиндикти текшерүүгө мажбурлайт. Натыйжада, бизде өтө душмандык механизм бар.
Бул суроо туулат: ар кандай командалар тарабынан көзөмөлдөнгөн ар түрдүү кызматтардын ортосундагы татаал өз ара аракеттенүү жөнүндө эмне айтууга болот? эмеспи traceview мындай кырдаалды чагылдыруу үчүн эң ылайыктуу курал болуп эсептелбейт?
Мобилдик иштеп чыгуучулар, жарандыгы жок кызматтардын ээлери, башкарылган мамлекеттик кызматтардын ээлери (мисалы, маалымат базалары) жана платформа ээлери башка нерсеге кызыгышы мүмкүн презентация бөлүштүрүлгөн система; traceview бул түп-тамырынан бери ар кандай муктаждыктар үчүн өтө жалпы чечим болуп саналат. Атүгүл өтө татаал микросервис архитектурасында кызмат ээлерине эки же үчтөн ашык жогору жана ылдый агым кызматтары боюнча терең билимдин кереги жок. Негизинен, көпчүлүк сценарийлерде колдонуучулар суроолорго жооп бериши керек кызматтардын чектелген топтому.
Бул кызматтын кичинекей бөлүгүн карап чыгуу үчүн чоңойтуучу айнек аркылуу караган сыяктуу. Бул колдонуучуга бул кызматтардын жана алардын түздөн-түз көз карандылыктарынын ортосундагы татаал өз ара аракеттенүү боюнча актуалдуу суроолорду берүүгө мүмкүндүк берет. Бул инженер билген кызматтар дүйнөсүндөгү артка кайтууга окшош ошол туура эмес, ошондой эле түшүнүү үчүн курчап турган кызматтарда эмне болуп жатканын бир аз түшүнөт эмне үчүн.
Мен сунуштап жаткан ыкма жогорудан ылдыйга, трасцензияга негизделген ыкмага так карама-каршы келет, мында талдоо бүт из менен башталып, андан кийин акырындык менен айрым аралыктарга чейин иштейт. Ал эми, ылдыйдан өйдө карай мамиле инциденттин потенциалдуу себебине жакын кичинекей аймакты талдоо менен башталат, андан кийин керек болсо издөө мейкиндигин кеңейтет (кызматтардын кеңири спектрин талдоо үчүн башка командаларды тартуу мүмкүнчүлүгү менен). Экинчи ыкма алгачкы гипотезаларды тез текшерүү үчүн ылайыктуу. Конкреттүү натыйжалар алынгандан кийин, көбүрөөк багытталган жана деталдуу талдоо жүргүзүүгө өтүүгө болот.
Топологияны түзүү
Колдонуучу билсе, кызматка тиешелүү көрүнүштөр абдан пайдалуу болушу мүмкүн кайсы кызмат же кызматтардын тобу кечиктирүүнү жогорулатуу же каталарды пайда кылуу үчүн жооптуу. Бирок, татаал системада бузулган кызматты аныктоо, өзгөчө, кызматтардан эч кандай ката билдирүүлөрү билдирилбесе, катачылык учурунда маанилүү эмес иш болушу мүмкүн.
Кызматтын топологиясын түзүү кайсы кызмат каталардын ылдамдыгынын жогорулашын же кызматтын байкаларлык начарлашына алып келген күтүү убактысынын көбөйүшүн аныктоого чоң жардам берет. Мен топологияны куруу жөнүндө айтканда, мен айткым келбейт кызматтар картасы, системада жеткиликтүү жана анын белгилүү болгон ар бир кызмат көрсөтүү . Бул көрүнүш багытталган ациклдик графикке негизделген трассадан жакшыраак эмес. Анын ордуна мен көргүм келет динамикалык түрдө түзүлгөн кызмат топологиясы, ката ылдамдыгы, жооп берүү убактысы же белгилүү бир шектүү кызматтар менен кырдаалды тактоого жардам берген колдонуучу аныктаган параметр сыяктуу белгилүү атрибуттарга негизделген.
Мисал келтирели. Келгиле, гипотетикалык жаңылык сайтын элестетип көрөлү. Башкы бет кызматы (башкы бет) Редис менен, сунуштоо кызматы, жарнама кызматы жана видео кызматы менен маалымат алмашат. Видео кызматы S3тен видеолорду жана DynamoDBден метаберилиштерди алат. Сунуштоо кызматы DynamoDBдан метаберилиштерди алат, Redis жана MySQLден маалыматтарды жүктөйт жана Кафкага билдирүүлөрдү жазат. Жарнама кызматы MySQLден маалыматтарды алат жана Кафкага билдирүүлөрдү жазат.
Төмөндө бул топологиянын схемалык көрүнүшү (көптөгөн коммерциялык маршруттук программалар топологияны курат). Кызматтык көз карандылыкты түшүнүү керек болсо, бул пайдалуу болушу мүмкүн. Бирок, учурунда мүчүлүштүктөрдү оңдоо, белгилүү бир кызмат (айталы, видео кызматы) көбөйгөн жооп берүү убактысын көрсөткөндө, мындай топология анча пайдалуу эмес.
Гипотетикалык жаңылык сайтынын кызматтык диаграммасы
Төмөнкү диаграмма жакшыраак ылайыктуу болот. Кызматта көйгөй бар (Video) так борборунда сүрөттөлгөн. Колдонуучу аны дароо байкайт. Бул визуализациядан видео кызматы S3 жооп берүү убактысынын көбөйүшүнө байланыштуу анормалдуу иштеп жатканы көрүнүп турат, бул башкы беттин бир бөлүгүн жүктөө ылдамдыгына таасирин тийгизет.
Динамикалык топология "кызыктуу" кызматтарды гана көрсөтөт
Динамикалык түрдө түзүлгөн топологиялар статикалык тейлөө карталарына караганда эффективдүү болушу мүмкүн, айрыкча ийкемдүү, авто-масштабдык инфраструктураларда. Кызмат топологияларын салыштыруу жана карама-каршы коюу мүмкүнчүлүгү колдонуучуга актуалдуу суроолорду берүүгө мүмкүнчүлүк берет. Система тууралуу так суроолор системанын кантип иштээрин жакшыраак түшүнүүгө алып келет.
Салыштырмалуу дисплей
Дагы бир пайдалуу визуализация салыштырмалуу дисплей болмок. Учурда издер жанаша салыштыруу үчүн анча ылайыктуу эмес, ошондуктан салыштыруулар адатта аралыгы. Жана бул макаланын негизги идеясы, так натыйжалардан эң баалуу маалыматты алуу үчүн аралыктар өтө төмөн.
Эки изди салыштыруу принципиалдуу жаңы визуализацияларды талап кылбайт. Чынында эле, гистограмма сыяктуу бир нерсе, трасцензия менен бирдей маалыматты чагылдыруу жетиштүү. Таң калыштуусу, бул жөнөкөй ыкма да эки изи өзүнчө изилдөөгө караганда алда канча көп жемиш алып келиши мүмкүн. Мындан да күчтүү мүмкүнчүлүк болмок визуализациялоо издерди салыштыруу Жалпысынан. GC (таштанды жыйноо) иштетүү үчүн жакында орнотулган маалымат базасынын конфигурациясынын өзгөрүшү бир нече сааттык масштабда ылдый агымдагы кызматтын жооп берүү убактысына кандай таасир этээрин көрүү абдан пайдалуу болмок. Эгерде мен бул жерде сүрөттөп жаткан нерсе инфраструктуралык өзгөрүүлөрдүн таасиринин A/B анализи сыяктуу сезилсе көп кызматтарда из натыйжаларын колдонуп, анда сиз чындыктан өтө алыс эмес.
жыйынтыктоо
Мен трассанын өзүнүн пайдалуулугунан шек санабайм. Мен чын жүрөктөн маалыматтарды чогултуу үчүн из камтылгандай бай, себептүү жана контексттик башка ыкма жок деп ишенем. Бирок, мен ошондой эле бардык издөө чечимдери бул маалыматтарды өтө натыйжасыз колдонот деп ишенем. Издөө инструменттери трасса көрүнүшүндө тыгылып кала бергенде, алар издерде камтылган маалыматтардан алынуучу баалуу маалыматтын максималдуу түрдө пайдалануу мүмкүнчүлүгү чектелет. Мындан тышкары, колдонуучунун тиркемедеги каталарды жоюу мүмкүнчүлүгүн кескин чектей турган таптакыр достук эмес жана интуитивдик визуалдык интерфейсти андан ары өнүктүрүү коркунучу бар.
Татаал системаларды мүчүлүштүктөрдү оңдоо, атүгүл эң акыркы куралдар менен, укмуштуудай кыйын. Куралдар иштеп чыгуучуга гипотезаны түзүүгө жана текшерүүгө жардам бериши керек, активдүү камсыз кылуу тиешелүү маалымат, четтөөлөрдү аныктоо жана кечиктирүүлөрдү бөлүштүрүүдө өзгөчөлүктөрдү белгилөө. Өндүрүштөгү мүчүлүштүктөрдү жоюуда же бир нече кызматтарды камтыган көйгөйлөрдү чечүүдө иштеп чыгуучулардын тандоо куралы болуп калуу үчүн, оригиналдуу колдонуучу интерфейстери жана визуализациялары керек, алар ошол кызматтарды түзүп, иштеткен иштеп чыгуучулардын психикалык моделине көбүрөөк шайкеш келет.
Анализ жана тыянак чыгаруу жеңилдиги үчүн оптималдаштырылган жол менен изи натыйжаларында жеткиликтүү болгон ар кандай сигналдарды чагылдыра турган системаны иштеп чыгуу үчүн олуттуу психикалык күч талап кылынат. Мүчүлүштүктөрдү оңдоо учурунда системанын топологиясын кантип абстракциялоо керектиги жөнүндө ойлонушуңуз керек, бул колдонуучуга айрым издерди же аралыктарды карабастан сокур тактарды жеңүүгө жардам берет.
Бизге жакшы абстракция жана катмарлоо мүмкүнчүлүктөрү керек (айрыкча UIде). Гипотезага негизделген мүчүлүштүктөрдү оңдоо процессине ылайыктуу болгондор, анда сиз кайталап суроолорду берип, гипотезаларды сынай аласыз. Алар бардык байкоо жүргүзүү көйгөйлөрүн автоматтык түрдө чечпейт, бирок алар колдонуучуларга интуицияларын курчутууга жана акылдуу суроолорду түзүүгө жардам берет. Мен визуализацияга көбүрөөк ойлонулган жана жаңычыл мамилеге чакырам. Бул жерде горизонтторду кеңейтүү үчүн реалдуу перспектива бар.
Котормочудан PS
Биздин блогдон дагы окуңуз:
- «";
- «";
- ««.
Source: www.habr.com