Site reliability engineering

Krzysztof Kempiński
Jul 19 · 13 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Grzegorzem Agacińskim o site reliability engineering.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to VP of Engineering w Nobl9, amerykańskim startupie budującym platformę do monitorowania wskaźników niezawodności systemów informatycznych

Na co dzień buduje i rozwija zespół deweloperski w oddziale Nobl9 w Poznaniu, który na ten moment liczy 40 osób. Wcześniej przez wiele lat był programistą, managerem i twórca kilku startupów.

Moim i Waszym gościem jest Grzegorz Agaciński.

Cześć, Grzegorz! Bardzo miło mi gościć cię w podcaście.

Cześć Krzysztofie, również bardzo miło mi gościć! Cieszę się, że będę mógł podzielić się wiedzą na temat SLO z twoją publicznością!

Dokładnie, bardzo ci dziękuję za przedstawienie i oczywiście to będzie temat naszej rozmowy site reliability engineering i tematy poboczne, czyli Grzegorz, twoja specjalizacja, więc bardzo się cieszę na to, że będę sam się też mógł dowiedzieć więcej o tym temacie.

Chciałbym rozpocząć standardowo, jak każdy podcast, który jest tutaj moim też udziałem, czyli zapytać cię, Grzegorz, czy słuchasz podcastów i jeśli tak, to może masz jakieś swoje ulubione, którymi mógłbyś podzielić się ze słuchaczami?

Nie mam za wiele czasu na słuchanie. Preferuję też trochę bardziej wizualną formę przekazu. Poza twoim podcastem, którego słucham mogę polecić Soft Skills Engineering, jak sama nazwa wskazuje, traktuje o często niełatwych dla ludzi technicznych tematach miękkich.

Bardzo polecam — podwyżki, awanse, różne tematy, można zadawać różne pytania i są poruszane w zabawny sposób. A także polecam podcast mojego kolegi, który się nazywa Internet Czas Działać. Jest to podcast o prywatności, prawach użytkowników i szeroko rozumianej wolności w internecie.

Z YouTuberów od tej wizualnej części to bardzo lubię Marka Robera, taki popularnonaukowy kanał, a także dla pośmiania się Last Week Tonight z Johnem Oliverem.

Bardzo fajne rekomendacje, dzięki wielkie!

Dziś będziemy dużo mówić o ogólno rozumianej niezawodności, oczywiście w ramach systemów informatycznych. Może warto byłoby zdefiniować czym jest niezawodność, czym jest reliability, które będzie dzisiaj wiele razy padało i czy ono istnieje w ramach ogólnie rozumianych systemów informatycznych czy tylko stron internetowych?

Gdybyś mógł więcej powiedzieć na ten temat.

Dosłownym i popularnym rozumieniu w branży, niezawodność jest rozumiana jako sam fakt czy twoja strona lub serwer działa lub nie albo na ile jest dostępna lub niedostępna dla twoich użytkowników.

Dosłownym i popularnym rozumieniu w branży, niezawodność jest rozumiana jako sam fakt czy twoja strona lub serwer działa lub nie albo na ile jest dostępna lub niedostępna dla twoich użytkowników.

My z kolei w Nobl9 reliability rozumiemy jako coś bardziej złożonego i również najczęściej związanego z interakcją z użytkownikiem. Mówimy o niezawodności usług, ale usług rozumianych niekoniecznie jako jeden endpoint, jedna strona, serwer, ale np. cała grupa usług realizujących konkretną, jedną usługę, np. dla użytkownika.

Taki przykład — reset hasła z jakimś potwierdzeniem mailowym. To jest wieloetapowy proces, w którym ktoś podaje maila, klika na stronie, mail przychodzi do użytkownika, klika w ten link w mailu, ustawia sobie nowe hasło. To jest cały proces, który ileś trwa, który ma ileś etapów i z punktu widzenia niezawodności możemy spojrzeć na niezawodność całego takiego procesu, a niekoniecznie poszczególnych jego elementów.

My niezawodność możemy rozumieć, jako też możliwość wykonania danej czynności przez użytkownika.

