AI-translated from English; not yet reviewed by a fluent editor.

# Claude je ponovo dostupan. Vašem preduzeću i dalje treba plan oporavka

> Incident Claude-a od 22. septembra je završen. Praktični vodič objašnjava kako preduzeća mogu da održe ograničenu uslugu, sačuvaju nezavršen posao i obrade sopstveni zaostatak nakon prekida AI usluge.

By BIG CHANGE Editorial

Published: 2026-09-22T08:51:37.833Z
Updated: 2026-09-22T08:51:37.833Z
Canonical: https://bigchange.ai/blog/claude-outage-ai-business-continuity

![An intact desktop document machine sits beside an open ledger with an orange bookmark and an orderly stack of folders.](https://bigchange.ai/api/media/file/preserved-work-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. When an AI service pauses, a business still needs accessible records of unfinished work. The bookmarked ledger represents preserving the stopping place. Conceptual illustration, not evidence of damaged equipment or lost data.

Claude je 22. septembra iskusio povećan broj grešaka na više modela. U konačnom izveštaju o incidentu Anthropic navodi da je period uticaja trajao od 00:50 do 02:10 UTC, odnosno 80 minuta. Incident je označen kao rešen u 02:35 UTC. Na spisku pogođenih komponenti bili su claude.ai, API, Code i Cowork. Izveštaj ne navodi da svaki zahtev nije uspeo, niti sadrži javno objašnjenje osnovnog uzroka. [Izveštaj Anthropic-a o incidentu](https://status.claude.com/incidents/7g1qpkyz5gxh)

Za preduzeće koje koristi AI u radnom postupku, obnova usluge rešava samo deo problema. Zahtevi korisnika i dalje mogu čekati. Neko je možda počeo ručno da obrađuje slučaj, dok je automatski pokušaj još aktivan. Nadređeni mora da zna koji posao može da se nastavi, a koji prvo treba proveriti.

Povremena nedostupnost asistenta je neprijatnost kada on služi za smišljanje ideja. Kada ista usluga pomaže u klasifikaciji pristiglih slučajeva, sastavljanju odgovora i ažuriranju zapisa, prekid postaje operativni problem. Korisna priprema je kratak plan kontinuiteta koji zaposleni mogu da prate i bez pristupa samoj AI usluzi.

Ovaj vodič koristi hipotetičku službu za korisničku podršku kako bi pokazao kako bi takav plan mogao da izgleda. Predloženi postupci namenjeni su prilagođavanju i vežbi, a ne predstavljaju test koji je sproveo BIG CHANGE niti opis korisnika pogođenih ovim incidentom.

## Izaberite uslugu koju možete održavati bez AI-ja

Zamislimo malog dobavljača opreme čiji asistent razvrstava pristigle zahteve za podršku i priprema odgovore na osnovu odobrenih podataka o proizvodima. Zaposleni pregledaju odgovore pre slanja. Iako su ljudi i dalje odgovorni za odgovore, organizacija posla u redu za podršku zavisi od tog sistema.

Ako asistent prestane da odgovara, prva odluka rukovodioca je šta služba i dalje može da obeća. Zaposleni bi mogli da nastave da potvrđuju prijem zahteva i obrađuju slučajeve sa bliskim rokovima, a da odlože rutinska objašnjenja o proizvodima. Moraju imati pristup izvornim porukama i odobrenom referentnom materijalu izvan asistenta. U suprotnom, „pređite na ručni rad” samo je uputstvo bez sredstava za njegovo sprovođenje.

Unapred izaberite taj ograničeni režim usluge. Odredite osobu koja može da ga aktivira, poslove koje treba zaustaviti i zaposlene koji će pokriti preostale zadatke. Utvrdite vreme za proveru kako privremeni aranžman ne bi ostao na snazi do popodneva bez ponovne procene. Obaveštenje za korisnike treba da objasni kašnjenje i dostupnu putanju za hitnu pomoć, bez obećanja koja tim ne može da ispuni.

Smernice Google-a za rad pod preopterećenjem opisuju pružanje ograničene funkcionalnosti, ograničavanje saobraćaja i davanje prednosti važnim zahtevima kada su resursi ograničeni. To su ustaljene tehnike pouzdanosti, a ne dijagnoza ovog incidenta sa Claude-om. Primenjene na službu podrške, podržavaju plansko smanjenje obima rada kada normalna obrada ne može da se nastavi. [Google SRE: postupanje pri preopterećenju](https://sre.google/sre-book/handling-overload/)

Ograničena usluga takođe mora imati granicu kapaciteta. Dvoje ljudi ne može neprimetno da preuzme obim posla automatizovanog sistema koji obično opslužuje mnogo više zahteva. Zabeležite koliko mogu da obrade, šta će čekati i kada će biti potrebna dodatna pomoć. Korisnici više dobijaju od realnog roka za odgovor nego od automatske potvrde koja stvara utisak da usluga radi normalno.

![Two rightward arrows connect a lowered stop lever, a folder under a magnifying glass, and a tray of work beside a raised lever.](/api/media/file/pause-review-restart-inline-v1.png)

## Vodite evidenciju posla izvan razgovora

Službi za podršku potreban je zapis o slučajevima koji može da pročita dok model nije dostupan. To može biti njen postojeći sistem podrške. Važno je da preduzeće može da utvrdi šta se dogodilo, a da od prekinutog asistenta ne traži da rekonstruiše postupak.

Za svaki slučaj sačuvajte izvorni zahtev, osobu ili postupak koji je za njega odgovoran i poslednju potvrđenu radnju. Sačuvani nacrt nije isto što i poslati odgovor. Predložena izmena zapisa o korisniku nije isto što i izmena koju je taj sistem potvrdio. Sačuvajte dokaze potrebne da biste ih razlikovali, uz ista ograničenja pristupa koja važe za osnovne podatke o korisniku.

Tokom prekida razvrstajte posao u sledeće praktične kategorije:

- Spremno za početak: obrada ni spoljna radnja još nisu započete.
- Delimično pripremljeno: klasifikacija ili nacrt postoje, ali sledeći korak nije završen.
- Potvrđeno završeno: odredišni sistem evidentira predviđenu radnju.
- Neizvesno: radnja je pokušana, ali nema potvrde.

Zadužite nekoga ko može da proveri odgovarajući sistem da ispita neizvesne slučajeve pre nastavka rada. Ako je asistent sastavljao odgovor kada je veza pukla, izrada novog nacrta možda neće predstavljati problem. Ako je odvojeni alat slao taj odgovor, ponavljanje celog zadatka moglo bi da ga pošalje dvaput. Radni postupak treba da beleži tu razliku.

Anthropic-ova API dokumentacija navodi da striming odgovor može da zakaže i nakon početnog odgovora sa HTTP statusom 200. To što se prikazao početni tekst ili je primljen početni status ne dokazuje da je stigao ceo odgovor. Zahtevajte od integracije da prepozna završetak, a delimičan rad sačuva kao delimičan. [Claude API dokumentacija o greškama](https://platform.claude.com/docs/en/api/errors)

## Ograničite broj ponovljenih pokušaja i odredite odgovornu osobu

Ponovljeni pokušaj može da otkloni privremenu grešku. Može i da produži neizvesnost ako svaki sloj zasebno ponavlja isti posao. Pre dodavanja dugmeta za ponovno slanje ili automatske petlje, pitajte dobavljača softvera da li ponovni pokušaji već postoje u biblioteci koju koristi klijent.

Anthropic za svoje zvanične SDK-je podrazumevano navodi dva automatska ponovljena pokušaja kod prolaznih grešaka, uz postepeno povećavanje čekanja i uvažavanje uputstva retry-after ako je prisutno. Dokumentacija o greškama takođe razlikuje privremene probleme servera od grešaka autentifikacije, dozvola i neispravnih zahteva. Ne može se pretpostaviti da će ponavljanje istog zahteva otkloniti svaku kategoriju grešaka. [Dokumentovano ponašanje Claude-a pri ponovnom pokušaju](https://platform.claude.com/docs/en/api/errors)

Operativno pravilo za službu podrške treba da odredi kada se automatski pokušaji zaustavljaju i ko zatim preuzima slučaj. Sačuvajte identifikator zahteva radi otklanjanja problema. Omogućite zaposlenima da vide da li posao čeka, ponavlja se ili čeka osobu kako ne bi nesvesno pokretali konkurentne pokušaje.

AWS objašnjava kako radnja može da uspe čak i kada njen odgovor ne stigne. Idempotentni API-ji koriste izričit identifikator zahteva da prepoznaju ponovljene pozive i spreče dodatne sporedne posledice. Prijemni servis mora da sprovodi taj ugovor; samo dodavanje internog broja slučaja ne pruža tu zaštitu. [AWS o bezbednim ponovljenim pokušajima](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

Pitajte konkretno za radnje u vašem postupku. Može li ponovljeni pokušaj da otvori novi zahtev za podršku ili pošalje još jednu e-poruku? Kada nije dostupna zaštita od duplikata, plan treba da zahteva proveru odredišnog zapisa pre ponavljanja. Ponovno generisanje teksta i ponavljanje čitavog poslovnog postupka zahtevaju različite odluke.

## Rezervni model treba da ima užu ulogu

Alternativna AI usluga može da pomogne da se posao nastavi, ali drugi nalog samo je početak rezervnog rešenja. Zamena zahteva odgovarajuća uputstva, odobren referentni materijal i dozvolu za obradu podataka. Takođe mora imati kapacitet kada se preduzeće osloni na nju.

Pre pokušaja potpune zamene izaberite ograničen rezervni zadatak. U našem hipotetičkom primeru drugačiji model mogao bi da razvrstava rutinske poruke, dok zaposleni obrađuju odgovore namenjene korisnicima. Tim bi mogao da ga proveri na reprezentativnim slučajevima, uključujući nejasne nazive proizvoda i zahteve koji moraju da se proslede osobi. Samo uglađen odgovor ne bi dokazao da model poštuje pravila podrške preduzeća.

Unapred odlučite koje informacije smeju da se šalju alternativnoj usluzi u slučaju incidenta. Zaposleni ne bi trebalo da improvizuju tako što će podatke o korisnicima kopirati na lične naloge. Kao deo nabavke proverite uslove obrade podataka i pristupne aranžmane alternativnog provajdera, uz kvalitet i cenu izlaza.

Različiti nazivi modela ne dokazuju ni nezavisnu dostupnost. Rezervni model i dalje može zavisiti od istog prijavljivanja, mrežne veze, skladišta dokumenata ili softvera za orkestraciju. Mapirajte zavisnosti koje bi predložena alternativa zaista uklonila. To može pokazati da red za ručnu obradu sa dostupnim referentnim dokumentima pruža korisniju zaštitu od drugog modela koji koristi istu vezu koja je otkazala.

Alternative zahtevaju održavanje kako se uputstva menjaju, a znanje o proizvodu zastareva. Zaposleni moraju da uvežbaju retko korišćene postupke. Malo preduzeće može opravdano da sačuva sporiju ručnu uslugu umesto da plaća udvostručavanje celog poslovanja. Odluku treba zasnovati na ceni odloženog rada i šteti od netačnog odgovora.

## Nastavite rad kroz red predmeta koji je pregledan

Kada provajder prijavi da je usluga obnovljena, prvo proverite mali uzorak sopstvenog radnog postupka pre nego što vratite uobičajeni obim rada. Obuhvatite slučaj koji koristi pronalaženje dokumenata i ažuriranje zapisa potrebne vašem preduzeću. Uspešan odgovor modela ne dokazuje da je svaki povezani sistem spreman.

Zatim pregledajte posao koji čeka. Uklonite slučajeve rešene ručno, proverite neizvesne radnje i izdvojite zahteve čije su se okolnosti promenile. Korisnik je možda dostavio nove informacije tokom prekida. Odgovor sastavljen na osnovu ranije verzije slučaja mogao bi da stvori novi problem nakon što se tehnička greška otkloni.

Preostali posao puštajte u kontrolisanim grupama. Sačuvajte kapacitet za nove hitne zahteve i pratite da li se red smanjuje. Ako pristigli zahtevi zauzimaju sav dostupan kapacitet za obradu, zaostatak će opstati čak i kada svaki novi pokušaj uspe. Za sustizanje može biti potrebno dodatno osoblje, privremeno smanjen obim usluge ili pošteno produženje rokova za odgovor.

U zasebnom numeričkom primeru pretpostavimo da stižu 24 slučaja na sat, a obrada stane na 30 minuta. Ostaje 12 zahteva na čekanju. Ako zatim služba obrađuje 36 slučajeva na sat, dok i dalje prima 24 nova, zaostatak će biti očišćen za jedan sat. Ovo su ilustrativne pretpostavke, a ne merenja incidenta sa Claude-om.

Google-ove smernice za ciljeve nivoa usluge počinju ishodom važnim za korisnika i zavisnostima potrebnim da bi se on postigao. Za ovu službu koristan pokazatelj mogao bi biti procenat hitnih slučajeva koji dobiju odgovarajući odgovor u obećanom roku. Dostupnost provajdera je važna, ali preduzeće mora da zna i da li su korisnici zaista dobili uslugu. [Google SRE: sprovođenje ciljeva nivoa usluge](https://sre.google/workbook/implementing-slos/)

Zabeležite kada je obnovljena normalna usluga za korisnike, koliko je nerešenih slučajeva ostalo i da li su kasnije bile potrebne ispravke. Ovi pokazatelji otkrivaju posao oporavka koji stranica sa statusom provajdera ne može da vidi.

## Uvežbajte jedan prekid pre proširenja automatizacije

Kratka simulacija za stolom može da otkrije nedostatak pristupa ili odgovornosti, a da ne ometa stvarne korisnike. Uzmite nekoliko izmišljenih slučajeva podrške i prođite kroz sledeći postupak:

1. Pretpostavite da model postane nedostupan na polovini pripreme odgovora. Pitajte ko aktivira ograničeni režim usluge i gde zaposleni pronalaze izvorni zahtev.
2. Jedan slučaj neka sadrži potvrđeno poslati odgovor, a drugi neizvestan pokušaj slanja. Proverite da li tim zna koji sistem može da potvrdi ishod.
3. Pretpostavite da se provajder oporavio dok novi slučajevi i dalje pristižu. Odlučite koji se posao nastavlja prvi i kako se ručno rešeni slučajevi uklanjaju iz zaostatka.
4. Zamolite nekoga ko nije sastavio plan da objasni postupak i utvrdi koji mu pristup ili evidencija nedostaju.

Zabeležite na koja pitanja vežba nije dala odgovor. Potrebne ispravke mogu biti male: pristup postojećem redu, jasno dugme za pauzu, sačuvana potvrda ili imenovani vlasnik oporavka. Ništa od toga ne garantuje neprekidnu uslugu. Svaka od tih mera može da olakša ograničavanje posledica prekida, a da se ne odbace koristi automatizacije.

Pre nego što asistentu poverite još jednu operativnu odgovornost, zamolite kolegu da pokaže kako bi se njome upravljalo tokom prekida. Ako odgovor zavisi od nedostupnog asistenta koji treba da zapamti šta je radio, plan kontinuiteta još zahteva doradu.

## Sources

- [Claude Status: Povećan broj grešaka na više modela](https://status.claude.com/incidents/7g1qpkyz5gxh) — Izveštaj provajdera navodi period uticaja od 80 minuta i kasnije vreme rešavanja. Javni JSON nezavisno je pročitan. Beleži povećan broj grešaka, a ne potpuni prestanak rada, i ne sadrži javno objašnjenje osnovnog uzroka.
- [Claude Platform: API greške](https://platform.claude.com/docs/en/api/errors) — Aktuelna dokumentacija obuhvata greške, podrazumevane ponovljene pokušaje SDK-ja i otkaze nakon početka striminga. Ti mehanizmi ne potvrđuju da je poslovni zadatak završen niti sprečavaju duplirane radnje u povezanim alatima.
- [AWS Builders' Library: Bezbedni ponovljeni pokušaji uz idempotentne API-je](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) — Objašnjenje Malcolma Featonbyja o neizvesnim odgovorima i sprečavanju duplikata. Prijemni servis mora da primenjuje API ugovor; sam identifikator nije dovoljan.
- [Google SRE: Postupanje pri preopterećenju](https://sre.google/sre-book/handling-overload/) — Ustaljene inženjerske smernice za ograničenu funkcionalnost, prioritete i ograničene ponovljene pokušaje. Članak prilagođava te principe hipotetičkoj službi podrške; one ne utvrđuju uzrok incidenta kompanije Anthropic.
- [Google SRE Workbook: Sprovođenje ciljeva nivoa usluge](https://sre.google/workbook/implementing-slos/) — Objašnjava ciljeve pouzdanosti zasnovane na ishodima korisnika i ključnim zavisnostima. Predloženi pokazatelj korisničke podrške i primer zaostatka služe kao ilustracija, a ne predstavljaju izmerene rezultate ni univerzalni cilj.