Czym jest opóźnienie SaaS?

Opóźnienie SaaS odnosi się do czasu, który upływa od momentu rozpoczęcia zadania przez użytkownika do dostarczenia wyniku przez aplikację SaaS (w tym opóźnienia sieciowe i czas przetwarzania aplikacji). Szybkość ładowania, czasy odpowiedzi API, responsywność pulpitu nawigacyjnego i czas trwania realizacji przepływu pracy wpływają na doświadczenie użytkownika.

Zaobserwowane opóźnienia mogą korelować z określonymi charakterystykami sieci i przetwarzania.

•   Aspekty sieciowe: Czynniki takie jak odległość sieciowa, przeciążenie ruchu i sama fizyczna odległość między użytkownikami a serwerami.
•   Aspekty aplikacji: Może to obejmować takie czynniki jak jakość kodu aplikacji, szybkość zapytań do bazy danych oraz wydajność wywołań API stron trzecich.
•   Aspekty infrastruktury: Należy wziąć pod uwagę pojemność infrastruktury chmurowej, zużycie zasobów przez mikroserwisy oraz złożoność architektury.

Obserwowane poziomy opóźnień mogą korelować ze zmianami w produktywności użytkowników i przychodach firmy.

1. Produktywność użytkownika: Szybkość aplikacji może wpływać na zadowolenie i produktywność użytkownika.
2. retencję: Istnieje związek między poziomami opóźnień a dalszym korzystaniem z produktu. Porzucenie aplikacji przez użytkowników mobilnych i czas ładowania strony mogą być powiązane, a ta zależność może być bardziej widoczna po 3 sekundach.
3. Biznesowe KPI: Opóźnienie powinno mieć bezpośredni wpływ na następujące metryki:

•   Wskaźniki konwersji.
•   Wskaźniki odnowienia.
•   Czasy ukończenia zadań.
•   Liczba zgłoszeń do wsparcia.

Wykorzystanie wielu strategii monitorowania może zapewnić szeroką perspektywę na stan wydajności.

Modyfikacje w infrastrukturze i projekcie oprogramowania mogłyby wpłynąć na optymalizację.

1. Modyfikacje w bazach danych i kodzie aplikacji mogłyby zostać zaimplementowane.
2. Wykorzystaj Sieci Dostarczania Treści (CDN) i buforuj często dostępne dane.
3. Kompresuj zasoby i zmniejsz liczbę wywołań API.
4. Skalowanie infrastruktury i uproszczenie architektury można rozważyć.
5. Nadaj priorytet ścieżkom użytkownika o największym ruchu, takim jak logowania i ładowanie paneli kontrolnych.

Czynniki środowiskowe niezależne od zarządzania dostawcy SaaS mogą korelować z poziomami zadowolenia użytkowników.

•   Środowisko użytkownika: Gdzie znajduje się użytkownik, jakiego rodzaju urządzenia używa i jaką przeglądarkę preferuje.
•   Routing sieciowy: Ścieżka, przez którą Dostawca Usług Internetowych (ISP) przesyła dane, oraz ogólne przeciążenie Internetu.
•   Integracje: Usługi stron trzecich połączone z aplikacją SaaS.
•   Weryfikacja rzeczywistości: Chociaż aplikacja jest zoptymalizowana, użytkownicy geograficznie oddaleni od centrum danych mogą zauważyć pewne opóźnienia.

Systematyczne rozwiązywanie problemów pomaga ustalić, czy opóźnienie ma charakter lokalny, regionalny, czy obejmuje całą platformę.

1. Określ zakres problemu, badając, czy występuje on na pojedynczym urządzeniu, w przeglądarce, sieci, regionie, czy też w konkretnym segmencie przepływu pracy.
2. Sprawdź dane RUM i testy syntetyczne razem, aby odkryć, czy problem ma charakter lokalny, regionalny, czy obejmuje całą platformę.
3. Użyj APM i rozproszonego śledzenia, aby zlokalizować źródło (Frontend, API, Baza Danych lub podmiot zewnętrzny).
4. Przeprowadź testy, zmieniając sieci, sprawdzając strony statusowe dostawców i pozyskując dane o wydajności z różnych regionów.

Dostarczenie powtarzalnych dowodów może pomóc zespołowi wsparcia w zrozumieniu zgłoszonego problemu. Oto kilka kroków, aby to zrobić:

1. Udokumentuj problem ze znacznikiem czasu i dołącz zrzuty ekranu, aby przedstawić dodatkowy kontekst.
2. Wykonaj kilka testów lokalizacji, aby upewnić się, że problem nie leży po Twojej stronie.
3. Odwiedź stronę dostawcy statusu, aby sprawdzić wszelkie incydenty zarejestrowane w ich systemie.
4. Przekazanie zespołowi wsparcia Twojego zgłoszenia, wraz z dowodami, może pomóc im w odtworzeniu problemu, którego doświadczasz.
5. Poproś o identyfikatory incydentów, szacowany czas realizacji i aktualizacje dotyczące przyczyn źródłowych.
6. Nie zapomnij wspomnieć o SLA/SLO które odnoszą się do takich zobowiązań w przypadku aplikacji krytycznych dla biznesu.