Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Site Reliability Engineering: odpowiedzi na 10 najczęstszych pytań

Dowiedz się więcej o Site Reliability Engineering, dzięki odpowiedziom specjalisty SRE, który pracował wcześniej jako programista.

Popularność Site Reliability Engineering gwałtownie rośnie, ale wciąż nie jest to powszechna specjalność. Dla niektórych skrót SRE nadal brzmi dość tajemniczo, a inżynierowie SR bywają myleni z administratorami lub specjalistami DevOps. Zebrałem więc najczęściej powtarzające się pytania dotyczące SRE i postarałem się na nie odpowiedzieć, by rozjaśnić, czego wymaga się od osób, które chcą zajmować się SRE i rozwijać się w tym kierunku.


SRE – czy to termin z książki wydanej przez Google?

Ogólnie rzecz biorąc – tak. Koncepcja Site Reliability Engineering pojawiła się w Google w 2003 roku. Od tamtej pory wiele firm stworzyło własne zespoły SRE. Przede wszystkim te, które silnie polegają na płynnym funkcjonowaniu systemów komputerowych, w tym Apple, Microsoft, Facebook, Twitter, Dropbox, Oracle i inni. Na przestrzeni ostatnich 2-3 lat lista firm, które wyodrębniły tę rolę w projektach, znacznie się wydłużyła. Kto dziś nie bazuje na wewnętrznych systemach IT, ich niezawodności, wydajności i integracji z serwisami zewnętrznymi? 

Zadania specjalistów SR w firmach mogą się od siebie różnić w zależności od modelu biznesowego. Z tej perspektywy SRE, jako relatywnie nowe podejście, jest podobne do metodologii Agile, którą, jak prawdopodobnie zauważyliście, każdy interpretuje odrobinę inaczej. W praktyce umiejętności wymagane od specjalistów SR przez różne firmy pokrywają się jednak w 80%.


Zapewnienie niezawodności – czy to nowa modna nazwa wsparcia technicznego?

Zdecydowanie nie! Koncepcja SRE zakłada, że developerzy nie tylko tworzą kod, ale także monitorują jego zachowanie w środowisku produkcyjnym. Wobec tego można zaryzykować stwierdzenie, że granica między rozwojem oprogramowania i jego użytkowaniem zaciera się. Jednym z zadań zespołu SRE jest niepozwalanie na to, by kolejne wdrożenia polegały na odbijaniu piłeczki między zespołem programistów a DevOps, w którym każda strona twierdzi, że błąd popełniła ta druga.

Specjalista Site Reliability nieustannie szuka możliwości automatyzacji i ma dość rozległy wpływ na ten proces. Każdy problem jest dla niego przede wszystkim powodem do przeprowadzenia analizy. Jeśli problem ten się powtarza lub związany jest z dużym ryzykiem, SRE może zdecydować, by naprawić coś w samej aplikacji lub stworzyć (samodzielnie lub z pomocą zespołu) narzędzie, które wyeliminuje błąd bez interwencji człowieka. Dzięki SRE nie tylko sprawdzamy, czy aplikacja zawiera błędy, ale także dowiadujemy się jak je naprawić i jak nieustannie poprawiać niezawodność systemu w przyszłości.

O ile naprawianie błędów mieści się w zakresie obowiązków teamu SRE, jego kluczowym zadaniem jest określenie wydajności systemu i systematyczna praca na rzecz jej poprawy. Specjalista SR zajmuje się wsparciem tylko wtedy, gdy procesy nie są prawidłowo zorganizowane – czyli gdy liczba błędów lawinowo wzrasta i zwyczajnie nie ma on czasu zajmować się swoimi podstawowymi zadaniami, a zamiast tego rozwiązuje bieżące, pilne sprawy. W naszych projektach zdecydowanie tego zabraniamy, ponieważ uważamy, że w rozwoju koncepcji SRE tkwi istotny potencjał naszego biznesu. Zadanie SRE to według nas przede wszystkim zredukowanie konieczności wsparcia do kontrolowanego i akceptowalnego poziomu.

Istotną różnicą pomiędzy SRE i wsparciem jest ilość komunikacji. Dla specjalisty SR stopień, do jakiego większość analityków systemowych (zwłaszcza w niewielkich firmach) jest zaangażowana w komunikację, jest niemałą niespodzianką. Zdecydowanie nie jest to praca nad wąskim zadaniem w kompletnej samotności. W naszych projektach zadanie polega na ciągłym komunikowaniu się z przedstawicielami strony biznesowej lub niezależnymi zespołami programistów.