Faktycznie takie szersze spojrzenie, ale wydaje mi się, że istotniejsze. My jako inżynierowie, jako osoby zajmujące się technologią patrzymy niskopoziomowo, tak jak powiedziałeś. Czy ten mikro serwis działa, czy ta usługa, ta baza danych działa, natomiast dla użytkownika końcowego to tak nie do końca ma znaczenie. Dla niego istotne jest to, czy może się zalogować, kliknąć, wygenerować raport itd.

Zastanawiam się skąd to pojęcie, ten trend, ten zespół technologii, bo dopiero dziś będziemy to sobie definiować. Skąd to się wzięło? Kto to zdefiniował? Jakie były początki SRE, gdybyś mógł to jakoś określić?

Początki SRE leżą tak jak wiele innych, ciekawych tematów — w Google. W takim tradycyjnym modelu tworzenia usług, który do dzisiaj też funkcjonuje w wielu miejscach. Operatorzy czy role odpowiedzialne za infrastrukturę są odpowiedzialne za dostarczenie deweloperom lub działowi, produktowi platformy, serwera, na której będą mogli uruchomić swoją wytworzoną aplikację.

Jedni nie do końca się drugimi interesują, bo ludziom od infrastruktury zależy, żeby ona działała stabilnie, a z kolei deweloperzy chcą dostarczać nowe wersje aplikacji. Tu się robią takie silosy między tymi dwoma działami i zarazem tarcia, bo każdy nowy deployment może zdestabilizować infrastrukturę i wówczas wymaga jakiejś pracy, czasami też manualnej, system operatorów, a oni są najczęściej rozliczani właśnie z tego, jak stabilnie lub niezgodnie ta infrastruktura działa.

Z kolei deweloperzy chcą wypuszczać nowe funkcjonalności jak najszybciej. Za to są rozliczani .I to widzimy ewidentny konflikt interesów — jedni chcą, aby serwer, usługa działała stabilnie, a drudzy chcą jak najszybciej dostarczać nowe funkcjonalności, które mogą to destabilizować.

W Google zrozumieli, że takie podejście się nie sprawdza. Postanowili podejść do problemu samej infrastruktury jako zagadnienia software i znalezienia jakiegoś kompromisu między potrzebami infrastruktury i produktu, a co najważniejsze, zaakceptować, że ryzyko, że coś nie działa istnieje i trzeba, i można nim zarządzać.

Z kolei deweloperzy chcą wypuszczać nowe funkcjonalności jak najszybciej. Za to są rozliczani .I to widzimy ewidentny konflikt interesów — jedni chcą, aby serwer, usługa działała stabilnie, a drudzy chcą jak najszybciej dostarczać nowe funkcjonalności, które mogą to destabilizować.

W Google zrozumieli, że takie podejście się nie sprawdza. Postanowili podejść do problemu samej infrastruktury jako zagadnienia software i znalezienia jakiegoś kompromisu między potrzebami infrastruktury i produktu, a co najważniejsze, zaakceptować, że ryzyko, że coś nie działa istnieje i trzeba, i można nim zarządzać.

Tym się właśnie zajmuje SRE, a co najważniejsze definiuje narzędzia, które pozwalają nam tym ryzykiem zarządzać.

Okej, to już teraz bardziej rozumiem genezę i faktycznie, tak jak powiedziałeś, jeśli to się narodziło w Google to pewnie strona była tym produktem, który musiał być monitorowany, nadzorowany, jeśli chodzi o niezawodność.

Zastanawiam się, czy w tym obecnym świecie technologicznym, tylko ograniczamy się do stron internetowych, właśnie, jeśli chodzi o SRE czy też takie rzeczy jak aplikacja mobilna, API publiczne itd., które też są jakimiś produktami informatycznymi czy tutaj te mechanizmy, o których powiedziałeś, te narzędzia też obejmują ten zakres technologii?

Wszystko, co nazywamy usługą można monitorować i realnie t można się nawet nie ograniczać do IT.

Wszystko, co jest realizowalne, mierzalne w jakiś sposób, na podstawie czego można zebrać jakąś metrykę działania czegoś. Można zbudować SLO i to monitorować. Oczywiście self reliability engineering w prostym zakresie odnosi się do usług informatycznych, gdzie pod zbiorem usług informatycznych jest ta wspomniana strona WWW, ale mogą to być również inne mikro serwisy, joby działające w tle, przetwarzające dane batchowo.

Possibilities are endless here.

Czy taka stuprocentowa niezawodność systemu to jest coś, do czego dążymy? Czy to w ogóle jest możliwe do osiągnięcia?

Myślę sobie, że to jest podobnie jak z błędami w oprogramowaniu. Musimy zaakceptować jakiś tam poziom tych błędów, nigdy nie będziemy w stanie stworzyć oprogramowania, które jest pozbawione tych błędów. Po prostu musimy z tym żyć i zastanawiam się, czy w przypadku niezawodności stron czy tak jak mówiłeś, ogólnie rozumianych usług informatycznych też ta stuprocentowa niezawodność jest taka umowna.

Jak na to patrzysz?

Stuprocentowa niezawodność nie jest w ogóle możliwa, a przede wszystkim nie jest potrzebna Znamy wszyscy oczekiwania — 100% uptime, 200% bezpieczeństwa, 300% nowych feature’ów.

Ale dlaczego to nie jest potrzebne? Ponieważ użytkownik, który korzysta z naszej usługi, robi to przy pomocy X systemów pośrednich może mieć słaby zasięg, słabe WiFi, lagujący telefon. Twój dostawca internetu może mieć jakąś czkawkę! Jest ogrom czynników, które i tak na końcu ograniczają dostępność usługi, także pościg za kolejnymi ułamkami procentów niezawodności to jest po prostu bezcelowy.

Abstrahując od tego, jest to szalenie drogie, jakby na to nie patrzeć. Niezawodność — mówisz 100%, ale tak naprawdę to zazwyczaj mówi się o 99,9 — ileś tam tych dziewiątek procentów, to każda kolejna dziewiątka dołożona do tej liczby zwiększa o rząd wielkości koszty. A jak wiemy, rzeczy i tak się psują. A realnie użytkownik nie zauważy tej różnicy pomiędzy 100% a 99,99%. On tego nie zauważy.

Natomiast clue tutaj jest takie, żebyśmy niezawodność traktowali jako feature naszej usługi. Mierzyli User Experience, aby wybrać taki poziom niezawodności, żeby nasi użytkownicy byli zadowoleni z korzystania z naszych usług. Jeżeli wiemy — albo zbadaliśmy, że nasi użytkownicy są zadowoleni przy niezawodności 97%, bo to też całkiem okej liczba, nie fiksujemy się na tych 99%, to przy 97% niezawodności mamy 3% na błędy.

Te 3% — tutaj zacznę przemycać już trochę wiedzy — nazywamy właśnie naszym error budżetem. To liczba naszego akceptowalnego ryzyka i w ramach SRE właśnie nią możemy zarządzać i posługiwać.

Rozumiem. Okej, czyli to zarządzanie jest tutaj ważne, na to musimy zwrócić uwagę. Żeby czymś zarządzać, najczęściej musimy to mierzyć. I tutaj kilka razy powiedziałeś już o wskaźnikach, o SLO.

Czy mógłbyś ten temat rozszerzyć, powiedzieć czym jest SLO?

Skrót oznacza service level objective. Są to wskaźniki niezawodności, które sami, jako twórcy danego systemu powinniśmy sobie zdefiniować.

Sam SLO nazywam takim kontraktem między stakeholderami, czyli wszystkimi uczestnikami wytwarzania oprogramowania.

To może być dział produktu, biznesu, deweloperzy, a nawet customer service i w tym kontrakcie definiujemy jaką wartość rozumiemy jako niezawodność danej usługi.

Prostym przykładem takiego SLO, które trafi do wszystkich jest monitorowanie czasu odpowiedzi serwera WWW. Typowe SLO. Chcemy, żeby nasz serwer odpowiadał na requesty, przez 99% czasu, poniżej 100 milisekund. Mając taką definicję SLO wprost dostajemy, że nasz error budget to jest 1%. To jest 1% na błędy, które możemy zarządzać.

