Сбалар кезінде провайдерді флаппингсіз автоматты түрде ажырату

Канал құлаған кезде не болады

Провайдердегі ақау көбіне бірден үзіліп қалғандай көрінбейді. Алдымен таймауттар көбейеді, кейін жеке-жеке 5xx қателер келеді, сосын қателер топ-тобымен шыға бастайды. Бірнеше минуттың ішінде канал "кейде жауап береді" күйінен "кезекті жұтып, дерлік ештеңе қайтармайтын" күйге өтіп кетуі мүмкін.

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

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

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

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

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

Қандай қателерді есептеу керек

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

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

429 кодын бөлек санаған дұрыс. Ол көбіне толық қолжетімсіздікті емес, квотаға, лимитке немесе жергілікті rate limit-ке тірелгеніңізді білдіреді. Егер 429-ды таймауттармен және 5xx қателерімен араластырсаңыз, роутер провайдер өлді деп ойлап, трафикті орынсыз басқа жаққа аудара бастайды.

Клиенттік қателерді де бір шелекке салудың керегі жоқ. Тым ұзын prompt, бұзылған JSON немесе модель параметрінің қате берілуі — провайдердің мәселесі емес. 429-ды бөлек өңдеуден басқа 4xx кодтарын отсечение логикасынан шығарған дұрыс.

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

Трафикке де төменгі шек керек. Егер модель екі сұрау алып, екеуі де құласа, бұл әлі статистика емес. Метрикаға сенуді терезеде кемі 20-50 сұрау жиналғанда бастаған практикалырақ. Таймауттар мен 5xx үшін бөлек шектер де көмектеседі: кейде провайдер түгел құламайды, тек тым баяу жауап бере бастайды. 429 үшін каналды бірден кескеннен гөрі, жүктемені азайту немесе backoff қосу пайдалырақ.

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

Терезе мен шектерді қалай таңдау керек

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

Чат үшін әдетте 30–60 секунд жеткілікті. Онда жылдам реакция керек: егер провайдер 5xx немесе таймауттарды шығара бастаса, пайдаланушы оны бірден байқайды. Batch тапсырмалар үшін терезені ұзағырақ жасауға болады, мысалы 3–10 минут. Пакеттік өңдеуде қате бағасы басқаша: сирек серпіліс онша қорқынышты емес, ал жалған өшіру үлкен көлемді қымбатырақ немесе баяуырақ арнаға ығыстырып жіберуі мүмкін.

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

Бастапқы нұсқа ретінде мынадай баптауларды алуға болады:

• чат үшін: 60 секунд терезе және 20-30% қате кезінде отсечение
• чат үшін: қатарынан 5-7 сәтсіздік болса, бірден өшіру
• batch тапсырмалар үшін: 5 минут терезе және 10-15% қате кезінде отсечение
• batch тапсырмалар үшін: кезекке тығып жатса, таймауттарға бөлек лимит

Трафикке төменгі шек қойылмаса, ереже жиі жалған сигнал береді. Егер бір минутта бар болғаны үш сұрау өтіп, оның бірі құласа, сіз 33% қате көресіз, бірақ бұл жай шу болуы мүмкін. Сондықтан шешім қабылдамастан бұрын канал терезеде кемі 20-50 сұрау алсын. Сирек трафик үшін тек пайызға емес, қателердің абсолют санына да қараған пайдалы.

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

Егер модельдерді бір шлюз арқылы жүргізсеңіз, шектерді сценарийге қарай бөлек қою жақсы. Интерактивті чат, пакеттегі таңбалау және ішкі пайплайндар бірдей қателер терезесінде өмір сүрмеуі керек.

Флаппингсіз трафикті қалай қайтаруға болады

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

