Деятельность по "идентификации проблем" часто выполняют Координаторы проблем. Однако бывает так, что персонал, изначально не вовлеченный в эту работу, например, специалисты по Управлению Мощностями, тоже может выявлять проблемы. Такие "находки" также следует регистрировать как проблемы.
Регистрационные детали проблем схожи с деталями инцидентов, но в случае проблемы не нужно включать в описание информацию о пользователе и т.д. Однако инциденты, связанные с конкретной проблемой, следует идентифицировать и соответствующим образом регистрировать. Ниже даются примеры случаев, когда могут быть идентифицированы проблемы:
? Анализ инцидентов показывает, что некоторый инцидент повторяется, возникает большое количество инцидентов или возникает негативная тенденция.
? Анализ инфраструктуры позволил определить ее слабые места, где могут произойти новые инциденты (возможно, это проводилось средствами Процессов Управления Доступностью и Управления Мощностями).
? Произошел серьезный инцидент, требующий структурного решения для предотвращения его повторения в будущем.
? Существует угроза срыва Уровня Услуг, согласованного с заказчиком (по показателям производительности, мощности ИТ-средств, затрат и т. д.)
? Нельзя установить связь между новыми инцидентами и уже известной проблемой или ошибкой.
? Нельзя установить связь между зарегистрированными инцидентами и любой из известных проблем или ошибок.
Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Необходимые для этого дополнительные ресурсы нужно обосновать с позиции издержек и выгод для организации. Например, определить области, которым требуется более действенная поддержка, и понять, насколько они важны для предоставляемых услуг.
Такая оценка может базироваться на "болевом показателе" инцидентов, в котором учитываются:
? издержки, которые несет бизнес из-за инцидентов;
? количество инцидентов;
? количество пользователей и бизнес-процессов, затронутых инцидентами;
? время и затраты на разрешение инцидентов.
Классификация и назначение
Проблемы можно классифицировать по областям (категориям). Классификация проблемы выполняется одновременного с анализом степени ее воздействия, т. е. уровня серьезности проблемы и ее влияния на услуги (срочность и степень воздействия). Вслед за этим проблеме присваивается приоритет, точно так же, как в Процессе Управления Инцидентами. Затем на основе результатов классификации за проблемой закрепляются ресурсы и персонал и определяется время, необходимое для ее решения.
Классификация проблемы включает в себя следующее:
? Категория: определение области, например, программное или аппаратное обеспечение;
? Степень воздействия на бизнес-процесс;
? Срочность: допустимая задержка в решении проблемы;
? Приоритет: показатель, объединяющий срочность, степень воздействия, риск и необходимые ресурсы;
? Статус: например, проблема, известная ошибка и т. д.
Классификация не является статичной, она может меняться на протяжении жизненного цикла проблемы. Например, наличие обходного решения или быстрого решения поможет снизить срочность проблемы, в то время как новые инциденты могут привести к усилению степени воздействия проблемы.
Расследование и диагностика
Расследование и диагностика являются итеративными фазами процесса, они неоднократно повторяются, каждый раз приближаясь все ближе к намеченному результату. Часто делаются попытки воспроизвести инцидент в условиях тестирования. Для решения проблемы могут потребоваться дополнительные знания, например, для анализа и диагностики проблемы можно привлечь специалистов из группы поддержки.
Проблемы возникают не только из-за программных или технических средств. Они могут быть вызваны ошибками в документации, ошибками персонала или процедурными ошибками, такими как выпуск неправильной версии программного обеспечения. Поэтому желательно включать описания процедур в Конфигурационную Базу Данных и проводить контроль их версий. В то же время многие ошибки связаны с компонентами ИТ-инфраструктуры.
После того как установлена причина проблемы, определены Конфигурационные Единицы или группы единиц, ее вызвавшие, установлена связь между Конфигурационной Единицей и инцидентом (инцидентами), становиться возможным определить Известную ошибку. После этого Управление Проблемами продолжит свою работу, выполняя функции контроля ошибок.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
В конце февраля 2009 года в продаже на Amazon появилось долгожданное устройство для чтения электронных книг Kindle 2. Это событие вызвало бурю негодов
Электронная читалка - вещь очень хрупкая. Если с ней обращаться не правильно - она может сломаться. Чтобы этого не случилось, нужно придерживаться лиш
Большинство книг в сети интернет распространяется в формате FB2 (Fiction Book). Этот формат очень удобен для чтения. Файлы, в нем созданные, отличаютс
Популярность электронных книг у читателей неуклонно растет. Для доказательства этого мы провели маленький эксперимент. Из 10 людей, читающих в метро,
Файлы формата FB2 часто можно увидеть среди огромнейшего разнообразия текстовых форматов. Такая высокая популярность объясняется его предназначением.
Первую версию формата PDF (Portable Document Format) еще в 1993 году разработала фирма Adobe Systems. В 2006 году она уже разработала версию 1.7, а с
Фирма Apple порадовала пользователей iPad, выпустив под него красивую и удобную читалку iBooks.