Kalidad ng Pagtatasa

Ang tampok na Kalidad ng Pagtatasa ay isang pagpapabuti sa nakaraang talim ng Kinakailangan.

Tampok na Kalidad ng Pagtatasa ng On-Demand na Pagtatasa

Ang mga natuklasan sa pagtatasa ay kasing ganda lamang ng data na nakolekta upang igiit ang mga natuklasan na iyon. Ang hindi matagumpay na pagtuklas at pagkolekta ng data ay nagpapababa ng halaga ng mga resulta ng pagtatasa at maaaring mag-ambag sa mga pananaw na hindi maganda ang kalidad. Minsan ang mga problemang ito ay hindi napapansin nang walang kakayahang ilabas ang mga ito at magbigay sa iyo ng naaaksyunan na patnubay upang matugunan ang mga ito. Ang pangunahing pagpapahusay na ito sa umiiral na mga kinakailangan na address ng lugar ng pokus sa dashboard ng pagtatasa ng Azure Log Analytics ay binuo na may dalawang layunin sa isip:

• Mga isyu sa kalidad ng pagtatasa sa ibabaw upang bigyan ka ng pagkakataon na ayusin at muling patakbuhin ang pagtatasa upang matiyak ang mahusay na kalidad ng pagtatasa.
• I-minimize ang pangangailangan para sa iyo na itaas ang mga tiket ng suporta upang matugunan ang mga isyu sa kalidad ng pagsusumite ng data sa pamamagitan ng pag-aalok ng tiyak at naaaksyunan na nilalaman ng pagwawasto.

Partikular, ang mga kakayahan na dinala sa merkado na nagpapahusay sa umiiral na kinakailangang focus area blade ay kinabibilangan ng:

1. Pag-uuri ng mga potensyal na estado ng pagkabigo sa mga paunang yugto ng pagpapatupad ng pagtatasa na kinabibilangan ng pagtuklas at koleksyon ng kinakailangan.

2. Index ng kalidad ng pagtatasa sa biswal na isang % rate ng tagumpay para sa pagkolekta ng data ng pagtatasa.

3. Isang na-update na donut graphic upang biswal na kumatawan sa mga kategorya at index ng kalidad ng pagtatasa.

Ano ang kinakatawan ng "Assessment Quality Index"?

AssessmentQualityIndex = Ipinasa ang Mga Kinakailangang Daloy ng Trabaho / Kabuuang Mga Kinakailangang Daloy ng Trabaho

Kapag tumatakbo ang pagtatasa, nagpapatakbo kami ng iba't ibang mga Collector at pagkatapos ay nagpapatakbo ng mga Analyzer sa mga resulta ng mga iyon. Kung may mga Collector na nabigo (dahil nabigo ang WMI remoting laban sa isang target), wala kaming anumang bagay na patakbuhin ang Analysis. Ito ay magreresulta sa isang hindi kumpletong resulta ng pagsusuri na binabawasan ang kalidad na ibinibigay namin sa iyo.

Noong una ay nilikha ang mga kinakailangan upang malutas ang sitwasyong ito. Bago patakbuhin ang Collectors, pinapatakbo namin ang Collectors sa "prerequisite mode" upang subukan kung natugunan ang mga partikular na kinakailangan (tinitiyak namin na naka-on ang WMI remoting sa target). Kung nabigo ang anumang mga kinakailangan, ipapakita namin ang mga pagkabigo na iyon sa Azure portal sa ilalim ng blade na "Mga Kinakailangan"; Ngunit ang paunang pagpapatupad ng mga kinakailangan ay hindi gumawa ng isang mahusay na trabaho ng pagpapakita sa end user ng isang pangkalahatang larawan ng kalidad ng pagtatasa.

Isaalang-alang ang sumusunod na sitwasyon. Nagpapatakbo ka ng ADAssessment at 100 target ang natukoy sa panahon ng Discovery. Nagpapatakbo kami ng Collector sa prerequisite mode para kumpirmahin na naka-on ang WMI Remoting, ngunit nabigo ito laban sa bawat target dahil hindi mo pa na-on ang WMI Remoting sa kanilang kapaligiran. Bago ang Kalidad ng Pagtatasa, makikita mo ang isang solong kinakailangang pagkabigo sa Azure na may kaugnayan sa "WMI Remoting hindi pinagana." Gayunpaman, magkakaroon ng 100 nabigong mga daloy ng trabaho at ang pagtatasa ay halos walang dapat pag-aralan, na nagreresulta sa isang mahinang pagtatasa. Hindi ito kinakailangang halata dahil makikita mo lamang ang isang solong kinakailangang pagkabigo sa Azure.

