Привет. Я сравнительно давно работаю в компании, которая занимается созданием корпоративных информационных систем.
В этой статье я хочу поделиться частично негативным опытом; возможно, кому-то еще будут интересны чужие «грабли».
Одной из интересных задач для команды наших инженеров-проектировщиков было построение единого «дерева неисправностей» крупной корпоративной информационной системы мониторинга оборудования.
Постановка задачи
Информационная система, в которую мы интегрировали этот классификатор, централизует информацию об авариях на самом разнообразном оборудовании, а также собирает данные о различных проблемных ситуациях из совершенно разнородных систем, баз данных и устройств.Понятно, что первичные экстренные сообщения в такой архитектуре будут совершенно другими.
Например, 3 разные внешние внешние системы отправили нам неисправность «обрыв», но в одном случае это был обрыв несущего кабеля в воздушной контактной линии, в другом — сбой электропитания, а в третьем — потеря связи между абонентами.
Нас такая ситуация не устраивала, так как от нас требовалось иметь четкую классификацию для последующего использования в отчетных и аналитических задачах.
Когда наш аварийный обработчик находил новые типы входящих событий, он просто добавлял их в каталог, и к моменту начала работы по систематизации только типов сообщений их накопилось более 1000. Мы поставили перед собой следующие цели:
- удалять синонимы – объединять записи, имеющие абсолютно одинаковое значение, но разное написание;
- разработать единую иерархическую классификационную структуру, в которую можно было бы «упаковать» неисправности любого характера;
- упростить дальнейшую разработку (детализацию) этой классификации, определив четкие и последовательные принципы ее построения.
- широкая применимость, возможность использования в других наших проектах и продуктах;
- простота и интуитивная ясность, что позволяет легко развивать эту структуру и находить «нужное место» для новых разломов;
- убедительность, возможность доказать этому и потенциальным заказчикам автоматизации нашу правоту - дело в том, что наша система охватила автоматизацией деятельность сразу нескольких крупных организационных подразделений, каждое из которых приняло свой подход к этому вопросу.
Ход работы и наши ошибки
Вскоре после начала работы стало ясно, что разработка принципа классификации является ключевой задачей всей темы.Взять за основу ни одну из классификаций, исходящих из внешних систем, не удалось по следующим причинам: — узость общей направленности оценок из-за специфики задач, решаемых конкретными системами, — отсутствие во многих случаях иерархии проблем (плоские списки неисправностей, не встроенные в древовидные структуры), - путаница формулировок, путаница причин и следствий по некоторым позициям.
Первую версию мы создали на основе группировки по объектам инфраструктуры, на которых произошли данные проявления неисправностей.
На самом деле это был самый простой путь, поскольку предполагал простое объединение отдельных «чужих» списков неисправностей на основе единой (нашей) модели инфраструктуры.
В общем, получилось примерно так: 
.
всего около 1600 строк, из которых около 600 не удалось привязать к конкретным объектам.
Однако не все задачи имели четкую объектную привязку и не все упомянутые объекты были внесены в нашу ресурсную базу.
Такой подход хоть и немного распутал ситуацию, но не позволил нам ввести общую иерархию, выявить синонимы и сократить общее количество, что и было одной из наших целей.
В дальнейшем «применимость» неисправности к объектам осталась в нашей системе, но она стала справочником, отдельным от общей иерархии неисправностей.
Результат
Итак, в какой-то момент стало ясно, что мы не сможем создать единую структуру ни на основе ранее развернутых информационных баз и систем, ни на основе принятых в организации нормативных документов.В результате мы разработали следующие принципы работы:
- выделять в основе созданного дерева нарушения (отклонения от норм) и проявления природных процессов, классифицируемых естественными науками;
- сохранить свою классификацию явлений и процессов природы с точки зрения современной науки;
- отделить последствия от первичных проявлений, а формулировки, содержащие как явление, так и последствия, отнести к той ветви, где присвоено последствие (например, «Отключение электроэнергии» относится к сбоям в электроснабжении, а «Потеря данных в результате отключения электроэнергии» относится к сбоям в работе информационных систем);
- все, что пока не может быть классифицировано, отводится в группу «Другое» и проводится систематическая работа по «анализу» этой группы на основе принятых выше принципов классификации.
- при определении места каждой новой записи в общей структуре руководствуйтесь только принципом: «Это проявление есть частный случай чего-то, уже включенного в дерево», и таким образом ищите место этой записи в дереве, начиная с его корень.
- недостающие «обобщения» допишите в дерево самостоятельно (если такого исходного тревожного сообщения у нас нет).
Каков результат?
К сожалению, эта работа не была завершена, и результат, на котором мы остановились, оказался крайне «сырым».Я считаю, что причины этой неудачи следующие: — эту работу должен был организовать и продолжить сам владелец инфраструктуры, но специалистов, готовых взяться за нее, просто не было; — специалистов «на местах» вполне устраивали знакомые им названия и классификации, а наши попытки обобщить и выделить подгруппы встретили их сопротивление; — внедрение глобальной аналитической отчетности, ради которой проводилась эта работа, так и не началось.
В целом заказчик не был готов к таким изменениям, а у нас не было достаточного административного ресурса, чтобы влиять на его сотрудников.
Конечно, можно сказать, что время было потрачено не зря.
В проведении такой работы накоплен тот значительный опыт, который частично формулируется в изложенных выше принципах.
Лично для себя я пришел к выводу о важности разбивать такие проекты на небольшие этапы, постоянно демонстрируя заказчику промежуточный результат и обеспечивая активную поддержку изменений с его стороны.
Почему это случилось? Почему промежуточный результат, который мы получили, даже на наш взгляд, был далек от совершенства? Как выяснилось в ходе реализации, пользователи в принципе готовы принять (и простить нас) любую классификацию, но при одном простом условии — Добавьте в форму текстовый поиск! Классификация есть продукт систематизации опыта.
Очевидно, что каждый человек, руководствуясь своим уникальным личным опытом, видит это по-своему.
Например, в почтовой программе некоторые (в том числе и я) создают сложную систему сортировки входящей почты, а другие вообще не сортируют почту, хранят все в одной папке и при этом прекрасно в ней ориентируются.
И они находят нужную букву быстрее меня.
Может у таких людей Яндекс в голове? Кроме того, любая предопределенная классификация может быть на 100% идеальной только после ее доработки с учетом последних данных, поступивших в систему.
То есть классификация требует постоянного ухода, и пользователю нужно не работать над системой, а пользоваться ею.
Поиск — это индексация, и он всегда работает эффективно на основе реальных данных.
Нужна ли тогда вообще классификация? Теги: #классификация #анализ данных #Анализ и проектирование систем
-
Основное Руководство По Покупкам В Интернете
19 Oct, 24 -
Virtual Movable Type, Коротко О Главном
19 Oct, 24 -
Как Облачный Сервис Превращается В Тыкву
19 Oct, 24 -
Функция Загрузки Для Собственного Фреймворка
19 Oct, 24 -
Пробки На Google Maps В России
19 Oct, 24 -
Youtrack Теперь С Центром Уведомлений
19 Oct, 24
