LLM логтарын сақтау мерзімдері: жазбаларды сыныптарға қалай бөлу керек

Неге бәріне бірдей сақтау мерзімі проблема тудырады

«Бәрін 180 күн сақтайық» деген ой қарапайым көрінеді, бірақ көбіне нәтиже жаман болады. Әр журналдың міндеті бөлек. Операциялық логтар қателерді, кідірістерді және лимиттерді көруге көмектеседі. Debug жазбалар команда prompt-та, маршруттауда немесе модель жауабында шыққан ақауды талдағанда керек. Аудит оқиғалары ұзағырақ сақталады, өйткені олар арқылы қолжеткізу, қызметкерлердің әрекеті және даулы операциялар тексеріледі.

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

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

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

«Керек болып қалар» деп сақтау көбіне ең қымбат тәсілге айналады. Логтың пайдасы уақыт өте төмендейді, ал сақтау қаупі артады. Толық request body бүгін инцидентті жөндеп жатқанда көмектесуі мүмкін. Үш аптадан кейін сол жазба онша керек болмай қалады, бірақ дерек ағып кетсе немесе ішкі тексеріс болса, көп сұрақ тудырады.

Бұл әсіресе трафик бір LLM API gateway арқылы өтетін жерде анық көрінеді. Операциялық оқиғалар үздіксіз жиналады, аудит қолжеткізу мен әрекеттерді бақылауға керек, ал шикі debug деректері тез шамадан тыс көбейеді. Мерзімдерді алдын ала бөлмесеңіз, команда алдымен бәрін жинайды да, кейін оны қауіпсіз әрі ұқыпты сұрыптай алмай қалады.

Жазбаларды үш класқа қалай бөлуге болады

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

Операциялық логтар сервистің күнделікті жұмысына керек. Онда әдетте request_id, шақыру уақыты, модель атауы, provider, статус, кідіріс, кіріс және шығыс token саны, құны, қате коды және retry саны жеткілікті. Осы өрістер арқылы кідіріс қайда өскенін, сұрау неге құлағанын және қай маршрут жұмыс істегенін көруге болады. Толық prompt пен толық жауап мұнда көбіне көмектескеннен гөрі кедергі жасайды.

Debug жазбалар қысқа мерзімге және нақты бір міндетке керек. Оларда system prompt нұсқасы, шақыру параметрлері, provider_request_id, қате стегі, fallback маршруты, prompt-тың қысқа бөлігі немесе қысқартылған жауап болуы мүмкін. Оларды нүктелі түрде қосып, сезімтал деректерді бірден маскалаған дұрыс. Әйтпесе debug тез-ақ артық ақпарат қоймасына айналып кетеді.

Аудиторлық із басқа міндетті шешеді. Ол дебаг үшін емес, әрекеттердің дәлелденетін тарихы үшін керек. Әдетте онда actor_id немесе service account, әрекет түрі, уақыт, policy шешімі, PII маскаланғаны туралы белгі, content белгісі, өңдеу аймағы, key идентификаторы, request немесе response хеші және дерекке кімнің қол жеткізгені жазылады. Мұндай журнал «не болды және қандай ережеге сүйенді» деген сұраққа жауап беруі керек, бүкіл хат алмасуды көшіріп бермеуі керек.

Ең жиі шатастырылатын нәрселер

Ең көп болатын шатасу — user_id мен пайдаланушының жеке деректері арасындағы айырмашылықты елемеу. Операция мен аудит үшін көбіне ішкі идентификатор немесе хеш жеткілікті. Телефон, ИИН, email және еркін мәтін ол жерге түспеуі керек.

Тағы бір қате — модель жауабының мәтінін аудитке салу. Тексеру үшін көбіне хеш, саясат белгісі және жауап берілгені туралы факт жеткілікті. Ал мәтіннің өзі керек болса, ол қысқа debug деректеріне жатады.

LLM gateway-де бұл өте анық көрінеді. Банк чат-ассистентінің операциялық логы timeout-ты, кідіріс өсімін және басқа модельге ауысуды көрсетеді. Debug жазба сәтсіз retry мен проблемалы сұрау параметрін табуға көмектеседі. Аудиторлық оқиға жүйенің PII-ді маскалағанын, сұрауды тиісті аймақта өңдегенін және оператор жауабына қолжеткізуді тіркегенін бекітеді.

Журналдарға тексермей жазуға болмайтын деректер

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

