Poznámka

Výhody hodnotenia stavu IT a hodnotenia na požiadanie si môžete vychutnať so zmluvou Premier, a to zakúpením aplikácie TOM Ako predplatného služby. Ďalšie informácie vám poskytne zástupca spoločnosti Microsoft.

Kvalita hodnotenia

Funkcia Kvalita hodnotenia je vylepšenie predchádzajúcej verzie predpokladu.

Funkcia hodnotenie na požiadanie – kvalita

Výsledky hodnotenia sú také dobré len ako údaje zhromaždené na vynecháenie týchto výsledkov. Neúspešné zisťovanie a zhromažďovanie údajov znižuje hodnotu výsledkov hodnotenia a môže prispieť k vynúteniu s nedostatočnou kvalitou. Niekedy sa tieto problémy aj nepozorujú a nie sú vhodné na ich povrch a poskytnú vám pokyny na ich riešenie. Táto významná vylepšenia pre existujúcu oblasť zamerania nevyhnutných predpokladov na tabuli hodnotenia analýzy denníkov Azure bola vyvinutá s dvomi cieľmi:

  • Problémy s kvalitou hodnotenia zariadení Surface, ktoré vám umožnia vykonať príležitosť na opravenie a opätovné spustenie hodnotenia s cieľom zabezpečiť dobrú kvalitu hodnotenia.
  • Minimalizujte potrebu zvýšite žiadosti o podporu a vyriešte problémy s kvalitou odosielania údajov prostredníctvom ponuky špecifického a actionable remediation obsahu.

Presnejšie, možnosti prinášané na trh, ktoré vylepšia existujúcu nevyhnutnú oblasť zamerania, napríklad:

  1. Kategorizácia potenciálnych štátov o zlyhaní do fáz spustenia úvodného hodnotenia, ktoré zahŕňajú zisťovanie a kolekciu nevyhnutných predpokladov.
  2. Index kvality hodnotenia na vizuálne hodnotenie miery úspešnosti pri zhromažďovaní údajov v rámci hodnotenia.
  3. Aktualizovaná prstencová grafika, ktorá vizuálne vystupuje kategórie a index kvality hodnotenia.

Čo predstavuje index kvality hodnotenia?

AssessmentQualityIndex = Passed Prerequisite Workflows / Total Prerequisite Workflows

Po spustení hodnotenia spustíme rôzne kolekcie a potom na ich výsledkoch spustíme analyzátory. Ak sa u vás nepodarí vytvoriť alebo vynecháte nejaký problém (t. j. pretože remotovanie WMI zlyhalo vzhľadom na cieľ), na analýzu nebudeme mať čo spustiť. Výsledkom bude neúplný výsledok hodnotenia, ktorý zníži kvalitu, ktorú vám poskytujeme.

Predpoklady boli pôvodne vytvorené na odstránenie tejto situácie. Pred spustením nádychov spustíme v "režime nevyhnutných požiadaviek" príkaz s cieľom otestovať, či boli splnené konkrétne predpoklady (t. j. overme, či je v cieľovom počítači povolené odtešovanie WMI). Ak niektorá nevyhnutná podmienka zlyhá, na portáli Azure sa tieto zlyhania premietli pod blade "Predpoklady". počiatočná implementácia nevyhnutných predpokladov však nezamýšla v tom, že koncovým používateľom sa už nezobrazuje celkový obraz kvality hodnotenia.

Pozrite si nasledujúci scenár. Spúšťate adAmisment a počas zisťovania sa identifikuje 100 cieľov. V režime nevyhnutných predpokladov spúšťame pre overenie, či je funkcia WMI Remoting povolená, no nie je v súlade s každým cieľom, pretože ste vo svojom prostredí nepoumožnili remoting WMI. Pred hodnotou kvality hodnotenia by sa v službe Azure mohla zobraziť jedna nevyhnutná chyba, ktorá sa týka nedo povoleného remotingu WMI. Malo by však 100 nevyhnutných pracovných postupov a hodnotenie by takmer malo čosi, čo by malo za následok veľmi slabé hodnotenie. Nie je to nevyhnutne zrejmé, pretože v službe Azure sa vám jednoducho môže zobraziť jedno nevyhnutné zlyhanie.

