Рисунок 6.3- Контроль ошибок.

6.7.1 Идентификация и запись ошибок.

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

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

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

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

6.7.2 Оценка ошибок.

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

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

Ошибки в продуктах внешних поставщиков.

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

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

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

Контроль ошибок в программной среде.

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

Рисунок 6.4 - Цикл ошибки в среде эксплуатации и в среде разработки.

Ошибки, найденные во время работы, приводят к накоплению Запросов на Изменение. Стратегия выпуска Релизов (см. главу 9 - «Управление релизами») предусматривает создание окончательного Релиза с внесенными в систему авторизованными Изменениями. Разработчики должны знать обо всех Известных ошибках и Проблемах, которые связаны с пакетным Релизом. Им следует удалять учетные записи об Известных ошибках и добавлять их в базу данных исправленных ошибок (или в CMDB) по мере их исправления. По ходу разработки они находят новые ошибки, которые также заносятся в эту базу данных.

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

6.7.3 Запись об устранении ошибок.

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

6.7.4 Закрытие ошибки.

После успешного внедрения Изменений по устранению ошибки соответствующие записи об Известной ошибке закрываются вместе со всеми связанными записями об Инцидентах и Проблемах. Требуется рассмотреть необходимость введения в процесс промежуточного статуса для записей об Инцидентах, Известных ошибках и Проблемах, такого как «Закрыт, ожидание PIR» для подтверждения, что все действия по устранению ошибок действительно завершены успешно. После этого Анализ результатов внедрения (Post-Implementation Review, или PIR) может подтвердить эффективность решения перед окончательным закрытием.

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

6.7.5 Мониторинг Проблем и прогресса разрешения ошибок.

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

Управление проблемами должно наблюдать за долгосрочным влиянием Проблем и Известных ошибок на услуги, предоставляемые Пользователям. В случае, если влияние становится значительным, Управление проблемами проводит эскалацию Проблемы, возможно, с помощью Консультативного комитета по изменениям (Change Advisory Board, CAB) для того, чтобы увеличить приоритет RFC, или для внедрения срочного Изменения, в зависимости от необходимости.

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

6.7.6 Советы по контролю ошибок.

Следует помнить следующие моменты по отношению к контролю ошибок:.

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

■ Подготовка RFC - одна из обязанностей контроля ошибок. Разрешения часто находятся в ходе технической настройки. Не забудьте, что эти Запросы на Изменение могут также нуждаться в изменениях процедур, методов работы и/или организационных структурах.

■ Рассмотрите возможность создания стандартных учетных записей ошибок для конкретных устройств (УЭ) или для категорий устройств, для записи рутинных отказов аппаратного обеспечения. Используйте их для поддержки краткого справочника по показателям отказов - хотя большая часть информации, как, например, среднее время между сбоями (Mean Time Between Failures, MBTF) и время простоя, предоставляется на основе данных об Инцидентах.

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

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

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