Скоринг пен антифродқа арналған on-prem инфрақұрылым: аппараттық құралда не маңызды?

Кешігу және модель сапасы: аппараттық неден шектеледі

Скоринг пен антифрод әдетте «қазір жауап бер» режимінде жұмыс істейді. Тек ықтималдықты есептеп қана қоймай, уақытында орындау керек: сұрауды қабылдау, фичаларды жинау, инференс өткізу, ережелерді қолдану, шешімді қайтару және оқиғаны логқа жазу.

Негізгі қате — тек орташа кешігуге қарау. Қолданушы мен бизнес үшін маңыздысы — таралымның келесі жағындағы мәндер: p95 және әсіресе p99. Егер p99 секірсе, сирек бірақ айқын «оқтап қалулар» пайда болады: төлем өтпей қалады, клиент қолдау қызметіне қоңырау шалып, қосымша тексеріс іске қосылады немесе конверсия төмендейді.

Аппараттық құралдар тек миллисекундтарға әсер етіп қана қоймай, шешімдердің сапасына да әсер етеді. Инфрақұрылым шамадан тыс жүктелсе, сервистер «шаршатып» жұмыс істеуі мүмкін: фичалар тайм-аутпен келеді, кэштегі ескі мәндер алынады, кейбір көздер қол жетімді болмай қалады. Формально модель өзгермейді, бірақ кіріс деректер нашарая түседі — қателер өседі және метрикалар «боюланады». Тұрақтылық та маңызды: бірдей сұрау бірдей деректермен әрқашан бірдей нәтиже беруі тиіс, тайм-ауттар мен жүктеменің әсерінен кездейсоқ ауытқулар болмауы қажет.

Әдетте тар орындар қайталанады:

• CPU — бір потокқа жеткілікті частота жетіспейді немесе пиковта ядроларға бәсекелестік басталады.
• RAM және кэштер — кэшке түспеу, қоқыс жинағыш (GC), бетфолттар.
• Желi — қызметтер арасындағы артық секірістер, интерфейстердің жүктелуі, фичесторға кешігулер.
• Диск — фичаларға баяу қол жеткізу, журнал жазуға кезектер, NVMe-ның нашар конфигурациясы.

Сатып алудан бұрын бизнеспен қарапайым нәрселерді келісіңіз: p95 пен p99 бойынша мақсатыңыз қандай, пиктегі ең үлкен RPS қандай, деградация кезінде не істеу керек (қызметтен бас тарту, тексерісті оңайлату, запас модельге көшу) және шешім үшін қандай деректер міндетті. Бұл жауаптар кешігулер бюджетін анықтайды және on‑prem инфрақұрылым қай жерде күшті болуы керегін көрсетеді.

Кешігулер бюджетін қадамдарға бөліңіз

Скоринг кезеңдерге бөлінбесе, CPU, RAM және NVMe туралы пікірлер «көзіме көрінбей» жүреді. On‑prem үшін бір рет кешігу бюджетін жинап, оны келісім ретінде бекіту — p50, p95 және p99 нақты жүктеме кезінде қай шамада болу керек екенін көрсетеді.

Бір сұраудың тізбегін алып, әр қадамды бөлек өлшеңіз. Әдетте бұл:

• сұрауды қабылдау және талдау (API, сериализация, валидация)
• фичаларды алу (кэш, БД, key‑value, кезектер)
• инференс (фичаларды дайындау, рантаймды шақыру)
• ережелер және постпроцессинг (шекті мәндер, explain, бизнес‑логикамен біріктіру)
• логтау және аудит (синхронды немесе асинхронды)

Содан кейін мақсаттарды тек «орташаға» ғана емес, хвосттарға да қойыңыз. p50 жылдамдық сезімін береді, p95 — тұрақтылықты, p99 — қолданушының шын азаптануы мен антифродтағы шығындарды көрсетеді. Жүктеме профилін қосыңыз: орташа RPS, пик және шоқтардың сипаты (мысалы, 3–5 минут ішінде 5x трафик).

