Знаходження результатів, які ніхто не читає: аудит споживачів для автоматизованих систем

Кожна автоматизована система накопичує роботу, яка виконується правильно, але нікому не потрібна: звіт, який генерується щоночі та ніхто не відкриває, механізм перевірки, який може зламатися, але ніколи не використовується, правило, додане до списку перевірок, яке насправді не читається жодним процесом. Жоден з цих елементів нічого не ламає, і саме тому вони залишаються. У цій статті описано, як провести аудит системи на наявність результатів роботи, які ніхто не використовує, що зазвичай виявляється під час такого аудиту, три помилки, через які аудит може пошкодити функціональні компоненти, та один елемент метаданих, який робить весь процес майже безкоштовним.

Правило, що лежить в основі аудиту: кожен крок має відправника та отримувача

Корисною практикою для конвеєрних процесів, незалежно від того, чи складаються вони з завдань cron, кроків CI чи послідовних сеансів ШІ, є вимога до того, щоб кожна одиниця роботи була підключена з обох сторін. Щось у верхній частині ланцюга надає їй контекст та вхідні дані; щось у нижній частині отримує результати її роботи. Крок, який належним чином отримує дані, але нікому їх не передає, не виконує корисної роботи, навіть якщо все, що він робить, є правильним.

Сформулювати це правило легко. Перевірити його складніше, оскільки порушення не залишає слідів. Аудит призначений для пошуку кроків, які виконують щось зрозуміле, але результати цих дій ніколи не використовуються. Він найбільш ефективний, коли проводиться регулярно, наприклад як частина кожного аналізу після завершення проєкту, а не лише один раз після проблеми з очищенням.

Що зазвичай виявляє чесний аудит

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

• Перевірки, які ніколи не запускаються. Вони знайшли 95 перевірок, які могли показати червоний статус, але до яких ніколи не зверталися. Кожна з них була належним чином реалізована та протестована, і кожна здавалася необхідною у момент її створення, проте жодна з них не була включена до жодного шляху виконання.
• Правила без способу їх застосування. Із 25 нещодавно прийнятих правил 19, тобто 76%, не мали жодних посилань у коді, списку перевірок чи рутинних процедурах. Проблемою була не непокора — на них взагалі нічого не вказувало. Одна процедура виправлення помилок залишалася у стандартному посібнику команди протягом 42 днів, не бувши застосованою жодного разу. Ніхто її не забув. Просто запис її було сплутано з її фактичним впровадженням.

Реєстр завдань, повний бездіяльних елементів. Живий підрахунок показував 417 відкритих завдань: 146 з них не мали жодної активності, а 104 – не мали визначення статусу „виконано“. Найстаріший недоторканий елемент був віком 37 днів.

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

Останній приклад узагальнює урок одним реченням: розміщення чогось у правильному місці – це не те саме, що його доставка.

Чому збої завжди трапляються у „швах“

Втрати зазвичай виникають на межах між системами, і це характерно не лише для ШІ. Щось передається, але не приймається, або приймається, але не помічається вчасно. У кожному з вищезгаданих випадків сторона-виробник працювала ідеально: автор написав текст, лічильник підрахував значення, ворота змогли відкритися. Бракувало лише споживача, який би це прийняв.

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

Ще два випадки демонструють наслідки, коли ця тиша триває:

• Система нагадувань зберігала повідомлення для людини-оператора та обіцяла їх доставку під час наступної успішної передачі. На одному з вузлів вона завжди завершувала роботу ще до виконання першої команди логіки. 552 повідомлення залишалися у очікуванні протягом 16 днів. Джерело даних функціонувало нормально, маршрут був правильним, але до споживача так і не дійшло жодне повідомлення.
• Публічна панель керування відображала 17 публікацій, отриманих з дзеркального сервера, хоча журнал записів, який, за задумом, мав їх відображати, взагалі не існував у системі. Панель точно відображала те, що мала, але ніхто не запитував, звідки вона насправді отримує дані.

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

Три способи, якими може піти не так під час аудиту використання

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

1. Вимірюйте використання, а не виклик

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

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

2. Виведіть вік даних та дотримуйтесь часового проміжку

Компонент, створений дев’ять днів тому, не може конкурувати у порівнянні тривалості використання протягом тридцяти днів. Аудит має вказувати, наскільки далеко сягають його дані, та ніколи не робити висновки щодо чогось, що створено пізніше за його часовий проміжок спостереження. Висновок, який не вказує період, що охоплюється, не має реальної сили та систематично карає те, що було створено нещодавно.

3. Виключіть елементи, чия цінність полягає у доступності

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

Глибша пастка: показники, які можуть лише підтверджувати

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

Рішення: оголосити споживача під час створення продукту

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

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

• додати обов’язкове поле „споживач“ у шаблони для нових завдань, правил та запланованих робіт
• відхиляти визначення статусу „завершено“, які описують лише дію виробника („панель керування оновлена“) без вказівки отримувача („панель керування видима для оператора, який знаходиться на чергуванні“)
• для всього, що передається через певні механізми, такі як спільне використання, черга чи ретрансляція, додати перевірку з боку отримувача, а не лише з боку відправника

Як тільки це поле буде наявне, аудит більше не потребуватиме складних пошуків. Достатньо просто знайти записи з порожнім значенням у полі „споживач“; цей список і є результатом, і його можна було б отримати в будь-який момент.

Основні висновки

• Результати без вказаного споживача за замовчуванням є невидимими, оскільки нічого не ламається, якщо їх ніхто не читає.
• Проблеми зазвичай виникають під час передачі даних, тому необхідно перевіряти їх доставку з боку отримувача.

Підраховуйте зміни стану, спричинені споживанням ресурсів, а не викликами точки входу.

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

Записуйте інформацію „хто це споживає та звідки ми це знаємо“ під час створення елемента; тоді аудит коштуватиме майже нічого.