Takie SLO definiuje się również w kontekście jakiegoś okna obserwacji czy np. patrzymy na to przez miesiąc kalendarzowy lub ostatni tydzień, natomiast ten wskaźnik nie jest też liczbą tak, żeby sobie funkcjonowała i była. Przekroczenie tego SLO powinno ciągnąć za sobą realne decyzje biznesowe, na które wszyscy stakeholderzy się zdecydowali, które organizacja powinna podjąć.

Również w drugą stronę — nieprzekroczenia tego budżetu również może dać nam pewne wskazówki, że być może przepłacamy. W idealnym modelu, mając ten 1% na błędy powinniśmy w tym okresie np. tego miesiąca wykorzystać ten 1% na błędy. Jeżeli tego nie zrobiliśmy, to być może gdzieś przepłacamy za infrastrukturę, coś jest za dobre.

Ciekawe pojęcie! Czy wskaźniki SLO czy je tylko stosujemy albo tylko możemy stosować w przypadku budowania aplikacji? Bo zastanawiam się, to o czym powiedziałeś, tak wyobrażam sobie, że może być stosowane również poza branżę IT. Może wychodzić poza ten nasz technologiczny obszar.

Czy SLO to są wskaźniki ściśle technologiczne czy też może szerzej?

Jest wiele przykładów i moim ulubionym jest przykład z MPK. Mamy tramwaje, mamy autobusy. Takie MPK mogłoby zdefiniować sobie SLO, że chcę 80% wszystkich autobusów, tramwajów, żeby przejeżdżało na czas w oknie miesiąca.

Jeżeli nie przyjeżdża na czas to 80%, to MPK mogłoby podjąć realną decyzję — musimy zrobić tak, żeby częściej jeździły. Trochę zmienić rozkład. Bo klienci są niezadowoleni, wiemy że są, bo nam to zgłaszają, więc musimy zadziałać. I w drugą stronę — jeżeli nie przekraczamy tego 80%, ci pasażerowie są zadowoleni, wszystko jeździ na czas, to może można np. zrobić dodatkową minutę przerwy między autobusami, dwie minuty, czyli wypuścić ich mniej. Dążymy celem optymalizacji kasy — mniej autobusów i rzadziej będą jeździć.

Chyba wiemy mniej więcej, o co chodzi w tym podejściu. Powiedziałeś, że 100% to jest mityczne, iluzoryczne i nieosiągalne. Jak procentowo te oczekiwania można by było ująć? Jeśli nie 100% to ile i czy takie ujęcie sprawy jest bardzo odgórne, w sensie, że ktoś po prostu przyjmuje jakąś tam wartość i do niej próbujemy dorównać czy też może najpierw badamy gdzie jesteśmy i próbujemy wyznaczyć co jest realne, co jest pewnym ulepszeniem w stosunku do bieżącej sytuacji, do czego chcemy dążyć w następnym kroku. Jak się takie czynniki procentowe najczęściej definiuje?

Nie ma tutaj jednej, prostej odpowiedzi. Wszystko zależy od tego, co robimy, zależy jakie decyzje biznesowe podejmujemy albo chcemy podejmować. Bardzo często to jest tak, że jeżeli zaczynamy ten temat i zastanawiamy się jakie liczby tutaj postawiać, to ustawimy sobie to SLO takie bardziej luźne, nie 100% czy tam bliżej 99 tylko może 90. I popatrzmy.

Obserwacja jest ważnym elementem tego, jaka ta wartość liczbowa powinna być i jak ją ustawić. Natomiast celem jest optymalizacja tego i znalezienie złotego środka, byśmy mogli oddawać nowe funkcjonalności do naszego systemu jak najszybciej z zachowaniem stabilności działania tego systemu i jednocześnie przy okazji, przy tych optymalnych kosztach.

Może nie musimy za dużo za tę infrastrukturę przepłacać? To jest taki złoty środek, który niestety każdy musi znaleźć sam i znaleźć taką liczbę, która — jest to takie trochę wbrew IT, jest good enough.

Co jest good enough — czy użytkownicy będą zadowoleni, my będziemy wystarczająco szybko dokładać nowych feature’ów, wszystko będzie działać tak jak chcemy i jeszcze będziemy w tym przypadku dostarczać to za optymalne pieniądze.