Мәселе мұндай деректердің тек сұрау мәтінінен ғана келмеуінде. Олар чат тарихында, құрал аргументтерінде, CRM-нен келген JSON-да, OCR нәтижелерінде, файл атауларында, тіркемелердің метадеректерінде, тіпті қате хабарламаларында да жасырын болуы мүмкін.

Әдетте логтарға кездейсоқ түсе беретін төрт топ бар:

• жеке деректер: ИИН, АЖТ, туған күн, паспорт деректері, телефон, email, мекенжай;
• қаржылық және келісімшарттық деректер: карта нөмірі, IBAN, келісімшарт нөмірі, шот, өтінім, полис;
• медициналық және сақтандыру мәліметтері: диагноздар, талдаулар, выписка, сақтандыру статусы;
• компанияның ішкі деректері: қызметкерлер туралы мәлімет, ticket және құжат үзінділері.

Бөлек мәселе — secret-тер. Журналдарда жиі Bearer token-дер, API key-лер, cookie-лер, OAuth кодтары, webhook secret-тер, signed URL-дер, базаға қосылу жолдары және уақытша құпиясөздер қалып қояды. Олар көбіне HTTP headers-те, query params-те, stack trace-те, орта дамптарында, debug print-терде және сақталған cURL сұрауларында көрінеді. Тіркемелер де қауіпті: PDF, суреттер, аудио және base64 жолдары кейде түгелімен, шығарылған мәтінімен қоса журналға кетеді.

Толық мәтінді тек қысқа инцидентті онсыз талдай алмайтын жағдайда ғана сақтаңыз. Көп жағдайда қауіпсізірек балама жетеді. Маска мәннің пішінін сақтайды, бірақ жолдың өзін жасырады. Хеш бір клиент немесе token бірнеше рет кездескенін көрсетуге көмектеседі, бірақ бастапқы мәнді ашпайды. Үлгі идентификаторы немесе prompt нұсқасы команда нақты жинақтағы ақауды іздегенде толық мәтіннен пайдалырақ болуы мүмкін.

Модель жауаптары да зиянсыз деп саналмауы керек. Модель сұраудағы жеке деректерді қайталап айтуы, құжатты мазмұндап беруі немесе ішкі хат алмасудан бір бөлікті қайта шығаруы мүмкін. Құралдардың шығысы одан да қауіпті: search, SQL, CRM, OCR және файл коннекторлары журналдауға болмайтын шикі мәтінді қайтара алады. Операциялық және аудиттік жазбалар үшін көбіне уақыт, модель, статус, кідіріс, жауап өлшемі, қате коды және мазмұны жоқ document ID жеткілікті.

Егер сізде AI Router сияқты PII маскалауы және аудит логтары бар gateway болса, бұл ережені оқиғаны жазғаннан кейін емес, жазбас бұрын қолданған жөн. Жазба ақауды табуға, қолжеткізуді растауға немесе тексеруден өтуге көмектеспесе, оның журналда орны жоқ.

Мерзімді қалай кезең-кезеңімен белгілеуге болады

Сақтау мерзімін сервистің бәріне емес, нақты өрістер мен оқиға түрлеріне берген дұрыс. Бір сұраудың ондаған ізі болуы мүмкін: шақыру уақыты, model ID, token саны, жауап коды, prompt үзіндісі, маскаланған user ID, IP, блоктау себебі, аудит жазбасы. Әр өрістің өз міндеті бар, демек мерзімі де өзінікі болуы керек.

Алдымен инвентаризациядан бастаңыз. API, background worker-лер, proxy, queue, мониторинг, SIEM және аралық сервистер не жазатынының толық тізімін жинаңыз. Көбіне артық дерек негізгі қосымшада емес, дәл солардың ішінде жатады.

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

Содан кейін тапсырмаға жеткілікті ең қысқа мерзімді қойыңыз, «запаспен» емес. Кідіріс метрикалары мен қате кодтары көбіне 14-30 күнге жеткілікті. Prompt үзінділері бар debug жазбаларды бірнеше күн ғана сақтаған дұрыс немесе мүлде жазбаған жөн. Аудит оқиғалары ұзағырақ сақталады, өйткені олар арқылы кім, қашан, не істегені тексеріледі.

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

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

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

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

Лог пен архивтің арасы қай жерде өтеді

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

