LLM істен шыққаннан кейінгі postmortem: қандай өрістерді тіркеу керек

Ақаудан кейін бөлшектер неге тез ұмытылады

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

LLM жүйелерінде бұл қарапайым веб-сервиске қарағанда көбірек байқалады. Бір сұраныс көбіне бірнеше қабаттан өтеді: қолданба, API шлюз, прокси, модель провайдері, кэш, қауіпсіздік сүзгілері. Әр қабаттың өз уақыты, өз request ID-і және өз лог форматы бар. Егер команда бір шлюзді, мысалы AI Router-ды қолданса, кейін тағы қолданба мен провайдер логтарына қараса, бір ғана қате үш бөлек оқиға сияқты көрініп кетуі мүмкін.

Кері қайтарудан кейін сурет одан әрі бұзылады. Инженер ескі промптты қайтарды, feature flag-ты өшірді, модельді ауыстырды, лимиттерді түзетті — жүйе қайта жұмыс істей бастады. Продакшен үшін бұл дұрыс. Тергеу үшін — жоқ. Бастапқы күй тез жоғалады. Күн соңына дейін JSON-ды қай схема күтті, ақау кезіндегі system prompt қандай болды, сол трафикке қандай маршрут таңдалды — соны қалпына келтіру қиынға соғады.

Көбіне алғашқы сағатта мынадай детальдар жоғалады:

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

Факт аз болса, команда әдетте себеп туралы дауға кетеді. Бір адам модельді кінәлайды, екіншісі — жаңа парсерді, үшіншісі — желіні немесе rate limit-ті. Әңгіме созылады, ал түзету кейінге қалады. LLM инцидентін талдау дәл осы жерде бұзылады: шаблоннан емес, тірек жоғалғаннан.

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

LLM жүйесінде нені инцидент деп санау керек

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

LLM postmortem үшін кең ережені алған дұрыс: егер жүйе қымбаттап, баяулап, қауіпті болып немесе сапасы едәуір нашарлап кетсе, оқиғаны тіркеу керек. Әйтпесе команда тек «сервис жауап бермеді» деп есте сақтайды да, шынайы себеп бір күннен кейін-ақ көмескіленіп кетеді.

Жиі жіберілетін қате — тек техникалық қолжетімділікке қарау. LLM жүйесі 200 OK қайтара алады, бірақ соған қарамастан өнімді бұзады. Қарапайым мысал: чат жауапты сәтті берді, бірақ JSON парсингтен өтпеді, себебі модель артық мәтін қосты. Формалды түрде сұраныс аяқталды, ал іс жүзінде релизден кейінгі сценарий істемей қалды.

Тыныш ақаулар әсіресе қауіпті. Олар мониторингте сирек шу шығарады, бірақ метриканы тез бүлдіреді. Әдетте бұған бұзылған JSON немесе қолданба күтпеген басқа формат, типтік тапсырмаларда hallucination-ның көбеюі, PII ағып кетуі немесе masking-тің өтпей қалуы, сапаға пайдасыз сұраныс құнының өсуі және пайдаланушы сценарийді тастап кететін деңгейдегі кідірістің артуы жатады.

Проблема қай қабаттан басталғанын бірден белгілеу пайдалы. Бұл релизден кейінгі дауды көп үнемдейді. Инцидент жазбасында ақау қай жерде болғанын нақты көрсеткен дұрыс: модельде ме, модельдер арасындағы маршрутизацияда ма, system prompt-та ма, tool calling-де ме, жауапты өңдеуде ме, әлде retry саясаты ма.

Кейде бір қабат емес, екі қабаттың байланысы бұзылады. Мысалы, router трафикті басқа модельге жіберді, жаңа модель JSON схемасын нашар ұстады, ал қолданба жауапты құрал шақырмас бұрын тексермеді. Пайдаланушы бір ғана ақауды көреді, бірақ команда тұтас тізбекті жазуы керек.

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

Ақаудан кейін бірден қандай өрістерді жазу керек

Ақаудан кейінгі алғашқы 15–30 минут postmortem LLM пайдалы бола ма, әлде болжамдар жиынтығына айнала ма — соны шешеді. Логтар әлі қолда тұрғанда, ал қатысушылар детальдарды есінде сақтап тұрғанда, түсіндірме мен қорытындысыз тек құрғақ фактіні тіркеңіз.

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

Сосын симптомды пайдаланушының көзімен сипаттаңыз. «LLM дұрыс істемеді» демей, нақты жазыңыз: бос жауап, бұзылған JSON, артық өрістер пайда болды, модель мәтінді қате тілде берді, таймаут 4 секундтан 40 секундқа өсті. Бір нақты мысал бес жалпы сөйлемнен пайдалырақ.

Келесіде трассаны түгел жинауға көмектесетін идентификаторларды сақтаңыз: request_id немесе басқа request ID, tracing ID, әсер еткен API key, қызмет немесе клиент атауы, сұраныс қай жерден келгені және құпия деректерсіз 1–2 кіріс пен жауап үлгісі.

Осысының өзі инцидентті соқыр іздемеуге жетеді. Егер трафик AI Router сияқты шлюз арқылы өтсе, шлюз деңгейіндегі request ID-ні және провайдер берсе, оның ID-сін де сақтаған пайдалы.

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

Релиз контексі болмаса, сурет те толық болмайды. Релиз нұсқасын, белсенді флагтарды, лимиттерді, маршрутизациядағы соңғы өзгерістерді, JSON схемасын, кэштеуді, модерацияны немесе PII maskirovkасын көрсетіңіз. Ақаудан бір сағат бұрын жасалған кішкентай өзгерістің өзі кейін себеп болып шығуы жиі кездеседі.

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

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

Postmortem-ді қадамдап қалай жинау керек

Ақаудан кейінгі алғашқы 30–60 минут командаға анық сурет беретін уақыт па, әлде болжамдар жиынын ба — соны шешеді. Бұл сәтте кім кінәлі екенін талқылағаннан пайда аз. Логтар ротацияға кетпей тұрғанда, адамдардың есі әлі жаңа кезде фактілерді тез тіркеген әлдеқайда пайдалы.

Жұмысқа жарайтын postmortem шаблоны әдетте былай жиналады:

1. Алдымен құрғақ фактіні бекітеді: не бұзылды, қашан басталды, оны кім бірінші байқады, қай жол көбірек зардап шекті — чат па, классификация ма, JSON жауаптары ма, retrieval ме, әлде billing ме.
2. Бірден инцидент ізі жиналады: қолданба логтары, қате мен кідіріс метрикалары, трассалар, бірнеше шикі сұраныс пен жауап, промпт, модель және релиз нұсқасы.
3. Сосын таймлайн минуттап құрастырылады. Оған әдетте релиз, алғашқы alert, қолмен тексеру, 4xx немесе 5xx өсуі, модель ауыстыру, кері қайтару және сервис қайтадан қалыпты жауап бере бастаған сәт кіреді.
4. Одан кейін түсіндіру толық па, соны тексереді. Себеп бір симптомды ғана емес, бүкіл картинаны түсіндіруі керек. Егер теория тек бұзылған JSON-ды түсіндіріп, бірақ таймауттың өсуін және құнның секіруін түсіндірмесе, қазуды жалғастыру керек.
5. Соңында қорытындыларды жұмысқа айналдырады. Әр әрекеттің иесі, мерзімі және нәтижесі анық болуы керек: контракт тест қосу, жауап схемасын қатыру, canary-релиз енгізу, alert-ті жаңарту.

Таймлайнды есте сақтауға емес, жүйелік деректерге сүйеніп жинаған дұрыс. Адамдар оқиғалардың ретін жиі шатастырады, әсіресе түнде команда промпттарды, rate limit-терді және fallback-ты қатар тексерсе. Егер трафик бір шлюз арқылы өтсе, уақытты audit log, модель, провайдер және key бойынша салыстырған ыңғайлы. Бұл ақау қай жерде басталғанын тезірек түсінуге көмектеседі: қолданбада ма, маршрутизацияда ма, әлде модель ауысқаннан кейін ме.

Тағы бір тәсіл — қасында 2–3 шикі үлгіні ұстау. Бірі — релизге дейінгі сәтті сұраныс, бірі — инцидент кезіндегі сәтсіз сұраныс, тағы бірі — түзетуден кейінгі сұраныс. Осындай үштікпен system prompt форматы, temperature, JSON схемасы, контекст ұзындығы немесе PII maskirovkası нақты не өзгерткенін көру оңай.