Ngayon, gamit ang tampok na Kalidad ng Pagtatasa, nagbibigay kami ng Assessment Quality Index, na kung saan ay ang porsyento lamang ng Passed Prerequisite Workflows/Total Prerequisite Workflows. Kaya sa nakaraang halimbawa, makikita mo ang isang 0% o 1% Assessment Quality Index, na ginagawang malinaw na ang pangkalahatang kalidad ng pagtatasa ay lubhang mahina dahil sa mga pagkabigo sa kinakailangan.

Note

Sa totoong buhay, ang ADAssessment ay malamang na nagpapatakbo ng mas malawak na iba't ibang mga kinakailangang daloy ng trabaho, hindi lamang WMI Remoting, kaya mas malamang na makakita tayo ng mas mataas na Assessment Quality Index.

Ano ang pagkakaiba sa pagitan ng Pagkabigo sa Pagtuklas, Mahahalagang Pagkabigo sa Kinakailangan, at Iba pang Mga Pagkabigo sa Kinakailangan?

Ang pagsusuri ay dumadaan sa iba't ibang yugto kapag tumatakbo ito. Una, patakbuhin namin ang Discovery upang mahanap ang iba't ibang mga node na susuriin. Susunod, nagpapatakbo kami ng iba't ibang mga Collector sa Prerequisite Mode. Sa wakas, patakbuhin namin ang Mga Kolektor tulad ng dati, pagkatapos ay patakbuhin ang Pagsusuri.

Ang mga kinakailangan ay pangunahing nababahala sa unang dalawang yugto: Pagtuklas at Mga Kolektor na tumatakbo sa Prerequisite Mode.

Ang kinakailangang output file ay tumutukoy na ngayon sa yugto kung saan naganap ang bawat kinakailangang pagkabigo at ipapakita namin iyon sa Azure.

Bakit paminsan-minsan lamang lumilitaw ang susi ng Mahahalagang Pagkabigo sa Kinakailangan sa Donut Chart/Legend?

Kapag lumikha ang mga may-akda ng IP ng kanilang Mga Pagtatasa, maaari nilang opsyonal na markahan ang Mga Daloy ng Trabaho bilang Mahalaga. Nangangahulugan ito na ang daloy ng trabaho ay kritikal sa kalidad ng pagsusuri. Kung ang Pagtatasa ay walang Mahahalagang Daloy ng Trabaho na tinukoy, HINDI namin ipapakita ang Mahahalagang Pagkabigo sa Kinakailangan sa Donut Chart / Legend sa Azure.

Bakit kung minsan ay ipinapakita lamang natin ang "Mga Pagkabigo sa Pagtuklas", ngunit hindi ang iba pang mga kategorya sa Azure?

Kung ang pagsubok ng MVE (Minimum Viable environment) ay nabigo sa panahon ng Discovery, nangangahulugan ito na ang ilang mga pangunahing prereqiusites ay hindi natutugunan (sa SQLAssessment, walang mga SQL server ang maaaring matagpuan). Sa kasong iyon, ang mga Collector ay hindi man lang tumatakbo sa Prerequisite Mode - maaga kaming nag-bail out mula sa assessment run. Kapag nangyari ito, ipinapakita lamang namin ang Mga Pagkabigo sa Pagtuklas sa Azure.

Bakit nakikita ko ang blangko na talim ng Kalidad ng Pagtatasa?

Hindi lahat ng mga makina ng pagkolekta ng data/naka-iskedyul na mga gawain na nagsusumite ng data sa workspace ng Log Analytics na ito ay muling pinatakbo ang Pagtatasa gamit ang mga bagong bit ng Kalidad ng Pagtatasa. Awtomatikong malulutas ang sarili nito nang isang beses:

1. lahat ng mga makina ng pagkolekta ng data at naka-iskedyul na mga gawain sa mga makina na iyon ay muling patakbuhin ang pagtatasa gamit ang mga bagong bit, O
2. ang panahon ng pagpapanatili ng data (default ng 30 araw) ay nagiging sanhi ng pagkabulok ng lumang data, na nag-iiwan lamang ng "mabuti" na data na nabuo pagkatapos ng tampok na Kalidad ng Pagtatasa ay inilabas.

Ang tampok na Kalidad ng Pagtatasa ay nangangailangan sa amin na magdagdag ng isang bagong haligi ng CustomData sa mga file ng output ng pagtatasa, at ang bagong UX ay nag-parse ng bagong haligi ng CustomData upang makabuo ng mga statics na ipinapakita sa bagong blade ng Kalidad ng Pagtatasa.