Жедел қолжетімді жерде тек күнде керек деректі қалдырған жөн. Көп команда үшін бұл операциялық логтар: сұрау уақыты, жауап коды, модель, token саны, клиент немесе сервис идентификаторы, шақыру тізбегі бойынша tracing, фильтрдің іске қосылу фактісі және PII маскаланғаны туралы белгі. Prompt пен жауаптың толық мәтіні мұндай жиілікпен сирек қажет болады.

Тәжірибелік сақтау схемасы әдетте былай көрінеді:

• hot layer-де қысқа мерзім — егер қателерді талдау үшін онсыз болмайтын болса, сұраулар мен жауаптардың шикі мәтіні;
• cold layer-де орта мерзім — инциденттер мен даулы жағдайларға қатысты debug жазбалар;
• ұзақ мерзім — бақылау, биллинг және тексеру үшін метадеректер;
• мерзім аяқталғаннан кейін — егер жазба бөлек ережеге түспесе, архивсіз жою.

Cold storage екінші «тірі» базаға айналмауы керек. Оған қолжеткізу баяу, құқықтар тар, іздеу дөрекілеу. Бұл — ескі жазбалар күнделікті жұмысты бөгемей тұруы үшін төленетін қалыпты баға.

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

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

Жою сәтін қолмен шешім емес, ереже ретінде жазған дұрыс. Мысалы: жазба hot және cold қабаттардағы мерзімін өтеді, тексеріске қатыспайды, қаржылық салыстыру үшін керек емес және бөлек нормативке түспейді. Сонда жүйе оны архивсіз жояды. Мұндайда сақтау саясаты «кездейсоқ керек болып қалар» деген қойма емес, шын жұмыс істейтін саясатқа айналады.

Банк чат-ассистентіне мысал

Клиент банк чатына: «Өтінімнің статусын тексеріңіз, менің ИИН 123456789012» деп жазады. Сервис үшін бұл кәдімгі сұрау, бірақ лог үшін бұл енді тәуекел. Егер команда бүкіл диалогты тексермей барлық журналға жаза берсе, ИИН тез арада debug-қа, мониторингке және архивке тарап кетеді.

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

Операциялық логта минимум қалады: сұрау уақыты, session ID, қандай модель шақырылғаны, API жауап коды, кідіріс және token шығыны. Debug ізінде команда тек ақауды талдауға көмектесетін бөлікті ұстайды: қате ID, prompt нұсқасы, сервис атауы және толық мәтіннің орнына қысқа маскаланған үзінді. Аудиторлық журналда жазбаға қолжеткізу, маршруттау баптауларының өзгеруі, жаңа кілттің шығарылуы, rate limit немесе маскалау ережелерінің өзгеруі тіркеледі.

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

Егер сұрау қате берсе, әзірлеушілер қысқа уақытқа егжей-тегжейлі debug ізін қоса алады. Бірақ мұнда да артық дерек сақтамау керек. «Проверьте статус заявки, мой ИИН 123456789012» дегеннің орнына журналда «Проверьте статус заявки, мой ИИН [MASKED]» сияқты нәрсе қалуы тиіс. Мұндай жазбаны инцидент жабылғанша 24–72 сағат сақтау көбіне жеткілікті.

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

Егер банк LLM сұрауларын AI Router сияқты OpenAI-үйлесімді бір gateway арқылы жіберсе, мұндай схеманы бір жерден ұстау әлдеқайда оңай. Операциялық, debug және аудит оқиғалары үшін мерзімді бөлек қоюға болады, ал PII журналға түспей тұрып маскаланады.

Ең жиі жіберілетін қателер

Мәселе көбіне сақтау мерзімінен емес, артық көшірмелерден басталады. Команда бір жүйе үшін ереже орнатады, ал деректер бұрыннан бес жерде жатып қалады: қосымшада, gateway-де, APM-де, queue-де және аналитикаға арналған экспортта. Сонда сақтау саясаты қағаз жүзінде ғана қалады.

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

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

Журнал түрлерінің өзін де жиі шатастырады. Қол жеткізу аудиті кімнің және қашан деректі ашқанын немесе әрекет жасағанын көрсетеді. Техникалық tracing қателікті, timeout-ты немесе артық retry-ды табу үшін керек. Debug жазбалар әзірлеушіге нақты бұзылуды дәл осы сәтте түсінуге көмектеседі. Бұлардан бөлек, резервтік көшірмелер, кезектер және экспорттар бар — адамдар соны жиі ұмытып кетеді.

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

