Popularność Site Reliability Engineering gwałtownie rośnie, ale wciąż nie jest to powszechna specjalność. Dla niektórych 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ć, aby rozjaśnić, czego wymaga się od osób, które chcą zajmować się SRE. 1. 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. 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%. 2. 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, aby 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ć, aby 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 Site Reliability 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. Site Reliability specjalista 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ę podstawowymi zadaniami, a zamiast tego rozwiązuje 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. 3. 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 Reliability 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. 4. Czym jest niezawodność i 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, aby nie przesadzić i nie mierzyć tego, co nas nie interesuje. Przykładowo, 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źnikami na poziomie usług, np. wskaźnikami biznesowymi. System lepiej służy użytkownikom nie wtedy, gdy procesor jest mniej obciążony, ale i wtedym 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 ich wyeliminowanie. Wraz z przedstawicielami strony biznesowej, inżynierowie SR ustalają Service Level Objectives (SLO), czyli np. cele na poziomie usług i akceptowalne wskaźniki niezawodności. 5. Jakie wykształcenie i doświadczenie powinien posiadać specjalista SR? Koncepcja Site Reliability Engineering IT 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. Klasyczne przykłady zadań to: ciągły brak pamięci w rejestrach serwera; wyczerpanie puli wątków, kiedy np. niektóre wątki nie są zwracane; czy sytuacja, w której jeden z 3 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. 6. 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. 7. Czy praca SRE jest rutynowa? 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, aby 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. 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. 8. Czy SRE pracują z developerami, czy jest to osobny zespół? Praktykowane są 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. 9. 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ć jedną trzecią 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, aby za 2-3 lata - jeśli chcą - mieć bazę do dalszego rozwoju jako developer. 10. Czy koncepcja SRE przetrwa długo? Czy tego typu doświadczenie będzie pożądane? Moim zdaniem, doświadczenie tego typu stanie się 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. Aby 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ąć to robić. 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? Gregory Burmistrov, System Analyst, Site Reliability Engineer w DataArt; wcześniej był głównym administratorem w Mail.ru i razem z tą spółką opuścił DataArt (która stworzyła Mail.ru), wrócił jednak do firmy i do programowania, zajmowałem się także wydajnością i niezawodnością systemów.
