14 lip 2021 POIT #125: Site reliability engineering
Witam w sto dwudziestym piątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest site reliability engineering.
Dziś moim gościem jest Grzegorz Agaciński – 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ół developerski w oddziale Nobl9 w Poznaniu, który na ten moment liczy 40 osób. Wcześniej przez wiele lat był programistą, managerem i twórcą kilku startupów.
W tym odcinku o site reliability engineering rozmawiamy w następujących kontekstach:
- czym jest reliability?
- skąd się wzięło pojęcie Site Reliability Engineering?
- czy osiągnięcie 100% niezawodności systemu jest w ogóle możliwe?
- czym jest SLO?
- czy SLO wykorzystujemy tylko przy budowaniu aplikacji?
- co daje podejście do budowania produktów w modelu SRE – z punktu widzenia developerów?
- kim jest inżynier zajmujący się SRE?
- dlaczego jeszcze stosunkowo niewiele firm zdecydowało się przejść na model SRE?
- w Polsce temat SRE dopiero raczkuje, jak to wygląda na przykład w Stanach?
- jakie materiały możemy polecić osobom chcącym dowiedzieć się więcej o SRE i SLO?
- jak będzie wyglądał rozwój tej dziedziny?
Subskrypcja podcastu:
- zasubskrybuj w Apple Podcasts, Google Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
- ściągnij odcinek w mp3
- poproszę Cię też o polubienie fanpage na Facebooku
Linki:
- Profil Grzegorza na LinkedIn – https://www.linkedin.com/in/gagacinski/
- Nobl9 – https://nobl9.com/
Wsparcie na Patronite:
Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.
Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.
👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit
Pozostańmy w kontakcie:
- 📧 Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
- 📩 Zapisz się na newsletter, aby nie przegapić kolejnych ciekawych odcinków
- 🎙 Subskrybuj podcast w lub
Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)
Transkrypcja podcastu
To jest 125. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o site reliability engineering. Przypominam, że w poprzednim odcinku rozmawiałem o edge computingu.
Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/125.
Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.
Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego, jest między innymi ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.
Jednocześnie bardzo dziękuję moim obecnym patronom. A teraz życzę Ci już miłego słuchania.
Odpalamy!
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.
Okej, fajnie to wygląda! Powiedziałeś tutaj o automatyzacji. Zastanawiam się, na ile w tym zapewnieniu czy też podnoszeniu niezawodności aplikacji, usług, rolę gra czynnik ludzki, a na ile mimo wszystko automatyzacja góruje i przoduje?
Niezawodność to nie jest coś, nad czym pracujemy raz w ramach życia aplikacji i zawsze ją będziemy mieli. Do tego trzeba podejść jak do czegoś ciągle zmieniającego się i ewoluującego wraz z naszym systemem. Bardzo łatwo jest napisać system, który będzie super niezawodny, nie ma żadnych feature’ów i nigdy się nie zmienia, ale pieniędzy na tym nie zarobisz.
Wracając do sedna pytania. Automatyzacja jest świetnym sposobem na zapewnienie lepszej niezawodności, ale wykluczenie czynnika ludzkiego nie jest możliwe. Oczywiście, u odstaw SRE też leży wyciąganie lekcji, zabezpieczenie się w przyszłości przed awariami, które się już wydarzyły, żeby w przyszłości się nie wydarzyły, ale trzeba być świadomym, że awaria jest też naturalnym elementem życia systemu i ludzie też muszą być na nią przygotowani.
Mówiłem wcześniej – ten temat SRE trochę raczkuje w Polsce, ale jestem ciekawy jak to wygląda w Stanach, kiedy obserwujecie ten rynek. Czy tam na przykład jest zainteresowanie na waszą usługę, produkt?
Zainteresowanie jest duże. W USA zdecydowanie duże, większe organizacje rozumieją potrzebę przejścia do modelu SRE i fakt, że im się to po prostu opłaca i robią tranzycję w tym kierunku.
My przez ostatni rok prowadziliśmy duże akcje edukacyjne, nie staraliśmy się nachalnie naszego produktu firmom sprzedawać, tylko bardziej rozmawiać, edukować, słuchać ich potrzeb i widać, że to przynosi efekty. Teraz klienci sami do nas wracają i mówią „Hej, my już chcemy robić SRE, wiemy, że potrzebujemy SLO i nie będziemy tego systemu rozwijać sami”.
Są niektóre firmy, które próbują robić to in house, próbują domowymi metodami stworzyć taki system, ale koniec końców też rozumieją, że na dłuższa metę zewnętrzny provider, który pracuje nad rozwiązaniem tego problemu cały czas rozwiąże to lepiej niż oni wewnętrznie, jakimiś własnymi zasobami czy deweloperem po godzinach.
Jeśli to nie jest core biznesu, którym ta firma się zajmuje, to oczywiście taka usługa zewnętrzna będzie najprawdopodobniej dużo lepsza, jednocześnie odciąży działania firmy i pozwoli jej się skupić na tym, co jest właściwe dla jej domeny.
Gdyby ktoś ze słuchaczy był zainteresowany pogłębieniem swojej wiedzy na temat SRE, SLO – czy mógłbyś jakieś materiały, jakieś miejsca może polecić, gdzie warto poczytać, pooglądać pewne rzeczy w tym temacie?
Jasne! Dziś jedynie dotknęliśmy wierzchołka góry lodowej o nazwie reliability, dlatego zachęcam zainteresowanych do głębszego poznania tematu i na pewno mogę odesłać nie robiąc reklamy do naszej strony, ale mamy tam bardzo dużo fajnych, ciekawych artykułów i materiałów edukacyjnych: nobl9.com.
W maju tego roku zorganizowaliśmy pierwszą wirtualną i dedykowaną SLO konferencję o nazwie SLOconf, wirtualna, bo sytuacja jest, jaka jest, ale myślę, że wyszło bardzo fajnie. Mieliśmy ponad 2000 uczestników, dziesiątki mówców, wszystkie nagrania, wszystkie filmy są dostępne na YouTube, na naszym kanałem albo pod hasztagiem #SLOconf.
Bardzo polecam – sama formuła jest świetna, ponieważ te filmiki mają od kilku do kilkunastu minut, sprawiało to, że mówcy musieli się naprawdę streścić, żeby przekazać co chcieli i nie są to godzinne wodolejstwa, a przez to też łatwo znaleźć chwile, żeby sobie taki filmik obejrzeć.
Jak już chcemy wejść głębiej to oczywiście książka SRE od Google. One są dostępne publiczne, online można je znaleźć i poczytać, bardzo polecam. Również jest książka autorstwa pioniera tematyki SLO na świecie oraz pełniącego zupełnie przez przypadek rolę dyrektora do spraw SRE w Nobl9, Alexa Hidalgo, która się nazywa Implementing service level objectives.
Bardzo fajne podejście, bardzo fajnie opowiada o tym, jak się do tego zabrać od zera, od podstaw, jak to wdrożyć w organizacji.
Okej, dzięki wielkie za to. Myślę, że z racji na to, że nastawienie na quality produktów, rozwiązań cyfrowych rośnie, to też będzie rosło zapotrzebowanie, żeby właśnie to SLO wyznaczać, mierzyć, analizować i że tutaj w tym kierunku będzie coraz większe zainteresowanie.
Chciałbym zapytać na koniec, jak myślisz – w którym kierunku ta dziedzina będzie podążać? Może jakieś trendy, które obecnie występują?
Temat jest na tyle jeszcze świeży, oczywiście poza Google, że tak powiem, że główny rozwój widzę w szerszej adopcji tego modelu przede wszystkim.
To jest coś, co na pewno nas mocno czeka i trafi również do Europy, ponieważ my również rozmawiamy z klientami z Europy i do Polski pewnie wkrótce. Automatyzacja powtarzalnych, monotonnych czynności, to jest ten kierunek, gdzie wszyscy do tego dążą, mierzenie wszystkiego, na wszystkim można zrobić metrykę, na podstawie wszystkiego można podjąć decyzję, także jest tutaj sporo też pracy dla tych samych organizacji, które muszą po swojej stronie wykonać, a realnie – znajdowanie tego złotego środka, tego optimum między niezawodnością, dostępnością tej usługi, budżetem i tempem dostarczania, to się po prostu opłaca. Tutaj jest próba mentalny do pokonania dla firm, które muszą zrozumieć, że to się na dłuższą metę im opłaca i na pewno będą tę metodę wdrażać. I wcale nie trzeba być wielkim gigantem, każdy może się tym zająć, a chcąc nie chcąc to zadowolony użytkownik będzie płacił za twoją usługę.
Bardzo dobre podsumowanie. Grzegorz, bardzo ci dziękuję za rozmowę, za takie przystępne przedstawienie tego tematu. Dzięki za poświęcony czas i powiedz proszę, gdzie cię można znaleźć w internecie, jak się z tobą skontaktować?
Znaleźć mnie można na pewno na LinkedIn, nazywam się Grzegorz Agaciński, ale również możecie pisać do mnie na maila – greg@nobl9.com. Zapraszam do kontaktu, chętnie odpowiem na wszystkie pytania, jeżeli mielibyście więcej!
Super. Oczywiście wszystkie linki jak zawsze będą w notatce do odcinka, z mojej strony Grzegorz jeszcze raz bardzo Ci dziękuję i do usłyszenia!
Również dziękuję, pozdrawiam, do usłyszenia!
To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Temat SRE i SLO narodził się w Google i tam jest najmocniej rozwijany. Ten model przyjmuje się jednak coraz szerzej, gdyż zwyczajnie się opłaca.
Z racji na to należy przypuszczać, że w najbliższych latach będzie coraz popularniejszy.
Jeśli ten odcinek był dla ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach.
Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.
Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o site reliability engineering.
Zapraszam do kolejnego odcinka już za tydzień!
Cześć!