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

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

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

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

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

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

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

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

Комментариев: 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-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT