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

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

Здрастуйте. Відносно давно працюю у фірмі створює корпоративні інформаційні системи. У даній статті хочу поділитися деяким частково негативним досвідом, можливо комусь будуть цікаві чужі «граблі».

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

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

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

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

Ми поставили собі такі цілі:

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

Ми прагнули і до того, щоб характерними рисами нашої класифікації стали:

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

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

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

- вузькість загальної спрямованості оцінок в силу специфічності завдань вирішуваних конкретними системами,

- відсутність у багатьох випадках ієрархії проблем (плоскі списки несправностей не побудовані в деревовидні структури),

- заплутаність формулювань, змішування в одних позиціях причин і наслідків.

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

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

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

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

Результат

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

У підсумку ми виробили такі принципи роботи:

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

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

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

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

Вважаю, що причини цієї невдачі такі:

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

- фахівців «на місцях» цілком влаштовували звичні для них назви та класифікації, а наші спроби узагальнення та виділення підгруп зустрічали їх опір;

- реалізація глобальної аналітичної звітності, для якої проводилася дана робота так і не стартувала.

Загалом замовник виявився не готовий до подібних змін, а у нас не було достатнього адміністративного ресурсу, щоб вплинути на його співробітників.

Звичайно можна говорити, що час було витрачено не дарма. Що був накопичений значний досвід проведення подібних робіт, який частково сформульований в описаних вище принципах. Для себе особисто зробив висновок про важливість розбиття подібних проектів на малі етапи, постійну демонстрацію проміжного результату замовнику та забезпечення активної підтримки змін з його боку.

Чому ж все-таки так вийшло? Чому проміжний результат, який ми отримали навіть на нашу думку був далекий від досконалості?

Як з'ясувалося в ході впровадження користувачі в принципі готові прийняти (і пробачити нам) будь-яку класифікацію, але при одній простій умові - Додайте в форму текстовий пошук!

Класифікація є продукт систематизації досвіду. Очевидно, що кожна людина, керуючись унікальним персональним досвідом, бачить її по своєму. Наприклад, у поштовій програмі одні (і я в тому числі) створюють складну систему сортування вхідної пошти, а інші взагалі не сортують пошту, зберігають всі в одній теці і при цьому прекрасно там орієнтуються. І вони швидше мене знаходять потрібний лист. Може бути у таких людей Яндекс в голові?

Крім того будь-яка зумовлена класифікація може бути на 100% досконала тільки після того як її доопрацювали з урахуванням останніх даних, що надійшли в систему. Тобто класифікація вимагає постійної турботи, а користувачеві потрібно не працювати над системою, а використовувати її. Пошук же це індексація, і вона ефективно працює за фактичними даними завжди. Чи потрібна тоді взагалі класифікація?

Image