To nie jest trywialne zadanie. Inżynierom w Google’u to zajmuje z miesiąc, zdefiniowanie jednego SLO dla nowych usług. Jest to współpraca wielu stakeholderów, wielu działów, które muszą ze sobą współpracować, żeby to ustalić.

Okej. Na początku mówiłeś, że ta niezawodność może być widziana jako tak całościowo — np. jak użytkownik odbiera, jakie ma doświadczenia z korzystania z jakiejś usługi, strony itd. Na ile to jest niezawodne.

To potrafię zrozumieć — z punktu widzenia użytkownik, on jest zainteresowany tym, żeby systemy, z których korzysta działały jak najbardziej niezawodnie. Natomiast jak to wygląda z punktu widzenia dewelopera?

Co daje deweloperom tworzenie produktów w tym modelu SRE?

Każdy użytkownik takiej organizacji może na tym skorzystać. Organizacje, które zdecydowały się na budowanie produktów tym modelu potrafią podejmować realne decyzje biznesowe na podstawie jakichś metryk IT. Dla ról inżynierskich, dla deweloperów jest to o tyle ważne, że dzięki monitorowaniu SLO inżynierowie mają konkretne metryki, taki oręż w ręku i wymierne wskaźniki, argumenty ułatwiające podejmowanie decyzji technicznych, które powinny podążać za potrzebami biznesowymi. Na koniec dnia produkt ma przynosić zyski jego twórcom. Jeżeli wypalamy SLO, jeżeli ustaliliśmy, że chcemy mieć 99%, ale ciągle to przepalamy to znaczy, że musimy się zatrzymać z rozwojem i kupić na poprawie stabilności.

Jeżeli go w ogóle nie wypalamy i nic złego się przez dłuższy czas nie dzieje, to znaczy, że może przepłacamy za infrastrukturę. Może możemy tu zredukować koszty? Jest to o tyle korzystne dla dewelopera, że on mając takie wskaźniki i organizację, która idzie w tym modelu, mówi wprost: słuchajcie, wypalamy to, teraz musimy zająć się długiem technologicznym. Albo: wszystko jest okej, lecimy dalej z feature’ami, możemy działać może jeszcze szybciej, może gdzieś możemy trochę przyoszczędzić. Ten model się po prostu opłaca.

Tak, na koniec dnia to się liczy najbardziej.

Ta organizacja się też nie mota. Ma realne kroki, które może podjąć nie zastanawiając się za wiele czy to jest dobre czy złe, bo liczby im to mówią.

Właśnie, do bazowania na danych jest obecnie mega kluczowe. Żeby jak najszybciej reagować na pewne zmiany w ramach rynku, w którym się firma porusza zazwyczaj z bardzo konkurencyjnego rynku, ten time to market i reagowanie na potrzeby użytkowników — często to jest przetrwanie dla firmy, więc faktycznie bazowanie na tych danych jest ważne.

Mówimy o podejściu SRE, że patrzymy sobie na nasze wskaźniki SLO, robimy analizę, ewentualnie reakcję. Natomiast jeśli chodzi o SRE to możemy również mówić o inżynierze, który zajmuje się SRE.

Jakie kompetencje posiada taki człowiek, jaki ma background zawodowy, jak wygląda jego praca?

SRE to rola, która najczęściej wywodzi się z DevOps. Google sam definiuje SRE jako rolę, która wprowadza w życie praktyki DevOps dokładając do tego monitorowanie SLO, zarządzanie error budgetem, a przede wszystkim traktowanie zadań operacyjnych jako problem programistyczny. Rozwiązywania zadań nie za pomocą ludzi, a kodu. I automatyzacji. Żeby to dobrze robić, taka rola jest też zdecydowanie bliżej aplikacji, bliżej developerów, nic nie stoi na przeszkodzie, żeby taki SRE również jakiś feature do aplikacji napisał. Nie ma żadnego problemu.

