LLM-сервис дежурныйы үшін алғашқы 15 минутқа арналған Runbook

Алғашқы 15 минутта әдетте не бұзылады

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

Сондықтан графиктер бір-біріне қайшы көрінуі мүмкін. Бір жерде 5xx күрт өседі, басқа жерде 429 көбейеді, ал өнімдегі шағымдар әртүрлі ақау сияқты естіледі. Шын мәнінде, бастауы бір болуы мүмкін: провайдер баяулай бастайды, кезек үлкейеді, қайталау сұраныстары жүктемені арттырады, содан кейін лимит пен бюджетке қатысты қателер қаптайды.

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

Кідіріс одан да жағымсыз. Ол кіретін ағын қатты өзгермесе де өседі. Бұл провайдер сұраныстарды ұзақ ұстаса, worker пул толып қалса, prompt cache өшсе немесе модель өз GPU ресурсында тұрып қалып, кезек жинай бастағанда болады. Дежурный үшін бұл алдамшы көрінеді: трафик бірқалыпты, ал пайдаланушылар сервис "ойланып" 20-30 секунд кетеді деп жазады.

Әдетте шағымдар бірден бірнеше түрде келеді:

• "Жауаптар жоғалды"
• "Бәрі баяулап кетті"
• "Сапа қатты нашарлады"
• "Шот тым тез өсіп жатыр"

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

Жақсы runbook алғашқы 15 минутта "бір қатені" іздеуге емес, үш нұсқаның бірін тез таңдауға көмектеседі: маршрут бұзылды, генерация ұзындығы өсті немесе жүйе әр сұранысқа көбірек қайталау жұмсай бастады.

Инцидентке дейін не дайындау керек

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

Алдымен шектерді анықтаңыз. "Бір нәрсе баяулап тұр" дегендей жалпы сөздер емес, нақты сан керек: қате пайызы қандай болса — авария, әр маңызды сценарий үшін қандай p95 latency қалыпты және бір сұранысқа, мың сұранысқа не сессияға шаққандағы құнның шегі қайда. Егер сервис бірнеше модель қолданса, шектерді бөлек сақтаңыз. Үлкен сыртқы модельдің, open-weight модельдің және rerank шақыруының қалыпты кідірісі әртүрлі.

Келесі қадам — маршрут картасын дайындау. Дежурныйдың қолында қарапайым кесте болуы керек: продта қандай модель тұр, ол қандай провайдер арқылы өтеді, қандай қосалқы жол бар және ауысқанда не өзгереді. Егер команда AI Router арқылы жұмыс істесе, бұл кестеде қандай сценарийлерді сол api.airouter.kz endpoint арқылы басқа провайдерге тез ауыстыруға болатынын, ал қайсысын data residency мен төмен кідіріс маңызды болғанда ел ішінде орналастырылған модельге жіберуге болатынын бірден белгілеу ыңғайлы.

Үшінші блок — соңғы өзгерістер журналы. Проблеманың көзі көбіне өте қарапайым: жаңа prompt, өскен max_tokens, қосылған flag, әдепкі модельдің ауысуы, клиенттің жаңа релизі немесе жаңа rate limit. Дежурный мұны жадынан іздемеуі керек. Кемі соңғы 72 сағаттағы өзгерістердің қысқа тізімі керек: уақыты, авторы және күтілген әсері.

Бір жерде мына нәрселер жатуы тиіс:

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

Соңғысы жиі бағаланбайды. Тек есімдер тізімі емес, қоңырау шалу тәртібі керек: уақытша қымбат модельді өшіруге кім рұқсат береді, жауапты деградацияны кім келіседі, SLA-сы қатаң клиенттерге кім жауап береді. Сонда 02:15-те бірінші кімге жазу керегін ойлап уақыт жоғалтпайсыз.

Жақсы құрастырылған runbook сағаттарды үнемдемейді. Көбіне ол алғашқы 7-10 минутты сақтайды, ал бұл — жергілікті құлдырау мен пайдаланушыларға көрінетін инциденттің айырмасы.

Алғашқы 5 минут

Әуелі алерттің тірі екенін, әлде жай шу екенін тексеріңіз. Бір график жеткіліксіз. Оны кем дегенде екі сигналмен салыстырыңыз: қате логтары, p95 latency, сұраныс саны, токен шығыны немесе өнімнен келген шағымдар.

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

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

Осы минуттарда симптомдарды үш қорапқа бөліп алған пайдалы:

• қателер: 4xx, 5xx, таймауттар, rate limit, бос немесе үзіліп қалған жауаптар
• баға: сұраныс құны, бір сұранысқа кететін токендер немесе қымбат модель үлесі өсті
• кідіріс: p95 және p99, кезек, алғашқы токенге дейінгі уақыт өсті

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

Келесі қадам қарапайым және көбіне ең пайдалысы: жүйе мінезін өзі өзгертетіннің бәрін паузаға қойыңыз. Таралуын тоқтатыңыз, canary-ді, автоэксперименттерді, A/B тестерді, жаңа модельге автоматты ауысуды, егер ол қатаң лимиттермен шектелмесе, доғарыңыз. Әуелі көріністі бекітіңіз, содан кейін баптауларды өзгертіңіз.

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

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

5-10 минут аралығы

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

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

Сервисті үнсіз бұзатын баптауларды тексеріңіз. Таймауттар қазіргі модель үшін тым қысқа болып қалған болуы мүмкін. Rate limit кілт деңгейінде шегіне жеткен болуы мүмкін. Жауап ұзындығы да жиі бірден екі метрикаға соғады: кідіріс пен есеп өседі.

Бұл сәттегі жылдам тексеру әдетте мынадай болады:

• әр модель мен маршрут бойынша p95 latency және error rate салыстырыңыз
• prompt tokens және completion tokens күрт өскен клиенттерді немесе кілттерді табыңыз
• жиі қолданылатын сұраныстарда cache hit үлесі түспегенін қараңыз
• қымбат маршруттың әдеттегіден жиірек іске қосылмағанын тексеріңіз

Кештің түсуі көбіне "бірден бәрі қымбаттап, баяулап кетті" деп көрінеді. Шын мәнінде сервис қайталанатын жауаптарға кіре алмай қалған, сондықтан әр өтініш толық генерацияға кеткен. Мұндай жағдай prompt, system message немесе sampling параметрлері өзгергеннен кейін болады.

Егер кідіріс пен баға бірге өссе, мінсіз диагнозды күтпеңіз. 5-10 минутта шығынды шектеген дұрыс. Қиын маршруттағы max_tokens-ты азайтыңыз. Fallback тізбегіндегі ең қымбат жолды алып тастаңыз. Жақында тексерілген, сапасы қанағаттанарлық қосалқы модельге трафиктің бір бөлігін аударыңыз.

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

10-15 минут аралығы

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

Деградация режимін есеп үшін емес, сервис тыныс алуды жалғастыруы үшін қосады. Ол толық жауап сапасы SLA-ға, бағаға немесе кезек ұзындығына соққы беріп тұрған кезде керек. Тәжірибеде бұл max_tokens-ты уақытша азайту, екінші кезектегі сценарийлер үшін tool calling-ді өшіру, шұғыл емес тапсырмаларды кезекке қою немесе қымбат модельден жылдамырақ модельге көшу болуы мүмкін. Егер команда AI Router арқылы жұмыс істесе, жылдам қадам көбіне бірдей OpenAI-үйлесімді endpoint арқылы трафиктің бір бөлігін басқа провайдерге не басқа модельге ауыстыру болады.

Нашар ой — бірден төрт нәрсені өзгерту. Егер сіз модельді, таймаутты, қайталауды және лимиттерді қатар өзгертсеңіз, бес минуттан соң не істегеніңізді ешкім түсінбейді. Бір ғана әрекетті таңдап, дабыл тудырған сол метрикаларды бақылаған дұрыс. Мысалы, проблемалы модельге түсетін трафик үлесін 80%-дан 20%-ға түсіріп, error rate, p95 және орташа сұраныс құнының төмендегенін тексеріңіз.

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

Эскалация үшін әдетте мына жинақ жеткілікті:

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

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

Баға өсімін трафик өсімінен қалай тез ажыратуға болады

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

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

Prompt пен жауап көлемін бөлек тексеріңіз. Сұраныс саны өзгермесе де, system prompt ұзарса, пайдаланушылар көбірек контекст жібере бастаса немесе модель тым егжей-тегжейлі жауап бере бастаса, шығын күрт өсуі мүмкін. input tokens пен output tokens бойынша орташа мән мен p95-ке қараңыз. Тек output tokens өсуі көбіне ұзын жауаптарды немесе құралдарды шақырудың артық циклдерін көрсетеді.

Жылдам срезді бес нүкте бойынша алған дұрыс:

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

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

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

Түнгі ауысым мысалы

