Nagdulot ng mas maraming error kaysa karaniwan sa maraming modelo ang Claude noong Setyembre 22. Ayon sa huling update ng Anthropic, tumagal ang epekto mula 00:50 hanggang 02:10 UTC, o 80 minuto. Idineklara nitong nalutas na ang insidente noong 02:35 UTC. Kabilang sa mga bahaging naapektuhan ang claude.ai, API, Code at Cowork. Hindi sinasabi sa ulat na pumalya ang bawat request, at wala itong inilalathalang paliwanag sa ugat ng problema. Ulat ng insidente ng Anthropic
Para sa negosyong gumagamit ng AI sa loob ng aktuwal na proseso ng trabaho, bahagi lang ng problema ang muling paggana ng serbisyo. Maaaring naghihintay pa rin ang mga kahilingan ng customer. Baka may nagsimulang humawak ng kaso nang mano-mano habang aktibo pa ang awtomatikong pagtatangka. Kailangang malaman ng superbisor kung aling trabaho ang puwedeng ipagpatuloy at alin ang dapat munang siyasatin.
Abala lang kapag paminsan-minsang hindi available ang assistant na ginagamit sa pagbuo ng mga ideya. Pero nagiging suliranin sa operasyon ang pagkaantala kapag ginagamit ang parehong serbisyo sa pag-uuri ng mga papasok na kaso, pagbuo ng sagot at pag-update ng mga rekord. Makakatulong ang isang maikling plano sa pagpapatuloy ng operasyon na kayang sundin ng mga tauhan kahit walang access sa AI.
Gumagamit ang gabay na ito ng kathang-isip na help desk para ipakita kung paano maaaring gumana ang gayong plano. Mga mungkahing proseso ang inilalahad para iakma at sanayin; hindi ito pagsubok na isinagawa ng BIG CHANGE o paglalarawan sa mga customer na naapektuhan ng insidenteng ito.
Piliin ang serbisyong mapananatili mo kahit walang AI
Isipin ang isang maliit na supplier ng kagamitan na gumagamit ng assistant para uriin ang mga papasok na mensahe sa suporta at maghanda ng sagot mula sa aprubadong impormasyon ng produkto. Sinusuri ng mga tauhan ang mga tugon bago ipadala. Umaasa ang negosyo sa sistema sa pag-aayos ng pila, kahit tao pa rin ang responsable sa mga sagot.
Kung tumigil sa pagtugon ang assistant, unang kailangang pagpasiyahan ng manager kung ano pa ang maipapangako ng help desk. Maaari pa ring kumpirmahin ng mga tauhan ang pagtanggap sa mga kahilingan at asikasuhin ang mga kasong malapit na ang takdang oras, habang ipinagpapaliban ang mga karaniwang paliwanag tungkol sa produkto. Kailangan nila ng access sa orihinal na mga mensahe at aprubadong sangguniang nasa labas ng assistant. Kung wala ang mga ito, utos lang na walang kakayahang isagawa ang “lumipat sa manwal na proseso.”
Piliin nang maaga ang limitadong serbisyong ito. Itakda kung sino ang maaaring magpatupad nito, aling trabaho ang ihihinto, at sinong mga tauhan ang sasalo sa natitirang gawain. Magtakda ng oras ng muling pagsusuri para hindi magpatuloy ang pansamantalang kaayusan buong hapon nang walang nagtatasa rito. Dapat ipaliwanag ng mga abiso sa customer ang pagkaantala at ang paraang magagamit para sa agarang tulong, nang walang pangakong hindi kayang tuparin ng pangkat.
Inilalarawan sa gabay pang-engineering ng Google tungkol sa sobrang karga ang pagpapanatili ng limitadong functionality, paglilimita sa trapiko at pagbibigay-priyoridad sa mahahalagang kahilingan kapag kapos ang mga mapagkukunan. Mga napatunayang teknik sa pagiging maaasahan ang mga ito, hindi paliwanag sa insidente ng Claude. Kapag iniangkop sa help desk, sinusuportahan ng mga ito ang sinasadyang pagbawas ng saklaw kapag hindi na maipagpatuloy ang normal na pagproseso. Google SRE: pagharap sa sobrang karga
Kailangan ding may limitasyon sa kapasidad ang pinasimpleng serbisyo. Hindi kayang saluhin nang palihim ng dalawang tao ang dami ng trabahong karaniwang pinoproseso ng isang awtomatikong sistema. Itala kung gaano karami ang kaya nilang asikasuhin, alin ang maghihintay at kung kailan kakailanganin ang karagdagang tulong. Mas kapaki-pakinabang sa mga customer ang makatotohanang palugit ng tugon kaysa awtomatikong kumpirmasyong nagpapahiwatig na normal ang serbisyo.