Teraz s funkciou Kvalita hodnotenia poskytujeme index kvality hodnotenia, ktorý je jednoducho percentuálnym podielom pracovných postupov s predložených nevyhnutnými predpokladmi/celkový počet nevyhnutných pracovných postupov. Vo vyššie uvedenom príklade sa preto zobrazí index kvality hodnotenia 0 % alebo 1 %, vďaka tomu bude zrejmé, že celková kvalita hodnotenia bola veľmi nízka z dôvodu nevyhnutných zlyhaní.

Poznámka

V reálnom živote pravdepodobne spúšťa ADAmisment širšiu škálu nevyhnutných pracovných postupov, nielen remoting WMI, preto by sme mali pravdepodobne lepší index kvality hodnotenia.

Aký je rozdiel medzi zlyhaním zisťovania, dôležitými zlyhaniemi nevyhnutných predpokladov a ďalšími nevyhnutnými zlyhaniami?

Hodnotenie prebieha v rôznych fázach. Najprv spustíme zisťovanie, aby sme našli rôzne uzly, ktoré budú vyhodnotené. Potom v režime nevyhnutných predpokladov spúšťame rôzne kolekcie. Nakoniec spustíme Kolekcie normálne a potom spustíme analýzu.

Predpoklady sa predovšetkým týkajú prvých dvoch fáz: Zisťovanie a Imeály sa spúšťajú v režime nevyhnutných predpokladov.

Výstupný súbor nevyhnutnými predpokladmi teraz špecifikuje etapu, v ktorej sa vyskytla každá nevyhnutná chyba, a my túto podmienku uvedieme v službe Azure.

Prečo sa kľúč Dôležité zlyhanie nevyhnutných predpokladov niekedy zobrazí len v prstencového grafu alebo legende?

Keď autori IP adries vytvárajú svoje hodnotenia, môžu voliteľne označiť pracovné postupy ako dôležité. Znamená to, že pracovný postup je pre kvalitu hodnotenia dôležitý. Ak v danom hodnotení nie sú definované žiadne dôležité pracovné postupy, v platforme Azure sa nebudú zobrazovať dôležité zlyhanie súčasti v prstencového grafu alebo legende.

Prečo sa niekedy zobrazujú iba chyby zisťovania, ale nie iné kategórie v službe Azure?

Ak je test MVE (minimálne Viable environment) počas zisťovania neúspešný, signaluje, že neboli splnené niektoré základné hodnoty prereqiusite (t. j. v súboroch SQLA pre SERVER SQL sa nenašiel žiadny problém). V takom prípade sa v režime nevyhnutných predpokladov dokonca spustia a od jeho spustenie pracujeme skôr. V takom prípade sa v službe Azure zobrazujú len zlyhania zisťovania.

Prečo sa mi zobrazí prázdny hárok kvality hodnotenia?

Nie všetky zariadenia na zhromažďovanie údajov alebo naplánované úlohy s odoslaním údajov do tohto pracovného priestoru Analýzy denníka znova spustite hodnotenie pomocou nových bitov kvality hodnotenia. Vyrieši sa automaticky raz 1) všetky zariadenia na zhromažďovanie údajov a naplánované úlohy v týchto počítačoch znova spustí hodnotenie pomocou nových bitov ALEBO 2) obdobie uchovávania údajov (predvolené 30 dní) spôsobuje, že staré údaje sú zastarané a ponechajú len dobré údaje vytvorené po vydaní funkcie Kvalita hodnotenia.

Funkcia kvalita hodnotenia vyžaduje, aby sme do výstupných súborov hodnotenia pridajú nový stĺpec CustomData a nový stĺpec UX analyzuje tento nový stĺpec CustomData a vygeneruje statické hodnoty zobrazené v novom dáte kvality hodnotenia.

