5 cichych awarii na produkcji i jak ich uniknąć
Wyobraź sobie, że Twoja aplikacja działa. Ludzie z niej korzystają. A potem coś się psuje — ale nie słyszysz huku. Ekran nie miga na czerwono. Po prostu strona się nie ładuje, ktoś nie może się zalogować, a na koniec miesiąca dostajesz rachunek, którego się nie spodziewałeś.
Najgroźniejsze awarie są ciche. Nie krzyczą. I właśnie dlatego potrafią działać po cichu całymi dniami, zanim ktokolwiek zauważy. Oto pięć takich sytuacji — opisanych tak, żeby było jasne, o co poprosić wykonawcę albo AI, zanim ruszysz z prawdziwymi użytkownikami.
1. Jeden zły klik kładzie aplikację dla wszystkich
Wyobraź sobie korek na jednym pasie, który zatrzymuje całe miasto. Tak działa źle zabezpieczona aplikacja: jeden użytkownik robi coś nietypowego — wpisuje dziwny znak, loguje się kontem bez hasła — i cały serwis się wyłącza. Nie dla niego jednego. Dla wszystkich naraz.
To groźne, bo nie da się tego przewidzieć. Wystarczy jeden niespodziewany przypadek, którego nikt nie sprawdził.
O co zadbać: poproś, żeby błąd jednego żądania psuł tylko to jedno żądanie, a nie całą aplikację (to się nazywa „globalny łapacz błędów”).
2. Brak limitu, czyli otwarte drzwi dla każdego
Wyobraź sobie bufet bez obsługi: jedna osoba może zająć wszystkie talerze i nikt jej nie powstrzyma. Tak samo aplikacja bez limitów — jeden użytkownik (albo bot) może wysłać tysiące żądań naraz i przeciążyć system tak, że przestaje odpowiadać reszcie.
To groźne, bo nie potrzeba do tego ataku — czasem wystarczy źle napisany skrypt po drugiej stronie.
O co zadbać: poproś o limit liczby żądań na osobę w danym czasie (fachowo: „rate-limit”), żeby nikt pojedynczo nie zatkał całości.
3. Cudza usługa padła i pociągnęła Cię za sobą
Twoja aplikacja prawie zawsze opiera się na czyichś usługach — mapach, płatnościach, wysyłce maili. To jak budowanie sklepu, którego prąd dostarcza sąsiad. Gdy u sąsiada wysiądzie prąd, Twój sklep też staje. A cudze usługi bywają zawodne: zwalniają, blokują, czasem zwracają śmieci zamiast danych.
To groźne, bo Twoja aplikacja może wisieć w nieskończoność, czekając na odpowiedź, która nigdy nie przyjdzie.
O co zadbać: poproś, żeby każde połączenie z cudzą usługą miało limit czasu (tzw. „timeout”) i automatyczną ponowną próbę — żeby krótka awaria u sąsiada nie zawiesiła wszystkiego u Ciebie.
4. Pętla, która po cichu drenuje budżet
Niektóre usługi liczą sobie pieniądze za każde użycie — na przykład AI, które odpowiada na pytania, albo wysyłka maili. Wyobraź sobie kran, który kapie przez całą noc: pojedyncza kropla nic nie kosztuje, ale rano masz zalane mieszkanie.
Jeśli coś w aplikacji zapętli się i wywołuje płatną usługę bez końca — albo ktoś specjalnie ją nadużyje — rachunek rośnie po cichu. Dowiadujesz się o tym dopiero z faktury.
O co zadbać: poproś o twardy limit kosztów na użytkownika (np. miesięczny), z jasnym komunikatem „wykorzystałeś limit, wróć za X dni”.
5. „Wysłałem maila” to nie znaczy, że dotarł
Klikasz „wyślij”, system mówi „wysłano” — i jesteś spokojny. A mail wylądował w spamie albo nigdzie. To jak wrzucenie listu do skrzynki, która okazała się zamurowana.
To groźne, bo nie widać problemu. Wszystko wygląda na działające, a klienci po prostu nie dostają potwierdzeń, faktur ani powitań.
O co zadbać: poproś o realny test dostarczalności — czyli sprawdzenie, że mail naprawdę dochodzi do skrzynki, a nie tylko „wyszedł” z serwera.
W skrócie
- Ciche awarie są najgroźniejsze — nie krzyczą, tylko po cichu wieszają, wylogowują albo drenują budżet.
- Zakładaj, że świat jest zawodny: cudze usługi padają, użytkownicy robią rzeczy nieprzewidziane, a płatne narzędzia liczą sobie za każde kliknięcie.
- Przed startem z prawdziwymi użytkownikami poproś wykonawcę albo AI o cztery rzeczy: globalny łapacz błędów, limity (czasu i kosztów), ponowne próby przy cudzych usługach i prawdziwy test dostarczalności maili.