Jak Salesforce skrócił rollback globalny z 12h do 10 minut

W świecie, gdzie cztery dziewiątki dostępności oznaczają roczny budżet awaryjny liczony w minutach, Salesforce zbudował mechanizm pozwalający cofnąć globalną wersję oprogramowania w 10 minut, mimo że obsługuje 1,5 biliona requestów miesięcznie (Salesforce). To poziom operacyjny, który rzadko widać w enterprise SaaS, a który ma bezpośrednie implikacje także dla polskich orgów korzystających z Hyperforce. Ten artykuł pokazuje, jak Salesforce przebudował Edge – swoją globalną warstwę perymetru – żeby rollback był zmianą ścieżki ruchu, a nie wielogodzinnym redeployem. I co ważniejsze: jak te lekcje można zastosować w architekturze integracji i CI/CD wokół Salesforce w Polsce.

Globalna architektura perymetru – dlaczego rollback musi być natychmiastowy

Salesforce Edge działa jako jednolity front door dla ruchu przychodzącego do Salesforce Core – ponad 21 punktów na świecie, wpiętych wprost w ścieżkę danych. To oznacza, że każda degradacja Edge natychmiast wpływa na dostęp klientów do aplikacji. Dlatego zespół Edge prowadzi usługę jako jeden globalny perymetr, a nie zestaw niezależnych regionów. Taki model upraszcza control plane i ujednolica zabezpieczenia, ale narzuca ekstremalne wymagania na procesy releasowe.

Do niedawna rollback był powolnym, sekwencyjnym procesem obejmującym region po regionie. Każdy cluster EKS potrzebował minut na uruchomienie podów, a pipeline wdrożeniowy działał z opóźnieniem. W efekcie cofnięcie wersji globalnie zajmowało nawet 12 godzin. Z perspektywy SRE to czas nieakceptowalny, bo jedna błędna aktualizacja mogła wyczerpać roczny budżet dostępności. To właśnie ten problem doprowadził do decyzji o pełnym wdrożeniu blue-green w skali globalnej.

Dla zespołów w Polsce zajmujących się CRM i integracjami oznacza to jedno: jeśli fundament aplikacji działa w trybie zero-wait rollback, to lokalne integrowanie z Salesforce również musi uwzględniać scenariusze nagłej zmiany ścieżki ruchu. W szczególności dotyczy to reverse proxy, CDN, i aplikacji budowanych na Heroku lub Kubernetes, które często nie mają wdrożonych podobnych mechanizmów.

Trend jest jasny – globalne SaaS-y zmierzają do architektury rollback-first, czyli projektowania systemów tak, aby odwrócenie wersji było operacją routingową, a nie compute-heavy redeployem. To standard, który w najbliższych latach stanie się wymogiem również dla systemów integracyjnych wokół CRM.

Jak działa blue-green na Kubernetes w skali 21 globalnych PoP

Salesforce początkowo rozważał gotowe narzędzia, takie jak Argo, ale natrafił na fundamentalny problem: Argo zakłada przełączanie ruchu na warstwie L7, tymczasem Edge jest tą warstwą. Argo nie wspiera też jednoczesnego utrzymania dwóch pełnoskalowych globalnych flot. To ryzyko sprawiło, że zespół Edge zdecydował się zaimplementować własny, natywny model blue-green na samym Kubernetes.

Kluczowy element to utrzymanie dwóch równoległych deploymentów – blue i green – zawsze w tej samej skali. Oba działają w pełnej gotowości, ale tylko jeden jest aktywny dzięki labelom Kubernetes Service. Normalnie HPA skalowałby je niezależnie. Salesforce musiał więc zmodyfikować algorytm autoskalowania tak, by HPA brał pod uwagę najwyższe zużycie CPU między obiema flotami i wymuszał identyczną liczbę podów po obu stronach.

Taki mechanizm gwarantuje pełną symetrię obciążenia – po przełączeniu labela ruch może przejść na flotę standby bez jakiegokolwiek ryzyka throttlingu. Dla praktyków Salesforce warto zauważyć podobieństwo do architektury zero-copy w Data 360, gdzie również chodzi o symetryzację ruchu między wieloma warstwami danych. W artykule o architekturze Customer Zero mechanizm redukcji kosztów operacyjnych przez zachowanie pełnej gotowości wielu instancji jest prezentowany w nieco innym, ale podobnym duchu.

