Чэкліст гатоўнасці AI-агента да прадакшну па этапах

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

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

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

Этап 1: разработка і локальны пратотып

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

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

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

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

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

Чаму: Разніцы шырока накапліваюцца, калі з’являюцца корыстувальнікі („Чы гэта працуе з заявкамі на французкай мове?“, „Чы можа адзеныя для корпаратыўных кліентаў мець строгейшую чыстонасць?“). Калі кожная з гэтых разніц трэба перакодаваць і выдаты новую версію, новыя кейсы стаюць у чэргу пасля інжынераў, тады як з налаштаванням гэта ўсё можна быстра выправіць.

Прыёмак: Узаменіваючы структуру if/else па рангу кожнага кліента, інструкціі агента ствараюцца на адпаведных тэкстовых шаблонах — аднам базовам і аднам па кожны ранг. Для дадзення новага ранга трэба дадаць новы файл.

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

Чаму: Праслед, які ніхто не запісаў, пазней становіцца неспакойным фактам, як правілу, выкрываемым пад час інцыдэту, а не пад час планавання. Запісаны праслед стае чарткай для наступнага этапу.

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

Этап 2: асяроддзе з меньшымі можлівасцямі і прыёмны стан

Тут сістэма спачатку стыкаецца з рэальной інфраструктурой і рэальнымі спосабамі ўзбіянняў. Яна цяпер працуе з ноутбука, пачынаецца занова і можа відбывацца колькіма людзямі адночасна.

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

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

Прыклад: Агент для перагляду прававых дакументаў працуе з раздэламі дакумента поўна ў адной екзекуцыі, ўтаманіваючы такім чынам весь запас інфармацыі, і перагляд длігі дакумент можа зайняць 10–15 мінут. Гэта выключае варыянт з безсерверным функцыям, якая мае жорсткі ліміт часу. Таксама гэта выключае варыянт з наборам кантэйнераў, якія працуюць сталя, адтак як агент выконваецца толькі калькі разоў на дзень, і працэздатнасць застаецца невыкарыстанай. Длігія, інтэнсівныя, рэдкаяя екзекуцыі паказуюць на сервіс, які налічвае толькі за актыўны час апрацоўкі і не мае ліміту часу.

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

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

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

Праўдзім, што «гэта апрацавалася два разы» і «гэтыя апрацаваліся адночасна». Большасць рэальных сістэм для перадачы паведамленняў можа адправіць адны трыгер больш чым раз. Простая перацэнка статусу («пачаць, якшто не пачато») не вяршыцца, таму што два працэсы можаць кожны прачытаць «не пачато» прычым не запісаць «пачато». Неабходна выкорыстоўваць механізм, які дазволіць толькі аднаму з іх выграць.

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

Прыклад: Замок, які выкарыстоўвалі для прызначэння працэса, працаваў за нормальных умовах, але не мог прыняць новы працэс, якількі працавальнік, які яго трываў, зьмерлаў або застаўся у застойванні. У працэсе вырабоцтва гэта выглядала як купа процэсаў, якія застаялі на этапы „обработкі“ на калькі дзён, і не было нічога, што магло б іх атрымаць. Для парадкавання была дадана тэрмінаваная прадзейнае права, токен, які не дазволяе вярнувшамуся працавальніку быць спылучаным з первісным воладаром, а таксама перыядычная пераглядка, якая атрымае будзь-які працэс, чыя прадзейнае права заканчылася без завершэння. Гэта набаго болей комплектна, чым проста „прызначыць яго раз“.

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

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

Прыклад: У сістэмы з ШЫ была дакладная логікарабатка з самага пачатку, але сервіс, які працюе праз інтэрнэт, — няма. Таму логікарабатка паказвала усё, што рабіў агент, а не запіт, які яго запускаў, адтуды што нічога спольнага не было, што бы ўз’яздзіла гэтыя два элементы. Рашэннем было стварыць ідэнтыфікатор запуску ў момент запіту і перадаваць яго ў логі кожнага сервіса, такім чынам, адна пошукавая запытка могла збіраць всю інфармацыю пра конкрэтны запуск, нават як две сістэмы логікарабаткі заставаліся околасцю.

