Интересную задачку нам предложили некоторое время назад в разделе "Задать вопрос": 
Расскажите пожалуйста преимущества (пользу) и недостатки (затраты) вариантов:
1. Известная ошибка это статус проблемы и тогда в системе автоматизации один объект.
2. Известная ошибка и проблема это 2 отдельных объекта.
Любой, кто участвовал в построении процесса управления проблемами, наверняка, размышлял о разных вариантах реализации такого объекта, как известная ошибка. Поделитесь своим мнением, коллеги!
Спасибо. А как быть в ситуации проактива, когда инцидентов еще небыло, мы нашли уязвимость (известную ошибку), и теперь ее надо ErrorControl, т.е этап Problem Control отсутствует?
А еще, может ли известная ошибка быть корнем разных проблем, и если да, то как увязывать одну ошибку с разными проблемами в случае одного объекта?
PS: система SM 9.x
Спасибо. А как быть в ситуации проактива, когда инцидентов еще небыло, мы нашли уязвимость (известную ошибку), и теперь ее надо ErrorControl, т.е этап Problem Control отсутствует?
Так ведь если в системе объект один (Problem), то Known error – это просто его состояние. Поэтому ничего не мешает зарегистрировать известную ошибку посрелством регистрации объекта Problem в состоянии Known error.
А еще, может ли известная ошибка быть корнем разных проблем, и если да, то как увязывать одну ошибку с разными проблемами в случае одного объекта?
Опять же – связями между проблемами.
А если по результатам разбирательств с проблемой было обнаруженно несколько ошибок, которые было решено причислить к известным?
Опять же – несколько проблем со связями.
Т.е. проблемы порождённые проблемой получатся или с чем связи?
Да.
Не очень хорошо получается. Получится, что часть проблем будут сами "превращаться" в ИО (известная ошибка 🙂 ), другие же будут с этими ИО связаны…
Может возникнуть путаница, будем потом разбираться, что есть что и как всё это фильтровать…
Ещё такой вот момент, есть такой вариант, что жизнь проблемы не закончится, на том, что мы классифицируем её как ИО. Мы можем продолжить работать над ней, и в конце концов решить.
Каким либо способом, т.е. проблема у нас перейдёт в статус Решена, но ИО при этом может остаться, т.е. её сатус никак не изменится.
Поэтому я бы разделял Проблму и ИО как разные сущности, имеющие самостоятельный жизненый цикл.
Может возникнуть путаница, будем потом разбираться, что есть что и как всё это фильтровать…
Мне кажется Вы усложняете. Если KE это состояние проблемы, то путаницы "Получится, что часть проблем будут сами "превращаться" в ИО, другие же будут с этими ИО связаны…" быть не может. На практике все проще 🙂
Мне кажется Вы упрощаете. 🙂
Две ситуации:
1. Выявли проблему, разобрались, оказалось, что причина в некой системной ошибке, которую устранить не представляется возможным. Проблему перевели в статус ИО (или КЕ, КЕ=ИО, так же?).
2. Выявили проблему, стали разбираться, выяснили, что причина проблемы две системных ошибки, которые решить не представляется возможным. Создали две связаных проблемы, перевели их в статус ИО. А что делать с той проблемой, из которой эти две ошибки создали?
Пока писал ещё подумал, что по хорошему нужна какая-то методика определеня как дифференцировать ошибки, как понять одна ошибка или несколько?
А вот что менее тривиально, это разные механизмы определения сроков обработки для проблем и известных ошибок. Но и это решается (или по крайней мере может быть решено) на одном объекте.
Проблемы сервиса могут считаться внутренней сущностью сервисного подразделения и быть не доступны пользователям.
Однако Know issues может быть публикуем, для того, чтобы пользователь их видел, мог соотнести симптому своего инцидента, применять доступный ему workaround (в том числе и определенный тип обращений к сервисному подразделению).
В такой ситуации описание проблемы и описание know issues будут отличаться и по содержанию и по уровню видимости. Это повод для многих их разделять на разные сущности и даже хостить в разных учетных системах.
Например публикация известных ошибок по пробуктам компании Microsoft, например в виде KB. Врятли это можно назвать статусом объекта Проблема, хотя не буду спорить, что в MS существует учет Проблем по продукту и ссылка на связанные KB есть свойство объекта Проблема.
Например публикация известных ошибок по пробуктам компании Microsoft, например в виде KB. Врятли это можно назвать статусом объекта Проблема, хотя не буду спорить, что в MS существует учет Проблем по продукту и ссылка на связанные KB есть свойство объекта Проблема.
Это немного натянутая аналогия, поскольку в KB Microsoft есть далеко не только KE, но и рекомендации "как настроить", и даже ответы на вопросы "где скачать", и так далее. И то, что KB (да еще и публичная) строится не на базе данных проблем, конечно, логично.
Если же мы строим публикацию именно KE (тем более для внутреннего употребления), ничего не мешает нам сделать в объекте Проблема поле [Описание KE] и публиковать список проблем с заданным набором полей (включая описание из поля [Описание KE]) с фильтром по состоянию / признаку "Известная ошибка". И будет нам KEDB без деления на два объекта.
P.S. На всякий случай оговорюсь еще раз: я НЕ призываю делить или не делить объекты "Проблема" и "Известная ошибка". Я лишь утверждаю (как и писал выше), что "принципиальной разницы нет" – и с делением, и без деления можно построить нормальный процесс. А сложности с реализацией этого процесса на практике почти на 100% связаны с мотивацией (поскольку у этого процесса нет явных триггеров вне поставщика ИТ-услуг, за исключением продуктовых компаний), а не с технологией учета.
Дмитрий, добрый день! Подскажите, пожалуйста, если было принято управленческое решение оставить проблему быть и всегда применять обходное решение (как в книге "Иллюстрированный ИТСМ" приведен пример про проблему с ошибкой в документации по ИТСМ..), то верно ли я понимаю, что проблема просто так и остается в базе навсегда висеть в статусе "Известная ошибка" и все.
Если да, то верно ли я предполагаю, что имеет смысл сделать какой-то атрибут, чтобы разделить ИО, которые мы планируем решать и которые реально нужно мониторить, перебирать, осознавать и шевелиться от тех, которые не нужно показывать в отчетах типа "Изветные ошибки, требующего нашего внимания"? Спасибо!
Забыла еще есть вопрос: пожалуйста, посоветуйте какие нужны атрибуты (поля в форме) для известных ошибок? Я планирую известные ошибки делать просто статусом проблемы для чего в форме проблемы будут поля "Корневая причина" / "Обходное решение". А какие еще нужны поля? КЕ тоже планируется что будут привязаны к проблеме.
На самом деле чтобы обсуждать один объект или не один, надо сначала договориться что мы имеем в виду под объектом.
Если Объект это запись в БД, то разговор не имеет смысла, поскольку некоторые системы позволяют реализовывать всё что угодно на одном объекте, т.е. утрировано есть всего одна таблица, а видимость или не видимость каких-то атрибутов определяется интерфейсом.
Или рассуждение идёт на более высоком уровне концептуальном уровне, и вопрос в том являются ли проблема и известная ошибка о разными сущностями или "известная ошибка" это всего лишь одно из состояний "проблемы".
В нашей компании "Известная ошибка" – это признак у объекта Проблема. Когда найдена корневая причина и обходное решение, мы устанавливаем галочку "Известная ошибка". Нам такой подход очень удобен.
О, какая тема, спасибо! Меня этот вопрос тоже занимал одно время, даже с Маартеном по этому поводу имел обстоятельную дискуссию. Сейчас могу твердо сказать, что принципиальной разницы нет. Но дьявол в мелочах – в системах, где объект один, надо проверять адекватность механизмов контроля проблем в состоянии "известная ошибка" и наличие связей проблем с базой знаний. Что же касается правильного распределения ответственности на этапах Problem Control и ErrorControl, его можно достичь и на объектах "Проблема" (например, за счет использования связей между проблемами).