Czym jest SRE i dlaczego tester powinien je znać?

Jeśli jesteś testerką/testerem i interesują Cię bardziej wymagające technicznie zagadnienia: programowanie, tematy DevOps, architektura systemów i szeroko pojęta automatyzacja procesów, to dziedzina Site Reliability Engineering (SRE) również powinna przypaść Ci do gustu.

 
Wpis powstał we współpracy z DREDAR. Autorem tekstu jest Adrian Gonciarz.

 

Co ma SRE do testowania?

W świecie, w którym duża część prostych zadań przejmowana jest przez AI, a stopień skomplikowania systemów i architektury IT rośnie, coraz ważniejsze jest porządkowanie tego wszystkiego w trosce o jakość (Quality of Service) i dostępność (Availability) tych usług działających w środowisku produkcyjnym. Jak przeczytasz poniżej, SRE jest blisko spokrewnione z Quality Control (czyli testowaniem), a jeszcze bardziej z Quality Assurance (czyli QA, często mylnie utożsamianym z testowaniem).

 

Czym zajmuje się SRE?

Coraz rzadziej mierzymy się z błędami w postaci niedziałającego przycisku, brzydkiego renderowania strony czy zepsutego logowania. Problemy, z którymi mierzymy się obecnie, wynikają z ogromnej ilości danych przetwarzanych przez systemy oraz nieustannej pogoni za błyskawicznym i stabilnym działaniem aplikacji obsługujących jednocześnie dużą liczbę użytkowników. Co więcej – użytkownikami naszych aplikacji nie są już tylko ludzie tacy jak Ty i ja, ale coraz częściej agenci, pełniący funkcję reprezentantów końcowego klienta. Sieć połączeń gęstnieje, centra danych się rozrastają, ilość wymienianych danych rośnie. Tu właśnie wkracza SRE, którego celem jest dbanie o niezawodność systemów.

Filozofia Site Reliability Engineering wywodzi się z firmy Google, gdzie powstała jako połączenie metod programistycznych z administracją systemów w celu zwiększenia dostępności i jakości usług dostarczanych przez Google. Główne zadania inżynierów zajmujących się SRE to:

• Wdrażanie i usprawnianie monitoringu infrastruktury i aplikacji, korzystając z metryk, logów oraz trace’ów (oraz wszystkich innych dostępnych źródeł telemetrii)
• Automatyzacja żmudnych, powtarzalnych czynności związanych z administracją w celu minimalizacji „ręcznej roboty” (ang. „toil”)
• Optymalizacja kosztów i poprawa wydajności
• Testowanie wydajności
• Chaos testy
• Dostarczanie narzędzi, które pozwalają innym członkom organizacji na śledzenie stanu systemu w sposób proaktywny i reaktywny
• Usprawnianie procesów na podstawie nauki wyciąganej z incydentów (post-mortem)
• Wdrażanie miar związanych z dostępnością i jakością usług we współpracy z zespołami

Jak widzisz, jest tego całkiem sporo. W praktyce SRE jest bardzo zróżnicowaną dziedziną, która wymaga (podobnie jak testowanie) komunikacji z różnymi członkami zespołu, zrozumienia charakterystyki i wymagań stawianych systemowi oraz ma silny związek z automatyzacją. Używa jednak innego zestawu narzędzi oraz skupia się dużo bardziej na obserwacji i przewidywaniu potencjalnych awarii. Inżynier SRE musi być nie tylko znawcą swojego systemu, ale także komfortowo czuć się w programowaniu, administracji systemami czy debugowaniu aplikacji. Wymagany jest również całkiem szeroki wachlarz narzędzi, z którymi SRE pracują na co dzień: Prometheus, Grafana, Kubernetes, Puppet, Ansible, Terraform, Jaeger, Elastic Stack, etc.

Dlatego właśnie uważam, że SRE to bardzo ciekawa ścieżka dla osoby, która ma w sobie ciekawość i interdyscyplinarne podejście wywodzące się z testowania, ale potrzebuje dużo bardziej technicznie wymagającej roli.

 

Typowy dzień pracy Site Reliability Engineera

