Tool calling-ті тестілеу: happy path-тен тыс не бұзылады

Неге happy path жеткіліксіз

Бір сәтті шақырудың өзі көп нәрсені дәлелдемейді. Ол тек модель, схема және инструмент ыңғайлы мысалда бір-біріне сай келгенін ғана көрсетеді. Өндірісте мұндай жағдай сирек болады.

Tool calling көбіне мынадай қарапайым қателіктен бұзылады: егер демо өтті болса, демек бәрі әрі қарай да солай жұмыс істейді. Бірақ модель кодты қатаң сценарий бойынша орындамайды. Әр шақыруды ол қайтадан құрастырады. Сирек кездесетін тұжырымда бір өрісті жоғалтып алады, типті шатастырады немесе артық аргумент қосады.

Одан әрі ұсақ қате келесісін тартып әкетеді. Инструмент нашар JSON алады, қате қайтарады, ал диалогтың келесі қадамы бұзылған күйге сүйеніп құралады. Пайдаланушы болжамды жауапты, артық сұрақты немесе түсініксіз кідірісті көреді, ал бастапқы мәселе онша үлкен болмаған еді.

Демода әдетте қысқа сұраныс, таза деректер және жылдам инструмент алынады. Ал шынайы жұмыста пайдаланушы қате теріп жазады, бірден екі нәрсе сұрайды, ойы өзгеріп тұрады, ал сыртқы сервис баяу жауап береді. Сол сценарий мүлде басқаша әрекет етеді.

Бұл бір OpenAI-үйлесімді API қолданып, тек модельді немесе провайдерді ауыстыратын командаларда жақсы байқалады. Шақыру форматы бірдей, бірақ мінез-құлық әртүрлі: бір модель схеманы ұқыпты ұстайды, екіншісі кейде міндетті өрісті тастап кетеді. Мұны алдын ала тексермесеңіз, жүйе міндетті аргументтегі бос жол сияқты ұсақ нәрседен бұзылады.

Happy path қажет. Бірақ ол тек бастамасы ғана. Егер сирек кірістерді, инструмент қателерін және сәтсіздіктен кейінгі мінез-құлықты тексермесеңіз, сіз жұмыс істейтін жүйені емес, демоны тестілеп жүрсіз.

Бос аргументтер мен жоғалған өрістер

Көбіне бәрі бос аргументтерден бұзылады. Модель null, бос жол \"\" немесе бос объект {} қайтара алады, ал сырт көзге бұл қалыпты шақыру сияқты көрінеді.

