Система формирования решения проблем функционирования компьютерных систем

Настоящая полезная модель предназначена для формирования решения проблем функционирования и исправления ошибок, возникающих в компьютерных системах пользователей. Технический результат настоящей полезной модели, заключающийся в автоматическом формировании решений проблем функционирования и исправления ошибок в компьютерных системах, достигается за счет автоматической генерации и добавления пользователями решений, способных исправить проблему на компьютерных системах пользователей. Оптимизация решений осуществляется на основе показателей качества решений, которые определяются в результате тестирования данных решений. Полезная модель позволяет обнаруживать проблему, потенциальную проблему или ошибку, выбирать наиболее оптимальный набор решений, применять их в автоматическом режиме с учетом рейтинга решений и профиля пользователя, а также фиксировать проблемы, их решения и формировать правила и решения. Применение полезной модели на практике позволяет повысить надежность компьютерных систем, на которых установлена и которые подключены к системе формирования решений проблем функционирования компьютерных систем.

Область техники

Настоящая полезная модель относится к системам технической поддержки пользователей и более конкретно к системам формирования решения проблем функционирования и исправления ошибок, возникающих в компьютерных системах пользователей.

Уровень техники

Уровень качества и удобства технической поддержки пользователей является важным показателем в характеристике технологического продукта. Одним из видов технической поддержки является поиск решений в базе знаний без вмешательства специалиста технической поддержки или эксперта. В реализованных на сегодняшний день подобных сервисах решения возникших проблем представляют собой документы в электронном формате (тексты и/или графические изображения), зачастую объединенные в базы знаний. Данными документами могут быть статьи, файлы-справки, инструкции для пользователей и многое другое.

Для нахождения необходимой информации по выявлению и устранению проблем, пользователю приходится потратить много времени на изучение документов, возможно не относящихся к продукту или его версии, которая интересует пользователя. Зачастую пользователь может не догадываться о причинах вызвавших тот или иной сбой, или у него может быть недостаточно квалификации, чтобы определить появление ухудшений в работе системы.

Существуют системы, анализирующие состояние компьютерной системы и обнаруживающие проблемы или ошибки. Подобные системы описаны, например, в патентах US6845474, US5740354 и заявках JP2006350955A2, JP2000322267A2. Однако они не способны в автоматическом режиме устранить существующую проблему.

Другой тип систем, например, который описан в патенте US5058113, позволяет обнаружить ошибку в удаленной компьютерной системе и исправить ее, используя известные правила. Однако данные правила представляют собой сигналы, а для определения наличия ошибки требуется период времени, в течение которого система находится под наблюдением. Более того часть проблем могут не сопровождаться отчетами об ошибках, что значительно сужает область применения данной системы.

На данный момент не существует систем, которые способны определить наличие проблем, классифицировать проблему, предложить наиболее эффективные варианты достижения положительного результата и по возможности применить данный вариант. В имеющихся системах также отсутствуют функции создания правил и решений, которые могут добавлять пользователи..

Данная полезная модель устраняет описанные недостатки и позволяет быстрее и эффективнее решить задачу восстановления корректного функционирования компьютерных систем пользователей.

Сущность полезной модели

Настоящая полезная модель предназначена для формирования решения проблем функционирования и исправления ошибок, возникающих в компьютерных системах пользователей.

Технический результат настоящей полезной модели заключается в автоматическом формировании решений проблем функционирования и исправления ошибок. Применение полезной модели на практике позволяет повысить надежность компьютерных систем, на которых установлена и которые подключены к системе формирования решений проблем функционирования компьютерных систем. Технический результат достигается за счет автоматической генерации и добавления пользователями новых решений, способных исправить проблему на компьютерных системах других пользователей. Описанная далее полезная модель позволяет обнаруживать проблему, потенциальную проблему или ошибку, выбирать наиболее оптимальный набор решений, применять их в автоматическом режиме с учетом рейтинга решений и профиля пользователя, а также фиксировать новые проблемы, их решения и формировать новые правила и решения.

Система формирования решения проблем функционирования компьютерных систем состоит из: (а) средства формирования новых решений, предназначенного для получения нового решения для категории проблем, записанного в заданном формате на компьютере пользователя, подключенного к серверу, поиска решений для упомянутой категории проблем в базе данных, сравнение по показателями качества нового решения с найденными в процессе упомянутого поиска в базе данных решениями; (б) средства тестирования решений, предназначенного для исполнения новых и хранящихся в базе данных решений в различных программно-аппаратных конфигурациях с целью определения показателей качества упомянутых решений и записи показателей качества в базу данных; (в) базы данных, предназначенной для упорядоченного хранения категорий проблем, решений, правил, по которым решение ставится в соответствие категории проблем, и показатели качества решений.

В варианте реализации система формирования решения проблем функционирования компьютерных систем содержит средство принятия решений, предназначенное для сбора системной информации, с подключенного к серверу компьютера пользователя, по которой определяется категория проблем и конфигурация компьютера пользователя, формирования списка решений из базы данных, соответствующих упомянутой категории проблем и применимых для упомянутой конфигурации компьютера пользователя, при этом список решений упорядочен по рейтингу решений и передачи решений из сформированного списка решений на упомянутый компьютер пользователя в упорядоченном порядке.

Также вариант реализации содержит базу данных, которая дополнительно содержит таблицы для упорядоченного хранения профилей пользователей, включающих, по меньшей мере, системную информацию персонального компьютера пользователя, информацию о возникших проблемах, принятых на персональном компьютере пользователя решениях и добавленных пользователем решениях;

Существует вариант реализации, в котором средство принятия решений загружает профиль пользователя из базы данных для его учета в формировании списка решений.

Пример реализации системы обрабатывает системную информацию, которая включает программную и аппаратную конфигурации компьютера пользователя, журналы событий, файлы отчетов приложений, информацию об ошибках, состояние центрального процессора, состояние оперативно запоминающего устройства, состояния сетевых устройств.

В одном из вариантов реализации рейтинг решений рассчитывается по количеству применений решения, причем, чем больше количество устранений проблем в компьютерных системах пользователей с использованием данного решения, тем больше его рейтинг.

Средства тестирования решений в различных вариантах реализации представляют собой набор виртуальных машин с различными программно-аппаратными конфигурациями и компьютеры пользователей, предназначенные для тестирования применения решения в программно-аппаратной конфигурации упомянутых виртуальных машин и упомянутого компьютера пользователя соответственно.

Различные варианты реализации используют для оценки решений показатели качества, включающие рейтинг решений, эффективность решений.

Краткое описание прилагаемых чертежей

Сопровождающие чертежи, которые включены для обеспечения дополнительного понимания полезной модели и составляют часть этого описания, показывают варианты осуществления полезной модели и совместно с описанием служат для объяснения принципов полезной модели.

Заявленная полезная модель поясняется следующими чертежами, на которых:

Фиг.1а, 1б и 1в показывают возможные варианты установки системы на сервере технической поддержки и компьютерной системе клиента.

Фиг.2 демонстрирует разделение компонентов, при установке системы на сервер технической поддержки и при установке на компьютерную систему клиента.

Фиг.3а отображает структурную схему системы формирования решения проблем функционирования компьютерных систем.

Фиг.3б показывает общую схему сервера, в котором имплементирована полезная модель.

Фиг.4 показывает блок схему алгоритма решения проблем.

Фиг.5 показывает блок схему алгоритма добавления частного решения.

Фиг.5а включает наборы частных решений с общими параметрами системы и общими решениями проблем.

Фиг.5б показывает блок схему алгоритма поиска решений с применением нечеткой логики.

Фиг.6 отображает схему выборки из базы данных правил и решений с учетом профиля пользователя.

Фиг.7 демонстрирует взаимосвязи проблем и решений с использованием логических правил.

Фиг.8а показывает схему поиска решений для новой проблемы в заданной подкатегории.

Фиг.8б показывает схему формирования правил для новых решений, относящихся к определенной ошибкой категории проблем.

Фиг.9 отображает последовательность решения сложных проблем с помощью вложенных цепочек решений.

Фиг.10 показывает пример компьютерной системы общего назначения, персонального компьютера или сервера.

Описание предпочтительных вариантов осуществления

Объекты и признаки настоящей полезной модели, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящая полезная модель не ограничивается примерными вариантами осуществления, раскрытыми ниже, она может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями для помощи специалисту в области техники в исчерпывающем понимании полезной модели, и настоящая полезная модель определяется только в объеме приложенной формулы.

Средство решения системных проблем представляет собой сложно структурированную систему, состоящую из нескольких средств. Данная система необходима для осуществления поддержки пользователей. В различных вариантах реализации описываемое средство может быть установлено в системе клиента, на удаленном сервере или распределено между системой клиента и удаленным сервером технической поддержки.

На Фиг.1а, 1б, 1в показаны три примера сервиса с различной архитектурой. Фиг.1а описывает пример, когда средство решения проблем установлено в системе клиента. Данный вариант позволяет осуществлять поддержку и устранять проблемы без подключения к сети Интернет, однако имеет недостаток - решения могут быть устаревшими, т.к. обновить их можно только установив новую систему, включающую данный сервис. При такой реализации клиент 100 называют «толстым» клиентом, а сервис выполнен в виде модуля быстрой поддержки пользователей 110. Реализация может представлять собой файл-справку (например, в формате .chm) к установленному приложению. Фиг.1б описывает более сложную структуру реализации, в которой функции сервиса распределены между клиентом 100 и сервером 130. В систему пользователя устанавливается модуль быстрой поддержки пользователя 110, который обладает необходимыми функциями для нахождения и устранения проблемы, возникшей в этой системе. В таком виде система клиента идентична системе, изображенной на Фиг.1а. Ряд функций, таких как обновление решений, профили пользователей, добавление новых решений, расширенная база знаний доступен благодаря серверу 130 с установленной базой быстрой поддержки пользователей 120. Работа сервиса в этом примере возможна, как используя подключение к серверу через сеть Интернет, так и без него. Третий возможный способ исполнения средства поддержки на Фиг.1в заключается в установке на сервере 130 быстрой поддержки пользователей 140, доступ к которому осуществляется с помощью веб-приложений, таких как браузер. Использование сервера быстрой поддержки пользователей возможно только при подключении к сети Интернет. При этом появляются положительные моменты, которые заключаются в отсутствии необходимости установки модуля поддержки в систему клиента, сокращение затрат вычислительных ресурсов, сохранение всех функции, которые предоставляет сервис, показанный на Фиг.1б. Примером системы с архитектурой показанной на Фиг.1в является веб-страница технической поддержки. Модули, показанные на Фиг.1а-в могут иметь собственные базы данных (не отображены). Данные также могут храниться в файлах различных форматов.

В зависимости от выбранного вида установки системы формирования решения проблем, конфигурации средства клиента и сервера могут варьироваться. На Фиг.2 показано структурное разделение системы решения проблем между клиентом 100 и сервером 130. При полной установке сервиса в систему клиента 100, он содержит следующие компоненты: локальную базу данных решений 201, средство сбора данных 202, средство принятия решений 203, средство исполнения решений 204, средство добавления решений 205, средство проверки решений 206 и базу данных правил проверки решений 207. В случае, когда архитектура системы предполагает включение сервера, часть функций дополняется и/или поддерживается в сервере 130 быстрой поддержки и реализуются в следующих средствах: база данных решений 211, средство сбора данных 212, средство принятия решений 213, средство исполнения решений 214, средство формирования новых решений 215, средство проверки решений 216, база данных правил проверки решений 217, база данных статистики решений 218, база данных профилей пользователей 219, средство тестирования решений 220. Некоторые средства, описанные на Фиг.2, дублируются в клиенте и сервере, но при этом функция их может различаться. Сервер обладает большим запасом вычислительных ресурсов, соответственно способен хранить большее количество информации и обрабатывать ее более сложными алгоритмами. В качестве примера рассмотрим базу данных решений 211 и локальную базу данных решений 201. Обе базы не отличаются функционально и предназначены для хранения проблем, решений и правил, по которым выбирается то или иное решение. При этом база данных, установленная на сервере способна хранить гораздо больший объем данных и обрабатывать его, в то время как локальная база данных содержит только информацию для конкретной версии системы пользователя. База данных статистики предназначена для хранения всех характеристик решений, полученных за счет учета применения каждого решения. Например сохраняется количество применений решения, количество эффективных применений, разбиение количества применений по геоположению пользователя и т.д. Далее будет подробнее описана функция сервиса и взаимосвязь его компонентов.

Структурная схема системы формирования решения проблем представлена на Фиг.3. При возникновении сбоев системы или других проблем средство сбора данных 300 сканирует систему пользователя. Этот процесс включает сбор внутренних отчетов, журналов, настроек программ, а также анализ установленных программ и средств в системе. Например, средство сбора данных может получить следующую информацию о системе:

- Коды ошибок

- Версия программы

- Данные о лицензии

- Дата обновления антивирусных баз

- Отчеты программ

- Журнал действий пользователей

- Конфигурация системы (программная и аппаратная)

Одним из важнейших оснований для автоматической категоризации проблемы является возвращаемое программой значение ошибки (явная категоризация). Список ошибок заранее содержит в себе информацию о типе проблемы, и может послужить одной из составляющих окончательной категоризации. Ниже приведены некоторые типы ошибок, характерные для антивирусных средств защиты (например, Kaspersky Internet Security 2011), возникающих у пользователей при работе программ.

[Licensing] - неизвестная ошибка

[Licensing] - ключ в черном списке

[Licensing] - базы данных устарели

[Activation] - превышено количество легальных пользователей

[Activation] - имя сервера не найдено

[Activation] - файл ключа заблокирован

[Activation] - код активации не подходит данному приложению

[Licensing] - лицензия недействительна

[Activation] - время действия ключа окончено

[Licensing] - некорректная дата активации

[Activation] - прокси-сервер недоступен

[Detection] - невозможно вылечить файл

[Conflict] - приложение завершилось аварийно

[Conflict] - конфликт с приложением

Ошибки могут возникать не только в приложениях и службах, вроде антивируса, но и в операционных системах (системных службах, драйверах и т.д.). Информация о них также может применяться для категоризации проблемы.

Важным фактом для определения категории проблемы является место запуска описываемой системы. Для многих продуктов есть возможность встроить точку вызова функции в диалоговое окно продукта. Например, для антивируса в диалоговом окне «Создать аварийную копию» можно встроить точку вызова сервиса. Если сервис был вызван из этой точки, то с большой долей вероятности можем предположить, что у пользователя возникла проблема с созданием задания по аварийному резервированию.

Далее собранные данные поступают в средство принятия решений 310. Главной задачей средства принятия решений является выбор наиболее полезного и продуктивного решения для системы пользователя. Для этого оно классифицирует проблему - определяет категорию проблемы по определенным параметрам. Предположим у пользователя проблема с обновлением антивирусных баз, в этом случае есть два варианта причины: окончание лицензионного соглашения и отсутствие доступа к северу обновления. Каждое из этих условий будет указывать, по меньшей мере, на категорию проблем, связанную с обновлением баз. В случае возникновения сложности с лечением файла, данные об этом будут записаны в журнале антивируса, по которой определяется категория «проблемы лечения файлов».

Далее создается запрос в базу данных правил и решений 320, где из всех записей производится выборка для данной проблемы и/или категории проблем. Решения обладают определенным рейтингом. После применения того или иного решения определяется, помогло ли оно или нет. В зависимости от результата повторной проверки или опроса рейтинг повышается или понижается соответственно. Рейтинги решений хранятся в базе данных статистики 218. Сортировка решений по рейтингу позволяет применять наиболее эффективные предложения по устранению неполадок, которые к тому же специализированы для данной конкретной системы пользователя.

Применение решения осуществляет средство исполнения решений 350, представляющее собой интерпретатор машинных инструкций, в случае если решение заключено в файле сценария. Применение решения также может заключаться в воспроизведении медиафайлов (флеш, аудио или видио) или текстовой информации или в загрузке исполняемого файла, в зависимости от того, в каком формате задано решение. Решением может быть также ссылка на обновление программного обеспечения, ссылка на программу-заплатку или ссылка на медиа-файл, который демонстрирует порядок действий для восстановления работоспособности.

Как было отмечено ранее, существует также возможность пополнения базы данных решений пользователями или сторонними специалистами, именуемыми экспертами. Для этого в системе предусмотрено средство добавления решений 340, которое создает решение в стандартизированном виде. Средство проверки решений 350 предотвращает попадание в систему ложных решений или, более того, решений, которые способны нанести вред компьютерам пользователей. Предусмотрено два варианта данного средства - проверка файла решения и эмуляция поведения решения. Правила проверки решений 360 являются отдельной структурой в системе. Для каждого пользователя заводится профиль, который содержит набор идентификационных данных и параметров системы, журнал, в котором хранится история возникших проблем, примененных решений и решенных проблем. Профили позволяют индивидуализировать работу средства поддержки и оптимизировать ее. База данных профилей 219 хранит данные пользователей, пользующихся данным сервисом.

В качестве основных можно выделить следующие категории проблем (для антивирусных средств защиты):

- процесс активации продукта завершился с ошибкой;

- обнаружен вредоносный объект и невозможно его удалить;

- антивирусные базы устарели, и возникла проблема с их обновлением;

- на компьютере пользователя установлена не последняя сборка продукта;

- возникли проблемы с установкой/удалением продукта;

- обнаружены уязвимости установленного программного обеспечения;

- другие подобные проблемы, возникающие при использовании продукта.

