Kvalitet procjene

Funkcija kvaliteta procjene je poboljšanje u odnosu na prethodnu preduvjetnu oštricu.

Funkcija procjene procjene na zahtjev

Nalazi procjene su dobri samo onoliko koliko su dobri podaci prikupljeni za potvrđivanje tih nalaza. Neuspješno otkriće i prikupljanje podataka degradira vrijednost rezultata procjene i može doprinijeti percepciji lošeg kvaliteta. Ponekad ovi problemi čak prođu nezapaženo bez mogućnosti da ih iznesu na površinu i pruže vam djelotvorne smjernice za njihovo rješavanje. Ovo veliko poboljšanje postojećih preduvjeta fokus područja blade na kontrolnoj tabli za procjenu Azure Log Analytics razvijeno je sa dva cilja na umu:

• Problemi sa kvalitetom procjene površine kako bi vam omogućili priliku za sanaciju i ponovno pokretanje procjene kako biste osigurali dobar kvalitet procjene.
• Smanjite potrebu za podizanjem ulaznica za podršku kako biste riješili probleme sa kvalitetom podnošenja podataka nudeći specifičan i djelotvoran sadržaj za popravak.

Konkretno, mogućnosti koje su dovedene na tržište koje poboljšavaju postojeću preduslovnu oštricu područja fokusa uključuju:

1. Kategorizacija potencijalnih stanja neuspjeha u početne faze izvršenja procjene koje uključuju otkrivanje i prikupljanje preduslova.

2. Indeks kvaliteta procjene za vizualnu stopu uspješnosti za prikupljanje podataka o procjeni.

3. Ažurirana grafika krofne za vizualno predstavljanje kategorija i indeksa kvaliteta procjene.

Šta predstavlja "Indeks kvaliteta procjene"?

AssessmentQualityIndex = Prošli preduslovni tokovi rada / Ukupni preduslovni tokovi rada

Kada se procjena pokrene, pokrećemo razne kolektore i zatim pokrećemo analizatore na rezultatima istih. Ako bilo koji Collector ne uspije (jer WMI remoting nije uspio protiv cilja), nećemo imati ništa za pokretanje analize. To će rezultirati nepotpunim rezultatom procjene koji smanjuje kvalitetu koju vam isporučujemo.

Preduslovi su prvobitno stvoreni da se popravi ova situacija. Prije pokretanja Collectora, pokrećemo Collectors u "preduvjetnom modu" da testiramo da li su ispunjeni specifični preduvjeti (provjeravamo WMI remoting je uključen na cilju). Ako bilo koji preduslov ne uspije, mi prikazujemo te greške na Azure portalu pod "Preduslovi" blade; Ali početna implementacija preduslova nije učinila sjajan posao pokazujući krajnjem korisniku ukupnu sliku kvaliteta procjene.

Razmotrite sljedeći scenarij. Vi pokrećete ADAssessment i 100 ciljeva je identificirano tijekom Discoveryja. Mi pokrećemo Collector u preduvjetnom modu da potvrdimo da je WMI Remoting uključen, ali ne uspijeva protiv svakog cilja jer niste uključili WMI Remoting u njihovom okruženju. Prije procjene kvaliteta, vidjet ćete jedan preduvjetni neuspjeh u Azure-u koji se odnosi na "WMI Remoting nije omogućen." Međutim, zapravo bi bilo 100 neuspjelih preduvjetnih radnih procesa i procjena bi teško imala nešto za analizu, što bi rezultiralo lošom procjenom. To nije nužno bilo očigledno jer ste mogli vidjeti samo jedan preduvjet neuspjeha u Azureu.

Sada, sa funkcijom Assessment Quality, pružamo Assessment Quality Index, koji je jednostavno postotak Passed Prerequisite Workflows/Total Prerequisite Workflows. Dakle, u prethodnom primjeru, vidjeli biste 0% ili 1% indeks kvalitete procjene, što jasno pokazuje da je ukupni kvalitet procjene bio izuzetno loš zbog preduvjetnih neuspjeha.

Bilješka

U stvarnom životu, ADAssessment vjerovatno pokreće širi spektar preduvjetnih radnih procesa, a ne samo WMI Remoting, tako da ćemo vjerovatnije vidjeti viši indeks kvaliteta procjene.

Koja je razlika između neuspjeha otkrića, važnih preduvjetnih neuspjeha i drugih preduvjetnih neuspjeha?

Procjena prolazi kroz različite faze kada se pokreće. Prvo, pokrećemo Discovery da pronađemo različite čvorove koji će biti procijenjeni. Zatim, pokrećemo razne kolektore u preduvjetnom modu. Konačno, pokrenut ćemo Kolekcionare kao i obično, a zatim pokrenuti Analizu.

Preduslovi se prvenstveno odnose na prve dvije faze: Discovery i Collectors pokrenuti u Prerequisite modu.

Izlazna datoteka preduvjeta će sada specificirati fazu u kojoj se dogodio svaki preduvjet neuspjeha i mi ćemo to prikazati u Azure-u.

Zašto se ključ Important Prerequisite Failures samo ponekad pojavljuje u Donut Chartu/Legendi?

Kada autori IP-a kreiraju svoje procjene, oni mogu opcionalno označiti tokove rada kao važne. To znači da je tok rada kritičan za kvalitet procjene. Ako procjena nema definirane važne tokove rada, NEĆEMO prikazati važne preduslovne neuspjehe u Donut Chartu/Legendi u Azure-u.

