Что такое известная ошибка

From Wikipedia, the free encyclopedia

A known error is a software bug that has not been fixed, but has a known root cause and either has little disruptive impact on the end user or a known work around.^[1]

Tested systems are often described as «free from known errors» in recognition that complex systems cannot be proven to be error free.^[2]

In IT Operations known errors may be logged in a system’s known error database (KEDB) which is then used to prioritize changes and to develop customer support reference information where a work around exists.^[3] In the ITIL framework KEDB is a part of the Problem Management process.

See also[edit]

• Fatal system error

References[edit]

From Wikipedia, the free encyclopedia

A known error is a software bug that has not been fixed, but has a known root cause and either has little disruptive impact on the end user or a known work around.^[1]

Tested systems are often described as «free from known errors» in recognition that complex systems cannot be proven to be error free.^[2]

In IT Operations known errors may be logged in a system’s known error database (KEDB) which is then used to prioritize changes and to develop customer support reference information where a work around exists.^[3] In the ITIL framework KEDB is a part of the Problem Management process.

See also[edit]

• Fatal system error

References[edit]

известная ошибка

Введение

Управление ИТ-услугами (ITSM) включает работу с инцидентами и проблемами. По мере возрастания роли ИТ в компании растет и потребность в обеспечении хорошего уровня сервиса, обеспечении максимальной доступности ИТ-услуг. Бизнес-пользователь должен иметь возможность получить решение своих проблем, если они возникают, как можно быстрее, и работать в любое время. Реализация процессов управления инцидентами и проблемами нацелена именно на это. В данной статье мы описываем, как может быть устроена работа ИТ-службы в рамках управления инцидентами и проблемами. Это описание основано на предложениях ITIL и опыте наших клиентов.

Язык инцидентов и проблем

ITIL Service Support — признанная в мире модель. Она основана на передовом опыте и используется как руководство ИТ-организациями при разработке подходов к управлению обслуживанием. Эта модель перспективна. Также она определяет дополнительные элементы, необходимые для успешного функционирования ИТ-организации как сервисного бизнеса. Она предоставляет технический словарь для обсуждения службы поддержки, определяет понятия и раскрывает отличия между различными видами деятельности. Например, деятельность, необходимая для реагирования на прерывания сервиса, его восстановления, отлична от деятельности по поиску и устранению причин, из-за которых прерывается обслуживание.

Инциденты

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

Примерами инцидентов являются:

1. Пользователь не может получить e-mail
2. Средство мониторинга сети указывает, что канал связи вскоре переполнится
3. Пользователь ощущает замедление работы приложения

Проблемы

Проблема — есть неизвестная причина одного или более инцидентов.Одна проблема может породить несколько инцидентов.

Ошибки

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

Примеры ошибок включают:

1. Неправильная сетевая конфигурация компьютера
2. Средство мониторинга неверно определяет статус канала в момент занятости маршрутизатора

Соотношение понятий управления инцидентами и проблемами показано на рисунке 1. Инциденты, проблемы и известные ошибки связаны в своего рода жизненный цикл: инциденты часто являются индикаторами проблем ⇒ выявление причины проблемы определяет ошибку ⇒ ошибки затем систематически исправляются.

Управление инцидентами

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

Она включает в себя:

1. Выявление и регистрация инцидентов
2. Классификация и начальная поддержка
3. Исследование и диагностика
4. Решение и восстановление
5. Закрытие
6. Владение, мониторинг, отслеживание и связь

Управление проблемами

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

Управление проблемами включает:

1. Контроль проблем
2. Контроль ошибок
3. Предотвращение проблем
4. Анализ основных проблем

Контроль проблем

Цель контроля проблем — найти причину проблемы, выполнив следующие шаги:

1. Идентификация и регистрация проблем
2. Классификация проблем и определение приоритетов их решений
3. Исследование и диагностика причин

Контроль ошибок

Контроль ошибок обеспечивает исправление проблем за счет следующих действий:

1. Идентификация и регистрация известных ошибок
2. Оценка способов устранения и расстановка приоритетов
3. Регистрация по временному обходу ошибки в средствах службы поддержки
4. Закрытие известных ошибок путем осуществления исправлений
5. Мониторинг известных ошибок для определения необходимости в изменении приоритетов

Анализ проблем

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

Организационные роли и распределение ответственности

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

Первый уровень поддержки

Организация (подразделение), представляющая первый уровень поддержки обычно относится к оперативным службам. Как правило, она называется диспетчерской службой, Call Center, Help Desk, Service Desk.

Роли. Владелец процесса

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

Первая линия поддержки

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

Обязанности

