Як ми будували «Дерево несправностей»

Однією з найбільш цікавих завдань для команди наших інженерів-проектувальників було побудови єдиного «дерева неполадок» для великої корпоративної інформаційної системи моніторингу обладнання.

В цій статті хочу поділитися нашим досвідом, можливо комусь буде цікаво.

Постановка завдання

Інформаційна система, в яку ми вбудовували даний класифікатор, виконує централізацію інформації про аварії на самому різноманітному обладнанні, а також збирає дані про різних проблемних ситуаціях з абсолютно різнорідних систем, баз даних і пристроїв. Зрозуміло, що первинні аварійні повідомлення в такій архітектурі будуть абсолютно різноманітні. Наприклад 3 різні зовнішні зовнішні системи посилали нам несправність «обрив», але в одному випадку це був обрив несучого тросу в підвісці контактної мережі, в іншому обрив електроживлення, а в третьому провалля зв'язку між абонентами. Дана ситуація нас не влаштовувала, так як від нас була потрібна чітка класифікація, для подальшого використання у звітно-аналітичних задачах.

Наш обробник аварій при знаходженні нових типів надходять подій просто додавав їх у довідник і до моменту початку робіт по систематизації тільки типів повідомлень накопичилося понад 1000.

Ми поставили собі наступні цілі:
  • прибрати синоніми — об'єднати записи, що мають абсолютно однаковий зміст, але різне написання;
  • виробити єдину ієрархічну структуру класифікації, в яку ми змогли б «укласти» несправності будь-якої природи;
  • спростити подальший розвиток (деталізацію) даної класифікації за рахунок визначення чітких та несуперечливих принципів її побудови.
Ми прагнули до того, щоб характерними рисами нашої класифікації стали:
  • общеприменимость, можливість використання в інших наших проектах і продуктах;
  • простота і інтуїтивна зрозумілість, що дозволяє легко розвивати дану структуру і знаходити «належне місце» новим несправностей;
  • переконливість, можливість довести цим і потенційним замовникам автоматизації нашу правоту — справа в тому, що наша система охоплювала автоматизацією діяльність відразу кількох великих організаційних підрозділів в кожному з яких був прийнятий свій власний підхід до даного питання.


Хід робіт і наші помилки

Незабаром після початку робіт стало зрозуміло, що вироблення принципу класифікації це ключове завдання всієї теми. Взяти за основу якусь із класифікацій приходять із зовнішніх систем не вдавалося з наступних причин:
— вузькість загальної спрямованості оцінок в силу специфічності завдань, вирішуваних конкретними системами,
— відсутність у багатьох випадках ієрархії проблем (плоскі списки несправностей не побудовані в деревовидні структури),
— заплутаність формулювань, змішування в одних позиціях причин і наслідків.

Першу версію ми створювали на основі групування за інфраструктурних об'єктів на яких виникали дані прояви несправностей. По суті це був найлегший шлях, так як передбачав просте об'єднання окремих «чужих» списків несправностей на основі єдиної (нашої) інфраструктурної моделі.

Загалом, виходило якось так:



… усього близько 1600 рядків, з яких близько 600 так і не вдалося прив'язати до конкретних об'єктів. При цьому не всі проблеми мали чітку об'єктну прив'язку і не всі згадувані об'єкти були введені в нашу ресурсну базу. Такий підхід хоч і трохи розплутував ситуацію, але не дозволяв нам ввести загальну ієрархію, виявити синоніми та скоротити загальну кількість, що було однією з наших цілей.

Надалі «придатність» несправності до об'єктів залишилася у нас в системі, але це окреме від загальної ієрархії несправностей довідник.

Результат

Отже, в якийсь момент стало ясно, що нам не вдасться створити єдину структуру ні на базі розгорнутих раніше інформаційних баз і систем, ні на базі прийнятих в організації нормативних документів.

У підсумку ми виробили такі принципи роботи:
  • відокремити докорінно створюваного дерева порушення (відхилення від норм) і прояви класифікованих природничими науками природних процесів;
  • зберегти для природних явищ і процесів їх класифікацію з точки зору сучасної науки;
  • відокремити наслідки від первинних проявів, а формулювання містять у собі і явище і наслідки відносити в ту гілку — куди віднесено наслідок (наприклад «Знеструмлення» відносимо до збоїв електроживлення, а «Втрата даних в результаті знеструмлення» — до порушень в роботі інформаційних систем);
  • все що поки не може бути класифіковано виділити в групу «Інше» і налагодити систематичну роботу з «розбору» даної групи на основі прийнятих вище принципів класифікації
  • при визначенні місця кожного нового запису в загальній структурі керуватися тільки принципом: «Приватним випадком чого вже внесеного в дерево є дане прояв», шукати таким чином місце запису в дереві починаючи від його кореня.
  • відсутні «узагальнення» додавати в дерево самостійно (якщо у нас немає такого вихідного аварійного повідомлення).


Діючи так, ми отримали приблизно наступний набір гілок для першого рівня дерева:



Що в підсумку?

На жаль ця робота не була закінчена і результат, який ми встановили у системі на мою думку є дуже «сирим».

Причини невдачі проекту на мою наступні:
— ця робота мала бути організована і продовжена силами самого власника інфраструктури, але там просто не знайшлося фахівців, готових взяти її на себе;
— фахівців «на місцях» цілком влаштовували звичні для них назви та класифікації, а наші спроби узагальнення і виділення підгруп зустрічали їх опір;
— реалізація глобальної аналітичної звітності, для якої проводилася ця робота так і не стартувала.
Загалом замовник виявився не готовий до таких змін, а у нас не було достатнього адміністративного ресурсу, щоб вплинути на його співробітників.

Тим не менше, був накопичений значний досвід проведення подібних робіт, який частково сформульований в описаних вище принципах.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.