Сыртқы дерек көздерін жеке есептеңіз. Кез келген сыртқы сервиске шығу p99-ды болжаусыз етеді. Пилотта деградация кезінде мінез‑құлықты тіркеңіз: кэштейсіз бе, фичаларды қысқартасыз ба, дәлдікті төмендетесіз бе немесе ережелерге фолбэк жасайсыз ба.

Алдын ала не есептелетіні туралы келісіңіз: таймаут па (мысалы, толық скорингке 50–100 мс), p99 шамасы, фолбэктердің үлесі өсіп кетсе не істеу, журнал жазудың жоғалуы. Пилот метрикаларын анықтаңыз: кезеңдер бойынша кешігулер таралымы, p99 кезінде RPS, таймауттар үлесі, кезектер, CPU және жадтың жүктелуі, сондай-ақ фичестордың жауап уақыты.

Инференс үшін CPU: частота, ядролар және NUMA

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

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

NUMA қарапайым тілмен

Екі процессорлы серверлерде жады «әр процессорға жақын» орналасады. Егер процесс CPU0-да жүріп, ал жады «бөтен» жартыдан бөлінсе, RAM-ға қол жеткізу баяулап, кешігу секіре бастайды. Бұл әдетте p95–p99-да көрінеді.

Пилотқа практикалық ереже: бір инференс сервисін бір NUMA түйінімен және оның жадымен шектеңіз. Немесе модельдерді түйіндерге айқын бөліңіз. On‑prem-та бұл көбіне көп ядро сатып алудан да үлкен әсер береді.

Энергия үнемдеу, turbo және тұрақтылық

Энергия үнемдеу режимдері мен агрессивті turbo орташа көрсеткіштерді жақсартады, бірақ тұрақтылықты нашарлатуы мүмкін. Жүктеме астында троттлинг және жиіліктің «пилалы» ауытқуы болып, жауап уақытының бұзылуына әкелуі мүмкін.

Пилоттық стендте тексеріңіз:

• ядролар бойынша жүктеме (бір ядро «толып», қалғандары бос па)
• контексттік ауыстырулар (шабуыл әдетте ағымдар бәсекелестігін немесе процестердің көптігін көрсетеді)
• жиілік пен троттлинг (ұзақ прогонда жиілік тұрақты ма)
• NUMA‑локалдық (жадтың қашық түйінге «ұшып кетуі» жоқ па)
• p95 және p99 (CPU мен жадқа байлағанда дейін және кейін салыстырыңыз)

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

RAM және кэш: жиі төмен бағаланатын нәрсе

On‑prem инфрақұрылымында RAM жиі ойлағаннан да маңызды. Жад «қысылғанда» жүйе ұзақ уақыт қалыпты көрінуі мүмкін, кейін сирек бірақ өте ұзақ кешігулер пайда болады. Бұл — p99‑дың хвосты: қоқыс жинағыш, кезектердің толуы, үлкен буферлерді бөлу, бетфолттар.

CPU кэштері мен деректер локалдылығы маңызды, себебі модельдер мен фичалар көп рет және ұсақ бөліктермен оқылады. Егер фичалар солай орналасқан болса, процессор жиі L3 орнына RAM‑ға жүгінеді, инференс уақыты өседі және болжамсыз болады. Сол сияқты, фичаларды әртүрлі құрылымдардан тартып, көп ұсақ сұраулар жасасаңыз және жаңа объектілер жиі құрасаңыз да кешігулер өседі.

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

Көлемді бағалау үшін модель(дер) жадыда, фичалар (ыстық кілттерге кэш), жұмыс буферлері, кезектер, қызметтік шығындар және резервті жинаңыз. Қарапайым ереже: бос RAM‑ның 30–50% сақтау, сонда пиктер жүйені свопқа итермейді.

Пилотта пайдалы бақылаулар:

• своп бар ма және оған шақырулар болды ма
• major page fault‑тар және пиктердегі кешігулердің өсуі
• L3 cache miss rate және IPC («жадқа шектелген» белгілері)
• p99 кезіндегі жад қысымы (кезектер, аллокациялар)
• бірнеше сағаттық жүктемеден кейінгі тұрақтылық

Егер пилот GSE S200 класты серверде өтсе, RAM көлемі мен фичаларды кэштеу саясатын өзгертуге дейін және кейін метрикаларды тіркеңіз. Көбіне бұл p99-ды CPU‑ны қымбат ауыстырудан гөрі көбірек жақсартады.

CPU немесе GPU: скоринг пен антифрод үшін қалай таңдау керек

Таңдау «қайсысы тез» емес, «қағида бойынша не табыс әкеледі» сұрағына келеді. Антифродта көбіне тұрақты p99 және бір сұраудың төмен кешігуі маңызды. Скорингте кейде пиктегі өткізу қабілеті (throughput) маңызды болады.

CPU көбінесе жеткілікті, егер модель компактты болса (градиентный бустинг, логистикалық регрессия, шағын эмбеддингтер), есептеулер қарапайым және кешігу тұрақты болуы керек. CPU‑ны ядролар бойынша оқшаулау оңай, фондық әсерді басқару жеңіл және модель ауыстырылғанда мінез‑құлықты бақылау қарапайым.

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

Келісімшарт көбіне батчингте. Ол сұраулар тобын жылдамдатады, бірақ бір сұраудың кешігуін нашарлатуы мүмкін: сұрау батч жиналатынша немесе кезек босайтынша күтеді. Егер SLA — «әр транзакция 20 мс ішінде», агрессивті батчинг p99-ды оңай нашарлатуы мүмкін, орташа жақсарса да.

Пилотта тек шектік максимумды емес, тұрақтылықты тексеріңіз:

• холодный старт және прогрев (тұрақты p50/p99 алу үшін қанша уақыт қажет)
• модель нұсқасын ауыстыру (hot reload кезінде кешігу мен қателер бар ма)
• кезектер мен батчинг (QPS өскенде және әр түрлі батч өлшемдерінде p99 қалай өзгереді)
• орта әсері (GPU драйверлері, CUDA нұсқалары, қуат режимдері, жиіліктер)
• фон әсерінен деградация (логтау, метрикалар жинау, фондық джобтар)

Жақсы тест—сол бір трафикті CPU‑only және CPU+GPU режимдерінде өткізіп, ең нашар 1% сұрауларды салыстыру. Антифродта көбіне пикте де тік p99 беретін нұсқа таңдалады, тіпті пиктік өткізу қабілеті аздау болса да.

Желi мен уақыт: миллисекундтарды жоғалтпау

Модель мен CPU тез болса да, желі p99‑ды болжамсыз етуі мүмкін. Скоринг пен антифрод үшін қауіпті хвосттар: коммутаторда қысқа кезектер, буферлердің толуы, шың уақыттарындағы микрозагрузка. Нәтижесінде «әдеттегі» 5–10 мс кейбір сұрауларда 50–150 мс болуы мүмкін.

NIC деңгейінде тек гигабиттерге ғана емес, кешігулер мен тұрақтылыққа қараңыз. Offload функциялары кейде көмектеседі, бірақ оларды пилотта қосып‑өшіріп, p95/p99 салыстыру керек. Бір хостта бірнеше сервис болса, драйверлер мен кезек параметрлері CPU‑ға бәсекелестік тудырмайтынын тексеріңіз.

Желіні «шулы» етпеу үшін трафик түрлерін алдын ала бөліңіз: онлайн‑скоринг, фичалар мен хранилищелерге қолжеткізу, админка мен мониторинг, бэкаптар мен репликациялар. Осылай түні бойы жүретін бэкап таңертең скоринг кешігулерін көтеріп жібермеу мүмкін.

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

Пилотта тексеріңіз:

