Oprogramowanie i inżynieria systemów
Audyt architektury i niezawodności oprogramowania na produkcji.
Może widzisz zdarzenia, które giną między serwisami, płatności zapisane dwa razy, przekroczenia czasu odpowiedzi pojawiające się dopiero pod obciążeniem albo dwa systemy, które inaczej pokazują to samo zamówienie.
Kiedy system zawodzi w sposób, którego twój zespół nie potrafi do końca wyjaśnić, albo wkrótce ma przyjąć znacznie większe obciążenie, niż przewidziano przy jego budowie, niezależny przegląd pokazuje, które ryzyka są poważne i od których zacząć.
Przykład jednego żądania płatności prześledzonego od początku do końca. Żądanie przychodzi z finalizacji zamówienia, przechodzi walidację i jest przetwarzane, łącznie z wywołaniem operatora płatności. Operator nie odpowiada w wyznaczonym czasie i to jest miejsce, które audyt bada. Odzyskanie polega na ponowieniu żądania bez drugiego obciążenia klienta.
Kiedy audyt ma uzasadnienie
Audyt przydaje się najbardziej po serii problemów, których nikt nie potrafi do końca wyjaśnić, albo przed zmianą, w której pomyłka byłaby kosztowna.
Problemy, które już widać
Awarie wracają
Po każdej poprawce wraca ten sam rodzaj awarii, a jej przyczyna wciąż nie jest pewna.
Zdarzenia giną albo przychodzą dwa razy
Komunikaty między serwisami giną, dublują się albo są przetwarzane w złej kolejności.
Systemy różnie pokazują te same dane
Zamówienie, płatność albo stan magazynowy wygląda inaczej w zależności od tego, gdzie sprawdzasz.
Przekroczenia czasu pod obciążeniem
W testach wszystko działa, a gdy ruch rośnie, system zwalnia albo przestaje odpowiadać.
Zmiany, które się zbliżają
Firmę czeka etap wzrostu
Więcej klientów, nowy rynek albo duża integracja obciążą system bardziej, niż przewidziano przy jego budowie.
W planach jest przepisanie lub migracja
Chcesz wiedzieć, co jest nie tak, zanim zdecydujesz o przebudowie, podziale albo przeniesieniu systemu.
System przejął nowy zespół
Osoby, które go zbudowały, zajęły się czymś innym, a zespół, który teraz go utrzymuje, potrzebuje rzetelnego obrazu jego działania.
Co sprawdzamy
Zakres każdego audytu ustalamy dla konkretnego systemu i pytań, na które potrzebujesz odpowiedzi. Oto obszary, które obejmuje audyt, i przykładowe pytania, jakie zadajemy w każdym z nich.
- 01
Granice serwisów i powiązania między nimi
Czy granice między serwisami wynikają z logiki biznesu, czy z historii kodu? Które serwisy muszą działać jednocześnie, żeby jedna akcja klienta się powiodła, i czy projekt systemu uwzględnia tę zależność?
- 02
Kolejki, komunikaty i dostarczanie zdarzeń
Czy komunikat może zginąć między publikacją a przetworzeniem? Co dzieje się z komunikatami, których przetwarzanie stale się nie udaje? Czy któraś część systemu zakłada kolejność zdarzeń, której infrastruktura nie gwarantuje?
- 03
Ponawianie i limity czasu
Co dzieje się dalej, gdy wywołanie przekroczy limit czasu, ale operacja w rzeczywistości się powiodła? Ponawianie na kilku warstwach naraz może w czasie incydentu zwielokrotnić obciążenie, a limity czasu w łańcuchu wywołań muszą do siebie pasować; sprawdzamy jedno i drugie.
- 04
Idempotentność
Czy każdą operację, która może zostać ponowiona albo dostarczona ponownie, da się bezpiecznie wykonać dwa razy? Ma to największe znaczenie tam, gdzie chodzi o pieniądze, rozliczenia albo stany magazynowe. Operacja idempotentna daje ten sam efekt bez względu na to, czy wykona się raz, czy kilka razy.
- 05
Transakcje i spójność danych
Gdy operacja biznesowa obejmuje więcej niż jedną bazę danych lub serwis, sprawdzamy, co utrzymuje zgodność danych, kiedy jeden z kroków zawiedzie w połowie.
- 06
Odporność i scenariusze awarii
Co robi system, gdy zależność działa wolno, a nie przestaje działać całkiem? Czy praca w trybie ograniczonym jest zaprojektowana, czy dzieje się przypadkiem?
- 07
Wydajność i skalowanie
Szukamy miejsca, w które najpierw uderzy kolejny etap wzrostu: bazy danych, wspólnej blokady, długiego łańcucha synchronicznych wywołań albo limitu u zewnętrznego dostawcy.
- 08
Obserwowalność i ryzyko operacyjne
Czy twój zespół może prześledzić, co stało się z pojedynczym żądaniem albo zdarzeniem, korzystając z logów, metryk i śledzenia rozproszonego? Czy alerty wskazują rzeczywisty wpływ na użytkowników? Które części systemu zależą od wiedzy jednej osoby?
- 09
Kod, gdy odpowiada na pytanie
Na niektóre pytania odpowiedź jest tylko w kodzie, na przykład jak klient ponawia żądanie płatności albo kiedy konsument potwierdza odbiór komunikatu. Jeśli to część uzgodnionego zakresu, czytamy odpowiedni kod. To przegląd celowany, a nie audyt całego kodu linia po linii.
Co otrzymujesz
Audyt kończy się raportem na piśmie, z którym twój zespół może dalej pracować, oraz wspólnym omówieniem wyników.
- 01
Ocena stanu obecnego
Jak system działa dziś, łącznie z przepływami, których nikt nigdy nie spisał. Dla zespołu, który przejął system po innych, już to bywa przydatne.
- 02
Ryzyka poparte dowodami
Każde ustalenie wskazuje, co zaobserwowaliśmy, na przykład konfigurację, ścieżkę w kodzie, wzorzec w logach albo przebieg incydentu, i wyjaśnia, dlaczego ma to znaczenie. Ryzyka oceniamy według prawdopodobieństwa i możliwych szkód.
- 03
Zalecenia według priorytetów
Co zmienić, w jakiej kolejności i dlaczego właśnie w takiej. Zmiany, które niskim kosztem usuwają poważne ryzyko, są wyraźnie oznaczone, więc lista przydaje się nawet wtedy, gdy uda się wykonać tylko jej część.
- 04
Plan usprawnień
Realistyczna kolejność prac, dopasowana do możliwości twojego zespołu, którą mogą przeprowadzić twoi inżynierowie albo my.
- 05
Omówienie wyników
Spotkanie robocze z twoim zespołem: przechodzimy przez ustalenia, konfrontujemy nasze wnioski z wiedzą zespołu i odpowiadamy na pytania.
Przykładowe ustalenie, napisane na potrzeby tej strony
Wyobraź sobie sklep internetowy z osobnymi serwisami płatności i zamówień.
P1Żądanie płatności, które przekroczy limit czasu, jest ponawiane i może obciążyć klienta dwa razy
- Obszary
- Idempotentność; Ponawianie i limity czasu
- Dowody
- W tym przykładzie koszyk ponawia wywołanie płatności po przekroczeniu limitu czasu bez klucza idempotencji, więc w logu operatora płatności mogą się pojawić dwa obciążenia za jedno zamówienie.
- Dlaczego to ważne
- Klient może zostać obciążony dwa razy, a każdy taki przypadek trzeba znaleźć i zwrócić ręcznie.
- Zalecenie
- Wysyłać klucz idempotencji z każdym żądaniem płatności i zapisywać przy nim odpowiedź operatora.
Niski koszt, usuwa poważne ryzyko
- P2Komunikaty, których przetwarzanie stale się nie udaje, są ponawiane bez limitu i mogą zablokować kolejkę
- P3Jedno zamówienie trudno prześledzić w logach przez kilka serwisów
Jak przebiega audyt
Każdy audyt przebiega według tego samego schematu. Czas trwania i to, ile czasu potrzeba od twojego zespołu, ustalamy przy określaniu zakresu.
- 01
Rozmowa o zakresie
Ustalamy, na jakie pytania ma odpowiedzieć audyt, które systemy obejmuje i czy obejmuje czytanie kodu.
- 02
Dostęp i poufność
Sposób dostępu i ochrony twoich informacji ustalamy, zanim jakikolwiek dostęp zostanie przyznany.
- 03
Rozmowy i dowody
Rozmawiamy z osobami, które budują i utrzymują system, oraz przeglądamy jego architekturę, konfigurację, logi, metryki i historię incydentów, a także kod, jeśli jest w zakresie.
- 04
Omówienie wyników
Przechodzimy przez ustalenia z twoim zespołem, konfrontujemy wnioski z jego wiedzą i odpowiadamy na pytania.
- 05
Raport na piśmie
Ocena stanu, ryzyka poparte dowodami, zalecenia według priorytetów i plan usprawnień w jednym dokumencie, który zostaje u twojego zespołu.
- 06
Dalsza współpraca, jeśli chcesz
Plan mogą zrealizować twoi inżynierowie albo my, jako osobną pracę w ramach usługi Dedykowane oprogramowanie.
Kto przeprowadza audyt
Audyt opiera się na doświadczeniu założyciela w systemach rozproszonych, niezawodności i odporności na awarie. Unbelievable Software założył w 2022 roku Bartłomiej Różycki, którego doświadczenie obejmuje systemy backendowe w fintechu i e-commerce.
Czego audyt nie obejmuje
Audyt nie obiecuje, że system nigdy nie zawiedzie, ani żadnego konkretnego wyniku. Pokazuje, gdzie są poważne ryzyka i którymi zająć się najpierw.
Usunięcie wykrytych problemów to osobna praca, którą może wykonać twój zespół albo my.
Kod czytamy tylko wtedy, gdy odpowiada na pytanie z uzgodnionego zakresu. Nie każdy audyt obejmuje przegląd kodu i żaden nie obejmuje całego kodu.
Pytania przed audytem
Jakiego dostępu potrzebujecie?
To zależy od uzgodnionych pytań. Przeglądamy architekturę, konfigurację, logi, metryki i historię incydentów, a kod tylko wtedy, gdy jego przegląd jest w zakresie. Dostęp ustalamy, zanim zostanie przyznany.
Ile to trwa i ile czasu zajmie naszemu zespołowi?
Jedno i drugie ustalamy przy określaniu zakresu, kiedy znamy już wielkość systemu i pytania, na które potrzebujesz odpowiedzi.
Czy audyt jest poufny?
Zasady poufności ustalamy w ramach określania zakresu, zanim uzyskamy dostęp do twoich systemów lub informacji.
Czy przeglądacie cały nasz kod?
Nie. Jeśli na pytanie da się odpowiedzieć tylko w kodzie, a przegląd kodu jest w uzgodnionym zakresie, czytamy odpowiedni fragment. To nie jest przegląd wyczerpujący.
Co dzieje się po raporcie?
Twój zespół może samodzielnie realizować plan. Jeśli potrzebujesz pomocy, możemy wprowadzić zmiany w ramach osobnego zlecenia.
Zacznij od pytań, na które potrzebujesz odpowiedzi
Opisz system i to, co cię w nim niepokoi. Odpowiadamy e-mailem, zwykle z pytaniami albo propozycją rozmowy.