Управление инцидентами Archives – Страница 13 из 16

Влияние сбоев на ИТ-услуги

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

Евгений Шилов, 1 июля 2012, последний комментарий 5 июля 2012

Управление черными ящиками

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

Роман Журавлёв, 13 июня 2012, последний комментарий 16 июня 2012

Доска аварий

Много раз уже слышали от различных Заказчиков "хотелку" под условным названием "доска аварий". Звучит она так: хотим, чтобы можно было быстро и наглядно увидеть инфраструктурные инциденты, которые еще оказывают влияние на предоставляемые ИТ-услуги. Цель понятна: хочется иметь перед глазами краткий снимок инфраструктуры, на котором видны все проблемные области, для того чтобы быстро принимать решения о возможных причинах инцидентов, использовать эту информацию при диагностике, ответах звонящим пользователям и т.д. Идея прекрасная, но смущает меня в ней следующее: влияние инфраструктурных инцидентов на ИТ-сервисы в каждом конкретном случае – вещь требующая вдумчивой оценки (иногда быстрой, иногда нет). Влияние может быть отложенным, влияние может…

Евгений Шилов, 30 мая 2012, последний комментарий 27 июня 2012

Допрос с пристрастием

На днях меня попросили показать примеры вопросов, которые можно задавать пользователям для оценки их удовлетворенности итогами решения инцидента. То есть по итогам решения инцидента пользователь не просто должен сказать: "да работает/нет не работает", а дать "развернутый" ответ о том, как все прошло и насколько он счастлив. Я решил заодно и на портале упомянуть эту тему и важные моменты: Нужно точно понимать, зачем проводится опрос, какие выводы предполагается сделать. Только так можно подобрать правильные вопросы и понять как затем обрабатывать ответы. Вопросов не должно быть много (2-3 достаточно) иначе есть риск вообще не получить ответов или получить случайные ответы Пользователя не…

Евгений Шилов, 14 мая 2012, последний комментарий 22 мая 2012

Смотрим на инциденты расширенными глазами

Хочу написать про еще одну технику управления рисками, незаслуженно забытую в книгах ITIL V3 2007 года, но восстановленную ("по чертежам" ITIL V2) в прошлогоднем обновлении. Я говорю о расширенном жизненном цикле инцидента (the Expanded Incident Lifecycle). Это раздел в описании процесса управления доступностью (Availability Management), где предлагается разделять каждый инцидент (незапланированный перерыв в нормальном предоставлении ИТ-услуг) на обязательные последовательные этапы. Момент возникновения инцидента, то есть, момент, когда пользователь ощутил снижение качества ИТ-услуги Обнаружение, то есть промежуток времени от возникновения до момента получения поставщиком ИТ-услуг информации об инциденте Диагностика, то есть время на поиск причины инцидента Исправление, то есть время на…

Константин Нарыжный, 2 мая 2012, последний комментарий 3 мая 2012

Оценка влияния инцидента

Ну наконец-то выходные и можно спокойно написать пару мыслей. Не раз уже обсуждали на семинарах проектирования подход к оценке уровня влияния инцидентов, поступающих от пользователей. Обычно влияние сказывается на приоритетах и нормативных сроках решения инцидентов, поэтому оценить влияние на начальном этапе чрезвычайно важно. Но, вспоминая, что на первой линии нам обычно доступны только сами пользователи с их суждениями о сложившейся ситуации, а объем диагностической информации минимален, приходится придумывать вопросы, которые специалист первой линии может задать пользователю и на основании ответов оценить влияние. К вопросам предъявляется ряд требований: пользователи могут дать ответ трактовка более-менее однозначна вопросов не много (обычно 2-4) Традиционную схему, которую часто приводят…

Евгений Шилов, 29 апреля 2012, последний комментарий 9 мая 2012

Семь преимуществ KEDB

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

Героизм в ITIL V3: борьба с инцидентами

На очередном курсе у крупного системного интегратора, слушатели смогли найти в ITIL V3 очередное противоречие. Их находкой хочу поделиться. Итак: два понятия.

Константин Нарыжный, 13 апреля 2012, последний комментарий 23 февраля 2016

Вопрос из зала: Обходное решение проблемы или типовое решение инцидента?

Владимир спрашивает: И снова о проблемах… в продолжении последнего семинара Евгения Шилова. Утрировано рассмотрим ситуацию с ошибкой в книге ITILv3 2007. В Книге в двух местах дано разное определение термина проблема. Из-за этого на экзаменах люди допускают ошибки и не набирают соответствующий бал. Проблемой в данном случае является ошибка в книге. Инцидентом низкий бал на экзамене. Решением инцидента является апелляция, результатов экзамена. Обходным решением проблемы является исключение из экзамена вопросов связанных с ошибкой. Структурным решением является переиздание книг. Вопросы: Может ли проблем менеджмент предложить в качестве обходного решение каждый раз писать апелляцию (допустим раньше инцидент решался просто повторной сдачей экзамена…

Вопрос из зала, 12 апреля 2012, последний комментарий 17 апреля 2012

Вопрос из зала: Нужно ли разделять оперативное и полное решение инцидента

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

Вопрос из зала, 1 апреля 2012, последний комментарий 6 апреля 2012

Самостоятельная классификация обращений

Ситуация: 1. Очень большая доля обращений (порядка 60%) относится к вопросам, касающихся функционирования специфических ИТ-систем. 2. Компетенции первой линии точно не хватит, чтобы решить хотя бы малую часть из таких обращений. И даже не решить, а грамотно пообщаться с заявителем. 3. Порядка 70% обращений поступает через портал и e-mail, остальное – по телефону. 4. Очень небольшое количество человек на первой линии, и нет возможности добавить персонал (в том числе и за счёт организации распределённой первой линии со специализацией сотрудников). 5. Пользователи «натренированы» не звонить, а обращаться через портал или e-mail, более-менее грамотно описывать симптомы и прикладывать скриншоты . Решение: Позволить пользователям…

Михаил Тобурдановский, 29 марта 2012, последний комментарий 2 апреля 2012

Портал №1 по управлению цифровымии информационными технологиями

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

Портал №1 по управлению цифровыми
и информационными технологиями