Алдымен каналға тыныс беріңіз. Әдетте 5-15 минут cooldown жеткілікті, бірақ нақты уақыт сұрау жиілігі мен қайта қателесудің бағасына байланысты. Егер жүйе жаңа ғана маршрутты өшірсе, трафикті қайтадан тұрақсыз каналға тықпай, сәл ұзақтау күткен дұрыс.

Боевый трафикті қайтармас бұрын бірнеше сынақ сұрауын жіберіңіз. Олар нақты сұрауларға ұқсас болуы керек: prompt өлшемі де, жауап түрі де, уақыт лимиті де бірдей болсын. Тек 200 OK алғандай формалды тексеру тым әлсіз. Канал жауап беруі мүмкін, бірақ бұрынғыдан үш есе баяу болуы да ықтимал.

Жұмыс істейтін схема қарапайым: алдымен трафиктің 5% қайтарып, 3-5 минут күтіңіз, сосын үлесті 15%-ға көтеріңіз, кейін 50%-ға жеткізіңіз, ал тұрақты терезеден кейін ғана 100% ашыңыз. Кішкентай үлестер флаппингті бірден толық қайтарудан жақсырақ басады. Егер канал қайтадан баяулай бастаса, сіз тек ағынның бір бөлігін ғана жоғалтасыз, бүкіл трафикті емес.

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

Жақсы ереже қызықсыз естіледі, бірақ жұмыс істейді: ramp-up кезінде қате не кідірістің кез келген елеулі өсуі маршрутты cooldown-ға қайтарады. Рұқсат беретін ерекше жағдайларсыз және "тағы аздап күтейік" деген сөзсіз. Әдетте схеманы бұзатын дәл сол жұмсартулар.

Схеманы қадамдап қалай баптау керек

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

Содан кейін баптау әдетте былай жүреді:

1. 2-4 сценарийді сипаттап, әрқайсысына жеке SLO қойыңыз. Онлайн чат үшін жылдам жауап пен таймауттардың аз болуы маңызды. Batch тапсырмалар үшін сәтті сұраулардың жалпы үлесі маңыздырақ.
2. Пайдаланушы тәжірибесіне шынымен әсер ететін метрикаларды таңдаңыз: error rate, latency және timeout rate. Көбіне осы жеткілікті.
3. Бұрынғы инциденттерді алып, бастапқы шектерді болжаммен емес, нақты дерекпен қойыңыз. Егер ақау кезінде timeout rate 7%-дан асса, ал p95 latency 10 секундтан асып кетсе, сол сандардан бастаңыз.
4. Ережені тарихи логтарда өткізіп көріңіз. Сонда схема провайдерді қанша рет орынсыз өшірер еді және терезе қай жерде сәтсіз таңдалғанын көресіз.
5. Fallback-ты алдымен трафиктің шағын үлесінде қосыңыз. Көбіне 5-10% жеткілікті: бұл нақты жүктемеде логиканы тексеріп, артық сұрау көшіруді болдырмайды.

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

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

Жақсы бастапқы схема әдетте скучный болады. Бұл — артықшылық. Ол тек айқын ақауларды кеседі, трафикті бес минут сайын жұлқыламайды және кезекшіге түсінікті қолмен басқару қалдырады.

Екі провайдермен мысал

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

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

Банкте мынадай ереже болуы мүмкін: 120 секунд терезе, тек таймауттар мен 5xx есептеледі, ал 4xx қозғалмайды. Канал осы терезеде кемі 200 сұраудан өтіп, сәтсіздік үлесі 18%-дан асса, өшеді. Бір кездейсоқ серпіліс шектен өтпейді. Ал шынайы инцидентті жүйе тез байқайды.

Әрі қарай көрініс былай болады:

• 10:00-де негізгі провайдер қалыпты жауап береді, орташа кідіріс әдеттегі шекте
• 10:01-ге қарай таймауттар көбейеді, бірақ өшіруге әлі жетпейді
• 10:02-де соңғы 120 секунд ішінде 240 сұрау жиналып, оның 52-сі таймаутпен немесе 5xx-пен аяқталады
• ереже іске қосылады да, резервтік маршрут инцидент аяқталғанша бүкіл трафикті алады

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

