Инциденттерді 5 минутта талдау үшін аудит-логтарды қалай қолдану керек

Пайдаланушы шағымынан кейін не болады\n\nШағым көбіне нашар күйде келеді: «бот бөтен деректерді көрсетті», «жауап біртүрлі болды», «керек блок жоғалып кетті». Пайдаланушыда request_id, модель атауы мен промпт нұсқасы болмайды. Оның қолында тек уақыт, скриншот және ашу-ыза бар.\n\nТикетті алдымен қолдау қызметі көреді, бірақ толық сурет әдетте оларда да болмайды. Олар аккаунтты, шамамен уақытты және шағым мәтінін біледі. Бұл аз. Егер лог сессияны, пайдаланушыны, API-кілтті және нақты сұрауды байланыстырып тұрмаса, алғашқы минуттар чаттарды, кестелерді және команданың жадысын ақтаруға кетеді.\n\nКейін әзірлеуші қосылып, бірнеше қарапайым сұрақ қояды. Модельге нақты қандай сұрау кетті? Қандай жүйелік промпт қосылды? Сол сәтте шаблонның қай нұсқасы жұмыс істеп тұрды? Шлюз қай модель мен қай провайдерді таңдады? Егер сұраулар бір LLM-шлюз арқылы өтсе, дәл із қалдырмай модельді де, провайдерді де, шақыру параметрлерін де оңай шатастырып алуға болады.\n\nОсы жерде дауласу тым ерте басталады. Бір адам ескі промпт іске қосылды деп сенеді. Екіншісі кеше маршрутизацияны өзгерткенін есінде ұстайды. Үшіншісі кінәлі кэш деп ойлайды. Логсыз команда тек есіне түсіреді, тексермейді.\n\nСондықтан «инциденттерді талдау үшін аудит-логтарды қалай қолдану керек» деген сұрақ іс жүзінде бір қарапайым нәрсеге тіреледі: бір сұраудың түсінікті тарихын бес минутта қалпына келтіре аласыз ба. Егер болмай тұрса, инцидент бірден жоғарыға өтеді де, команда әлі із кесіп жүреді.\n\nӘдетте талдауға бірден бірнеше рөл қатысады:\n\n- қолдау инцидент кімге әсер еткенін және пайдаланушыға не деп жауап беру керегін білгісі келеді;\n- әзірлеуші промпт, модель және параметрлердің нақты комбинациясын қалпына келтіргісі келеді;\n- қауіпсіздік жеке деректер болды ма және оларды кім көрді ме, соны тексереді;\n- заң және комплаенс чаттағы әңгіме емес, әрекеттердің нақты ізін күтеді.\n\nҚарапайым жағдайды елестетіңіз: менеджер ассистент қате тапсырыс нөмірін көрсетті деп жазады. Егер аудит-лог дұрыс жиналса, команда бірнеше минутта бастапқы сұрауды, қосылған нұсқаулықтарды, модель жауабын және жүйедегі кейінгі әрекеттерді көреді. Ондай із болмаса, бір инцидент оқиғалардың бірнеше нұсқасына айналады да, әрқайсысы уақыт жейді.\n\n## Лог бірден қандай сұрақтарға жауап беруі керек\n\nШағымнан кейін командада әдетте терең қазуға бір сағат жоқ. Жақсы аудит-лог бес минут ішінде бұл бұзылу ма, баптау қатесі ме, әлде модельдің даулы жауабы ма — соны көрсетуі керек.\n\nБірден бес сұрақ жабылуға тиіс.\n\n1. Сұрауды кім жіберді. user_id, tenant_id және API-кілт идентификаторы жоқ болса, инцидент тез арада жорамалға айналады. Бірнеше клиенті және ортасы бар жүйелерде бұл өрістер бірден пайдаланушы трафигін тесттер мен ішкі дебагтан бөледі.\n2. Бұл қашан болды. Лог нақты UTC уақытын және түсінікті жергілікті көрсетілімді сақтауы керек. Әйтпесе «кеше 19:40-та» деген шағым бүкіл оқиға тізбегімен бірге оңай екі сағатқа сырғып кетеді.\n3. Сұрау қайда кетті. Жауапты тек «LLM» берді білу жеткіліксіз. Қызметті, маршрутты, модельді, провайдерді және аймақты көру керек. Шлюз үшін бұл әсіресе маңызды: сұрау ережелер, фолбэк немесе конфигурацияның қолмен өзгеруі салдарынан басқа жаққа кетуі мүмкін.\n4. Жүйе не жіберді және не алып қайтты. Барлық мәтінді тұтастай сақтаудың қажеті жоқ, бірақ кіріс пен шығыстың маскаланған үзінділері, шақыру параметрлері, тіркеме түрі және жауап статусы керек. Әйтпесе модель қателесті ме, әлде жүйе сұрауды жіберер алдында бұрмалады ма — түсініксіз қалады.\n5. Инцидентке дейін не өзгерді. Егер біреу шағымға дейін он минут бұрын маршрутты, лимитті, маскалау ережесін немесе рұқсат етілген модельдер тізімін өзгерткен болса, лог мұны актор атымен және уақытымен бірден көрсетуі тиіс.\n\nБұл жауаптар бірден көрінсе, команда мәселені іздеуге емес, шешуге уақыт жұмсайды.\n\n## Аудит-логқа не жазу керек\n\nЕгер логта идентификаторлар болмаса, команда жорамалға уақыт жұмсайды. Әр жазба бір қарапайым сұраққа жауап беруі керек: бұл дәл сол сұрау ма, әлде қасында тұрғаны ма.\n\nrequest_id және trace_id-дан бастаңыз. Біріншісі нақты шақыруды табуға көмектеседі. Екіншісі бірнеше сервис болса, бүкіл тізбекті жинайды: API-шлюз, оркестратор, құрал, база, модерация. Пайдаланушы бір жауапқа шағымданғанда trace_id көбіне талдаудың жартысын үнемдейді.\n\nҚасында user_id, tenant_id және API-кілт идентификаторы керек. Сонда сұрауды кім жібергені, ол қай ұйымнан келгені және қандай қолжеткізу қолданылғаны бір минутта түсінікті болады. B2B-сценарийлерде бұл әсіресе маңызды: бір модель ондаған командаға қызмет етуі мүмкін, ал жалдаушыларды шатастыру бүкіл талдауды бұзады.\n\nЖазба жауапқа қандай код әсер еткенін де белгілеуі керек. Мұнда минимум мынадай: промпт нұсқасы, жауап шаблоны және қызмет немесе воркер атауы. Бұл өрістерсіз қате фактісін көресіз, бірақ жүйе неге дәл сондай мәтін шығарғанын түсінбейсіз. Егер кеше команда жүйелік промптты өзгерткен болса, лог мұны репозиторийге кірмей-ақ көрсетуі керек.\n\nМаршрутизация үшін бөлек блок қажет. Модельді, провайдерді, аймақты және маршрут нұсқасын сақтаңыз. Бұл бір сұрау әртүрлі жолмен кете алатын кезде өте пайдалы. Егер жүйе ортақ шлюз арқылы жұмыс істесе, команда тек модель атын ғана емес, шақыру қай провайдер арқылы өткенін де көруі тиіс.\n\nСұрау мен жауап мәтіні де керек, бірақ шикі күйде емес. Кіріс пен шығыстың маскаланған үзінділерін, мысалы алғашқы 200-500 таңбаны сақтаған дұрыс. PII-ді бірден жабу керек, ал сезімтал өрістерді белгілермен алмастыру қажет. Бұл диалогтың мағынасын түсінуге жетеді әрі логқа артық тәуекел тастамайды.\n\nЖазбаның соңында операциялық өрістерді қалдырыңыз: кезеңдер бойынша кідіріс пен жалпы latency, кіріс және шығыс токендер саны, атауы мен статусы бар құрал шақырулары, қате коды және қысқа себеп. Осындай жинақ шағымнан кейінгі алғашқы сұрақтардың көбін жабады: сұрауды кім жіберді, жүйе не көрді, қайда бағыттады, қандай код іске қосылды және қай сатыда бәрі дұрыс болмады.\n\n## Бір оқиға тізбегін қалай жинау керек\n\nПайдаланушы шағымданғанда команда «барлық логтарды» емес, бір ғана сұрау тарихын іздейді. Ол кіру нүктесінен басталып, адам экранда көрген немесе API арқылы алған жауапқа дейін жетуі керек.\n\nБұл үшін сұраудың бүкіл жолына бір request_id қажет. Оны кіріс кезінде жасаңыз да, шлюз, маршрутизация, тексерулер, модель шақырулары, кейінгі өңдеу және жауап жіберу арқылы өткізіп отырыңыз. Егер сұрау AI Router сияқты OpenAI-үйлесімді шлюз арқылы өтсе, бұл идентификатор сіздің сервистен шлюзге және провайдерге дейін жоғалмауы тиіс.\n\nЕгер жүйе ретрай жасаса немесе құралдарды шақырса, бір ғана ортақ идентификатор аздық етеді. Әр қайталау әрекетінің өз retry_id-і, ал әр құрал шақыруының өз tool_call_id-і болуы керек. Сонда бірінші сұрау таймауттан құлағаны, екіншісі басқа модельге кеткені, ал үшіншісі пайдаланушыға жауап бергені көрінеді.\n\nПайдаланушы сұрауы мен провайдер жауабының байланысы да «уақыты шамамен сәйкес келді» дегендей болмауы керек. Логтарда сыртқы provider_request_id, модель атауы, жауап статусы, тоқтау себебі және әр қадамдағы уақыт белгілері пайдалы. Бұларсыз команда қате қайда болды деп дауласады: сіздің кодыңызда ма, роутерде ме, әлде провайдерде ме.\n\nСол сәтте нәтижеге әсер етуі мүмкін барлық өзгерістерді бөлек белгілеңіз. Егер сервис промптты ауыстырса, модельді переключілесе, қолжеткізу ережелерінің басқа жиынтығын қосса немесе жаңа маскалау саясатын қолданса, лог мұны уақытпен бірге анық көрсетуі керек.\n\nӘдетте бес байланыс жеткілікті:\n\n- бүкіл тізбекке арналған ата-ана request_id;\n- ретрайлар мен құрал шақыруларына арналған еншілес идентификаторлар;\n- сыртқы модель жауабы үшін provider_request_id;\n- промпт нұсқасы, модель және қолжеткізу ережелерінің нұсқасы;\n- баптауларды кім және қашан қолмен өзгерткені.\n\nПанельдегі қолмен жасалған әрекеттер талдауды көбіне кодтан да қатты бұзады. Біреу 14:03-те қолжеткізу ережесін өзгертті, ал шағым 14:07-де келді. Егер мұндай әрекеттерді қызметкердің атымен, уақытымен және бұрынғы мен жаңа мәнімен логтамасаңыз, команда жарты сағатын жорамалдауға жұмсайды.\n\nЖақсы оқиға тізбегі бір сұраққа жауап береді: осы сұраумен нақты не болды, қадам-қадамымен. Егер кез келген қадамды алдыңғысымен байланыстыру мүмкін болмаса, тергеу бірден баяулайды.\n\n## Бес минутта қалай талдау жасау керек\n\nШағымнан кейін бірден дәл себепті дәлелдеудің қажеті жоқ. Алдымен тұманды сейілту керек: нақты не болғанын, қай жерде болғанын және әрі қарай нені тексеру керегін түсіну керек.\n\nБірінші минут бір тірек идентификаторын іздеуге кетеді. Ең жақсысы — тикеттен, клиенттік логтан немесе қате хабарламасынан алынған request_id. Егер ол жоқ болса, оқиға уақыты мен user_id бойынша іздеңіз, бірақ бұл баяуырақ және жиі артық сәйкестік береді.\n\nЕкінші минутта сұраудың контекстін тексеріңіз. Оны кім жіберді, қай tenant_id ішінде, қандай API-кілтпен және қай уақытта. Мұнда көбіне қарапайым себеп шығады: шағым бір пайдаланушыдан келді, бірақ лог басқа аккаунтқа, тесттік кілтке немесе көрші ортаға қатысты болып шығады.\n\nКейін сұрау маршрутын қалпына келтіріңіз. Төрт нәрсе керек: сұрауды қай сервис қабылдады, қай модель жауап берді, шақыру қай провайдер арқылы өтті және бұл қай аймақта болды. LLM-жүйелер үшін бұл ұсақ нәрсе емес. Бірдей промпт басқа модельге немесе басқа backend-ке кеткенде мүлде бөлек нәтиже беруі мүмкін.\n\n### Талдаудың ортасында нені қарау керек\n\nЕнді маскаланған кіріс пен шығысты салыстырыңыз. Логты роман сияқты оқымаңыз. Сұрау пайдаланушының шағымына сай келе ме, қайталау болды ма, препроцессингтен кейін промпт өзгерді ме, жауап модельге дейін қате берілді ме, әлде жауаптан кейін бе — соны тексеріңіз. Егер пайдаланушы «ассистент бөтен деректерді жауап берді» десе, тек жауап мәтінін емес, араласқан контексттің іздерін де іздеңіз.\n\nСосын құрал шақыруларын, кэшті және лимиттерді ашыңыз. Мәселе көбіне модельде емес, жүйенің ескі кэш алуы, қате құралға сұрау жіберуі, rate limit-ке соғылуы немесе таймауттан кейін сұрауды қайталауында болады. AI Router сияқты шлюзде мұндай іздер ерекше пайдалы, өйткені бір request_id бірнеше маршрутизация қабатынан өтуі мүмкін.\n\nБесінші минутқа қарай сізде себептің алғашқы жұмыс нұсқасы болуы керек. Соңғы үкім емес, қысқа жазба: «сұрау басқа кілт арқылы өтті», «жауап кэштен келді», «құрал бөтен контекст қайтарды», «провайдер жаңа нәтижемен қайталап жіберді». Қасына келесі қадамды жазып қойыңыз: кэшті өшіру, tenant_id бойынша оқшаулауды тексеру, толық trace көтеру немесе backend командасынан шикі лог сұрау.\n\n## Мысал: ассистент бөтен деректерді жауап берді\n\nМұндай шағым әдетте қысқа және қатқыл естіледі: пайдаланушы ассистент оның телефон нөмірін, мекенжайын немесе шарт нөмірін көрсеткенін жазады. Бұл сәтте сезімге қарсы пікір айтудың пайдасы жоқ. Жедел түрде дерек ағып кетті ме, ақпарат қайдан келді және нақты не бұзылды — соны түсіну керек.\n\nLLM аудит-логтары шағымды бірден нақты сессиямен байланыстыруы керек. Егер жазбада tenant_id, session_id және дерек көзі болса, команда негізгі көріністі тез көреді: сұрау қай контурда жұмыс істеді, оны қандай сессия жіберді және ассистент жауабын қайдан алды. Дәл осы қадамда көбіне ең жағымсыз нәрсе көрінеді. Мысалы, сессия tenant_id банк A-ға тиесілі, ал құрал басқа tenant_id-дің CRM жазбасын қайтарды. Бұл енді «галлюцинация» емес, деректерді оқшаулаудағы қате.\n\nКелесі қадамда құрал шақыруы қаралады. Лог қандай іздеу жұмыс істегенін көрсетуі керек: векторлық па, SQL ме, CRM API ме, әлде ішкі каталог па. Құрал атауы, сұрау параметрлері, табылған record_id жинағы және авторизация статусы пайдалы. Сонда сурет тез жиналады. Ассистент бөтен өрістерді ойлап тапқандықтан емес, backend tenant_id бойынша фильтрсіз іздегеннен кейін артық клиент карточкасын қайтарған болуы мүмкін.\n\nПромпт нұсқасы да көп нәрсені өзгертеді. Егер кеше команда tool calling ережесін жаңартса, бұл бірден көрінуі тиіс. Айталық, prompt_version v17-де CRM бойынша жазба иесін тексермей жауап беруге қатаң тыйым болған, ал v18-де бұл қадам байқаусызда алынып тасталды. Онда себеп модельде де, индексте де емес, бизнес-логиканың өзгеруінде болады.\n\nСоңғы тексеру — жауаптың маскаланған бөлігі. Ол жаңа дерек таратпай-ақ инцидент фактісін растайды. Логта «Сіздің нөміріңіз: +7 7XX XXX 12 34, шарт N ***5481» сияқты үзінді жеткілікті. Бұл пайдаланушының дұрыс айтқанын түсіну үшін де, жеке деректерді чаттарға таратпау үшін де жетеді.\n\nЕгер платформа PII-ді тікелей аудит-логтардың өзінде маскалайтын болса, талдау әлдеқайда тыныш өтеді. Инженер фактіні, көзді және промпт нұсқасын көреді, бірақ бөтен деректерді әрі қарай көшіріп жүрмейді.\n\n## Командалар уақытты қай жерде жоғалтады\n\nКоманда сағаттарын көбіне қатенің өзіне емес, тым аз жауап беретін логқа жұмсайды. Шағым қазірдің өзінде келді, пайдаланушы түсіндіруді күтеді, ал инженерлер алдымен не болғанын түсінуге тырысады.\n\nЕң жиі кездесетін сәтсіздік қарапайым: лог тек сұрау статусын және қате кодын сақтайды. Құлаулар үшін бұл кейде жеткілікті. Ал «ассистент дұрыс емес деректерді көрсетті» немесе «кеше релизден кейін жауап күрт өзгерді» сияқты шағымдар үшін мұндай лог дерлік бос. 200 коды қандай промпт жұмыс істегенін, қай модель жауап бергенін, ережелерде не өзгергенін және PII маскировкасы өтті ме — соны айтпайды.\n\nLLM-жүйелерде бірнеше сервис уақытты әртүрлі жазса, шатасу тез өседі. Бір сервис жергілікті уақытты жазады, екіншісі UTC, үшіншісі секундты дөңгелектейді. Сосын команда үш жазбаны қарап, алдымен не болғанын дауласады: жүйелік промпттың ауысуы ма, пайдаланушы сұрауы ма, әлде модель жауабы ма. Осындай бір салыстыруға оңай 20 минут кетеді.\n\nТағы бір жиі бос орын: сұраулар промпттар, модерация ережелері, маршрутизация және шаблон нұсқаларынан бөлек сақталады. Онда тергеу бірнеше жүйеден пазлды қолмен құрастыруға айналады. Егер сұрау шлюз арқылы өтіп, содан кейін деректерді маскалап, одан кейін постөңдеуден өтсе, ортақ оқиға тізбегінсіз ешкім ақау қай сатыда пайда болғанын тез түсінбейді.\n\nЖеке деректері бар шикі мәтіндер де уақыт ұрлайды. Мұндай логты кең командаға беруге қорқынышты, сондықтан қолжетімділік екі-үш адамға ғана тарылады. Содан кейін скриншот жіберу, қолмен өңдеу және күту басталады. Қауіпсізірегі — барлығын сол күйі тастай салмай, маскаланған өрістер мен метадеректерді сақтау.\n\nСақтау мерзімі іске кіріспей тұрып-ақ талдауды бұзады. Пайдаланушы дүйсенбіде шағымданды, қолдау сәрсенбіде эскалация жасады, инженерлер бейсенбіде логты ашты, ал қажет жазбалар 48 сағаттан кейін өшіп қалған. Содан кейін команда фактімен емес, жадымен дауласады.\n\nТағы бір жері қарапайым: лог схемасының иесі жоқ. Әр команда өрістерді өзінше жазады, атауларын ескертусіз өзгертеді және жазбалардың сапасын тексермейді. Бір айдан кейін request_id бәрінде болмай қалады, промпт нұсқасы кейбір сұрауларда жоғалады, ал модель өрісі бір сервисте model, екіншісінде provider_model деп аталады. Мұндай логта тек уақыт емес, қорытындыға деген сенім де жоғалады.\n\n## Инциденттерді логтаудың чек-парағы\n\nЖақсы лог қолдау, ML-команда және backend арасында хат алмасусыз-ақ алғашқы сұрақтарға жауап береді. Егер пайдаланушы қате уақытты, request_id немесе user_id жіберсе, инцидент жүздеген жазбаны қолмен қарау арқылы емес, бірнеше іздеумен табылуы керек.\n\nЖылдам тексеріс әдетте алты тармаққа келеді:\n\n- жазба request_id, user_id немесе дәл уақыт терезесі бойынша табылады;\n- tenant_id, API-кілт, орта және сұрау көзі көрінеді;\n- промпт нұсқасы, модель, провайдер және орындалу маршруты бар;\n- шағымның мәнін PII-ді ашпай түсіну үшін маскаланған кіріс пен шығыс сақталған;\n- ретрайлар, кэш, құрал шақырулары және rate limit іске қосылуы белгіленген;\n- жүйелік оқиғалар қызметкерлердің қолмен жасаған әрекеттерінен бөлек тұр.\n\nСоңғы тармақты жиі төмен бағалайды. Егер қолдау қызметкері тапсырманы қайта іске қосса, промптты ауыстырса, құралды өшірсе немесе лимитті уақытша көтерсе, бұл адамның аты-жөні және әрекет уақытымен бөлек журналда тұруы керек. Әйтпесе команда модель туралы дауласады, ал шын бұзылу қолмен араласудан туған болады.\n\nТолық мәтінді сақтау қауіпті, ал бос лог пайдасыз. Жұмыс істейтін ымыра қарапайым: PII-ді жасырыңыз, бірақ сұрау құрылымын, қызметтік өрістерді, мәтін ұзындығын, құрал атауларын, кэш статусын және модель жауабының кодын қалдырыңыз.\n\nЕгер осы сәтте өрістердің кемінде жартысын көрмесеңіз, пайдаланушы шағымдарын талдау қазірдің өзінде баяулайды. Демек келесі инцидентті қайтадан бөлшектеп жинауға тура келеді.\n\n## Әрі қарай не істеу керек\n\nЕгер шағымнан кейін команда әлі де чаттар, кестелер және скриншоттар арқылы жауап іздесе, мәселе адамдарда емес. Мәселе — лог бір түсінікті сұрау тарихын жинамайды.\n\nКішкентайдан бастаңыз: бір міндетті өрістер жиынын және бір атау схемасын бекітіңіз. Тіпті request_id сияқты ұсақ нәрсе барлық сервисте бірдей аталуы керек, бір жерде requestId, бір жерде req_id болмауы тиіс. Әр жазба үшін әдетте сұрау идентификаторы, қауіпсіз пайдаланушы идентификаторы, оқиға уақыты, промпт нұсқасы, модель, API-кілт, жауап статусы, қолмен әрекет белгісі және егер оқиға басқа жазбаны жалғастырса parent_event_id қажет.\n\nСосын үш соңғы шағымды алып, осы схема арқылы өткізіңіз. Бірінші түсінікті жауапқа дейін қанша уақыт кететінін өлшеңіз: пайдаланушы не жіберді, сұрауды қай модель өңдеді, тізбек дәл қай жерде бұрылды. Егер бұған бес минуттан көп кетсе, LLM аудит-логтары әзірге мәселені шешпейді.\n\nКөбіне уақыт күрделі ақауларда емес, соқыр аймақтарда жоғалады. Командалар әдетте сүрінетін жерлерді тексеріңіз:\n\n- өнімде, шлюзде және сақтаудағы уақыт белдеулері сәйкес келмейді;\n- ретрайлар мен қайталап жіберулер бөлек инцидент сияқты көрінеді;\n- жүйелік промпт немесе шаблон ауысуы еш жерде жазылмайды;\n- қолдаудың қолмен әрекеттері жалпы тізбектен бөлек өмір сүреді.\n\nИнцидент бойынша алғашқы қорытындыны бес минутта жазатын бір адамды белгілеңіз. Толық талдау емес, қысқа жазба: таймлайн, әсер еткен пайдаланушылар, ықтимал себеп және логта не жетіспейтіні. Мұндай ырғақ ұзақ талқылаудан гөрі әлсіз тұстарды тезірек көрсетеді.\n\nЕгер команда AI Router арқылы жұмыс істесе, бұл схемаға PII маскировкасы, аудит-логтар, кілт деңгейіндегі rate limits және деректерді Қазақстан ішінде сақтау бұрыннан қосылғанын алдын ала тексерген пайдалы. Жергілікті заң талаптары мен даулы жауаптарды із қалдырмай талдау маңызды командалар үшін мұндай нәрсе екінші кезектегі бөлшек емес. airouter.kz сайтында мұндай бақылау қабатын продакшеннен бөлек тарих ретінде емес, жалпы архитектураның бөлігі ретінде қолдануға болады.\n\nБір аптадан кейін сол тестті тағы үш шағыммен қайталаңыз. Егер команда әртүрлі жүйелерді қолмен ақтармай-ақ тізбекті жинай алса, сіз дұрыс бағыттасыз. Егер олай болмаса, келесі инцидент сол олқылықты қымбаттатып жібермей тұрғанда, жетіспейтін өрісті қазірден қосыңыз.