Рассмотрим механизм поиска и применения решения, который показан на Фиг.4. Процесс инициируется запросом на решение проблемы 400. Запрос составляется и отправляется автоматически в случае отклонения рабочих показателей системы от нормы или инициируется пользователем.

Существует два возможных варианта развития событий: с применением интеллектуального поиска решений и без его применения. Сервис можно настроить также на последовательное решение проблемы - с применением интеллектуального поиска решений, а затем без него. В случае применения интеллектуального поиска производится сбор данных системы, их анализ и выявление стандартной проблемы 420. Под стандартной проблемой понимается уже известная и классифицированная проблема, которая хранится в памяти сервиса. Автоматический поиск может оказаться безрезультатным, в этом случае система позволяет осуществить поиск проблемы по списку категориий. При этом также производится сбор данных 410 для более точного поиска. Следующим шагом за выбором категории проблемы с учетом полученных данных является поиск подходящих решений 425. Каждое решение обладает собственным рейтингом, который высчитывается по статистическим показателям, что позволяет отсортировать 430 найденные решения по статистике (по рейтингу). Далее на шаге 435 происходит последовательное применение решений. Если решение с наибольшим рейтингом не исправило неблагоприятную ситуацию, применяется следующее решение по убыванию рейтинга. Подобный цикл 435-450, состоящий из проверки эффективности решения, изменения статистики решения и применения следующего решения, если такое существует, повторяется до тех пор, пока положительный результат не будет достигнут или пока не применены все решения, соответствующие данной проблеме. После применения каждого решения обновляется статистика данного решения: рейтинг повышается, когда решение помогло и рейтинг понижается в противном случае. Если после прохождения процесса поиска решений путем выбора категории проблемы и с применением интеллектуального поиска, проблема остается нерешенной, составляется запрос эксперту 455, состоящий из собранных данных о системе и принятых мерах. Запрос фиксируется в базе данных в качестве проблемы, требующей решения. Процесс завершается выходом из системы 465 после отправки запроса эксперту или после удовлетворительного результата применения решения.

