Жеке деректерге қауіп төндірмей промпттарды отладкалау үшін нені сақтау керек

Қай жерде қауіп бар

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

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

Ең жиі кездесетін қате — қауіп тек хабарлама мәтінінде деп ойлау. Шын мәнінде жеке деректер көбіне бір қарағанда көзге түспейтін кәдімгі өрістердің ішінде жатады: профильдегі аты-жөні, өтінім метадеректеріндегі телефон мен email, жеткізу мекенжайы, ИИН, келісімшарт нөмірі, шот немесе паспорт деректері. Әсіресе оператордың еркін түсініктемелері қауіпті. Онда көбіне деректің көбі жиналып қалады.

Екінші мәселе де бар: шикі сұраулар команда ойлағаннан әлдеқайда ұзақ сақталып кетеді. Олар «диагностика үшін бір апта» деп қосылады да, жарты жылдан кейін аналитикада, backup-та және тесттік экспорттарда жатып қалады. Көшірме көп болған сайын, оларға кімнің қолы жететінін және не үшін керегін түсіну қиындай түседі.

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

Банкте, телекомда немесе healthcare саласында бұл өте анық көрінеді: бір дұрыс бапталмаған лог компаниядағы бизнес-функцияның өзінен де көп жеке дерек жинап алуы мүмкін. Сондықтан ережені іске қоспай тұрып анықтап алған дұрыс. Сұраулар AI Router сияқты бір API шлюзі арқылы өтсе де, логтау саясаты, сақтау мерзімі және қолжетімділік бәрібір команданың жауапкершілігінде қалады.

Логтардың үш қабаты

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

Әдетте үш қабат жеткілікті:

• сирек және күрделі инциденттерді талдауға арналған шикі сұрау
• күнделікті отладка мен сапаны талдауға арналған маскаланған көшірме
• мәтінсіз жалпы көрініс беретін агрегатталған метрикалар

Шикі қабат күнде қажет емес. Оған команда күмәнді жауапты, құралдар тізбегіндегі ақауды немесе обезличенный нұсқадан түсініксіз шағымды көргенде жүгінеді. Сондықтан мұндай қабатты өте қысқа уақыт сақтау дұрыс — бірнеше сағаттан бірнеше күнге дейін. Қолжетімділікті тек кезекші инженерлерге және инцидентті талдауға ресми құқығы бар адамдарға берген жөн. Компания сезімтал деректермен жұмыс істесе, шикі қабатты кәдімгі логтардан бөлек сақтап, оны кім және не үшін ашқанын жазып отырыңыз.

Маскаланған көшірме ұзақтау өмір сүреді. Дәл осы нұсқада әзірлеушілер әдетте промпттағы әлсіз тұстарды іздейді: модель контексті қай жерде жоғалтады, рөлдерді қай жерде шатастырады немесе жауап форматты сақтамай қояды. Бұл нұсқада есімдер, телефондар, email, ИИН, келісімшарт нөмірлері және басқа идентификаторлар [NAME] немесе [ACCOUNT_ID] сияқты түсінікті маркерлермен алмастырылады. Мәтін пайдалы болып қалады, бірақ адамды тікелей әшкерелемейді.

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

Әр қабат үшін жеке сақтау мерзімін және жеке қолжетімділік шеңберін белгілеңіз. Шикі деректердің мерзімі ең қысқа, қолжетімділік ең тар болуы керек. Маскаланған логтардың мерзімі орташа. Ал метрикалардың мерзімі ең ұзақ, қолжетімділігі ең кең болады.

Егер AI Router арқылы airouter.kz қолдансаңыз, мұны бірден келісіп алған жөн: PII маскалау қай жерде қосылады, аудит-логтарды кім көреді және шикі сұраулардың өзі қанша уақыт өмір сүреді. Шлюз операциялық тәуекелдің бір бөлігін азайтады, бірақ ішкі сақтау саясатын алмастырмайды.

Шикі қабатта нені қалдыру керек

Шикі сұрау аналитика үшін емес, жауап бұзылған сирек талдаулар үшін керек. Сондықтан ақауды қайта шығару үшін міндетті нәрсені ғана сақтаңыз. Қалғанының бәрін маскаланған қабатқа немесе метрикаларға шығарған дұрыс.

Ыңғайлы минимал жиынтық мынадай көрінеді:

• system prompt мәтіні бөлек өрісте
• user prompt мәтіні бөлек өрісте
• tool calls және құралдардың жауаптары диалог мәтінінен бөлек
• модель атауы, версиясы, провайдер және сұраудың нақты маршруты
• шақыру параметрлері: temperature, max tokens, top_p және мінез-құлыққа шынымен әсер ететін басқа мәндер
• кіріс және шығыс токен саны, жауап коды, жауап беру уақыты және request id

Осындай бөлу талдауды жеңілдетеді. Егер model switch-тен кейін system prompt өзгерісі салдарынан мінезі бұзылса, ол бірден көрінеді. Егер ақау tool call-дан шықса, оны мәтін, рөлдер және қызметтік өрістер араласқан үлкен JSON ішінен іздеудің қажеті жоқ.

Шикі қабатқа бәрін көшіре бермеңіз. Тіркемелерді, файлдарды, суреттерді, құжат скандарын, клиент профилінің ұзақ нұсқаларын және CRM тарихын түгел сол жерге салудың қажеті жоқ. Қателерді іздеу үшін көбіне объектке сілтеме, оның түрі, өлшемі, MIME type-і және өңдеу статусы жеткілікті. Файл бүлінсе, паспорттың немесе анықтаманың көшірмесін сақтамай-ақ түсінесіз.

Дәл осы ереже клиент деректеріне де қатысты. Түгел профильді, мекенжайды, карта нөмірін және барлық өтініш тарихын логқа жазудың қажеті жоқ. Егер талдау үшін контекст маңызды болса, қысқа техникалық өрістерді ғана қалдырыңыз: internal user id, сегмент, тіл, арна, сценарий версиясы. Әдетте осының өзі жетеді.

Егер команда бір LLM шлюзін қолданса, тек сыртқы endpoint-ті емес, сұрау нақты қай модель мен провайдерге кеткенін де сақтаған пайдалы. Әйтпесе кез келген талдау «бәрі бір API арқылы өтті» деген сөйлемге тіреліп қалады, ал бұл ештеңені түсіндірмейді.

Шикі мәтінді таймер арқылы өшірген дұрыс. Қолмен емес, «кейін тазалаймыз» деген логикамен емес, TTL және автоматты тазалау арқылы. Көп команда үшін 7–30 күн жеткілікті, егер инциденттер тез талданса. Ұзағырақ мерзім тек нақты негізі бар бөлек жағдайларда сақталады. Мұндай тәртіпті тексеру оңай, қауіпсіздікке түсіндіру оңай және кездейсоқ бұзу әлдеқайда қиын.

Маскаланған көшірмені қалай жасау керек

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

Сезімтал бөліктерді қарапайым белгілермен алмастырған дұрыс. Атауды [NAME]-ға, телефонды [PHONE]-ға, поштаны [EMAIL]-ге, ИИН-ді [IIN]-ге ауыстыруға болады. Мәтінде карта нөмірі, мекенжай немесе келісімшарт нөмірі кездессе, олар үшін де өз тегіңіз болғаны дұрыс.

Мақсат фразаны бос шаблонға айналдыру емес. Құрылымды сақтаңыз. Егер қолданушы: «Менің атым Айжан, ИИН 990101300123, өтінім статусын тексеріңіз» деп жазса, логта: «Менің атым [NAME], [IIN], өтінім статусын тексеріңіз» деп қалдырған дұрыс. Сонда модельдің қай жерде қателескені көрінеді: entity тануда ма, сұрауды бағыттауда ма, әлде жауапта ма.

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

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

Тағы бір жағымсыз тұзақ бар: маскалау көбіне бұрыс енгізуді жіберіп алады. Адамдар email-ді бос орынмен жазады, телефонда ел коды болмайды, ИИН-ге артық таңба қосылады. Скандағы OCR шуылы да қосылады: «8» әріпке ұқсап кетеді, «@» түсіп қалады, есім бөлшектеніп кетеді. Сондықтан маскалауды қате жазбалармен, аралас тілмен және құжат танылғаннан кейінгі мәтінмен тексерген жөн.

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

Мәтінсіз қандай метрикаларды санауға болады

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

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

Көбіне бес метрика тобы жеткілікті:

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

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

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

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

Қолмен түзету жиілігі «қате/қате емес» деген құрғақ статусқа қарағанда шынайы сапаны жақсы көрсетеді. Егер банк операторы модель жауабын 40% жағдайда өзгертіп отырса, формальды ақаулар аз болса да, промпт әлі шикі. Түзетудің тереңдігін де санаған дұрыс: бір дата түзету мен жауапты толық қайта жазу — екі түрлі мәселе.

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

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