• жүктеме кезінде пакет жоғалту және ретрансмиттер
• түйіндер арасындағы джиттер
• бір сегменттағы және сегменттер арасындағы RTT
• фондық трафиктің p99-ға әсері

Пайдалы сценарий: скоринг жүктемесін қосып, параллель түрде «шум» қосыңыз (логтау, репликация, бэкап). p99‑ді сегментациядан бұрын және кейін салыстыру миллисекундтардың қай жерде жоғалып жатқанын көрсетеді.

Хранилище және фичаларға қолжетімділік: NVMe, кэш және логтау

Көп жағдайда кешігу модельде емес, деректерге қолжетуде «ойнап кетеді»: фичалар, клиент профильдері, тізімдер (blacklist, whitelist), карта немесе құрылғы бойынша соңғы оқиғалар. Егер оқу баяу хранилищеға түссе, p95 және p99 CPU жылдам болса да өседі.

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

Диск үш орында жиі әсер етеді: онлайн‑фичестор (key‑value немесе жергілікті БД), профильдер мен күй (мысалы, клиент бойынша счетчиктер), оқиға журналдары — талдау және оқыту үшін. Егер бәрі бір томда тұрса, лог жазу байқалмай I/O кезегін жеп, оқу кешігулерін бұзып жіберуі мүмкін.

Қатты старттан кейін «салқын» күйге қалудан аулақ болу үшін кэшті прогрeв жоспары керек: ыстық фичаларды жадыда ұстаңыз, ал бастарда типтік кілттерді өтіңіз. Алдын ала шешіңіз, қанша RAM кэске қажет, қаншасы модель мен сервиске керек.

Логтарды скорингті тежемейтіндей жазған дұрыс: онлайн шешімді толық аудиттен бөліп, буферлеп, топтап жіберіңіз; мүмкіндігінше логтар мен фичесторды әр түрлі NVMe немесе томдарға орналастырыңыз. fsync пен жазу жиілігін бақылау — p99 проблемаларының жиі себебі.

Пилотта қараңыз:

• фичаларды оқу кешігулерінің p95/p99
• I/O кезегінің тереңдігі және пиктегі өсу
• логтарды бір уақытта жазғанда секірістер
• қайта жүктегеннен кейінгі прогрев ұзақтығы
• нақты кілттер бойынша тұрақтылық, синтетика емес

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

Сенімділік және изоляция: p99 секірмеуі үшін

Скоринг пен антифродта шешімнің орташа кешігуі емес, p99 шешеді. On‑prem-та бұл жиі «күшті CPU емес», ал қуат пен сенімділікте және сервистің басқа жүктеменен бөлісуінде тұрады.

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

Қуаттың резерві тікелей p99-ға әсер етеді. Сервер 80–90% CPU‑да үнемі жұмыс істесе, кез келген шоқ (GC, фондық тапсырмалар, пернелер) ұзақ хвосттарға айналады. Практикалық шешім — жұмыс жүктемесін төмен жоспарлап, пиктер мен бір түйіннің жетіспеушілігі үшін headroom қалдыру.

Сыртқы жүктемелерден оқшаулану міндетті. Скоринг ауыр тапсырмалармен (модель оқу, экспорттар, есептер, қауіпсіздік сканері) бір хостты бөліспеуі керек. Тіпті сирек фондық процестер диск, кэш немесе CPU‑ны секундтарға алып қоюы мүмкін.

Пилотта тексеріңіз:

• түйіннің ақауы (p95/p99, сұраулар кезегі, қалпына келу уақыты)
• сақтау деградациясы (фичалар мен журналдар жоғала ма)
• «шулы көрші» (p99 қалай өзгереді)
• қызметті қайта жүктеу (кэштерді прогрев қанша уақыт алады)
• аудит және рұқсаттар (кім қалай қол жеткізеді, әрекеттер журналданады ма)

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

Пилот қадамдап: сатып алудан бұрын жабдықты қалай тексеру

