Stabilność , skalowalność i diagnozowalność

1. Stabilność, skalowalnośćidiagnozowalność czylilubięspać w nocy….

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

3. Czegochceklient? Funkcjonalność!

4. O czymniemyślisię w czasieimplementacji • Reakcjanasytuacjewyjątkowe • Problemy z siecią/serwisami • Instalacja • Diagnostyka • Przywracaniesystemu do życia • Monitoring

5. Co to znaczyniestabilny?

6. Na podstawie “Release IT”

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

8. Punktyintegracji?

9. Punktupadku? Każdypunktintegracjikiedyśwybuchnie. Niewiadomotylko: • Kiedy • Jakczęsto to siępowtórzy • Jakiebędąobjawy… • Błądprzewidywalny • Błądnieprzewidziany • Dużeopóznienie • Zwistotalny… • Mega wielkizwrot

10. Wartorozmawiać… Należy • PoszukaćPunktówintegracjiizastanowićsię: • Jakiebłędysąobsługiwane? • Co jeślipojawisięnieoczekiwanybłąd? • Co jeślisterowanieniewróci w ogóle? • Co gdyniebedziebłędu ale danebędąbezsensu –np. pustyzwrot? • Co gdyzwrotbędzieolbrzymi? • Co będziegdybędziemycośzmieniać w serwisie?

11. Punktintegracjiczyli co jest potamtejstronie…

12. Brakodpowiedzi

13. Brakodpowiedzi… • Czymożemyżyćbezdziałającejusługi? czyli jaka jest różnicamiędzy 5x9 a 2x8 99.999% vs 88%

14. Dostępnośćsystemu • Różnicamiędzy 99.999% a 88% wynosi 1051h w skaliroku • Przykoszcieopóźnieńrzędu 1k$/h daje to kwotę ponadmilion $ • Wiele firm wycenia 1h na 100k$

15. Czy to naprawdępotrzebne? DB - klienci Serwisobsługaklientów DB - księgowość Serwisksięgowy Serwisreklamowy DB - cennik Aplikacja WWW Przeglądarka

16. Czy to naprawdępotrzebne? • Czy do pokazaniatowarówpotrzebaaktualnychreklam ? Promocji? • Czymożnażyćnp. bezdanychklientów? Czasemmożna – czasemmamy je w cisteczkachi w sytuacjiwyjątkowejmożemyichniedoczytywać z serwisu.

17. Fail Fast

18. Fail Fast • Dużolepiejszybkozasygnalizowaćbłądniżpróbowaćobsłużyć go naniskimpoziomienp. przezpowtórzenia • Dlabazydanychpowtórzeniemożemiećsens (np. w przypadku deadlock-ów) • Lepiejzwalidowaćdaneprzed a nienakońcutransakcji • Lepiejupewnićsię, żemamypotrzebnewszsytkiezasobyzanimrozpoczniemyczasochlonneprzetwarzanie (np. zawołamyzewnętrzneserwisy)

19. Fail Fast – czarnyscenariusz • bazaserwisuobsługaklientówledwożyje (właśnieliczony jest rocznyraport). • próbujemykupićcoś w sklepie (jakwieluinnych) ?

20. Time Out • Zawszegdytylkomożnapowinienbyćustawiany • Zwyklewartodaćmożliwośćkonfiguracji

21. Circuit Breaker • Jeśliserwisnp. marketingustwierdza, że ma problem z baza (npdługiczasodpowiedzi) odrazuraportujebłądnp. przez 1 min żebydaćczasbazienapodniesieniesię.

22. Hand Shaking • Zamiastodrazupytaćserwis o pot dużedane (zwłaszanastarcielubpojakimśczasiebezczynności) możnanajpierwzapitać go o status • Start systemu – porestarcie …

23. Slow responses Ulubionezajęcieznudzonegoklienta: “Odśwież” Długiczasodpowiedzi: • Blokujełańcuchpytających - wątki, pamięć Ew. timeout iponowienienieanulująpoprzedniegożądania, czyli jest jeszczegorzej. Co z pomysłem by nieobsługiwaćkolejnyćżadań z tegosamego IP?

24. Co to jest? Zasadaodwróconego SLA.

25. Jedno z rozwiązań - publish DB - klienci DB – księgowość + Obrazdanychklientów Serwisobsługaklientów Serwisksięgowy DB – cennik + Obrazdanychksięgowych, klienckich Serwisreklamowy Aplikacja WWW Przeglądarka

26. Użytkownicy to zło ... konieczne Sąrózni – wieluprzeglądamałokupuje Dodatkowosą: • promocje • boty • hakerzy

27. Sesje Pyt: długieczykrótkie ? Odp: Lekkie, a najlepiejwcale • Użytkownikniewie co to zamykaniesesji – ulubionysposóbwyjścia to przejściegdzieindziej, a niewyloguj • Botnieobsługujeciastek – co oznacza …domyślnienowąsesjędlakażdegożądania – np. żebyodpowiedzieć “temupanudziękujemy”

28. Reakcjałańcuchowa Przetwarzaniezleceń Przetwarzaniezleceń Przetwarzaniezleceń Aplikacja WWW Przeglądarka

29. Czy system musiznieśćwszystko ? Powinien • dobrzedziałać w typowychwarunkach • przetrwać (niekoniecznie super wydajnie) ektremalnewarunki – promocje, święta

30. Bulkheads? • WartorozważyćoddzielneQoSdlaróżnychtypówklientów, usługitdnp. przezwydzielenieoddzielnychpodsystemów • Kompromis: skalowanie vs. stabilność

31. Wycieki Pamięć Połączenia do bazy, Wątki Duży problem dladługodziałającychaplikacji

32. Diagnostyka • Monitorowanie: pamięć, dysk, zasoby, sieciowewołania, wolumendanych, stanpunktówintegracji, • Logowanie: wyjątki, błędnewołania, problemysieciowe (+ kontekst), ale bezujawnianiaszczegłówużytkownikom

33. Fiddling • Aplikacjawymagarestartów • Aplikacjawymagaczyszczeniadysku (rolowanielogów) • Skomplikowany start/restart • Trudnakonfiguracja

34. Health Check • Strona z syntetycznąprezentacjąstanusystemu • Self testy

35. Test Harnes • Przytestowaniu (manualnym) testujemynietylko “heapy path” • Staramysiędociekliwi, nieprzewidywalni, poprostuwredni • Testy automatyczneniezatąpiątesterów Np. • wyjmowaniekabelkowsieciowych to wcalenietakizłypomysł. • złośliwegenerowaniedużychzwrotówczypsuciedanychmożebyćtrudne do uzyskania w normalnymtrybietestowania

36. Ktoza to zapłaci? • Budując “proof of concept” systemumusimyzbudować go tanio– to tylkomakieta • Żadendziałającykomercyjnyduży system niebyłpisanyjakoduży system… • R 1.0 to poczatekżyciasystemu (a niekoniec) • Niemożnadodaćwszystkiegonaraz, ale to nieznaczyżemożnaniedodawaćwcale • Różnicamiędzystanemobecnym a docelowym to … długtechniczny

37. Z drugiejstrony? • Często jest takzedecyzjepodjetenapoczatkudeterminujakształt (istabilnosc) • Na początkuwiemy o systemienajmniej..