Claude је 22. септембра имао повећан број грешака на више модела. У завршном ажурирању инцидента Anthropic наводи да је утицај трајао од 00:50 до 02:10 UTC, укупно 80 минута. Инцидент је означен као решен у 02:35 UTC. Међу погођеним компонентама наведени су claude.ai, API, Code и Cowork. У извештају се не каже да је сваки захтев отказао, нити се објављује објашњење основног узрока. Евиденција инцидента компаније Anthropic
За предузеће које користи вештачку интелигенцију у радном процесу, обнова услуге решава само део проблема. Захтеви клијената можда и даље чекају. Неко је можда почео ручно да обрађује случај док је аутоматски покушај још био активан. Надређени треба да зна који послови могу да се наставе, а које најпре треба проверити.
Повремена недоступност асистента јесте непријатност ако помаже некоме у разради идеја. Када иста услуга класификује пристигле случајеве, саставља одговоре и ажурира евиденцију, прекид постаје оперативни проблем. Корисна припрема је кратак план континуитета који запослени могу да прате и без приступа самој услузи вештачке интелигенције.
Овај водич користи хипотетички кориснички сервис да покаже како такав план може да функционише. Поступци су предлози које треба прилагодити и увежбати, а не тест који је спровео BIG CHANGE нити опис корисника погођених овим инцидентом.
Одаберите услугу коју можете да одржавате без вештачке интелигенције
Замислимо малог добављача опреме чији асистент разврстава пристигле захтеве за подршку и припрема одговоре на основу одобрених информација о производима. Запослени прегледају одговоре пре слања. Предузеће зависи од система за организовање реда захтева, иако људи и даље одговарају за садржај порука.
Ако асистент престане да одговара, прва одлука руководиоца јесте шта сервис и даље може да обећа. Запослени би могли да потврђују пријем захтева и обрађују случајеве са хитним роком, а одложе рутинска питања о производима. Потребан им је приступ оригиналним порукама и одобреним референтним материјалима ван асистента. У супротном, „пређите на ручни рад“ остаје упутство без средстава за његово спровођење.
Унапред изаберите услугу смањеног обима. Именујте особу која може да је активира, послове које треба паузирати и запослене који ће покрити преостале задатке. Одредите време за поновну процену како привремени аранжман не би трајао цело поподне без ичије провере. Обавештења клијентима треба да објасне кашњење и доступан начин добијања хитне помоћи, уз обећања која тим може да испуни.
Google-ове инжењерске смернице о преоптерећењу описују пружање услуге са смањеним функцијама, ограничавање саобраћаја и давање предности важним захтевима када су ресурси ограничени. То су проверене технике поузданости, а не дијагноза овог инцидента са Claude-ом. Примењене на кориснички сервис, подржавају намерно сужавање обима када нормална обрада не може да се настави. Google SRE: поступање при преоптерећењу
За услугу смањеног обима потребно је и ограничење капацитета. Две особе не могу неприметно да преузму обим посла аутоматизованог система који обично обрађује много више захтева. Забележите колико могу да обраде, шта ће чекати и када ће бити потребна додатна помоћ. Клијентима више користи уверљив рок за одговор него аутоматска потврда која оставља утисак да услуга ради уобичајено.
Водите евиденцију рада изван разговора са асистентом
Корисничком сервису је потребна евиденција случајева коју може да прочита док модел није доступан. То може бити постојећи систем за подршку. Важно је да предузеће може да утврди шта се догодило без тражења од прекинутог асистента да реконструише догађаје.
За сваки случај сачувајте првобитни захтев, одговорну особу или поступак и последњу потврђену радњу. Сачувани нацрт није исто што и послат одговор. Предложена измена записа о клијенту није исто што и измена коју је тај систем потврдио. Сачувајте доказе који омогућавају да се то разликује, уз иста ограничења приступа која важе за основне податке о клијенту.
Током прекида поделите посао у следеће практичне категорије:
- Спремно за почетак: обрада нити спољна радња још нису започете.
- Делимично припремљено: класификација или нацрт постоји, али следећи корак није завршен.
- Потврђено као завршено: одредишни систем бележи намеравану радњу.
- Неизвесно: радња је покушана, али потврда недостаје.
Неизвесне случајеве доделите особи која може да провери одговарајући систем пре наставка. Ако је асистент припремао одговор када је веза прекинута, нови нацрт може бити безопасан. Ако је друга алатка слала тај одговор, понављање целог задатка може довести до двоструког слања. Ова разлика припада евиденцији радног тока.
Anthropic у документацији API-ја наводи да токенизовани одговор може да откаже након почетног HTTP одговора 200, који означава успех. Приказ првог текста или пријем тог почетног статуса не доказује да је стигао цео одговор. Интеграција треба да препозна завршетак и делимичан рад сачува као делимичан. Claude API: документација о грешкама
Ограничите број поновних покушаја и одредите одговорну особу
Поновни покушај може да отклони привремени квар. Али може и да продужи неизвесност ако сваки слој засебно понавља исти посао. Питајте добављача софтвера да ли се поновни покушаји већ одвијају унутар његове клијентске библиотеке пре него што додате још једно дугме за понављање или аутоматску петљу.
Anthropic наводи да његове званичне SDK библиотеке подразумевано двапут аутоматски покушавају после привремених грешака, уз све веће паузе и поштовање упутства retry-after ако је присутно. Документација о грешкама такође разликује привремене проблеме сервера од грешака аутентификације, дозвола и погрешно обликованих захтева. Не може се претпоставити да ће понављање истог захтева отклонити сваку врсту грешке. Документовано понашање поновних покушаја у Claude-у
Оперативно правило за кориснички сервис треба да одреди када се аутоматски покушаји заустављају и ко затим преузима случај. Сачувајте идентификатор захтева ради отклањања проблема. Запосленима прикажите да ли посао чека, поново се покушава или захтева људско поступање, како несвесно не би покренули више паралелних покушаја.
AWS објашњава како радња може да успе иако њен одговор никада не стигне. Његови API-ји са својством идемпотентности користе посебан идентификатор захтева да препознају понављања и спрече додатне споредне ефекте. Пријемна услуга мора да примењује тај уговор; само додавање интерног броја случаја не пружа такву заштиту. AWS о безбедном понављању захтева
Питајте конкретно за радње које ваш поступак обухвата. Може ли поновљени покушај да отвори још један захтев за подршку или пошаље још један имејл? Ако заштита од дуплирања није доступна, план треба да захтева проверу одредишног записа пре новог покушаја. Понављање генерисања текста и понављање целог пословног процеса захтевају различите одлуке.
Резервни модел треба да има ужу дефиницију задатка
Алтернативна услуга вештачке интелигенције може да помогне у наставку рада, али други налог је тек почетак резервног решења. Замена треба да има одговарајућа упутства, одобрене референтне материјале и дозволу за обраду података. Потребан јој је и капацитет када је предузећу неопходна.
Пре него што покушате потпуну замену, изаберите ограничен резервни задатак. У нашем хипотетичком корисничком сервису други модел би могао да класификује рутинске поруке, док запослени обрађују одговоре клијентима. Тим би га могао проценити на репрезентативним случајевима, укључујући двосмислене називе производа и захтеве које треба проследити особи. Сам течан одговор не доказује да је модел поштовао правила подршке компаније.
Пре инцидента одлучите који подаци смеју да се шаљу алтернативној услузи. Запослени не би требало да импровизују тако што ће налепити податке о клијентима у личне налоге. У оквиру набавке проверите услове обраде података и начин приступа резервном решењу, упоредо са квалитетом резултата и ценом.
Различити називи модела такође не доказују независну доступност. Резервно решење и даље може да зависи од исте пријаве, мрежне везе, складишта докумената или софтвера за оркестрацију. Утврдите које зависности предложена алтернатива заиста избегава. Та вежба може да покаже да ручни ред захтева и доступни референтни документи пружају кориснију заштиту од другог модела који зависи од исте везе у квару.
Алтернативна решења захтевају одржавање како се упутства мењају и знање о производима застарева. Запослени треба да вежбају поступке које ретко користе. Мало предузеће може сасвим оправдано да задржи спорију ручну услугу уместо да плаћа дуплирање целог пословања. Одлука треба да зависи од трошкова одложеног посла и штете од погрешног одговора.
Наставите рад са провереним редом захтева
Када добављач пријави да је услуга обновљена, проверите мали узорак сопственог радног тока пре него што вратите уобичајен обим обраде. Укључите случај који проверава проналажење докумената и ажурирање евиденције, што је вашем предузећу потребно. Успешан одговор модела не потврђује да су сви повезани системи спремни.
Затим прегледајте посао на чекању. Уклоните случајеве већ решене ручно, проверите неизвесне радње и издвојите захтеве чије су се околности промениле. Клијент је можда доставио нове податке током прекида. Одговор заснован на старијој верзији случаја може да створи нови проблем након што се технички квар завршио.
Преостали посао поново покрећите у контролисаним серијама. Оставите капацитет за нове хитне захтеве и пратите да ли се ред смањује. Ако долазна потражња троши сав расположиви капацитет, заостатак ће се наставити иако сваки нови покушај успе. За надокнаду заостатка може бити потребно додатно особље, привремено смањење обима услуге или искрено продужење рокова за одговор.
У засебном бројчаном примеру, претпоставимо да стиже 24 случаја на сат, а обрада стане на 30 минута. Остаје 12 захтева на чекању. Ако сервис затим обрађује 36 случајева на сат док и даље пристиже 24 нових, требаће му сат времена да рашчисти заостатак. Ово су илустративне претпоставке, а не мерења инцидента са Claude-ом.
Google-ове смернице за циљеве нивоа услуге полазе од исхода важног корисницима и зависности неопходних за његово остварење. За овај сервис корисна мера могла би да буде удео хитних случајева на које је одговорено на одговарајући начин у обећаном року. Доступност добављача јесте важна, али предузеће мора да зна и да ли су његови клијенти добили услугу. Google SRE: увођење циљева нивоа услуге
Забележите када је настављена нормална услуга за клијенте, број нерешених случајева и исправке потребне након тога. Те мере откривају посао опоравка који добављачева страница са статусом не може да примети.
Увежбајте један прекид пре него што проширите аутоматизацију
Кратка вежба за столом може да открије недоступне дозволе или неодређену одговорност без ометања стварних клијената. Употребите неколико измишљених захтева за подршку и прођите кроз следећи редослед:
- Претпоставите да модел постане недоступан док припрема одговор. Питајте ко активира услугу смањеног обима и где запослени могу да пронађу оригинални захтев.
- Једном случају доделите потврђено послат одговор, а другом покушај слања чији је исход неизвестан. Проверите да ли тим зна у ком систему може да утврди шта се догодило.
- Претпоставите да је добављач обновио услугу док нови случајеви и даље пристижу. Одлучите који се послови први настављају и како ручно решени случајеви излазе из реда заостатка.
- Затражите од некога ко није написао план да објасни поступак и наведе које дозволе или записи му недостају.
Забележите на која питања вежба није могла да одговори. Исправке могу бити мале: приступ постојећем реду захтева, јасно дугме за паузу, сачувана потврда или одређена особа одговорна за опоравак. Ниједна мера не гарантује непрекидну услугу. Свака може да олакша ограничавање последица прекида, а да се не одбаце користи аутоматизације.
Пре него што асистенту поверите још једну оперативну одговорност, замолите колегу да покаже како би се тај посао обављао током прекида. Ако одговор зависи од недоступног асистента и његовог памћења започетог посла, план континуитета још није довршен.
