LLM провайдерінің денсаулығын өз метрикаларыңыз бойынша бағалау

Неге статус-страница сіздің көріністі көрсетпейді

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

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

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

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

Тағы бір тұзақ бар: ретрайлар. Олар жиі ақауды жасырып, жалған тұрақтылық сезімін береді. Формалды түрде сұрау сәтті аяқталды, бірақ тек екінші не үшінші әрекеттен кейін. Пайдаланушы кідірісті көреді, сервис көбірек токен мен уақыт жұмсайды, ал ішкі сәттілік статистикасы шындықтан жақсырақ көрінеді.

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

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

Провайдер денсаулығы өз жағыңызда есептеледі. "All systems operational" баннеріне емес, сервисіңіздің продакшн жүктемеңізге дәл қазір қалай жауап беретініне қарап.

Провайдердің денсаулығы деп нені айтамыз

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

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

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

Тәжірибеде бұл айырмашылық тез көрінеді. Мысалы, қолдау боты модельден өтініш санатын және клиентке арналған қысқа жауапты қайтаратын JSON сұрайды. Провайдер күні бойы дерлік "қолжетімді" болуы мүмкін, бірақ жауаптардың 7%-ы бұзылған форматта келсе, тағы 3%-ы бос болса, өнім үшін бұл жаман күн.

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

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

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

Өз жағыңызда қандай метрикалар жинау керек

Тек HTTP 200-ді санау аздық етеді. Провайдердің денсаулығын бағалау үшін пайдаланушыға жұмыс істейтін жауап жетті ме, ол қаншалықты тез келді және оған сенуге бола ма — соны көрсететін метрикалар керек.

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

Желілік ақауларды да бөлек санаңыз. Таймаут, қосылымның үзілуі және сұраудың тоқтатылуы — бір нәрсе емес. Таймаут көбіне шамадан тыс жүктеме немесе тым баяу генерация туралы айтады. Үзілу көбіне желіге немесе проксиге байланысты. Тоқтатуды әдетте клиент жасайды, оны провайдер қателерімен араластырмау керек, әйтпесе LLM API қолжетімділігін төмен көрсетесіз.

Кідіріс бойынша орташа мәнге емес, екі нүктедегі P50 және P95-ке қараңыз: бірінші токенге дейін және толық жауапқа дейін. Бірінші метрика чаттағы және copilot-тардағы жылдамдық сезіміне әсер етеді. Екіншісі ұзын генерациялар, қысқаша мазмұндау және JSON-шығарылымдар үшін маңызды. Орташа уақыт мұнда алдайды: бір өте баяу жауап бүкіл күнді бұзуы мүмкін, ал пайдаланушы дәл P95-тегі ұзын құйрықты байқайды.

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

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

Бірінші дашборд үшін әдетте мына жинақ жеткілікті:

• жауап кодтары топтар бойынша және 429 бөлек
• таймауттар, үзілімдер, тоқтатулар
• бірінші токенге дейінгі P50 және P95
• толық жауапқа дейінгі P50 және P95
• бұзылған JSON, бос, қысқа және күтпеген бас тартулар

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

Деректерді шатастырмай қалай бөлу керек

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

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

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

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

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

Канареечные тексерулерді де продакшнмен араластырмау қажет. Синтетикалық сұрау тұрақты: бірдей промпт, бірдей жауап өлшемі, бірдей жиілік. Ал продакшн трафик басқаша өмір сүреді. Пайдаланушылар ұзағырақ жазады, кесте сұрайды, үлкен мәтін бөліктерін тіркейді. Мұның бәрін бірге қоссаңыз, LLM API қолжетімділігі нақты пайдаланушылардікінен жақсырақ болып көрінеді.

Шу шығаратын тағы бір нәрсе — сұрау ұзындығы. 50 токендік қысқа промпт пен 8 мың токендік ұзын құжат бір қоржында отырмауы керек. Әйтпесе API провайдерінің қателері, таймауттар және кідіріс ауыр жүктеменің қалыпты әсерімен араласып кетеді.

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

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

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

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

Әр метриканы бір 0-ден 100-ге дейінгі шкалаға келтірген дұрыс. Әйтпесе 1% таймаут, 4 секунд кідіріс және 7% бұзылған JSON-ды адал түрде қоса алмайсыз. Нормалау "нарық бойынша" емес, өз шектеріңіз бойынша қойылады. Бір өнім үшін P95 3 секунд қабылданарлық, басқасы үшін бұл — сәтсіздік.

Қарапайым нұсқа мынадай көрінеді:

скор = 0.30 * availability + 0.20 * latency + 0.20 * quality + 0.15 * api_errors + 0.10 * timeouts + 0.05 * format

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

Айыппұлды да әртүрлі еткен жөн. P95-тің 1,8-ден 2,2 секундқа өсуі трафикті күрт бұруға себеп емес. Ал таймауттардың 0,2%-дан 1,5%-ға секіруі қауіпті. Бұзылған форматқа да солай қараңыз. Егер парсер жауапты оқи алмаса, мұндай ақауды қосымша 300-500 мс-тан қаттырақ жазалау дұрыс.

