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