02:13. Түнгі релизден кейін дашборд жағымсыз ауысымды көрсетеді: p95 4 секундтан 11 секундқа өскен. 5xx онша өзгермейді, таймаут аз, ал клиент шағымдары әлі түспеген. Бұл қауіпті жағдай. Сервис формалды түрде тірі, бірақ пайдаланушы әлдеқашан тым ұзақ күтіп отыр, ал ақша әдеттегіден тезірек кетіп жатыр.

Дежурный алдымен жалпы графикке емес, маршруттар бойынша срезге қарайды. Бір минуттағы сұраныс аздап қана артқан, бірақ бір жауаптағы орташа output tokens екі есеге жуық өскен. Баға графигінде тағы бір із көрінеді: релизден кейін трафиктің бір бөлігі fallback-қа өткен, ал fallback енді әдеттегі модельге емес, қымбатырақ модельге апарады. Егер команда бірыңғай шлюз арқылы жұмыс істесе, мұндай ауытқу маршрут үлесі мен 1K токен бағасы арқылы жақсы көрінеді.

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

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

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

Осыдан кейін дежурный журналға үш фактіні бекітеді: қандай релиз шықты, қай fallback қосылды және қандай max_tokens лимиті қайтарылды. Таңертең осы үш жол бойынша команда түпкі себепті тез табады да, келесі түнгі ауытқу 20 минут емес, 5 минут алатындай runbook-ты жаңартады.

Дежурныйлар жиі қай жерде қателеседі

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

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

Орташа мән тым ерте тыныштандырады

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

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

Тағы бір жиі қателік — тек қателерді емдеп, шығынға қарамау. Мысалы, 5xx басқа маршрутқа ауысқаннан кейін жоғалды. Жақсы. Бірақ 1000 токенге шаққандағы құн, жауап ұзындығы және қайталанған сұраныстар саны не болды? Кейде қате тек жүйе ұзындау, баяуырақ және қымбатырақ жауап бере бастағандықтан жоғалады.

Трафикті сапаны жылдам тексермей ауыстыру

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

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

Соңғы қате, ең жалықтыратыны және ең қымбаты: дежурный өз әрекеттерін нақты жазып қалдырмайды. Уақыт белгілері болмаса, команда кейін p99 қашан өскенін, қайталауды кім қосқанын және қандай түзетуден кейін баға секіргенін дауласып жатады. Сондықтан runbook қарапайым жазбаны талап етуі керек: не өзгерді, қашан өзгерді және 2-3 минуттан кейін қандай әсер болды.

Эскалация алдында қысқа чек-парақ

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

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

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

Эскалация алдында мына бес нәрсені тексеріңіз:

• басталу уақыты, қазіргі error rate, p95 немесе бір сұраныс құны бар
• не қатты өсіп тұрғаны түсінікті: қате ме, кідіріс пе, әлде шығын ба
• қандай модельдер, API key-лер, провайдерлер және клиенттер инцидентке кіргені көрінеді
• бір қауіпсіз әрекет жасалып, оның әсері 2-3 минуттан соң өлшенген
• сервис иесіне сандар мен келесі қадамды қамтитын қысқа хабар жіберілген

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

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

Сервис иесіне арналған хабар 4-5 жолдан аспауы керек. Мысалы: "02:14-де 5xx өсімі басталды, қазір сұраныстардың 12%-ы қате береді. Qwen 3 және DeepSeek V3.2 екі клиентте әсерленді. 30% трафикті резервтік маршрутқа ауыстырдық, 3 минутта error rate 7%-ға түсті. Провайдер лимиттерін тексеру және толық ауыстыру туралы шешім керек".

Инциденттен кейін runbook-қа не қосу керек

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

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

Runbook-ты ақау түріне бөліңіз

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

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

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

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

Runbook-ты ақаудан кейін бірден жаңартыңыз

Ақаудан кейін 15-20 минуттық қысқа талқылау жеткілікті. Қай сигнал кеш байқалғанын, қай қадам бірден көмектескенін, ненің артық болғанын және дежурный экранында не жетіспегенін бекітіңіз.

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

Қазір AI Router арқылы мұндай схема құрып жатқан командаларға маршруттар, аудит логтары және лимиттер бойынша бір дереккөз ұстау оңайырақ. Бірақ жақсы шлюз болса да runbook-ты ештеңе алмастырмайды: инцидент кезінде жеңетін — баптауы көп адам емес, алғашқы 15 минутта бірінен кейін бірі дұрыс шешім қабылдайтын адам.