Rola ta jest przez to mocniej skierowana w stronę rozumienia zadowolenia klienta i w ogóle samego użytkownika. Do takiego backgroundu, to odpowiedziałbym w ten sposób: jeśli infrastruktura nie jest ci obca i umiesz programować w języku, który sprawi, że będziesz w stanie zautomatyzować powtarzalne czynności, to jesteś na dobrej drodze.

Rola ta jest przez to mocniej skierowana w stronę rozumienia zadowolenia klienta i w ogóle samego użytkownika. Do takiego backgroundu, to odpowiedziałbym w ten sposób: jeśli infrastruktura nie jest ci obca i umiesz programować w języku, który sprawi, że będziesz w stanie zautomatyzować powtarzalne czynności, to jesteś na dobrej drodze.

Okej, wszystko jasne. Relatywnie niewiele firm jeszcze korzysta z tego modelu. Zastanawiam się, czy to wynika z tego, że to jest domena dużych graczy typu Google, taki moment w rozwoju, kiedy już się opłaca inwestować po prostu w rozwój takiego działu. Jak ze swoich obserwacji możesz wnioskować? Czy to tylko duże firmy inwestują, czy też jest może jakaś duża bariera wejścia?

Skąd wynika relatywnie nieduże zainteresowanie tym podejściem?

Pozwolę sobie zacytować książkę z Google’a odnośnie do SRE: „Anyone can do site reliability engineering. Sure, Google pioneer the practice, but you don’t have to work for tech giant to use SRE to increase reliability and improve system performance”.

To tak tytułem wstępu, ale mierzenie i monitorowanie SLO wcale nie jest takie proste. Rozmawialiśmy wcześniej o prostych przykładach SLO, ale w zależności od potrzeb, metod liczenia jest wiele. Robi się to w wielu przedziałach czasowych, metryki do mierzenia SLO można pobierać z różnych systemów monitoringu itd. To się spiętrza. Google jest o tyle wygodne, że budując swoje usługi dostarcza swoim zespołom to wszystko out of the box.

Na wolnym rynku nie istnieją specjalne narzędzia pozwalająca w sposób kompleksowy rozwiązać problem monitorowania SLO.

Tu wchodzimy my, cali na niebiesko-zielono, bo to nasze firmowe barwy i nasza platforma kwestie monitorowania SLO klientom po prostu bardzo ułatwia. W uproszczeniu — wzięliśmy na siebie całą logikę skomplikowanych, matematycznych obliczeń i przetwarzania tej ogromnej ilości danych.

Właśnie, to może opowiedz trochę o narzędziu, które budujecie w Nobl9. Na czym polega działanie, na czym polega efekt i zastosowanie narzędzia, nad którym pracujecie?

Nasza usługa jest oferowana jako SaaS lub jako on premise dla klientów chcących korzystać z rozwiązania w ramach własnej infrastruktury. Tacy oczywiście dużo też są i oni sobie takie życzenia stawiają.

Co do samej aplikacji, to konieczne jest wyjaśnienie, że Nobl9 nie jest narzędziem, które ma zastąpić istniejący monitoring systemów IT. My się dołączamy do tych systemów i to z nich wyciągamy zdefiniowane przez użytkownika metryki, aby móc na ich podstawie i na podstawie ich wartości obliczyć poszczególne SLO.

W ramach naszej platformy użytkownik wprowadza sobie definicję tego SLO, ustala procent wymaganej niezawodności, ustala okres obserwacji, metodę liczenia i wiele innych parametrów oraz wskazuje na podstawie jakiejś metryki lub metryk obliczenia po naszej stronie mają się wykonywać.

Nasz system zbiera te wszystkie dane, wykonuje odpowiednią magię i tu dostarczamy nasza wartość biznesową w postaci m.in. wykresów czy też wysyłamy alerty i pomagamy w ten sposób podejmować decyzje co do poszczególnych SLO.

Interakcje z naszym systemem można prowadzić przy pomocy przeglądarki i w ramach aplikacji webowej, ale również można to zautomatyzować korzystając z naszego narzędzia konsolowego. Daje nam to tyle, że jak ktoś ma zautomatyzowany cały CICD i deployuje nową usługę, może od razu w tym samym pipelinie ustawić SLO na tej nowej usłudze w naszym systemie.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-125-site-reliability-engineering/

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.