SRE – programista czy DevOps?

Site Reliability Engineering to próba połączenia tych dwóch kierunków. Inżynierowie, którzy pracują w obszarze SR, dogłębnie rozumieją systemy, wiedzą, jak się w nie wgryźć i potrafią przepisać kod złej jakości. Ale w tej roli jest także odrobina DevOps – specjalista SR powinien rozumieć, jak działają serwery, na których wdrożony jest system, w jaki sposób system jest skalowalny, jak rozkłada się obciążenie, etc.

Specjaliści SRE są niezbędni przede wszystkim w obszernych projektach obejmujących skomplikowane, silnie obciążone aplikacje. To oni wiedzą, jak system zachowuje się w warunkach rzeczywistych, w szczególności, gdy coś idzie nie tak – np. pojawia się błąd sieci lub bazy danych. Wiedza ta jest potrzebna nie tylko do tego, by błyskawicznie ustabilizować aplikację, ale także, by wprowadzić konieczne zmiany do kodu źródłowego.


Czym jest niezawodność? Czy da się ją zmierzyć za pomocą określonych kryteriów?

Podstawowym zadaniem inżynierów Site Reliability jest otoczenie dowolnego systemu mierzalnymi wskaźnikami, które mogą różnić się w zależności od projektu. Ważne, by nie przesadzić i nie mierzyć tego, co nas nie interesuje. Np. ilość miejsca na dysku serwera i obciążenie procesora same w sobie wpływają na funkcjonowanie systemu, ale nie odpowiadają na istotne pytania. Inżynierowie SR nie są zainteresowani wskaźnikami technicznymi, a Service Level Indicators (SLI; wskaźniki na poziomie usług) - np. wskaźnikami biznesowymi. System lepiej służy użytkownikom nie wtedy, gdy procesor jest mniej obciążony, a wtedy, gdy jest w stanie obsługiwać więcej zapytań bez straty na jakości.

Jedynie wiedząc, jak mierzyć czynniki krytyczne z perspektywy biznesowej, możemy rozpocząć proces zwiększania poziomu niezawodności. Jasne jest, że jednocześnie rośnie koszt rozwoju, wsparcia i utrzymania systemu. Co więcej, wszystkie wymienione czynniki wzrastają gwałtownie, szczególnie kiedy mamy do czynienia z systemem funkcjonującym w wielu regionach - pojawia się wtedy kwestia uniwersalnej linii (i bardzo często SRE muszą radzić sobie z tak złożonymi kontekstami).

W tym miejscu SRE okazuje się kluczowym argumentem w negocjacjach biznesowych, ponieważ tacy specjaliści są w stanie wytłumaczyć (odnosząc się do wskaźników biznesowych), na ile system jest niezawodny, z jakimi potencjalnymi problemami mamy do czynienia i ile będzie kosztowało wyeliminowanie ich. Wraz z przedstawicielami strony biznesowej, inżynierowie SR ustalają Service Level Objectives (SLO; kolejny istotny skrót), czyli np. cele na poziomie usług i akceptowalne wskaźniki niezawodności.


Jakie wykształcenie i doświadczenie powinien posiadać specjalista SRE?

Koncepcja Site Reliability Engineering jest wciąż relatywnie nowa, więc osoby o dokładnie takich kwalifikacjach właściwie nie występują na rynku. Do pełnienia tej roli rozważa się zarówno developerów (SRE nie powinni bać się Pythona ani Javy), jak i specjalistów DevOps, którzy są gotowi zagłębić się w kod. Na szczęście zakres zadań jest bardzo szeroki: od monitorowania i powiadamiania (typowe zadanie DevOps), do kompleksowego eliminowania błędów, którego mogą podjąć się jedynie doświadczeni programiści.

