Инж. техн. системы Метод. материалы (1). Министерство науки и высшего образования российской

• Название: Министерство науки и высшего образования российской
• Дата: 07.10.2021
• Размер: 61.41 Kb.
• Имя файла: Инж. техн. системы Метод. материалы (1).docx
• Тип: Документы; #242784
• страница: 7 из 11

Контрольные вопросы

лов?

1. 
   Для чего предназначена цифровая подпись системных фай-
   

2. 
   С помощью какой утилиты осуществляется проверка си-
   

стемных файлов? Какие функции она выполняет?

3. 
   Какие функции выполняет утилита Msconfig?
   
4. 
   Что такое безопасный режим загрузки Windows? Какие за- дачи с помощью его решаются?
   
5. 
   Что такое точки восстановления системы? Как с помощью их решается проблема устранения проблем, вызванных установкой нового приложения?
   
6. 
   Для чего служит консоль восстановления? Какие способы запуска её вы знаете?
   

Лабораторная работа № 5. Сбор информации об ошибках

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

Для выполнения лабораторной работы № 5 студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах.
Понятие отчета об ошибках
Отчёт об ошибке (англ. error report или crash report) – это файл, содержащий техническую информацию об исключительной ситуа- ции (исключении), произошедшей в программе на компьютере пользователя.

Отчеты об ошибках создаются, когда в системе возникают неполадки с аппаратным или программным обеспечением. Отчеты об ошибках содержат следующие разделы: сведения о состоянии компьютера при возникновении ошибки, версия используемой опе- рационной системы и аппаратного обеспечения, а также цифровой код продукта, используемый для определения лицензии. Также пе- редается IP-адрес компьютера, поскольку для отправки отчета необходимо подключиться к сетевой службе. Отчеты об ошибках могут содержать данные файлов журналов, например, имена поль- зователей, IP-адреса, URL-адреса, имена файлов и пути к ним, а также адреса электронной почты. Отчеты об ошибках отправляются с использованием шифрования в базу данных с ограниченным до- ступом и не используются в каких-либо коммерческих целях.
Настройка параметров отбора событий
Можно настроить параметры сбора данных диагностики для ведения журнала событий. События можно регистрировать как в журнале событий Windows, так и журнале трассировки. Можно настроить параметры регулирования событий, чтобы задавать число
событий, регистрируемых в каждом журнале в соответствии с кри- тичностью события. Для расширения возможностей управления при регулировании событий можно задать регулирование всех событий или любой отдельной категории событий. Доступно несколько кате- горий событий в зависимости от служб и возможностей.

Категории событий могут определяться по отдельным служ- бам или по группам связанных событий. К категориям выбранных событий относятся:

• 
  для всех;
  
• 
  категории, определенные в соответствии с используемым продуктом, например, Office SharePoint Server 2007 или Microsoft Office Project Server 2007;
  
• 
  административные функции, такие как «Администрирова- ние», «Резервное копирование и восстановление», и др.
  

Для выбранной категории устанавливается минимальный уро- вень критичности событий, которые следует регистрировать в жур- нале событий Windows и в журнале трассировки. В каждом журнале будут регистрироваться события этого или более высокого уровня критичности. Записи в этом списке сортируются в порядке от мак- симального уровня критичности к минимальному.

События журнала Windows могут иметь следующие уровни:

• 
  не используется;
  
• 
  error (ошибка);
  
• 
  warning (предупреждение);
  
• 
  не удалось выполнить аудит;
  
• 
  успешное выполнение аудита;
  
• 
  information (информация).
  

События журнала трассировки могут иметь следующие уровни:

• 
  не используется;
  
• 
  unexpected (непредвиденный);
  
• 
  monitorable (контролируемый);
  
• 
  high (высокая);
  
• 
  medium (средняя);
  
• 
  verbose (подробный).
  

Структура отчета об ошибке
ID (Идентификатор, Номер). Каждой записи в системе учета ошибок присваивается уникальный идентификатор или номер. Как правило, он задается самой системой по определенному шаблону. Это может быть просто числовой номер (1,2,3,…3487), а может быть идентификатор вида ПРОЕКТ-НОМЕР, например, TPO-2367, REG-335 и так далее.

Тип (Трекер). Системы управления задачами, как правило, содержат в себе записи различных типов – задача (Task), улучшение (Feature), баг (Bug), пользовательская история (User Story) и так да- лее. Для каждого типа может быть свой набор полей и свой жизнен- ный цикл.

Заголовок (Тема, Title). Краткое описание проблемы. Оно отображается в списках, результатах поиска, фильтрах и позволяет быстро понять, в чем суть проблемы. Оно не должно быть слишком коротким и общим, но одновременно и не должно быть слишком длинным. Существует мнемоническое правило для грамотного со- ставления описания «Что? Где? Когда?»: описание должно описы- вать, что именно сломалось, где сломалось и при каких условиях. Например, «Не работает поиск» – плохое описание ошибки, а «В форме поиска после отправки запроса выдается ошибка

«Internal Error» вместо результатов» – уже лучше.

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

Версия. Версия продукта, в которой ошибка была обнаружена.

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

Приоритет (Priority). Приоритет показывает, с какой срочно- стью должен быть исправлен дефект.

Серьезность (Важность, Severity). Серьезность показывает степень влияния дефекта на систему.

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

Описание. Подробное описание проблемы. Иногда бывает од- но поле для описания проблемы, и тогда в нем нужно указать шаги для воспроизведения, фактический результат, ожидаемый резуль- тат. Иногда вместо этого поля могут быть 3 разных – для шагов, фактического и ожидаемого результатов.

Шаги для воспроизведения. Не всегда этот пункт выделяется как отдельное поле. Если его нет, то нужно шаги для воспроизведе- ния написать в поле «Описание».

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

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

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