Na stronie statusu jest napisane, że wszystko działa. Twój APM pokazuje kolor zielony. Tymczasem klient w Singapurze nie może się zalogować. Potencjalny klient z Brazylii porzucił rejestrację. Transakcja korporacyjna w Niemczech nie doszła do skutku, ponieważ „przekroczono limit czasu wersji demonstracyjnej.”
Globalne monitorowanie czasu pracy dla SaaS nie jest opcjonalne — pozwala zobaczyć, czego faktycznie doświadczają Twoi klienci.
Stworzyłeś solidny produkt. Infrastruktura jest na AWS lub GCP. Używasz Cloudflare lub Fastly. Masz podstawowe monitorowanie czasu pracy — prawdopodobnie sprawdzasz je w jednej lub dwóch lokalizacjach co kilka minut.
Następnie zaczniesz otrzymywać zgłoszenia pomocy technicznej z określonych regionów. „Nie można uzyskać dostępu do aplikacji”. „Logowanie ciągle kończy się niepowodzeniem.” „Strony nie ładują się.” Sprawdzasz swój pulpit nawigacyjny – wszystko wygląda dobrze. Prosisz ich, aby spróbowali ponownie — czasem się udaje, czasem nie.
Odrzucasz to jako błąd użytkownika, problemy z siecią po jego stronie lub problemy przejściowe. Ale biletów wciąż przybywa. I zdajesz sobie sprawę: nie masz możliwości sprawdzenia, czego tak naprawdę doświadczają użytkownicy w Singapurze, São Paulo czy Johannesburgu.
Twoje monitorowanie okłamuje Cię – nie celowo, ale przez zaniechanie. Sprawdzanie z jednego miejsca i zakładanie, że reprezentuje to cały świat.
W tym miejscu globalne monitorowanie czasu pracy SaaS staje się krytyczne. Nie jako coś, co warto mieć, ale jako jedyny sposób, aby dowiedzieć się, czy Twój produkt jest rzeczywiście dostępny dla klientów, do których próbujesz dotrzeć.
Internet nie jest jednolity. Żądanie z Tokio do Twojego pochodzenia w USA-Wschód przechodzi przez zupełnie inną infrastrukturę niż żądanie z Londynu.
DNS nie jest natychmiastowy ani uniwersalny. Jeśli najbliższy użytkownikowi węzeł anycast Twojego dostawcy DNS jest przeciążony, źle skonfigurowany lub nieosiągalny, użytkownik ten nie może rozpoznać Twojej domeny – nawet jeśli Twoje serwery działają prawidłowo. Różne programy rozpoznawania nazw DNS mogą zwracać różne wyniki, a niektóre mogą buforować nieaktualne lub nieprawidłowe rekordy.
Prawdziwy scenariusz: główny dostawca usług DNS w chmurze miał 4-godzinną awarię, która dotknęła tylko serwery nazw w regionie Azji i Pacyfiku. Produkty SaaS korzystające z tego dostawcy wykazały 100% czasu sprawności w monitorowaniu w USA, będąc jednocześnie całkowicie offline dla 2 miliardów potencjalnych użytkowników.
Trasy BGP mogą bez ostrzeżenia ulec zmianie, przerwaniu lub stać się nieoptymalne. Wyciek trasy, źle skonfigurowana ścieżka AS lub awaria dostawcy usług tranzytowych mogą sprawić, że Twoje serwery będą nieosiągalne z całych krajów, a jednocześnie będą doskonale dostępne z innych krajów. Problemy te zdarzają się regularnie i mogą utrzymywać się przez wiele godzin.
Prawdziwy scenariusz: główny dostawca usług internetowych w Brazylii błędnie skonfigurował swój routing, przez co cały ruch do usługi SaaS z siedzibą w USA był kierowany przez Europę, zanim trafił do USA. Opóźnienie wzrosło ze 120 ms do 800 ms – funkcjonalne, ale zbyt wolne w przypadku funkcji czasu rzeczywistego.
Twoja sieć CDN ma setki lokalizacji brzegowych, ale nie wszystkie są zawsze sprawne. Przewaga w Dżakarcie może spaść, podczas gdy przewaga w Singapurze jest w porządku. Strona stanu CDN może nie odzwierciedlać degradacji regionalnej, a użytkownicy kierowani do problematycznej krawędzi mogą doświadczać awarii lub ekstremalnego spowolnienia.
Prawdziwy scenariusz: Krawędź CDN w São Paulo obsługiwała błędy 502 przez 6 godzin z powodu problemu z konfiguracją zaplecza. Globalny status CDN pokazał „Operacyjny”, ponieważ 95% krawędzi było w porządku. Brazylijscy użytkownicy uznali SaaS za całkowicie zepsuty.
Główni dostawcy usług internetowych mają ustalenia dotyczące peeringu, które wpływają na przepływ ruchu. Jeśli punkt równorzędny między regionalnym dostawcą usług internetowych a dostawcą usług w chmurze jest przeciążony lub doświadcza utraty pakietów, użytkownicy tego dostawcy usług internetowych będą mieli ograniczony dostęp do Twojej usługi SaaS — nawet jeśli użytkownicy innego dostawcy usług internetowych w tym samym mieście nie będą mieli żadnych problemów.
Prawdziwy scenariusz: duży indyjski dostawca usług internetowych wdał się w spór dotyczący peeringu z amerykańskim dostawcą usług w chmurze, który trwał 3 tygodnie. Użytkownicy tego dostawcy usług internetowych doświadczyli czasu ładowania przekraczającego 5 sekund. Firma SaaS straciła znaczny udział w rynku indyjskim, zanim w ogóle zorientowała się, że istnieje problem.
Główny problem: wszystkie te awarie są specyficzne dla lokalizacji. Twoja infrastruktura działa. Twój kod jest w porządku. Jednak gdzieś pomiędzy Twoimi serwerami a użytkownikami w określonych regionach coś jest uszkodzone — a jedynym sposobem na wykrycie tego jest sprawdzenie, skąd faktycznie znajdują się ci użytkownicy.
Większość narzędzi do monitorowania czasu pracy została zbudowana z myślą o prostszej epoce — kiedy „serwer odpowiada?” było wystarczającym pytaniem. W przypadku SaaS z użytkownikami globalnymi to już nie wystarczy.
Wiele konfiguracji monitorowania SaaS sprawdza od 1 do 5 lokalizacji, często skupionych w USA i Europie. Jeśli Twoi użytkownicy znajdują się w regionie APAC, LATAM, Bliskiego Wschodu lub Afryki, nie masz żadnego wglądu w ich doświadczenia. Regionalna awaria po prostu nie zostanie zarejestrowana.
Przeprowadzanie kontroli z regionów AWS do infrastruktury hostowanej przez AWS korzysta ze zoptymalizowanej łączności szkieletowej chmury. Prawdziwi użytkownicy w sieciach domowych lub korporacyjnych pokonują zupełnie inne ścieżki z różnymi trybami awarii.
Twój SaaS może technicznie odpowiedzieć, ale załadowanie może zająć 15 sekund. Prosta kontrola HTTP 200 mówi „w górę” – ale dla użytkowników faktycznie jest to w dół. Bez progów opóźnień na region pomijasz powolne awarie, które frustrują użytkowników.
Kiedy nastąpi awaria regionalna, musisz wiedzieć: Czy to DNS? Czy to ścieżka sieciowa? Czy upłynął limit czasu uzgadniania TLS? Bez śledzenia trasy, MTR i analizy opóźnień nie można zdiagnozować pierwotnej przyczyny ani dostarczyć dowodów swojemu dostawcy usług hostingowych.
Kiedy monitorujesz tylko z kilku lokalizacji, widzisz tylko ułamek tego, czego doświadczają Twoi użytkownicy. Reszta to martwy punkt, w którym awarie zdarzają się niezauważone.
Z każdą minutą, w której Twój SaaS jest niedostępny w danym regionie, tracisz użytkowników, przychody i reputację — często nawet o tym nie wiedząc.
Użytkownicy, którzy nie mają dostępu do Twojego SaaS, nie zawsze narzekają — odchodzą. Jeśli użytkownik wersji próbnej ulegnie awarii podczas pierwszej sesji, przepadnie. Jeśli płacący klient doświadcza powtarzających się problemów, zaczyna szukać alternatyw. Zobaczysz zmianę wskaźników, ale nie będziesz wiedział, że jest to spowodowane regionalnymi problemami z dostępnością.
Twój marketing generuje ruch z całego świata. Jeśli proces rejestracji jest zakłócony lub niemożliwie powolny w określonych regionach, ruch ten ulega odbiciu. Zapłaciłeś za przejęcie, ale konwersja nie powiodła się z powodu problemu regionalnego, o istnieniu którego nie miałeś pojęcia. CAC rośnie; LTV spada.
Google indeksuje z wielu lokalizacji na całym świecie. Jeśli Googlebot napotka powolne reakcje lub awarie w niektórych regionach, ma to wpływ na wyniki Core Web Vitals, częstotliwość indeksowania, a ostatecznie na rankingi na tych rynkach. Twój ruch organiczny spada w niektórych krajach i nie masz pojęcia dlaczego.
Wieść się rozprzestrzenia. „Ten SaaS jest zawodny w regionie APAC”. „Wypróbowaliśmy je, ale aplikacja w naszym biurze w Berlinie nigdy nie ładuje się prawidłowo”. Recenzje G2, wątki na Twitterze i pogawędki społeczności Slack kształtują postrzeganie w sposób trudny do odwrócenia. Zanim dowiesz się o problemie, szkody zostaną już wyrządzone.
Skuteczne globalne monitorowanie czasu pracy wymaga różnorodności geograficznej, dogłębnej diagnostyki i odpowiednich progów ostrzegania.
Zasięg nie zależy tylko od ilości — chodzi o dopasowanie do lokalizacji geograficznej użytkowników. Jeśli masz użytkowników w Azji Południowo-Wschodniej, potrzebujesz węzłów w Singapurze, Dżakarcie, Bombaju, Tokio i Sydney. Jeśli kierujesz reklamy na Amerykę Łacińską, potrzebujesz São Paulo, Buenos Aires, Meksyk. Każda lokalizacja charakteryzuje się innymi warunkami sieciowymi.
Mapuj lokalizacje monitorowania tam, gdzie znajdują się Twoi płacący klienci.
Kiedy wystąpi awaria, musisz wiedzieć, gdzie na ścieżce sieciowej wystąpiła awaria. Czy chodzi o rozpoznawanie DNS? Konkretny przeskok sieciowy? Twoja krawędź CDN? Dane Traceroute i MTR z dotkniętego regionu dostarczają dowodów pozwalających zdiagnozować pierwotną przyczynę i skutecznie przekazać ją dostawcom.
Dane diagnostyczne zamieniają stwierdzenie „gdzieś jest” w „dokładnie dlaczego”.
Czy czas reakcji 300 ms z Tokio jest normalny, czy też uległ pogorszeniu? Bez danych historycznych nie można tego stwierdzić. Ciągłe monitorowanie tworzy wartości bazowe dla poszczególnych lokalizacji, dzięki czemu można ostrzegać o odchyleniach od normy — wychwytywać powolne degradacje, zanim staną się przestojami, i odróżniać rzeczywiste problemy od jednorazowych chwilowych zakłóceń.
Linie bazowe pozwalają ostrzegać o „gorszym niż zwykle” – a nie tylko o „pogorszeniach”.
Przewodnik krok po kroku dotyczący wdrażania monitorowania, które faktycznie wychwytuje regionalne awarie.
Przejrzyj statystyki, aby zidentyfikować 20 krajów z największą liczbą aktywnych użytkowników i przychodów. Sprawdź, skąd pochodzą rejestracje, skąd konwersje z wersji próbnych i skąd pochodzą przychody z ekspansji. Są to regiony, z których należy monitorować.
Nie każdy punkt końcowy wymaga globalnego monitorowania. Skoncentruj się na: głównym adresie URL aplikacji, punktach końcowych logowania/uwierzytelniania, procesie rejestracji, punktach końcowych API używanych przez klientów oraz wszelkich stronach publicznych kluczowych dla SEO i konwersji.
Wybierz usługę monitorowania o szerokim zasięgu geograficznym — co najmniej 50 lokalizacji na wszystkich kontynentach. Upewnij się, że zasięg odpowiada Twojej lokalizacji geograficznej użytkownika. Ustaw interwały sprawdzania na 1 minutę dla krytycznych punktów końcowych; 5 minut dla stron dodatkowych.
Nie ostrzegaj tylko o awariach — ostrzegaj, gdy czas reakcji przekracza akceptowalne progi. W przypadku SaaS należy wziąć pod uwagę: <1 s dla strony logowania, <2 s dla ładowania pulpitu nawigacyjnego, <500 ms dla wywołań API. W przypadku odległych lokalizacji konieczne może być nieco wyższe progi regionalne.
Skonfiguruj alerty uruchamiane w przypadku awarii lub degradacji określonych regionów. Kieruj alerty regionalne o wysokim priorytecie do inżynierów na wezwanie. Zintegruj się ze Slackiem, PagerDuty lub istniejącym przepływem pracy związanym z zarządzaniem incydentami.
Upewnij się, że na żądanie możesz uruchomić programy Traceroute i MTR z dowolnej lokalizacji monitorowania. Po uruchomieniu alertu będziesz potrzebować natychmiastowych danych diagnostycznych, aby określić, czy problemem jest DNS, routing sieciowy, CDN czy pochodzenie.
Ustaw cykliczne przypomnienie w kalendarzu, aby sprawdzić regionalne trendy dotyczące czasu pracy i opóźnień. Poszukaj powolnych degradacji, które nie wywołały alertów, regionów o stale wyższych opóźnieniach i wzorców, które korelują ze skargami użytkowników lub danymi o rezygnacji.
Udokumentuj, co zrobić w przypadku wykrycia regionalnej awarii: jak zweryfikować problem, z kim się skontaktować w Twojej sieci CDN lub u dostawcy usług hostingowych, jakie dane diagnostyczne należy zebrać i jak poinformować o stanie klientów, których to dotyczy.
Latency Global został stworzony specjalnie z myślą o globalnej widoczności, jakiej potrzebują produkty SaaS. Monitorujemy z ponad 70 rzeczywistych lokalizacji na 6 kontynentach — obejmując każdy większy region, w którym mogą przebywać Twoi użytkownicy.
Każde sprawdzenie obejmuje pełny podział czasu (DNS, TCP, TLS, TTFB), a podczas badania problemów możesz uruchomić programy Traceroute i MTR z dowolnego miejsca. Dane historyczne pokazują trendy w poszczególnych regionach, dzięki czemu można wykryć degradacje, zanim staną się przestojami. Cena jest prosta: 5 USD/miesiąc za 5 monitorów z dostępem do wszystkich lokalizacji.
Globalne monitorowanie wymaga dużej infrastruktury — dlatego większość narzędzi kosztuje 50–500 USD miesięcznie. Zapewniamy jego dostępność dla SaaS na wczesnym etapie, skupiając się na tym, co najważniejsze: zasięgu geograficznym i głębokości diagnostycznej.
Produkty SaaS zazwyczaj obsługują użytkowników na całym świecie, a nie tylko z jednego miejsca geograficznego. W przeciwieństwie do tradycyjnego oprogramowania lokalnego, Twój SaaS musi być dostępny z dowolnego miejsca, w którym znajdują się Twoi klienci. Awarie regionalne — spowodowane problemami z DNS, problemami z routingiem BGP, awariami CDN lub problemami z peeringiem ISP — mogą sprawić, że Twój produkt będzie niedostępny dla całych rynków, a jednocześnie będzie wyglądał na w pełni sprawny z Twojej lokalizacji monitorowania. Globalne monitorowanie czasu pracy to jedyny sposób, aby zobaczyć, czego faktycznie doświadczają Twoi międzynarodowi użytkownicy.
Zależy to od lokalizacji geograficznej użytkownika, ale ponad 50 lokalizacji to dobry punkt odniesienia dla kompleksowego zasięgu. Kluczem jest zapewnienie monitorowania w każdym regionie, w którym masz znaczących użytkowników lub przychody. Jeśli 15% ARR pochodzi z regionu APAC, potrzebujesz wielu węzłów w regionie Azji i Pacyfiku. Jeśli rozszerzasz działalność na Amerykę Łacińską, potrzebujesz węzłów w Brazylii, Argentynie i Meksyku. Dopasuj zakres monitorowania do znaczenia biznesowego, a nie tylko liczby użytkowników.
Pulpity nawigacyjne CDN i dostawców usług w chmurze pokazują widok wewnętrzny – który często jest ograniczony. Mogą pokazywać, że „wszystkie systemy działają”, podczas gdy użytkownicy w określonych regionach doświadczają awarii z powodu problemów z równorzędnością, problemów z routingiem BGP lub degradacji na poziomie brzegowym, które nie są rejestrowane jako pełne przestoje. Niezależne monitorowanie spoza infrastruktury pozwala uzyskać podstawową wiedzę na temat tego, czego faktycznie doświadczają użytkownicy końcowi, a która często różni się od tego, co pokazują pulpity dostawców.
Obydwa, priorytetowo ze względu na wpływ na biznes. Zacznij od: (1) adresu URL/pulpitu nawigacyjnego głównej aplikacji, (2) punktów końcowych logowania/uwierzytelniania, (3) przepływu rejestracji, (4) punktów końcowych API używanych przez klientów, (5) strony głównej witryny marketingowej. W przypadku SaaS przepływ uwierzytelniania jest szczególnie krytyczny — jeśli użytkownicy nie mogą zalogować się z regionu, nie mogą korzystać z Twojego produktu. Punkty końcowe interfejsu API mają znaczenie, jeśli masz platformę integracyjną lub klientów korzystających z Twojego interfejsu API.
Dzięki 1-minutowym interwałom kontrolnym możesz wykryć awarie w ciągu 1–2 minut. Alarmowanie powinno nastąpić natychmiast po potwierdzeniu awarii (zwykle po 2–3 kolejnych awariach, aby uniknąć alarmowania w przypadku przejściowych sygnałów dźwiękowych). W przypadku krytycznych punktów końcowych na głównych rynkach chcesz uzyskać informację w ciągu 5 minut od rozpoczęcia przestoju. Im szybciej wykryjesz, tym szybciej możesz zdiagnozować i złagodzić skutki — lub przynajmniej poinformować o stanie dotkniętych klientów.
Nawet jeśli problem ma charakter nadrzędny, monitorowanie zapewnia: (1) dowody na istnienie problemu (nie można naprawić tego, czego nie można udowodnić), (2) dane diagnostyczne (traceroute, MTR) umożliwiające identyfikację konkretnego dostawcy lub powodującego problemy przeskoku, (3) dokumentację umożliwiającą skuteczną eskalację do Twojej sieci CDN lub dostawcy usług hostingowych oraz (4) dane informujące, czy należy dodać redundancję, zmienić dostawcę lub dodać lokalizacje brzegowe w dotkniętych regionach. Wiedza o problemie jest pierwszym krokiem do złagodzenia jego skutków.
Przestań się zastanawiać, czy Twój SaaS jest rzeczywiście dostępny w Singapurze, São Paulo lub Sydney. Dodaj punkty końcowe, wybierz lokalizacje monitorowania i zobacz, czego faktycznie doświadczają użytkownicy na całym świecie — zanim Ci o tym powiedzą.
5 USD/miesiąc • Ponad 70 lokalizacji (+40 więcej wkrótce) • Brak umów • Anuluj w dowolnym momencie