Dahil dito ay naging mahirap ang backward compatibility. Gumagana lamang ang bagong UX kung pinatakbo mo ang pagtatasa gamit ang bagong mga pagbabago sa ODA Client na pupunan ang haligi ng CustomData. Kaya mayroon kaming ilang code sa aming UX na makikilala kung ang workspace ng Log Analytics ay may anumang mga talaan na may CustomData na napuntahan, na nagpapahiwatig na ang pagtatasa ay pinatakbo gamit ang mga bagong bit. Kung hindi, bumalik tayo sa lumang talim ng mga kinakailangan. Kung umiiral ang CustomData, ipinapakita namin ang bagong blade ng Kalidad ng Pagtatasa.

Ngunit posible para sa maramihang mga makina ng pagkolekta ng data (o kahit na maramihang naka-iskedyul na mga gawain sa PAREHONG makina ng pagkolekta ng data) na magsumite ng data sa isang solong workspace ng Log Analytics, at ang blade na ito ay isang pagsasama-sama ng mga kinakailangang resulta para sa lahat ng mga makina ng pagkolekta ng data na konektado sa workspace. Kaya ano ang mangyayari kung ang ilang mga makina ay nagsumite ng data gamit ang bagong haligi ng CustomData, ngunit ang ilan ay hindi? Ipinapakita ba natin ang lumang UX o ang bagong UX?

Dito mo makikita ang blangko na talim sa screenshot. Walang magandang solusyon dito, kaya makikita mo ang sirang intermediate state na ito hanggang sa magsumite ng data ang lahat ng data collection machine gamit ang mga bagong bit.

Mayroong ilang mga kapus-palad na mga kaso sa gilid dito na maaaring magresulta sa isang masakit na karanasan para sa mga customer:

1. Alam namin na para sa ilang mga pagtatasa karaniwan na magkaroon ng maraming naka-iskedyul na pag-setup ng mga gawain sa parehong makina ng pagkolekta ng data (Windows Client Assessment, halimbawa), at ang mga naka-iskedyul na gawain ay naka-setup upang tumakbo sa iba't ibang araw. Sabihin nating mayroon kang dalawang gawain, isa sa Lunes at isa sa Miyerkules. Kapag tumatakbo ang gawain sa Lunes, makikita mo ang blangko na talim hanggang sa tumatakbo ang pangalawang gawain sa Miyerkules, kung saan dapat magsimulang makita ng customer ang bagong talim ng Kalidad ng Pagtatasa.

2. Paano kung ang 3 mga makina ng pagkolekta ng data ay may SQL Assessment na tumatakbo at tumuturo sa parehong workspace ng Log Analytics, ngunit ang isa sa mga machine na iyon ay na-decommissioned 2 linggo na ang nakalilipas? Ang iba pang dalawang makina ay magpapatakbo ng pagtatasa gamit ang aming mga bagong bit, ngunit dahil ang pangatlong makina ay na-decommission, hindi nito maaaring patakbuhin ang pagtatasa gamit ang aming mga bagong bit. Sa sitwasyong ito, makikita ng customer ang blangko na talim.

3. Nakita namin ang problemang ito sa ilan sa aming mga workspace ng pagsubok na may MARAMING tao na nagpapatakbo ng mga pagtatasa at nagsusumite ng data sa parehong workspace ng Log Analytics. Sa kasong ito, napakahirap (marahil imposible) na subaybayan ang lahat at ipaalam sa kanila na muling patakbuhin ang pagtatasa gamit ang mga bagong bit.

Gayunpaman, ang problema ay awtomatikong malulutas sa sandaling mangyari ang isa sa dalawang sumusunod na bagay:

1. Ang lahat ng mga makina ng pagkolekta ng data at naka-iskedyul na mga gawain sa mga makina na iyon ay muling patakbuhin ang pagtatasa gamit ang mga bagong bit, O

2. Ang panahon ng pagpapanatili ng data (default ng 30 araw) ay nagiging sanhi ng pagkabulok ng lumang data, na nag-iiwan lamang ng "magandang" data na nabuo pagkatapos ilabas ang tampok na Kalidad ng Pagtatasa.

Para sa kadahilanang iyon, napagpasyahan namin na ito ay isang katanggap-tanggap na halaga ng kaguluhan na dapat tiisin.

Sa pinakamasamang sitwasyon, ang mga customer ay maaaring palaging lumikha ng isang bagong workspace ng Log Analytics, o gamitin ang Data Purger API, pagkatapos ay muling patakbuhin ang pagtatasa na magreresulta sa isang malinis na blade ng Kalidad ng Pagtatasa.