Kratak odgovor: rašireni prekidi rada cloud platforme obično proizlaze iz lanca kvarova, a ne iz jednog izoliranog pokvarenog poslužitelja. Rizična konfiguracija ili promjena softvera može utjecati na zajedničku ovisnost kao što su identitet, DNS, autorizacija ili API kontrolne ravnine. Prvi kvar zatim pokreće ponovne pokušaje, promjene prometa ili automatsko skaliranje, što povećava opterećenje i širi utjecaj na regije ili proizvode. Slaba uočljivost i netestirani put oporavka mogu uzrokovati dulje trajanje prekida.
Taj je obrazac važan jer mijenja ono za što biste se trebali pripremiti. „Oblak“ nije jedno računalo, a „pružatelj usluga ne radi“ nije potpuna dijagnoza. Vaša aplikacija može ovisiti o nekoliko usluga pružatelja usluga, vašoj vlastitoj konfiguraciji, vanjskim API-jima i procesu oporavka koji funkcionira samo ako je testiran. Ovaj vodič objašnjava glavne uzroke, što početnik treba prvo provjeriti i pogreške koje otežavaju upravljanje velikim prekidom rada.
Dostupnost se odnosi na to može li usluga uspješno odgovoriti na zahtjev. Pad performansi znači da odgovara, ali presporo ili s povećanom stopom pogrešaka. Opsežni incident može utjecati na podatkovnu ravninu - sustave koji opslužuju promet aplikacije - ili kontrolnu ravninu - API-je i interne sustave koji se koriste za stvaranje, konfiguriranje, autentifikaciju i upravljanje resursima. Prekid rada kontrolne ravnine može spriječiti implementacije ili skaliranje čak i dok već pokrenuta opterećenja nastavljaju opsluživati određeni promet.
Dijeljena ovisnost je usluga na koju se oslanjaju mnogi proizvodi ili putovi zahtjeva. DNS, upravljanje identitetom i pristupom, validacija certifikata, usmjeravanje, metapodaci, kvote i uočljivost uobičajeni su primjeri. Ako je ta ovisnost centralizirana ili ima zajednički način kvara, mali kvar može imati puno veći radijus eksplozije - skup korisnika, regija ili usluga pogođenih jednim kvarom.
Promjene su vodeći izvor velikih incidenata jer mogu biti ispravne u jednom kontekstu, a nesigurne na razini platforme. Uređivanje dozvola, pravilo usmjeravanja, zastavica značajke, promjena sheme ili automatizirana akcija kapaciteta mogu utjecati na svaku regiju ili svaki stroj okrenut prema korisnicima. Automatizacija može pojačati rezultat prije nego što ga čovjek vidi.
Službena analiza Cloudflarea za 18. studenog 2025. ilustrira ovu vrstu kvara. Promjena dozvola baze podataka uzrokovala je dupliciranje redaka u datoteci značajke Bot Management. Datoteka je postala otprilike dvostruko veća, proširila se na računala diljem svijeta i premašila ograničenje u softveru za usmjeravanje. Cloudflare kaže da incident nije uzrokovan kibernetičkim napadom; kvar je nastao zbog interakcije konfiguracije i softvera. Tvrtka je zaustavila širenje i implementirala poznato ispravnu datoteku. Pročitajte detaljnu analizu prekida rada Cloudflarea od 18. studenog 2025. za detaljan izvještaj pružatelja usluga.
Temeljne usluge često se nalaze ispod mnogih naizgled nepovezanih proizvoda. Identitet, autorizacija, interni DNS, nadzor, metapodaci i API-ji koji se koriste za pružanje resursa mogu postati uobičajena točka kvara. Simptomi s kojima se suočavaju korisnici mogu izgledati drugačije - neuspješne prijave, pogreške u implementaciji, isteci vremena ili nedostajući pokazatelji - ali temeljna ovisnost može biti ista.
U svom sažetku nakon događaja US-EAST-1 od 7. prosinca 2021., AWS je opisao neočekivanu interakciju koja je uključivala automatiziranu aktivnost skaliranja i interne mrežne uređaje. AWS je rekao da je pogođena mreža hostirala temeljne usluge, uključujući nadzor, interni DNS, usluge autorizacije i dijelove kontrolne ravnine EC2. Pokušaji povezivanja i ponovni pokušaji zatim su doprinijeli zagušenju. AWS je također izvijestio da su pogođeni njegov kontaktni centar za podršku i dijelovi komunikacijskog puta o ispravnosti usluge. Sažetak nakon događaja AWS-a koristan je primjer zašto pružatelj usluga može imati poteškoća s istovremenim vraćanjem usluga i njihovom dijagnosticiranjem.
Kada zahtjev ne uspije, klijenti često pokušavaju ponovno. Oluja ponovnih pokušaja nastaje kada mnogi klijenti pokušavaju ponovno odjednom, posebno bez eksponencijalnog odustajanja - strategije koja povećava čekanje između pokušaja - i podrhtavanja, koje dodaje malo nasumično kašnjenje. Ti ponovni pokušaji troše isti oskudni kapacitet i mogu djelomični kvar pretvoriti u širi prekid.
Drugi multiplikatori opterećenja uključuju prečeste provjere ispravnosti, automatsko prebacivanje u slučaju kvara koje šalje promet u već zauzetu regiju, redove čekanja koji odjednom oslobađaju cijeli zaostatak i politike automatskog skaliranja koje reagiraju na simptome, a ne na uzrok. Usluga stoga može propasti iako njezini poslužitelji nisu fizički oštećeni. Važno pitanje nije samo "Može li pružatelj usluga dodati kapacitet?" već i "Dodaju li naši klijenti i automatizacija više posla na put neuspjeha?"
Platforme u oblaku i dalje ovise o fizičkim podatkovnim centrima, energetskim sustavima, hlađenju, optičkim vezama, usmjerivačima, uređajima za pohranu i regionalnim mrežnim putovima. Redundancija smanjuje rizik, ali ne čini svaki kvar nevidljivim. Zajednički objekt, zona dostupnosti, međuregionalna veza ili granica usmjeravanja mogu utjecati na mnoge usluge odjednom.
Regionalni oporavak također može biti neravnomjeran. U svom zapisu o incidentima od 12. lipnja 2025., Google Cloud je izvijestio da je više proizvoda imalo problema s API-jem povezanih s temeljnom ovisnošću, pri čemu se oporavak razlikovao ovisno o lokaciji; u zapisu je posebno navedeno da je sporiji oporavak u središnjem dijelu SAD-a1 te u uslugama u SAD-u i više regija. Zapis o incidentu Google Cloud Service Health pokazuje zašto provjera jedne regije ili jednog proizvoda nije dovoljna za razumijevanje punog opsega.
Platforma može biti ispravna sve dok ne primi neočekivani ulaz: datoteku koja je veća od ograničenja parsera, duplicirani zapis, neobičan API odgovor ili migraciju podataka koja otkriva pretpostavku u starijem kodu. Ovi kvarovi su posebno opasni kada se isto izdanje ili konfiguracija distribuira globalno.
Tvrda ograničenja nisu uvijek očita iz normalnog testiranja. Konfiguracijska datoteka može biti valjana, ali prevelika za nizvodnu komponentu. Stopa zahtjeva može biti prihvatljiva u jednoj regiji, ali premašiti kvotu nakon prebacivanja u slučaju kvara. Posao oporavka može biti siguran jednom, ali stvoriti duplicirani rad kada se ponavlja. Testiranje treba obuhvatiti loše podatke, djelomični kvar ovisnosti, regionalnu evakuaciju i ponovljeno izvršavanje - ne samo sretan put.
Distribuirani napadi uskraćivanjem usluge, ukradeni vjerodajnice, zloupotreba i zlonamjerne promjene konfiguracije mogu uzrokovati prekide u radu. No, skok prometa ili neuspjeh u autentifikaciji nisu dokaz napada. Tretiranje svakog incidenta kao sigurnosnog događaja može poslati odgovor u pogrešnom smjeru i odgoditi vraćanje konfiguracije.
Koristite dokaze: usporedite obrasce zahtjeva, zapise o autentifikaciji, zapise o promjenama, ažuriranja statusa pružatelja usluga i neovisne sonde. Održavajte sigurnosnu eskalaciju dostupnom, ali odvojite „ono što znamo“ od „ono što sumnjamo“. Cloudflareova analiza iz 2025. konkretan je podsjetnik da prekid rada u početku može izgledati kao napad, a ipak imati drugačiji uzrok.
Prekid rada postaje teže obuzdati kada sustav za nadzor ovisi o istom putu kvara kao i aplikacija. Nadzorna ploča može pokazati da virtualni stroj radi dok korisnici ne mogu dovršiti transakciju. Smjernice Google Clouda o SLO-ima usmjerenima na korisnike i prilagođenim metrikama objašnjavaju ovu razliku: vrijeme rada infrastrukture nije isto što i uspješna radnja korisnika.
Koristite barem jednu neovisnu sintetičku provjeru - planirani test koji izvodi sigurnu transakciju sličnu onoj za korisnike - izvan pogođenog okruženja. Zadržite drugi način za pristup ažuriranjima incidenata i zabilježite stranice statusa pružatelja usluga, interna upozorenja i izvješća korisnika u jednoj vremenskoj crti. Nemojte pretpostavljati da je stranica statusa nepogrešiva: Cloudflare je izvijestio da i njegova vlastita stranica statusa nije bila dostupna tijekom incidenta u studenom 2025., iako je bila smještena izvan Cloudflareove infrastrukture.
Započnite s jednostavnom mapom ovisnosti. Uključite DNS, identitet, tajne, certifikate, redove čekanja, baze podataka, pohranu objekata, API-je trećih strana, isporuku sadržaja, praćenje i regiju pružatelja usluga. Označite koje su komponente potrebne za svaki zahtjev, a koje se mogu degradirati ili zaobići. Ova vježba često otkriva da dvije „neovisne“ regije i dalje dijele identitet, DNS, alate za implementaciju ili jednog vanjskog dobavljača.
Definirajte svoj RTO (ciljno vrijeme oporavka, ciljano vrijeme za vraćanje usluge) i RPO (ciljna točka oporavka, prihvatljiva količina gubitka podataka mjerena u vremenu). Zatim odaberite kontrole koje odgovaraju poslovnim potrebama. Mala interna nadzorna ploča može prihvatiti ručni oporavak. Tijek rada plaćanja ili hitnih slučajeva može zahtijevati uslugu za više regija, testiranu replikaciju podataka i dokumentiranog vlasnika za prebacivanje u slučaju kvara.
| Rani trag | Vjerojatni uzrok | Priprema ili kontrola |
|---|---|---|
| Greške počinju odmah nakon implementacije ili promjene pravila | Promjena konfiguracije ili softvera | Canary izdanja, odobrenja, kontrola verzija i brzo vraćanje na prethodno stanje |
| Nekoliko proizvoda ne uspijeva provjeriti autentičnost ili razriješiti imena | Dijeljeni identitet, autorizacija ili ovisnost o DNS-u | Mapiranje ovisnosti i neovisni put pristupa |
| Latencija raste s povećanjem broja ponovnih pokušaja | Preopterećenje ili oluja ponovnog pokušaja | Povratak, podrhtavanje, prekidači i rasterećenje |
| Jedna regija se oporavlja, dok druga ostaje oslabljena | Regionalna razlika u kapacitetu ili ovisnosti | Testirano prebacivanje u slučaju kvara za više regija i regionalni runbookovi |
| Infrastruktura izgleda zdravo, ali transakcije ne uspijevaju | Jaz uočljivosti ili nizvodna ovisnost | SLO-ovi na razini korisnika i provjere sintetičkih transakcija |
Glavni uzroci raširenih prekida rada u oblaku su međudjelujući sustavi: nesigurne promjene, dijeljene ovisnosti, preopterećenje i ponovni pokušaji, kvarovi regionalne infrastrukture, nedostaci u softveru i obliku podataka, sigurnosni ili prometni događaji te slijepe točke u detekciji. Ne možete eliminirati svaki prekid rada pružatelja usluga, ali možete ograničiti njegov radijus. Mapirajte ovisnosti, mjerite rezultate korisnika, učinite ponovne pokušaje pristojnima, održavajte promjene reverzibilnima, testirajte prebacivanje u slučaju kvara i održavajte zapis o incidentima koji razlikuje činjenice od hipoteza.
Napomena o izvoru: Ovaj je članak provjeren 16. rujna 2026. Incidenti s pružateljima usluga dokumentirani su primjeri, a ne iscrpan popis, a naknadne analize pružatelja usluga možda neće otkriti svaki interni detalj. Nazivi proizvoda, arhitekture, stranice statusa i ponašanje oporavka mogu se s vremenom mijenjati.
Pregledajte značajne prekide rada Salesforcea u 2025. godini, što je zakazalo, koliko su dugo trajali odabrani incidenti i praktične lekcije o otpornosti koje timovi mogu primijeniti.
Izradite praktičan plan za kontinuitet zastoja u Salesforceu s analizom utjecaja, ciljevima RTO/RPO, ručnim rješenjima, kontrolama integracije i provjerama oporavka.
Naučite kako kontaktirati Salesforce podršku tijekom većeg prekida: provjerite status povjerenja, odaberite pravi kanal, otvorite snažan slučaj i pratite oporavak.
Rješavanje problema s prijavom u Salesforce Workbench, REST Explorerom, timeoutom, 503, verzijom API-ja i ograničavanje pogrešaka tijekom zastoja pomoću praktičnog dijagnostičkog popisa za provjeru.
Problemi sa StoreForceom mogu poremetiti raspoređivanje, evidenciju vremena i tijekove rada zaposlenika. Naučite kako procijeniti utjecaj, održati trgovine u funkciji, provjeriti oporavak i znati kada eskalirati problem.
Razumjeti glavne uzroke raširenih prekida rada u oblaku, kako se kvarovi kaskadno prenose, što prvo provjeriti i kako osmisliti otporniji plan oporavka.
If Datorama or Marketing Cloud Intelligence seems down, use this evidence-based checklist to verify the outage, protect reporting quality, and know when data is trustworthy again.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
Prekid rada AWS-a ne znači automatski da je Salesforce u kvaru. Saznajte kako Hyperforce, regije, instance i Salesforce Trust određuju je li vaša organizacija pogođena.