Фиг.7 демонстрирует пример правил, которые осуществляют связь условий (параметров компьютерной системы пользователя и решений. Представленные блок-схемы позволяют более детально описать процесс выбора решений для определенной проблемы. В базе данных правил и решений хранятся записи о проблемах 700, разделенные на классы (категории) 710 и решения 720, а также правила 740, по которым каждой категории проблем ставится в соответствие несколько решений 730. При этом количество решений для одной категории проблем может составлять ноль, одно, два и ограничивается лишь объемами памяти. Решение может быть отнесено к нескольким проблемам, т.е. несколько проблем могут решаться одним способом. Например, на Фиг.7 правило определило, что решение «а» может помочь в исправлении проблем «1» и «6». А решений для категории проблем «2» правило не нашло, в то время как для категории «5» определено три возможных решения. Правила для определения решений создает эксперт в процессе обучения системы - указывает верные и неверные решения, выставляет причинно-следственные зависимости и контрольные значения параметров, характеризующие пробему и соответствующее решение. Создание правила экспертом для каждой частной проблемы и каждого частного решения приведет к появлению изрядного количества подобных правил и как следствие к переполнению памяти и нехватке ресурсов для поиска и хранения этих правил. Одним из вариантов реализации, в котором данный недостаток отсутствует, является средство принятия решений с алгоритмом, построенным на правилах нечеткой логики и возможностью генерации новых правил и решений за счет полученных от пользователей частных решений.

Для повышения скорости обмена данными между пользователями и оперативного дополнения базы данных решений описываемая система позволяет пользователям добавлять решения в автоматическом режиме. В случае, когда пользователь зафиксировал отклонения от нормы в работе системы или об этом ему сигнализировала система и пользователь знает каким образом можно их устранить, ему предлагается создать решение этой проблемы самостоятельно и загрузить в базу данных правил и решений. Пользователь, который осуществляет данную процедуру, именуется экспертом. Процесс добавления решений изображен в виде блок-схемы на Фиг.5. Началом данного процесса является запрос на добавление решения на этапе 500. Для того чтобы стандартизировать формат правил стоит определить проблему на этапе 505 - отнести ее к определенной категории, используя информацию, полученную от средства сбора данных 300. На шаге 510 происходит запуск генератора решений - средства, входящего в состав средства добавления решений 340, который на этапе 515 записывает действия эксперта на машиночитаемом языке. Данный процесс принято называть записью макроса. Чтобы не допустить записи вредоносного, ошибочного, неквалифицированного решения, предлагается два этапа проверки кода решения: непосредственно во время записи на этапе 520 и по результатам тестирования решения (этапы 530, 535). В случае если решение не соответствует правилам безопасности и/или стандартам качества, решение исправляется или не сохраняется (этап 525). Правилами безопасности являются права доступа к файлам, процессам и т.д, а под стандартом качества понимаются показатели эффективности, совместимость программ и устройств и т.д. Для проверки, можно использовать различные методы тестирования решений, например, с использованием компьютеров пользователей. Когда решения успешно проходят оба этапа проверки, они сохраняются в базе данных решений в таблицу для добавленных решений на этапе 540, рейтинг пользователя изменяется в базе данных профилей пользователей на этапе 545 и процесс завершается на этапе 550. В результате количество полезных решений увеличивается, и повышается вероятность и скорость достижения положительного исхода. Процедура добавления решений предполагает сохранение информации, полученной от пользователя, в следующем формате:

Добавленное решение содержит состояние системы и инструкции для исправления неполадки, созданные генератором решения, и является частным решением. Состояние системы представлено набором параметров системы с их значениями. Значение параметра может быть установлено или может отсутствовать. Значение отсутствует, если данный параметр не может охарактеризовать данную конфигурацию системы, например, когда в компьютере пользователя не установлено соединение с сетью и параметры состояния сетевых портов не могут быть получены. Вероятность абсолютного совпадения исходных данных у нескольких пользователей очень мала, что делает данную запись практически неприменимой. Чтобы преобразовать частное решение в решение, которое будет эффективно использоваться во многих системах пользователей (далее именуется общим решением), применяется алгоритм, показанный на Фиг.5а. В базе данных накапливаются частные решения пользователей 561, 571, 581. Они состоят из набора параметров системы Х 562, 572, 582 и набора инструкций А и В, которые на Фиг.5а обозначены номерами 563, 573, 583. Накапливаемые частные решения сравниваются друг с другом и объединяются, образуя общее решение и правило, по которому оно ставится в соответствие проблеме. Сравнение может осуществляться всеми известными способами, например, по контрольным суммам. Результатом сравнения является количественная мера, характеризующая степень совпадения двух наборов параметров или двух наборов инструкций. Пороги значений данных степеней, при превышении которых наборы считаются похожими, задаются экспертами.

Рассмотрим два случая соответствия частных решений. Первый случай возникает, когда наборы инструкций двух частных решений считаются похожими. В этом случае сравниваются установленные параметры системы, соответствующие данным решениям. Отсутствующие (неустановленные) параметры при сравнении игнорируются. В итоге образуется правило, которое определяет следственную связь между общим набором параметров системы, который является пересечением двух исходных наборов параметров, и наборами инструкций в частных решениях. Данное правило сохраняется в базе данных правил и решений.

Например, Х1={х1,х2,х3,х4} и Х2=(х1,х2,х3,х4,х5}, где х1-х5 - установленные параметры системы, и А1=А2, где А1 и А2 - совпадающие наборы инструкций, решающие проблемы, заключенные в X1 и Х2 соответственно. Тогда правило будет выглядеть следующим образом:

IF [X={x1, х2, х3, х4}] THEN [A1, A2],

где [А1, А2] список решений, состоящий из решения A1 и A2.

Сходство наборов параметров системы составляет второй частный случай, который предполагает создание правила, определяющего связь между дополненным набором параметров системы и каждым набором инструкций в частных решениях. Под дополненным набором параметров понимается тот, в котором различающиеся значения параметра дополняют друг друга. Данный параметр имеет два и более значения, в зависимости от количества значений параметра в исходных наборах.

Например, Х1={х1, х2, х3, х4} и Х2={х1, х2, х3, х4'}, где х1-х4, х4' - установленные параметры системы, и А1А2, где A1 и A2 - различающиеся наборы инструкций, решающие проблемы, заключенные в X1 и Х2 соответственно. Тогда правило будет выглядеть следующим образом:

IF [Х={х1, х2, х3, х4 or x4'}] THEN [A1, A2],

где [А1, А2] список, состоящий из решения А1 и А2.

Когда количество значений параметра системы в правиле достигает относительно большого значения, то набор можно экстраполировать в функцию. Данный шаг может позволить предугадать потенциальные проблемы, сократить количество правил и упростить хранение данных. Примером подобного прогнозирования может являться случай, в котором конфликт антивируса происходит с несколькими версиями приложения, например, с версиями 1.0, 1.1, 1.2. В данном случае Х1=1.0, Х2=1.1 Х3=1.2. Можно предположить, что конфликт можно будет встретить и с версией 1.3.

На Фиг.5б изображен пример реализации алгоритма определения решений, основанный на нечеткой логике. Алгоритм заключается в определении правил для исправления проблем в компьютерной системе пользователя. На этапе 591 средство сбора данных 300 собирает информацию о системе пользователя: операционной системе, программной и аппаратной конфигурации, отчетах приложения и т.д. На этапе 592 происходит переход от частных параметров системы к нечетким проблемам - лингвистическим переменным (термам). Этот процесс представляет собой классификацию проблем и тем самым разделение их на категории. Например, набору параметров со значениями соответствуют следующие термы:

Параметр и его значение	Терм	Класс проблем
Дата последнего обновления приложения =	Приложение обновлялось:
3 дня назад	Недавно	-
1 неделя назад	Давно	Проблемы с
		обновлением
Уровень загрузки центрального процессора =	Загрузка:
10%	Слабая	-
50%	Средняя	-
90%	Сильная	Конфликт приложений;
		Лечение вирусов

На этапе 593 нечеткие правила из базы данных правил и решений 320 сопоставляются с нечеткими переменными. В результате, после сопоставления будет найдено правило, подходящее той или иной нечеткой переменной. Правило содержит ссылку на набор решений или на параметр, который характеризует каждое решение и сохраняется в виде метаданных, тем самым на шаге 593 будут установлен тип решений, который способен исправить имеющуюся проблему согласно заданному правилу. Для перехода к четким переменным существует этап 594, на котором в базе дынных правил и решений находятся решения данного типа. Далее на шаге 595 происходит передача найденных решений на исполнение. Применение решения производится на стороне клиента, путем воспроизведения решения. Передача решений может осуществляться через http протокол или любой другой протокол передачи данных, с помощью специльно установленного программного агента и т.д.

Другой пример адаптивного поиска решения показан на Фиг.8а. На чертеже изображена база данных правил и решений 320, в которой проблемы 700 разбиты на категории, подкатегории и разделы. Каждой проблеме соответствует набор решений 710. В случае если обнаружена проблема, для которой не существует решений в базе данных, делается предположение, что для схожих проблем могут быть одни и те же решения. В качестве примера приведена проблема «Б», которая находится в одной подкатегории с проблемами 700 «А» и «В». Соответствующие правила определили наборы решений 710: {X1, Х2, Х3} для проблемы «A», {Y1, Y2, Y3} для проблемы «В» и пустой набор решений для «Б». В этом случае строится адаптивный набор решений 720, который содержит решения проблем своей подкатегории. Итогом работы данного алгоритма будет правило:

IF [«Б»] THEN [X1, Y1, Х2, Y2, Х3, Y3]

В данном примере решения проблем «А» и «В» чередуются, однако порядок следования может быть выбран и в зависимости от рейтинга решения, его простоты и т.д.

У пользователя могут возникнуть сложные проблемы, которые невозможно классифицировать однозначно. Они разбиваются на несколько более простых проблем и решаются последовательно. Примерами возникновения сложных проблем могут являться следующие ситуации:

- при решении проблемы лечения вируса может оказаться, что необходимо решить проблему обновлений антивирусных баз;

- при возникновении ситуации, когда приложением является антивирус и базы антивирусных сигнатур повреждены, может возникнуть необходимость выполнить восстановление антивирусной программы, проверку на вирусы, выполнить обновление программы до последней версии - в зависимости от текущих условий. Все эти вложенные решения - решения проблем, обнаруженных в ходе исправления первоначальной задачи, могут предлагаться как параллельно, так и последовательно, одно за другим.

- в ситуации, когда приложение, например антивирус, не запускается, может возникнуть потребность перейти к удалению несовместимого программного обеспечения, выполнить проверку на вирусы, выполнить обновление программы до последней версии.

Ход решения сложных проблем показан на Фиг.9. Существует цепочка решений проблемы «А» 900, которая состоит из отдельных решений расположенных по рейтингу. В ходе применения решений появляется необходимость в решении другой проблемы «В», называемой в данном случае вложенной. Цепочки вложенных решений 910, 920, 930, 940 так же отсортированы по рейтингу. После исправления вложенных проблем процесс возвращается в следующий по порядку этап решения проблемы «А». Количество вложений ограничено количеством подкатегорий проблем, известных на данный момент и сохраненных в базе данных правил и решений. Процесс завершается в момент, когда положительный результат достигнут или испробованы все предложенные решения. В данном примере для решения проблемы «А» потребовалось решить четыре вложенные проблемы. Всего в примере показано использование пятнадцати различных решений. Каждая цепочка решений отсортирована по признаку и содержит решения, которые учитывают параметры компьютера пользователя и данные из его профиля: историю применения решений, уровень знаний пользователя и т.д.

Решение в общем случае представляет собой набор данных, руководствуясь которыми можно предотвратить или исправить сбой в работе компьютерной системы. Существует много различных вариантов в представлении решений для компьютерных систем, к которым относятся текстовые документы, медиафайлы (аудио, видео, анимация), исправление программы (patch), файлы конфигурации, сценарии. Каждый вид решений может дополнять или заменять другие, например, для решения проблемы необходимо выполнить сценарий, но чтобы проблема не возникла повторно, рекомендуется установить исправление для продукта или для операционной системы. Использование каждого из видов решений не всегда представляется возможным в связи с различиями в операционных системах пользователей и другими обстоятельствами. Самым распространенным способом является поддержка с помощью текстовых документов. Положительной стороной данного способа является доступность для всех пользователей, легкость в редактировании и простота в использовании. С развитием технологий появляются более насыщенные способы поддержки пользователей с применением видео, аудио и других медиа форматов. Однако документы в таком формате, также как и текстовые документы, невозможно применить автоматически. Рассмотрим варианты решений, воплощение которых не требует действий пользователя, - это обновления, дополнения или исправления программы или системы в целом с помощью специальных средств исправлений (patch). Данные средства можно установить в систему пользователя и тем самым устранить неполадки системы. Исправления создаются экспертами и добавляются в базу данных решений. Еще одной разновидностью решений может быть сценарий - последовательность инструкций на машинном языке, которые могут быть исполнены системой без какого либо вмешательства пользователя. Сложность в реализации сценариев заключается в том, что не все компоненты обладают ключевым функционалом - не существует интерфейса управления. Файлы конфигурации позволяют применять настройки системы, но существует проблема, аналогичная проблеме применения сценариев.

Учет настроек компьютера пользователя позволяет значительно повысить качество представляемого сервиса поддержки. В некоторых смыслах индивидуализация является необходимым фактором для эффективного решения проблем. Правила, которые позволяют определить полезные решения, т.е. использование которых возможно в данной системе и с определенной долей вероятности приведет к положительному эффекту, используют параметры, получаемые из компьютера пользователя. Учет параметров составляет основную функцию индивидуализации. Функционал дополняется такими возможностями, как:

- Ведение истории пользователя (сохранение возникающих проблем, решений, которые оказались полезными, добавленных решений, настроек программы и т.д.);

- Выбор уровня знаний (представление решений в соответствии уровню знаний пользователя: начинающий, продвинутый и экспертный уровни);

- Рейтинг пользователя (ранжирование пользователей по качеству и количеству добавленных решений, частотой пользования сервисом) и т.д.

Уровень знаний пользователя устанавливается, например, самим пользователем, по умолчанию в качестве начального уровня или основывается на других настройках. Если настройки приложения отличаются от стандартных, пользователь считается экспертом. Подробное описание категоризации пользователей отражено в заявке под номером RU 2009142890.

Таблица 1
Тип пользователя	Уровень представления данных	Решение
Начальный уровень	простой	Подробное описание последовательности действий
Продвинутый уровень	средний	Указание настроек системы и описание последовательности действий
Экспертный уровень	сложный	Указание специфических настроек системы

В таблице 1 показан пример соответствия уровней знаний и уровней представления данных. Для пользователей с начальным уровнем знаний описание решения будет сопровождаться в виде подробного описания последовательности действий. Продвинутый пользователь получит доступ к более компактным комментариям с указанием настроек системы и описанием последовательности действий. Эксперту, как правило, достаточно предоставить самую необходимую информацию, которую он понимает и знает, как ее применить.

На Фиг.6 показана структурная схема индивидуализации сервиса. Средство сбора данных сканирует систему и определяет ее параметры: наименование, версию и серийный номер приложения 610; тип, лицензионный ключ и дату окончания лицензии 620; страну и язык локализации 630; дату и номер обновления антивирусных баз 640. Средство принятия решений 600 учитывает собранные данные и осуществляет выборку из базы данных правил и решений 320 - фильтрует из всего списка решений только те, которые соответствуют данным параметрам. В итоге, если у пользователя установлено антивирусное приложение N-ной версии с актуальными антивирусными базами и действующим лицензионным ключом, средство принятия решений предложит решение специально для данной N-ной версии продукта и исключит из списка решения проблемы, связанные с нелицензионным использованием и устаревшими антивирусными базами.

В общем случае действия системы можно выстроить в следующую последовательность: (а) обнаруживается событие (если событие можно идентифицировать, то определяется код ошибки, класс проблемы и т.д.); (б) действия на системе записываются в журнал, который анализирутеся для определения ошибки, сбоя в системе, предшествующих конфликту приложений, сбою в работе приложения, действия пользователя (неверные настройки, неверные действия, такие как разрешение выполнения вредоносного кода, отключение программы защиты и т.д.); (в) применение правил нечеткой логики для системных параметров и определение возможных решений; (г) применение решений с учетом сортировки по рейтингу и персонализации; (д) добавление нового частного решения и его проверка.

На Фиг.8б показана схема формирования решения и правила для данного решения. На фигуре отображены решения, исправляющие ошибку 12345 890: «решение 1» 850, «решение 2» 860, «решение 3» 870. Как было описано выше, номер ошибки категоризирует проблему. По номеру ошибки можно определить, что произошло у пользователя - невозможно вылечить файл или невозможны запись/чтение памяти, ошибка в программе и другое. При этом зафиксированы наборы системных параметров, при которых была зафиксирована данная проблема - параметры X1-Х4 (820-823). На Фиг.8б отображены связи параметров и решения, которые позволяют определить эффективное исправление проблемы для данного набора параметров.

Пунктирные стрелки задают правила: связь параметров и ошибок может быть неоднозначной. Возможны случаи, когда для частного случая не существует решения. Например, ошибка 12345 890, возникшая в компьютерной системе с параметрами Х4 823 в данный момент не может быть исправлена с использованием данных связей, тогда как ошибка в системе Х2 821 решается сразу двумя способами. В представленном в качестве примера наборе правил существует избыточность - ошибку в система X1-Х3 (820-822) можно исправить, используя два решения из трех известных. Соответственно сравнивая рейтинги решений можно удалить одно из них, например, «решение 3» 870. На Фиг.8б также показано «Новое Решение» 880. Оно может быть добавлено в базу данных экспертом или быть сгенерированным по алгоритмам, описанным в этом документе. «Новое решение» 880 может являться объединением, дополнением или пересечением нескольких известных решений с целью повышения его эффективности и применимости. Известно, что оно позволяет исправить Ошибку 12345 890, но для того, чтобы определить рейтинг решения, эффективность его работы на компьютерных системах с различными системными параметрами, необходимо тестирование решения. Процесс тестирования может проходить в автоматическом режиме на компьютерных системах пользователей или в виртуальном пространстве, в котором моделируются различные наборы параметров - например различные версии ОС, процессоров, пользовательских приложений, сетевых интерфейсов и т.д. После того, как результаты тестирования получены, новое решение сравнивают с другими известными решениями и их мета данными об эффективности и применимости решения. Например, в случае если «Новое Решение» 880 исправляет ошибку 12345 890 во всех частных системах X1-Х4 (820-823) и при этом является менее ресурсоемким по сравнению с другими, его рейтинг будет самым высоким, и оно будет применяться в первую очередь.

Общая схема сервера, в котором имплементирована полезная модель, представлена на Фиг.3б. В базе данных 380 хранятся решения; их мета-данные; правила, по которым определяются решения для исправления соответствующих ошибок и проблем функционирования. Сервер позволяет пополнять данную базу путем генерации новых правил (оптимизации имеющихся правил); тестировать решения для определения совместимости решений с системными параметрами: программными и аппаратными составляющими компьютерной системы пользователя и определения рейтинга для новых решений; а также для формирования последовательности решений, сортированных по рейтингу и персонализированных с учетом профиля пользователя, в ответ на собранную системную информацию. Средство формирования решений 365 обрабатывает созданное экспертом решение, проводит поиск схожих решений и решений для данной категории проблем (для данной ошибки), после чего проводит сравнение данных решений по рейтингу, по совместимости и анализирует избыточность решений. На основе этих показателей проставляется первичный уровень рейтинга для нового решений. Новые решений проходят этап тестирования в средстве тестирования решений 370 для определения совместимости и уровня эффективности на компьютерах с различными настройками и характеристиками. Совместимость, уровень эффективности, рейтинг и другие возможные характеристики решений в совокупности составляют показатели качества решений. Данное средство 370 может быть реализовано различными способами, например, в качестве набора виртуальных машин с разными характеристиками. В случае если ошибка будет исправлена в той или иной виртуальной машине, решение считается совместимой с данными параметрами. Чем больше количество совместимых компьютерных систем, тем больше эффективность. В качестве расширения функционала, оценивается ресурсоемкость решений: время, память, вычислительные ресурсы, необходимые для исполнения решения. Результаты тестирования влияют на рейтинг решений: чем больше эффективность и меньше ресурсоемкость, тем выше рейтинг. Существует вариант реализации, в котором тестирование решение переносится на сторону пользователей. В случае возникновения проблемы, отправляется новое решение, после чего возвращаются результаты, которые обрабатываются и заносятся в базу данных. Поиск решений для пользователей осуществляет средство принятия решений 375, подробно описанное ранее.

Фиг.10 представляет пример компьютерной системы общего назначения, персонального компьютера или сервера 20, содержащих центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS), содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс привода магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.).

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35 и дополнительные программные приложения 37, другие программные модули 38 и программные данные 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонки, принтер и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг.10. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 51 и глобальную вычислительную сеть (WAN) 52. Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 51 через сетевой адаптер или сетевой интерфейс 53. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью 52, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

1. Система формирования решения проблем функционирования компьютерных систем, включающая сервер, который при этом содержит:

(а) средство формирования решений, хранящееся в памяти и исполняемое на процессоре сервера, предназначенное для:

- получения решения для категории проблем, записанного в заданном формате на компьютере пользователя, подключенного к серверу, и записи полученного решения в базу данных;

- поиска решений для упомянутой категории проблем в базе данных;

- сравнения полученного решения по показателям качества с найденными в процессе упомянутого поиска в базе данных решениями;

и при этом упомянутое средство принятия решений связано со средством тестирования решений и базой данных;

(б) средство тестирования решений, хранящееся в памяти и исполняемое на процессоре сервера, предназначенное для исполнения полученных и хранящихся в базе данных решений в различных программно-аппаратных конфигурациях с целью определения показателей качества упомянутых решений и записи показателей качества в базу данных, при этом упомянутое средство тестирования решений связано с базой данных;

(в) базу данных, хранящуюся в памяти сервера, предназначенную для упорядоченного хранения категорий проблем, решений, правил, по которым решение ставится в соответствие категории проблем, и показатели качества решений;

2. Система по п.1, которая дополнительно содержит средство принятия решений, хранящееся в памяти и исполняемое на процессоре сервера, предназначенное для:

- сбора системной информации, по меньшей мере, с одного подключенного к серверу компьютера пользователя, по которой определяется категория проблем и конфигурация компьютера пользователя;

- формирования списка решений из базы данных, соответствующих упомянутой категории проблем и применимых для упомянутой конфигурации компьютера пользователя, при этом список решений упорядочен по рейтингу решений; и

- передачи решений из сформированного списка решений на упомянутый компьютер пользователя в упорядоченном порядке.

3. Система по п.1, в которой база данных дополнительно содержит таблицы для упорядоченного хранения профилей пользователей, включающих, по меньшей мере, системную информацию персонального компьютера пользователя, информацию о возникших проблемах, принятых на персональном компьютере пользователя решениях и добавленных пользователем решениях.

4. Система по пп.2 и 3, в которой средство принятия решений предназначено также для загрузки профиля пользователя из базы данных и формирования списка решений с учетом загруженных данных.

5. Система по п.1, в которой системная информация включает, по меньшей мере, программную и аппаратную конфигурации компьютера пользователя, журналы событий, файлы отчетов приложений, информацию об ошибках, состояние центрального процессора, состояние оперативно запоминающего устройства, состояние сетевых устройств.

6. Система по п.1, в которой рейтинг решений рассчитывается по количеству применений решения, причем чем больше количество устранений проблем в компьютерных системах пользователей с использованием данного решения, тем больше его рейтинг.

7. Система по п.1, в которой средство тестирования решений представляет собой набор виртуальных машин с различными программно-аппаратными конфигурациями, предназначенными для тестирования применения решений.

8. Система по п.1, в которой средство тестирования решений хранится и исполняется, по меньшей мере, на одном компьютере пользователя и предназначено для тестирования применения решения в программно-аппаратной конфигурации упомянутого компьютера пользователя.

9. Система по п.1, в которой показатели качества содержат, по меньшей мере, рейтинг решений, эффективность решений.

10. Система формирования решения проблем функционирования компьютерных систем, включающая сервер, который при этом содержит:

(а) средство формирования решений, хранящееся в памяти и исполняемое на процессоре сервера, предназначенное для:

- поиска решений для категории проблем в базе данных;

- формирования решения для упомянутой категории проблем путем модификации решений, найденных в базе данных в процессе поиска, и записи сформированного решения в базу данных;

- сравнения по показателям качества сформированного решения с найденными в процессе поиска в базе данных решениями;

и при этом упомянутое средство принятия решений связано с базой данных и средством тестирования решений;

(б) средство тестирования решений, хранящееся в памяти и исполняемое на процессоре сервера, предназначенное для исполнения сформированных и хранящихся в базе данных решений в различных программно-аппаратных конфигурациях с целью определения показателей качества упомянутых решений и записи показателей качества в базу данных, при этом упомянутое средство тестирования решений связано с базой данных;

(в) базу данных, хранящуюся в памяти и исполняемую на процессоре сервера, предназначенную для упорядоченного хранения категорий проблем, решений, правил, по которым решение ставится в соответствие категории проблем, и показатели качества решений.

11. Система по п.10, которая дополнительно содержит средство принятия решений, хранящееся в памяти и исполняемое на процессоре сервера, предназначенное для:

- сбора системной информации, по меньшей мере, с одного подключенного к серверу компьютера пользователя, по которой определяется категория проблем и конфигурация компьютера пользователя;

- формирования списка решений из базы данных, соответствующих упомянутой категории проблем и применимых для упомянутой конфигурации компьютера пользователя, при этом список решений упорядочен по рейтингу решений; и

- передачи решений из сформированного списка решений на упомянутый компьютер пользователя в упорядоченном порядке.

12. Система по п.10, в которой база данных дополнительно содержит таблицы для упорядоченного хранения профилей пользователей, включающих, по меньшей мере, системную информацию персонального компьютера пользователя, информацию о возникших проблемах, принятых на персональном компьютере пользователя решениях и добавленных пользователем решениях.

13. Система по пп.11 и 12, в которой средство принятия решений предназначено также для загрузки профиля пользователя из базы данных и формирования списка решений с учетом загруженных данных.

14. Система по п.10, в которой системная информация включает, по меньшей мере, программную и аппаратную конфигурации компьютера пользователя, журналы событий, файлы отчетов приложений, информацию об ошибках, состояние центрального процессора, состояние оперативно запоминающего устройства, состояние сетевых устройств.

15. Система по п.10, в которой рейтинг решений рассчитывается по количеству применений решения, причем чем больше количество устранений проблем в компьютерных системах пользователей с использованием данного решения, тем больше его рейтинг.

16. Система по п.10, в которой средство тестирования решений представляет собой набор виртуальных машин с различными программно-аппаратными конфигурациями, предназначенными для тестирования применения решений.

17. Система по п.10, в которой средство тестирования решений хранится и исполняется, по меньшей мере, на одном компьютере пользователя и предназначено для тестирования применения решения в программно-аппаратной конфигурации упомянутого компьютера пользователя.

18. Система по п.10, в которой показатели качества содержат, по меньшей мере, рейтинг решений, эффективность решений.