Pod kątem lokalnych zespołów DevOps ważna jest lekcja: HPA out-of-the-box nie rozumie zaawansowanych wzorców deploymentu. Jeśli system wymaga natychmiastowego failbacku, trzeba projektować logikę scalingu ręcznie. Dotyczy to również aplikacji, które integrują się z Salesforce i pracują pod dużym obciążeniem, np. real-time ETL czy event processing.

Zarządzanie ruchem i wymuszone drainowanie połączeń TCP

Sama zmiana labela Service nie wystarczy, gdy mówimy o ruchu TCP utrzymującym się godzinami. W systemach perymetru klient i upstream mogą trzymać połączenie bardzo długo. Salesforce musiał więc wprowadzić wymuszony, kontrolowany drain. Po przełączeniu ruchu, uruchamiany jest job Kubernetes łączący się przez mTLS do każdego poda i wysyłający polecenie drenażu połączeń.

Dzięki temu istniejące kanały TCP zamykają się w sposób kontrolowany, co wymusza natychmiastowe ponowne zestawienie połączenia z aktywną flotą. Ten proces zapewnia konwergencję ruchu w minutach, a nie w godzinach. To właśnie mechanizm, który sprawia, że rollback globalny trwa 10 minut – bo nie czeka na naturalne wygaszenie połączeń.

Praktyczne implikacje dla zespołów pracujących z integracjami są jasne: systemy obsługujące webhooki, streaming API lub middleware pośredniczące między Salesforce a systemami ERP powinny mieć podobny sposób obsługi reconnectów. W polskich wdrożeniach nadal często dominuje założenie, że połączenia będą stabilne lub że timeouty naturalnie rozwiążą problem. W kontekście architektur opartych o eventy i streaming (np. Platform Events, Change Data Capture), jest to już zbyt naiwne.

Przypomina to też wnioski z analizy awarii USA26, opisanej w analizie awarii infrastruktury Salesforce, gdzie długotrwałe połączenia okazały się jednym z czynników utrudniających szybkie odtworzenie ruchu. Salesforce Edge pokazuje, że ręczny drain jest jedynym skutecznym sposobem na przewidywalne operacje rollback.

Operowanie w czterech dziewiątkach i lekcje dla polskich architektów

Przy SLA na poziomie 99.99 procent budżet awarii wynosi około 52 minuty rocznie. To oznacza, że każdy incydent musi być gaszony natychmiast. Salesforce opisuje przypadek, w którym dzięki nowemu modelowi udało się zatrzymać eskalację z SEV-1 do SEV-0 właśnie dlatego, że rollback trwał 10 minut zamiast kilku godzin (źródło: Salesforce). To nie jest trik operacyjny – to zmiana w filozofii, w której rollback jest priorytetową ścieżką, a nie ostatecznością.

Ta logika jest coraz bardziej potrzebna również w polskich orgach. Wraz z rosnącą adopcją agentowych integracji, real-time processing i AI-driven automations, coraz więcej aplikacji działa w modelu always-on i wymaga odporności na błędne releasy. W artykule o automatyzacji incident response z Agentforce pokazujemy, że w AI-era szybkość reakcji ma wartość krytyczną.

Dla architektów oznacza to konieczność wprowadzenia kilku zasad: rollback musi być automatyczny, zdefiniowany jako operacja sieciowa; integracje muszą być projektowane do natychmiastowego reconnectu; a systemy CI/CD nie mogą zakładać, że rozgrzewanie klastra jest akceptowalne podczas incydentu. W praktyce wiele zespołów będzie musiało zrewidować własne procesy deploymentu, bo standard wyznaczony przez Edge stanie się wkrótce oczekiwaniem klientów również wobec rozwiązań budowanych wokół Salesforce.

To kierunek zgodny z globalnym trendem SRE: systemy powinny szybciej zawracać, niż naprawiać. I to właśnie Salesforce pokaże w nadchodzących latach, przenosząc podobne mechanizmy również do warstw usług aplikacyjnych.

Podsumowanie

Rollback w 10 minut przy 1,5 biliona requestów miesięcznie nie jest ciekawostką techniczną, tylko sygnałem, jak będzie wyglądać architektura enterprise SaaS w najbliższej dekadzie. Salesforce pokazuje, że skalowalność i bezpieczeństwo zaczynają się w warstwie perymetru, a kluczem jest projektowanie systemów tak, aby każde odwrócenie zmian było operacją routingową. Dla polskich zespołów Salesforce to dobry moment, by sprawdzić, czy lokalne procesy deploymentu i integracji są gotowe na szybkie, deterministyczne rollbacki. Jeśli nie – to właśnie tu jest największa dźwignia odporności na awarie.