• Точная регистрация инцидентов. Первый уровень поддержки гарантирует, что информация об инциденте вносится в журнал системы. Для этого должно быть:

  • Гарантировано, что карточка инцидента содержит точное и достаточно детальное описание проблемы
  • Гарантирован правильный выбор важности/приоритета инцидента
  • Определена природа проблемы, контакты пользователя, влияние на бизнес и ожидаемое время решения

• Владение каждым инцидентом. Как адвокат конечного пользователя первый уровень поддержки обеспечивает успешное разрешение каждого инцидента. При этом гарантируется своевременное решение вопросов за счет:

  • Разработки и управления планом действий по решению вопроса
  • Инициации конкретных назначений заданий для персонала и бизнес-партнеров
  • Эскалации инцидента, если требуется, когда цель не достигается во время
  • Обеспечения внутреннего взаимодействия в соответствии с целями обслуживания
  • Защиты интересов вовлеченных бизнес-партнеров

• Первый уровень поддержки использует базу данных управления проблемами для сопоставления инцидентов известным ошибкам и применения ранее найденных способов разрешения инцидентов. Цель заключается в разрешении 80 процентов инцидентов. Остальные инциденты передаются (эскалируются) на второй уровень.

• Непрерывное улучшение процесса управления инцидентами. Как владелец данного процесса первый уровень поддержки гарантирует улучшение при необходимости процесса посредством:

  • Оценки эффективности данного процесса и таких механизмов поддержки, как отчеты, виды связи и форматы сообщений, процедуры эскалации
  • Разработки специфических для подразделений отчетов и процедур
  • Поддержки и совершенствования взаимодействия и списков эскалации
  • Участие в процессе анализа проблем

Способности и навыки

• Навыки межличностного общения первостепенны. Персонал первого уровня поддержки вовлечен главным образом в расстановку приоритетов и управление проблемами. На этом уровне поддержки проводятся лишь незначительные технические изыскания. Способность применять «консервированные» решения. Персонал первого уровня должен уметь распознавать симптомы, применять поисковые инструменты для обнаружения ранее разработанных решений и помогать конечным пользователям в применении таких решений.

Второй уровень поддержки

Этот уровень также обычно относится к оперативным службам.

Роли

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

Обязанности

• Решение инцидентов, переданных с первого уровня. Если для первого уровня поддержки ожидается, что он решает 80% инцидентов, то от второго уровня поддержки ожидается, что он решает 75% инцидентов, переданных ему первым уровнем, то есть 15% от числа зарегистрированных инцидентов. Остальные инциденты передаются на третий уровень.
• Определение причин проблем. Второй уровень поддержки определяет причины проблем и предлагает меры по их обходу или устранению. Они привлекают и управляют другими ресурсами по мере необходимости для определения причин. Решение проблем передается на третий уровень, когда причина заключается в архитектурном или техническом вопросе, который превышает их уровень квалификации.
• Обеспечение реализации исправлений и устранений проблем. Второй уровень поддержки обеспечивает инициирование проектов в организациях разработчиках для реализации планов устранения известных ошибок. Они обеспечивают документирование найденных решений, сообщают о них персоналу первого уровня и реализуют их в инструментах.
• Постоянный мониторинг инфраструктуры. Второй уровень поддержки пытается идентифицировать проблемы до возникновения инцидентов посредством наблюдения за компонентами инфраструктуры и принятия корректирующих действий при обнаружении дефектов или ошибочных тенденций.
• Заблаговременный анализ тенденций инцидентов. Уже случившиеся инциденты исследуются для того, чтобы определить не свидетельствуют ли они о наличии проблем, которые следует исправить, чтобы они не вызвали новые инциденты. Исследуются те инциденты, которые закрыты и не сопоставлены известным проблемам, на предмет наличия потенциальных проблем.
• Постоянное совершенствование процесса управления проблемами. Как владелец процесса управления проблемами второй уровень поддержки гарантирует, что процесс и имеющиеся возможности адекватны и улучшает их при необходимости. Они проводят сессии анализа проблем, чтобы выявить полученные уроки и гарантировать, что средства контроля над процессом, такие как совещания и отчеты, адекватны.

Способности и навыки

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

Третий уровень поддержки

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

Роли

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

Обязанности

• Решение инцидентов, переданных со второго уровня. Так как большинство инцидентов вызывается известными ошибками, то очень немного инцидентов (5%) проходит через второй уровень на третий. Третий уровень отвечает за решение всех инцидентов, которые к ним поступают.
• Участие в деятельности по управлению проблемами.Третий уровень поддержки задействован в поиске причин, способов обхода и устранения ошибок.
• Реализация мер по устранению ошибок из инфраструктуры. У третьего уровня значительная роль в планировании, конструировании и реализации проектов по устранению недостатков инфраструктуры. Выполнение этих проектов должно быть согласовано с обычной работой по развитию инфраструктуры для достижения нужного баланса.

