Chất lượng đánh giá
Tính năng Chất lượng Đánh giá là một cải tiến trên lưỡi điều kiện tiên quyết trước đó.
Tính năng chất lượng đánh giá đánh giá theo yêu cầu
Kết quả đánh giá chỉ tốt như dữ liệu được thu thập để xác nhận những phát hiện đó. Việc khám phá và thu thập dữ liệu không thành công làm giảm giá trị của kết quả đánh giá và có thể góp phần vào nhận thức về chất lượng kém. Đôi khi những vấn đề này thậm chí đi không nhận thấy mà không có khả năng để bề mặt chúng và cung cấp cho bạn hướng dẫn có thể hành động để giải quyết chúng. Cải tiến lớn đối với vùng lấy nét điều kiện tiên quyết hiện có trên bảng điều khiển đánh giá Azure log Analytics đã được phát triển với hai mục tiêu trong tâm trí:
- Các vấn đề về chất lượng đánh giá bề mặt cho phép bạn có cơ hội khắc phục và tái chạy đánh giá nhằm đảm bảo chất lượng đánh giá tốt.
- Giảm thiểu nhu cầu bạn nâng cao vé hỗ trợ để giải quyết các vấn đề chất lượng gửi dữ liệu bằng cách cung cấp nội dung khắc phục cụ thể và có thể thực hiện.
Cụ thể, các khả năng được đưa ra thị trường giúp tăng cường vùng lấy nét điều kiện tiên quyết hiện có bao gồm:
- Phân loại tiềm năng lỗi trạng thái vào giai đoạn thực hiện đánh giá ban đầu bao gồm khám phá và điều kiện tiên quyết bộ sưu tập.
- Chỉ mục chất lượng đánh giá trực quan %thành công khi thu thập dữ liệu đánh giá.
- Một đồ họa donut cập nhật để đại diện trực quan các loại và chỉ số chất lượng đánh giá.
"Chỉ số chất lượng đánh giá" thể hiện những gì?
AssessmentQualityIndex = Passed Prerequisite Workflows / Total Prerequisite Workflows
Khi đánh giá chạy, chúng tôi chạy các Collectors khác nhau và sau đó chạy Phân tích trên kết quả của những người đó. Nếu bất kỳ Trình thu thập nào thất bại (ví dụ: vì WMI từ bỏ không đạt mục tiêu), chúng tôi sẽ không có gì để chạy Phân tích trên đó. Điều này sẽ dẫn đến kết quả đánh giá không đầy đủ làm giảm chất lượng chúng tôi cung cấp cho bạn.
Điều kiện tiên quyết đã được tạo ra ban đầu để khắc phục tình huống này. Trước khi chạy Collectors, chúng tôi chạy Collectors trong "chế độ điều kiện tiên quyết" để kiểm tra xem các điều kiện tiên quyết cụ thể đã được đáp ứng hay chưa (ví dụ: chúng tôi xác minh việc từ bỏ WMI được bật cho mục tiêu). Nếu bất kỳ điều kiện tiên quyết nào không thành công, chúng tôi sẽ hiển thị những lỗi đó trong cổng thông tin Azure trong thanh kiếm "Điều kiện tiên quyết"; nhưng việc thực hiện ban đầu các điều kiện tiên quyết không làm một công việc tuyệt vời của việc hiển thị người dùng cuối một hình ảnh tổng thể về chất lượng của đánh giá.
Hãy xem xét kịch bản sau đây. Bạn đang chạy ADAssessment và 100 mục tiêu được xác định trong quá trình Khám phá. Chúng tôi chạy một Collector trong chế độ điều kiện tiên quyết để xác nhận WMI Remoting được bật, nhưng nó không chống lại mỗi mục tiêu vì bạn đã không kích hoạt WMI Remoting trong môi trường của họ. Trước Chất lượng Đánh giá, bạn sẽ thấy một lỗi điều kiện tiên quyết duy nhất trong Azure liên quan đến "WMI Remoting không được bật" (WMI Remoting). Tuy nhiên, trên thực tế sẽ có 100 quy trình làm việc tiên quyết không thành công và đánh giá sẽ khó có thứ gì để phân tích, dẫn đến đánh giá rất kém. Điều này không nhất thiết phải rõ ràng vì bạn chỉ có thể thấy một lỗi điều kiện tiên quyết trong Azure.
Bây giờ, với tính năng Chất lượng Đánh giá, chúng tôi cung cấp một Chỉ số Chất lượng Đánh giá, chỉ đơn giản là tỷ lệ dòng công việc điều kiện tiên quyết được Thông qua/ Dòng công việc điều kiện tiên quyết của Tổng số. Vì vậy, trong ví dụ trên, bạn sẽ thấy Chỉ số Chất lượng Đánh giá 0% hoặc 1%, làm cho rõ ràng rằng chất lượng đánh giá tổng thể vô cùng kém do điều kiện tiên quyết không thành công.
Lưu ý
Trong cuộc sống thực, ADAssessment có thể chạy nhiều quy trình điều kiện tiên quyết hơn, không chỉ WMI Remoting, vì vậy chúng tôi sẽ có nhiều khả năng thấy một chỉ số chất lượng đánh giá cao hơn.
Đâu là sự khác biệt giữa Discovery Failure, Important Prerequisite Failures và Other Prerequisite Failures?
Bài đánh giá trải qua nhiều giai đoạn khác nhau khi chạy. Trước tiên, chúng tôi thực hiện Discovery để tìm các nút khác nhau sẽ được đánh giá. Tiếp theo, chúng tôi chạy nhiều Collectors khác nhau trong Chế độ Điều kiện tiên quyết. Cuối cùng, chúng ta sẽ chạy Collectors bình thường, sau đó chạy Phân tích.
Điều kiện tiên quyết chủ yếu có liên quan với hai giai đoạn đầu tiên: Discovery và Collectors chạy trong chế độ điều kiện tiên quyết.
Tệp đầu ra điều kiện tiên quyết giờ đây sẽ xác định giai đoạn mà trong đó mỗi lỗi điều kiện tiên quyết xảy ra và chúng tôi sẽ hiển thị phần đó trong Azure.
Tại sao phím Điều kiện tiên quyết quan trọng chỉ đôi khi hiển thị trong Biểu đồ/Chú giải Donut?
Khi các tác giả IP tạo bài đánh giá của họ, họ có thể tùy ý đánh dấu Dòng công việc là Quan trọng. Điều này có nghĩa rằng Dòng công việc rất quan trọng đối với chất lượng của bài đánh giá. Nếu đánh giá đã cho không xác định dòng công việc quan trọng, chúng tôi sẽ KHÔNG hiển thị các Lỗi điều kiện tiên quyết quan trọng trong Biểu đồ/Chú giải Donut trong Azure.
Tại sao đôi khi chúng tôi chỉ hiển thị "Lỗi khám phá", chứ không phải các danh mục khác trong Azure?
Nếu thử nghiệm MVE (Môi trường Khả năng truy nhập Tối thiểu) thất bại trong quá trình Khám phá, nó có nghĩa là không đáp ứng được một số prereqiusites cơ bản nhất định (ví dụ: trong SQLAssessment, không có máy chủ SQL nào có thể được tìm thấy). Trong trường hợp đó, Collectors thậm chí không chạy ở Chế độ điều kiện tiên quyết - chúng tôi giải cứu sớm sau khi chạy đánh giá. Khi điều này xảy ra, chúng tôi chỉ hiển thị Sự cố Khám phá trong Azure.
Tại sao tôi thấy lưỡi dao Đánh giá Chất lượng trống?
Không phải tất cả các máy thu thập dữ liệu/các nhiệm vụ đã lên lịch gửi dữ liệu đến không gian làm việc Log Analytics này đều đã chạy lại bài đánh giá với các bit Chất lượng Đánh giá mới. Sẽ tự động giải quyết một lần 1) tất cả các máy thu thập dữ liệu và các nhiệm vụ đã lên lịch trên những máy đó đã chạy lại đánh giá bằng các bit mới, HOẶC 2) khoảng thời gian lưu trữ dữ liệu (mặc định là 30 ngày) làm cho dữ liệu cũ mục tiêu, để lại chỉ dữ liệu "tốt" được tạo ra sau khi tính năng Chất lượng Đánh giá được phát hành.
Tính năng Chất lượng Đánh giá yêu cầu chúng tôi thêm cột CustomData mới vào tệp đầu ra đánh giá và UX mới phân tích cột CustomData mới này để tạo các tĩnh được hiển thị trong lưỡi Chất lượng Đánh giá mới.
Điều này làm cho khả năng tương thích ngược trở nên khó khăn. UX mới chỉ hoạt động nếu bạn chạy bài đánh giá bằng cách sử dụng thay đổi Máy khách ODA mới sẽ tự động điền cột CustomData. Vì vậy, chúng tôi có một số mã trong UX của chúng tôi sẽ xác định xem không gian làm việc Log Analytics có bất kỳ bản ghi nào có CustomData được điền, biểu thị đánh giá đã được chạy bằng các bit mới hay chưa. Nếu không, chúng ta sẽ quay trở lại với lưỡi kiếm điều kiện tiên quyết cũ. Nếu CustomData DOES tồn tại, thì chúng tôi sẽ hiển thị lưỡi Chất lượng Đánh giá mới.
Nhưng có thể nhiều máy thu thập dữ liệu (hoặc thậm chí nhiều tác vụ được lên lịch trên cùng một máy thu thập dữ liệu) đang gửi dữ liệu đến một không gian làm việc Log Analytics duy nhất và lưỡi dao này là tổng hợp các kết quả điều kiện tiên quyết cho tất cả các máy thu thập dữ liệu được kết nối với không gian làm việc. Vậy điều gì sẽ xảy ra nếu một số máy đã gửi dữ liệu với cột CustomData mới, nhưng một số người không? Chúng tôi hiển thị UX cũ hay UX mới?
Đây là khi bạn sẽ thấy lưỡi dao trống trong ảnh chụp màn hình ở trên. Không có giải pháp tuyệt vời ở đây, vì vậy bạn sẽ thấy trạng thái trung gian bị lỗi này cho đến khi tất cả các máy thu thập dữ liệu đã gửi dữ liệu bằng cách sử dụng các bit mới.
Có một số trường hợp biên không may ở đây có thể dẫn đến trải nghiệm đau đớn cho khách hàng:
Chúng tôi biết rằng đối với một số bài đánh giá khá phổ biến khi thiết lập nhiều tác vụ đã lên lịch trên cùng một máy thu thập dữ liệu (ví dụ: Đánh giá máy khách Windows) và những tác vụ đã lên lịch đó được thiết lập để chạy vào các ngày khác nhau. Giả sử bạn có hai nhiệm vụ, một vào thứ Hai và một vào Thứ Tư. Sau khi tác vụ chạy vào thứ Hai, bạn sẽ thấy lưỡi trống ở trên cho đến khi nhiệm vụ thứ hai chạy vào Thứ tư, tại thời điểm đó khách hàng nên bắt đầu nhìn thấy lưỡi Dao Chất lượng Đánh giá mới.
Điều gì sẽ xảy ra nếu 3 máy thu thập dữ liệu đều có SQL Assessment đang chạy và chỉ đến cùng một không gian làm việc Log Analytics, nhưng một trong những máy đó đã ngừng hoạt động cách đây 2 tuần? Hai máy khác sẽ chạy đánh giá với các bit mới của chúng tôi, nhưng vì máy thứ ba đã ngừng hoạt động, nó không thể chạy bài đánh giá với các bit mới của chúng tôi. Trong trường hợp này, khách hàng sẽ thấy lưỡi trống ở trên.
Chúng tôi đã thấy vấn đề này trong một số không gian làm việc thử nghiệm của chúng tôi có LOT của những người đang chạy đánh giá và gửi dữ liệu đến cùng một không gian làm việc Log Analytics. Trong trường hợp này, nó rất khó khăn (có lẽ là không thể) để theo dõi tất cả mọi người và làm cho họ để chạy lại đánh giá bằng cách sử dụng các bit mới.
Tuy nhiên, vấn đề sẽ tự động giải quyết chính nó một trong hai điều sau đây xảy ra
- Tất cả các máy thu thập dữ liệu và các tác vụ đã lên lịch trên những máy đó đã chạy lại bài đánh giá bằng cách sử dụng các bit mới, HOẶC
- Khoảng thời gian Lưu trữ Dữ liệu (mặc định 30 ngày) làm cho dữ liệu cũ mục hỏng, chỉ để lại dữ liệu "tốt" được tạo ra sau khi tính năng Chất lượng Đánh giá được phát hành.
Vì lý do đó, chúng tôi quyết định đây là một số tiền chấp nhận được của sự hỗn loạn để chịu đựng.
Trường hợp xấu nhất, khách hàng luôn có thể tạo không gian làm việc Log Analytics mới hoặc sử dụng API Lọc dữ liệu, sau đó chạy lại bài đánh giá sẽ dẫn đến lưỡi dao Đánh giá sạch.