Audyt architektury systemu: kiedy jest potrzebny i co znajduje

Audyt architektury to nie opinia o twoim stacku. To mapa miejsc, w których system pęka pod planem, który faktycznie masz.

Przeglądy architektury mają złą sławę, bo wiele z nich to ćwiczenia z gustu — konsultant tłumaczy, że wybrałby inaczej. Użyteczny audyt odpowiada na węższe i o wiele cenniejsze pytanie: skoro biznes zamierza być za osiemnaście miesięcy tam, gdzie zamierza — co pęknie, kiedy i ile kosztuje naprawa?

Sygnały, że potrzebujesz go teraz

• Wydajność zauważalnie spada wraz ze wzrostem ruchu i nikt nie potrafi powiedzieć dokładnie dlaczego
• Koszty infrastruktury rosną szybciej niż przychód
• Jeden komponent pada i pociąga za sobą niepowiązane funkcje
• Dowiezienie małej funkcji wymaga ruszenia wielu części systemu
• Za chwilę zwiększysz ruch dziesięciokrotnie — start, partnerstwo, runda finansowania
• Inwestor zapytał, czy architektura się skaluje, a uczciwa odpowiedź brzmi: nikt nie wie

Co bada audyt

Warstwa danych, najpierw i najtrudniej

W większości systemów prawdziwym sufitem jest baza danych i to najdroższa rzecz do zmiany później. Co się liczy: rozdział odczytu i zapisu, indeksowanie pod rzeczywiste wzorce zapytań, nieograniczone zapytania rosnące razem z tabelą, czy limitem jest pojedynczy master do zapisu, i czy schemat może ewoluować bez przestoju.

Izolacja awarii

• Co się dzieje, gdy zewnętrzna zależność jest wolna, a nie martwa — timeouty i bezpieczniki, czy kaskadowe wyczerpanie wątków
• Czy jeden najemca albo jeden ciężki klient może pogorszyć usługę dla wszystkich
• Czy zadania w tle mogą zagłodzić ścieżkę żądań

Szybkość zmian

Architektura to nie tylko obciążenie. System, którego nie da się bezpiecznie zmieniać, zawodzi w swojej roli, nawet jeśli nigdy nie pada. Szukamy sprzężenia wymuszającego zmiany w wielu modułach, braku szwów do testowania i współdzielonego stanu, który uniemożliwia lokalne rozumowanie.

Dopasowanie do wielkości zespołu

Jak powinien wyglądać wynik

Sensem audytu architektury jest zamiana mglistego lęku o skalowanie w niewielką liczbę datowanych i wycenionych decyzji.

Sprawdź konkretną hipotezę wzrostu

Diagram nie pokazuje rzeczywistej granicy systemu. Powiąż zmianę użycia z zależnościami, pojemnością i odtwarzaniem.

1. Prześledź krytyczne żądanie przez usługi, kolejki i magazyny danych.
2. Wskaż wspólne punkty awarii i niesprawdzone założenia pojemności.
3. Porównaj ograniczone zmiany według wpływu i kosztu weryfikacji.

• modernizacja oprogramowania →
• tworzenie backendu →