Способности и навыки

• Эксперты в соответствующих областях. Команды третьего уровня должны быть экспертами, которые планируют и проектируют ИТ-инфраструктуру.

Процессы

Можно выделить три основных процесса, связанных с управлением инцидентами и управлением проблемами:

• процесс управления инцидентами
• процесс контроля проблем
• процесс контроля ошибок

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

Процесс управления инцидентами

Данный процесс сфокусирован на скорейшем восстановлении прерванного сервиса. В таблице 1 приведены основные параметры этого процесса, а на рисунке 1 показана диаграмма его работы.

Рисунок 1. Модель процесса

Процесс контроля проблем

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

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

Рисунок 2. Модель процесса контроля проблем

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

1. Если у вас достаточное количество проблем, то назначьте постоянную команду. Иначе создавайте команду при появлении проблемы, во многом также как формируется команда под какой-либо проект;
2. Команда почти всегда должна быть с междисциплинарным опытом и знаниями. И это конечно зависит от природы возникшей проблемы;
3. Следует давать оценку времени на определение причины (разрабатывать план проекта) в момент появления проблемы. В соответствии с этой оценкой следует измерять прогресс в деятельности команды.

После того как ресурсы выделены и расставлены приоритеты, фактическая механика определения причины может принимать различные формы. Хорошо зарекомендовали себя такие методы поиска причин как Анализ Кепнера и Трего, диаграммы Ишикавы, диаграммы Парето и прочее.

Процесс контроля ошибок

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

Рисунок 3. Модель процесса контроля ошибок

Взаимодействия

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

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

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

Эскалация

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

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

Функциональная эскалация

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

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

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

Иерархическая эскалация

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

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

Отчеты и совершенствование процессов

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

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

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

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

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

Наконец жизненно необходимый набор отчетов, типа:

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

Заключение

Разработка процессов и процедур управления инцидентами проводится многими организациями, но далеко не все эти организации делают то же самое для управления проблемами. Часто это происходит из-за недостаточно ясного понимания характеристик этих двух видов деятельности. Управление инцидентами — простейший вид деятельности для понимания, поскольку он просто создает механизм для реагирования на прерывания сервиса. Поскольку «визгливое колесо всегда будет смазано», то управление инцидентами развивается достаточно быстро. Однако для развития управления проблемами часто имеется меньше поводов.

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

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

Управление Проблемами

5.1. Введение

Как
было сказано в предыдущей главе, Процесс
Управления Инцидентами начинает
действовать с появлением инцидента и
прекращает свою работу после исправления
ситуации. Это означает, что корневая
причина возникновения инцидента не
всегда бывает установлена и инцидент
может повто­риться снова.

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

5.1.1. Определение — «проблема» и «известная ошибка»

На
рис 5.1 показаны взаимосвязи между
проблемой, известной ошибкой и Запросом
на Изменение и даны определения этих
терминов.

5.1.2. Взаимоотношения с Процессом Управления Инцидентами

Процесс
Управления Проблемами поддерживает
Процесс Управления Инцидентами,
предоставляя ему обходные решения и
быстрые исправления-, но при этом не
неся прямой ответственности за раз­решение
инцидента. Управление Инцидентами
помогает быстро исправить ошибку любыми
доступ­ными средствами, включая
обходные решения, в то время как Управление
Проблемами занимается поиском причины
произошедшего и ее устранением. Инцидент
может никогда «не стать» проблемой.
Однако кроме самого инцидента, может
быть определена связанная c.
ним
проблема. Поэтому работа над проблемой
может помочь в разрешении текущего
инцидента, если он еще открыт.

5.2. Цель процесса

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

Управление
Проблемами гарантирует, что:

• существующие
  и регулярно возникающие ошибки
  идентифицированы, документированы и
  отсле­живаются;

• симптомы
  ошибок, постоянные или временные решения
  документируются;

• подаются
  Запросы на Изменения с целыо модификации
  инфраструктуры;

• предотвращается
  возникновение новых инцидентов;

• создаются
  отчеты о качестве инфраструктуры ИТ и
  самого процесса.

Управление
Проблемами позволяет быстро улучшить
качество услуг путем значительного
сокраще­ния количества инцидентов и
уменьшения рабочей нагрузки на
ИТ-организацию. Некоторые из преимуществ
данного процесса состоят в следующем:

• Улучшение
  качества
  ИТ-услуг
  и Управления — результат документирования
  ошибок и/или их устранения.

• Повышение
  производительности
  труда
  пользователей
  — за счет улучшения качества услуг.

• Повышение
  производительности труда персонала
  — наличие документированных решений
  проб­лем позволяет даже менее опытным
  участникам Процесса Управления
  Инцидентами разрешать инциденты быстрее
  и эффективнее.

• Улучшение
  репутации
  ИТ-услуг
  — в результате улучшения стабильности
  услуг заказчики с боль­шим желанием
  сотрудничают с ИТ-организацией в новых
  сферах бизнеса.

• Совершенствование
  знаний в области
  Управления,
  эффективное обучение
  — Процесс Управле­ния Проблемами
  позволяет хранить исторические данные’,
  которые используются при определе­нии
  тенденций
  и
  помогают принять меры по предотвращению
  новых инцидентов. Исторические данные
  также можно использовать при проведении
  исследований
  и
  диагностирования, а также, при создании
  Запросов на Изменения.

• Улучшение
  регистрации инцидентов — Управление
  Проблемами вводит стандарты на
  регистра­цию и классификацию инцидентов
  с целью эффективного определения
  проблем и их симптомов. Это также
  помогает улучшить составление отчетов
  об инцидентах.

• Более
  высокая доля инцидентов, разрешенных
  на первой линии поддержки — поскольку
  Про­цесс Управления Проблемами
  разрабатывает решения для ликвидации
  инцидентов и проблем, а обходные решения
  можно найти в базе знаний, то первая
  линия поддержки с большим успехом сама
  разрешает инциденты.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Ошибка, недостаток, сбой или сбой в компьютерной программе или системе

A Ошибка программного обеспечения — это ошибка, недостаток или сбой в компьютерной программе или системе, из-за которой она дает неверный или неожиданный результат или ведет себя непредусмотренным образом. Процесс поиска и исправления ошибок называется «отладка » и часто использует формальные методы или инструменты для выявления ошибок, а с 1950-х годов некоторые компьютерные системы были разработаны также для обнаружения, обнаружения или автоматического исправления различных компьютерные ошибки во время работы.

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

Некоторые программные ошибки связаны с катастрофами. Ошибки в коде, который управлял аппаратом Therac-25 лучевой терапии, были непосредственными причинами смерти пациентов в 1980-х годах. В 1996 г. ракета Европейского космического агентства стоимостью 1 миллиард долларов прототип Ariane 5 должна была быть уничтожена менее чем через минуту после запуска из-за ошибки в системе. бортовая компьютерная программа наведения. В июне 1994 года вертолет Royal Air Force Chinook врезался в Mull of Kintyre, в результате чего погибло 29 человек. Первоначально это было отклонено как ошибка пилота, но расследование Computer Weekly убедил запрос Палаты лордов в том, что это могло быть вызвано ошибкой программного обеспечения в компьютере управления двигателем.

самолета. В 2002 году исследование, проведенное по заказу Национальный институт стандартов и технологий Министерства торговли США пришел к выводу, что «программные ошибки или ошибки настолько распространены и настолько пагубны, что обходятся экономике США примерно в 59 миллиардов долларов. ежегодно, или около 0,6 процента валового внутреннего продукта ».

Содержание

• 1 История
  • 1.1 Отчет« Ошибки в системе »
• 2 Терминология
• 3 Профилактика
  • 3.1 Типографические ошибки
  • 3.2 Методологии разработки
  • 3.3 Поддержка языков программирования
  • 3.4 Анализ кода
  • 3.5 Инструментарий
• 4 Тестирование
• 5 Отладка
• 6 Тест ошибок
• 7 Управление ошибками nt
  • 7.1 Уровень серьезности
  • 7.2 Приоритет
  • 7.3 Версии программного обеспечения
• 8 Типы
  • 8.1 Арифметика
  • 8.2 Логика
  • 8.3 Синтаксис
  • 8.4 Ресурс
  • 8.5 Многопоточность
  • 8.6 Взаимодействие
  • 8.7 Работа в команде
• 9 Последствия
• 10 Хорошо известные ошибки
• 11 В популярной культуре
• 12 См. Также
• 13 Ссылки
• 14 Внешние ссылки

История

Среднеанглийское слово bugge лежит в основе терминов «bugbear » и «bugaboo » как терминов, используемых для обозначения монстра.

