Prekidi rada Salesforcea u 2025. nisu slijedili jedan jednostavan obrazac. Neki incidenti bili su ograničeni na određene instance ili proizvode, dok su drugi prelazili više oblaka ili ovisili o infrastrukturi treće strane. Za operativne, IT, CRM, trgovinske i marketinške timove, korisna retrospektiva nije popis svake objave o povjerenju objavljene te godine. To je pregled poremećaja koji otkrivaju ponavljajuće načine kvara: ovisnosti o autentifikaciji, infrastrukturu podatkovnog centra, oporavak baze podataka, mreže za isporuku sadržaja, DNS pružatelja usluga u oblaku i promjene koje je potrebno vratiti.
Ova referenca usredotočuje se na odabrani skup značajnih incidenata iz 2025. koje je dokumentirao Salesforce Trust. „Veliki“ ovdje znači operativno značajan zbog trajanja, opsega ili vrste pogođenog tijeka rada korisnika; to ne znači da je svaki korisnik bio pogođen i ne radi se o potpunom popisu incidenata. Točan utjecaj ovisio je o proizvodu, instanci, regiji i zakupniku.
| Datum | Što je Salesforce izvijestio | Prijavljeno trajanje ili prozor oporavka | Zašto je to operativno važno |
|---|---|---|---|
| 7. veljače | Prekid usluge za podskupinu korisnika, pri čemu Salesforce navodi ograničenja resursa povezana s visokim korištenjem mrežnog prometa. | 2 sata i 20 minuta | Pritisak kapaciteta i prometa može pretvoriti degradaciju performansi u potpunu nedostupnost. |
| 13. – 14. veljače | Prekid usluge povezan s problemom treće strane; Salesforce je izjavio da je dobavljač pronašao oštećenje fizičke mrežne infrastrukture dok je Salesforce radio na prebacivanju u slučaju kvara. | 1 sat i 45 minuta | Vanjska povezivost može postati dio efektivne granice dostupnosti Salesforcea. |
| 10. – 11. lipnja | Događaj u više oblaka utjecao je na autentifikaciju i usluge u različitim proizvodima, uključujući Heroku, Commerce, Marketing Cloud i druge Salesforce usluge. | Jedan incident s Trustom trajao je 22 sata i 43 minute | Identitet i ovisnosti dijeljene platforme mogu stvoriti širok utjecaj na poslovanje čak i kada pojedinačne aplikacije ostanu ispravne. |
| 18. – 19. lipnja | Kvar sustava hlađenja u podatkovnom centru u Indianapolisu izazvao je prekid mreže; Salesforce je izvijestio da je većina poslužitelja u teže pogođenim skupinama podataka isključena iz mreže prije postupne obnove. | Faza prekida usluge prijavljena kao 18 sati i 44 minute zbog navedenog incidenta | Fizički objekti, napajanje, umrežavanje, virtualna infrastruktura, baze podataka i oporavak aplikacija mogu formirati dugi lanac ovisnosti. |
| 2. – 6. listopada | Korisnici Marketing Clouda na bazi podataka DB10016 izgubili su uslugu jer baza podataka nije bila dostupna; Salesforce je proveo vraćanje i validaciju baze podataka. | Faza prekida usluge prijavljena je kao 3 dana i 16 sati prije prelaska na smanjenje performansi | Oporavak baze podataka može biti puno sporiji od ponovnog pokretanja aplikacije, stoga planovi kontinuiteta trebaju dugotrajan način rada. |
| 20. listopada | Više Salesforce oblaka pogođeno je DNS problemom kod treće strane dobavljača cloud infrastrukture. Commerce Cloud, MuleSoft, Marketing Cloud Account Engagement, Heroku i druge usluge prijavile su povezani utjecaj. | Razlikuje se ovisno o usluzi; navedeni poremećaj u trgovini trajao je 3 sata i 19 minuta, dok je incident MuleSofta ostao otvoren 16 sati i 23 minute. | Ovisnost na razini jednog pružatelja usluga može stvoriti različite simptome i vremena oporavka među proizvodima. |
| 18. studenog | Podskup trgovina Commerce Clouda povremeno je imao HTTP 500 pogreške. Salesforce je izjavio da njihova platforma i mreža rade normalno te je prekid pripisao ažuriranju konfiguracije CDN davatelja treće strane koje je vraćeno unatrag. | 4 sata i 40 minuta | Dostupnost usmjerena prema korisnicima može zakazati na rubu isporuke čak i kada je osnovna aplikacijska platforma ispravna. |
Izvorni zapisi: incident Salesforce Trust 13702 , incident Salesforce Trust 13729 , incident Salesforce Trust 10014307 , incident Salesforce Trust 10014353 , incident Salesforce Trust 20003296 , incident Salesforce Trust Commerce Cloud 20003368 , incident Salesforce Trust MuleSoft 20003364 i incident Salesforce Trust Commerce Cloud 20003465 .
Salesforce Trust izvještava o incidentima po proizvodu, instanci, usluzi, a ponekad i po bazi podataka ili regionalnoj komponenti. Prekid rada 7. veljače utjecao je na podskup korisnika. Incident u Marketing Cloudu 2. listopada usredotočio se na jednu bazu podataka. Događaj 20. listopada obuhvatio je više oblaka, ali je proizveo različita vremena oporavka i simptome. Za odgovorne osobe prvo korisno pitanje stoga nije samo je li Salesforce u kvaru, već koji zakupnik, proizvod, regija, instanca i ovisnost ne radi.
Salesforce pruža način pronalaženja statusa organizacije pomoću njezinog naziva Moje domene. Službeni članak podrške objašnjava kako koristiti stranicu Status povjerenja za pronalaženje statusa i informacija o održavanju specifičnih za instancu: Pomoć za Salesforce: preuzmite status organizacije i datume održavanja pomoću Moje domene .
Nekoliko incidenata iz 2025. pokazuje zašto planiranje kontinuiteta SaaS-a ne može stati na granici dobavljača SaaS-a. Incident od 13. do 14. veljače uključivao je dobavljača mreže treće strane. Prekid rada više oblaka 20. listopada bio je povezan s problemom DNS-a kod dobavljača infrastrukture u oblaku treće strane. Dana 18. studenog, Salesforce je izvijestio o problemima s povezivošću trgovine Commerce Clouda povezanim s ažuriranjem konfiguracije dobavljača CDN-a treće strane.
Pouka nije da su treće strane inherentno nepouzdane. Pouka je da tijekovi rada korisnika ovise o lancu usluga: identitet, DNS, umrežavanje, isporuka sadržaja, infrastruktura u oblaku, API-ji i aplikacijske usluge. Vaš model incidenta trebao bi slijediti taj lanac.
Događaj u podatkovnom centru od 18. do 19. lipnja snažan je primjer. Salesforce je opisao vraćanje fizičkih i virtualnih resursa, zatim pokretanje baza podataka i replika, validaciju parametara podataka i oporavak ovisnih usluga. Poremećaj baze podataka Marketing Clouda u listopadu također je prošao kroz vraćanje, provjere konfiguracije, validaciju, a zatim kasniju fazu degradacije performansi.
Ta je razlika važna za poslovne timove. „Platforma se oporavlja“ ne znači nužno da je svaki red čekanja ispražnjen, svaka integracija ponovljena, svaka trgovina stabilna ili svaki planirani zadatak uspješno izvršen.
Koristan pregled povjerenja ima tri koraka. Prvo, pročitajte pogođene usluge i instance. Drugo, usporedite objavljeno vrijeme početka s vašom telemetrijom; Salesforce ponekad revidira vremena početka incidenata kako se istrage poboljšavaju. Treće, razlikovajte prekid usluge od pogoršanja performansi ili prekida značajki. Te oznake opisuju različita operativna stanja, a incident na razini značajke može ostaviti većinu platforme upotrebljivom.
Nemojte pretpostavljati da je trajanje incidenta jednako razdoblju tijekom kojeg je svaki pogođeni kupac iskusio identične simptome. Ažuriranja Salesforcea često opisuju širenje ili smanjenje radijusa utjecaja, postupni oporavak ili obnovu specifičnu za proizvod. Za interno izvještavanje zabilježite i službeni vremenski okvir dobavljača i vlastiti uočeni prozor utjecaja.
Najjača lekcija o otpornosti iz 2025. jest da plan prekida rada treba imati način rada dulji od 30 minuta. Kratki prekid može zahtijevati samo komunikaciju i strpljenje. Višesatni događaj zahtijeva rad u redu čekanja i kontrolirane ručne procese. Prekid rada koji traje više dana, poput spomenutog incidenta s bazom podataka Marketing Clouda, zahtijeva primopredaju osoblja, upravljanje zaostatcima, komunikaciju s klijentima i plan oporavka za odgođene kampanje, uvoze, izvoze, API operacije i izvještavanje.
Definirajte prioritete oporavka prije prekida rada. Za prodajnu organizaciju, prikupljanje potencijalnih klijenata i obveze prema kupcima mogu doći prije osvježavanja analitike. Za trgovca na malo, bilježenje narudžbi, točnost zaliha i vidljivost korisničke službe mogu biti kritični put. Za marketinški tim, prioritet može biti sprječavanje dvostrukih slanja i očuvanje stanja kampanje, umjesto pokušaja forsiranja svake planirane aktivnosti kroz nestabilan sustav.
Koristite retrospektivu za testiranje pretpostavki, a ne za predviđanje sljedećeg kvara. Incidenti iz 2025. pokazuju da početni problem može nastati zbog pritiska prometa, umrežavanja dobavljača, fizičkog hlađenja, baza podataka, DNS-a, konfiguracije CDN-a ili promjena softvera. Nijedno jedinstveno rješenje ne pokriva sve to.
Zreli plan kontinuiteta Salesforcea stoga bi trebao mapirati poslovne procese na tehničke ovisnosti, dodijeliti vlasnike zamjenskih postupaka, definirati sigurno ponašanje ponovnog pokušaja, održavati praćenje povjerenja Salesforcea blizu tijeka rada incidenta i uključivati formalnu fazu usklađivanja nakon oporavka usluge. Najkorisnija metrika nije jednostavno „vrijeme dok Salesforce ne postane zelen“. To je vrijeme dok se poslovni proces ne provjeri od početka do kraja i dok se zaostatak ne sigurno riješi.
Ova retrospektiva pripremljena je na temelju vlastitih zapisa o povjerenju i pomoći tvrtke Salesforce i fokusira se na odabrane incidente iz kalendarske 2025. godine. Salesforce je tijekom godine objavio mnoge druge obavijesti o incidentima, uključujući kraće i uže definirane događaje. Neke stranice o povjerenju ažurirane su nakon početnog događaja kako su razjašnjeni vremenski okviri utjecaja i pogođene komponente. Za trenutno stanje usluge koristite Salesforce Trust Status umjesto da se oslanjate na povijesni članak.
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.
