Галоўная / Артыкулы

Адаптаванне выходных дадзеных, які ніхто не чытае: аудыт для спожыццаў у автаматызаваных системах

Дазвольце даклэ расказаць, чаму невыкарыстаныя выходны данны застаюцца невидмымі ў аўтаматызаваных та агентных пайплайнах, як пераглядаць іх без пашкоджэння справных частак, а таксама пра тое, што самэ ўтримвае іх.

Выдавец: REACTAPP.TOP6 хв чытання1435 слоў

Крыніцы: Audit for Work Nobody Consumes

Кожная аўтаматызаваная система накаплівае роботу, якая працюе правільна, але нікому не ўжоўна: звіт, які генеруецца ўвечары і які ніхто не ачынае, механізм пераканання, які можа зламацца, але ніколи не выкорыстоўваецца, правіла, якія дадаюцца да списку перакананняў, але якія ніякі процес насправды не чытае. Нічога з гэтага не ламае, і самэ гэта ўсёлкі прычына, чаму гэтыя элементы застаюцца. У этай статыце описваецца, як аудытаваць систему на наявнасць выходных дадзеных, якіх немае таго, хто іх выкарыстоўваець, што зазвычай адкрывае такі аудыт, трое ошибак, якія можуць спрабаваць знішчыць справныя компаненты, і адна метаданные, якая робіць весь гэты процес практычна безкоштовным.

Правіла, якія стояць за аудытом: кожны крок мае адправніка і прымоўніка

Прыгодным прынцыпам для пайплайнаў, незалежна ад таго, чыя яны складаюцца з заданняў cron, крокаў CI чы сеансаў AI-агентаў, ёст канстантна прабаваць з’яеднваць кожную елементарную частку работы з обох бакоў. Чыясць вышэй у роўні падаюць яе контекст і вхідныя даны; чыясць нижэй прымоюць тое, што яна стварыла. Крок, які правяльна прымоўчае, але нікаму не перадае рэзультат, не выкааняе корыстной работы, нават якшо ўсё, што ён рабіць, правельна.

Сформулюваць гэты прынцып лёгка. Адстаўляць яго ў жыццё сложней, таму што адхыленне не залечва жадных следаў. Аудыт праглядае крокі, якія выкааняюць якісь дзеяння, але рэзультаты яных ніколі не выкарыстоўваюцца. Ён стае наіболей корыстным, калі адбываецца рэгулярна, напрыклад як частка кожнай ретроспективы, а не толькі раз пасля якога-небудзь інцидэту.

Што зазвычай выявляе часовы аудыт

