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

Проблемы и известные ошибки

Интересную задачку нам предложили некоторое время назад в разделе "Задать вопрос": 

Расскажите пожалуйста преимущества (пользу) и недостатки (затраты) вариантов:

1. Известная ошибка это статус проблемы и тогда в системе автоматизации один объект.

2. Известная ошибка и проблема это 2 отдельных объекта.

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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 17

  • О, какая тема, спасибо! Меня этот вопрос тоже занимал одно время, даже с Маартеном по этому поводу имел обстоятельную дискуссию. Сейчас могу твердо сказать, что принципиальной разницы нет. Но дьявол в мелочах – в системах, где объект один, надо проверять адекватность механизмов контроля проблем в состоянии "известная ошибка" и наличие связей проблем с базой знаний. Что же касается правильного распределения ответственности на этапах Problem Control и ErrorControl, его можно достичь и на объектах "Проблема" (например, за счет использования связей между проблемами).

    • ITSM вопрос

      Спасибо. А как быть в ситуации проактива, когда инцидентов еще небыло, мы нашли уязвимость (известную ошибку), и теперь ее надо ErrorControl, т.е этап Problem Control отсутствует?

      А еще, может ли известная ошибка быть корнем разных проблем, и если да, то как увязывать одну ошибку с разными проблемами в случае одного объекта?

      PS: система SM 9.x

      • Спасибо. А как быть в ситуации проактива, когда инцидентов еще небыло, мы нашли уязвимость (известную ошибку), и теперь ее надо ErrorControl, т.е этап Problem Control отсутствует?

        Так ведь если в системе объект один (Problem), то Known error – это просто его состояние. Поэтому ничего не мешает зарегистрировать известную ошибку посрелством регистрации объекта Problem в состоянии Known error.

        А еще, может ли известная ошибка быть корнем разных проблем, и если да, то как увязывать одну ошибку с разными проблемами в случае одного объекта?

        Опять же – связями между проблемами.

        • Pavel Solopov

          А если по результатам разбирательств с проблемой было обнаруженно несколько ошибок, которые было решено причислить к известным?

          • Опять же – несколько проблем со связями.

            • Pavel Solopov

              Т.е. проблемы порождённые проблемой получатся или с чем связи?

              • Да.

                • Pavel Solopov

                  Не очень хорошо получается. Получится, что часть проблем будут сами "превращаться" в ИО (известная ошибка 🙂 ), другие же будут с этими ИО связаны…
                  Может возникнуть путаница, будем потом разбираться, что есть что и как всё это фильтровать…

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

                  • Может возникнуть путаница, будем потом разбираться, что есть что и как всё это фильтровать…

                    Мне кажется Вы усложняете. Если KE это состояние проблемы, то путаницы "Получится, что часть проблем будут сами "превращаться" в ИО, другие же будут с этими ИО связаны…" быть не может. На практике все проще 🙂

                    • Pavel Solopov

                      Мне кажется Вы упрощаете. 🙂
                      Две ситуации:

                      1. Выявли проблему, разобрались, оказалось, что причина в некой системной ошибке, которую устранить не представляется возможным. Проблему перевели в статус ИО (или КЕ, КЕ=ИО, так же?).

                      2. Выявили проблему, стали разбираться, выяснили, что причина проблемы две системных ошибки, которые решить не представляется возможным. Создали две связаных проблемы, перевели их в статус ИО. А что делать с той проблемой, из которой эти две ошибки создали?

                      Пока писал ещё подумал, что по хорошему нужна какая-то методика определеня как дифференцировать ошибки, как понять одна ошибка или несколько?

                       

      • А вот что менее тривиально, это разные механизмы определения сроков обработки для проблем и известных ошибок. Но и это решается (или по крайней мере может быть решено) на одном объекте.

    • Grigory Kornilov

      Проблемы сервиса могут считаться внутренней сущностью сервисного подразделения и быть не доступны пользователям.

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

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

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

       

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

        Это немного натянутая аналогия, поскольку в KB Microsoft есть далеко не только KE, но и рекомендации "как настроить", и даже ответы на вопросы "где скачать", и так далее. И то, что KB (да еще и публичная) строится не на базе данных проблем, конечно, логично.

        Если же мы строим публикацию именно KE (тем более для внутреннего употребления), ничего не мешает нам сделать в объекте Проблема поле [Описание KE] и публиковать список проблем с заданным набором полей (включая описание из поля [Описание KE]) с фильтром по состоянию / признаку "Известная ошибка". И будет нам KEDB без деления на два объекта.

        P.S. На всякий случай оговорюсь еще раз: я НЕ призываю делить или не делить объекты "Проблема" и "Известная ошибка". Я лишь утверждаю (как и писал выше), что "принципиальной разницы нет" – и с делением, и без деления можно построить нормальный процесс. А сложности с реализацией этого процесса на практике почти на 100% связаны с мотивацией (поскольку у этого процесса нет явных триггеров вне поставщика ИТ-услуг, за исключением продуктовых компаний), а не с технологией учета.

        • Анна Лобова

          Дмитрий, добрый день! Подскажите, пожалуйста, если было принято управленческое решение оставить проблему быть и всегда применять обходное решение (как в книге "Иллюстрированный ИТСМ" приведен пример про проблему с ошибкой в документации по ИТСМ..), то верно ли я понимаю, что проблема просто так и остается в базе навсегда висеть в статусе "Известная ошибка" и все.

          Если да, то верно ли я предполагаю, что имеет смысл сделать какой-то атрибут, чтобы разделить ИО, которые мы планируем решать и которые реально нужно мониторить, перебирать, осознавать и шевелиться от тех, которые не нужно показывать в отчетах типа "Изветные ошибки, требующего нашего внимания"? Спасибо!

        • Анна Лобова

          Забыла еще есть вопрос: пожалуйста, посоветуйте какие нужны атрибуты (поля в форме) для известных ошибок? Я планирую известные ошибки делать просто статусом проблемы для чего в форме проблемы будут поля "Корневая причина" / "Обходное решение". А какие еще нужны поля? КЕ тоже планируется что будут привязаны к проблеме.

  • Pavel Solopov

    На самом деле чтобы обсуждать один объект или не один, надо сначала договориться что мы имеем в виду под объектом.
    Если Объект это запись в БД, то разговор не имеет смысла, поскольку некоторые системы позволяют реализовывать всё что угодно на одном объекте, т.е. утрировано есть всего одна таблица, а видимость или не видимость каких-то атрибутов определяется интерфейсом.

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

  • Роман Выходов

    В нашей компании "Известная ошибка" – это признак у объекта Проблема. Когда найдена корневая причина и обходное решение, мы устанавливаем галочку "Известная ошибка". Нам такой подход очень удобен.


Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM