Otwierasz Salesforce, a funkcja działa wolno, jest niedostępna lub zwraca błąd. Jednocześnie zauważasz raporty o problemie z AWS. Kuszące jest stwierdzenie, że „Salesforce działa na AWS, więc przyczyną musi być AWS”. Czasami może to być trafne stwierdzenie, ale rzeczywista zależność jest bardziej złożona. Salesforce intensywnie korzysta z AWS, szczególnie za pośrednictwem Hyperforce , podczas gdy niektóre środowiska i usługi Salesforce korzystają z innej infrastruktury. Incydent w AWS może zatem wpłynąć na niektóre obciążenia Salesforce, nie powodując jednocześnie awarii wszystkich klientów Salesforce ani wszystkich produktów Salesforce.
Praktyczne pytanie nie dotyczy tylko tego, czy Salesforce korzysta z AWS. Tak. Przydatne pytanie brzmi, która część usługi Salesforce jest hostowana, gdzie jest hostowana, od którego regionu lub usługi AWS jest zależna oraz czy problem dotyczy Salesforce, AWS, Twojej własnej integracji, czy ścieżki sieciowej między nimi . Ten przewodnik wyjaśnia tę zależność, od najprostszych sprawdzeń po bardziej szczegółowe szczegóły architektoniczne, a następnie pokazuje, jak samodzielnie zweryfikować swoją sytuację.
Hyperforce to architektura infrastruktury chmury publicznej firmy Salesforce, służąca do dostarczania aplikacji Salesforce w regionalnych środowiskach chmurowych. Firma Salesforce opisuje Hyperforce jako infrastrukturę stojącą za rozwiązaniem Customer 360 i korzysta z usług dostawców chmury publicznej, aby zwiększyć dostępność regionalną, rezydencję danych, kontrolę bezpieczeństwa i skalowalność.
Według Salesforce, od września 2026 roku Hyperforce jest dostępny w Amazon Web Services w wielu krajach, a także rozszerza się na Google Cloud Platform. To rozróżnienie ma znaczenie: stwierdzenie „Salesforce korzysta z AWS” jest prawdziwe, ale stwierdzenie „każda organizacja Salesforce działa tylko na AWS” już nie. Salesforce nadal obsługuje również część infrastruktury własnej zarządzanej przez Salesforce, a poszczególne usługi mogą działać w infrastrukturze niezależnej od organizacji głównej.
Aktualne wskazówki firmy Salesforce dotyczące lokalizacji infrastruktury są dostępne w Pomocy Salesforce: Gdzie znajduje się moja instancja Salesforce?. Firma Salesforce wyjaśnia również szerszy model Hyperforce w ogólnych informacjach i często zadawanych pytaniach dotyczących Hyperforce firmy Salesforce .
Zależność jest znaczna, ale wielowarstwowa. AWS od lat jest głównym strategicznym dostawcą usług chmurowych dla Salesforce, a AWS opisuje firmy jako posiadające globalne partnerstwo strategiczne. Salesforce korzysta z infrastruktury AWS do wdrożeń Hyperforce, a także zintegrował produkty Salesforce z usługami AWS, takimi jak Amazon Connect i Amazon Bedrock.
Dla klienta pomocne jest podzielenie relacji na trzy warstwy:
| Warstwa | Co zależy od AWS | Co to oznacza operacyjnie |
|---|---|---|
| Warstwa hostingowa Salesforce | Organizacja lub usługa Salesforce może działać w środowisku Hyperforce hostowanym w regionie AWS. | Problem z infrastrukturą regionalną lub bazową AWS może mieć znaczenie dla dostępności Salesforce dla danego hostowanego obciążenia. |
| Warstwa produktu i usługi Salesforce | Niektóre dodatki Salesforce lub usługi pomocnicze mogą działać w AWS niezależnie od głównej organizacji Salesforce. | Funkcja może przestać działać nawet wtedy, gdy podstawowy system CRM działa prawidłowo. |
| Warstwa integracji klienta | Twoja firma może połączyć Salesforce z własnymi obciążeniami AWS, interfejsami API, Amazon Connect, potokami danych lub siecią prywatną. | Problem może dotyczyć konta AWS lub ścieżki sieciowej, nawet jeśli sam Salesforce działa prawidłowo. |
Ten warstwowy model jest kluczem do rozwiązywania problemów. Strona stanu z informacją „Salesforce działa” nie dowodzi, że integracja hostowana w AWS jest prawidłowa. Z kolei ogólne zdarzenie AWS nie dowodzi, że dana instancja Salesforce jest dotknięta problemem.
Salesforce twierdzi, że instancje Hyperforce korzystają z modelu aktywny/aktywny w trzech strefach dostępności w danym regionie. Strefa dostępności (AZ) to odizolowana lokalizacja w regionie AWS. W modelu aktywny/aktywny, wydajność aplikacji działa w wielu strefach, zamiast utrzymywać jedną strefę w stanie bezczynności jako rezerwę zimną. Salesforce twierdzi, że ruch jest rozłożony na aktywne serwery aplikacji we wszystkich trzech strefach, a replikacja bazy danych zapewnia spójność między strefami.
Architektura ta ma na celu zmniejszenie zależności od pojedynczej strefy dostępności. Jeśli problem z jedną strefą dostępności jest lokalny, projekt może umożliwić kontynuację usługi w pozostałych strefach. Architektura wielostrefowa nie eliminuje jednak wszystkich możliwych trybów awarii. Problem z usługą obejmujący cały region, problem z płaszczyzną sterowania, zakłócenia w sieci, błąd oprogramowania, awaria zależności lub incydent na poziomie aplikacji nadal mogą wpływać na dostępność.
Prawidłowy model myślowy jest zatem następujący: Salesforce na platformie AWS został zaprojektowany tak, aby był odporny w obrębie regionu AWS, ale nadal ma zależności infrastrukturalne, które mogą mieć znaczenie podczas większych wydarzeń związanych z platformą AWS .
To właśnie tutaj wiele dochodzeń w sprawie incydentów kończy się niepowodzeniem. Salesforce wyraźnie zaznacza, że niektóre usługi mogą działać na oddzielnej infrastrukturze, integrując się z organizacją klienta. Na przykład dokumentacja Salesforce dla Sales Engagement, Einstein Activity Capture, Salesforce Inbox i Einstein Conversation Insights stwierdza, że usługi te są hostowane w infrastrukturze AWS, odrębnej od infrastruktury Salesforce Core organizacji.
Oznacza to, że użytkownik może zobaczyć taką sytuację:
Firma Salesforce dokumentuje to rozdzielenie w swoich wytycznych dotyczących migracji Hyperforce dla rozwiązań Sales Engagement, Einstein Activity Capture, Salesforce Inbox i Einstein Conversation Insights .
Zacznij od oficjalnego statusu i informacji o zaufaniu Salesforce. Znajdź status swojej konkretnej instancji Salesforce, zamiast polegać na ogólnych raportach, że „Salesforce nie działa”. Salesforce wyjaśnia, jak zidentyfikować instancję organizacji w artykule „ Wyświetlanie informacji o instancji Salesforce dla Twojej organizacji” .
W konfiguracji Salesforce użyj pola Szybkie wyszukiwanie, aby znaleźć Informacje o firmie , a następnie poszukaj pola Instancja . Salesforce zaznacza, że dwuliterowe prefiksy instancji, takie jak AP0, oznaczają infrastrukturę własną zarządzaną przez Salesforce, a trzyliterowe prefiksy, takie jak GBR10, oznaczają infrastrukturę Hyperforce.
Instancja Hyperforce nie jest automatycznie synonimem AWS na zawsze. Salesforce twierdzi, że Hyperforce jest dostępny w AWS i jest rozszerzany na Google Cloud Platform. W dokumentacji firmy klienci, którzy chcą ustalić, czy dana instancja Hyperforce jest dostępna w AWS, czy w GCP, powinni skontaktować się z działem obsługi klienta Salesforce.
Ma to coraz większe znaczenie dla korelacji incydentów. Nie należy mapować „Hyperforce” na „AWS” wyłącznie na podstawie samego słowa.
Jeśli potwierdziłeś, że Twoja organizacja lub usługa Salesforce, której dotyczy problem, działa w AWS, zidentyfikuj region. Aktualna dokumentacja lokalizacji Salesforce zawiera listę regionów Hyperforce i ich dostawców chmury publicznej. Na przykład, Salesforce wymienia regiony Hyperforce obsługiwane przez AWS, takie jak Sydney, Bombaj, Tokio, Singapur, Londyn, Frankfurt, Kanada Centralna i kilka regionów USA.
Następnie porównaj incydent Salesforce z oficjalnymi informacjami AWS Health dotyczącymi danego regionu i usługi. Unikaj traktowania problemu w jednym regionie AWS jako dowodu na istnienie niepowiązanego regionu Salesforce.
Jeśli sam Salesforce działa prawidłowo, sprawdź ścieżkę integracji. Typowe zależności po stronie klienta obejmują bramy API, funkcje Lambda, Amazon Connect, bazy danych, kolejki, prywatne punkty końcowe, sieci VPN, DNS i korporacyjne mechanizmy kontroli sieci. Awaria jednego z tych komponentów może zostać odebrana przez użytkowników jako „problem Salesforce”, ponieważ błąd występuje w ramach przepływu pracy Salesforce.
Przydatnym testem jest zadanie sobie pytania: Czy ta sama operacja Salesforce może się powieść bez wywoływania naszej usługi AWS? Jeśli tak, organizacja główna może być sprawna, podczas gdy ścieżka integracji zawodzi.
Niektóre organizacje korzystają z AWS Direct Connect , prywatnego połączenia sieciowego z AWS, aby spełnić wymagania sieciowe Hyperforce w AWS. Salesforce dokumentuje przypadek użycia routingu określonego ruchu e-mail Hyperforce przez AWS Direct Connect dla organizacji z wymaganiami dotyczącymi prywatnej łączności, zgodności lub rezydencji danych.
Tworzy to kolejną warstwę zależności. W przypadku połączenia prywatnego incydent może wystąpić między użytkownikiem a Salesforce, a nie w samym Salesforce. Odpowiednia dokumentacja Salesforce to: „ Route Email Through AWS Direct Connect for Hyperforce” .
Salesforce opisuje Hyperforce jako rozwiązanie zaprojektowane do działania w wielu dostawcach chmury publicznej. To zmniejsza architektoniczne założenie, że jeden hiperskaler musi być stałym podłożem dla wszystkich obciążeń Salesforce. Dokumentacja Salesforce na rok 2026 podaje, że Hyperforce jest dostępny w AWS, a obsługa Google Cloud Platform jest wprowadzana w wybranych regionach, zgodnie z planem działania Salesforce.
Dla klientów nie oznacza to, że istniejąca organizacja Salesforce automatycznie przełącza się z AWS na Google Cloud podczas awarii AWS. Wsparcie dla wielu chmur dotyczy przede wszystkim tego, gdzie Salesforce może wdrożyć i obsługiwać swoją platformę. Nie należy zakładać przełączania awaryjnego między dostawcami, chyba że Salesforce wyraźnie to udokumentuje dla używanej usługi.
Relacja nie ogranicza się jedynie do hostingu infrastruktury. AWS i Salesforce opisują szersze strategiczne partnerstwo obejmujące dane, sztuczną inteligencję, możliwości contact center, integrację i zaopatrzenie. Oficjalna strona partnerstwa AWS podkreśla integrację produktów Salesforce z technologiami AWS, w tym generatywną sztuczną inteligencję i możliwości zarządzania danymi. Możesz zapoznać się z tą relacją na oficjalnej stronie partnerstwa AWS i Salesforce .
Ma to znaczenie podczas przeglądów architektury, ponieważ pojawiają się dwa różne pytania dotyczące zależności:
Te dwie zależności mają różnych właścicieli, ścieżki monitorowania, procedury odzyskiwania i zespoły wsparcia.
Gdy użytkownicy zgłaszają, że usługa Salesforce jest niedostępna lub częściowo uszkodzona, należy wykonać poniższe sprawdzenia w podanej kolejności:
Wiesz, że Twoja diagnoza staje się silniejsza, gdy dowody pokrywają się na wielu poziomach. Jeśli Salesforce Trust zgłasza incydent dla konkretnej instancji, a dotknięta nim funkcja pasuje do objawów, to Salesforce jest silnie uwikłany. Jeśli Salesforce działa prawidłowo, ale testy integracji z AWS zakończą się niepowodzeniem w tym samym czasie, lepszym tropem jest zależność od AWS po stronie klienta. Jeśli problem dotyczy tylko jednego dodatku Salesforce, podczas gdy podstawowe funkcje CRM działają prawidłowo, zbadaj oddzielną infrastrukturę i status tej usługi.
Nie zatrzymuj się na stwierdzeniach „AWS miał awarię” lub „Salesforce sprawdził awarię”. Pewną odpowiedź znajdziesz, dopasowując swoją instancję, produkt, region i ścieżkę integracji .
Salesforce jest silnie zależny od AWS, zwłaszcza że wiele wdrożeń Hyperforce i usług wspierających działa w oparciu o infrastrukturę AWS. Zależność ta nie jest jednak uniwersalna ani jednowymiarowa. Salesforce obsługuje również infrastrukturę własną, rozszerza Hyperforce na wielu dostawców chmury publicznej i może hostować poszczególne usługi niezależnie od głównej organizacji klienta.
Dla zespołów operacyjnych najlepszym rozwiązaniem jest traktowanie Salesforce i AWS jako grafu zależności, a nie pojedynczego stosu. Należy zidentyfikować, gdzie działa organizacja główna, zmapować oddzielnie hostowane usługi Salesforce, udokumentować każdą zarządzaną przez klienta integrację z AWS i monitorować każdą warstwę niezależnie. To znacznie przyspiesza proces od komunikatu „Salesforce nie działa” do konkretnego komponentu, który faktycznie wymaga uwagi.
Inwestycje w CCUS rosną, ale czy wychwytywanie dwutlenku węgla może odwrócić globalne emisje? Zobacz, gdzie to działa, jakie są ograniczenia skali i jakie dowody są istotne.
Compare seven global programs for digital supply chains, logistics, analytics, global trade, and operations, with practical guidance on choosing the right fit.
Dowiedz się, w jaki sposób interfejsy mózg-komputer dekodują sygnały neuronowe, aby przywrócić komunikację i ruch, jakie są osiągnięcia ostatnich badań i co nadal ogranicza stosowanie BCI.
Zobacz, w jaki sposób komercyjne drony łączą w sobie czujniki, sztuczną inteligencję, baterie, komunikację i oprogramowanie do sterowania lotem, a także dowiedz się, w jakim zakresie autonomia nadal zależy od misji i regulacji.
Porównaj siedem solidnych opcji studiów magisterskich z zakresu akumulatorów i magazynowania energii pod kątem materiałów, systemów, badań, znajomości branży, elastyczności, języka i kompromisów w zakresie kosztów.
Dowiedz się, w jaki sposób masa ładunku, ograniczenia akumulatora, pogoda, wydajność napędu i architektura statku powietrznego wpływają na wytrzymałość przemysłowych bezzałogowych statków powietrznych — i jak ją poprawić.
Porównaj wiodące programy inżynierii biomedycznej dla inteligentnych urządzeń medycznych, obejmujące projektowanie, bioelektronikę, sztuczną inteligencję, cyberbezpieczeństwo, szkolenia kliniczne i regulacje.
Stwórz praktyczny plan ciągłości przestoju Salesforce z jasnymi priorytetami, zapasowymi przepływami pracy, kontrolami odzyskiwania, kryteriami testowania i realistycznymi ograniczeniami.
Problemy z StoreForce mogą zakłócać harmonogramy, ewidencję czasu pracy, zmiany zmian i komunikację w sklepie. Dowiedz się, jak zdiagnozować problem, utrzymać płynność operacji w sklepie i zweryfikować proces odzyskiwania danych.
Dowiedz się, jak skontaktować się z pomocą techniczną Salesforce w przypadku poważnej awarii, wybierz odpowiedni kanał, przygotuj przydatny przypadek i podejmij działania następcze, nie tworząc przy tym duplikatów zgłoszeń.