Мұндай жағдайларды бөлек тексеріңіз. Схема үшін де, код үшін де бұл әртүрлі сигнал. {\"order_id\": null} валидациядан өтпей қалуы мүмкін, {\"order_id\": \"\"} өтіп кетіп, іздеуді бұзуы мүмкін, ал {} жүйенің міндетті өріс мүлде болмаған кезде қалай әрекет ететінін көрсетеді.

find_order инструменті үшін қарапайым тест пайдалы: алдымен order_id-ге бос мән беріңіз, сосын бұл өрісті мүлде алып тастаңыз. Бірінші жағдайда модель аргумент керек екенін түсінетіндей, бірақ оны толтыра алмайтындай көрінеді. Екінші жағдайда ол order_id жоқ болса, инструментті шақыруға болмайтынын мүлде елемейді.

Екі қабаттың мінез-құлқын бөлек салыстырыңыз. Валидатор кіріс деректерінде не дұрыс емес екенін нақты айтуы керек. Инструменттің өзі валидатор бірдеңені байқамай өткізіп жіберсе де, болжамды әрекет етуі тиіс. Әйтпесе тесттерде команда бір қате көреді де, өндірісте мүлде басқа қателік алады.

Бірнеше қарапайым ережені бірден бекіткен дұрыс. Егер қауіпсіз іздеу үшін өріс жетпесе, жүйе нақтылау сұрайды. Егер әрекет бірдеңе жіберсе, есептен шығарса немесе өзгертсе, шақыру бірден тоқтатылуы керек. Егер мән бос болса, қате анық болуы тиіс, ешқандай болжам да, әдепкі мән де болмауы керек. Егер схема сұранысты қабылдамаса, инструмент мүлде іске қосылмауы тиіс.

Бұл ең пайдалы тексерулердің бірі. Ол қай жерде шынайы қорғаныс барын, қай жерде тек оның көрінісі ғана барын тез көрсетеді. Егер бос аргумент тым алысқа дейін өтіп кетсе, кейін багты модельден емес, бизнес-логика мен логтардан іздеуге тура келеді.

Артық өрістер мен бұзылған схема

Артық өрістер tool calling-ті қате типтерден де баяу бұзады. Сұраныс сырттай қалыпты көрінеді, инструмент кейде жауап та береді, бірақ мағынасы ауысып кеткен болады. Модель debug, comment немесе user_context қосты, ал код оны не жұтып қойды, не тексерусіз әрі қарай беріп жіберді.

Сондықтан тек JSON-ның жарамды болуын ғана емес, аргументтердің қатаң пішінін де тексеру маңызды. Егер схема бәріне рұқсат берсе, қате инструмент біртүрлі әрекет ете бастағанша байқалмайды. Мысалы, өтінім рәсімдейтін функция amount пен currency күтеді, ал модель тағы discount_override жібереді. Егер парсер өрісті үнсіз өткізіп жіберсе, модель не істемек болғанын бақылау қолыңыздан шығады.

Бұл жерде пайдалы тест өте қарапайым: дұрыс аргументтер жиынын алыңыз, үстіне бір-екі қажетсіз өріс қосыңыз да, валидатор payload-ты "түзетуге" тырыспай, оны анық түрде қабылдамайтынын тексеріңіз. Логтарда бастапқы payload-ты нормализация мен қысқартуға дейін толық сақтаған дұрыс. Және ақау қай жерде болғанын бөлек белгілеңіз: модель қате аргумент жинады ма, әлде парсер схеманы ұстай алмады ма.

Логтар бұл жерде ойлағаннан да маңызды. Егер журналда тек тазартылған аргументтер ғана қалса, команда істің нақты себебін көрмейді. Кейін бәрі инструмент жай ғана қате қайтарғандай болып көрінеді, ал шын мәнінде модель мүлде болмауы керек өрісті қосып жіберген.

Мұнда екі бөлек мәселе бар. Біріншісі — модель артық өріс жасады. Екіншісі — валидация қабаты оны үнсіз қабылдады. Бұлар әртүрлі жолмен түзетіледі. Бірінші жағдайда инструмент сипаттамасын, мысалдарды және жүйелік нұсқаулықты түзетесіз. Екіншісінде схеманы қатаңдатасыз, қосымша қасиеттерге тыйым саласыз және парсерге модель үшін ой жүгіртуге мүмкіндік бермейсіз.

Егер тесттен кейін модель не жібергенін және схеманың оны қай қадамда тоқтатқанын айта алмасаңыз, тексеріс әлі дайын емес.

Қате типтер және үнсіз түрлендірулер

Ең жағымсыз қателер схема сұранысты бірден кері қайтарған жерде емес, оның тым ерте "көмектескен" тұсында пайда болады. Модель санның орнына \"limit\": \"10\" жіберді, код оны үнсіз 10-ға айналдырды, тест өтті. Кейін басқа модель \"0010\" қайтарды, ал келесі сервис оны сан емес, код ретінде оқыды.

Мұндай жағдайларды бөлек ұстау керек. Библиотека автокаст жасай алса да, санды жол ретінде және жолды сан ретінде жіберіп көріңіз. Әйтпесе сіз инструмент контракты емес, нақты парсердің жұмсақтығын тексеріп жүрген боласыз.

Мынадай бірнеше қарапайым жаман мысал жақсы жұмыс істейді:

• \"amount\": \"5000\", егер схема integer күтсе
• \"currency\": 398, егер өріс жол болуы тиіс болса
• \"mode\": true, егер өріс тек \"strict\" немесе \"soft\" қабылдаса
• объектінің орнына массив, мысалы [{\"id\":1}] орнына {\"id\":1}

Bool-ды enum орнына және массивті объект орнына бөлек тексеріңіз. Мұндай қателер әр қабаттан әртүрлі өтеді: бір қабат шағымданады, екіншісі үнсіз типті өзгертеді, үшіншісі бизнес-логиканың ішінде құлайды. Команда тек ортақ tool failed дегенді көріп, талдауға уақыт жоғалтады.

Автокастқа сүйенбеңіз, егер ережені әдейі жазып қоймаған болсаңыз. Егер өрісті жолдан санға айналдыруға болады, оны бір жерде сипаттап, тест қосыңыз. Егер болмайтын болса, сұранысты бірден кері қайтарыңыз. Аралас тәсіл жүйені тез бұзады, әсіресе бірдей шақыру әртүрлі модельдер немесе әртүрлі провайдерлерге баратын болса. Бір модель 42 қайтарады, екіншісі \"42\", үшіншісі null.

Қате хабарламаның өзін де тестілеу маңызды. Кодқа field amount: expected integer, got string сияқты нақты жауап керек. Модельге болса дұрыс типпен қайта шақыра алуы үшін қысқа әрі түсінікті жауап қажет. Егер бұл хабарламалар әр инструментте әрқалай болса, қайталап көру кездейсоққа айналып, debug бір сағатқа созылады.

Ұзақ істейтін инструменттер және жауап күту

Инструменттің өзі модельден де ұзақ кідіріп қалуы мүмкін. Көбіне LLM емес, сыртқы сервис баяулайды: CRM-дегі іздеу, биллингке сұраныс, құжат тексеру, баға есептеу. Мұны алдын ала тексермесеңіз, диалог қатып қалғандай көрінеді де, пайдаланушы жүйе бұзылды деп ойлайды.

Бірдей шақыруды кемінде үш режимде өткізіп көрген дұрыс:

• 100 мс
• 5 с
• 30 с

100 мс-та бәрі қалыпты көрінеді. 5 секундта интерфейсте тірі статус бар-жоғы, сұранысты тоқтату мүмкіндігі және диалог тарихы жоғалмай ма — соны байқайсыз. 30 секундта әдеттегі тексерісте байқалмайтын қателер шығады: таймаут, жоғалған жауап, қайта іске қосу және түсіндірмесіз бос экран.

Пайдаланушы не көруі керек

Егер инструмент бірнеше секундтан ұзақ күтсе, интерфейс мұны қарапайым сөзбен айтуы керек. Деректерді тексеріп жатырмын немесе Сервистен жауап күтіп тұрмын сияқты қысқа статустар жарайды. Диалогты статусы жоқ ілулі күйде қалдырмаңыз, әйтпесе адам сол сұранысты қайта жібере бастайды.

Тауардың қоймада бар-жоғын тексеретін чатты елестетіңіз. 5 секундта пайдаланушы әлі күте алады. 30 секундта оған енді таңдау керек: әрі қарай күту, сұранысты тоқтату немесе сервис уақытында жауап бермегені туралы түсінікті хабарлама алу.

Мұнда тек уақыт шегін ғана емес, оның айналасындағы мінез-құлықты да тексеру маңызды:

• таймаут болғанда не болады: анық қате ме, әлде үнсіздік пе
• шақыруды қолмен тоқтатуға бола ма
• жүйе автоматты түрде қайталап көреме, қанша рет
• кеш келген жауап қазірдің өзінде жабылған диалогқа түсе ме

Автоматты қайталау көбіне тәжірибені бір честный таймауттан да қатты бұзады. Егер жүйе үнсіз екінші әрекетті бастаса, пайдаланушы не болып жатқанын түсінбейді, ал команда кейін логтардан бірдей сұраныстардың себебін іздейді. Шексіз жүктелуден гөрі бір анық статус пен бір түсінікті күту ережесі жақсы.

Қайта шақыру және идемпотенттілік

Модель бір инструментті екі рет шақырып қоюы мүмкін. Бұл таймауттан кейін, инструмент жауабы түсініксіз болғанда немесе хабарламалар тізбегінде қарапайым ақау шыққанда болады. Тестте тек сәтті өту ғана болса, мұндай ақау оңай өндірісте қалып қояды.

Дубль сценарийін бөлек тексерген дұрыс. Модельге сол бірдей аргументтермен шақыруды бірден, бірнеше секундтан кейін және жартылай жауаптан соң тағы қайталап көруге мүмкіндік беріңіз. Сосын жүйе қалыпты қайталау әрекетін шынайы дубльден қалай ажырататынын қараңыз.

Оқуды және жазуды басынан бастап бөлу керек. Балансты, өтінім статусын немесе құжаттар тізімін қайта сұрау әдетте қауіпсіз. Ал тапсырыс жасау, хат жіберу немесе төлемді есептен шығару қауіпті: пайдаланушы екі хат, екі өтінім немесе қос төлем алуы мүмкін.

Әдетте дубль мәтінге қарап емес, операцияның id-сі арқылы анықталады. Бұл id-ді клиент немесе сервер жасайды да, инструмент шақыруымен бірге жібереді. Егер жүйе сол id-ні екінші рет көрсе, әрекетті қайта іске қоспайды, бұрынғы нәтижені немесе ағымдағы статусды қайтарады.

Бірақ бұл да жеткіліксіз. Бірдей operation id келіп, аргументтер өзгеріп кеткен жағдайды да тексеріңіз. Мұндай сұранысты үнсіз қабылдауға болмайды. Жүйе оны кері қайтарып, қақтығысты логқа жазып, жазбаны қайта орындамауы тиіс.

Ең аз дегенде мына тексерулер болуы керек:

• бірдей шақыру қатарынан екі рет келеді
• екінші шақыру таймауттан кейін келеді
• бірінші шақыру орындалды, бірақ жауап модельге жетпеді
• бірдей operation id өзгерген аргументтермен келді

Практикада бұл әсіресе тапсырыстар, хаттар және төлемдер үшін маңызды. Бір ғана сақталған operation id көбіне ұзақ әрі күрделі тестілерден де көп ақша мен жүйкені сақтап қалады.

Тесттерді қадамдап қалай жинау керек

Көп істің басында бір қарапайым мәселе жатады: команда әр инструмент нені қабылдап, нені қайтаруы керек екенін нақты бекітпейді. Мұны бір кестеге немесе файлға түсіріп қойыңыз. Әр инструмент үшін міндетті аргументтерді, типтерді, рұқсат етілген мәндерді және жанама әсерін жазыңыз. Егер шақыру тапсырыс, өтінім немесе базаға жазба жасаса, оны бөлек белгілеңіз.

Одан кейін мына шаблонмен жүріңіз:

1. Әр өріс үшін қалыпты кірісті, бос кірісті және қате кірісті белгілеңіз.
2. JSON schema қосулы болса да, артық өріс жағдайын қосыңыз.
3. Инструмент таймауттарын тексеріңіз: жылдам жауап, ұзақ жауап, уақыт бойынша үзілу.
4. Бірдей шақырудың дублін жасап, жүйе екінші объект жасап жібермейтінін қараңыз.
5. Әр тест үшін нақты күтілетін нәтижені жазыңыз.

Соңғы пункт көбіне нашар жасалады. қате өңделуі тиіс деген сөйлемнің пайдасы аз. Нақтырақ жазыңыз: инструмент мүлде шақырылмайды, модель нақтылау сұрайды, жүйе валидация қатесін қайтарады, қайталанған сұраныс дубль жасамайды, пайдаланушыға түсінікті хабарлама көрсетіледі.

Сосын бірдей жиынды бірнеше модельде өткізіңіз. Бұл мінез-құлық айырмасын тез көрсетеді. Бір модель бос жол қайтарады, екіншісі санды жолға айналдырады, үшіншісі артық аргумент қосады. Егер сізде бір OpenAI-үйлесімді endpoint болса, мұндай прогонды клиентті қайта жазбай-ақ автоматтандыруға болады.

Қысқа мысал. create_ticket деген инструмент бар делік, оның өрістері title және priority. Оған арналған минималды тест жиыны мынадай болуы мүмкін: екі өріс те берілген, title бос, priority жоқ, priority сан болып келген, модель department өрісін қосқан, инструмент тым кеш жауап берген, бірдей шақыру екі рет кеткен. Осындай жиыннан кейін бірден қай жерде кәдімгі кіріс тексерісі жеткілікті, ал қай жерде идемпотенттілік керек екені көрінеді.

Практикадан қарапайым сценарий

Ассистент кездесуді calendar.create арқылы брондайды. Пайдаланушы: Айгүлді кездесуге жазып қой деп жазады. Модель атты көреді, бірақ нақты күнді алмайды. Нақтылау сұраудың орнына бәрібір инструментті шақырып, тек client_name жібереді.

Одан әрі бір емес, бірден бірнеше қадам бұзылады. Күнтізбе сервисі баяу жауап береді, мысалы 8-10 секундтан кейін. Жауап келмей тұрып модель шақыру жоғалды деп ойлап, екінші сұраныс жібереді. Егер жүйе дубльді тексермесе, команда бір емес, екі брондау әрекетін алады.

Мұндай тесттің пайдасы күткеннен де жоғары. Ол тек JSON schema-ны емес, бүкіл тізбектің мінез-құлқын тексереді: модельді, инструментті, ретрайларды және қате кезіндегі логиканы.

Жақсы сценарийде жүйе төрт нәрсе істейді. Ол күнсіз шақыруды жұмсақ болжаусыз кері қайтарады. Толық емес өрістер жиынымен кездесу жасамайды. Қайталанған шақыруды request_id немесе басқа тұрақты идентификатор арқылы дубль ретінде таниды. Және пайдаланушыдан күнді нақтылауды сұрайды, қайта-қайта үнсіз әрекет жасамайды.

Егер осы пункттердің бірі де жұмыс істемесе, қате тез арада өндірісте пайда болады. Пайдаланушы түсініксіз диалог көреді, оператор күнтізбеден дубль іздейді, ал команда логтарды талдауға уақыт жоғалтады.

Tool calling үшін бұл өте көрсеткішті кейс. Сырттай қарапайым көрінеді, бірақ бірден бірнеше типтік ақауды ұстайды: жоғалған міндетті аргумент, инструмент таймауты және идемпотенттіліктің жоқтығы.

Жақсы күтілетін нәтиже жалықтырғандай естіледі, және бұл қалыпты. Ассистент шамамен былай жауап беруі тиіс: Айгүлмен кездесудің күнін нақтылап жіберіңіз. Түсінікті бір сұрақ күнтізбеде кездейсоқ жасалған екі жазбадан әлдеқайда жақсы.

Командалар жиі өткізіп алатын нәрселер

Көбіне командалар тек бір жағымды сценарийді тексереді: модель жарамды JSON қайтарды, инструмент аргументтерді қабылдады, жауап тез келді. Демо үшін бұл жеткілікті. Өндіріс үшін — көбіне емес.

Сондықтан тесттер жасыл болып көрінеді де, бірінші біртүрлі жауап келгенше бәрі жақсы сияқты болады. Модель бос объект жіберуі, схема жоқ өрісті қосуы немесе санның орнына жол беруі мүмкін. Егер тесттер тек сәтті шақыру фактісіне қараса, мұндай ақаулар байқалмай қалады.

Тағы бір жиі қате — нормализацияланған жауапты ғана сақтау және модельдің шикі шығысын сақтамау. Онда команда тек парсерден, ретрайдан немесе арнайы маппингтен кейін қалған нәрсені көреді. Кейін себепті түсіну қиын: модель қателесті ме, код деректерді үнсіз тазартып жіберді ме, әлде шлюз форматты өзгертті ме.

Бұл әсіресе сұраныстар бірнеше модель мен провайдер арқылы өтетін жүйелерде анық байқалады. Егер сізде AI Router сияқты бір OpenAI-үйлесімді endpoint болса, шикі жауапты, audit log-ты және нормализациядан кейінгі нәтижені бөлек сақтаған дұрыс. Әйтпесе екі түрлі ақау бірдей көрінеді.

Көбіне қателердің екі класын шатастырады. Схема қатесі дегеніміз — инструментті мүлде іске қосуға болмайды: аргументтер толық емес, тип қате, міндетті өріс жоқ. Бизнес-логика қатесі басқа: схема жарамды, бірақ сұраныстың өзі жаман, мысалы аударым сомасы лимиттен жоғары немесе тауар таусылып қалған.

Тағы бір олқылық — команда жүйе сәтсіз шақырудан кейін не істейтінін тексермейді. Ол модельден сұранысты қайталауды сұрай ма? Адамға түсінікті қате қайтара ма? Сол бір шақыруды екінші рет орындай ма? Дәл осы жерде артық есептен шығару, өтінім дубльдері және шатасқан логтар пайда болады.

Тексеруге тұрарлық ең аз нәрсе:

• шикі модель жауабын және нормализация нәтижесін бөлек логтау
• схема қатесін және бизнес-логика қатесін ажырату
• тек қателіктің өзін емес, одан кейінгі мінез-құлықты да тестілеу
• бақылаусыз қайталама шақыру жасалмайтынын тексеру

Релиз алдында жылдам тексеріс

Релиз алдында өндірісте қымбатқа түсетін ақауларды ерте ұстайтын қысқа тест жиынын жүргізу пайдалы. Егер инструмент бір рет бос аргумент алып, тізбек әрі қарай жалғасса, пайдаланушы схема қатесін емес, бұзылған әрекетті көреді: қайталанған төлем, бос іздеу немесе тұрып қалған жауап.

Мәселелер көбіне өте қарапайым. Модель null, бос жол, артық өріс немесе JSON schema сан күтетін жерде жол жібереді. Демода мұндай жағдайлар көп байқалмайды. Жұмыс ағынында олар бірден шығады.

• Әр міндетті аргумент үшін кемінде үш жаман мән беріңіз: null, \"\" және қате тип. Егер amount сан болуы керек болса, жол жіберіңіз. Егер city жол болуы тиіс болса, массив жіберіңіз.
• Артық өрістерді бөлек тексеріңіз. Жүйе сұранысты түсінікті қателікпен тоқтатуы немесе алдын ала сипатталған ереже бойынша мұндай өрістерді құрал шақырылмай тұрып алып тастауы керек.
• Баяу инструменттер үшін күту лимитін қойыңыз. Уақыт бітсе, пайдаланушы не істемей қалғанын және әрі қарай не істеуге болатынын түсінетін нақты мәтін алуы керек.
• Қауіпті операцияларға дубльден қорғаныс қосыңыз. Қайта жасалған есептен шығару, хат жіберу немесе өтінім құру әрекеті екінші рет орындалмауы тиіс.
• Логтар шақырудың бүкіл барысын жинайтынына көз жеткізіңіз: бастапқы сұраныс, таңдалған инструмент, шикі аргументтер, валидация нәтижесі, инструмент жауабы және пайдаланушы көрген мәтін.

Егер команда бірнеше модель қолданса, бұл тексеріс әр байланыс жұбы үшін бөлек қажет. Шақыру форматы бір, ал модельдердің ұсақ қателері әртүрлі. AI Router сияқты ортада бұл ерекше байқалады: бір OpenAI-үйлесімді эндпоинт интеграцияны жеңілдетеді, бірақ әр модельдің мінез-құлқын тексеруді жоймайды. Мұндай прогон бірнеше минут алады. Ал релизден кейінгі инцидентті талдау әлдеқайда ұзаққа созылады.

Әрі қарай не істеу керек

Алғашқы тесттерден кейін бәрін бірден қамтуға тырыспаңыз. Оның орнына 8-12 кейстен тұратын қысқа регрессия жиынтығын жинап, модель, жүйелік промпт және JSON schema өзгерген сайын іске қосып отырыңыз. Бұл әдетте релизге дейін ақаулардың көп бөлігін ұстауға жетеді.

Ондай жиынға тек сәтті жауапты емес, бос аргументтері бар кейстерді, жоғалған міндетті өрісті, артық өрісті, қате типті, инструмент таймаутын және бірдей әрекеттің қайталанған шақыруын енгізіңіз. Егер инструмент ақша есептен шығара алса, тапсырыс статусын өзгертсе немесе хабарлама жіберсе, идемпотенттілікті бөлек тексеріңіз.

Жұмысқа арналған ең аз жиын мынадай көрінеді:

• әр маңызды инструмент үшін бір регрессиялық тест жиыны
• модель, промпт және схема ауысқаннан кейінгі прогон
• таймауттарды, ретрайларды және дубльдерді бөлек тексеру
• логтар мен PII маскалауын бақылау
• схема мен шақыру ережесіне бір жауапты адам

Егер команда бірнеше модельді салыстырса, әр прогон үшін SDK-ны өзгертіп, бөлек интеграциялар жасаудың қажеті жоқ. Бір OpenAI-үйлесімді жолды барлық модельге ортақ ұстап, тек маршрутты ауыстырған оңайырақ. Қазақстан мен Орталық Азиядағы командалар үшін мұны api.airouter.kz арқылы AI Router-мен жинауға болады: код пен SDK сол күйі қалады, ал модельдердің мінез-құлқын бірдей шартта салыстыру әлдеқайда жеңіл.

Логтар жөнінде алдын ала келісіп алған дұрыс, инциденттен кейін емес. Сұраныстар мен жауаптарды қайда сақтайтыныңызды, инструменттің шикі аргументтеріне кім кіре алатынын, логтардың қанша уақыт сақталатынын және жеке деректердің қалай маскаланатынын шешіп қойыңыз. Егер аргументтерге ИИН, телефон, мекенжай немесе медициналық деректер түсуі мүмкін болса, маскалау ережесі әдепкі бойынша жұмыс істеуі тиіс.

Соңғысы: схема, тесттер және ретрай ережелерінің иесі болуы керек. Бір адам немесе бір команда. Әйтпесе схема өзгереді, тесттер артта қалады, ал қайталама шақыру көрші сервистерде әртүрлі әрекет ете бастайды. Практикада продакшанды ең қатты бұзатын да көбіне модельдің өзі емес, осы.