Wstaję rano, piję kawę… A tak poważnie, to typowy dzień pracy SRE zależy mocno od tego, jak organizacja zdefiniowała sobie tę rolę. W niektórych firmach zadania skupiają się bardzo mocno na pracy z infrastrukturą i platformą, dostarczaniu zespołom programistycznym narzędzi, dzięki którym same będą mogły szybciej i skuteczniej zapobiegać lub reagować na awarie. W innych przypadkach SRE jest mocno zorientowane na operacje lub klienta końcowego. Wtedy SRE skupia się na metrykach, dashboardach czy definiowaniu SLO (Service Level Objective). Często jest to mieszanka tych dwóch podejść – patrząc na finalnego użytkownika, szukamy braków na niższych poziomach i możliwości optymalizacji oraz naprawy „dziur”, przez co nasza praca jest bardzo barwna i nie możemy narzekać na nudę.

Żeby nie być gołosłownym – moje ostatnie zadanie polegało na zwiększeniu obserwowalności w aplikacji zarządzającej flotą robotów w fabrykach. Zacząłem od rozmów z product ownerem, żeby zrozumieć, co jest dla niego ważne. Potem zapoznałem się z API, w którym aplikacja wystawia swoją telemetrię (informacje o statusie baterii, położeniu, błędach, etc.). Używając narzędzi open-source (Json Exporter, Prometheus, Grafana), przetłumaczyłem JSON z odpowiedzi API na metryki Prometheusa i zwizualizowałem ważne informacje na dashboardach oraz wprowadziłem alerty. Całość oczywiście znajduje się w repozytorium, które pozwala zarządzać infrastrukturą jako kodem (IaC w postaci Ansible). W efekcie owner aplikacji ma lepszy pogląd na status i problemy z flotą robotów, co pozwala uniknąć poważniejszych awarii.

 

Rynek pracy dla SRE

SRE jest ciągle stosunkowo świeżą dziedziną i nie do końca dobrze zdefiniowaną. W zasadzie każda organizacja implementuje praktyki SRE na swój sposób, a co za tym idzie, oferty pracy dla SRE mogą się znacząco różnić. Jest ich jednak coraz więcej i przypomina mi to trochę czas, w którym pojawiło się modne hasło „DevOps” – wtedy zarówno definicja tej metodyki, jak i ról z nią związanych, mocno ewoluowały. Jedno jest tutaj dla mnie pewne – osoba o wysokich umiejętnościach technicznych, znajomości zasad projektowania i monitorowania systemów z doświadczeniem w programowaniu (czyli taki tester skrzyżowany z „DevOpsem”) będzie w zespole na wagę złota. Rynek pracy również docenia takie umiejętności, a oferty pracy z wynagrodzeniem w okolicach 30k PLN nie należą w tej branży do rzadkości.

Ważne: można również (i w większości przypadków należy!) wdrażać SRE w firmach, w których formalna rola/etat SRE nie istnieje. W takiej konfiguracji wyżej wymienione aktywności są rozdzielane na poszczególnych członków zespołu – administratorów, programistów, devopsów czy testerów.

 

Gdzie uczyć się Site Reliability Engineering?

Jeśli chcecie dowiedzieć się więcej o SRE, warto zacząć od źródeł, czyli materiałów Google (https://sre.google/). Na tej stronie znajdziecie nie tylko dokładniejszy opis wszystkich elementów, ale także darmowe książki. Świetny wybór to też książka „Seeking SRE. Conversations About Running Production Systems at Scale” autorstwa Davida N. Blank-Edelman’a.

Jeśli lubicie blogi, to gorąco polecę ekipę Dynatrace. To prawdziwi pasjonaci SRE, a w dodatku świetni edukatorzy: https://www.dynatrace.com/news/blog/what-is-site-reliability-engineering/

A jeśli, razem ze swoim zespołem, chcielibyście nie tylko dowiedzieć się więcej, ale i „pobrudzić sobie ręce” i wejść w rolę Site Reliability Engineera – możecie rozważyć udział w szkoleniu, które zaprojektowałem i prowadzę: Praktyczne wprowadzenie do SRE. Serdecznie zapraszam!

Adrian Gonciarz