Wstęp
Użytkownicy otwierają je na starych urządzeniach, w słabych sieciach komórkowych, w publicznych sieciach Wi-Fi, w roamingu i przy niskim poziomie baterii. Przełączają aplikacje w połowie aplikacji. Tracą sygnał w windach. Mimo to oczekują, że saldo, kontrola kart, przelewy, powiadomienia i wsparcie będą działać szybko.
Nie oznacza to jednak, że każda funkcja powinna działać w pełni offline. W bankowości wiele czynności wymaga walidacji w czasie rzeczywistym, aktualnych danych konta, kontroli zgodności lub potwierdzenia bezpieczeństwa serwera. Aplikacja powinna jednak zachowywać się przewidywalnie nawet w niesprzyjających warunkach.
Istnieje duża różnica pomiędzy:
- Coś poszło nie tak.
I to:
- Twoje połączenie jest niestabilne. Zapisaliśmy dane przelewu, ale płatność nie została zrealizowana. Spróbuj ponownie, gdy będziesz online.
Ta druga wiadomość zmniejsza niepokój. Pomaga również zapobiegać błędom.
Jeśli planujesz produkt we współpracy z firmą fintech zajmującą się tworzeniem oprogramowania lub oceniasz usługi tworzenia aplikacji mobilnych, niezawodność powinna być elementem procesu odkrywania, architektury, kontroli jakości i planowania wdrożenia. Wpływa ona na koszty i harmonogram, ale chroni również firmę przed chaosem w dziale wsparcia, negatywnymi opiniami i utratą zaufania.
Niezawodność i wydajność aplikacji bankowości mobilnej
Aplikacja bankowości mobilnej może wyglądać elegancko, zapewniać solidne zabezpieczenia i oferować wszystkie oczekiwane funkcje. To jednak nie ma większego znaczenia, jeśli aplikacja zawiedzie podczas logowania, zawiesi się podczas wczytywania transakcji lub zawiesi się podczas przelewu.
Niezawodność nie jest technicznym dodatkiem w rozwoju aplikacji bankowości mobilnej. Jest częścią produktu. Użytkownicy oczekują, że ich aplikacja bankowa będzie działać w podróży, podczas dojazdów do pracy, podczas korzystania ze słabego sygnału Wi-Fi lub podczas sprawdzania płatności między spotkaniami.
Dla założycieli firm fintech, banków i zespołów produktowych oznacza to, że niezawodność trzeba zaplanować z wyprzedzeniem, a nie wdrażać po uruchomieniu.
Niezawodna aplikacja bankowości mobilnej powinna Ci pomóc:
- utrzymuj przepływy krytyczne dostępne, gdy sieć jest słaba
- zmniejsz liczbę nieudanych transakcji, duplikatów żądań i zgłoszeń pomocy technicznej
udzielaj użytkownikom jasnych informacji zwrotnych zamiast niejasnych błędów - wykrywaj awarie i problemy z wydajnością, zanim wpłyną one negatywnie na oceny
- dostosować produkt, inżynierię, zapewnienie jakości i operacje do mierzalnych celów
W tym artykule omówiono podstawowe kwestie dotyczące niezawodności i wydajności, jakie powinna uwzględniać każda aplikacja bankowości mobilnej: zachowanie przy słabej sieci, buforowanie, ponowne próby, łagodne pogorszenie jakości, monitorowanie awarii, SLO i monitorowanie.
Dlaczego niezawodność ma znaczenie w rozwoju aplikacji bankowości mobilnej
Aplikacje bankowe niosą ze sobą większy ładunek emocjonalny niż większość aplikacji konsumenckich.
Jeśli aplikacja streamingowa działa wolno, ludzie się irytują. Jeśli aplikacja bankowa działa wolno, ludzie zaczynają się martwić o swoje pieniądze.
Niezawodność ma wpływ na wiele aspektów działalności przedsiębiorstwa.
Zaufanie i utrzymanie
Użytkownicy mogą wybaczyć niewygodny ekran. Są jednak mniej tolerancyjni, gdy aplikacja zawiesza się podczas płatności lub wyświetla niespójne informacje o koncie. Stabilność to sygnał zaufania.
Obciążenie pracą wsparcia
Niewłaściwa obsługa błędów prowadzi do powstawania zgłoszeń do pomocy technicznej, których można uniknąć. Użytkownicy kontaktują się z pomocą techniczną, gdy nie wiedzą, czy przelew został zrealizowany, dlaczego operacja na karcie się nie powiodła lub czy saldo jest aktualne.
Konwersja i adopcja
Cyfrowe wdrożenie, aktywacja kart, przelewy, wnioski kredytowe i połączenia z otwartą bankowością – wszystko to zależy od płynnego przebiegu. Problemy z wydajnością mogą dyskretnie obniżyć konwersję.
Zgodność i audytowalność
W produktach finansowych sama świadomość awarii nie wystarczy. Zespoły potrzebują logów, znaczników czasu, identyfikatorów żądań i przejrzystych przejść między stanami, aby móc bezpiecznie zbadać sprawę.
Reputacja w sklepie z aplikacjami
Awarie, zawieszanie się, problemy z logowaniem i powolne ładowanie często trafiają do publicznych recenzji. Monitorowanie awarii i wydajności pomaga zespołom wykryć te problemy, zanim użytkownicy zaczną się skarżyć.
Zacznij od krytycznych przepływów użytkowników
Nie każdy ekran musi spełniać te same standardy niezawodności.
Baner marketingowy może zawieść bez ostrzeżenia. Potwierdzenie płatności nie.
Zanim wybierzesz narzędzia lub wzorce architektoniczne, zidentyfikuj najważniejsze przepływy użytkowników:
- logowanie i uwierzytelnianie
- przegląd konta i salda
- historia transakcji
- status karty i kontrola karty
- transfery wewnętrzne i zewnętrzne
- potwierdzenie płatności
- głębokie linki powiadomień push
- wsparcie lub tworzenie sporów
- KYC i kroki wdrażania
Następnie sklasyfikuj je według ryzyka.
Wyświetlanie salda powinno być szybkie i przejrzyste. Przelewy powinny być zabezpieczone przed duplikacją. Blokada karty powinna pokazywać przejrzysty status i potwierdzenie. Historia transakcji może korzystać z buforowania w bardziej agresywny sposób, o ile stany oczekujące i zaksięgowane są łatwe do zrozumienia.
Dzięki takiemu myśleniu opartemu na przepływie zespół może zdecydować, gdzie praca nad niezawodnością ma największe znaczenie.
Jeśli chcesz uzyskać szerszy pogląd na temat planowania bezpiecznych produktów finansowych, możesz także zapoznać się z blogiem Appricotsoft.
Strategie offline i słabej sieci
Strategia offline w bankowości mobilnej nie polega na udawania, że wszystko działa bez internetu.
Chodzi o zaprojektowanie uczciwego, bezpiecznego i użytecznego zachowania w sytuacji utraty łączności.
Wykrywaj jakość sieci, a nie tylko jej stan online
Urządzenie może być wprawdzie podłączone do sieci, ale mimo to połączenie może być zbyt słabe, aby umożliwić bezpieczny transfer danych.
Aplikacja powinna rozumieć różne stany:
- brak połączenia
- słabe lub niestabilne połączenie
- połączony, ale powolny
- związane z błędami serwera
- połączony, ale sesja wygasła
Każdy stan powinien wyzwalać inne komunikaty i zachowania.
Na przykład, jeśli aplikacja nie może odświeżyć danych konta, może wyświetlić ostatnie dostępne saldo za pomocą etykiety takiej jak:
- Ostatnia aktualizacja 10 minut temu.
To jest o wiele lepsze niż pusty ekran.
Zwiększ odporność funkcji tylko do odczytu
Niektóre funkcje mogą pozostać użyteczne nawet przy słabym połączeniu:
- ostatnio przeglądana historia transakcji
- zapisane dane odbiorcy płatności
- informacje o oddziale lub bankomacie w pamięci podręcznej
- artykuły pomocy
- podstawowe informacje profilowe
- szczegóły projektu przelewu przed wysłaniem
Zasada jest prosta: użytkownicy powinni wiedzieć, czy widzą dane na żywo, czy zapisane.
Unikaj niebezpiecznych działań offline
Niektórych czynności nie należy wykonywać w trybie offline:
- ostateczne przesłanie przelewu
- zmiany limitów kart
- zatwierdzenie nowego odbiorcy płatności
- weryfikacja tożsamości
- decyzje dotyczące pożyczek lub kredytów
- wszystko, co wymaga kontroli ryzyka w czasie rzeczywistym
W przypadku tych przepływów aplikacja może zapisywać postępy, weryfikować dane wejściowe i wyjaśniać kolejny krok. Nie powinna ona jednak sugerować, że uregulowana czynność finansowa została wykonana przed jej potwierdzeniem przez serwer.
Zachowaj postęp użytkownika
Słabe połączenie jest jeszcze gorsze, gdy użytkownicy tracą informacje, które już wprowadzili.
W przypadku długich formularzy, wprowadzania danych lub konfiguracji transferu zachowaj w stosownych przypadkach bezpieczny, niespecyficzny postęp:
- zapisz dozwolone pola robocze lokalnie
- pozwól użytkownikom na ponowną próbę od nieudanego kroku
- zachowaj wybranego odbiorcę i kwotę widoczną po nieudanym połączeniu z siecią
- unikaj czyszczenia ekranu po tymczasowych błędach
To drobny szczegół UX, ale pomaga wyeliminować wiele frustracji.
Szybkie, użyteczne i uczciwe buforowanie
Buforowanie może sprawić, że aplikacja bankowa będzie działać szybciej. Może również zmniejszyć obciążenie serwera i pomóc użytkownikom w przypadku słabego połączenia.
Jednak nieaktualne dane finansowe mogą powodować zamieszanie, dlatego buforowanie wymaga pewnych reguł.
Dobrymi kandydatami do buforowania są:
- strony historii transakcji
- Często zadawane pytania i artykuły pomocy technicznej
- wykaz oddziałów banku lub bankomatów
- Konfiguracja interfejsu użytkownika i flagi funkcji
- dane referencyjne niewrażliwe
- ostatnio załadowane podsumowania kont z etykietami świeżości
Dane wrażliwe wymagają bardziej rygorystycznego traktowania. Zespół powinien określić, co można przechowywać, jak długo, czy należy je szyfrować i kiedy należy je wyczyścić.
Używaj etykiet informujących o świeżości
Użytkownicy nie powinni musieć zgadywać, czy informacje są aktualne.
Używaj etykiet takich jak:
- Zaktualizowano przed chwilą.
- Ostatnia aktualizacja 14:32.
- Wyświetlanie zapisanych danych. Połącz, aby odświeżyć.
Ma to największe znaczenie w przypadku sald i statusu transakcji.
Pamięć podręczna według przepływu, a nie nawyku
Buforowanie wszystkiego nie jest strategią.
W przypadku każdego elementu w pamięci podręcznej zapytaj:
- Czy poprawia odczuwalną prędkość?
- Czy zmniejsza liczbę powtarzających się wywołań API?
- Czy to pomaga przy słabym połączeniu?
- Czy nieaktualne dane są w tym przypadku dopuszczalne?
- Czy stwarza ryzyko bezpieczeństwa lub zgodności?
Przemyślana polityka buforowania sprawia, że aplikacja wydaje się szybka i nie wprowadza użytkowników w błąd.
Ponowne próby bez powtarzających się działań
Ponawianie prób jest konieczne w przypadku zawodnych sieci. W przepływach finansowych również może być niebezpieczne.
Wyobraź sobie, że użytkownik klika “Wyślij pieniądze”, połączenie zostaje zerwane, a aplikacja ponawia żądanie. Czy przelew został zrealizowany raz, dwa razy, czy wcale?
Dlatego logika ponawiania prób musi współdziałać z zabezpieczeniami zaplecza.
Wykorzystaj idempotentność w działaniach finansowych
W przypadku przelewów, płatności i operacji kartowych aplikacja i zaplecze powinny używać kluczy idempotentności.
Dzięki temu możliwe jest bezpieczne ponawianie żądania bez tworzenia duplikatów transakcji.
Aplikacja może poinformować użytkownika:
- Sprawdzamy status płatności. Prosimy nie przesyłać ponownie.
Zaplecze potrafi rozpoznać powtarzające się żądania jako część tej samej akcji.
Użyj inteligentnych reguł ponawiania prób
Nie każdy błąd należy ponawiać.
Spróbuj ponownie, gdy:
- połączenie zostaje tymczasowo zerwane
- żądanie przekracza limit czasu
- serwer zwraca tymczasowy problem z dostępnością
Nie próbuj ponownie bezmyślnie, gdy:
- uwierzytelnianie nie powiodło się
- użytkownik wprowadził nieprawidłowe dane
- na koncie nie ma wystarczających środków
- żądanie narusza regułę biznesową
- akcja wymaga nowego potwierdzenia użytkownika
Dodaj odroczenie i ograniczenia
Agresywne ponawianie prób może przeciążyć zaplecze i wyczerpać baterię urządzenia.
Stosuj limity ponownych prób i wykładniczy czas wycofywania. W przypadku niepowodzenia ponownych prób jasno określ kolejny krok.
Przydatna wiadomość brzmi tak:
- Nie mogliśmy potwierdzić wyniku, ponieważ połączenie zostało przerwane. Sprawdź historię transakcji przed ponowną próbą.
Słaby przekaz brzmi tak:
- Błąd. Spróbuj ponownie.
Łaskawa degradacja
Łagodna degradacja oznacza, że aplikacja nadal będzie dostarczać użytkownikom wartościowe treści, nawet gdy część systemu ulegnie awarii.
Jeśli usługa nagród jest niedostępna, użytkownicy nadal powinni mieć możliwość przeglądania sald. Jeśli kategoryzacja transakcji jest opóźniona, użytkownicy nadal powinni widzieć historię transakcji. Jeśli baner promocyjny nie działa, nie powinien blokować pulpitu nawigacyjnego.
Priorytety funkcji planu
Posortuj funkcje według ich ważności.
Krytyczny:
- login
- dostęp do konta
- transfery
- sterowanie kartami
- status transakcji
Ważny:
- wsparcie
- oświadczenia
- powiadomienia
- sprzeczanie się
- otwarte połączenia bankowe
Niekrytyczne:
- banery
- zalecenia
- personalizacja
- treści marketingowe
Pomaga to zespołowi zdecydować, co powinno blokować użytkownika, a co może działać po cichu.
Zaprojektuj stany zapasowe
Każdy ważny ekran wymaga zaplanowanych stanów zapasowych:
- załadunek
- pusty
- nieaktywny
- częściowe dane
- błąd serwera
- sesja wygasła
- konserwacja
Stany te powinny być napisane prostym językiem i testowane tak, jak normalne ekrany.
Unikaj pulpitów nawigacyjnych typu „wszystko albo nic”
Panel bankowy często opiera się na kilku usługach: kontach, kartach, transakcjach, ofertach, powiadomieniach i wsparciu.
Jeśli jedna usługa ulegnie awarii, cały panel nie powinien się zawiesić.
Zamiast tego zaprojektuj niezależne sekcje. Jeśli dane karty są tymczasowo niedostępne, pokaż resztę pulpitu i umieść jasny komunikat w sekcji karty.
Podstawy wydajności
Wydajność to nie tylko czas reakcji zaplecza. To również to, jak szybko działa aplikacja.
Uwaga dla użytkowników:
- czas uruchomienia aplikacji
- szybkość logowania
- czas ładowania pulpitu nawigacyjnego
- przewijanie listy transakcji
- wyszukiwanie i filtrowanie odpowiedzi
- czas potwierdzenia przelewu
- zawiesza się i opóźnia wprowadzanie danych
Zoptymalizuj pierwszy użyteczny ekran
W przypadku aplikacji bankowych pierwszym przydatnym ekranem jest zazwyczaj pulpit nawigacyjny.
Nie ładuj wszystkiego przed wyświetleniem czegokolwiek. Priorytetem jest przegląd konta, ważne alerty i główne działania. Mniej ważne moduły mogą załadować się po wyświetleniu ekranu głównego.
Utrzymuj płynność historii transakcji
Historia transakcji może z czasem stać się zbyt długa.
Stosuj paginację, indeksowanie lokalne tam, gdzie to konieczne, oraz wydajne filtry. Unikaj ładowania do pamięci danych obejmujących wiele lat naraz.
Dobra historia transakcji obejmuje:
- szybkie obciążenie początkowe
- wyczyść oczekujące i opublikowane statusy
- wyszukiwanie i filtry, które się nie zawieszają
- paragony lub szczegóły ładowane na żądanie
- kontrolowane zachowanie eksportowe
Testuj na prawdziwych urządzeniach
Wydajność flagowego telefonu testowego nie jest wystarczająca.
Testuj na starszych urządzeniach, różnych wersjach systemów operacyjnych i wolniejszych sieciach. Ma to szczególne znaczenie, jeśli aplikacja obsługuje szeroką bazę klientów.
Silna firma zajmująca się tworzeniem aplikacji na Androida lub iOS powinna planować obsługę urządzeń już na wczesnym etapie, a nie dopiero po pojawieniu się skarg.
Monitorowanie awarii i śledzenie stabilności
Monitorowanie awarii jest jednym z podstawowych elementów każdej produkcyjnej aplikacji mobilnej.
Narzędzia takie jak Firebase Crashlytics Pomóż zespołom śledzić, priorytetyzować i badać problemy ze stabilnością na różnych platformach. Firebase opisuje Crashlytics jako narzędzie do raportowania awarii w czasie rzeczywistym, które pomaga zespołom znajdować i naprawiać problemy ze stabilnością wpływające na jakość aplikacji.
Konfiguracja monitorowania awarii powinna obejmować:
- użytkownicy bez awarii
- sesje bez awarii
- błędy krytyczne i niekrytyczne
- dotknięte wersje aplikacji
- modele urządzeń i wersje systemów operacyjnych
- ekrany lub przepływy, w których dochodzi do awarii
- stan sieci, gdy jest to istotne
- działania użytkownika przed awarią, bez gromadzenia poufnych danych
Nie czekaj, aż użytkownicy zgłoszą awarie
Wielu użytkowników nie skontaktuje się z pomocą techniczną. Po prostu przestaną korzystać z aplikacji lub wystawią negatywną opinię.
Monitorowanie awarii zapewnia zespołowi wgląd w sytuację zanim problem stanie się publiczny.
Ustal priorytety według wpływu
Nie każda katastrofa jest tak samo pilna.
Ustal priorytety problemów na podstawie:
- ilu użytkowników jest dotkniętych
- czy krach wpłynie na krytyczne przepływy bankowe
- czy zaczęło się po wydaniu
- czy blokuje logowanie, płatności, karty lub wdrażanie
- czy dotyczy to konkretnego urządzenia lub wersji systemu operacyjnego
Połącz dane dotyczące awarii z zarządzaniem wydaniami
Każde wydanie powinno być ściśle monitorowane po udostępnieniu.
Jeśli liczba awarii wzrośnie, zespół powinien być w stanie wstrzymać wdrażanie, zbadać problem, rozwiązać go i szybko wypuścić poprawkę.
Właśnie w tym miejscu tworzenie niestandardowych aplikacji mobilnych korzysta z dyscypliny procesu wdrażania. Aplikacja nie jest po prostu uruchamiana. Jest obsługiwana, monitorowana, ulepszana i chroniona.
SLO: zdefiniuj, co oznacza niezawodność
“Samo określenie ”niezawodny” jest zbyt niejasne.
Zespołom potrzebne są mierzalne cele.
W inżynierii niezawodności witryny SLO, czyli cel poziomu usług, to docelowa wartość lub zakres mierzonego wskaźnika usługi. Wytyczne Google dotyczące SRE opisują docelowe poziomy usług jako cele mierzone wskaźnikami poziomu usług. Pomagają zespołom definiować niezawodność w konkretnych kategoriach.
W przypadku bankowości mobilnej cele SLO pomagają zespołom produktowym i inżynieryjnym uzgodnić, co oznacza coś wystarczająco dobrego dla użytkowników i ryzyka biznesowego.
Przykładowe cele usług bankowości mobilnej:
- 99,9% – dostępność udanych logowań miesięcznie
- 99,5% pomyślnie rozpatrzonych próśb o odświeżenie salda miesięcznie
- Ładowanie 95% pulpitu nawigacyjnego kończy się w ciągu 2 sekund przy normalnych warunkach sieciowych
- 99,9% kontroli statusu transferu zwraca wyraźny stan końcowy lub oczekujący
- Sesje bez awarii utrzymują się powyżej 99,81 TP3T na wersję aplikacji
- krytyczne głębokie linki powiadomień push otwierają właściwy cel 99% w danym momencie
To tylko przykłady, a nie uniwersalne zasady. Właściwe cele zależą od dojrzałości produktu, infrastruktury, bazy użytkowników, regulacji i modelu biznesowego.
Cele SLO powinny być zorientowane na użytkownika
Nie mierz wyłącznie czasu sprawności serwera.
Usługa zaplecza może być uruchomiona, a użytkownicy nadal nie mogą dokończyć transferu z powodu błędu urządzenia mobilnego, przekroczenia limitu czasu interfejsu API lub awarii urządzenia zewnętrznego.
Lepsze pytania brzmią:
- Czy użytkownicy mogą się zalogować?
- Czy mogą zobaczyć informacje o koncie?
- Czy uda im się bezpiecznie wykonać transfer?
- Czy mogą potwierdzić status płatności?
- Czy mogą odzyskać sprawność działania przy słabym stanie sieci?
Wskaźniki niezawodności zorientowane na użytkownika pomagają kierownictwu zrozumieć rzeczywisty stan produktu.
Podstawy monitorowania aplikacji bankowości mobilnej
Monitorowanie powinno obejmować całą drogę od urządzenia mobilnego do systemów zaplecza i dostawców zewnętrznych.
Stan aplikacji mobilnej
Ścieżka:
- użytkownicy i sesje bez awarii
- czas uruchamiania aplikacji
- czas ładowania ekranu
- Współczynniki błędów API z aplikacji
- wskaźniki przekroczenia limitu czasu sieci
- wolne lub zamrożone ekrany
- nieudane głębokie linki
Stan zaplecza i interfejsu API
Ścieżka:
- Dostępność API
- Opóźnienie API
- wskaźniki błędów według punktu końcowego
- błędy uwierzytelniania
- błędy w przetwarzaniu płatności lub przelewu
- opóźnienia w kolejkach
- wydajność bazy danych
Zdrowie w zależności od osób trzecich
Aplikacje bankowości mobilnej często korzystają z procesorów płatności, dostawców usług KYC, dostawców kart, interfejsów API bankowości otwartej, narzędzi do wykrywania oszustw i dostawców powiadomień.
Ścieżka:
- czasy reakcji dostawców
- wskaźniki błędów dostawców
- nieudane przetwarzanie webhooka
- opóźnione aktualizacje statusu
- rozmiar kolejki ponownych prób
- luki w pojednaniu
Sygnały biznesowe i operacyjne
Wskaźniki techniczne powinny być powiązane z wynikami biznesowymi.
Ścieżka:
- nieudane próby transferu
- odwiezienie na pokład
- zgłoszenia pomocy technicznej według typu problemu
- awarie kontroli kart
- błędy w tworzeniu sporów
- trendy w recenzjach w sklepie z aplikacjami
Dzięki temu założyciele i kadra zarządzająca zyskują jaśniejszy obraz niezawodności wykraczający poza panele sterowania infrastrukturą.
Alertowanie
Monitorowanie bez alarmowania jest pasywne. Alarmowanie bez dyscypliny staje się szumem.
Utwórz alerty dotyczące problemów wymagających podjęcia działań:
- wskaźnik nieudanych logowań powyżej progu
- opóźnienia w potwierdzeniu przelewu
- gwałtowny wzrost liczby awarii po wydaniu
- Opóźnienie API powyżej SLO
- awaria dostawcy płatności
- nieudane dostarczenie powiadomienia push
- wzrost współczynnika błędów w przepływie krytycznym
Unikaj powiadamiania całego zespołu o każdej, nawet najmniejszej zmianie.
Alerty powinny mieć właścicieli, poziomy ważności i podręczniki reagowania.
Przykładowe poziomy ważności:
- Poziom zagrożenia 1: użytkownicy nie mogą się zalogować ani wykonywać ważnych operacji finansowych
- Poziom 2: główna funkcja jest osłabiona, ale użytkownicy nadal mogą wykonywać podstawowe zadania
- Stopień 3: problem niekrytyczny lub odizolowany błąd specyficzny dla urządzenia
Dzięki temu reakcja na incydenty jest lepiej zorganizowana, a panika mniejsza.
Strategia wydania
Wiele problemów z niezawodnością pojawia się jeszcze przed premierą.
Solidna strategia wydawnicza powinna obejmować:
- flagi funkcji dla ryzykownych zmian
- wdrożenia etapowe według procentu użytkowników
- Kontrola jakości na rzeczywistych urządzeniach
- testowanie słabej sieci
- testy regresyjne dla przepływów krytycznych
- monitorujące panele kontrolne przygotowane przed wydaniem
- plan wycofania
- okno obserwacji po zwolnieniu
W przypadku tworzenia aplikacji bankowości mobilnej wdrażanie etapowe jest szczególnie przydatne. Zamiast udostępniać je wszystkim naraz, zespół może monitorować mniejszą grupę użytkowników, wykrywać problemy i stopniowo je rozszerzać.
Ma to również znaczenie w przypadku tworzenia aplikacji wieloplatformowych. Jeśli używasz React Native lub innego podejścia wieloplatformowego, testy niezawodności nadal muszą obejmować zachowanie specyficzne dla danej platformy, zarówno na iOS, jak i Androidzie.
Jak Appricotsoft zwiększa niezawodność aplikacji bankowości mobilnej
W Appricotsoft nie traktujemy niezawodności jako osobnej listy kontrolnej o charakterze technicznym.
Wszystko zaczyna się od priorytetów, starannego projektowania, uczciwej komunikacji i ciągłej walidacji.
Nasze podejście jest zgodne z naszą misją: chcemy być przykładem tego, jak powinno wyglądać tworzenie świetnego oprogramowania, pod względem jakości, innowacyjności, zaufania i odpowiedzialności.
Zaczynamy od przepływów krytycznych dla biznesu
Zanim zaczniesz pisać kod, pomagamy zdefiniować, które przepływy są najważniejsze:
- login
- przegląd konta
- transakcje
- transfery
- zarządzanie kartami
- proces wdrażania do firmy nowego pracownika
- wsparcie
- powiadomienia
Dzięki temu możemy projektować niezawodność w oparciu o rzeczywisty wpływ na użytkownika, a nie o ogólne założenia.
Wcześnie planujemy zachowanie w trybie offline i przy słabej sieci
Definiujemy, co powinno działać w trybie offline, co powinno być tylko do odczytu, co musi wymagać potwierdzenia na żywo i w jaki sposób aplikacja powinna komunikować niepewność.
Dzięki temu można uniknąć późniejszych nieporozumień dotyczących doświadczeń użytkowników.
Projektujemy bezpieczne ponowne próby i czyste stany
W przypadku działań finansowych planujemy identyfikatory żądań, idempotentność, reguły ponawiania prób i stany potwierdzenia.
Cel jest prosty: użytkownicy nigdy nie powinni zastanawiać się, czy ich pieniądze zostały przelane dwukrotnie.
Włączamy monitorowanie do planu wydania
Monitorowanie awarii, śledzenie wydajności, metryki API i alerty powinny być gotowe przed uruchomieniem.
Obserwowalność nie powinna być kwestią drugorzędną.
W celu zapewnienia transparentnej dostawy korzystamy z Unison Framework
Nasz Unison Framework pomaga klientom zobaczyć postęp na podstawie jasno określonych etapów:
- Wyrównywać
- Plan
- Zbudować
- Uprawomocnić
- Początek
- Rosnąć
Cotygodniowe wersje demonstracyjne, dzienniki decyzji, rejestry ryzyka, kryteria akceptacji, kontrole jakości i gotowość do wydania — wszystko to sprzyja przewidywalności dostawy.
Narzędzia AI mogą pomóc w powtarzalnej pracy, dokumentacji, scenariuszach testowych i analizach. Ludzie pozostają odpowiedzialni za wyniki. To ma znaczenie w branży fintech, gdzie jakości i odpowiedzialności nie da się delegować automatyzacji.
Walidujemy za pomocą QA i scenariuszy z życia wziętych
Testowanie niezawodności powinno obejmować więcej niż tylko testowanie prawidłowych ścieżek.
Testujemy:
- wolne sieci
- przerwane sesje
- ponownych prób
- wygasłe sesje
- różnice między urządzeniami
- nieudane interfejsy API
- częściowe przerwy w świadczeniu usług
Niezawodne produkty powstają w wyniku testowania niekomfortowych sytuacji, zanim doświadczą ich użytkownicy.
Typowe błędy, których należy unikać
Nawet doświadczone zespoły mogą nie doceniać niezawodności.
Traktowanie zachowań offline jako czegoś drugorzędnego
Zachowanie offline i w warunkach słabego połączenia sieciowego powinno być projektowane celowo. W przeciwnym razie aplikacja stanie się nieprzewidywalna w momencie, gdy użytkownicy najbardziej potrzebują przejrzystości.
Wyświetlanie nieaktualnych danych bez wyjaśnienia
Dane z pamięci podręcznej są przydatne tylko wtedy, gdy użytkownicy mają świadomość ich aktualności.
Ponawianie działań finansowych bez idempotencji
Może to powodować duplikowanie żądań i poważne ryzyko operacyjne.
Monitorowanie tylko czasu sprawności zaplecza
Czas działania zaplecza nie jest równoznaczny z niezawodnością aplikacji mobilnej. Monitoruj ścieżkę użytkownika.
Ignorowanie błędów niekrytycznych
Błędy niekrytyczne mogą ujawnić uszkodzone przepływy, nieudane walidacje i mylące stany, zanim doprowadzą do awarii.
Wydanie bez planu wycofania
Każda wersja produkcyjna wymaga planu reagowania. Nadzieja nie jest strategią wydania.
Często zadawane pytania
Czym jest niezawodność w rozwoju aplikacji bankowości mobilnej?
Niezawodność oznacza, że użytkownicy mogą wykonywać ważne operacje bankowe bezpiecznie i spójnie, nawet gdy sieci, urządzenia, interfejsy API lub usługi stron trzecich są niedoskonałe.
Obejmuje dostępność, wydajność, przejrzyste zarządzanie błędami, zapobieganie awariom i odzyskiwanie po awarii.
Czy aplikacja bankowości mobilnej powinna działać w trybie offline?
Niektóre części mogą działać w trybie offline lub tylko do odczytu, np. historia transakcji w pamięci podręcznej, zapisana zawartość pomocy technicznej lub formularze robocze.
Kluczowe operacje finansowe, takie jak przelewy, zmiany kart i weryfikacja tożsamości, zazwyczaj wymagają potwierdzenia na żywo przez serwer.
Czym jest łagodna degradacja?
Łagodna degradacja oznacza, że aplikacja nadal będzie użyteczna, nawet gdy część systemu ulegnie awarii.
Na przykład, jeśli oferty lub nagrody są niedostępne, użytkownicy nadal powinni mieć możliwość przeglądania kont i dokonywania przelewów.
Czym są SLO w aplikacjach bankowych?
Cele SLO to mierzalne cele dotyczące niezawodności, takie jak wskaźnik udanych logowań, czas ładowania pulpitu nawigacyjnego, sesje bez awarii lub pomyślne potwierdzenie transferu.
Pomagają zespołom definiować i śledzić, co oznacza niezawodność.
Dlaczego monitorowanie awarii jest ważne?
Monitorowanie awarii pomaga zespołom wykrywać problemy ze stabilnością zanim zgłoszą je użytkownicy.
Pokazuje, które wersje aplikacji, urządzenia i przepływy są objęte problemem, dzięki czemu zespół może Czy niezawodność zwiększa koszty tworzenia aplikacji mobilnych?
Może zwiększyć nakład pracy związany z planowaniem, testowaniem, monitorowaniem i inżynierią.
Jednak zaniedbanie kwestii niezawodności często później kosztuje więcej w postaci zgłoszeń pomocy technicznej, nieudanych transakcji, złych recenzji, awaryjnych poprawek i odejścia użytkowników.
Jakie pytania dotyczące niezawodności założyciele firm zajmujących się tworzeniem aplikacji mobilnych powinni kierować do tych, które je tworzą?
Zapytaj, jak radzą sobie ze słabą siecią, buforowaniem, ponawianiem prób, monitorowaniem, raportowaniem awarii, celami usług (SLO), wycofywaniem zmian i reagowaniem na incydenty.
Dobry partner powinien jasno i wyraźnie wyjaśniać te zagadnienia, nie uciekając się do żargonu technicznego.
Wniosek
Niezawodność i wydajność to elementy, które obiecują produkty bankowości mobilnej.
Niezawodna aplikacja pomaga użytkownikom czuć się bezpiecznie. Reaguje jasno, gdy sieć jest słaba. Unika duplikowania działań. Szybko ładuje kluczowe informacje. Działa nadal, gdy usługi niekrytyczne zawodzą. Dostarcza zespołowi danych potrzebnych do ciągłego ulepszania produktu.
Jeśli tworzysz produkt bankowy, portfel cyfrowy, aplikację płatniczą lub platformę fintech, zaplanuj niezawodność od pierwszego dnia.
Będzie to miało wpływ na architekturę, UX, zapewnienie jakości, monitorowanie, wsparcie i długoterminowy rozwój.
W Appricotsoft pomagamy założycielom firm, zespołom fintech i firmom finansowym tworzyć aplikacje mobilne, które są funkcjonalne, stabilne, mierzalne i gotowe do pracy w rzeczywistych warunkach. Niezależnie od tego, czy potrzebujesz dedykowanego rozwoju aplikacji mobilnej, rozwoju React Native, natywnej wiedzy specjalistycznej na iOS i Androida, czy wsparcia w ulepszeniu istniejącego produktu, pomożemy Ci przekształcić niezawodność w praktyczną zaletę.
Stwórzmy oprogramowanie bankowe, któremu użytkownicy będą mogli zaufać.