Негізгі провайдердегі инцидент аяқталған кезде, трафикті бірден түгел қайтармаңыз. Мысалы, бес минут жаңа ақау белгісі болмаса, жүйе тек 10% трафикті тексеру үшін қайта жібереді. Егер таймауттар өспесе, үлесті ары қарай көтеруге болады: 25%, кейін 50%, тек содан кейін 100%.

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

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

Ең жиі қате — барлық модельге, барлық провайдерге және барлық сценарийге бірдей шек қою. Бұл дерлік әрдайым тепе-теңдікті бұзады. Қысқа классификация сұрауы мен ұзақ чат әртүрлі ырғақта жүреді, ал шағын open weight модель мен ірі frontier модель кідіріс пен таймаут бойынша әртүрлі норма береді. Егер ереже бәріне бірдей болса, сіз не тірі арнаны тым ерте кесесіз, не өлі арнаны тым ұзақ ұстайсыз.

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

Көп адам 400 және 422 жауаптарын провайдердің сәтсіздігі деп есептейді. Бұл схеманы бұзады. Мұндай кодтар көбіне қате сұрауды, тым ұзын контексті, форматтың бұзылуын немесе валидация қатесін білдіреді. Егер оларды 5xx, таймауттар және желілік үзілістермен араластырсаңыз, маршруттау дұрыс емес ақауды емдей бастайды.

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

Ең қымбат қате трафикті қайтарғанда болады. Канал бір сәтті жауап берді де, команда оған бірден сұраулардың 100%-ын қайтарады. Бір минуттан соң ол қайта құлайды, сосын аздап тіріліп, бәрі қайта басталады — флаппинг. Дұрыс схема трафикті сатымен қайтарады: 5%, кейін 20%, кейін 50%, ал тұрақты терезеден кейін ғана толық көлем.

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

Жіберер алдындағы чек-лист

Жіберер алдында қысқа тізімді қарап шығу пайдалы.

• Терезеде жеткілікті сұрау болуы керек. Егер модельге минутына 3-5 сұрау ғана келсе, қысқа терезе көп нәрсе білдірмейді. Сирек трафик үшін терезені ұзартып, мысалы 30-50 сұраудан кем емес бақылау шегін қойыңыз.
• 429 мен 5xx-ті бөліңіз. 429 коды көбіне ақауды емес, лимитті білдіреді. Мұндайда алдымен трафик үлесін азайту немесе backoff қосу дұрыс.
• Отсечение жасалғаннан кейін cooldown қойыңыз. Ол өтпейінше, қалыпты трафикті қайтармаңыз. Алдымен 1-5% сияқты сынақ үлесін беріп, жаңа қателер терезесін бақылаңыз.
• Дашборд метрикаларды провайдер мен модель бойынша бөлек көрсетуі керек. Әйтпесе сіз тек жалпы нашарлауды көріп, бүкіл арна ма, әлде бір нақты модель ме — түсінбей қаласыз.
• Командада қолмен override және шешімдер журналы болуы керек. Кезекші инженер провайдерді алып тастап, оны қайта ротацияға қосып, сосын қандай шек іске қосылғанын, қай терезеде және кім күйін өзгерткенін көрсететін жазбаны аша алуы тиіс.

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

Бірінші релизден кейін не істеу керек

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

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

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

Кемінде бір рет тест трафикте оқу-жаттығу ақауын жасаңыз. Бір провайдерге күштеп 5xx, таймаут немесе кідірістің күрт өсуін беріп, жүйе арнаны өшіре ме, флаппингке түспей ме және трафикті тыныш қайтара ала ма — соны тексеріңіз. Толық продда емес, 1% тест сұранысында мәселе табылғаны әлдеқайда жақсы.

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

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