Пилот қажетті емес графиктер үшін емес, кейін p99‑ты бұзатын нәрселерді табу үшін керек: шоқтар, сирек ауыр сұраулар, CPU мен жадқа бәсекелестік. Бастапқы көрсеткіштерді айқындаңыз: мақсатты RPS (өсуге резервпен), күрделі кейстердің үлесі (мысалы, 5–10% «күдікті» сұраулар көп ережелер мен фичалармен), фичалардың және жауаптың орташа және ең үлкен көлемі.

Тест контурын өндірістікке мүмкіндігінше ұқсас етіп жинаңыз, бірақ шағын: 1–2 модель, ережелер қабаты (бар болса), фичалар көзі (кэш немесе хранилище) және міндетті логтау. Тізбек адал болуы керек: фичаларды алу, препроцессинг, инференс, постпроцессинг, оқиға жазу.

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

Әр прогон сайын тіркеңіз: бүкіл тізбек және инференс бойынша бөлек p50/p95/p99, ядролар бойынша CPU жүктелуі және жиілік, контексттік ауыстырулар мен кезектер, жадтың, желінің және I/O‑ның мінезі. Қателерді де жазып қойыңыз: таймауттар, деградациялар, прогревтегі кешігулер өсімі.

Содан кейін бір тестте 2–3 конфигурацияны салыстырыңыз: CPU‑бағдарлы (жоғары частота және дұрыс NUMA) және GPU нұсқасы, егер модель шындығында батчингтен ұтады. Көбіне аралас шешім қабылданады: жабдықты нүктелі түрде өзгерту (мысалы, RAM немесе NVMe қосу), ал басқа нәрсені баптаулармен толықтыру (ағын пулдары, pinning, фича кэштері, таймауттар).

Егер пилот интегратор арқылы өтсе, «прошел/прошел емес» критерийлерін p99 және қателер бойынша келісіңіз. Осындай жобаларда GSE.kz S200 серверлеріне негізделген стенд жинауға көмектесіп, өлшеулерді сатып алуға дейін қайталауға болатындай етіп бекітеді.

Мысал сценарий: банк үшін пиктік жүктемелері бар антифрод пилоты

Банк уақытында on‑prem скоринг пен антифрод инфрақұрылымын іске қосады. Қалыпты күндерде ағыны тұрақты, ал жалақы күндері жүктеме 3 есеге дейін өседі. Кешігулер талаптары өзгермейді: фичаларды алу және оқиғаны журналға жазу қоса алғанда, p99 60 мс‑дан аспауы тиіс.

Пилотты өндірістік копиясының мини‑нұсқасы ретінде жинайды: инференс үшін сервер, бөлек фичалар сервисі және сыртқы тәуелділіктердің имитациясы (кезек, API, логтау). Бірден орташа емес, p95/p99‑ды тексереді, себебі антифродта дәл осы хвосттар таймауттар мен транзакция жоғалтуларға әкеледі.

Екі режимде тексереді: жеке сұраулар (кешігулер үшін әділ) және микробатчинг (кіру ағыны жоғары болса). Сонымен бірге фичаларға екі тәсілді салыстырады: RAM‑да ыстық кілттер кэші және промахта дисктен оқу.

Өлшеулерден әдетте келесі көрініс шығады. QPS өссе, p99 CPU бәсекелестігі мен NUMA‑ның секіруінен шығады, орташа жақсы болса да. Агрессивті және синхронды логтау p99‑ды I/O себепті тез өсіреді — мұнда NVMe және асинхронды жазу көмектеседі. Фичаларды RAM‑да кэштеу модельді жылдамдатудан жиірек үлкен әсер береді. Микробатчинг CPU жүктемесін төмендетеді, бірақ егер батч мөлшері пиковый трафикке сәйкес таңдалмаса кешігуді нашарлатуы мүмкін.