Егер талдаудан кейін сізде тек «мұқият болу керек» деген қорытынды қалса, шаблон істемегені. Нәтиже нақты болуы тиіс: «жұмаға дейін үш модель үшін валид JSON тестін қосамыз, жауапты backend lead бақылайды».

Шаблонды кім толтырады және фактілерді кім тексереді

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

Әдетте бір құжат иесі барлық бөлікті бір мәтінге жинайды, ал қалғандары өз жазбаларына жауап береді. Солай команда хронологияны гипотезалардан тез ажыратады және «кім жақсырақ есінде сақтайды» деп дауласпайды.

Инцидент менеджері хронологияны жинайды: алғашқы alert, эскалация уақыты, команданың әрекеті, уақытша шаралар және сервис қайтадан қалыпты жұмыс істей бастаған сәт. Релиз әзірлеушісі ақаудың алдында не өзгергенін жазады: код, config, SDK нұсқасы, жаңа жауап парсері немесе басқа модельге маршрут ауыстыру. ML-инженер модельді, промпт нұсқасын, сұраныс параметрлерін және eval нәтижелерін тексереді, сондай-ақ тесттердің нақты трафикпен сәйкес келген-келмегенін және жауап форматы бұзылмағанын қарайды. Платформа инженері логтарды, таймауттарды, сұраныс лимиттерін, retry-лерді және API шлюзі деңгейіндегі қателерді салыстырады. Егер команда AI Router қолданса, ол audit log-тарды, маршрутты, PII maskirovkасын және маршрутизация өзгергеннен кейін трафик басқа провайдерге кетпегенін қосымша тексере алады. Команда жетекшісі келесі релизге дейінгі тәуекелді бекітеді: әрекеттердің иесін, мерзімін және релизді шығаруға болмайтын шарттарды қояды.

Фактілерді тексеруді де бөлу жақсы. Хронология alert пен логтар арқылы салыстырылады, ес арқылы емес. Релиз өзгерістері commit, flag және config арқылы тексеріледі. Модель туралы қорытындылар модель ID-і, промпт нұсқасы және тест нәтижелері арқылы расталады, «бұрын жақсы жұмыс істейтін» деген сөзбен емес.

Соңғы нұсқаны кім бекітеді

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

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

JSON жауабын бұзған релиз мысалы

Жұма кешке команда жаңа модельді трафиктің 20%-ына қосты. Ауыстыру тыныш өтті: HTTP статус кодтары қалыпты болды, кідіріс өскен жоқ, айқын желілік қате байқалмады. Сондықтан алғашқы 15 минутта бәрі релиз сәтті өтті деп ойлады.

Проблема клиенттік сервиске келгенде шықты: ол нақты өрістері бар қатаң JSON күтетін. Жаңа модель tool calling форматында басқаша жауап бере бастады, ал парсер құлап қалды. Пайдаланушыға бұл кәдімгі ақау сияқты көрінді: сұраныс жіберілді, жауап бар сияқты, бірақ әрекет орындалмайды.

Мұндай жағдайды желімен немесе таймаутпен шатастыру оңай. Команда да алдымен қате ізбен жүрді: retry-лерді, балансировщикті, API логтарын қарады. Бірақ транспорттың қалыпты жұмыс істеп тұрғаны тез белгілі болды. Ескі маршрут күткен форматтағы JSON қайтарды, ал жаңа маршрутта құрал аргументтері басқаша оралған құрылым келді.

Postmortem-ге не жазылды

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

Осы жинақ дау-дамайды факт арқылы аяқтауға жетті. Команда жаңа және ескі модельдің үлгі жауаптарын салыстырғанда, себеп анық болды: желі де емес, SDK да емес. Бөгелген жер — модель жауабы мен басқа форматты күткен код арасындағы contract.

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

Келесі релизде команда қолмен тексеруге сүйенген жоқ. JSON схемадан ауытқыса, build тоқтайтын contract test қосты, canary-ді тек 5% трафикке қосты және парсинг қателері өскенде бөлек alert орнатты. Бұл дүйсенбі күні кінәлі іздегеннен арзанырақ.