Термин «ошибка» для описания дефектов был частью инженерного жаргона с 1870-х годов и предшествовал электронным компьютерам и компьютерному программному обеспечению; возможно, изначально он использовался в аппаратной инженерии для описания механических неисправностей. Например, Томас Эдисон написал следующие слова в письме своему сотруднику в 1878 году:

Так было во всех моих изобретениях. Первым шагом является интуиция, и она приходит с порывом, затем возникают трудности — эта штука выдает, и [это] затем, что «жуки» — как называются такие маленькие ошибки и трудности — проявляют себя и месяцы интенсивного наблюдения, изучения прежде чем будет достигнут коммерческий успех или провал, необходимы и труд.

Baffle Ball, первая механическая игра в пинбол, в 1931 году рекламировалась как «свободная от ошибок». Проблемы с военным снаряжением во время Второй мировой войны упоминались как ошибки (или сбои ). В фильме 1940 года Flight Command дефект в части радиопеленгатора называется «ошибкой». В книге, опубликованной в 1942 году, Луиза Дикинсон Рич, говоря о механизированной машине для резки льда, сказала: «Распиловка льда была приостановлена ​​до тех пор, пока не будет привлечен создатель, чтобы устранить жучков. своего любимого ».

Исаак Азимов использовал термин« ошибка »для обозначения проблем с роботом в своем рассказе« Поймай этого кролика », опубликованном в 1944 году.

A страница из журнала электромеханического компьютера Harvard Mark II с изображением мертвой мотылька, удаленной с устройства.

Термин «ошибка» использовался в описании компьютерного первопроходца Грейс Хоппер, который объявил причину неисправности в одном из первых электромеханических компьютеров. Типичная версия этой истории такова:

В 1946 году, когда Хоппер освободили от действительной службы, она поступила на Гарвардский факультет в вычислительную лабораторию, где продолжила свою работу над Mark II и Марк III. Операторы связали ошибку в Mark II с мотыльком, застрявшим в реле, придумав термин «ошибка». Этот баг был аккуратно удален и записан в журнал. Исходя из первой ошибки, сегодня мы называем ошибки или сбои в программе ошибкой.

Хоппер не нашла ошибку, что она с готовностью признала. В бортовом журнале была дата 9 сентября 1947 года. Операторы, которые его нашли, включая Уильяма «Билла» Берка, позже работавшего в Лаборатории военно-морского оружия, Дальгрен, Вирджиния, были знакомы с техническим термином и забавно сохранил насекомое с пометкой «Первый реальный случай обнаружения ошибки». Хоппер любил пересказывать эту историю. Этот журнал, вместе с прикрепленным к нему мотыльком, является частью коллекции Смитсоновского Национального музея американской истории.

Связанный термин «отладка » также появился раньше, чем его использовали в вычислительной технике: Оксфордский словарь английского языка этимология этого слова содержит свидетельство 1945 года в контексте авиационных двигателей.

Идея, что программное обеспечение может содержать ошибки, восходит к 1843 году Ады Лавлейс. примечания к аналитической машине, в которых она говорит о возможности того, что программные «карты» для аналитической машины Чарльза Бэббиджа ошибочны:

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

Отчет «Ошибки в системе»

Институт открытых технологий, управляемый группой New America, выпустил доклад «Ошибки в системе» в августе 2016 года, в котором говорится, что политики США должны провести реформы, чтобы помочь исследователям выявлять и устранять ошибки программного обеспечения. В отчете «подчеркивается необходимость реформы в области обнаружения и раскрытия уязвимостей программного обеспечения». Один из авторов отчета сказал, что Конгресс сделал недостаточно для устранения уязвимости киберпрограмм, хотя Конгресс принял ряд законопроектов по борьбе с более серьезной проблемой кибербезопасности.

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

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

Терминология

Хотя использование термина «ошибка» для описания ошибок программного обеспечения является обычным явлением, многие предложили отказаться от него. Один из аргументов состоит в том, что слово «ошибка» не связано с тем, что проблема была вызвана человеком, и вместо этого подразумевает, что дефект возник сам по себе, что привело к необходимости отказаться от термина «ошибка» в пользу таких терминов, как «дефект» с ограниченным успехом. Начиная с 1970-х годов Гэри Килдалл несколько юмористически предложил использовать термин «грубая ошибка».

В разработке программного обеспечения термин «метаморфизм ошибки» (от греческого meta = «изменение», morph = «форма») означает эволюции дефекта на заключительном этапе развертывания программного обеспечения. Преобразование «ошибки», совершенной аналитиком на ранних этапах жизненного цикла разработки программного обеспечения, которая приводит к «дефекту» на заключительной стадии цикла, было названо «метаморфизмом ошибки».