Пилоттың қорытындысы көбіне «ең қуатты сервер керек» емес, болжамды жиынтық: бір ағын бөлігі үшін жеткілікті CPU частотасы, кэш фичалар үшін резервті RAM, журналдар мен жергілікті деректер үшін NVMe, сервистер арасындағы төмен кешігулі желі. Бұл p99‑ды пиктерде де ұстап тұрады, модельді қайта жазбай — конфигурация мен жұмыс режимдері арқылы. Егер тест GSE S200 серверінде болса, BIOS, NUMA және қуат профильдерін бекітіңіз — сонда сатып алу мен енгізу кезінде нәтижені қайта алу оңай болады.

On‑prem жабдық пен тесттерді таңдаудағы жиі қателіктер

Пилот көбінесе орташа кешігуге сенуден құрылады. Скоринг пен антифродта маңыздысы — хвосттар: p95 және әсіресе p99. Олар «жылдам» деген сезімді «қолданушы күтеді» дегенге айналдырып, конверсияға әсер етеді, антифродта — жіберіліп кеткен шабуылдар мен қате блоктауларға әкеледі.

Екінші қате — үнемдеп, барлығын бір түйінге қою. Қасында модельді оқыту, экспорттар, есептер немесе лог сканингі сияқты ауыр фондық тапсырмалар жүргенде, инференс кезегі өсіп, p99 себебі белгісіз түрде секіреді.

On‑prem инфрақұрылым таңдауындағы типтік қателер:

• көп ядроны алады, бірақ төмен частота — бір сұрау ұзарады
• желіні төмен бағалайды (коммутатордағы кезектер, MTU қателері, пакет жоғалтулар)
• холодный старт бойынша қорытады (кэш прогрелмеген, модель мен фичалар жадыда емес)
• синтетикада тест жасап, нақты пиктер мен деректерсіз қорытынды жасайды

Пилоттар тәжірибесінен мысал: 200 RPS кезінде бәрі жақсы көрінеді, бірақ қысқа шоқтарда 800 RPS‑қа дейін p99 3 есе өседі. Себеп модельде емес — CPU‑ға бәсекелестік пен фичалар хранилищесіне баратын желідегі кезектер.

Жақсы әдет: прогретілен және холодный режимдерді бөлек өлшеу, нақты пиктер қосу және кешігумен қатар CPU ядролар бойынша пайдалану, жад, желі кезектері және I/O тіркеу.

Қысқа чек‑лист және келесі қадамдар

On‑prem инфрақұрылымды өлшенетін метрикалардан құраған дұрыс. Бір қысқа пилот көп айлық конфигурация талқылаулардан гөрі пайдалы.

Пилот: міндетті тексерулер

Пилотты нақты өмірге ұқсатып қойыңыз: сол таймауттар, сол пиктер, сол «жаман» сұраулар. Міндетті жинақ:

• бүкіл тізбек және инференс, фичалар мен желі бойынша p50/p95/p99
• пиктердегі мінез (RPS шоқтары, кезектер, p99 деградациясы)
• холодный старт (қызметті қайта жүктегеннен кейін кэштің прогреві, модельді жүктеу)
• бір түйіннің ақауы (ауыстыру, кешігу өсуі, сұраулар жоғалуы)
• уақытты бақылау (event time, таймзоналар, сағаттардың сәйкессіздігі)

Мұндай тексерістен кейін қайда уақыт кетіп жатқанын жиі көруге болады: NUMA мен CPU кэштерінде, жад жетіспеушілігінде, диск күтуінде немесе сегменттер арасындағы желі өтулерінде.

Сатып алудан бұрын не бекіту керек

Сатып алу кездейсоқтық болмауы үшін қысқа тізім дайындаңыз:

• p99 мақсаты мен есеппен 2–3 расталған конфигурация (CPU/RAM/IOPS резервімен)
• CPU талаптары (частота, NUMA‑байлау ережелері)
• RAM талаптары (модель, фичалар, кэштер свопсыз) және журналдар мен фичестор үшін NVMe
• желі талаптары (NIC, сегментация, шлюздер мен балансировщиктер қай жерде)
• масштабтау жоспары: қашан түйіндер қосылады және p99‑тың секірмеуін қалай тексересіз

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