Wprowadzenie
W ostatnim roku przeprowadziłem audyt backendu dla średniej wielkości platformy SaaS. Zebraliśmy logi, przeanalizowaliśmy ruch – i odkryliśmy, że aż 15% endpointów API nie było używanych od ponad 6 miesięcy. Niektóre odpowiadały na zapytania botów, ale żaden realny klient ich nie wywoływał. Koszt utrzymania? Spokojnie kilka tysięcy złotych miesięcznie na samej infrastrukturze, nie licząc długu technicznego. To nie jest odosobniony przypadek. Martwe endpointy to cichy złodziej budżetu IT – szczególnie w firmach, które szybko rosły i nie miały czasu na porządki.
Dlaczego martwe endpointy powstają?
Najczęściej to efekt iteracyjnego rozwoju: dodajemy funkcjonalność, tworzymy nowe API, ale stare wersje pozostają „na wszelki wypadek”. Albo integracje z zewnętrznymi systemami, które już nie istnieją. Albo funkcje, które zostały zastąpione, ale nikt nie usunął starego kodu. Problem narasta, gdy zespół nie ma kultury deprecjacji – każdy boi się, że coś się zepsuje, więc utrzymuje wszystko wiecznie. Efekt? Pay-as-you-go w chmurze zamienia się w pay-for-nothing.
3 lekcje z praktyki
Lekcja 1: Audyt nie boli – brak audytu boli bardziej
Przeprowadzenie audytu endpointów wcale nie musi być trudne. W praktyce wystarczy tydzień zbierania logów z API gatewaya lub bezpośrednio z serwerów. Użyj prostego skryptu, który agreguje wywołania według endpointu i metody. Odfiltruj ruch od botów (User-Agent, IPy, częstotliwość). To, co zostanie, to realne użycie. Zobaczysz, które endpointy mają zerową liczbę wywołań od użytkowników.
Przykład: W jednym z projektów znaleźliśmy endpoint /api/v1/reports – nie wywoływany od 8 miesięcy. Po rozmowie z biznesem okazało się, że funkcja raportów została przeniesiona do panelu administracyjnego, ale endpoint został. Usunięcie go zmniejszyło zużycie CPU na serwerze o 3% – niby niewiele, ale w skali roku robi różnicę.
Lekcja 2: Martwe endpointy generują realne koszty
Każdy endpoint, nawet nieużywany, to:
- Kod do utrzymania (przeglądy, aktualizacje bibliotek, testy)
- Zajęta przestrzeń w monitoringu (logi, metryki, alerty – często skonfigurowane dla wszystkich endpointów)
- Potencjalne luki bezpieczeństwa (nieużywany kod to często niepatchowany kod)
- Opóźnienia w CI/CD (build i testy trwają dłużej)
W przytoczonym audycie po usunięciu 15% endpointów build pipeline skrócił się o 20%. Deweloperzy odetchnęli, a koszty chmury spadły o około 8%.
Lekcja 3: Wprowadź kulturę deprecjacji
Nie wystarczy wyczyścić raz. Trzeba wprowadzić proces:
- Każdy nowy endpoint powinien mieć datę przydatności? Przynajmniej w dokumentacji.
- Ustal politykę: jeśli endpoint nie jest używany przez 3 miesiące – oznacz go jako deprecated, wyślij alert do zespołu, po kolejnym miesiącu usuń.
- Używaj feature flags – łatwiej wyłączyć funkcję, sprawdzić, czy nikt nie narzeka, a potem usunąć kod.
W praktyce działa to świetnie. Klient, który wdrożył tę politykę, po roku nie miał ani jednego martwego endpointu. A oszczędności pozwoliły sfinansować nową funkcję.
Jak to wygląda w praktyce?
Zacznij od małego: wybierz jeden mikroserwis lub jeden kontroler. Zaloguj rzeczywiste użycie przez 7 dni. Porównaj z dokumentacją. Zdziwisz się, ile rzeczy jest nieużywanych. Potem przeskaluj na całość. Polecam zautomatyzować – skrypt co miesiąc generujący raport „endpointy bez ruchu od 90 dni”.
Podsumowanie
Martwe endpointy to nie tylko problem techniczny – to realne pieniądze, czas zespołu i ryzyko bezpieczeństwa. Jeśli Twoja firma rozwijała się szybko, prawdopodobnie masz ich kilkanaście lub kilkadziesiąt. Audyt i czyszczenie to jeden z najprostszych sposobów na optymalizację kosztów i wydajności. Nie wymaga wielkich nakładów, a przynosi wymierne efekty. A przy okazji – pokazuje, że zespół myśli o architekturze długoterminowo. W JurskiTech.pl regularnie przeprowadzamy takie audyty – i za każdym razem znajdujemy coś, co można poprawić. Może to dobry moment, żeby sprawdzić swoje API?