Различные этапы «ошибки» во всем цикле могут быть описаны как «ошибки», «аномалии», «сбои», «сбои», «ошибки», «исключения», «сбои», «сбои», «ошибки», » дефекты »,« инциденты »или« побочные эффекты ».

Предотвращение

Отрасль программного обеспечения приложила много усилий для сокращения количества ошибок. К ним относятся:

Типографические ошибки

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

Методологии разработки

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

Модульное тестирование включает в себя написание теста для каждой функции (модуля), которая программа для исполнения.

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

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

Разработка с открытым исходным кодом позволяет любому исследовать исходный код. Школа мысли, популяризированная Эриком С. Реймондом как закон Линуса, гласит, что популярное программное обеспечение с открытым исходным кодом имеет больше шансов иметь мало ошибок или совсем не иметь ошибок, чем другое программное обеспечение., потому что «при достаточном внимании к нему все ошибки мелкие». Однако это утверждение оспаривается: специалист по компьютерной безопасности Элиас Леви писал, что «легко скрыть уязвимости в сложном, малоизученном и недокументированном исходном коде», потому что «даже если люди просматривают код, это не означает, что они обладают достаточной квалификацией для этого «. Примером того, что это произошло случайно, была уязвимость 2008 OpenSSL в Debian.

Поддержка языков программирования

Языки программирования включают функции, помогающие предотвратить ошибки, такие как системы статических типов , ограниченное пространства имен и модульное программирование. Например, когда программист записывает (псевдокод) LET REAL_VALUE PI = "THREE AND A BIT", хотя это может быть синтаксически правильным, код не проходит проверку типа . Скомпилированные языки улавливают это без необходимости запускать программу. Интерпретируемые языки выявляют такие ошибки во время выполнения. Некоторые языки намеренно исключают функции, которые легко приводят к ошибкам, за счет более низкой производительности: общий принцип заключается в том, что почти всегда лучше писать более простой и медленный код, чем непостижимый код, который выполняется немного быстрее, особенно с учетом того, что обслуживание стоимость существенная. Например, язык программирования Java не поддерживает арифметику с указателем ; реализации некоторых языков, таких как Pascal и языков сценариев, часто имеют границы среды выполнения , проверяющие массивов, по крайней мере, в отладочной сборке.

Анализ кода

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

Инструментарий

Инструменты для мониторинга производительности программного обеспечения во время его работы, специально для поиска таких проблем, как узкие места, или для обеспечения уверенности в правильной работе, могут быть встроенными в код явным образом (возможно, так просто, как выражение PRINT «I AM HERE») или предоставлено в виде инструментов. Часто бывает неожиданностью обнаружить, где большую часть времени занимает фрагмент кода, и это удаление предположений может привести к переписыванию кода.

Тестирование

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

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

Отладка

Типичная история ошибок (GNU Classpath данные проекта). Новая ошибка, отправленная пользователем, не подтверждена. Как только он был воспроизведен разработчиком, это подтвержденная ошибка. Подтвержденные ошибки позже исправлены. Ошибки, относящиеся к другим категориям (невоспроизводимые, не будут исправлены и т. Д.), Обычно составляют меньшинство.

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

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

Однако даже с помощью отладчика обнаружение ошибок — это своего рода искусство. Нередко ошибка в одном разделе программы вызывает сбои в совершенно другом разделе, что особенно затрудняет отслеживание (например, ошибка в подпрограмме рендеринга графики , вызывающая файл I / O ошибка подпрограммы) в явно несвязанной части системы.

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

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

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

С 1990-х годов, особенно после катастрофы Ariane 5 Flight 501, возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода посредством абстрактной интерпретации.

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

Тест ошибок

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

• тест Siemens
• ManyBugs — тест на 185 ошибок C. в девяти программах с открытым исходным кодом.
• Defects4J — это тест на 341 ошибку Java из 5 проектов с открытым исходным кодом. Он содержит соответствующие исправления, которые охватывают множество типов исправлений.
• BEARS — это эталонный тест на ошибки сборки с непрерывной интеграцией с упором на ошибки тестирования. Он был создан путем мониторинга сборок из проектов с открытым исходным кодом на Travis CI.

Управление ошибками

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

Уровень серьезности