Спробуйце справжні кліент якомога раней. Калі корыстувальнікі прабываюць да сістэмы праз певны браузер, дапрыгнутку чы ўстатку, адразу ж працаваць з гэтым об’ектам, і не задаваліся гэнерычным API-кліентам чы апрыксамай.

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

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

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

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

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

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

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

Прыёмак: Апарат для тэставання навантажэння выканае тыя ж запыты API, якія выканае рэальны панель керування кліента для запуску тэста, а пасля пераканае табылку статусу, каб з’ясавіць, калі тэст завершыўся, адтуды што тэст заканчваецца пазней, а першая адпаведзь нічога не сказвае пра рэзультат. Колькісць адночасных тэстаў зростае паэтапна — ад калькі до дзесяткаў, а потым і да болей чым ста, пры чым існуе жорсткі ліміт для загальнай колькісці тэстаў і выдаткаў, адтуды што кожны фальшывы тэст ўрахоўваецца як рэальны запыт у модэлі аблікавання. Гэта паказала, што справжнім вузькім месцам пад навантажэнням быў сам праўодзіцель модэля, а не аблігаючая інфраструктура, што не было б відна падчас окалачных тэстаў.

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

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

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

Этап 3: прадзеяванне

Гэта апошняя асяроддзе першыя чыстыя корыстувальнікі. Пытанне пераходзіць з "чы робіць функцыя?" на "чы весь працэс застаецца стабільным, калі умовы не ідэальныя?" Гэта включае паўтаральныя запускі, частыя перыяды і змяны, калі мадэль або запрос пад ёю зменяюцца.

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

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

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

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

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

Прыёмак: Агента для рэдагавання дакумента перакантролююць на фіксаваным наборы прыёмакоў трыма спосабамі: чы не выбраў ён правыя часткі для рэдагавання (пораўняўшы з адпаведнай кантрольнай варыянтай, пераглянутай чалавекам), чы былі яго запропанаваныя змяны правымі (оцэненыя аддзельным модэлем суддзі), і насколькі яго рэзультаты разлічаюцца праз разныя запускі з аднаковым вхідным дакументам. Аналіз усіх трох пунктов у разных версіях, а не толькі показніка «успех/неспэх», паказаў, што адна змяна паспрабавала павысіць адну паметку, а тым часам таямна пашкодзіць іншую.

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

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

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

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

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

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

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

Чаму: Правіло на кшталт „развярнуць X раней за Y“ застаецца актуальным толькі пакуль людзін, якая яго знае, ў адсутнасці, або пакуль хтось автаматызуе працэс, не ведаючы пра гэта. Правілы парадку, якія маюць значэння, павінны быць часткай інструментаў.

Прыёмны прыклад: Служба кіравання запускамі выкарыстоўвае ID ай-інтэлектуальнага рантайму, які стварае іншы набор для развёртвання, і якбы кожны набор апісваўся на іншы, цэе створыла бы цыкл. Таму набор рантайму пасля стварэння запісвае свой ID у спяльны хранілнік параметраў, а набор кіравання запускамі чытае яго там. Гарантуюцца, што рантайм існуе першы, і наборы ніколі не апісваюцься на адны другі.

Этап 4: вораты да працывання

Пасляльній чакліст выпалюецца перад тым, як рэальныя корыстувальнікі пачнуць выкарыстоўваць сістэму. Тады ужо павінна быць паставлена пытанне правільнасці. Заставало толькі падтвердзіць, што тое, што выкідаецца, ўсё ж такі ёсць тое, што працавало пад час тэстаў, і што непрацясці можна выправіць і ўз’ясніць.

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

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

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

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

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

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

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

Чаму: Фраза «Мы пазней дадам правільныя лог-запісы» практычна ніколі не выконваецца, калі наступаюць рэальныя канцэнтрацыі, і калі потрэба стае явной, відсутняя історыя ужо нельга восстановіць пазней.

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

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

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

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

Патэрн пад чэрніцай

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

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