Klasyczny przykład zadania: ciągły brak pamięci w rejestrach serwera; albo wyczerpanie puli wątków, kiedy np. niektóre wątki nie są zwracane; albo sytuacja, w której jeden z trzech serwerów pod load balancerem wciąż jest przeładowany, podczas gdy dwa pozostałe pracują normalnie. Są to przykłady skomplikowanych problemów technicznych, które wymagają zrozumienia tego, co tkwi „pod maską”, czyli tego, jak systemy są skalowane w chmurze, jak rozłożone jest obciążenie i w jaki sposób radzi sobie z nim serwer. Tego rodzaju problemy powinien zbadać senior developer. Mamy tu do czynienia z zadaniami związanymi z konfiguracją i tymi lokalnymi, mniej złożonymi. 

SRE to obszar z pogranicza rozwoju oprogramowania i DevOps. Znalezienie osoby z rozległym doświadczeniem w obu obszarach jest praktycznie niemożliwe. Zatem, posiadanie wiedzy na temat wszystkich procesów i narzędzi nie jest wymagane od osób, które chcą podjąć się roli inżyniera SR. SRE oferuje perspektywy nie tylko seniorom, ale także młodszym developerom i DevOps. Mają oni szansę zgłębić tę specjalizację, zanim stanie się ona powszechna.


Czy SRE to przeciwieństwo feature development?

SRE może ograniczyć zbyt szybkie tempo rozwijania nowych funkcji, pełniąc rolę stabilizatora. Ale nazywanie Site Reliability Engineering złem i wiązanie go z „antyrozwojem” oprogramowania to ogromna pomyłka. Specjaliści SR nie są przeciwieństwem developerów zajmującym się rozwojem systemów – raczej wprowadzają równowagę po stronie biznesowej, która nieustannie naciska na ekspansję funkcji, niezależnie od tego, o jakiej aplikacji, czy systemie mówimy.

Nowe funkcje, zwłaszcza te zaprojektowane w pośpiechu, zawsze destabilizują system. Kiedy pojawia się plan wprowadzenia ich do środowiska produkcyjnego, SRE może odwołać się do wskaźnika budżetu błędów. Gdy budżet błędów jest wybrany lub przekracza punkt krytyczny, SRE podnosi alarm i sygnalizuje potrzebę stabilizacji. To intuicyjne: jeśli system jest stabilny, można go odrobinę zdestabilizować, dodając nowe funkcje. Jeśli nie – nie warto ryzykować. Należy eliminować zagrożenia, odkładając rozwijanie nowych funkcji na później, Ale koncepcja SRE pozwala mówić o tym w zrozumiały sposób, z użyciem konkretnych informacji i wskaźników. Ponadto, rola SRE wiąże się z odpowiedzialnością za tę równowagę i daje inżynierom odpowiednie uprawnienia.


Czy praca SRE jest rutynowa?

Nie. Trudno nazwać obowiązki specjalisty Site Reliability rutynowymi – nie mamy przecież na myśli niekończącej się serii powtarzalnych zadań. Praca obejmuje na pewno działania związane ze wsparciem: najprawdopodobniej pewnego dnia padnie serwer i trzeba będzie się tym zająć. Pewnie stanie się to wieczorem, kiedy klient rozpoczyna przetwarzanie zamówień. W naszych projektach nikt jednak nie wymaga od zespołu, by był dostępny 24 godziny na dobę, a wsparcie na żądanie to zazwyczaj kwestia tygodnia pracy raz na dwa miesiące i jest to zadanie płatne, nawet jeśli nie wpłyną w tym czasie żadne zapytania.

Praca w obszarze SRE może być zatem podzielona na dwie części. A samo gaszenie pożarów może być przecież całkiem przyjemne: dzielnie spieszysz na ratunek z gaśnicą i pokonujesz ogień z niemałą satysfakcją (choć pod nosem krytykujesz tych, którzy zafundowali ci tę przygodę). Wydaje się, że po takiej akcji wszyscy powinni spać spokojnie, ale dla SRE praca dopiero się zaczyna: trzeba zbadać, co spowodowało incydent, ocenić ryzyko i zdecydować, w jaki sposób można zapobiec pojawianiu się podobnej sytuacji w przyszłości. Dodatkowo samo tego typu śledztwo może wciągać, a jego pomyślne zakończenie jest wystarczająco dobrym powodem to odczucia satysfakcji.


Czy SRE pracują z developerami, czy jest to osobny zespół?

Praktykujemy oba podejścia. W pierwszym przypadku inżynier SR jest wprowadzany do zespołu razem z developerami i specjalistami QA. Zdarza się, że są wtedy w stanie konfliktu kreatywnego, który zapobiega wybieraniu przez nich niebezpiecznych kompromisów.