Уровень серьезности — это влияние ошибки на работу системы. Это может быть потеря данных, финансовая потеря, потеря репутации и потраченные впустую усилия. Уровни серьезности не стандартизированы. Воздействие различается в зависимости от отрасли. Сбой в видеоигре оказывает совершенно иное влияние, чем сбой в веб-браузере или системе мониторинга в реальном времени. Например, уровни серьезности ошибки могут быть такими: «сбой или зависание», «нет обходного пути» (что означает, что клиент не может выполнить данную задачу), «имеет обходной путь» (что означает, что пользователь все еще может выполнить задачу), «визуальный дефект »(например, отсутствующее изображение или смещенная кнопка или элемент формы) или« ошибка документации ». Некоторые издатели программного обеспечения используют более квалифицированные уровни серьезности, такие как «критический», «высокий», «низкий», «блокирующий» или «простой». Серьезность ошибки может быть отдельной категорией по отношению к ее приоритету для исправления, и эти две категории могут быть количественно определены и обработаны отдельно.

Priority

Приоритет определяет, где ошибка попадает в список запланированных изменений. Приоритет определяется каждым производителем программного обеспечения. Приоритеты могут быть числовыми, например от 1 до 5, или именованными, например, «критические», «высокие», «низкие» или «отложенные». Эти рейтинговые шкалы могут быть похожи или даже идентичны рейтингам серьезности, но оцениваются как комбинация серьезности ошибки с предполагаемыми усилиями по исправлению; ошибка с низким уровнем серьезности, которую легко исправить, может получить более высокий приоритет, чем ошибка средней степени серьезности, для исправления которой требуются чрезмерные усилия. Рейтинги приоритета могут быть согласованы с выпусками продукта, например «критический» приоритет, указывающий на все ошибки, которые необходимо исправить до следующего выпуска программного обеспечения.

Выпуски программного обеспечения

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

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

• Срок должен быть соблюден, а ресурсов недостаточно для исправления всех ошибок к указанному сроку.
• ошибка уже исправлена ​​в следующем выпуске, и она не имеет высокого приоритета.
• Изменения, необходимые для исправления ошибки, слишком дороги или затрагивают слишком много других компонентов, что требует серьезного тестирования.
• Можно подозревать или знать, что некоторые пользователи полагаются на существующее поведение с ошибками; предлагаемое исправление может ввести критическое изменение.
• Проблема находится в области, которая будет устаревшей в следующем выпуске; исправлять это не нужно.
• Это «не ошибка». Возникло недопонимание между ожидаемым и предполагаемым поведением, когда такое недопонимание не связано с путаницей, возникшей из-за недостатков дизайна или ошибочной документации.

Типы

В проектах разработки программного обеспечения — «ошибка» или «сбой» может быть введен на любом этапе. Ошибки возникают из-за упущений или недоразумений, допущенных командой разработчиков программного обеспечения во время спецификации, проектирования, кодирования, ввода данных или документации. Например, относительно простая программа для построения списка слов по алфавиту может не учитывать, что должно произойти, если слово содержит дефис. Или при преобразовании абстрактного дизайна в код кодировщик может непреднамеренно создать единичную ошибку и не отсортировать последнее слово в списке. Ошибки могут быть такими же простыми, как опечатка: имелось в виду «<» where a «>».

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

Концептуальные ошибки — это неправильное понимание разработчиком того, что должно делать программное обеспечение. Полученное программное обеспечение может работать в соответствии с пониманием разработчика, но не в соответствии с тем, что действительно необходимо. Другие типы:

Арифметика

• Деление на ноль.
• Арифметическое переполнение или потеря значимости.
• Потеря арифметической точности из-за округления или численно нестабильные алгоритмы.

Логика

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

Синтаксис

• Использование неправильного оператора, например выполнение присваивания вместо проверки равенства. Например, в некоторых языках x = 5 установит значение x равным 5, а x == 5 будет проверять, является ли x в настоящее время 5 или каким-либо другим числом. Интерпретируемые языки допускают сбой такого кода. Скомпилированные языки могут обнаруживать такие ошибки до начала тестирования.

Ресурс

• Нулевой указатель разыменование.
• Использование неинициализированной переменной.
• Использование в противном случае действительной инструкции для неправильного тип данных (см. упакованный десятичный / двоичный десятичный код ).
• Нарушения доступа.
• Утечка ресурсов, когда конечный системный ресурс (например, память или дескрипторы файлов ) исчерпываются из-за повторного выделения без освобождения.
• Переполнение буфера, при котором программа пытается сохранить данные за пределами выделенного хранилища. Это может привести или не привести к доступу нарушение или нарушение хранилища. Они известны как ошибки безопасности.
• Чрезмерная рекурсия, которая, хотя и логически допустима, вызывает переполнение стека.
• Ошибка использования после освобождения, где указатель используется после того, как система освободила память, на которую он ссылается.
• Ошибка двойного освобождения.

Многопоточность