Жасырын көшірмелер де болады: backup, dead-letter queue, support үшін CSV экспорттары, test dump-тар. Олар көбіне негізгі логтардан ұзақ өмір сүреді. Егер продта PII маскаланса, ал резервтік көшірмеде шикі мәтін жатса, ереже іс жүзінде орындалмағаны.

Сондықтан жоюды практикада тексеру керек. Бір test request_id алыңыз, мерзімнің аяқталуын күтіңіз де, оны негізгі қоймадан, backup-тан, queue-лардан және экспорттардан іздеп көріңіз. Егер AI Router сияқты gateway қолдансаңыз, қосымша түрде не қосымша өзі, не gateway, не SIEM не сақтайтынын бөлек жазған пайдалы. Әйтпесе көшірмелер тез қайта пайда болады.

Мерзімді кім бекітеді және қалай өзгертеді

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

Жұмыс схемасы әдетте қарапайым. Өнім деректің мағынасын түсіндіреді: лог не үшін керек, оны кім пайдаланады, қаншалықты жиі қарайды. ИБ тәуекелге қарайды: жазбада жеке деректер, token-дер, сұрау мәтіні, модель жауаптары, қызметтік идентификаторлар бар ма. Заңгерлер мен compliance мерзімдерді келісімшартпен, ішкі ережелермен және реттеуші талаптармен салыстырады. Платформа командасы мұны жүйеде іске асырады: лог класстарын бөледі, жоспарлы жоюды қояды, маскалауды қосады және мүмкін болған жерде қолмен көшіріп алуға тыйым салады.

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

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

Ұзарту құқығын да бәріне бірдей бере салмаған жөн. Әдетте өтінімді сервис иесі береді, ИБ келіседі, егер лог жеке деректерге немесе даулы операцияларға тікелей қатысты болса, заңгер қосылады, ал платформа шешімді орындайды. Бұл «бәрін сақтап қояйық» деген өтініштерді айтарлықтай азайтады.

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

Матрицаны жай белгі үшін емес, өнім өзгерген соң қайта қараған дұрыс. Жаңа байланыс арнасы, CRM интеграциясы, prompt caching, басқа model provider, жаңа аудит оқиғалары немесе маскалаудың жаңа тәсілі дерек құрамын өзгертеді. Мұндай өзгерістерден кейін бұрынғы мерзімдер жиі сәйкес келмей қалады.

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

Іске қосар алдындағы қысқа тексеріс

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

Іске қосар алдында мына қысқа тізімді қарап шығыңыз:

• әр өрістің сақтау себебі және өмір сүру мерзімі нақты;
• PII журналға жазбас бұрын маскаланады;
• егжей-тегжейлі debug тек диагностика кезінде қосылады;
• жою негізгі қоймада ғана емес, көшірмелерде де тексерілген;
• аудит жазбаларына қолжеткізу ашық және оның өзі де журналданады.

Практикада осының өзі проблемалардың көбін қысқартуға жетеді. Мысалы, банк чат-ассистентінде операциялық оқиғаларды detailed debug жазбаларынан ұзақ сақтау мүмкін, бірақ тек сол оқиғаларда клиенттің шикі хабарламалары мен артық идентификаторлар болмаса ғана.

Егер команда AI Router сияқты LLM gateway арқылы жұмыс істесе, ереже өзгермейді. Бір endpoint дисциплинаны алып тастамайды: мерзім әр лог класына бөлек керек, маскалау жазбас бұрын орындалуы тиіс, ал жою барлық көшірмеге дейін жетуі керек.

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

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

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

Әдетте алты баған жеткілікті: өріс немесе оқиға атауы, жазба класы, PII бар-жоғы, сақтау мерзімі, жою немесе обезличивание тәсілі және ереже иесі.

Содан кейін құжатты емес, жүйенің нақты әрекетін тексеріңіз. Командалар жиі негізгі базада жоюды баптайды да, тест ортаны, объектілік қоймаға экспортты және резервтік көшірмелерді ұмытып кетеді. Соның салдарынан дерек «жойылғандай» көрінеді, бірақ іс жүзінде әлі айлар бойы жата береді. Бір рет тест жасап, жазба жасап, мерзімін күтіп, оның команда таба алатын барлық жерден шынымен жоғалғанына көз жеткізген дұрыс.

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

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

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