Výpadky Salesforce v roce 2025 se neřídily jedním jednoduchým vzorcem. Některé incidenty se omezovaly na konkrétní instance nebo produkty, zatímco jiné se týkaly více cloudů nebo závisely na infrastruktuře třetích stran. Pro provozní, IT, CRM, obchodní a marketingové týmy není užitečnou retrospektivou seznam všech příspěvků o důvěře publikovaných v daném roce. Jde o přehled narušení, která odhalují opakující se režimy selhání: závislosti na ověřování, infrastruktura datových center, obnova databází, sítě pro doručování obsahu, DNS poskytovatelů cloudu a změny, které je třeba vrátit zpět.
Tato reference se zaměřuje na vybranou sadu významných incidentů z roku 2025 zdokumentovaných organizací Salesforce Trust. „Závažný“ zde znamená provozně významný incident z důvodu trvání, rozsahu nebo typu ovlivněného pracovního postupu zákazníka; neznamená to, že byl ovlivněn každý zákazník, a nejedná se o kompletní soupis incidentů. Přesný dopad závisel na produktu, instanci, regionu a klientovi.
| Datum | Co uvedla společnost Salesforce | Uváděná doba trvání nebo okno zotavení | Proč je to provozně důležité |
|---|---|---|---|
| 7. února | Přerušení služeb pro podskupinu zákazníků, přičemž Salesforce uvádí omezení zdrojů spojená s vysokým využitím síťového provozu. | 2 hodiny 20 minut | Kapacita a tlak provozu mohou zhoršit výkon a způsobit naprostou nedostupnost. |
| 13.–14. února | Přerušení služby spojené s problémem u dodavatele třetí strany; Společnost Salesforce uvedla, že dodavatel zjistil poškození fyzické síťové infrastruktury, zatímco Salesforce pracoval na failoveru. | 1 hodina 45 minut | Externí konektivita se může stát součástí efektivní hranice dostupnosti Salesforce. |
| 10.–11. června | Událost napříč více cloudy ovlivnila ověřování a služby napříč produkty, včetně Heroku, Commerce, Marketing Cloud a dalších služeb Salesforce. | Jeden incident Trustu trval 22 hodin a 43 minut | Závislosti identity a sdílené platformy mohou mít široký dopad na podnikání, i když jednotlivé aplikace zůstávají v pořádku. |
| 18.–19. června | Selhání chladicího systému v datovém centru v Indianapolisu způsobilo narušení sítě; společnost Salesforce uvedla, že většina serverů ve více postižených řadách byla odpojena od sítě ještě před zahájením postupné obnovy. | Fáze přerušení provozu hlášená jako 18 hodin a 44 minut v souvislosti s citovaným incidentem | Fyzická zařízení, napájení, sítě, virtuální infrastruktura, databáze a obnova aplikací mohou tvořit dlouhý řetězec závislostí. |
| 2.–6. října | Zákazníci služby Marketing Cloud s databází DB10016 ztratili přístup k internetu, protože databáze nebyla k dispozici; Salesforce provedla obnovení a ověření databáze. | Fáze přerušení služby hlášena jako 3 dny a 16 hodin před přechodem ke zhoršení výkonu | Obnova databáze může být mnohem pomalejší než restart aplikace, takže plány kontinuity potřebují dlouhodobý režim. |
| 20. října | Několik cloudů Salesforce bylo ovlivněno problémem s DNS u externího dodavatele cloudové infrastruktury. Související dopad hlásily služby Commerce Cloud, MuleSoft, Marketing Cloud Account Engagement, Heroku a další. | Liší se podle služby; uváděné narušení obchodu trvalo 3 hodiny 19 minut, zatímco incident MuleSoft zůstal otevřený 16 hodin 23 minut. | Závislost na úrovni jednoho poskytovatele může u různých produktů vytvářet různé příznaky a doby obnovy. |
| 18. listopadu | Podmnožina obchodů Commerce Cloud občas hlásila chyby HTTP 500. Společnost Salesforce uvedla, že její platforma a síť fungují normálně, a narušení připsala aktualizaci konfigurace poskytovatele CDN třetí strany, která byla vrácena zpět. | 4 hodiny a 40 minut | Dostupnost pro zákazníky může selhat na hranici doručování, i když je základní aplikační platforma v pořádku. |
Zdrojové záznamy: 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 a incident Salesforce Trust Commerce Cloud 20003465 .
Společnost Salesforce Trust hlásí incidenty podle produktu, instance, služby a někdy i podle databáze či regionální komponenty. Narušení provozu 7. února ovlivnilo podmnožinu zákazníků. Incident Marketing Cloud z 2. října se soustředil na jednu databázi. Událost z 20. října se týkala více cloudů, ale měla různé doby obnovy a příznaky. Pro respondenty proto první užitečnou otázkou není jen to, zda je Salesforce mimo provoz, ale který klient, produkt, region, instance a závislost selhává.
Salesforce nabízí způsob, jak zjistit stav organizace pomocí jejího názvu v sekci Moje doména. Oficiální článek podpory vysvětluje, jak pomocí stránky Stav důvěryhodnosti vyhledat stav a informace o údržbě specifické pro danou instanci: Nápověda Salesforce: získejte stav organizace a data údržby pomocí stránky Moje doména .
Několik incidentů z roku 2025 ukazuje, proč plánování kontinuity SaaS nemůže zastavit na hranici dodavatele SaaS. Incident z 13. a 14. února se týkal síťového dodavatele třetí strany. Narušení provozu více cloudů z 20. října souviselo s problémem DNS u dodavatele cloudové infrastruktury třetí strany. Dne 18. listopadu společnost Salesforce oznámila problémy s připojením k obchodu Commerce Cloud související s aktualizací konfigurace poskytovatele CDN třetí strany.
Poučení nespočívá v tom, že třetí strany jsou ze své podstaty nespolehlivé. Jde o to, že pracovní postupy zákazníků závisí na řetězci služeb: identita, DNS, sítě, doručování obsahu, cloudová infrastruktura, API a aplikační služby. Váš model incidentů by měl tento řetězec sledovat.
Událost v datovém centru z 18. a 19. června je toho silným příkladem. Společnost Salesforce popsala obnovu fyzických a virtuálních zdrojů, následné zprovoznění databází a replik, ověření parametrů dat a obnovu závislých služeb. Říjnové narušení databáze Marketing Cloud rovněž prošlo obnovou, kontrolami konfigurace, ověřením a následnou fází snížení výkonu.
Toto rozlišení je pro obchodní týmy důležité. „Platforma se zotavuje“ nutně neznamená, že každá fronta je vyprázdněna, každá integrace byla přehrána, každý obchod je stabilní nebo každá naplánovaná úloha byla úspěšně spuštěna.
Užitečná kontrola důvěryhodnosti má tři fáze. Zaprvé, přečtěte si dotčené služby a instance. Zadruhé, porovnejte publikovaný čas zahájení s vaší telemetrií; Salesforce někdy upravuje časy zahájení incidentů s tím, jak se vyšetřování zlepšuje. Zatřetí, rozlište narušení služby od zhoršení výkonu nebo narušení funkcí. Tyto popisky popisují různé provozní stavy a incident na úrovni funkcí může způsobit, že většina platformy bude použitelná.
Nepředpokládejte, že doba trvání incidentu se rovná době, během níž každý postižený zákazník pociťoval stejné příznaky. Aktualizace Salesforce často popisují rozšiřování nebo zmenšování dosahu, postupné zotavení nebo zotavení specifické pro daný produkt. Pro interní reporting zaznamenejte jak oficiální časový harmonogram dodavatele, tak i vaše vlastní pozorované okno dopadu.
Nejdůležitějším ponaučením z roku 2025 v oblasti odolnosti je, že plán výpadku by měl mít více než 30minutový režim. Krátkodobé narušení může vyžadovat pouze komunikaci a trpělivost. Několikahodinová událost vyžaduje práci ve frontě a kontrolované manuální procesy. Narušení trvající několik dní, jako například zmíněný incident v databázi Marketing Cloud, vyžaduje předávání personálu, správu nevyřízených záležitostí, komunikaci se zákazníky a plán obnovy pro odložené kampaně, importy, exporty, operace API a reporting.
Definujte priority obnovy před výpadkem. Pro prodejní organizaci může být příjem potenciálních zákazníků a závazky vůči nim před aktualizací analytických dat. Pro maloobchodníka může být kritickou cestou zachycení objednávek, přesnost zásob a přehled o zákaznickém servisu. Pro marketingový tým může být prioritou zabránění duplicitnímu odesílání a zachování stavu kampaně, spíše než snaha vynutit každou naplánovanou aktivitu prostřednictvím nestabilního systému.
Retrospektivu použijte k otestování předpokladů, nikoli k předpovídání dalšího selhání. Incidenty z roku 2025 ukazují, že počáteční problém může pramenit z tlaku na provoz, sítí dodavatelů, fyzického chlazení, databází, DNS, konfigurace CDN nebo změn softwaru. Žádné jednotné řešení nepokrývá všechny tyto faktory.
Propracovaný plán kontinuity Salesforce by proto měl mapovat obchodní procesy na technické závislosti, přiřadit vlastníky záložních procesů, definovat bezpečné chování při opakovaném pokusu, udržovat monitorování důvěryhodnosti Salesforce v blízkosti pracovního postupu incidentů a zahrnovat formální fázi odsouhlasení po obnovení služby. Nejužitečnější metrikou není jen „doba do ověření stavu Salesforce“. Je to doba do úplného ověření obchodního procesu a bezpečného vyřešení nevyřízených záležitostí.
Tato retrospektiva byla připravena na základě vlastních záznamů o důvěryhodnosti a pomoci společnosti Salesforce a zaměřuje se na vybrané incidenty z kalendářního roku 2025. Společnost Salesforce v průběhu roku zveřejnila mnoho dalších oznámení o incidentech, včetně kratších a užšího rozsahu událostí. Některé stránky důvěryhodnosti byly aktualizovány po první události, protože byla vyjasněna okna dopadu a dotčené komponenty. Pro aktuální stav služby použijte stav důvěryhodnosti Salesforce , nikoli se spoléhejte na historický článek.
Projděte si významné výpadky Salesforce v roce 2025, co selhalo, jak dlouho trvaly vybrané incidenty a praktické ponaučení z odolnosti, které mohou týmy uplatnit.
Vytvořte praktický plán pro zajištění kontinuity výpadků v Salesforce s analýzou dopadů, cíli RTO/RPO, manuálními řešeními, integračními kontrolami a kontrolami obnovy.
Zjistěte, jak kontaktovat podporu Salesforce během velkého výpadku: zkontrolujte stav důvěryhodnosti, vyberte správný kanál, začněte s důkladným podáním žádosti a sledujte obnovení.
Řešení problémů s přihlášením do Salesforce Workbench, REST Explorerem, časovým limitem, chybou 503, verzí API a omezením chyb během výpadků pomocí praktického diagnostického kontrolního seznamu.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Pochopte hlavní příčiny rozsáhlých výpadků cloudu, jak se selhání kaskádovitě šíří, co zkontrolovat jako první a jak navrhnout odolnější plán obnovy.
Pokud se zdá, že Datorama nebo Marketing Cloud Intelligence nefungují, použijte tento kontrolní seznam založený na důkazech k ověření výpadku, ochraně kvality reportů a zjištění, kdy jsou data opět důvěryhodná.
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.
An AWS outage does not automatically mean Salesforce is down. Learn how Hyperforce, regions, instances, and Salesforce Trust determine whether your org is affected.