Postmortem-ді бұзатын қателер

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

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

Екінші қате — бір абзацта факт пен болжамды араластыру. «14:03-та 5xx өсті» және «мүмкін, провайдер модельдің мінез-құлқын өзгерткен шығар» қатар тұрса, құжат тез дәлдігін жоғалтады. Дұрысы — логтардан, трассалардан және метрикалардан расталған фактілерді, команда әлі тексеріп жатқан гипотезаларды және инцидент кезінде қабылданған шешімдерді бөлек ұстау.

Не жиі жазылмай қалады

Команда өте жиі кіріс пен шығыс мысалдарын сақтамайды, сосын бәрін есте сақтауға сүйеніп дауласады. PII maskirovkасымен кемінде 2–3 нақты мысал керек: аттар, нөмірлер, мекенжайлар, аккаунттар. Онсыз ақауды нақты сұраныс түрі, жаңа промпт нұсқасы немесе модельдің сирек жауабы тудырғанын түсіну қиын.

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

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

Келесі релиз алдында тез чеклист

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

Егер өткен инцидент JSON жауабын бұзса, жаңа релиз бір нәрсені дәлелдеуі тиіс: сондай ақау енді байқалмай өтпейді. Мұнда қарапайым smoke-тест жеткіліксіз. Дәл сол сценарийге, дәл сол жауап форматына, дәл сол сұраныс параметрлеріне және продакшендe құлаған дәл сол клиенттік кодқа арналған тест керек.

Жіберер алдында мына тармақтарды қарап шыққан пайдалы:

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

Командалар көбіне кері қайтаруды тексергенде қателеседі. Олар ол «бәрібір жұмыс істейді» деп ойлайды, бірақ тәуелділіктерді, лимиттерді, жауап форматын және таймауттарды тексермейді. Егер сіз AI Router сияқты бірыңғай LLM шлюзі арқылы жұмыс істесеңіз, модель немесе маршрут ауысқанда қажет ID-лер, audit log-тар және клиент интеграциясының мінез-құлқы сақталатынына алдын ала көз жеткізген дұрыс.

Инцидентті талдау тек релизді өзгерткен кезде ғана пайдалы. Егер содан кейін test, alert, task owner және тексерілген rollback жоспары пайда болса, құжат жұмыс істеді деген сөз. Егер тек мәтін ғана қалса, команда сол ақауды түнде қайта жөндеп отырады.

Шаблонмен әрі қарай не істеу керек

Шаблон әр ақаудан кейін үлкейе бермеуі керек. Команда әр инциденттен соң тағы үш өріс қоса берсе, бірнеше айдан кейін оны ешкім дұрыс толтырмайды. Келесі релиз алдында шешім қабылдауға жететін 8–12 тармақтан тұратын бір қысқа форма ұстаған дұрыс.

Форманы қысқа ұстаңыз

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

Айына бір рет соңғы LLM postmortem-дерді ашып, қай жолдар бос тұрғанын қарау пайдалы. Егер бір өріс бірнеше талдауда қатар толтырылмаса, себебі әдетте қарапайым: ол керек емес немесе сұрақ тым бұлыңғыр қойылған. Екі жағдайда да форманы қысқартқан дұрыс.

Өрістерді тек қажет кезде қосыңыз

LLM ақауларында DevOps формасындағы әдеттегі өрістер кейде аздық етеді. Егер инцидентке сұраныс маршруты, провайдер немесе жауапты өңдеу ережелері әсер етсе, шаблонға тағы бірнеше жол қосыңыз: route немесе model route атауы, сұранысқа жауап берген provider, нәтижеге маркировка әсер етсе content label, және оқиғалар тізбегін қалпына келтіруге болатын audit log.

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

Егер трафик AI Router арқылы өтсе, инцидентті тек қолданба логтарымен салыстыру жеткіліксіз. Audit log-тарды, key бойынша лимиттерді, model route-ты және content label-ді тексеріңіз. Тәжірибеде ақау жиі релиз қатесі сияқты көрінеді, бірақ себебі қарапайым болады: сұраныстар басқа жаққа кетіп қалған, бір key rate limit-ке тірелген, не жауап басқа белгімен келіп, сценарийді бұзған.

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

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