Марина спрашивает:
Подскажите, пжл, нужно ли разделять оперативное решение инцидента и полное решение инцидента? например: не формируется автоматически отчет (перестал работать функционал некой системы Х). например, пользователь может вручную создавать этот отчет (оперативное решение=обходной вариант), а исправление кода в системе Х (например, отчет не формируется из-за ошибки в коде) это уже полное решение инцидента? не смешиваются ли здесь понятия — решение проблемы?
Спасибо за ответ. Смущает меня следующее: все технические и логические ошибки РАВНО проблема (вопросов с операционными и ложными обращениями нет) В моем понимании, работает процесс, например, в системе Х выкладывается отчет ежедневно. Например, сегодня, отчет не выложился -> инцидент. Для меня, решением инцидента будет если в этой системе мой отчет выложится. причина – ошибка в коде, отчет не будет выложен, пока не уберут эту ошибку. Либо заплаточное решение мне подойдет, главное чтобы в системе Х появится мой отчет. И ВНИМАНИЕ! вводится еще временное(оперативное решение), например, мне вручную пришлют по почте этот отчет, либо какие-то данные, которые мне необходимы. А проблема, если например, несколько таких инцидентов произошло. В чем я заблуждаюсь?
т.е. полное решение инцидента – система Х сформирует мне отчет, оперативное решение – мне этот отчет кто-нибудь пришлет по альтернативному варианту
“отчет не будет выложен, пока не уберут эту ошибку”
Значит регистрация проблемы не потребуется. Если Вы смогли обойти ошибку, будет обработка проблемы. Наличие именно нескольких инцидентов для проблемы не требуется.
Это не значит, что я именно так и рекомендую делать всем компаниям. Пока это разговор про ITIL, разумеется в жизни будут и другие детали, которые влияют на решение. Люди, процессы, автоматизация.
я не понимаю логики разве не будет ДУБЛИРОВАНИЯ технического инцидента и проблемы? ) Очень прошу пояснить, поскольку хотелось бы окончально разобраться, казалось бы в простых понятиях. В моем понимании, есть стандартная процедура формирования отчета в системе Х и значит решение инцидента – когда эта стандартная процедура снова заработает как и раньше. почему обходной вариант приравнивается к решению инцидента? я допускаю, что не все инц-ты могут решаться, затратность и прочее, но сейчас не об этом )
Беда, в том, Марина, что все эти “простые понятия”, очень расплывчаты и некорректны.
Между инцидентом и поблемой не хватает прослойки: причины инцидента. Точнее проблема этой причиной и объявляется. Но правильнее было бы (с моей точки зрения) исходить из следующих понятий (упрощённо):
Инцидент – когда не выполняется какая-то функция, которая должна выполняться.
Причина инцидента – почему эта функция не выполняется (у похожих инцидентов, кстати, могут быть разные причины).
Проблема – часто повторяющаяся причина или причина возникновения часто повторяющихся причин (здесь мы строим причнно-следственные связи: каждая причина следствие другой причины…).
Тогда, возможно у вас всё станет на свои места.
Инцидент может быть решён (если устранена причина), либо решён обходным решением (причину не устранили). Если у вас будет какой-то признак способа решения, вы сможете держать в памяти такие инциденты.
Если какая-то причина всплывает слишком чато, то это уже попахивает проблемой, которую возможно стоит решать более кардинально.
Вот я тут рассуждал на эту тему немного, может что-то будет полезно http://pasol-711.livejournal.com/8832.html
Павел, в целом я с вами согласна, что такое инцидент и что такое проблема. Мне кажется логичнее ввести два типа решения у инцидента, + оставить понятие проблемы. НО нельзя превращать решение инцидента в решение проблемы, иначе золотое правило 20% проблем порождает 80% инцидентов не будет работать ) будет правило 80% проблем порождает 80% инцидентов (+еще 20%инцидентов)
по поводу типов решения инцидентов:
Оперативное решение инцидента – временное восстановление работы процесса/ИТ-услуги, не предусмотренное стандартным процессом.
Полное решение – восстановление работы процесса/ИТ-услуги (возврат к тому состоянию, который был изначально спроектирован).
Проблема – ваше определение проблемы, я с ним согласна
Если спускаться до уровня всяких классификаторов, то я бы разнёс эти два классификатора. Решён – это один из статусов. А Применено обходное решение – логический признак (чек-бокс, если опускаться ещё ниже до интерфейса).
Т.е. у нас инцидент остаётся открытым, с признаком применено обходнео решение. Т.е. он у нас висит. мы про него помним, но в принципе пока ситуацию как-то решили.
А потом, кстати. если инцидент долго висист с обходным решением, и не решается, можно из него и проблему породить. Чтобы разобраться а в чём же дело…
спасибо! наши мнения совпадают ))
Вход – потребность в отчете (триггер).
Выход – отчет.
Что происходит между этими двумя точками это вопрос нормального функционирования. Триггер сработал, а на выходе ничего нет – инцидент. “Управление инцидентами” что-то быстро сделало и после всех манипуляций отчет появился – инцидент закрыт. А вот в чем причина, как не допустить повторения инцидента – пусть “Управление проблемами” занимается.
Т.е. все инциденты в обязательном порядке должны пройти через управление проблемами? А штат управления проблемами раза эдак в два будет больше?
Отличный вариант 🙂
Один из вариантов обработки инцидента:
1. Уточнили что же на самом деле надо пользователю, чтобы он делом занялся, а не звонил по поддержкам.
2. Поискали в базе известных ошибок. Если нашли – привязали инцидент к ошибке, применили оптимальное обходное решение из описания ошибки.
3. Поискали в базе проблем. Если нашли – привязали инцидент к проблеме, применили, возможно не оптимальное, но актуальное обходное решение из описания проблемы.
4. Поискали в ранее закрытых инцидентах. Если нашли – пробуем применить решение из того инцидента. Помогло – как-то отмечаем, что при решении использован опыт из инцидента N.
5. Не нашли ничего похожего (кстати довольно редкое явление) решаем инцидент так, чтобы максимально быстро закрыть основную потребность пользователя.
«Управление проблемами» не плохо бы просмотреть инциденты из п. 4 и 5 – вдруг это первый звоночек к серьезной катастрофе.
А относительно штата управления проблем и инцидентов – они ведь очень часто пересекаются. Не на уровне менеджеров и координаторов, а на уровне исполнителей. Т.е. вполне вероятно, что один и тот же человек будет заниматься одной и той же ситуацией, только в рамках разных процессов. Т.е. сегодня он тушит пожар, а завтра разбирается в причинах, расставляет огнетушители.
Если вы не выяснили причину, то в 2, 3 и 4 вы возможно найдёте совсем не то, что нужно.
Пример:
Пользователь: “У меня не формируется отчёт”.
В известных ошибках вы находите: “Не формируется отчёт”. И связываете инцидент с этой ошибкой. В ожидании решения ошибки предлагаете пользователю формировать отчёты силами администратора.
Но! У пользователя не формируется отчёт потому-что у него недостаточно прав. А ошибка связана с тем, что не хватает производительности рабочей станции.
Если вы не смотрите на причины, то вы сильно рискуете ошибиться.
самый главный вопрос: КАК появился этот отчет? если пользователь ВРУЧНУЮ его составляет, а должна база это делать, что это РЕШЕНИЕ инцидента? Я вот считаю что это обходной путь, временная заплатка, пока инцидент не разрешится (НЕ ПРОБЛЕМА), т.е. РЕШЕНИЕ ИНЦИДЕНТА = вернуться в то состояние, когда отчет формировался автоматически..
Тут от требований заказчика зависит как мне кажется:
Если я как заказчик требую услугу Беспроводной интернет, то факт неисправности роутера и замены его соединением проводным для меня не является востановлением услуги, снижением степени влияния, да, но не востановлением… такой инцидент я никогда не позволю закрыть.
В свою очередь если я требую услугу интернет, то факт неисправности роутера и подключение меня к проводному соеденению востанавливает доступ в интернет и инцидент можно считать закрытым… Пускай там проблем дальше разбирается…
Договориться “какой нам интернет нужен” при этом можно через умные документы типо SLR.. и зафиксировать эти договоренности в SLA.
С отчетностью тоже самое…
Если заказчик требует автоматическое формирование отчёта, то ручной механизм лишь снижает влияние инцидента, но не устраняет его.
Если слово автоматическое отсутсвует, то ручной механизм закрывает инцидент… А дальше пусть проблем разбирается.
Тут вопрос скорее внутренний, приплетать сюда заказчика, по моему мнению, не стоит.
Вот, например, мне вообще не важно заводит мой провайдер инциденты, транслирует ли в проблемы, учитывает ли изменения, ведёт ли CMDB. Мне важно, что интернет у меня пявился через 5 минут после звонка в техподдержку, а лучше бы вообще не пропадал.
Мне как заказчику тоже не важна внутренняя кухня. Но для меня принципиально, что если мне нужен беспроводной интернет и мы договорились с ИТ, что они его предоставляют. То замена беспроводного интернета, проводным не будет для меня и главное для ИТ решением инцидента и нужно продолжать бегать и тушить пожар, даже если он стал не столь интенсивным.
Если для меня важно, что интернет у меня появился через 5 минут и не важно, какой это будет интернет… то это уже другие договорённости.
Принимать решения, что является восстановлением согласованного уровня услуги, без привлечения заказчика, приводит к риску негатива.
Это лишь один из подходов к закрытию инцидента…
Привлечение заказчикам к подобным аспектам внутренней кухни, бывает очень продуктивно… Первый шаг к SLM если хотите…
Из опыта реальных проектов.
Один из главных вопросов обсуждения и согласования с Заказчиком на этапе проектирования – это порядок закрытия инцидента. Особенно связанного с неработоспособностью ПО. Ведь здесь ещё возникает Управление изменениями…
Дмитрий, объясните, пожалуйста, в чем преимущества закрытия инцидентов с обходным решением и открытия проблемы?
Я такого никогда не утверждал 🙂 Попробую коротко объясниться, бо ситуация мне кажется довольно простой (хотя по обилию комментариев и не скажешь):
1. Есть два основания для реактивной регистрации проблем: непосредственно по факту закрытия инцидента и по итогам анализа инцидентов за период.
2. Когда Вы решаете инцидент, критерий не в том, какое решение предпочесть (обходное или постоянное), а в том, чтобы решить инцидент как можно быстрее. На практике бывают ситуации, когда инцидент не решить, не устранив причины (например, не выполняется расчёт премий по целевым показателям из-за ошибки в реализации алгоритма в SAP HR, она известна, её надо устранить). Бывает, конечно и наоборот. И тогда работает пункт 3.
3. Если Вы, закрывая инцидент, знаете, что ошибка выявлена, но не устранена (применено обходное решение), по факту закрытия инцидента регистрируется проблема – чтобы устранить ошибку. Например, не выполнялась операция из-за логической ошибки в таблице БД. Таблицу поправили вручную, операция прошла, но почему закривели данные? Вероятно из-за ошибки в реализации других операций. Это может случиться снова, и последствия могут быть уже более глобальными. В этом случае имеем регистрацию проблемы по факту единичного инцидента (даже если он – не критичный). Держать в этом случае открытый инцидент до устранения ошибки – некорректно, поскольку процесс управления инцидентами не умеет управлять такими работами. Для этого специально существует другой процесс – управления проблемами, с другой логикой организации, сроками, ответственными.
4. Если Вы, закрывая инцидент, полагаете, что ошибка устранена, и инцидент некритичный, проблему по факту закрытия инцидента регистрировать не нужно – нет смысла (критичные инциденты – отдельная история, но об этом отдельно). Это, к слову, совсем не значит, что проблема по этому инциденту не будет зарегистрирована по итогам периода, потому что Вы не можете знать, является ли устранённая Вами причина корневой (на самом деле никогда не знаете, но это тоже отдельная тема). Например, отказала точка доступа WiFi. Заменили, инцидент закрыли. Через месяц отказала и новая точка WiFi, и так далее. По итогам повторяющегося отказа зарегистрировали проблему. В ходе анализа выяснили, что корневая причина – некачественное электропитание.
5. Критичный инцидент (даже один) ВСЕГДА рекомендуется связывать с проблемой – новой или существующей. В идеале система автоматизации не должна дать возможность закрыть критичный инцидент без связи с проблемой. Это важно, поскольку, как показано в пункте 4, даже если мы полагаем, что причина устранена, это может быть неверно (мы не можем этого знать, процесс управления инцидентами по своему дизайну не даёт ответа на этот вопрос). А повторения критичных инцидентов (глобальные отказы критичных ИС) нам точно не хотелось бы.
6. Во всех случаях, как только услуга пользователю восстановлена (что бы под этим ни подразумевалось в каждом конкретном случае), инцидент закрывается – область ответственности процесса управления инцидентами заканчивается.
Уф, устал писать…
а вас не смущает, что ВСЕ инц-ты с логическими и техническими ошибками пойдут в проблемы? и тогда наглядности в проблемах не будет.. т.к. в вашем случае будут проблемы, которые должны решать инциденты (и тогда непонятен смысл решения инцидента), а есть, которые будут предотвращать их появление. Т.е. сопоставление кол-во инц-тов и кол-во проблем будет примерно одинаковым. но ведь это неправильно!!!!
“а вас не смущает, что ВСЕ инц-ты с логическими и техническими ошибками пойдут в проблемы?”
Нет, Марина, меня это абсолютно не смущает. По двум причинам:
1. Это никак не следуют из того, что я написал. Далеко не по всем инцидентам появится регистрация проблем.
2. Обычно (на практике) сложность с процессом управления проблемами обратная – на входе недостаточно проблем, процесс простаивает или работает очень вяло. Поэтому на практике всегда приходится решать задачу создания потока проблем (и для этого есть понятные методы), тем более – потока важных, значимых проблем (вместо всякой мелочёвки, которая легко используется для “надувания” отчётности без особой пользы для организации).
Так что – нет, ни разу не смущает 🙂
“в вашем случае будут проблемы, которые должны решать инциденты”
Вот в частности этого не будет НИКОГДА, и это прямо следует из текста, который я написал. Пожалуйста, читайте внимательней.
“не смешиваются ли здесь понятия — решение проблемы?”
Смешивается. Поэтому обычно это делается в рамках процесса управления проблемами. Вас чем-то смущает такой вариант?