Audyt obecnych rozwiązań

Celem jest zamiana wrażeń na pomiary. Nie ogólna opinia, że system jest przestarzały, tylko lista: to zapytanie trwa jedenaście sekund pod obciążeniem, ta zależność ma opublikowaną podatność, czas tego zadania rośnie liniowo wraz z tabelą zamówień, tej kopii zapasowej nigdy nie odtworzono. Z ustaleniami w takiej formie da się pracować, można je wycenić i zaplanować. Z ogólnymi opiniami nie.

Wychodzi z tego określona klasa problemów: pakiety zapóźnione o lata, z opublikowanymi podatnościami; dane uwierzytelniające zapisane tam, gdzie nie powinny się znaleźć; konfiguracja stagingu i produkcji, która po cichu się rozjechała, przez co testowanie na stagingu dowodzi mniej, niż wszyscy zakładają; oraz ręczne kroki we wdrożeniu, które potrafi wykonać tylko jedna osoba. Żadne z tego nie wymaga obciążenia, żeby je znaleźć. Wszystko potrafi zaboleć w najgorszym momencie.

Te dwie rzeczy rozjeżdżają się w większości przypadków. Zespoły optymalizują funkcję napisaną ostatnio i przeoczają wywołanie ORM, które po cichu wykonuje się raz na każdy wiersz. Patrzymy na plany zapytań, ślady żądań, poziom błędów i zużycie zasobów przy realnym ruchu, a tam gdzie obraz jest niepełny, sami generujemy obciążenie, żeby znaleźć sufit świadomie, zamiast czekać, aż odkryje go premiera.

Efektem jest liczba zamiast przymiotnika. „System obsłuży mniej więcej taką współbieżność, zanim czasy odpowiedzi przekroczą Twój próg, a ogranicza go pula połączeń do bazy” to coś, na czym da się oprzeć plan. „Może się nie skalować” nie jest.

Kopie zapasowe, które wykonują się poprawnie, ale nigdy nie zostały odtworzone. Failover skonfigurowany dwa lata temu, który dziś by nie zadziałał, bo instancja zapasowa ma inną wersję. Procedura wycofania wdrożenia opisana w dokumencie, lecz nigdy nieprzećwiczona, więc pierwsza próba wypada w trakcie awarii. Zewnętrzna usługa bez ustawionego timeoutu, przez co jej zawieszenie zawiesza także Twoją aplikację.

Przechodzimy przez to celowo, bo sprawdzenie jest tanie, a odkrywanie tego na żywo bardzo drogie.

Warto nazwać jeszcze jedną, pokrewną kategorię: rzeczy, o których wie tylko jedna osoba. Krok wdrożeniowy istniejący w czyjejś historii poleceń. Komponent, którego nikt inny nigdy nie modyfikował. Konto u dostawcy założone na prywatny adres jednego pracownika. To nie są usterki techniczne i nie pojawią się na żadnym wykresie w monitoringu, ale zachowują się dokładnie jak pojedyncze punkty awarii. Odchodzą razem z tą osobą.

Ten podział ma znaczenie, bo trzecia kategoria to dokładnie to, co zespoły chcą naprawiać najpierw. Porządkowanie kodu daje satysfakcję i widać jego efekt. Zwykle jest też najmniej pilną pozycją na liście. Audyt jest najbardziej użyteczny wtedy, gdy daje przyzwolenie, żeby zostawić brzydki kod w spokoju i poświęcić ten sam tydzień na upewnienie się, że potrafisz odtworzyć bazę danych.

Część ustaleń będzie tym, co Twój zespół zgłaszał już wcześniej. To w porządku i często o to właśnie chodzi. Zewnętrzny pomiar bywa tym, co sprawia, że wewnętrznie znany problem zostaje potraktowany poważnie i doczekuje się budżetu.