Скорды бір минутқа есептемеңіз. Қысқа терезеде, әсіресе трафик аз болса, шу тым көп болады. Маршрутизация үшін 15-30 минуттық жылжымалы терезе қолданған дұрыс, ал трендті тексеру үшін бірнеше сағаттық ұзын терезені қатар ұстаңыз. Тағы бір пайдалы қорғаныс — ең аз таңдау көлемі. Егер 8-ақ сұрау болса, мұндай скорды шешуші деп санауға ерте.

Және тек жалпы баллды емес, оның неге түскенін де сақтаңыз. "Скор 61: таймауттар -18, формат -14, сапа -5" деген жазба жай қызыл индикатордан пайдалырақ. Команда бірден не бұзылғанын түсінеді де, болжам жасауға бір сағат жұмсамайды.

Продакшн жүктемесіндегі мысал

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

Күндіз команда минутына шамамен 200 сұрау жібереді. A провайдері HTTP қателерін дерлік бермейді, әрі жалпы статус-страница бойынша онда бәрі жақсы. Бірақ бірінші токенге дейінгі уақыт 0,9 секундтан 1,8 секундқа өседі. Бұл қолдау чатында бірден сезіледі: оператор ұзағырақ күтеді, клиент кідірісті көреді, ал сұраулардың бір бөлігі қайталап жіберіледі.

Тек LLM API қолжетімділігіне қарасаңыз, A провайдері қалыпты сияқты. Өз метрикаларыңызға қарасаңыз, басқа нәрсе көрінеді: сервис тірі, бірақ сіздің сценарий үшін нашар жұмыс істеп тұр. JSON келеді, бірақ баяу. Өтініштерді классификациялау үшін бұл әлі де төзуге болады, ал диалог үшін — жоқ.

Түнде трафик B провайдеріне ауысады. Оның бірінші токенге дейінгі уақыты жақсырақ, бірақ басқа мәселе өседі: жауаптар жиірек ортасынан үзіліп қалады. HTTP-код 200 күйінде қалады, статус-страница да жасыл, бірақ аяқталған жауаптар үлесі, мысалы, 98%-дан 91%-ға түседі. Логта бұл бірден көрінеді: JSON-дегі жабатын жақша келмеді, басымдық өрісі бос, парсер бұзылады.

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

Айтайық, қолжетімділікке 40% салмақ, кідірісқа 25%, JSON жарамдылығына 20% және жауаптың аяқталуына 15% бердіңіз. Күндіз A провайдерінің скоры кідіріс салдарынан 100-дің 78-іне түседі, ал одан өзінен әлі алерт келмеген. Түнде B провайдерінің скоры ағымның үзілуінен 72-ге дейін түседі.

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

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

Командалар жиі жіберетін қателер

Егер провайдер HTTP 200 қайтарса, бұл сұрау жақсы өтті деген сөз емес. Модель жауапты қысқартып жіберуі, бос жол қайтаруы, JSON-ды бұзуы немесе сіздің сценарийіңіз үшін тым кеш жауап беруі мүмкін. Скоринг үшін 200 — тек жеткізу фактісі, қалыпты нәтиже емес.

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

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

Командалар салыстыруды өздері де бұзып жібереді. Олар промптты, temperature параметрін, system нұсқауларын немесе context өлшемін өзгертіп алады да, кейін A провайдері B-ден жақсы деген қорытынды шығарады. Бұл енді басқа тест. Егер жауап сапасын салыстырсаңыз, кіріс бүкіл салыстыру терезесінде бірдей қалуы керек.

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

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

Іске қосар алдындағы чек-лист

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

Продакшн жүктемесіне дейін кемінде мыналарды тексеріңіз.

• Бір request_id сұрау жолының бәрінен өтуі керек: клиент, backend, роутер, модельді шақыру, ретрайлар және жауап.
• Әр тапсырма үшін өз канареечные сұрауларыңыздың жиыны керек. Бір әмбебап промпт көбіне жалған көрсетеді.
• Алерттер тек қате үлесіне емес, кідіріс пен жауап форматына да қарауы керек.

Тағы үш тексеріс бар, олар көбіне ұзақ түнгі талқылаулардан құтқарады.

• Дашбордта модель бойынша да, провайдер бойынша да срездер болуы керек.
• Ретрайлар мен таймауттарды бастапқы жауаптардан бөлек санау қажет.
• Команда маршрутты ауыстыру шегі мен трафикті кері қайтару ережелерін алдын ала келіскені дұрыс.

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

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

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

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

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

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

Сосын әрекеттерді кезең-кезеңімен қосыңыз:

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

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

Егер трафик airouter.kz ішіндегі AI Router арқылы өтсе, мұндай метрикаларды бір жерге жинау оңайырақ: сіз base_url-ді api.airouter.kz-ке ауыстырып, OpenAI-үйлесімді endpoint арқылы жұмыс істеуді жалғастырасыз, тіпті ішінде бірнеше провайдер мен модельді салыстырып отырсаңыз да. Бұл әр вендордың статус-страницасына емес, өз метрикаларыңызға сүйеніп маршруттарды бағалау керек кезде ыңғайлы.

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