Backend aplikacji mobilnej bez opieki — co psuje się na serwerze, gdy nikt go nie pilnuje

Aplikacja w sklepie to tylko połowa produktu. Prawie każda aplikacja mobilna rozmawia z serwerem: pobiera z niego dane, loguje użytkowników, zapisuje zamówienia, wysyła powiadomienia. Google Play i Apple pilnują, żeby sama aplikacja była aktualna, i przypominają o tym terminami. Serwera nie pilnuje nikt poza Tobą.

Gdy przejmujemy porzucone aplikacje, backend jest zwykle w gorszym stanie niż aplikacja. Nikt go nie aktualizował, bo „działa", a o tym, że coś jest nie tak, właściciel dowiaduje się w dniu awarii.

Dlaczego awaria backendu jest gorsza niż awaria aplikacji

Błąd w aplikacji dotyczy zwykle jednej wersji, jednego modelu telefonu albo jednej ścieżki. Awaria serwera dotyczy wszystkich użytkowników i wszystkich wersji aplikacji naraz. Nie naprawisz jej nowym wydaniem w sklepie, bo problem nie leży w aplikacji.

Dla użytkownika wygląda to tak samo jak błąd aplikacji: kręcące się kółko, pusty ekran, komunikat „brak połączenia". Dlatego takie awarie często widać najpierw w ocenach w sklepie — piszemy o tym w tekście o tym, skąd się bierze niska ocena aplikacji.

Certyfikat SSL — najbardziej banalna z poważnych awarii

Przeglądarka przy wygasłym certyfikacie pokaże ostrzeżenie i pozwoli przejść dalej. Aplikacja mobilna zwykle po prostu przestaje się łączyć z serwerem. Z perspektywy użytkownika aplikacja przestała działać w całości, z dnia na dzień.

Do niedawna certyfikat odnawiało się raz w roku i dało się to zrobić ręcznie. To się zmienia. CA/Browser Forum, organizacja ustalająca zasady dla urzędów certyfikacji i przeglądarek, skraca maksymalny okres ważności certyfikatów:

Przy certyfikacie ważnym 100 albo 47 dni ręczne odnawianie przestaje być realne. Potrzebne jest automatyczne odnawianie i monitoring, który sprawdzi, czy ono faktycznie działa. To drugie jest ważne: Let's Encrypt od 4 czerwca 2025 nie wysyła już e-maili o zbliżającym się wygaśnięciu certyfikatu. Jeśli automat po cichu przestał działać, np. po zmianie konfiguracji serwera, nikt nie dostanie ostrzeżenia.

Przypinanie certyfikatu

W części aplikacji, zwłaszcza finansowych i medycznych, stosuje się certificate pinning: aplikacja ufa tylko konkretnemu certyfikatowi albo kluczowi serwera. Jeśli przy odnowieniu certyfikatu zmieni się klucz, wszystkie wersje aplikacji z przypiętym starym kluczem przestaną się łączyć — i żadna z nich nie dowie się o aktualizacji, bo nie połączy się z serwerem.

Zanim wymienisz certyfikat na serwerze, sprawdź, czy aplikacja go przypina i do czego dokładnie. Bezpieczniejszy wariant to przypięcie klucza publicznego z kluczem zapasowym, przygotowanym z wyprzedzeniem. Więcej o tym, kiedy pinning ma sens, piszemy w tekście o najczęstszych lukach w bezpieczeństwie aplikacji mobilnych.

Domena

Pokrewny problem: domena API zarejestrowana na prywatne konto programisty albo agencji, z kartą, która dawno wygasła. Wygaśnięcie domeny wyłącza nie tylko API, ale też pocztę i stronę. Sprawdź, na kogo jest zarejestrowana i kiedy się kończy.

Środowisko, które przestało dostawać poprawki

Backend działa na konkretnym systemie operacyjnym i w konkretnym środowisku uruchomieniowym: PHP, Node.js, Pythonie, Javie. Każde z nich ma swój cykl wsparcia, po którym nie dostaje już poprawek bezpieczeństwa. Przykładowe terminy:

Uczciwie: tego dnia serwer nie przestanie działać. Przestanie dostawać łatki, a każda nowa luka w tej wersji zostanie otwarta na zawsze. Drugi problem jest bardziej przyziemny: im dłużej czekasz, tym większy skok przy aktualizacji. Przejście o jedną wersję PHP czy Node.js to zwykle kilka godzin pracy. Przejście o cztery wersje naraz oznacza zmiany w kodzie, w bibliotekach i we frameworku, a czasem przeprowadzkę na nowy serwer, bo system jest zbyt stary, żeby zainstalować na nim nowe środowisko.

To ten sam mechanizm, który opisujemy po stronie aplikacji w tekście o długu technicznym: małe aktualizacje regularnie są tańsze niż jedna duża co kilka lat.

