Qeyd. tərcümə.: Bu materialın müəllifi imgix-də API işlənməsi və xüsusilə mikroservis testi üzrə ixtisaslaşan mühəndis Sindi Sridharandır. Bu materialda, onun fikrincə, aktual problemlərin həlli üçün həqiqətən təsirli vasitələrin çatışmazlığı olan paylanmış izləmə sahəsində mövcud problemlərə dair ətraflı baxışını bölüşür.
[İllüstrasiya ondan götürülmüşdür paylanmış izləmə haqqında.]
Bu hesab edilir ki, həyata keçirmək çətindir və bunun qaytarılması . İzləmənin problemli olmasının bir çox səbəbi var, tez-tez hər bir sorğu ilə müvafiq başlıqları ötürmək üçün hər bir sistem komponentinin konfiqurasiyasına cəlb olunan əməyə istinad edilir. Bu problem mövcud olsa da, heç bir halda həll edilə bilməz. Yeri gəlmişkən, bu, tərtibatçıların izləməyi niyə sevmədiyini izah etmir (hətta artıq işlədiyi halda da).
Paylanmış izləmə ilə bağlı əsas problem məlumatların toplanması, nəticələrin yayılması və təqdim edilməsi üçün formatların standartlaşdırılması və ya nümunənin nə vaxt, harada və necə aparılacağını müəyyən etmək deyil. Mən təsəvvür etməyə çalışmıram əhəmiyyətsiz bu "anlaşılanlıq problemləri" əslində olduqca əhəmiyyətli texnikidir və (əgər biz həqiqətən Açıq Mənbəni nəzərdən keçiririksə) ) bu problemlərin həll edilmiş hesab edilməsi üçün aradan qaldırılmalı olan siyasi çağırışlar.
Ancaq bütün bu problemlərin həll olunduğunu təsəvvür etsək, heç bir şeyin əhəmiyyətli dərəcədə dəyişməyəcəyi ehtimalı yüksəkdir. son istifadəçi təcrübəsi. İzləmə ən çox yayılmış sazlama ssenarilərində, hətta tətbiq edildikdən sonra da praktiki istifadə olmaya bilər.
Belə fərqli bir iz
Paylanmış izləmə bir neçə fərqli komponentdən ibarətdir:
- proqramların və ara proqramların idarəetmə vasitələri ilə təchiz edilməsi;
- paylanmış kontekst transferi;
- izlərin toplanması;
- iz saxlama;
- onların çıxarılması və vizuallaşdırılması.
Paylanmış izləmə haqqında çoxlu söhbətlər onu yeganə məqsədi sistemə tam diaqnoz qoymağa kömək etmək olan bir növ vahid əməliyyat kimi qəbul etməyə meyllidir. Bu, əsasən paylanmış izləmə haqqında fikirlərin tarixən necə formalaşması ilə bağlıdır. IN , Zipkin mənbələri açıldığında edildiyi qeyd edilmişdir bu [Zipkin] Twitter-i daha sürətli edir. İzləmə üçün ilk kommersiya təklifləri də olaraq təşviq edildi .
Qeyd. tərcümə.: Əlavə mətnin başa düşülməsini asanlaşdırmaq üçün gəlin aşağıdakılara uyğun olaraq iki əsas termini müəyyən edək :
- Span — paylanmış izləmənin əsas elementi. Bu, adı, başlanğıc və bitmə vaxtları, teqlər, qeydlər və kontekstlə müəyyən iş axınının (məsələn, verilənlər bazası sorğusunun) təsviridir.
- Aralıqlar adətən digər aralıqlara keçidlər ehtiva edir və bu, birdən çox aralığın birləşdirilməsinə imkan verir Trace — paylanmış sistem vasitəsilə hərəkət edən sorğunun ömrünün vizuallaşdırılması.
İzlər istehsal sınağı, fəlakətin bərpası sınağı, səhv inyeksiya sınağı və s. kimi tapşırıqlarda kömək edə biləcək inanılmaz qiymətli məlumatları ehtiva edir. Əslində, bəzi şirkətlər artıq oxşar məqsədlər üçün izləmədən istifadə edirlər. ilə başlayaq Saxlama sisteminə boşluqları köçürməkdən başqa başqa məqsədləri də var:
- Məsələn, Uber sınaq trafiki və istehsal trafiki arasında fərq yaratmaq üçün nəticələrin izlənməsi.
- Facebook kritik yolun təhlili və müntəzəm fəlakətin bərpası sınaqları zamanı trafikin dəyişdirilməsi üçün məlumatların izlənməsi.
- Həm də sosial şəbəkə Tərtibatçılara izləmə nəticələrinə dair ixtiyari sorğular keçirməyə imkan verən Jupyter noutbukları.
- İzləyicilər (Lineage Driven Failure Injection) səhv inyeksiya ilə sınaq üçün paylanmış izlər.
Yuxarıda sadalanan variantlardan heç biri tam olaraq ssenariyə aid deyil ayıklama, bu müddət ərzində mühəndis izə baxaraq problemi həll etməyə çalışır.
Gələndə hələ sazlama skriptinə çatır, əsas interfeys diaqram olaraq qalır izləmə (baxmayaraq ki, bəziləri bunu da adlandırır "Gantt chart" və ya "şəlalə diaqramı"). Altında izləmə я birlikdə izi təşkil edən bütün aralıqlar və onu müşayiət edən metadata. Hər açıq mənbə izləmə sistemi, eləcə də hər bir kommersiya izləmə həlli təklif edir izləmə izləri vizuallaşdırmaq, detallaşdırmaq və filtrləmək üçün istifadəçi interfeysi.
İndiyə qədər gördüyüm bütün izləmə sistemləri ilə bağlı problem bunun nəticəsidir vizuallaşdırma (traceview) iz yaratmaq prosesinin xüsusiyyətlərini demək olar ki, tamamilə əks etdirir. Alternativ vizuallaşdırmalar təklif edildikdə belə: istilik xəritələri, xidmət topologiyaları, gecikmə histoqramları, onlar yenə də son nəticəyə gəlirlər. izləmə.
Keçmişdə İ UI/UX izləmə "yeniliklərinin" əksəriyyəti bununla məhdudlaşır izdə əlavə metadata, onlara yüksək kardinallıqla məlumat yatırmaq (yüksək kardinallıq) və ya xüsusi aralıqlara endirmək və ya sorğuları yerinə yetirmək imkanı təmin edir inter- və intra-iz. Bununla izləmə əsas vizuallaşdırma vasitəsi olaraq qalır. Bu vəziyyət davam etdikcə, paylanmış izləmə (ən yaxşı halda) ölçülərdən, qeydlərdən və yığın izlərindən sonra sazlama vasitəsi kimi 4-cü yeri tutacaq və ən pis halda bu, pul və vaxt itkisinə çevriləcək.
İzləmə ilə bağlı problem
Məqsəd izləmə — əlaqəli olduğu paylanmış sistemin bütün komponentləri üzrə vahid sorğunun hərəkətinin tam təsvirini təqdim etmək. Bəzi daha təkmil izləmə sistemləri sizə ayrı-ayrı aralıqlara endirməyə və zamanla qəzaya baxmaq imkanı verir daxilində bir proses (aralıqların funksional sərhədləri olduqda).
Mikroservislər arxitekturasının əsas müddəası təşkilati strukturun şirkətin ehtiyacları ilə böyüdüyü ideyasıdır. Mikroservislərin tərəfdarları iddia edirlər ki, müxtəlif biznes tapşırıqlarının fərdi xidmətlərə paylanması kiçik, avtonom inkişaf qruplarına bu cür xidmətlərin bütün həyat dövrünə nəzarət etməyə imkan verir və onlara bu xidmətləri müstəqil şəkildə qurmaq, sınaqdan keçirmək və yerləşdirmək imkanı verir. Bununla belə, bu paylamanın dezavantajı hər bir xidmətin digərləri ilə qarşılıqlı əlaqəsi haqqında məlumatın itirilməsidir. Belə şərtlərdə, paylanmış təqib üçün vazgeçilmez bir vasitə olduğunu iddia edir ayıklama xidmətlər arasında mürəkkəb qarşılıqlı əlaqə.
Əgər həqiqətən , onda heç bir adam onu başında saxlaya bilmir tamamlandı şəkil. Əslində, bunun hətta mümkün olduğu fərziyyəsinə əsaslanaraq alət hazırlamaq bir növ anti-naxışdır (səmərəsiz və məhsuldar olmayan yanaşma). İdeal olaraq, ayıklama kömək edən bir vasitə tələb edir axtarış sahəsini daralt, belə ki, mühəndislər nəzərdən keçirilən problem ssenarisinə uyğun ölçülər alt çoxluğuna (xidmətlər/istifadəçilər/hostlar və s.) diqqət yetirə bilsinlər. Arızanın səbəbini təyin edərkən, mühəndislərdən proses zamanı nə baş verdiyini başa düşmələri tələb olunmur bütün xidmətlər bir anda, çünki belə bir tələb mikroservis arxitekturası ideyasına zidd olardı.
Bununla belə, traceview edir yəni Bu. Bəli, bəzi izləmə sistemləri izdəki aralıqların sayı o qədər böyük olduqda, onları bir vizuallaşdırmada göstərmək mümkün olmayanda sıxılmış izləmə görüntüləri təklif edir. Bununla belə, belə bir soyudulmuş vizuallaşdırmada belə böyük miqdarda məlumat olduğundan, mühəndislər hələ də məcbur Seçimi problem mənbəyi olan xidmətlər dəstinə əl ilə daraldaraq, onu "ələyin". Təəssüf ki, bu sahədə maşınlar insanlardan çox sürətlidir, səhvlərə daha az meyllidir və onların nəticələri daha çox təkrarlanır.
Traceview-in səhv olduğunu düşündüyüm başqa bir səbəb, onun hipoteza əsaslanan sazlama üçün yaxşı olmamasıdır. Əsasında sazlamadır iterativ fərziyyə ilə başlayan proses, sonra müxtəlif vektorlar üzrə sistemdən əldə edilən müxtəlif müşahidələrin və faktların yoxlanılması, nəticələr/ümumiləşdirmələr və fərziyyənin doğruluğunun sonrakı qiymətləndirilməsi.
Imkan sürətli və ucuz hipotezlərin sınaqdan keçirilməsi və buna uyğun olaraq zehni modelin təkmilləşdirilməsidir təməl daşı sazlama Hər hansı bir ayıklama vasitəsi olmalıdır interaktiv və axtarış sahəsini daraldın və ya yalançı lider olduqda, istifadəçiyə geri qayıtmağa və sistemin fərqli bir sahəsinə diqqət yetirməyə icazə verin. Mükəmməl vasitə bunu edəcək fəal şəkildə, dərhal istifadəçinin diqqətini potensial problem sahələrinə cəlb edir.
Heyif, izləmə interaktiv interfeysli alət adlandırmaq olmaz. Onu istifadə edərkən ümid edə biləcəyiniz ən yaxşı şey, artan gecikmə mənbəyini tapmaq və onunla əlaqəli bütün mümkün etiketlərə və qeydlərə baxmaqdır. Bu mühəndisə müəyyən etməyə kömək etmir naxışlar trafikdə, məsələn, gecikmə paylanmasının xüsusiyyətləri və ya müxtəlif ölçmələr arasında korrelyasiyaları aşkar edin. bu problemlərin bəzilərini həll etməyə kömək edə bilər. Həqiqətən, anormal aralıqları müəyyən etmək və anomal davranışla əlaqəli ola biləcək teqlər alt dəstini müəyyən etmək üçün maşın öyrənməsindən istifadə edərək uğurlu təhlil. Bununla belə, mən hələ də traseview və ya DAG-dan (istiqamətləndirilmiş asiklik qrafik) əhəmiyyətli dərəcədə fərqli olan aralıqlara tətbiq olunan maşın öyrənməsi və ya məlumatların öyrənilməsi tapıntılarının cəlbedici vizualizasiyalarını görməmişəm.
Aralıqlar çox aşağı səviyyədədir
Traceview ilə bağlı əsas problem budur uzanır həm gecikmə təhlili, həm də kök səbəb təhlili üçün çox aşağı səviyyəli primitivlərdir. Bu, işləmək üçün daha rahat olan backtrace kimi daha yüksək səviyyəli alətlərin olduğunu bilərək, istisnanı həll etməyə çalışmaq üçün fərdi prosessor əmrlərini təhlil etmək kimidir.
Bundan əlavə, mən aşağıdakıları iddia etmək azadlığını götürəcəyəm: ideal olaraq, ehtiyacımız yoxdur tam şəkil müasir izləmə vasitələri ilə təmsil olunan sorğunun həyat dövrü ərzində baş verdi. Bunun əvəzinə, nə haqqında məlumatı ehtiva edən daha yüksək səviyyəli abstraksiya forması tələb olunur səhv getdi (backtrace oxşar), bəzi kontekstlə birlikdə. Bütün izi izləmək əvəzinə onu görməyə üstünlük verirəm часть, maraqlı və ya qeyri-adi bir şeyin baş verdiyi yer. Hazırda axtarış əl ilə aparılır: mühəndis izi alır və maraqlı bir şey axtarışında müstəqil şəkildə spanları təhlil edir. Şübhəli fəaliyyəti aşkar etmək ümidi ilə fərdi izlərdə spanlara baxan insanların yanaşması heç də miqyaslı deyil (xüsusilə onlar span ID-si, RPC metodunun adı, span müddəti kimi müxtəlif diapazonlarda kodlanmış bütün metadataları anlamağa məcbur olduqda 'a, qeydlər, etiketlər və s.).
Traceview üçün alternativlər
İzləmə nəticələri, sistemin bir-biri ilə əlaqəli hissələrində baş verənlər haqqında qeyri-ciddi fikir təmin edən şəkildə vizuallaşdırıla bildikdə ən faydalıdır. Bu baş verənə qədər, sazlama prosesi əsasən qalır inert və istifadəçinin düzgün korrelyasiyaları fərq etmək, sistemin düzgün hissələrini yoxlamaq və ya tapmacanın hissələrini bir araya gətirmək qabiliyyətindən asılıdır - əksinə alət, istifadəçiyə bu fərziyyələri formalaşdırmağa kömək edir.
Mən vizual dizayner və ya UX mütəxəssisi deyiləm, lakin növbəti hissədə bu vizuallaşdırmaların necə görünə biləcəyi ilə bağlı bir neçə fikri bölüşmək istəyirəm.
Xüsusi xidmətlərə diqqət yetirin
Sənayenin ideyalar ətrafında birləşdiyi bir vaxtda , fərdi komandaların öz xidmətlərinin bu məqsədlərə uyğun olmasını təmin etmək üçün prioritet verməsi ağlabatan görünür. Bundan belə çıxır xidmət yönümlü vizuallaşdırma belə komandalar üçün ən uyğundur.
İzlər, xüsusən də nümunə götürmədən, paylanmış sistemin hər bir komponenti haqqında məlumat xəzinəsidir. Bu məlumat istifadəçiləri təmin edəcək hiyləgər bir prosessora verilə bilər xidmət yönümlü Onlar əvvəlcədən müəyyən edilə bilər - hətta istifadəçi izlərə baxmazdan əvvəl:
- Gecikmə paylama diaqramları yalnız yüksək dərəcədə nəzərə çarpan sorğular üçün (xarici tələblər);
- Xidmətin SLO məqsədlərinə nail olunmadığı hallar üçün gecikmələrin paylanması diaqramları;
- Sorğularda ən çox rast gəlinən, “maraqlı” və “qəribə” etiketlər təkrar olunur;
- hallar üçün gecikmə bölgüsü bağımlılıkları xidmətlər SLO məqsədlərinə çatmır;
- Müxtəlif aşağı xidmətlər üçün gecikmə bölgüsü.
Bu suallardan bəziləri sadəcə olaraq daxili ölçülərlə cavablandırılmır, bu da istifadəçiləri spanları diqqətlə nəzərdən keçirməyə məcbur edir. Nəticədə, son dərəcə istifadəçi düşmən mexanizmimiz var.
Bu, sual doğurur: müxtəlif komandalar tərəfindən idarə olunan müxtəlif xidmətlər arasında mürəkkəb qarşılıqlı əlaqə haqqında nə demək olar? elə deyilmi izləmə belə bir vəziyyəti işıqlandırmaq üçün ən uyğun vasitə hesab edilmir?
Mobil tərtibatçılar, vətəndaşlığı olmayan xidmətlərin sahibləri, idarə olunan dövlət xidmətlərinin sahibləri (məsələn, verilənlər bazası) və platforma sahibləri başqa bir şeylə maraqlana bilər. təqdimat paylanmış sistem; izləmə bu əsaslı fərqli ehtiyaclar üçün çox ümumi bir həlldir. Hətta çox mürəkkəb mikroservis arxitekturasında xidmət sahiblərinin iki və ya üçdən çox yuxarı və aşağı xidmətlər haqqında dərin biliyə ehtiyacı yoxdur. Əslində, əksər ssenarilərdə istifadəçilər yalnız bununla bağlı suallara cavab verməlidirlər məhdud xidmətlər dəsti.
Bu, kiçik bir xidmət alt dəstinə onu diqqətlə araşdırmaq üçün böyüdücü şüşə vasitəsilə baxmaq kimidir. Bu, istifadəçiyə bu xidmətlər və onların birbaşa asılılıqları arasında mürəkkəb qarşılıqlı əlaqə ilə bağlı daha aktual suallar verməyə imkan verəcək. Bu, mühəndisin bildiyi xidmətlər dünyasında geri çəkilməyə bənzəyir o səhvdir və ətrafdakı xidmətlərdə nələr baş verdiyini anlamaq üçün bəzi anlayışlara malikdir niyə.
Təşviq etdiyim yanaşma yuxarıdan aşağıya, traseview-əsaslı yanaşmanın tam əksidir, burada təhlil bütün izdən başlayır və sonra tədricən ayrı-ayrı diapazonlara qədər işləyir. Bunun əksinə olaraq, aşağıdan yuxarıya yanaşma hadisənin potensial səbəbinə yaxın olan kiçik bir sahənin təhlili ilə başlayır və sonra ehtiyac olduqda axtarış sahəsini genişləndirir (daha geniş spektrli xidmətlərin təhlili üçün digər komandaların cəlb edilməsi potensialı ilə). İkinci yanaşma ilkin fərziyyələri tez yoxlamaq üçün daha uyğundur. Konkret nəticələr əldə edildikdən sonra daha diqqətli və ətraflı təhlilə keçmək mümkün olacaq.
Topologiyanın qurulması
İstifadəçi bilirsə, xidmətə xüsusi baxışlar inanılmaz dərəcədə faydalı ola bilər nədir xidmət və ya xidmətlər qrupu gecikmənin artmasına və ya xətaların yaranmasına görə məsuliyyət daşıyır. Bununla belə, mürəkkəb sistemdə xəta törədən xidmətin müəyyən edilməsi uğursuzluq zamanı qeyri-ciddi bir iş ola bilər, xüsusən də xidmətlərdən heç bir səhv mesajı bildirilməyibsə.
Xidmət topologiyasının qurulması, hansı xidmətin səhv dərəcələrində artım və ya xidmətin nəzərəçarpacaq dərəcədə pisləşməsinə səbəb olan gecikmə müddətində artım olduğunu anlamaqda böyük kömək ola bilər. Mən bir topologiya qurmaq haqqında danışarkən, bunu nəzərdə tutmuram xidmətlərin xəritəsi, sistemdə mövcud olan və onunla tanınan hər bir xidməti göstərir . Bu görünüş yönləndirilmiş asiklik qrafikə əsaslanan traceviewdən yaxşı deyil. Əksinə mən görmək istərdim dinamik şəkildə yaradılan xidmət topologiyası, xəta dərəcəsi, cavab müddəti və ya xüsusi şübhəli xidmətlərlə vəziyyəti aydınlaşdırmağa kömək edən hər hansı istifadəçi tərəfindən müəyyən edilmiş parametr kimi müəyyən atributlara əsaslanır.
Bir nümunə götürək. Gəlin hipotetik xəbər saytını təsəvvür edək. Əsas səhifə xidməti (ön səhifə) Redis ilə tövsiyə xidməti, reklam xidməti və video xidməti ilə məlumat mübadiləsi aparır. Video xidməti S3-dən videolar və DynamoDB-dən metadata alır. Tövsiyə xidməti DynamoDB-dən metadata alır, Redis və MySQL-dən məlumatları yükləyir və Kafkaya mesajlar yazır. Reklam xidməti MySQL-dən məlumatları alır və Kafkaya mesajlar yazır.
Aşağıda bu topologiyanın sxematik təsviri verilmişdir (bir çox kommersiya marşrutlaşdırma proqramları topologiyanı qurur). Xidmətdən asılılıqları anlamaq lazımdırsa, bu faydalı ola bilər. Lakin, ərzində ayıklama, müəyyən bir xidmət (məsələn, video xidmət) artan cavab müddəti nümayiş etdirdikdə, belə bir topologiya çox faydalı deyil.
Hipotetik xəbər saytının xidmət diaqramı
Aşağıdakı diaqram daha uyğun olardı. Xidmətdə problem var (video) düz mərkəzdə təsvir edilmişdir. İstifadəçi bunu dərhal hiss edir. Bu vizuallaşdırmadan aydın olur ki, video xidmət S3 cavab müddətinin artması səbəbindən anormal işləyir və bu, əsas səhifənin bir hissəsinin yükləmə sürətinə təsir göstərir.
Yalnız "maraqlı" xidmətləri göstərən dinamik topologiya
Dinamik olaraq yaradılan topologiyalar statik xidmət xəritələrindən daha səmərəli ola bilər, xüsusən elastik, avtomatik miqyaslı infrastrukturlarda. Xidmət topologiyalarını müqayisə etmək və müqayisə etmək imkanı istifadəçiyə daha uyğun suallar verməyə imkan verir. Sistem haqqında daha dəqiq suallar sistemin necə işlədiyini daha yaxşı başa düşməyə səbəb ola bilər.
Müqayisəli ekran
Başqa bir faydalı vizuallaşdırma müqayisəli ekran olardı. Hazırda izlər yan-yana müqayisələr üçün çox uyğun deyil, ona görə də müqayisələr adətən uzanır. Və bu məqalənin əsas ideyası, izlərin nəticələrindən ən qiymətli məlumatı çıxarmaq üçün məsafələrin çox aşağı səviyyədə olmasıdır.
İki izi müqayisə etmək prinsipcə yeni vizuallaşdırma tələb etmir. Əslində, izləmə ilə eyni məlumatı təmsil edən histoqram kimi bir şey kifayətdir. Təəccüblüdür ki, hətta bu sadə üsul iki izi ayrı-ayrılıqda öyrənməkdən daha çox meyvə gətirə bilər. Daha da güclü ehtimal olardı vizuallaşdırmaq izlərin müqayisəsi Toplam. GC (zibil toplama) aktivləşdirmək üçün bu yaxınlarda yerləşdirilmiş verilənlər bazası konfiqurasiya dəyişikliyinin bir neçə saatlıq miqyasda aşağı axın xidmətinin cavab müddətinə necə təsir etdiyini görmək çox faydalı olardı. Əgər burada təsvir etdiyim şey infrastruktur dəyişikliklərinin təsirinin A/B təhlili kimi səslənirsə bir çox xidmətlərdə iz nəticələrini istifadə edərək, o zaman həqiqətdən çox da uzaq deyilsiniz.
Nəticə
İzləmənin özünün faydalılığına şübhə etmirəm. Mən ürəkdən inanıram ki, məlumat toplamaq üçün izdə olan kimi zəngin, səbəbli və kontekstli başqa bir üsul yoxdur. Bununla belə, mən də inanıram ki, bütün izləmə həlləri bu məlumatlardan son dərəcə səmərəsiz istifadə edir. İzləmə alətləri izləmə təsvirində ilişib qaldıqca, onlar izlərdə olan məlumatlardan çıxarıla bilən qiymətli məlumatdan maksimum istifadə etmək imkanlarında məhdud olacaqlar. Bundan əlavə, istifadəçinin proqramdakı səhvləri aradan qaldırmaq imkanlarını ciddi şəkildə məhdudlaşdıracaq tamamilə qeyri-dost və qeyri-intuitiv vizual interfeysin daha da inkişaf etdirilməsi riski var.
Mürəkkəb sistemləri, hətta ən son alətlərlə sazlamaq olduqca çətindir. Alətlər tərtibatçıya hipotezi formalaşdırmağa və sınamağa kömək etməlidir, fəal şəkildə təmin edir müvafiq məlumatlar, kənar göstəricilərin müəyyən edilməsi və gecikmələrin paylanmasının xüsusiyyətlərini qeyd etmək. İstehsal uğursuzluqlarını aradan qaldırarkən və ya çoxsaylı xidmətləri əhatə edən problemləri həll edərkən izləmənin tərtibatçıların seçim alətinə çevrilməsi üçün həmin xidmətləri yaradan və işlədən tərtibatçıların zehni modelinə daha uyğun gələn orijinal istifadəçi interfeysləri və vizualizasiyalar lazımdır.
Təhlil və nəticə çıxarmaq asanlığı üçün optimallaşdırılmış şəkildə izləmə nəticələrində mövcud olan müxtəlif siqnalları təmsil edəcək bir sistemin dizaynı əhəmiyyətli zehni səy tələb edəcəkdir. Sazlama zamanı sistem topologiyasını necə mücərrəd etmək barədə düşünmək lazımdır ki, istifadəçi fərdi izlərə və ya aralıqlara baxmadan kor nöqtələri aradan qaldırmağa kömək etsin.
Bizə yaxşı abstraksiya və qatlama imkanları lazımdır (xüsusilə UI-də). İterativ olaraq suallar verə və fərziyyələri sınaqdan keçirə biləcəyiniz hipoteza əsaslanan sazlama prosesinə yaxşı uyğun gələnlər. Onlar bütün müşahidə problemlərini avtomatik həll etməyəcəklər, lakin istifadəçilərə intuisiyalarını kəskinləşdirməyə və daha ağıllı suallar yaratmağa kömək edəcəklər. Vizuallaşdırmaya daha düşünülmüş və innovativ yanaşmaya çağırıram. Burada üfüqləri genişləndirmək üçün real perspektiv var.
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «.
Mənbə: www.habr.com