W ramach drugiego podejścia, mamy w projekcie zespół SRE. Najczęściej używamy go w projektach, które przekroczyły etap aktywnego tworzenia oprogramowania i system jest dość stabilny. Taki system może już być używany przez klienta. Poprawa procesu i interakcji oraz zapewnienie automatycznego odzyskiwania danych może być zatem istotne na tym etapie. Team zajmuje się tu wskaźnikami, zrozumieniem urządzeń, badaniem problematycznych obszarów. W niektórych przypadkach SRE może poprosić zespół developerów o przegląd kodu lub samodzielnie wprowadzić w nim zmiany i ująć to w budżecie błędów.


Czego można się nauczyć pracując jako Site Reliability Engineer?

Można dowiedzieć się wiele o złożoności systemu, co w przyszłości może pomóc na etapie przenoszenia go do środowiska produkcyjnego. Obecnie prawie nikt nie jest w stanie pozwolić sobie na pisanie kodu bez myślenia o jego przyszłości. Wszyscy uczestnicy dowolnego większego projektu muszą monitorować obciążenie i bezpieczeństwo. Praca z istniejącymi systemami jako SRE pozwala skrócić ścieżkę i natychmiast zanurzyć się w procesie, obserwując jednocześnie działanie dużego biznesu.

Praca ta pozwala developerom poświęcić ponad 30% czasu spędzanego na pracy z systemem, na przynoszenie korzyści realnym osobom. Mają możliwość zobaczenia i dotknięcia obu współczesnych kierunków w pracy z systemami produkcyjnymi – monitorowania i powiadamiania. Ponadto, narzędzia do tego przeznaczone to programy na licencji open source. Doświadczenie zdobyte przy pracy z nimi może więc być łatwo przeniesione na inne projekty i do innych firm.

Dla inżynierów DevOps, SRE to świetna okazja do lepszego zrozumienia tego, w jaki sposób napisane są systemy. Taka praca pozwala pracować z kodem na tyle blisko, by za 2-3 lata (jeśli chcą) mieć bazę do dalszego rozwoju jako developer.


Czy koncepcja SRE przetrwa długo? Czy tego typu doświadczenie będzie pożądane?

Oczywiście, doświadczenie tego typu będzie nieodzowne. Inżynierowie SR będą stanowić stałe źródło dochodu dla firm chcących angażować się w duże projekty typu enterprise. Systemy stają się coraz bardziej skomplikowane, koszty wzrastają i niemożliwe jest zapamiętanie wszystkich szczegółów wdrażania 200 mikroserwisów. Rola SRE ma zatem szansę stać się w kolejnych latach tak powszechna, jak QA Automation 10- czy DevOps 5 lat temu. By zarządzać projektami, w których pracują setki programistów, będziemy potrzebować ludzi będących w stanie opanować chaos. W przeciwnym wypadku projekty zawalą się pod własnym ciężarem.

Co więcej, doświadczenie w obszarze SRE będzie przydatne nawet dla tych, którzy po upływie jakiegoś czasu będą chcieli wrócić wyłącznie do programowania (albo zacząć!). Umiejętność przewidywania przyszłości za pomocą kodu w środowisku produkcyjnym stanie się normą. Ostatecznie – czy istnieje ktoś, kto ma ochotę być przeklinany przez kolegów z teamu albo – po prostu - użytkowników, dla których płynne funkcjonowanie systemu jest kluczowe?


Od autora

W moim przypadku wyglądało to dość przewrotnie – zajmowałem się Site Reliability Engineering, zanim poznałem ten termin. Studiowałem, by zostać programistą, ale nie popracowałem długo w ramach tej specjalności – zostałem administratorem systemów. Byłem głównym adminem w Mail.ru i razem z nią opuściłem DataArt (DataArt stworzyła Mail.ru, ale kilka lat później serwis oddzielił się od niej i przeniósł się do Moskwy). Wróciłem jednak do firmy i do programowania, zajmowałem się także wydajnością i niezawodnością systemów. Kiedy dowiedziałem się, że jeden z naszych klientów potrzebuje specjalisty SRE, okazało się, że moje doświadczenie administratora, developera i analityka systemowego odpowiada wymaganiom na stanowisko specjalisty SR.

Zobacz kogo teraz szukają