Уявіце команду, яка адмініструеўае высока автаматызаваны процес роботы, куды включены агенты, і якая сама пракранула такую перапрацавку. Рэзультаты былі негатывныя, і саме гэта зробіла ўсё гэта корыстным.

  • «Вораты», якія ніколі не працуюць. Автары знайшлі 95 пераканалень, якія маглі показаць проблему, але якія ніколі не былі актывацыраны. Кожна з іх была належным чынам реалізавана і працавана, і кожная здавалася неабходной у момент стварэння, пры тым жадна з іх не была включана ні ў які лянцюг дзеянь.
  • Правілы без таго, хто іх прымае. З 25 няўзначна запрацоўваных правілаў 19, тыябро 76%, не мелі жадных асоціяцый з якім-небудзь фрагментам коду, чарткай або рутыной. Проблема не была у непаслуху; нічога проста не вказывала на іх. Адна з процедураў дыбаггінгу застаўся ў стандартных інструкцыях каманды пра 42 дзёны, не быў застосаваны ні разу. Ніхто яго не забыў. Яго запіс проста быў спачатку спытаны як його запрацоўкі.
  • Рэжыстр задач, запоўнены ўсунутымі элементамі. Актуальны пільга паказваў 417 адкрытых задач: 146 з іх не мелі жадных дзеянняў, а 104 не мелі вакументавання прыняцья як завершаных. Старэйшы незменны элемент мела вік 37 дзён.
  • Панель керування, якую ніхто не могаў паказаць. Панель керування процесам выдавання апошні раз абнавлялася праз кожнае выданне і зберагалася ў спакушанай тэчцы, дзе яй было месца. Але права на аднароджэнне на машыне выработкі былі налаштаваны толькі на прыём, таму нічага, што там было запісана, не распространялася. Несколькі тыдзён яна была точной і актуальной, але ніхто іншы яе не бачыў.
  • Пасляпэдні прыклад узьміць урок у адной лініі: размешчэнне чаго-небудзь у правым месцы — гэта не тое ж самае, што і яго доставка.

    Чаму неудача завжды выходзіць на межах

    Збыткі зазвычай выступаюць на межах між системамі, і гэта стосуецца не толькі штучнага інтэлекту. Чыясь даныя перадаюцца, але не прыймаюцца, або прыманыя, але не фіксуюцца ў належны час. У кожнам з вышэўказаных случаев сторона-выпускнік працавала ідеальна: пісьменнік напісаў, лічыльнік пасчитаў, вораты змоглі адкрыцца. Што не хватала, так гэта — названага спожыцеля.

    Асновная проблема заключаецца у тым, што калі спожыцеля няма, нічога не выходзіць з-пад контролю. Відсутнае спожыцтва не стварае ні якоўных памылак, ні апавешчэнняў, ні запісаў у журнале. Выпускнікі находзяцься пад наглядам, таму што ўсе іх проблемы явны; спожыцелі рэдка калі пераблікуюцца, таму што ўсёлякая відсутнасць у яных залишаецца непазначанай.

    Іншыя два прыклады паказваюць наследкі, калі гэтыя «тышы» трываюць:

    • Сістэма паведамленняў зберагала паведамленні для чалавека-операцыянара і обяцаўаў выдаткі ў разе наступнай успешной аправы. На аднам з узлоў яна завершала сваю роботу ўсё часы, перш чым запрацаваць першую лінію логіки. 552 паведамленні чакалі прыблізна 16 дзён. Стан апарату, які ўтвараў выход, быў нормальны, а маршрут — правільны, але да спожывача паведамленні так і не дасяглі.
    • Публічная панель керування паказвала 17 публікацый, якія былі запрацоўваны з копіі, тады як журнал, які, за прыпускам, яго відображаў, не існаваў ніде ў ціх системах. Панель аддачы вярна паказвала тое, што мела. Ніхто не запытаўся, з чаго на самай працэ паказаныя данні.

    Оба гэтыя прыклады маглі бы быть выявлены праз пераканальную перапалоху: чы гэтага дасягнуў оператацыянар, чы існуе джерела даных на панелі керування.

    Тры спосабы, якімі можа паспяліцца аудыт выкарыстоўвання

    Наўінны варыянт такога аудыту, „пралягчыць, як часта викорыстоўваецца кожны компонент, і адмахнуцься таго, што дае ноль“, актываўна пашкоджае систему. Шэсць змян, прынятых у ціх трох, спрямованыя на рашэнне найпаўзачыцей проблем, з якімі ён сталкаецца.

    1. Імкніце викорыстоўванне, а не вызов

    Існуе спакуса падключыць лічылку да явнага точкі входу, напрыклад, да вызову інструмента, який завантажае навык або запускае скрыпту. Але компоненты часта викорыстоўваюцца опосередка. Якщо автаматызаваныя рутіны проста чытаюць файл навыку, а не вызываюць інструмент, які яго абгортае, лічылка вызоўваў пакажае ноль для компонента, які викорыстоўваецца сталячы, і аудыт прызнае яго неактыўным.

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

    2. Адрадзіце вякасць даных і сачавайцеся за акнаўскім перыядам

    Компанента, створаная дзевяць дней тыму, не можа выграўваць у порэвананні з той, якая выкорыстоўваецца трэцьі дзень. Аудыт должен паказаць, на які час звяртаюцца його даны, і ніколі не выдаваць адгукі ўжо па чыннай моменту. Рашэнне, якое не зазначае перыяд, які ён охопляе, не мае рэальной сілы, і ён систематычна карае тое, што было створанае найняўлегкае.

    3. Адстаўце тыя элементы, якіх цэннасць ёст каштовнасць доступнасці

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

    Глыбэйшая пастка: показнікі, якія можаць толькі падтвердзіць

    За межамі статыстыкай існуе ўжо болей фундаментальная проблема. Метрыка, якая можа рухацца толькі на корысть створанага вам продукту, не ўтварае доказаў. Аудыт, які ніколі не можа запрасіць да выключэння практычнага раштрыку, на самай працэ ёсць толькі звычным аповешчэнням пра статус пад іншым назвам. Перш чым даваць веру рэзультатам, запытайцеся, які результат павинен прывести вас да выдалення чаго-небудзь, і пераканайцеся, што такі результат дасягнучы.

    Рашэнне: адзначыце спожывача ў момент стварэння продукту

    Найэфектывейшыя змены ўсегда маленькія. Для кожнага продукту – будзь то шлюз, правілу, аповешчэнне, панелі керавання чы задача – зафіксуйце адну лінію ў момент стварэння, а не пасля аудыту: хто яго спожывае і якая змена статусу падтверджвае, што ён быў спожыты.

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

    • Даць неабяжлівая польна «consumer» у шаблонах для новых заданняў, правіл і запланаваных завадб.
    • Адхіляцыя вакласаў «завершана», якія описваюць толькі дзеяння вырабніка («дашборд апцэнтаваны») без прыёмніка («дашборд видны для адпаведнага пераглядача»).
    • Для всьога, што доставляецца через межу, такую як спільна памяць, чат-ліст або релеютор, трэба дадзець перакананне на боку прыёмніка, а не толькі на боку вырабніка.

    Калі такая польна існуе, аудыт больш не выклікае патробу ў спецыяльным розследаванні. Дастатньва проста запытацца пра артыфакты з порожнім значэнням польна «consumer»; гэты список і є рэзультатам, і яго можна было прачытаць у будзь-які момент.

    Ключовыя выводы

    • Рэзультаты выдання без прыёмніка за замовчаннем є невиднымі, таму што нічога не паспявае, калі ніхто іх не чытае.
    • Паспявання з’яўляюцца пры перадачах, таму трэба пераканацца ў доставцы на боку прыёмніка.
  • Лічыце змяны стану, якія выйшлі з-за спрыткаў, а не з-за вызоўванняе точкі входу.
  • Адзвярцайце інформацыю пра вікна дадзэйнаў, ніколы не ацэнюйце компаненты, якія моладзейшыя за яго, і тэставайце толькі аб’екты, якія залежаць ад наявнасці, узамен лічэння ўжытку іх.
  • Запісвайце „хто спрыткае гэта і як мы гэта ведаем“ калі ствараецца аб’ект; тады аудыт коштае практычна нічога.