Plkst. 9:10 no rīta Northstar Office Supply pārdošanas komanda mēģina atvērt Salesforce un saņem pakalpojuma kļūdu. Pa e-pastu pienāk jauni pasūtījumi, klientu apkalpošanas aģenti nevar redzēt kontu vēsturi, un fonā atkārtoti mēģina integrācija, kas nosūta pasūtījumu atjauninājumus uz noliktavu. Neviens vēl nezina, vai darbības traucējumi ilgs piecas minūtes vai visu atlikušo dienu.
Ilustratīvais scenārijs: Northstar Office Supply ir fiktīvs uzņēmums, kas tiek izmantots visā šajā rakstā. Tā nav klienta atsauksme, incidenta ziņojums vai testa rezultāts. Piemērs parāda, kā reāla organizācija varētu pārvērst uzņēmējdarbības nepārtrauktības koncepcijas darbības plānā.
Noderīgs Salesforce dīkstāves plāns negarantē, ka visi procesi turpināsies normāli. Tas nosaka, kuriem darbiem ir jāturpinās, kuri darbi var gaidīt, kā cilvēki sazināsies, kā tiks kontrolētas integrācijas un kā ieraksti tiks saskaņoti pēc atkopšanas. Šajā rokasgrāmatā tiek izmantota jaunākā Salesforce dokumentācija, kas pārbaudīta 2026. gada 16. septembrī, kā arī NIST ārkārtas plānošanas vadlīnijas. Produktu nosaukumi, funkcijas, pieejamība, līgumi un pakalpojumu saistības var mainīties, tāpēc validējiet savu Salesforce izdevumu un līgumus.
Salesforce pašreizējā noturības dokumentācijā ir svarīgi nošķirt pakalpojumu sniedzēja nepārtrauktības programmu un klienta paša uzņēmējdarbības nepārtrauktības plānu. Salesforce uzņēmuma noturības/dzīves cikla kopsavilkumā, kas atjaunināts 2026. gada 23. jūlijā, ir aprakstītas pakalpojumu sniedzēja līmeņa programmas riska pārvaldībai, uzņēmējdarbības nepārtrauktībai, krīžu pārvaldībai, trešo pušu riskam, kibernoturībai, incidentu reaģēšanai un katastrofu atkopšanai. Tas neaizstāj klienta plānu personāla nodrošināšanai, manuālajam darbam, klientu saziņai, integrācijām vai datu saskaņošanai.
Vēl viena aktuāla izmaiņa ir 2026. gada 9. septembra Salesforce palīdzības lapa par uzlaboto starpreģionu nepārtrauktības (ACRC) risinājumu. Salesforce apgalvo, ka ACRC ir premium klases Hyperforce piedāvājums ārkārtas reģionālām katastrofām un ka tas tika pārdēvēts no “Out of Region Disaster Recovery”. Lapā ir norādīti RTO un RPO mērķi — 12 stundas un 4 stundas ACRC, norādīts, ka daži pakalpojumi vēl netiek atbalstīti, un norādīts, ka smilškastes organizācijas netiek aptvertas. Šī informācija var būt svarīga, ja vecākā izpildes grāmatā ir atsauce uz iepriekšējo produkta nosaukumu vai tiek pieņemts, ka maksas atkopšanas opcija aizsargā katru organizāciju un funkciju.
Lielākajai daļai uzņēmumu praktiskais sākumpunkts joprojām ir klienta īpašumā esošs plāns, kas darbojas parastu Salesforce pakalpojumu pārtraukumu, plānotas apkopes perioda, identitātes kļūmes, tīkla problēmas vai integrācijas pārtraukuma laikā. Pakalpojumu sniedzēja atkopšanas iespējas var samazināt risku; tās nevar noteikt jūsu uzņēmuma prioritātes jūsu vietā.
Aprakstiet rezultātu darbības terminos. Northstar mērķis varētu būt: “Salesforce piegādes pārtraukuma laikā nodrošināt steidzamu klientu pieprasījumu, pasūtījumu saistību un noliktavas nodošanas kustību; novērst dublētu izpildi; ik pēc 30 minūtēm paziņot statusu; un pēc pakalpojumu atgriešanas saskaņot katru pagaidu ierakstu.” Šis apgalvojums ir noderīgāks nekā “uzturēt Salesforce pieejamību”, jo pēdējais lielākoties nav klienta kontrolē.
Nepārtrauktības plānam vajadzētu ļaut komandai ātri atbildēt uz pieciem jautājumiem:
NIST apraksta ārkārtas situāciju plānošanu kā koordinētu plānu, procedūru un tehnisko pasākumu stratēģiju informācijas sistēmu, darbību un datu atjaunošanai pēc darbības traucējumiem. Tās vadlīnijās uzsvars tiek likts uz sistēmu un darbību novērtēšanu, lai noteiktu prasības un prioritātes. Izmantojiet šo ideju kā plānošanas pamatu, bet pielāgojiet kontroles saviem Salesforce produktiem, procesiem, līgumiem un riska tolerancei.
Sāciet ar ietekmes uz uzņēmējdarbību analīzi, nevis ar Salesforce objektu sarakstu. Intervējiet procesu īpašniekus no pārdošanas, apkalpošanas, finanšu, izpildes, atbilstības un IT nodaļām. Pajautājiet, kas tiek apturēts, ja Salesforce nav pieejams, ko var veikt no esoša avota un kas kļūst bīstams, ja tajā tiek ievadīts vēlāk bez kontroles.
Northstar pirmais inventarizācijas posms varētu izskatīties šādi:
| Process | Ietekme dīkstāves laikā | Pagaidu metode | Atveseļošanās pierādījumi |
|---|---|---|---|
| Steidzamas klientu lietas | Pakalpojumu saistības un eskalācijas var tikt palaistas garām | Apstiprināta tālruņa rinda un ierobežota bezsaistes veidlapa | Lietas numurs, īpašnieks, laika zīmogs, prioritāte un turpmākās darbības statuss |
| Jauni pasūtījumi | Pasūtījumi var tikt aizkavēti vai dublēti. | Kontrolētu pasūtījumu reģistrs ar unikāliem pagaidu ID | Klienta apstiprinājums, preču saraksts, cenas apstiprinājums un izpildes rezultāts |
| Noliktavas nodošana | Sūtījumiem var trūkt autoritatīva pieprasījuma | Manuāla atbrīvošanas apstiprināšana no pilnvarota vadītāja | Pagaidu ID atbilst galīgajam Salesforce pasūtījumam |
| Pārdošanas aktivitāte | Cauruļvada redzamība kļūst novecojusi | Esošās sanāksmes piezīmes un neliela apstiprināta uzņemšanas lapa | Pēdējā kontaktpersona, nākamais solis, īpašnieks un avota laika zīmogs |
| Plānotās integrācijas | Atkārtoti mēģinājumi var radīt dublikātus vai pārslogot galapunktus | Pauze, karantīna vai ātruma ierobežojums atbilstoši izpildes grāmatai | Rindas dziļums, statuss, atkārtošanas lēmums un saskaņošanas ziņojums |
Neievietojiet sensitīvus klientu datus improvizētā personīgā izklājlapā vai tērzēšanas pavedienā. Definējiet apstiprinātu pagaidu krātuvi, piekļuves sarakstu, saglabāšanas periodu un dzēšanas procedūru. Ja manuāla veidlapa nav iespējama, apkopojiet minimālos datus, kas nepieciešami, lai nodrošinātu kritiskā procesa norisi.
Piešķiriet katram kritiskajam procesam atkopšanas laika mērķi (RTO) un atkopšanas punkta mērķi (RPO). RTO norāda, cik ātri procesam ir nepieciešams izmantojams risinājums vai atjaunots pakalpojums. RPO norāda, cik daudz jaunāko datu uzņēmums var atļauties zaudēt vai atkārtoti izveidot. Tie ir biznesa lēmumi, nevis minējumi par to, cik ātri Salesforce atrisinās incidentu.
Northstar varētu noteikt vienas stundas RTO steidzamām klientu lietām, četru stundu RTO noliktavas nodošanai un vienas darba dienas RTO regulārām preču piegādes atjauninājumiem. Tas varētu noteikt nulles RPO maksājuma autorizācijas lēmumam, vienlaikus pieņemot, ka regulāras pārdošanas pavadzīmes ir jāievada atkārtoti no laika zīmoga pagaidu žurnāla. Skaitļi ir fiktīvi piemēri; jūsu finanšu, juridiskajiem un operāciju īpašniekiem ir jāapstiprina mērķi.
Dokumentējiet katra mērķa pamatā esošo pieņēmumu. Vienas stundas RTO var būt nepieciešama personāla nodrošināta tālruņa rinda, apmācīts dežūrmenedžeris un iepriekš apstiprināta veidlapa. Ja šie resursi nav pieejami nedēļas nogalēs, mērķis nav plāns — tā ir vēlme.
Definējiet īsu aktivizēšanas procedūru, lai darbinieki neimprovizētu dažādas atbildes. Pirmajai personai, kas pamana problēmu, jāreģistrē UTC laiks, skartie lietotāji, skartie produkti, kļūdas ziņojums un biznesa process. Pēc tam incidenta vadītājs pārbauda, vai problēma ir plaša vai lokāla.
Salesforce vietnē Trust ir sniegta reāllaika un vēsturiska informācija par produktu un instanču pieejamību un veiktspēju. Pašreizējās palīdzības vadlīnijas paskaidro, kā identificēt instanci, izmantojot Iestatīšana > Uzņēmuma informācija vai meklējot prefiksu Mans domēns, un kā interpretēt statusa krāsas: zaļa — pieejams, dzeltena — pakalpojuma degradācija, violeta — apkope un sarkana — pakalpojuma pārtraukums. Salesforce arī iesaka sūtīt Trust paziņojumus un iesaka sazināties ar atbalsta dienestu, ja galvenā problēma vietnē nav parādījusies ilgāk par 10 minūtēm.
Uzticēšanās ir būtisks pierādījums, taču skaidra statusa lapa nepierāda, ka jūsu tīkls, identitātes nodrošinātājs, pārlūkprogramma, API akreditācijas dati vai integrācijas galapunkts ir veselīgs. Northstar vajadzētu pārbaudīt otru lietotāju, otru tīklu un zema riska tikai lasīšanas darbību, ja to atļauj politika. Ja tiek ietekmēts tikai viens birojs, uzņēmuma mēroga manuāla procesa aktivizēšana var radīt nevajadzīgu darbu.
Nosauciet risinājumu par nosauktu režīmu, piemēram, “Salesforce degradētās darbības”, un definējiet tā ieejas un izejas kritērijus. Darbiniekiem jāzina, kur atrast pašreizējo veidlapu, kas apstiprina izņēmumus un kuras darbības ir aizliegtas. Labs risinājums ir apzināti šaurāks par parastajām darbībām.
Northstar degradētas darbības varētu atļaut steidzamus gadījumus, apstiprinātus pasūtījumus un sūtījumu aizturēšanu, vienlaikus apturot atlaides, kontu apvienošanu, masveida atjauninājumus un nebūtisku datu importēšanu. Plānam jāpiešķir pagaidu identifikators katram manuālajam darījumam. Noderīgs identifikators var ietvert datumu, komandas kodu un secības numuru, taču precīzs formāts jāizvēlas organizācijai un jāpārbauda, vai nav kolīziju.
Izmantojiet pienākumu sadali darbībām ar lielu ietekmi. Personai, kas saņem pasūtījumu, nevajadzētu būt vienīgajai personai, kas apstiprina augstas vērtības sūtījumu. Pieprasiet otru pārbaudi atmaksas, bankas datu izmaiņu vai klienta identitātes lēmumu gadījumā. Reģistrējiet apstiprinājumus ar laiku, vārdu un iemeslu. Šīs kontroles var šķist lēnākas, taču tās samazina risku, ka īslaicīga piegādes pārtraukuma rezultātā rodas krāpšanas, privātuma vai izpildes incidents.
Padariet integrācijas par daļu no nepārtrauktības plāna, nevis pielikumu, kas pieder tikai izstrādātājiem. Uzskaitiet katru ienākošo un izejošo plūsmu, tās aktivizētāju, datu īpašnieku, rindas vai atkārtotas mēģinājuma uzvedību, dublikātu risku un biznesa sekas. Iekļaujiet plānotos uzdevumus, tīmekļa āķus, starpprogrammatūru, notikumu plūsmas, identitātes nodrošinātājus, atskaišu izrakstus un cilvēku augšupielādes.
Salesforce darbības pārtraukuma laikā automātiski atkārtoti mēģinājumi var būt gan noderīgi, gan kaitīgi. Ja galamērķis nav pieejams, var būt piemēroti ierobežoti atkārtoti mēģinājumi ar rezervāciju. Ja avots pieņem ziņojumus, bet Salesforce to nedara, ievietojiet ziņojumus rindā ar noturīgu laika zīmogu un idempotences atslēgu. Ja neviena no pusēm nevar apstiprināt, vai rakstīšana izdevās, pārtrauciet atskaņošanu, līdz ir zināms statuss. Nekad nepieņemiet, ka taimauts nozīmē, ka darījums netika apstiprināts.
Northstar izpildgrāmata var norādīt integrācijas īpašniekam apturēt izejošos uzdevumus pēc trim neveiksmīgiem mēģinājumiem, saglabāt sākotnējo vērtumu, reģistrēt pēdējo apstiprināto Salesforce laika zīmogu un novērst manuālu atkārtotu ievadīšanu, līdz rinda ir klasificēta. Precīzs slieksnis ir izdomāts piemērs. Nosakiet to, pamatojoties uz novēroto uzvedību, pakalpojumu sniedzēja norādījumiem un biznesa risku.
Nepārtrauktība un dublēšana risina saistītas, bet atšķirīgas problēmas. Nepārtrauktības procedūra nodrošina uzņēmuma darbību pārtraukuma laikā. Dublēšana palīdz atgūt datus pēc dzēšanas, bojāšanas vai cita zuduma notikuma. Dublēšana automātiski nenodrošina tiešu aizvietotāju Salesforce lietojumprogrammai, tās atļaujām, automatizācijām vai integrācijām.
Salesforce datu dublēšanas vadlīnijās dublējumkopijas ir aprakstītas kā atsevišķi glabātas kopijas atjaunošanai un ieteiktas regulāras dublējumkopijas, vairākas atrašanās vietas un pārbaudīta atkopšana. Izlemiet, kuri ieraksti, metadati, faili un audita informācija uzņēmumam ir jāatjauno, cik ilgi tie ir jāglabā un kas var autorizēt atjaunošanu. Pārbaudiet, vai atjaunotos datus var saskaņot ar pagaidu ierakstiem, kas izveidoti dīkstāves laikā.
Ja jūsu organizācija apsver iespēju ieviest uzlabotu starpreģionu nepārtrauktības risinājumu (Advanced Cross-Region Continuity), uzmanīgi izlasiet pašreizējos Salesforce bieži uzdotos jautājumus. Salesforce norāda, ka piedāvājums attiecas tikai uz Hyperforce, daži pakalpojumi vēl netiek atbalstīti un atkopšanas notikums padara organizāciju nepieejamu, kamēr notiek atkopšanas operācijas pēc katastrofām. Tajā arī norādīts, ka valsts līmeņa datu glabāšanas saistības var tikt ietekmētas, ja primārie un sekundārie reģioni atrodas dažādās valstīs. Tie ir plānošanas ierobežojumi, nevis zemsvītras piezīmes.
Piešķiriet vienu incidenta vadītāju, vienu tehnisko vadītāju, vienu biznesa operāciju vadītāju un vienu komunikācijas īpašnieku. Definējiet katras lomas rezerves kopijas. Saglabājiet ziņojuma faktiskumu: kas tiek ietekmēts, kad tas sākās, kas lietotājiem jādara, ko viņi nedrīkst darīt, kad tiks saņemts nākamais atjauninājums un kur atrodas apstiprinātās instrukcijas.
Nepaziņojiet atkopšanas laiku, ko Salesforce nav apstiprinājis. Nelūdziet klientiem atkārtoti nosūtīt informāciju, ja sākotnējais pieprasījums, iespējams, jau ir rindā. Northstar gadījumā klienta ziņojumā varētu būt teikts, ka pasūtījumu pieņemšana notiek, izmantojot pagaidu kanālu, ka klientiem jāizmanto viena norādītā saziņas metode un ka nākamais statusa atjauninājums tiks izdots noteiktā laikā.
Iekļaujiet iekšējās eskalācijas robežvērtības. Piemēram, kritisks klientu ietekmējošs process var nekavējoties nosūtīt incidenta potenciālajam klientam ziņojumu, savukārt novecojis ziņojums var gaidīt līdz nākamajai plānotajai pārskatīšanai. Saistiet plānu ar pašreizējiem Salesforce Trust paziņojumiem un organizācijas atbalsta tiesībām. Tālruņu koks, kas vairs neatbilst darbaspēkam, nav komunikācijas plāns.
Sāciet ar galda spēles vingrinājumu. Dodiet Northstar komandai izdomātu uzdevumu, piemēram: “Plkst. 9:10 Salesforce nav pieejams apkalpošanas un pārdošanas komandām; noliktavas integrācijas darbi atkārtoti uzrāda kļūmes; Trust ziņo par pakalpojuma pārtraukumu.” Palūdziet katrai lomai veikt plāna pirmās 30 minūtes, izmantojot tikai dokumentētos materiālus.
Novērojamu rezultātu mērīšana:
Pēc galda testa veiciet kontrolētu tehnisko testu smilškastes vai neražošanas vidē, kur scenārijs ir drošs un atbalstīts. Neapgalvojiet, ka smilškastes vingrinājums pierāda ražošanas pārslēgšanos. Salesforce ACRC dokumentācijā ir skaidri norādīts, ka smilškastes organizācijas nav ietvertas ACRC, kas ir atgādinājums pārbaudīt faktisko atkopšanas tvērumu, nevis secināt to no zemākas vides.
Atkopšana sākas, kad incidenta vadītājam ir ticami pierādījumi, ka skartais Salesforce pakalpojums ir lietojams, nevis tikai tad, kad lietotājs var ielādēt pieteikšanās lapu. Apstipriniet statusa lapu, veiciet nelielu autorizētu darbību, pārbaudiet integrācijas un paziņojiet par kontrolētu atgriešanos pie normālas darbības.
Saskaņot secībā, kas aizsargā ierakstu sistēmu:
Plāns nevar piespiest Salesforce ātrāk atgūties, garantēt integrācijas rakstīšanas pabeigšanu vai likt neatbalstītam produktam darboties kā atbalstītam produktam. Tas nevar aizstāt līguma pārskatīšanu, privātuma analīzi, dublējuma testēšanu vai reaģēšanu uz drošības incidentiem. Manuāls risinājums var radīt arī transkripcijas kļūdas, piekļuves kontroles problēmas, aizkavētu ieņēmumu atzīšanu un klientu apjukumu.
Tāpēc plānā jāiekļauj lēmums par apturēšanu. Ja komanda nevar pārbaudīt klienta identitāti, maksājuma norādījuma integritāti, sūtījuma statusu vai datu pārsūtīšanas galamērķi, darbība jāatliek, lai veiktu autorizētu pārskatīšanu. Nepārtrauktība nav tas pats, kas katra darījuma turpināšana par katru cenu.
Northstar panākumi nenozīmē, ka “Salesforce nekad nedarbojas”. Panākumi nozīmē, ka komanda atpazīst traucējumus, aizsargā kritiski svarīgu darbu, izvairās no nedrošas improvizācijas, uztur izsekojamu pagaidu darbību uzskaiti un atgriežas pie normālas darbības bez slēptiem dublikātiem vai trūkstošām saistībām. Šis ir standarts, kam jāatbilst praktiskam Salesforce biznesa nepārtrauktības plānam.
Pārskatiet ievērojamākos Salesforce darbības pārtraukumus 2025. gadā, kas neizdevās, cik ilgi ilga atlasītie incidenti un praktiskās noturības mācības, ko komandas var pielietot.
Izveidojiet praktisku Salesforce dīkstāves nepārtrauktības plānu ar ietekmes analīzi, RTO/RPO mērķiem, manuāliem risinājumiem, integrācijas vadīklām un atkopšanas pārbaudēm.
Uzziniet, kā sazināties ar Salesforce atbalsta dienestu nopietnas elektroenerģijas padeves pārtraukuma laikā: pārbaudiet uzticamības statusu, izvēlieties pareizo kanālu, atveriet spēcīgu pieteikumu un izsekojiet atkopšanas gaitu.
Novērsiet Salesforce Workbench pieteikšanās, REST Explorer, taimauta, 503, API versijas problēmas un ierobežojiet kļūdas dīkstāves laikā, izmantojot praktisku diagnostikas kontrolsarakstu.
StoreForce problēmas var traucēt darba grafiku, laika uzskaiti un darbinieku darbplūsmas. Uzziniet, kā novērtēt ietekmi, nodrošināt veikalu darbību, pārbaudīt problēmu risināšanu un zināt, kad tās ir jārisina.
Izprotiet galvenos plaši izplatīto mākoņpakalpojumu dīkstāves cēloņus, to, kā kļūmes kaskādes veidā izplatās, kas jāpārbauda vispirms un kā izstrādāt noturīgāku atkopšanas plānu.
Ja šķiet, ka Datorama vai Marketing Cloud Intelligence nedarbojas, izmantojiet šo uz pierādījumiem balstīto kontrolsarakstu, lai pārbaudītu darbības traucējumu, aizsargātu pārskatu kvalitāti un zinātu, kad dati atkal ir uzticami.
Praktisks ieskats tajā, kā Heroku darbības pārtraukumi var ietekmēt izvietotās lietotnes, dinamometrus, maršrutēšanu, datubāzes, izvietošanu, Heroku Connect, žurnālus un atkopšanu.
Izprotiet, kā Salesforce un AWS savienojas, izmantojot Hyperforce, integrācijas, tīklošanu, datu glabāšanu, elektroenerģijas padeves pārtraukumus un kopīgu operatīvo atbildību.
AWS darbības pārtraukums ne vienmēr nozīmē, ka Salesforce nedarbojas. Uzziniet, kā Hyperforce, reģioni, instances un Salesforce Trust nosaka, vai jūsu organizācija ir ietekmēta.