Na základe toho bola spätná kompatibilita komplikovaná. Nová UX verzia funguje len v prípade, že hodnotenie spustíte pomocou nových zmien klienta ODA, ktoré budú vyplniť stĺpec CustomData. Preto máme v UX kód, ktorý identifikuje, či má pracovný priestor Analýza denníka nejaké záznamy s vyplnenými údajmi CustomData, čo znamená, že hodnotenie bolo spustený s novými bitmi. Ak nie, pri návrate k starej nevyhnutnej čete sa vrátime. Ak customData EXISTUJE, zobrazí sa nový server kontroly kvality hodnotenia.

Zariadenia na zhromažďovanie údajov (alebo dokonca viacero naplánovaných úloh v tom istom zariadení na zhromažďovanie údajov) je však možné odosielať do jedného pracovného priestoru analýzy denníka a tento server blade je agregáciou nevyhnutných výsledkov pre všetky zariadenia na zhromažďovanie údajov pripojené k pracovnému priestoru. Čo sa teda stane, ak niektoré počítače odoslali údaje pomocou nového stĺpca CustomData, ale niektoré nie? Zobrazujeme staré UX alebo novéux?

Vtedy sa na snímke obrazovky vyššie zobrazí prázdny hárok. Nebolo tu žiadne skvelé riešenie, takže tento nefunkčný prechodný stav sa zobrazí dovtedy, kým všetky zariadenia na zhromažďovanie údajov neodovzná údaje pomocou nových bitov.

Existujú však aj prípady, keď sú okraje spoločnosti Edge a pre zákazníkov by sa mohli u nich vyskytnúť až príliš ťažké výsledky:

  1. Vieme, že pri niektorých hodnoteniach je pomerne bežné mať v tom istom zariadení na zhromažďovanie údajov nastavených viacero naplánovaných úloh (napríklad hodnotenie klienta Windows) a tieto naplánované úlohy sú nastavené na rôzne dni. Povedzme, že máte dve úlohy, jednu v pondelok a jednu v stredu. Keď sa úloha spustí v pondelok, nad tým sa bude nachádzať prázdny server blade, až kým sa druhá úloha neudá v stredu, na ktorej by mal zákazník začať vidieť nový server kontroly kvality hodnotenia.

  2. Čo ak sú všetky zariadenia na zhromažďovanie údajov v SQL spustené a ukazovali do toho istého pracovného priestoru Analýzy denníka, ale jeden z týchto počítačov bol pred 2 týždňami vyradený z prevádzky? Ostatné dva počítače prebehli hodnotenie s našimi novými bitmi, keďže však tretí počítač bol vyradený z činnosti, na základe našich nových bitov nemôže spustiť hodnotenie. V tomto scenári by sa zákazníkovi nad tým mohol zobraziť prázdny hárok.

  3. Tento problém sme zaznamenali v niektorých našich testovacích pracovných priestoroch, v ktorých je veľa ľudí, ktorí spúšťajú hodnotenia, a odosielali údaje do toho istého pracovného priestoru Analýzy denníka. V tomto prípade je veľmi ťažké (pravdepodobne úplne nemožné) vystopovať všetkých a dať im do toho znova spustiť hodnotenie pomocou nových bitov.

Problém sa však automaticky vyrieši, keď sa stane jedna z týchto dvoch stať

  1. Všetky zariadenia na zhromažďovanie údajov a naplánované úlohy v týchto počítačoch znova spustite hodnotenie pomocou nových bitov ALEBO
  2. Obdobie uchovávania údajov (predvolené 30 dní) spôsobuje, že staré údaje sú zastarané a ponechajú len dobré údaje vytvorené po vydaní funkcie kvalita hodnotenia.

Z tohto dôvodu sme sa rozhodli, že ide o prijateľnú hodnotu blesku.

Scenár najhoršieho prípadu, zákazník môže vždy vytvoriť nový pracovný priestor analýzy denníka alebo použiť rozhranie DATA Purger API a potom znova spustiť hodnotenie, ktoré bude mať za následok server clean Assessment Quality blade.

Ak chcete získať všeobecné pripomienky k Strediska zdrojov alebo k obsahu, pošlite svoje pripomienky zástupcovi spoločnosti Microsoft. Konkrétne požiadavky a aktualizácie obsahu týkajúce sa centra služieb vám poskytne náš tím podpory a odošliteprípad.