• Тупик, когда задача A не может продолжаться до выполнения задачи B. заканчивается, но в в то же время задача B не может продолжаться до завершения задачи A.
• Состояние гонки, когда компьютер не выполняет задачи в порядке, заданном программистом.
• Ошибки параллелизма в критических секциях, взаимные исключения и другие особенности параллельной обработки. Время проверки — время использования (TOCTOU) — это форма незащищенной критической секции.

Взаимодействие

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

Коллективная работа

• Нераспространяемые обновления; например программист изменяет myAdd, но забывает изменить mySubtract, который использует тот же алгоритм. Эти ошибки смягчаются философией Не повторяйся.
• Комментарии устарели или неверны: многие программисты считают, что комментарии точно описывают код.
• Различия между документации и продукта.

Последствия

Объем и тип ущерба, который может вызвать программная ошибка, естественным образом влияют на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемые космические путешествия или автомобильная безопасность, поскольку недостатки программного обеспечения могут привести к травмам или даже смерти людей, такое программное обеспечение будет подвергаться гораздо более тщательной проверке и контролю качества, чем для Например, веб-сайт интернет-магазина. В таких приложениях, как банковское дело, где недостатки программного обеспечения могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также более важен, чем, скажем, приложение для редактирования фотографий. Технологическому центру Software Assurance НАСА удалось снизить количество ошибок до менее 0,1 на 1000 строк кода (SLOC ), но это не было сочтено возможным для проектов в мире бизнеса..

Помимо ущерба, причиненного ошибками, часть их стоимости связана с усилиями, вложенными в их исправление. В 1978 году Линц и др. показал, что в среднем по проектам 17% усилий по разработке вкладывается в исправление ошибок. Исследование, проведенное в 2020 году в репозиториях GitHub, показало, что медиана составляет 20 процентов.

Хорошо известные ошибки

Ряд программных ошибок стал широко известным, обычно из-за по степени серьезности: примеры включают крушения различных космических и военных самолетов. Возможно, самая известная ошибка — это проблема 2000 года, также известная как ошибка 2000 года, в которой опасались, что мировой экономический коллапс произойдет в начале 2000 года в результате того, что компьютеры думали, что это был 1900. (В конце концов, серьезных проблем не возникло.) Срыв в 2012 году на бирже был связан с одной такой несовместимостью между старым API и новым API.

В массовой культуре

• В романе 1968 года 2001: Космическая одиссея и соответствующем фильме 1968 года 2001: Космическая одиссея, бортовой компьютер космического корабля, HAL 9000, пытается убить всех членов экипажа. В последующем романе 1982 года 2010: Одиссея 2 и сопутствующем фильме 1984 года 2010 выясняется, что это действие было вызвано тем, что компьютер был запрограммирован двумя конфликтующими цели: полностью раскрыть всю свою информацию и сохранить в секрете истинную цель полета от экипажа; этот конфликт привел к тому, что HAL стал параноиком и, в конечном итоге, стал смертоносным.
• В американской комедии 1999 года Офисное пространство трое сотрудников пытаются использовать озабоченность своей компании исправлением компьютерной ошибки Y2K, заразив компьютер компании система с вирусом, который отправляет округленные пенни на отдельный банковский счет. Этот план имеет неприятные последствия, поскольку у самого вируса есть собственная ошибка, которая преждевременно отправляет большие суммы денег на счет.
• Роман 2004 года «Ошибка» Эллен Ульман описывает попытку программиста найти неуловимую ошибку в приложении базы данных.
• Канадский фильм 2008 года Control Alt Delete рассказывает о программисте в конце 1999 года, который пытается исправить ошибки в своей компании, связанные с годом Проблема 2000.

См. Также

• Анти-шаблон
• Программа вознаграждения за ошибку
• Удаление сбоя
• ISO / IEC 9126, которая классифицирует ошибку как дефект или несоответствие
• Классификация ортогональных дефектов
• Проблема с ипподромом
• Обзор РИСКОВ
• Индикатор программного дефекта
• Программная регрессия
• Программная гниль
• Автоматическое исправление ошибок

Ссылки

Внешние ссылки

• «Перечисление общих слабых мест »- экспертная веб-страница, посвященная ошибкам, на NIST.gov
• тип ОШИБКИ Джима Грея — другое er Тип ошибки
• Изображение «первой компьютерной ошибки» на Wayback Machine (архивировано 12 января 2015 г.)
• «Первая компьютерная ошибка! »- письмо от 1981 об ошибке Адмирала Хоппера
• «на пути к пониманию ошибок компилятора в GCC и LLVM «. Исследование ошибок в компиляторах 2016 г.