Dysk, logi i baza danych

Te awarie narastają powoli i wybuchają nagle:

• Logi zapełniają dysk. Serwer, który od lat zapisuje każde zapytanie do pliku bez rotacji, pewnego dnia nie ma miejsca. Baza danych przestaje przyjmować zapisy, a API zaczyna zwracać błędy 500.
• Baza rośnie, zapytania zwalniają. Zapytanie, które przy tysiącu użytkowników trwało 50 ms, przy stu tysiącach trwa kilka sekund, bo brakuje indeksu. Użytkownik widzi wolną aplikację, choć w aplikacji nic się nie zmieniło. Jak szukać takich przyczyn, opisujemy w tekście o tym, dlaczego aplikacja mobilna działa wolno.
• Pliki użytkowników bez limitu. Zdjęcia, załączniki i eksporty trzymane na dysku serwera zamiast w magazynie plików rosną bez końca.

Wszystkie trzy da się wykryć prostymi alertami na zajętość dysku, rozmiar bazy i czas odpowiedzi API.

Kopie zapasowe, których nikt nie odtwarzał

To, że kopie zapasowe się wykonują, nie znaczy, że da się z nich odtworzyć system. Przy przejęciach regularnie spotykamy kopie, które zawierają tylko bazę bez plików, są zapisywane na tym samym serwerze, który mają chronić, albo od miesięcy kończą się błędem, którego nikt nie czyta.

Minimum, które warto mieć:

• kopie przechowywane poza serwerem produkcyjnym, najlepiej u innego dostawcy albo w innym regionie,
• próbne odtworzenie przynajmniej raz na kwartał, na osobnym środowisku, z zapisanym czasem trwania,
• jasność, kto ma dostęp do kopii — zawierają te same dane osobowe co produkcja, więc obowiązują je te same zasady.

Rachunek za chmurę

Koszty chmury rosną po cichu: maszyny uruchomione do testu i nigdy nie wyłączone, logi przechowywane bez limitu, transfer danych, odczyty w Firebase rosnące razem z liczbą użytkowników. Warto raz na kwartał przejrzeć rachunek pozycja po pozycji i ustawić alerty budżetowe, które dostępne są u wszystkich dużych dostawców.

Groźniejszy scenariusz to rachunek, którego nikt nie płaci. Konto chmurowe opłacane prywatną kartą programisty, który odszedł, po kilku nieudanych płatnościach zostaje zawieszone — a razem z nim cały backend. Konto rozliczeniowe powinno być firmowe, z kartą firmową i adresem, który czyta więcej niż jedna osoba. To jeden z punktów, które opisujemy w tekście o tym, co zrobić, gdy programista zniknął.

Klucze i sekrety, które wygasają

Część poświadczeń, z których korzysta backend, ma datę ważności:

• Certyfikat APNs (.p12) do powiadomień push na iOS jest ważny rok. Po wygaśnięciu powiadomienia na iPhone'ach przestają dochodzić, a na Androidzie działają dalej. Rozwiązaniem jest klucz .p8, który nie wygasa — szczegóły w tekście o tym, dlaczego powiadomienia push przestały działać.
• Sekret klienta Sign in with Apple to podpisany token, który może być ważny najwyżej 6 miesięcy. Jeśli backend generuje go ręcznie, a nie automatycznie, logowanie przez Apple przestanie działać po upływie tego terminu.
• Klucze API dostawców płatności, map czy SMS-ów bywają rotowane przez dostawcę albo wygasają razem z umową.

Wszystkie te terminy warto mieć w jednym rejestrze, razem z informacją, gdzie dany klucz jest używany i kto może go odnowić.

Minimalny przegląd backendu

Większość tych rzeczy konfiguruje się raz, a potem tylko reaguje na alerty. Kto za nie odpowiada, warto zapisać wprost w umowie na utrzymanie aplikacji — inaczej każda strona zakłada, że zajmuje się tym druga.

Podsumowanie

Backend aplikacji mobilnej nie dostaje przypomnień od sklepów, więc łatwo o nim zapomnieć, dopóki działa. Najczęstsze awarie są banalne: wygasły certyfikat, pełny dysk, niezapłacony rachunek, przeterminowany klucz. Każdą z nich da się przewidzieć prostym monitoringiem i rejestrem terminów, a wydaje się na to ułamek kosztu jednej awarii.

Przejmujemy i utrzymujemy backendy aplikacji mobilnych razem z samymi aplikacjami — w ramach utrzymania aplikacji mobilnych albo jako osobną usługę backendu i API. Jeśli nie wiesz, w jakim stanie jest serwer Twojej aplikacji, napisz do nas. Stan samej aplikacji sprawdzimy w ramach bezpłatnej analizy aplikacji.