Architektura oprogramowania i audyt techniczny
Architektura to zbiór decyzji, które najtrudniej odwrócić: jak podzielony jest system, gdzie mieszkają dane, co z czym się komunikuje i co się dzieje, gdy jeden element przestaje odpowiadać. Podejmuje się je na początku, przy najmniejszej wiedzy o projekcie, a płaci się za nie przez cały jego czas życia.
Robimy dwie rzeczy: projektujemy architekturę systemów budowanych od zera i audytujemy te, które już działają, ale zaczęły przeszkadzać. W obu przypadkach efektem jest dokument, z którego wynika, co konkretnie zrobić, w jakiej kolejności i ile to mniej więcej kosztuje.
Kiedy warto zamówić audyt architektury
Najbardziej czytelnym sygnałem jest spadek tempa. Zmiany, które kiedyś zajmowały dzień, zajmują tydzień, bo każda dotyka pięciu miejsc naraz, a po wdrożeniu psuje się coś zupełnie niezwiązanego. To zwykle znaczy, że granice między częściami systemu się zatarły.
Drugi sygnał to koszty, które rosną szybciej niż ruch. Jeżeli rachunek za infrastrukturę podwaja się przy dwudziestoprocentowym wzroście liczby użytkowników, problemem prawie nigdy nie jest dostawca, tylko sposób, w jaki system korzysta z bazy danych.
Trzeci to zbliżająca się zmiana skali - planujesz wejście na nowy rynek, dużą kampanię albo przejęcie i chcesz wiedzieć, czy system to wytrzyma. Sprawdzenie tego przed, a nie w trakcie, jest wielokrotnie tańsze.
Jak wygląda audyt
Zaczynamy od rozmów z osobami, które system utrzymują i z niego korzystają, bo najdroższe problemy zwykle są wszystkim znane i po prostu nikt ich nie spisał. Równolegle czytamy kod, konfigurację i historię repozytorium - częstotliwość zmian w poszczególnych obszarach dobrze pokazuje, gdzie jest prawdziwe centrum ciężkości.
Potem mierzymy. Czas odpowiedzi najczęściej używanych ścieżek, zapytania obciążające bazę, zużycie zasobów w szczycie, czas potrzebny na wdrożenie zmiany i na odtworzenie środowiska po awarii. Liczby zamiast wrażeń są jedynym sposobem, żeby priorytetyzować bez kłótni.
Efektem jest raport z listą znalezisk uporządkowaną według stosunku ryzyka do kosztu naprawy, diagramem stanu obecnego i proponowanego oraz planem dojścia od jednego do drugiego. Plan jest podzielony na etapy, z których każdy da się wdrożyć osobno i każdy sam z siebie coś poprawia.
- Wywiady z zespołem i użytkownikami systemu
- Przegląd kodu, konfiguracji i historii zmian
- Pomiary wydajności i kosztów infrastruktury
- Raport z priorytetami i szacunkiem pracochłonności
- Diagramy stanu obecnego i docelowego
Projektowanie nowego systemu
Przy nowych projektach zaczynamy od pytania, co ma być łatwe do zmiany, bo to ono determinuje podział systemu. Jeśli spodziewasz się częstych zmian reguł rozliczeń, wydzielamy je tak, żeby dało się je modyfikować bez ruszania reszty. Architektura jest zawsze kompromisem, a naszym zadaniem jest ustawić ten kompromis pod Twój rzeczywisty scenariusz.
Domyślnie zaczynamy prosto. Dobrze zorganizowana pojedyncza aplikacja obsługuje znacznie większy ruch, niż się powszechnie sądzi, a wprowadza wielokrotnie mniej problemów niż rozdrobniona sieć mikroserwisów utrzymywana przez trzy osoby. Podział na osobne usługi proponujemy wtedy, gdy istnieje realny powód: różne tempo zmian, różne wymagania co do skalowania albo osobne zespoły.
Odporność i utrzymanie
Projektujemy przy założeniu, że elementy zawodzą: baza bywa niedostępna, zewnętrzne API zwalnia, wdrożenie trzeba wycofać. Praktyczne konsekwencje to limity czasu na każde wywołanie zewnętrzne, mechanizmy odcinające usługi, które przestały odpowiadać, oraz operacje bezpieczne przy powtórzeniu.
Do tego dochodzi warstwa obserwacji: dzienniki zdarzeń, metryki i śledzenie żądań przez system. Bez niej diagnoza awarii sprowadza się do zgadywania, a średni czas naprawy liczy się w godzinach zamiast w minutach. Uzupełniamy to o sprawdzone kopie zapasowe - kopia, której nigdy nie odtworzono, jest tylko założeniem.
Co dostajesz na koniec
Dokument architektury napisany tak, żeby przeczytał go zarówno programista, jak i osoba podejmująca decyzje o budżecie. Zawiera opis decyzji wraz z uzasadnieniem i odrzuconymi wariantami, bo za rok najważniejsze będzie pytanie, dlaczego zrobiono tak, a nie inaczej.
Do tego plan wdrożenia podzielony na etapy z szacunkiem pracochłonności oraz lista rzeczy, których świadomie nie robimy teraz. Możemy plan wykonać razem z Twoim zespołem albo przekazać go w całości - obie drogi są dla nas w porządku, bo wartość audytu tkwi w decyzjach, nie w tym, kto trzyma klawiaturę.
Najczęściej zadawane pytania
Ile trwa audyt architektury?
Czas zależy od wielkości systemu i liczby integracji, więc ustalamy go indywidualnie po wstępnej rozmowie. Audyt zawsze dzieli się na te same etapy: rozmowy i przegląd kodu, pomiary, a na końcu opracowanie raportu oraz omówienie go z zespołem.
Czy musimy przepisać system od zera?
Prawie nigdy. Przepisanie od zera jest najdroższą i najbardziej ryzykowną opcją, bo na czas przepisywania rozwój zatrzymuje się całkowicie. W większości przypadków da się wydzielać i wymieniać fragmenty stopniowo, przy działającym systemie.
Czy potrzebujecie dostępu do naszego kodu?
Do rzetelnego audytu tak, choć wystarczy dostęp do odczytu i możemy podpisać umowę o poufności przed rozpoczęciem. Da się też przeprowadzić węższą ocenę wyłącznie na podstawie dokumentacji i rozmów, ale wtedy wyraźnie zaznaczamy, czego nie zweryfikowaliśmy.
Mikroserwisy czy jedna aplikacja?
To zależy od tempa zmian i liczby zespołów, nie od mody. Przy jednym lub dwóch zespołach dobrze podzielona pojedyncza aplikacja jest zwykle tańsza w utrzymaniu i szybsza w rozwoju. Podział rekomendujemy, gdy istnieje konkretny powód, który da się nazwać.
Czy pomożecie wdrożyć rekomendacje?
Tak, i robimy to najczęściej. Możemy poprowadzić wdrożenie w całości, pracować ramię w ramię z Twoim zespołem albo pełnić rolę wsparcia przy trudniejszych etapach.
Ile kosztuje audyt architektury?
Koszt wynika z czasu potrzebnego na przegląd, a ten zależy od wielkości systemu i liczby integracji. Po wstępnej rozmowie i pobieżnym spojrzeniu na repozytorium podajemy widełki oraz zakres, który się w nich mieści. Jeżeli w trakcie okaże się, że trzeba zajrzeć głębiej, ustalamy to osobno, zamiast po cichu rozszerzać rachunek.
Czy audyt ma sens przy małym systemie?
Przy naprawdę małym systemie zwykle wystarczy krótsza konsultacja zamiast pełnego audytu - kilka godzin rozmowy i przeglądu kodu odpowiada wtedy na te same pytania. Mówimy o tym na starcie, bo płacenie za pełny, wielotygodniowy proces tam, gdzie wystarczy dzień, jest po prostu marnowaniem budżetu.
Porozmawiajmy o Twoim projekcie
Opisz nam swój projekt, a wrócimy do Ciebie z wyceną i orientacyjnym terminem. Każdy projekt wyceniamy indywidualnie, bo koszt i czas zależą od zakresu. Wstępna rozmowa jest bezpłatna i do niczego nie zobowiązuje.