Magtala ng mga gawain sa labas ng usapan
Kailangan ng help desk ng rekord ng kaso na mababasa habang hindi available ang modelo. Maaaring ito ang dati na nitong sistema ng suporta. Ang mahalaga, matitiyak ng negosyo kung ano ang nangyari nang hindi hinihiling sa naantalang assistant na buuing muli ang pangyayari.
Sa bawat kaso, panatilihin ang orihinal na kahilingan, ang taong o prosesong responsable, at ang huling pagkilos na kumpirmadong naisagawa. Iba ang naka-save na draft sa naipadalang tugon. Iba rin ang mungkahing pagbabago sa rekord ng customer sa pagbabagong kinumpirma ng sistemang iyon. Itago ang katibayang kailangan para mapag-iba ang mga ito, alinsunod sa parehong paghihigpit sa pag-access na ipinapataw sa batayang impormasyon ng customer.
Habang may pagkaantala, hatiin ang mga gawain sa mga praktikal na kategoryang ito:
- Handa nang simulan: wala pang pagproseso o panlabas na pagkilos na nagaganap.
- Bahagyang naihanda: may pag-uuri o draft na, pero hindi pa tapos ang susunod na hakbang.
- Kumpirmadong tapos: itinatala ng patutunguhang sistema ang nilalayong pagkilos.
- Hindi tiyak: sinubukan ang isang pagkilos, pero walang kumpirmasyon.
Italaga ang mga hindi tiyak na kaso sa taong makapagsisiyasat sa kaugnay na sistema bago ipagpatuloy ang mga ito. Kung naghahanda pa lang ng tugon ang assistant nang maputol ang koneksiyon, maaaring walang masamang epekto ang paggawa ng bagong draft. Pero kung hiwalay na kasangkapan ang ginagamit sa pagpapadala, maaaring madoble ang tugon kapag inulit ang buong gawain. Dapat itala sa proseso ang pagkakaibang ito.
Ayon sa dokumentasyon ng API ng Anthropic, maaaring pumalya ang streaming na tugon kahit nauna nang nagbalik ng matagumpay na HTTP 200 status. Hindi patunay na natanggap ang buong sagot ang paglitaw ng unang teksto o pagtanggap sa paunang status. Dapat matukoy ng integrasyon kung kumpleto na ang tugon at panatilihing bahagya ang bahagyang gawa. Dokumentasyon ng error sa Claude API
Limitahan ang mga muling pagsubok at magtalaga ng responsable
Maaaring malutas ng muling pagsubok ang pansamantalang problema. Maaari rin nitong patagalin ang kawalang-katiyakan kung paulit-ulit na inuulit nang magkakahiwalay ng bawat antas ang parehong gawain. Tanungin ang tagapagtustos ng software kung may awtomatikong muling pagsubok na sa loob ng client library nito bago magdagdag ng isa pang button o awtomatikong loop.
Ayon sa dokumentasyon ng Anthropic, awtomatikong inuulit nang dalawang beses bilang default ng mga opisyal nitong SDK ang mga request kapag pansamantala ang problema. Pinahahaba nito ang pagitan sa bawat pagtatangka at sinusunod ang tagubiling retry-after kapag mayroon. Ibinubukod din ng dokumentasyon ng error nito ang pansamantalang problema sa server sa mga error sa pagpapatotoo, pahintulot at maling pagkakabuo ng request. Hindi dapat ipagpalagay na malulutas ng pag-uulit ang lahat ng uri ng error. Nakadokumentong asal ng Claude sa muling pagsubok
Para sa help desk, dapat tukuyin ng tuntunin sa operasyon kung kailan hihinto ang mga awtomatikong pagtatangka at kung sino ang tatanggap ng kaso pagkatapos. Panatilihin ang identifier ng request para sa pag-troubleshoot. Ipakita sa mga tauhan kung naghihintay, muling sinusubukan o naghihintay ng tao ang isang gawain para hindi sila makapaglunsad nang hindi nalalaman ng magkakasabay na pagtatangka.
Ipinaliliwanag ng AWS kung paanong maaaring magtagumpay ang isang pagkilos kahit hindi dumating ang tugon nito. Gumagamit ang mga idempotent na API nito ng tahasang identifier ng request para makilala ang mga pag-uulit at maiwasan ang mga karagdagang epekto. Kailangang ipatupad ng tumatanggap na serbisyo ang kontratang ito; walang gayong proteksiyon ang simpleng paglalagay ng panloob na numero ng kaso. AWS tungkol sa ligtas na muling pagsubok
Magtanong tungkol mismo sa mga pagkilos ng workflow ninyo. Makakagawa ba ng panibagong support ticket o makapagpapadala ng isa pang email ang pag-uulit ng pagtatangka? Kung walang pananggalang laban sa duplikado, kailangang suriin muna sa patutunguhang rekord bago muling sumubok. Magkaiba ang pasiyang kailangan sa muling pagbuo ng teksto at sa pag-uulit ng buong proseso ng negosyo.
Dapat mas makitid ang tungkulin ng backup na modelo
Makakatulong ang alternatibong serbisyo ng AI para maipagpatuloy ang trabaho, pero simula pa lang ang pagkakaroon ng pangalawang account. Kailangan ng pamalit ng wastong mga tagubilin, aprubadong sangguniang materyal at pahintulot na humawak sa datos. Kailangan din nito ng kapasidad kapag ginamit ito ng negosyo.
Pumili muna ng limitadong fallback na gawain bago tangkaing palitan ang buong sistema. Sa kathang-isip nating help desk, maaaring mag-uri ng mga karaniwang mensahe ang ibang modelo habang tao ang sumasagot sa mga customer. Maaaring subukan ito ng pangkat gamit ang mga kinatawang kaso, kabilang ang malalabong pangalan ng produkto at mga kahilingang kailangang ipasa sa isang tao. Hindi sapat ang matatas na sagot para patunayang sinunod nito ang mga tuntunin ng suporta ng kompanya.
Pagpasiyahan nang maaga kung anong impormasyon ang maaaring ipadala sa alternatibong serbisyo. Hindi dapat magkusa ang mga tauhan na mag-paste ng mga rekord ng customer sa mga personal na account. Suriin ang mga tuntunin nito sa paghawak ng datos at mga kaayusan sa pag-access habang kinukuha ito, kasama ng kalidad at presyo ng mga sagot.
Hindi rin garantiya ng magkahiwalay na availability ang magkaibang pangalan ng modelo. Maaaring nakasalalay pa rin ang backup sa parehong pag-login, koneksiyon sa network, imbakan ng dokumento o orchestration software. Tukuyin kung aling mga dependency ang talagang naiiwasan ng iminungkahing alternatibo. Maaaring lumabas sa pagsusuring iyon na mas mabisang pananggalang ang manwal na pila at mga dokumentong madaling maabot kaysa isa pang modelong dumaraan sa parehong pumapalya na koneksiyon.
Kailangan ding panatilihin ang mga alternatibo habang nagbabago ang mga tagubilin at naluluma ang kaalaman sa produkto. Kailangang magsanay ang mga tauhan sa mga prosesong bihira nilang gamitin. Makatuwirang piliin ng maliit na negosyo ang mas mabagal na serbisyong manwal sa halip na gumastos para doblehin ang buong operasyon. Dapat ibatay ang pasiya sa halaga ng pagkaantala at pinsalang dulot ng maling sagot.
Ipagpatuloy ang trabaho gamit ang nasuring pila
Kapag iniulat ng provider na naibalik na ang serbisyo, subukan muna ang maliit na bahagi ng sarili ninyong workflow bago buksan muli ang normal na pagproseso. Magsama ng kasong sumusubok sa paghahanap ng dokumento at pag-update ng rekord na kailangan ng negosyo. Hindi patunay ng kahandaan ng bawat konektadong sistema ang matagumpay na tugon ng modelo.
Saka suriin ang mga nakapilang gawain. Alisin ang mga kasong naasikaso na nang mano-mano, siyasatin ang mga hindi tiyak na pagkilos, at tukuyin ang mga kahilingang nagbago na ang kalagayan. Maaaring may bagong impormasyong ibinigay ang customer habang may pagkaantala. Maaaring lumikha ng panibagong problema ang pagbuo ng tugon mula sa lumang bersiyon ng kaso kahit tapos na ang teknikal na aberya.
Iproseso ang natitirang gawain sa maliliit at kontroladong batch. Maglaan ng kapasidad para sa mga bagong agarang kahilingan at subaybayan kung lumiliit ang pila. Kung nauubos ng mga bagong dating ang lahat ng magagamit na kapasidad, mananatili ang backlog kahit matagumpay ang bawat bagong pagtatangka. Maaaring kailanganin ng dagdag na tauhan, pansamantalang pagbawas ng serbisyo o tapat na pagpapahaba ng oras ng pagtugon para makahabol.
Bilang hiwalay na halimbawa sa numero, ipagpalagay na dumarating ang 24 na kaso kada oras at huminto ang pagproseso nang 30 minuto. May 12 kasong naghihintay. Kung makapagproseso ang help desk ng 36 kada oras habang patuloy na may dumarating na 24 kada oras, aabutin ito ng isang oras bago maubos ang backlog. Mga palagay lang na naglalarawan ito, hindi sukat ng insidente sa Claude.
Nagsisimula ang gabay ng Google tungkol sa mga service-level objective sa kinalabasang mahalaga sa mga user at sa mga dependency na kailangan para maihatid iyon. Para sa help desk na ito, maaaring sukatin ang bahagdan ng mga agarang kasong nabigyan ng angkop na tugon sa loob ng ipinangakong oras. Mahalaga ang availability ng provider, pero kailangan ding malaman ng negosyo kung natanggap ng mga customer ang serbisyo. Google SRE: pagpapatupad ng mga service-level objective
Itala kung kailan bumalik sa normal ang serbisyo sa customer, ilan ang kasong hindi pa nalulutas at kung anong mga pagwawasto ang kinailangan pagkatapos. Ipinakikita ng mga sukat na ito ang gawaing pang-recovery na hindi nakikita sa status page ng provider.
Magsanay sa isang pagkaantala bago palawakin ang automation
Maaaring matukoy ng maikling tabletop exercise ang kakulangan sa access o responsibilidad nang hindi naaabala ang mga aktuwal na customer. Gumamit ng ilang kathang-isip na kaso ng suporta at sundan ang ganitong pagkakasunod-sunod:
- Ipagpalagay na hindi na available ang modelo sa kalagitnaan ng paghahanda ng sagot. Itanong kung sino ang magpapatupad ng limitadong serbisyo at saan makikita ng mga tauhan ang orihinal na kahilingan.
- Itakda na kumpirmadong naipadala ang isang tugon at hindi tiyak ang pagpapadala ng isa pa. Suriin kung alam ng pangkat kung aling sistema ang makapagpapatunay sa kinalabasan.
- Ipagpalagay na naibalik na ang serbisyo ng provider habang patuloy na dumarating ang mga bagong kaso. Pagpasiyahan kung aling gawain ang unang ipagpapatuloy at paano aalisin sa backlog ang mga kasong natapos nang mano-mano.
- Magpaliwanag sa pamamaraang ito sa isang taong hindi sumulat ng plano at ipatukoy sa kanya kung anong pahintulot o rekord ang wala sa kanya.
Itala kung anong mga tanong ang hindi nasagot ng pagsasanay. Maaaring simple lang ang mga kailangang ayusin: access sa kasalukuyang pila, malinaw na kontrol sa paghinto, naka-save na kumpirmasyon o itinalagang responsable sa recovery. Walang isa man dito ang garantiya ng tuluy-tuloy na serbisyo. Pero bawat isa ay makatutulong para makontrol ang pagkaantala nang hindi isinusuko ang pakinabang ng automation.
Bago magbigay sa assistant ng panibagong tungkulin sa operasyon, hilingin sa isang kasamahan na ipakita kung paano hahawakan ang tungkuling iyon kapag may outage. Kung nakasalalay ang sagot sa pag-alala ng hindi available na assistant sa ginagawa nito, kailangan pang pagbutihin ang plano sa pagpapatuloy.