Zašto ponekad prikazujemo samo "Discovery Failures", ali ne i druge kategorije u Azure-u?

Ako MVE (Minimum Viable environment) test ne uspije tokom Discoveryja, to znači da određeni osnovni zahtjevi nisu ispunjeni (u SQLAssessmentu, ne mogu se naći SQL serveri). U tom slučaju, Kolektori se čak i ne pokreću u Prerequisite modu - mi se ranije spašavamo iz procjene. Kada se to dogodi, prikazujemo samo Discovery Failures u Azure-u.

Zašto vidim praznu oštricu kvalitete procjene?

Nisu sve mašine za prikupljanje podataka/planirani zadaci koji šalju podatke u ovaj radni prostor Log Analytics-a ponovo pokrenuli procjenu sa novim bitovima kvaliteta procjene. Riješit će se automatski jednom:

1. sve mašine za prikupljanje podataka i planirani zadaci na tim mašinama su ponovo pokrenuli procjenu koristeći nove bitove, ILI
2. period zadržavanja podataka (default od 30 dana) uzrokuje propadanje starih podataka, ostavljajući samo "dobre" podatke koji su generirani nakon što je objavljena funkcija kvaliteta procjene.

Funkcija Assessment Quality zahtijevala je od nas da dodamo novu CustomData kolonu u izlazne datoteke procjene, a novi UX analizira ovu novu CustomData kolonu kako bi generirao statiku prikazanu u novom Assessment Quality bladeu.

To je učinilo kompatibilnost unatrag nezgodnom. Novi UX radi samo ako ste pokrenuli procjenu koristeći nove promjene ODA klijenta koje će popuniti kolonu CustomData. Dakle, imamo neki kod u našem UX-u koji će identificirati da li radni prostor Log Analytics-a ima bilo kakve zapise sa popunjenim CustomData-om, što znači da je procjena pokrenuta sa novim bitovima. Ako ne, vraćamo se na staru oštricu preduvjeta. Ako CustomData NE postoji, onda prikazujemo novi Assessment Quality blade.

Ali moguće je da više mašina za prikupljanje podataka (ili čak više zakazanih zadataka na ISTOJ mašini za prikupljanje podataka) šalje podatke u jedan radni prostor Log Analytics-a, a ovaj nož je agregacija preduslovnih rezultata za sve mašine za prikupljanje podataka povezane sa radnim prostorom. Dakle, šta se dešava ako su neke mašine poslale podatke sa novom kolonom CustomData, ali neke nisu? Da li prikazujemo stari ili novi UX?

Tada ćete vidjeti praznu oštricu na snimku zaslona. Ovdje nije bilo sjajnog rješenja, tako da ćete vidjeti ovo pokvareno međustanje sve dok sve mašine za prikupljanje podataka ne pošalju podatke koristeći nove bitove.

Postoje neki nesretni rubni slučajevi ovdje koji bi mogli rezultirati bolnim iskustvom za kupce:

1. Znamo da je za neke procjene uobičajeno imati više zakazanih zadataka postavljenih na istoj mašini za prikupljanje podataka (Windows Client Assessment, na primjer), a ti planirani zadaci su postavljeni da se pokreću u različitim danima. Recimo da imate dva zadatka, jedan u ponedjeljak i jedan u srijedu. Kada se zadatak pokrene u ponedjeljak, vidjet ćete prazno oštricu sve dok se drugi zadatak ne pokrene u srijedu, kada bi kupac trebao početi vidjeti novu oštricu kvalitete procjene.

2. Šta ako 3 mašine za prikupljanje podataka imaju SQL Assessment pokrenut i upućuju na isti Log Analytics radni prostor, ali jedna od tih mašina je povučena iz upotrebe prije 2 sedmice? Druge dvije mašine bi pokrenule procjenu s našim novim bitovima, ali budući da je treća mašina povučena iz upotrebe, ne može pokrenuti procjenu s našim novim bitovima. U ovom scenariju, kupac bi vidio praznu oštricu.

3. Vidjeli smo ovaj problem u nekim od naših testnih radnih prostora koji imaju PUNO ljudi koji pokreću procjene i šalju podatke u isti radni prostor Log Analyticsa. U ovom slučaju, vrlo je teško (vjerojatno nemoguće) pronaći sve i natjerati ih da ponovno pokrenu procjenu koristeći nove bitove.

Međutim, problem će se automatski riješiti kada se dogodi jedna od dvije sljedeće stvari:

1. Sve mašine za prikupljanje podataka i planirani zadaci na tim mašinama su ponovo pokrenuli procjenu koristeći nove bitove, ILI

2. Period zadržavanja podataka (default od 30 dana) uzrokuje propadanje starih podataka, ostavljajući samo "dobre" podatke koji su generirani nakon što je objavljena funkcija kvaliteta procjene.

Iz tog razloga, odlučili smo da je ovo prihvatljiva količina turbulencije koju treba izdržati.

U najgorem slučaju, korisnici uvijek mogu kreirati novi radni prostor Log Analytics-a, ili koristiti Data Purger API, a zatim ponovo pokrenuti procjenu koja će rezultirati čistim Assessment Quality bladeom.