Salesforce pakalpojumu pārtraukumi 2025. gadā nesekoja vienam vienkāršam modelim. Daži incidenti aprobežojās ar konkrētām instancēm vai produktiem, savukārt citi šķērsoja vairākus mākoņus vai bija atkarīgi no trešo pušu infrastruktūras. Operāciju, IT, CRM, tirdzniecības un mārketinga komandām noderīga retrospekcija nav visu tajā gadā publicēto Trust ierakstu saraksts. Tā ir to traucējumu apskats, kas atklāj atkārtotus kļūmju režīmus: autentifikācijas atkarības, datu centra infrastruktūra, datubāzes atkopšana, satura piegādes tīkli, mākoņpakalpojumu sniedzēja DNS un izmaiņas, kas jāatceļ.
Šajā atsaucē galvenā uzmanība pievērsta atlasītam nozīmīgu 2025. gada incidentu kopumam, ko dokumentējis Salesforce Trust. Ar “būtisku” šeit tiek domāts operacionāli ievērojams incidents ilguma, apjoma vai ietekmētās klientu darbplūsmas veida dēļ; tas nenozīmē, ka tika ietekmēti visi klienti, un tas nav pilnīgs incidentu uzskaitījums. Precīza ietekme bija atkarīga no produkta, instances, reģiona un nomnieka.
| Datums | Salesforce ziņotā informācija | Ziņotais ilgums vai atveseļošanās periods | Kāpēc tas ir svarīgi operacionāli |
|---|---|---|---|
| 7. februāris | Pakalpojumu pārtraukumi daļai klientu, un Salesforce min resursu ierobežojumus, kas saistīti ar augstu tīkla datplūsmas izmantošanu. | 2 stundas 20 minūtes | Jaudas un satiksmes slodzes dēļ veiktspējas pasliktināšanās var izraisīt pilnīgu nepieejamību. |
| 13.–14. februāris | Pakalpojuma pārtraukums saistīts ar trešās puses piegādātāja problēmu; Salesforce paziņoja, ka piegādātājs konstatēja bojājumus fiziskajā tīkla infrastruktūrā, kamēr Salesforce strādāja pie rezerves pārslēgšanas. | 1 stunda un 45 minūtes | Ārējā savienojamība var kļūt par daļu no efektīvās Salesforce pieejamības robežas. |
| 10.–11. jūnijs | Vairāku mākoņu notikums ietekmēja autentifikāciju un pakalpojumus dažādos produktos, tostarp Heroku, Commerce, Marketing Cloud un citos Salesforce pakalpojumos. | Viens trasta incidents ilga 22 stundas un 43 minūtes. | Identitātes un koplietoto platformu atkarības var radīt plašu ietekmi uz uzņēmējdarbību pat tad, ja atsevišķas lietojumprogrammas paliek neskartas. |
| 18.–19. jūnijs | Dzesēšanas sistēmas kļūme Indianapolisas datu centrā izraisīja tīkla darbības traucējumus; Salesforce ziņoja, ka lielākā daļa serveru visvairāk skartajos serveros pārstāja darboties pirms pakāpeniskas atjaunošanas. | Minētajā incidentā ziņots, ka pakalpojuma pārtraukuma ilgums ir 18 stundas un 44 minūtes. | Fiziskās iekārtas, barošana, tīklošana, virtuālā infrastruktūra, datubāzes un lietojumprogrammu atkopšana var veidot garu atkarības ķēdi. |
| 2.–6. oktobris | Marketing Cloud klienti datubāzē DB10016 zaudēja pakalpojumu, jo datubāze nebija pieejama; Salesforce veica datubāzes atjaunošanu un validāciju. | Ziņots, ka pakalpojuma pārtraukuma fāze ilgst 3 dienas un 16 stundas pirms veiktspējas pasliktināšanās. | Datu bāzes atjaunošana var būt daudz lēnāka nekā lietojumprogrammas restartēšana, tāpēc nepārtrauktības plāniem ir nepieciešams ilgtermiņa režīms. |
| 20. oktobrī | Vairākus Salesforce mākoņus ietekmēja trešās puses mākoņinfrastruktūras piegādātāja DNS problēma. Par saistītu ietekmi ziņoja Commerce Cloud, MuleSoft, Marketing Cloud Account Engagement, Heroku un citi pakalpojumi. | Atšķīrās atkarībā no pakalpojuma; minētie Commerce pakalpojuma pārtraukumi ilga 3 stundas un 19 minūtes, savukārt MuleSoft incidents palika atklāts 16 stundas un 23 minūtes. | Viena pakalpojumu sniedzēja līmeņa atkarība var radīt atšķirīgus simptomus un atkopšanas laikus dažādos produktos. |
| 18. novembrī | Daļai Commerce Cloud veikalu platformu periodiski radās HTTP 500 kļūdas. Salesforce paziņoja, ka tās platforma un tīkls darbojas normāli, un traucējumus skaidroja ar trešās puses CDN pakalpojumu sniedzēja konfigurācijas atjauninājumu, kas tika atsaukts. | 4 stundas 40 minūtes | Klientu apkalpošanas pieejamība var neizdoties piegādes perifērijā pat tad, ja galvenā lietojumprogrammu platforma ir darbspējīga. |
Avota ieraksti: Salesforce Trust incidents 13702 , Salesforce Trust incidents 13729 , Salesforce Trust incidents 10014307 , Salesforce Trust incidents 10014353 , Salesforce Trust incidents 20003296 , Salesforce Trust Commerce Cloud incidents 20003368 , Salesforce Trust MuleSoft incidents 20003364 un Salesforce Trust Commerce Cloud incidents 20003465 .
Salesforce Trust ziņo par incidentiem pēc produkta, instances, pakalpojuma un dažreiz pēc datubāzes vai reģionālā komponenta. 7. februāra darbības traucējumi ietekmēja klientu apakškopu. 2. oktobra Marketing Cloud incidents bija vērsts uz vienu datubāzi. 20. oktobra notikums aptvēra vairākus mākoņus, taču radīja atšķirīgus atkopšanas laikus un simptomus. Tāpēc respondentiem pirmais noderīgais jautājums nav tikai tas, vai Salesforce nedarbojas, bet gan tas, kurš nomnieks, produkts, reģions, instance un atkarība nedarbojas.
Salesforce nodrošina veidu, kā atrast organizācijas statusu, izmantojot tās nosaukumu My Domain. Oficiālajā atbalsta rakstā ir paskaidrots, kā izmantot uzticamības statusa lapu, lai atrastu instancei specifisku statusa un uzturēšanas informāciju: Salesforce palīdzība: iegūstiet organizācijas statusu un uzturēšanas datumus, izmantojot My Domain .
Vairāki 2025. gada incidenti parāda, kāpēc SaaS nepārtrauktības plānošana nevar apstāties pie SaaS pārdevēja robežas. 13.–14. februāra incidentā bija iesaistīts trešās puses tīkla pārdevējs. 20. oktobra vairāku mākoņu darbības pārtraukums bija saistīts ar DNS problēmu trešās puses mākoņinfrastruktūras pārdevējā. 18. novembrī Salesforce ziņoja par Commerce Cloud veikala savienojamības problēmām, kas saistītas ar trešās puses CDN pakalpojumu sniedzēja konfigurācijas atjauninājumu.
Mācība nav tāda, ka trešās puses pēc savas būtības ir neuzticamas. Tā ir tāda, ka klientu darbplūsmas ir atkarīgas no pakalpojumu ķēdes: identitātes, DNS, tīklošanas, satura piegādes, mākoņinfrastruktūras, API un lietojumprogrammu pakalpojumiem. Jūsu incidentu modelim ir jāseko šai ķēdei.
Spilgts piemērs ir datu centra pasākums, kas notika 18.–19. jūnijā. Salesforce aprakstīja fizisko un virtuālo resursu atjaunošanu, pēc tam datubāzu un kopiju aktivizēšanu, datu parametru validāciju un atkarīgo pakalpojumu atjaunošanu. Arī oktobra Marketing Cloud datubāzes darbības traucējumi ietvēra atjaunošanu, konfigurācijas pārbaudes, validāciju un vēlāku veiktspējas degradācijas fāzi.
Šī atšķirība ir svarīga biznesa komandām. “Platforma atkopjas” nebūt nenozīmē, ka katra rinda ir iztukšota, katra integrācija ir atkārtota, katra vitrīna ir stabila vai katrs ieplānotais uzdevums ir veiksmīgi izpildīts.
Noderīga uzticamības pārskatīšana ietver trīs posmus. Pirmkārt, izlasiet ietekmētos pakalpojumus un instances. Otrkārt, salīdziniet publicēto sākuma laiku ar savu telemetriju; Salesforce dažreiz pārskata incidentu sākuma laikus, uzlabojoties izmeklēšanai. Treškārt, nošķiriet pakalpojumu pārtraukumus no veiktspējas pasliktināšanās vai funkciju pārtraukumiem. Šīs etiķetes apraksta dažādus darbības stāvokļus, un funkciju līmeņa incidents var padarīt lielāko daļu platformas lietojamu.
Nepieņemiet, ka incidenta ilgums ir vienāds ar periodu, kurā katrs skartais klients piedzīvoja identiskus simptomus. Salesforce atjauninājumi bieži apraksta ietekmes rādiusa paplašināšanu vai samazināšanu, pakāpenisku atkopšanu vai produktam specifisku atjaunošanu. Iekšējai ziņošanai reģistrējiet gan pārdevēja oficiālo laika grafiku, gan savu novēroto ietekmes periodu.
Vissvarīgākā noturības mācība no 2025. gada ir tāda, ka elektroenerģijas padeves pārtraukuma plānam jābūt ilgākam par 30 minūšu režīmu. Īslaicīgam pārtraukumam var būt nepieciešama tikai komunikācija un pacietība. Vairāku stundu ilgs notikums prasa rindā esošu darbu un kontrolētus manuālus procesus. Pārtraukums, kas ilgst vairākas dienas, piemēram, minētais Marketing Cloud datubāzes incidents, prasa personāla nodošanu, uzdevumu pārvaldību, komunikāciju ar klientiem un atjaunošanas plānu atliktajām kampaņām, importam, eksportam, API darbībām un pārskatu sniegšanai.
Pirms elektroenerģijas padeves pārtraukuma definējiet atkopšanas prioritātes. Pārdošanas organizācijai potenciālo klientu pieņemšana un klientu saistības var būt svarīgākas par analītikas atsvaidzināšanu. Mazumtirgotājam pasūtījumu saņemšana, krājumu precizitāte un klientu apkalpošanas pārskatāmība var būt kritiskais ceļš. Mārketinga komandai prioritāte var būt dublētu sūtījumu novēršana un kampaņas stāvokļa saglabāšana, nevis mēģinājums piespiest katru plānoto darbību veikt nestabilā sistēmā.
Izmantojiet retrospektīvu pieņēmumu pārbaudei, nevis nākamās kļūmes prognozēšanai. 2025. gada incidenti liecina, ka sākotnējo problēmu var izraisīt datplūsmas spiediens, piegādātāju tīklošana, fiziskā dzesēšana, datubāzes, DNS, CDN konfigurācija vai programmatūras izmaiņas. Neviens atsevišķs risinājums neaptver visus šos aspektus.
Tāpēc nobriedušā Salesforce nepārtrauktības plānā vajadzētu biznesa procesus sasaistīt ar tehniskajām atkarībām, piešķirt rezerves īpašniekus, definēt drošu atkārtotas mēģināšanas darbību, Salesforce uzticamības uzraudzību uzturēt tuvu incidentu darbplūsmai un pēc pakalpojuma atjaunošanas iekļaut formālu saskaņošanas fāzi. Visnoderīgākais rādītājs nav vienkārši "laiks, līdz Salesforce kļuva zaļš". Tas ir laiks, līdz biznesa process tika pārbaudīts no sākuma līdz beigām un kavējumi tika droši novērsti.
Šī retrospekcija tika sagatavota, izmantojot Salesforce pašu uzticamības un palīdzības ierakstus, un tajā galvenā uzmanība pievērsta atlasītiem incidentiem no 2025. kalendārā gada. Salesforce gada laikā publicēja daudzus citus incidentu paziņojumus, tostarp īsākus un šaurāka tvēruma notikumus. Dažas uzticamības lapas tika atjauninātas pēc sākotnējā notikuma, jo tika precizēti ietekmes periodi un skartie komponenti. Pašreizējā pakalpojuma stāvokļa informācijai izmantojiet Salesforce uzticamības statusu , nevis paļaujieties uz vēsturisku rakstu.
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.
