Stabilność, skalowalność i diagnozowalność czyli lubię spać w nocy….

Inspiracja “Feature complete” is not the same as “production ready” Michael T. Nygard

Czego chce klient? Funkcjonalność!

O czym nie myśli się w czasie implementacji Reakcja na sytuacje wyjątkowe Problemy z siecią/serwisami Instalacja Diagnostyka Przywracanie systemu do życia Monitoring

Co to znaczy niestabilny?

Na podstawie “Release IT”

Integration point I haven’t seen a “pure-website” project since about If your projects are like mine, they have probably been enterprise integration projects that happen to have an HTML-based front end. Punkt styku 2 podsystemów:  RPC, wołanie Com-a, Socket, WCF  Baza danych?

Punkty integracji?

Punkt upadku? Każdy punkt integracji kiedyś wybuchnie. Nie wiadomo tylko: Kiedy Jak często to się powtórzy Jakie będą objawy…  Błąd przewidywalny  Błąd nieprzewidziany  Duże opóznienie  Zwis totalny…  Mega wielki zwrot

Warto rozmawiać… Należy Poszukać Punktów integracji i zastanowić się: Jakie błędy są obsługiwane? Co jeśli pojawi się nieoczekiwany błąd? Co jeśli sterowanie nie wróci w ogóle? Co gdy nie bedzie błędu ale dane będą bez sensu –np. pusty zwrot? Co gdy zwrot będzie olbrzymi? Co będzie gdy będziemy coś zmieniać w serwisie?

Punkt integracji czyli co jest po tamtej stronie…

Brak odpowiedzi

Brak odpowiedzi… Czy możemy żyć bez działającej usługi? czyli jaka jest różnica między 5x9 a 2x % vs 88%

Dostępność systemu Różnica między % a 88% wynosi 1051h w skali roku Przy koszcie opóźnień rzędu 1k$/h daje to kwotę ponad milion $ Wiele firm wycenia 1h na 100k$

DB - klienci DB - księgowość DB - cennik Czy to naprawdę potrzebne? Aplikacja WWW Serwis księgowy Serwis reklamowy Serwis obsługa klientów Przeglądar ka

Czy to naprawdę potrzebne? Czy do pokazania towarów potrzeba aktualnych reklam ? Promocji? Czy można żyć np. bez danych klientów? Czasem można – czasem mamy je w cisteczkach i w sytuacji wyjątkowej możemy ich nie doczytywać z serwisu.

Fail Fast

Dużo lepiej szybko zasygnalizować błąd niż próbować obsłużyć go na niskim poziomie np. przez powtórzenia Dla bazy danych powtórzenie może mieć sens (np. w przypadku deadlock-ów) Lepiej zwalidować dane przed a nie na końcu transakcji Lepiej upewnić się, że mamy potrzebne wszsytkie zasoby zanim rozpoczniemy czasochlonne przetwarzanie (np. zawołamy zewnętrzne serwisy)

Fail Fast – czarny scenariusz baza serwisu obsługa klientów ledwo żyje (właśnie liczony jest roczny raport). próbujemy kupić coś w sklepie (jak wielu innych) ?

Time Out Zawsze gdy tylko można powinien być ustawiany Zwykle warto dać możliwość konfiguracji

Circuit Breaker Jeśli serwis np. marketingu stwierdza, że ma problem z baza (np długi czas odpowiedzi) od razu raportuje błąd np. przez 1 min żeby dać czas bazie na podniesienie się.

Hand Shaking Zamiast od razu pytać serwis o pot duże dane (zwłasza na starcie lub po jakimś czasie bezczynności) można najpierw zapitać go o status Start systemu – po restarcie …

Slow responses Ulubione zajęcie znudzonego klienta: “Odśwież” Długi czas odpowiedzi: Blokuje łańcuch pytających - wątki, pamięć Ew. timeout i ponowienie nie anulują poprzedniego żądania, czyli jest jeszcze gorzej. Co z pomysłem by nie obsługiwać kolejnyć żadań z tego samego IP?

Co to jest? Zasada odwróconego SLA.

DB – cennik + Obraz danych księgowych, klienckich DB – księgowość + Obraz danych klientów DB - klienci Jedno z rozwiązań - publish Aplikacja WWW Serwis księgowy Serwis reklamowy Serwis obsługa klientów Przeglądark a

Użytkownicy to zło... konieczne Są rózni – wielu przegląda mało kupuje Dodatkowo są: promocje boty hakerzy

Sesje Pyt: długie czy krótkie ? Odp: Lekkie, a najlepiej wcale - Użytkownik nie wie co to zamykanie sesji – ulubiony sposób wyjścia to przejście gdzie indziej, a nie wyloguj Bot nie obsługuje ciastek – co oznacza … domyślnie nową sesję dla każdego żądania – np. żeby odpowiedzieć “temu panu dziękujemy”

Reakcja łańcuchowa Aplikacja WWW Przetwarzani e zleceń Przeglądar ka Przetwarzani e zleceń

Czy system musi znieść wszystko ? Powinien dobrze działać w typowych warunkach przetrwać (niekoniecznie super wydajnie) ektremalne warunki – promocje, święta

Bulkheads? Warto rozważyć oddzielne QoS dla różnych typów klientów, usług itd np. przez wydzielenie oddzielnych podsystemów Kompromis: skalowanie vs. stabilność

Wycieki Pamięć Połączenia do bazy, Wątki Duży problem dla długo działających aplikacji

Diagnostyka Monitorowanie: pamięć, dysk, zasoby, sieciowe wołania, wolumen danych, stan punktów integracji, Logowanie: wyjątki, błędne wołania, problemy sieciowe (+ kontekst), ale bez ujawniania szczegłów użytkownikom

Fiddling Aplikacja wymaga restartów Aplikacja wymaga czyszczenia dysku (rolowanie logów) Skomplikowany start/restart Trudna konfiguracja

Health Check Strona z syntetyczną prezentacją stanu systemu Self testy

Test Harnes Przy testowaniu (manualnym) testujemy nie tylko “heapy path” Staramy się dociekliwi, nieprzewidywalni, po prostu wredni Testy automatyczne nie zatąpią testerów Np. wyjmowanie kabelkow sieciowych to wcale nie taki zły pomysł. złośliwe generowanie dużych zwrotów czy psucie danych może być trudne do uzyskania w normalnym trybie testowania

Kto za to zapłaci? Budując “proof of concept” systemu musimy zbudować go tanio – to tylko makieta Żaden działający komercyjny duży system nie był pisany jako duży system… R 1.0 to poczatek życia systemu (a nie koniec) Nie można dodać wszystkiego na raz, ale to nie znaczy że można nie dodawać wcale Różnica między stanem obecnym a docelowym to … dług techniczny

Z drugiej strony? Często jest tak ze decyzje podjete na poczatku determinuja kształt (i stabilnosc) Na początku wiemy o systemie najmniej..