Одной из наиболее интересных задач для команды наших инженеров-проектировщиков было построения единого «дерева неисправностей» для крупной корпоративной информационной системы мониторинга оборудования.
В данной статье хочу поделиться нашим опытом, возможно кому-то будет интересно.
Постановка задачи
Информационная система, в которую мы встраивали данный классификатор, выполняет централизацию информации об авариях на самом разнообразном оборудовании, а также собирает данные о различных проблемных ситуациях из совершенно разнородных систем, баз данных и устройств. Понятно, что первичные аварийные сообщения в такой архитектуре будут абсолютно разнообразны. Например 3 различные внешние внешние системы посылали нам неисправность «обрыв», но в одном случае это был обрыв несущего троса в подвеске контактной сети, в другом обрыв электропитания, а в третьем пропадание связи между абонентами. Данная ситуация нас не устраивала, так как от нас требовалась четкая классификация, для последующего использования в отчетно-аналитических задачах.
Наш обработчик аварий при нахождении новых типов поступающих событий просто добавлял их в справочник и к моменту начала работ по систематизации только типов сообщений накопилось более 1000.
Мы поставили себе следующие цели:
- убрать синонимы — объединить записи, имеющие абсолютно одинаковый смысл, но разное написание;
- выработать единую иерархическую структуру классификации, в которую мы смогли бы «уложить» неисправности любой природы;
- упростить дальнейшее развитие (детализацию) данной классификации за счет определения четких и непротиворечивых принципов ее построения.
Мы стремились и к тому, чтобы характерными чертами нашей классификации стали:
- общеприменимость, возможность использования в других наших проектах и продуктах;
- простота и интуитивная понятность, позволяющая легко развивать данную структуру и находить «положенное место» новым неисправностям;
- убедительность, возможность доказать данному и потенциальным заказчикам автоматизации нашу правоту — дело в том, что наша система охватывала автоматизацией деятельность сразу нескольких крупных организационных подразделений в каждом из которых был принят свой собственный подход к данному вопросу.
Ход работ и наши ошибки
Вскоре после начала работ стало ясно, что выработка принципа классификации это ключевая задача всей темы. Взять за основу какую либо из классификаций приходящих из внешних систем не удавалось по следующим причинам:
— узкость общей направленности оценок в силу специфичности задач решаемых конкретными системами,
— отсутствие во многих случаях иерархии проблем (плоские списки неисправностей не построенные в древовидные структуры),
— запутанность формулировок, смешивание в одних позициях причин и последствий.
Первую версию мы создавали на основе группировки по инфраструктурным объектам на которых возникали данные проявления неисправностей. По сути это был самый легкий путь, так как предполагал простое объединение отдельных «чужих» списков неисправностей на основе единой (нашей) инфраструктурной модели.
В общем, получалось как то так:
….итого около 1600 строк, из которых около 600 так и не удалось привязать к конкретным объектам. При этом не все проблемы имели четкую объектную привязку и не все упоминаемые объекты были введены в нашу ресурсную базу. Такой подход хоть и немного распутывал ситуацию, но не позволял нам ввести общую иерархию, выявить синонимы и сократить общее количество, что было одной из наших целей.
В дальнейшем «применимость» неисправности к объектам осталась у нас в системе, но это стал отдельный от общей иерархии неисправностей справочник.
Результат
Итак, в какой то момент стало ясно, что нам не удастся создать единую структуру ни на базе развернутых ранее информационных баз и систем, ни на базе принятых в организации нормативных документов.
В итоге мы выработали следующие принципы работы:
- отделить в корне создаваемого дерева нарушения (отклонения от норм) и проявления классифицированных естественными науками природных процессов;
- сохранить для природных явлений и процессов их классификацию с точки зрения современной науки;
- отделить последствия от первичных проявлений, а формулировки содержащие в себе и явление и последствия относить в ту ветку — куда отнесено последствие (например «Обесточивание» относим к сбоям электропитания, а «Потеря данных в результате обесточивания» — к нарушениям в работе информационных систем);
- все что пока не может быть классифицировано выделить в группу «Прочее» и наладить систематическую работу по «разбору» данной группы на основе принятых выше принципов классификации
- при определении места каждой новой записи в общей структуре руководствоваться только принципом: «Частным случаем чего из уже внесенного в дерево является данное проявление», искать таким образом место данной записи в дереве начиная от его корня.
- недостающие «обобщения» добавлять в дерево самостоятельно (если у нас нет такого исходного аварийного сообщения).
Действуя так, мы получили примерно следующий набор веток для первого уровня дерева:
Что в итоге?
К сожалению данная работа не была закончена и результат, который мы установили в системе по моему мнению является крайне «сырым».
Причины неудачи проекта по моему следующие:
— данная работа должна была быть организована и продолжена силами самого владельца инфраструктуры, но там просто не нашлось специалистов, готовых взять ее на себя;
— специалистов «на местах» вполне устраивали привычные для них названия и классификации, а наши попытки обобщения и выделения подгрупп встречали их сопротивление;
— реализация глобальной аналитической отчетности, для которой проводилась данная работа так и не стартовала.
В общем заказчик оказался не готов к подобным изменениям, а у нас не было достаточного административного ресурса, чтобы повлиять на его сотрудников.
Тем не менее, был накоплен значительный опыт проведения подобных работ, который отчасти сформулирован в описанных выше принципах.
Автор: Basych
