Качество на оценката

Функцията за оценяване на качеството е подобрение в сравнение с предишното ножче Prerequisite.

Функция за оценка на качеството при поискване

Резултатите от оценката са толкова добри, колкото данните, събрани за потвърждаване на тези констатации. Неуспешното откриване и събиране на данни намалява стойността на резултатите от оценката и може да допринесе за усещане за лошо качество. Понякога тези проблеми дори остават незабелязани, без възможност да ги извадим на повърхността и да ви предоставим приложими насоки за справянето им. Това голямо подобрение на съществуващото поле за фокус на предварителни изисквания в таблото за оценяване на Azure Log Analytics е разработено с две цели:

• Проблеми с качеството на оценката на повърхността, за да ви даде възможност да коригирате и повторите оценката, за да осигурите добро качество на оценката.
• Минимизирайте необходимостта да повдигате билети за поддръжка за справяне с проблеми с качеството на подаване на данни, като предлагате конкретно и приложимо съдържание за отстраняване.

По-конкретно, възможностите, пуснати на пазара, които подобряват съществуващата предпоставка за фокусна зона, включват:

1. Категоризиране на потенциалните състояния на повреда във фазите на изпълнение на първоначалната оценка, които включват откриване и събиране на предварителни изисквания.

2. Индекс за качество на оценката за визуално процент на успеваемост за събиране на данни за оценка.

3. Актуализирана графика на понички за визуално представяне на категориите и индекса за качество на оценяването.

Какво представлява "Индекс на качеството на оценяването"?

AssessmentQualityIndex = Преминати предварителни работни потоци / Общо предварителни работни потоци

Когато оценката се изпълни, ние стартираме различни колектори и след това стартираме анализатори на резултатите от тях. Ако някой от колекционерите се провали (защото WMI referring се провали срещу целта), няма да имаме за какво да изпълняваме анализа. Това ще доведе до непълен резултат от оценката, което намалява качеството, което ви предоставяме.

Първоначално бяха създадени предпоставки за коригиране на тази ситуация. Преди да стартираме колекторите, ние стартираме колекторите в "режим на предварителна подготовка", за да проверим дали са изпълнени конкретни предварителни условия (проверяваме, че WMI referring е включено на целта). Ако някоя от предпоставките е неуспешна, ние ги показваме в портала на Azure под оловото "Предпоставки"; Но първоначалното прилагане на предпоставките не свърши добра работа, за да покаже на крайния потребител цялостна картина на качеството на оценката.

Помислете за следната примерна ситуация. Изпълнявате ADAssessment и по време на откриването се идентифицират 100 цели. Пускаме колекционер в режим на предварителна необходимост, за да потвърдим, че WMI Remoting е включен, но той се проваля срещу всяка цел, защото не сте включили WMI Remoting в тяхната среда. Преди качеството на оценяването ще видите една предпоставка за грешка в Azure, свързана с "WMI Remote не е разрешено". Въпреки това, всъщност ще има 100 неуспешни работни процеса и оценката едва ли ще има какво да анализира, което ще доведе до лоша оценка. Това не беше непременно очевидно, защото можеше да се види само една предпоставка за грешка в Azure.

Сега, с функцията за качество на оценяването, ние предоставяме индекс за качество на оценяването, който е просто процентът на преминати работни потоци с предварителни изисквания/общ брой работни потоци с предварителни изисквания. В предишния пример ще видите 0% или 1% индекс на качеството на оценяването, което ясно показва, че цялостното качество на оценката е изключително лошо поради предварителни грешки.

Бележка

В реалния живот ADAssessment вероятно изпълнява по-голямо разнообразие от предварителни работни процеси, а не само WMI Remoting, така че е по-вероятно да видим по-висок индекс за качество на оценяването.

Каква е разликата между неуспех при откриване, важни предварителни грешки и други предварителни грешки?

Оценката преминава през различни фази, когато се изпълнява. Първо стартираме Discovery, за да намерим различните възли, които ще бъдат оценени. След това стартираме различни колектори в режим на предварителна необходимост. Накрая ще стартираме Collectors както обикновено, след което ще стартираме Analysis.

Предпоставките се отнасят предимно до първите две фази: откриване и колекционери се изпълняват в режим на предварителна подготовка.

Изходният файл с предварителни изисквания вече ще посочи фазата, в която е възникнала всяка предпоставка за грешка, и ще я извадим на показ в Azure.

Защо ключът Важни предварителни грешки се показва само понякога в диаграмата/легендата на поничките?

Когато IP авторите създават своите оценки, те могат по желание да маркират работните потоци като важни. Това означава, че работният процес е от решаващо значение за качеството на оценката. Ако оценяването няма дефинирани важни работни потоци, НЯМА да покажем важните предварителни грешки в диаграмата/легендата на поничките в Azure.

Защо понякога показваме само "Грешки при откриване", но не и другите категории в Azure?

Ако тестът MVE (Minimum Viable environment) се провали по време на Discovery, това означава, че някои основни пререквизити не са изпълнени (в SQLAssessment не могат да бъдат намерени SQL сървъри). В този случай колекционерите дори не се изпълняват в режим на предварителни условия - ние се спасяваме по-рано от оценката. Когато това се случи, показваме само неуспешни откривания в Azure.

Защо виждам празно острие за качество на оценката?

Не всички машини за събиране на данни/планирани задачи, които изпращат данни в това работно пространство на Log Analytics, са изпълнили отново оценяването с новите битове за качество на оценяването. Ще се разреши автоматично веднъж:

1. всички машини за събиране на данни и планирани задачи на тези машини са изпълнили отново оценката с помощта на нови битове, ИЛИ
2. периодът на съхранение на данните (по подразбиране 30 дни) води до затихване на старите данни, оставяйки само "добри" данни, които са генерирани след пускането на функцията за качество на оценяването.

Функцията за качество на оценяването изискваше от нас да добавим нова колона CustomData към изходните файлове за оценяване, а новият UX анализира тази нова колона CustomData, за да генерира статиките, показани в новото поле за качество на оценяването.

Това прави обратната съвместимост трудна. Новият UX работи само ако сте изпълнили оценяването с помощта на новите промени в ODA Client, които ще попълнят колоната CustomData. Така че имаме някакъв код в нашия UX, който ще идентифицира дали работното пространство на Log Analytics има някакви записи с попълнени CustomData, което означава, че оценката е извършена с новите битове. Ако не, се връщаме към острието на старите предпоставки. Ако CustomData СЪЩЕСТВУВА, тогава показваме новото гнездо за качество на оценяването.

Възможно е обаче няколко машини за събиране на данни (или дори няколко планирани задачи на ЕДНА и СЪЩА машина за събиране на данни) да изпращат данни в едно работно пространство на Log Analytics и това поле е обобщение на предварителни резултати за всички машини за събиране на данни, свързани към работното пространство. И така, какво се случва, ако някои машини са изпратили данни с новата колона CustomData, но други не? Показваме ли стария UX или новия UX?

Тогава ще видите празното острие на екранната снимка. Тук нямаше страхотно решение, така че ще видите това счупено междинно състояние, докато всички машини за събиране на данни не изпратят данни, използвайки новите битове.

Тук има някои нещастни крайни случаи, които могат да доведат до болезнено преживяване за клиентите:

1. Знаем, че за някои оценявания е обичайно да има няколко планирани задачи, настроени на една и съща машина за събиране на данни (Windows Client Assessment, например) и тези планирани задачи се настройват да се изпълняват в различни дни. Да приемем, че имате две задачи, една в понеделник и една в сряда. След като задачата се изпълни в понеделник, ще виждате празното ножче, докато втората задача не се изпълни в сряда, след което клиентът трябва да започне да вижда новото острие за качество на оценката.

2. Какво ще стане, ако 3 машини за събиране на данни имат SQL Assessment, работещо и сочещо към едно и също работно пространство на Log Analytics, но една от тези машини е била изведена от експлоатация преди 2 седмици? Другите две машини ще извършат оценката с нашите нови битове, но тъй като третата машина беше изведена от експлоатация, тя не може да извърши оценката с нашите нови битове. В този сценарий клиентът ще види празното острие.

3. Видяхме този проблем в някои от нашите тестови работни пространства, в които МНОГО хора изпълняват оценявания и изпращат данни в едно и също работно пространство на Log Analytics. В този случай е много трудно (вероятно невъзможно) да проследите всички и да ги накарате да повторят оценката, използвайки новите битове.

Проблемът обаче автоматично ще се разреши сам, след като се случи едно от следните две неща:

1. Всички машини за събиране на данни и планирани задачи на тези машини са изпълнили отново оценката с помощта на нови битове, ИЛИ

2. Периодът на съхранение на данните (по подразбиране 30 дни) води до затихване на старите данни, оставяйки само "добри" данни, генерирани след пускането на функцията за качество на оценяването.

Поради тази причина решихме, че това е приемливо количество турбуленция.

В най-лошия случай клиентите винаги могат да създадат ново работно пространство на Log Analytics или да използват API за пречистване на данни, след което да изпълнят отново оценяването, което ще доведе до чисто острие за качество на оценяването.