Қадамдап қалай енгізу керек

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

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

1. Шикі қабатты ең тар етіп қалдырыңыз. Ақауды талдауға міндетті нәрсені ғана сақтаңыз: сұрау ID, уақыт, модель, system prompt, пайдаланушы енгізуі, жауап, қате коды және шақыру параметрлері. Сақтау мерзімі қысқа болсын.
2. Маскаланған қабатты журналға жазбас бұрын жасаңыз, жазып болған соң емес. Егер сұрауда аты, телефон, ИИН, карта нөмірі немесе мекенжай болса, сервис бұл бөліктерді логқа түспей тұрып-ақ белгілермен алмастыруы тиіс.
3. Метрикаларды бөлек ұстаңыз. Оған мәтін керек емес. Сұрау ұзындығы, токен саны, кідіріс, қате үлесі, құн және егер бар болса, сапа бағасы жеткілікті.
4. Схеманы бір түсінікті сценарийде тексеріңіз. Мысалы, бір типтегі пайдаланушы сұрауының ағынын алыңыз да, оны бүкіл тізбекпен өткізіңіз: қабылдау, маскалау, логқа жазу, метрика жинау, инцидентті талдау.
5. Қамтуды қысқа тексерістен кейін ғана кеңейтіңіз. Әзірлеуші, қауіпсіздік маманы және өнім иесі бір қарапайым сұраққа жауап берсін: қателіктің себебін артық жеке деректерсіз табуға бола ма.

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

Банктік чат-бот мысалы

Клиент банк чатына: «Сәлеметсіз бе, мен картаны қайта шығарудың статусын көріп тұрған жоқпын. Менің атым Алия, телефоным 8 701 123 45 67» деп жазады. Команда үшін бұл — кәдімгі қолдау сұрауы. Логтау үшін — пайдалы сигнал мен жеке деректің араласуы.

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

Шикі қабат тек сирек ақаулар үшін керек. Оған банк prompt ID, таңдалған модель, сұрау уақыты, техникалық статус және мәтіннің өзін қысқа сақтау терезесімен — мысалы, 24 сағатқа немесе ішкі ережеге сай бірнеше күнге — жазады. Бұл нақты ақауды талдауға жетеді: модель клиенттің ниетін түсінбеді ме, артық сұрақ қойды ма, әлде жауап беру кезінде тұрып қалды ма.

Қатарлас жүйе маскаланған көшірме жасайды. Онда клиенттің фразасы енді былай көрінеді: «Сәлеметсіз бе, мен картаны қайта шығарудың статусын көріп тұрған жоқпын. Менің атым [NAME], телефоным [PHONE]». Диалогта келісімшарт нөмірі, ИИН немесе мекенжай болса, олар да белгілермен ауыстырылады. Сұраудың мағынасы сақталады, ал жеке деректер кетеді.

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

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

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

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

Командалар қай жерде қателеседі

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

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

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

Төртінші қате логқа бүкіл контекстті ойланбай тыққанда шығады. Оған system prompt, хат алмасу тарихы, RAG іздеу нәтижелері және тіркелген файлдар кіріп кетеді. Осындай бір сәтсіз debug dump бүкіл жеке деректер архивіне айналып кетеді.

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

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

Іске қоспас бұрын тексеру

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

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

Іске қоспай тұрып мыналарды тексерген жөн:

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

Тәжірибеде көбіне екінші және төртінші тармақтан құлайды. Команда email-ді маскалайды, бірақ келісімшарт нөмірін, сирек мекенжайды немесе дәрігердің тегін қамтитын еркін комментарийді қалдырады. Формалды түрде дерек «анонимдендірілген», бірақ адамды әлі де тануға болады. Қолжетімділікпен де ұқсас жағдай: бір ортақ логты аналитик, әзірлеуші және қолдау мердігері көрсе, шынайы бөліну жоқ.

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

Егер сіз AI Router арқылы airouter.kz негізінде LLM-интеграцияларды іске қоссаңыз, алғашқы прод-трафикке дейін мына төрт нәрсені бөлек тексеріңіз: шикі сұраулар қайда сақталады, PII маскалауы қалай қосылған, аудит-логтарды кім көреді және қандай дерек ел ішінде сақталуы тиіс. Мұны тірі трафикте қайта жасатқаннан гөрі алдын ала шешкен дұрыс.

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

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

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

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

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

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