V 9:10 se obchodní tým společnosti Northstar Office Supply pokouší otevřít Salesforce a obdrží chybu služby. Nové objednávky přicházejí e-mailem, pracovníci zákaznického servisu nevidí historii účtů a integrace, která odesílá aktualizace objednávek do skladu, se na pozadí pokouší o opětovné spuštění. Nikdo zatím neví, zda narušení bude trvat pět minut, nebo zbytek dne.
Ilustrativní scénář: Northstar Office Supply je fiktivní společnost použitá v tomto článku. Nejedná se o zákaznickou referenci, zprávu o incidentu ani výsledek testu. Tento příklad ukazuje, jak by skutečná organizace mohla proměnit koncepty kontinuity podnikání v provozní plán.
Užitečný plán prostojů Salesforce neslibuje, že každý proces bude pokračovat normálně. Definuje, která práce musí pokračovat, která práce může počkat, jak budou lidé komunikovat, jak budou řízeny integrace a jak budou záznamy po obnovení odsouhlaseny. Tato příručka používá aktuální dokumentaci Salesforce kontrolovanou 16. září 2026 a také pokyny NIST pro plánování pro případ nouze. Názvy produktů, funkce, dostupnost, smlouvy a závazky služeb se mohou změnit, proto si ověřte vlastní verzi a smlouvy Salesforce.
Současná dokumentace společnosti Salesforce týkající se odolnosti podniku činí důležitý rozdíl mezi programem kontinuity provozu poskytovatele a vlastním plánem kontinuity podnikání zákazníka. Souhrn Salesforce Enterprise Resilience/BCP, aktualizovaný 23. července 2026, popisuje programy na úrovni poskytovatele pro řízení rizik, kontinuitu podnikání, krizové řízení, rizika třetích stran, kybernetickou odolnost, reakci na incidenty a zotavení po havárii. Nenahrazuje plán zákazníka pro personální obsazení, manuální práci, komunikaci se zákazníky, integrace ani sladění dat.
Další aktuální změnou je stránka nápovědy Salesforce z 9. září 2026 pro Advanced Cross-Region Continuity (ACRC). Salesforce uvádí, že ACRC je prémiová nabídka Hyperforce pro mimořádné regionální katastrofy a že byla přejmenována z Out of Region Disaster Recovery. Stránka uvádí cílové hodnoty RTO a RPO 12 hodin a 4 hodiny pro ACRC, poznamenává, že některé služby zatím nejsou podporovány, a uvádí, že organizace typu sandbox nejsou zahrnuty. Tyto podrobnosti mohou být důležité, pokud starší runbook odkazuje na dřívější název produktu nebo předpokládá, že placená možnost obnovy chrání každou organizaci a funkci.
Pro většinu podniků zůstává praktickým výchozím bodem plán vlastněný zákazníkem, který funguje během běžného výpadku služeb Salesforce, plánovaného okna údržby, selhání identity, problému se sítí nebo výpadku integrace. Funkce obnovy poskytovatele může snížit riziko; nemůže za vás rozhodovat o vašich obchodních prioritách.
Popište výsledek z hlediska provozu. Cílem společnosti Northstar by mohlo být: „Během výpadku Salesforce udržovat v chodu naléhavé požadavky zákazníků, závazky objednávek a předávání do skladu; zabránit duplicitnímu vyřizování; sdělovat stav každých 30 minut; a po obnovení služby odsouhlasit každý dočasný záznam.“ Toto prohlášení je užitečnější než „udržovat dostupnost Salesforce“, protože to druhé je většinou mimo kontrolu zákazníka.
Plán kontinuity by měl týmu umožnit rychle odpovědět na pět otázek:
NIST popisuje plánování pro případ nouze jako koordinovanou strategii plánů, postupů a technických opatření pro obnovu informačních systémů, provozu a dat po narušení. Jeho pokyny kladou důraz na vyhodnocení systémů a provozu za účelem určení požadavků a priorit. Použijte tuto myšlenku jako rámec plánování, ale přizpůsobte kontrolní mechanismy vašim produktům, procesům, smlouvám a toleranci rizik v Salesforce.
Začněte analýzou dopadu na podnikání, nikoli seznamem objektů Salesforce. Proveďte rozhovory s vlastníky procesů z oblasti prodeje, služeb, financí, plnění požadavků, dodržování předpisů a IT. Zeptejte se, co se zastaví, pokud Salesforce není k dispozici, co lze provést ze stávajícího zdroje a co se stane nebezpečným, pokud se k tomu přistoupí později bez kontroly.
Pro Northstar by první inventář mohl vypadat takto:
| Proces | Dopad během prostojů | Dočasná metoda | Důkazy o zotavení |
|---|---|---|---|
| Naléhavé případy zákazníků | Závazky ohledně služeb a eskalace mohou být zmeškány | Schválená telefonní fronta a omezený offline formulář | Číslo případu, vlastník, časové razítko, priorita a stav následné péče |
| Nové objednávky | Objednávky mohou být zpožděny nebo duplikovány | Řízený registr objednávek s jedinečnými dočasnými ID | Potvrzení zákazníka, seznam položek, schválení ceny a výsledek plnění |
| Předání skladu | Zásilky mohou postrádat autoritativní požadavek | Ruční schválení uvolnění od autorizovaného manažera | Dočasné ID spárované s finální objednávkou Salesforce |
| Prodejní aktivita | Viditelnost potrubí se stává zastaralou | Stávající zápisy ze schůzek a malý schválený formulář pro příjem | Poslední kontakt, další krok, vlastník a časové razítko zdroje |
| Plánované integrace | Opakované pokusy mohou vytvářet duplikáty nebo přetížit koncové body. | Pozastavení, karanténa nebo omezení rychlosti podle runbooku | Hloubka fronty, stav, rozhodnutí o přehrání a zpráva o odsouhlasení |
Nevkládejte citlivá zákaznická data do improvizované osobní tabulky nebo vlákna chatu. Definujte schválené dočasné úložiště, seznam přístupových práv, dobu uchovávání a postup mazání. Pokud je ruční formulář nevyhnutelný, shromážděte minimální data potřebná k zajištění chodu kritického procesu.
Každému kritickému procesu přiřaďte cílovou dobu obnovy (RTO) a cílový bod obnovy (RPO). RTO udává, jak rychle proces potřebuje použitelné alternativní řešení nebo obnovenou službu. RPO udává, kolik aktuálních dat si firma může dovolit ztratit nebo znovu vytvořit. Jde o obchodní rozhodnutí, nikoli o odhady, jak rychle Salesforce incident vyřeší.
Společnost Northstar by mohla stanovit dobu trvání (RTO) jednu hodinu pro naléhavé případy zákazníků, čtyřhodinovou dobu trvání pro předávání do skladu a jeden pracovní den pro běžné aktualizace procesů. Pro rozhodnutí o autorizaci platby by mohla stanovit nulovou dobu trvání (RPO), přičemž by akceptovala, že běžné prodejní doklady musí být znovu zadávány z dočasného protokolu s časovým razítkem. Čísla jsou fiktivní příklady; cíle musí schválit vaši finanční, právní a provozní vlastníci.
Zdokumentujte předpoklad, na kterém je každý cíl založený. Hodinový časový limit může vyžadovat obsazenou telefonní frontu, vyškoleného vedoucího služby a předem schválený formulář. Pokud tyto zdroje nejsou o víkendech k dispozici, cíl není plán – je to aspirace.
Definujte krátký aktivační postup, aby zaměstnanci neimprovizovali s různými reakcemi. První osoba, která si problému všimne, by měla zaznamenat čas UTC, dotčené uživatele, dotčené produkty, chybovou zprávu a obchodní proces. Vedoucí incidentu poté ověří, zda je problém široký nebo lokální.
Webové stránky Salesforce o důvěře poskytují informace v reálném čase i historické informace o dostupnosti a výkonu produktů a instancí. Aktuální nápověda vysvětluje, jak identifikovat instanci pomocí Nastavení > Informace o společnosti nebo vyhledáním předpony Moje doména a jak interpretovat barvy stavu: zelená pro Dostupné, žlutá pro Zhoršení služby, fialová pro Údržbu a červená pro Přerušení služby. Salesforce také doporučuje notifikace o důvěře a doporučuje kontaktovat podporu, pokud se základní problém na webu neobjeví po dobu delší než 10 minut.
Důvěra je nezbytným důkazem, ale jasná stránka se stavem nedokazuje, že vaše vlastní síť, poskytovatel identity, prohlížeč, přihlašovací údaje API nebo integrační koncový bod jsou v pořádku. Northstar by měl otestovat druhého uživatele, druhou síť a nízkorizikovou akci pouze pro čtení, pokud to zásady dovolují. Pokud je ovlivněna pouze jedna pobočka, může aktivace manuálního procesu v celé společnosti vytvořit zbytečnou práci.
Řešení nazvěte pojmenovaným režimem, například „Operace Salesforce s omezeným provozem“ a definujte jeho vstupní a výstupní kritéria. Zaměstnanci by měli vědět, kde najdou aktuální formulář, kdo schvaluje výjimky a které akce jsou zakázány. Dobré řešení je záměrně užší než běžné operace.
Pro Northstar by omezený provoz mohl umožnit naléhavé případy, schválené objednávky a blokování dodávek, zatímco by se pozastavily slevy, slučování účtů, hromadné aktualizace a import nepodstatných dat. Plán by měl každé manuální transakci přiřadit dočasný identifikátor. Užitečný identifikátor může zahrnovat datum, kód týmu a pořadové číslo, ale přesný formát by měla zvolit organizace a zkontrolovat jej na kolize.
U akcí s vysokým dopadem používejte oddělení povinností. Osoba, která objednávku přijímá, by neměla být jedinou osobou, která schvaluje zásilku s vysokou hodnotou. Vyžadujte druhou kontrolu v případě vrácení peněz, změn bankovních údajů nebo rozhodnutí o identitě zákazníka. Zaznamenávejte schválení s uvedením času, jména a důvodu. Tyto kontroly se mohou zdát pomalejší, ale snižují riziko, že se z krátkodobého výpadku stane podvod, incident narušení soukromí nebo plnění zásilky.
Udělejte z integrací součást plánu kontinuity, ne jen dodatek vlastněný pouze vývojáři. Uveďte všechny příchozí a odchozí toky, jejich spouštěče, vlastníky dat, chování při zařazení do fronty nebo opakovaném pokusu, riziko duplicity a obchodní důsledky. Zahrňte naplánované úlohy, webhooky, middleware, streamy událostí, poskytovatele identit, výpisy z reportů a nahrávání lidmi.
Během výpadku Salesforce mohou být automatické opakování pokusů užitečné nebo škodlivé. Pokud cíl není k dispozici, mohou být vhodné omezené opakování s odkladem. Pokud zdroj přijímá zprávy, ale Salesforce ne, zařaďte zprávy do fronty s trvalým časovým razítkem a klíčem idempotence. Pokud žádná ze stran nemůže potvrdit, zda zápis proběhl úspěšně, zastavte přehrávání, dokud nebude znám stav. Nikdy nepředpokládejte, že časový limit znamená, že transakce nebyla potvrzena.
Runbook společnosti Northstar může dát vlastníkovi integrace pokyn, aby po třech neúspěšných pokusech pozastavil odchozí úlohy, zachoval původní datovou část, zaznamenal poslední potvrzené časové razítko Salesforce a zabránil ručnímu opětovnému vstupu, dokud nebude fronta klasifikována. Přesná prahová hodnota je fiktivní příklad. Nastavte ji na základě pozorovaného chování, pokynů poskytovatele a obchodního rizika.
Zajištění kontinuity a zálohování řeší související, ale odlišné problémy. Procedura pro zajištění kontinuity provozu zajišťuje chod firmy i během přerušení. Záloha pomáhá obnovit data po smazání, poškození nebo jiné ztrátě. Záloha automaticky neposkytuje živou náhradu pro aplikaci Salesforce, její oprávnění, automatizace ani integrace.
Pokyny pro zálohování dat společnosti Salesforce popisují zálohy jako kopie uložené samostatně pro účely obnovení a doporučují pravidelné zálohování, více umístění a testovanou obnovu. Rozhodněte, které záznamy, metadata, soubory a auditní informace potřebuje firma obnovit, jak dlouho je musí uchovávat a kdo může obnovení autorizovat. Otestujte, zda lze obnovená data porovnat s dočasnými záznamy vytvořenými během výpadku.
Pokud vaše organizace zvažuje rozšířenou kontinuitu mezi regiony, pečlivě si přečtěte aktuální nejčastější dotazy k Salesforce. Salesforce uvádí, že nabídka je omezena na Hyperforce, některé služby zatím nejsou podporovány a událost obnovy znemožní organizaci dostupnost během operací obnovy po havárii. Také uvádí, že závazky k ukládání dat na úrovni jednotlivých zemí mohou být ovlivněny, pokud se primární a sekundární regiony nacházejí v různých zemích. Jedná se o plánovací omezení, nikoli o poznámky pod čarou.
Přiřaďte jednoho vedoucího incidentů, jednoho technického vedoucího, jednoho vedoucího obchodních operací a jednoho zodpovědného za komunikaci. Definujte zálohy pro každou roli. Udržujte zprávu věcnou: čeho se to týká, kdy to začalo, co by uživatelé měli dělat, co nesmí dělat, kdy dorazí další aktualizace a kde jsou uloženy schválené pokyny.
Neoznamujte čas obnovení, který Salesforce nepotvrdil. Nežádejte zákazníky o opakované zasílání informací, pokud původní požadavek již může být zařazen do fronty. V případě společnosti Northstar by zpráva pro zákazníka mohla uvádět, že příjem objednávek probíhá prostřednictvím dočasného kanálu, že zákazníci by měli použít jeden určený způsob kontaktu a že další aktualizace stavu bude vydána v definovaném čase.
Zahrňte interní prahové hodnoty pro eskalaci. Například kritický proces s dopadem na zákazníka může okamžitě odeslat zájemce o incident, zatímco zastaralý report může počkat na další plánovanou kontrolu. Propojte plán s aktuálními oznámeními Salesforce Trust a nároky organizace na podporu. Telefonní strom, který již neodpovídá pracovní síle, není komunikační plán.
Začněte cvičením u stolu. Zadejte týmu Northstar fiktivní výzvu, například: „V 9:10 není Salesforce k dispozici pro servisní a prodejní týmy; úlohy integrace skladu vykazují opakované chyby; Trust hlásí narušení služeb.“ Požádejte každou roli, aby provedla prvních 30 minut plánu pouze s použitím zdokumentovaných materiálů.
Měření pozorovatelných výsledků:
Po provedení testu v tabletu spusťte kontrolovaný technický test v sandboxovém nebo neprodukčním prostředí, kde je scénář bezpečný a podporovaný. Netvrdte, že cvičení v sandboxovém prostředí prokáže převzetí služeb v produkčním prostředí. Dokumentace ACRC společnosti Salesforce výslovně uvádí, že sandboxové organizace nejsou ACRC pokryty, což je připomínka k testování skutečného rozsahu obnovy, nikoli k jeho odvozování z prostředí nižší úrovně.
Obnova začíná, když má vedoucí pracovník incidentu spolehlivý důkaz, že postižená služba Salesforce je použitelná – nikoli pouze tehdy, když uživatel může načíst přihlašovací stránku. Potvrďte stavovou stránku, otestujte ji malou autorizovanou akcí, zkontrolujte integrace a oznámte kontrolovaný návrat k normálnímu provozu.
Proveďte odsouhlasení v pořadí, které chrání systém záznamů:
Plán nemůže donutit Salesforce k rychlejší obnově, zaručit dokončení integračního zápisu ani zajistit, aby se nepodporovaný produkt choval jako podporovaný. Nemůže nahradit smluvní kontrolu, analýzu soukromí, testování záloh ani reakci na bezpečnostní incidenty. Ruční řešení může také způsobit chyby při přepisu, problémy s řízením přístupu, zpožděné rozpoznávání tržeb a zmatek zákazníků.
Plán by proto měl zahrnovat rozhodnutí o zastavení. Pokud tým nemůže ověřit totožnost zákazníka, integritu platebního pokynu, stav zásilky nebo cíl datového přenosu, pozastavte akci k autorizovanému přezkoumání. Kontinuita není totéž jako pokračování v každé transakci za každou cenu.
Pro Northstar úspěch neznamená „Salesforce nikdy neselže“. Úspěch spočívá v tom, že tým rozpozná narušení, ochrání kritickou práci, vyhne se nebezpečné improvizaci, uchovává sledovatelný záznam o dočasných akcích a vrátí se k normálnímu provozu bez skrytých duplicit nebo chybějících závazků. To je standard, který by měl splňovat praktický plán kontinuity podnikání Salesforce.
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.
