SRE to skrót, który w moim przekonaniu pojawia się w otoczeniu IT z coraz większym natężeniem. Kilka tygodni temu wpadł mi w ręce opis stanowiska pracy dla project managera, w którym była wspomniana współpraca z SRE. W nowym modelu pracy mojego projektu również długofalowo mają zostać uwzględnieni SRE, a w ostatnim tygodniu co najmniej dwie osoby spytały mnie o to, co na temat tej roli wiem.
W dzisiejszym artykule podsumujemy więc rolę Site Reliability Inżyniera (ang. Site Reliability Engineer) odnosząc ją jednocześnie do, wydawać by się mogło, całkiem podobnej roli devopsa.
SRE – etymologia pojęcia
SRE reprezentuje podejście inżynierii oprogramowania do zadań operacyjnych w projekcie. Zadania te często, szczególnie w mniejszych projektach są wykonywane ręcznie. SRE wykorzystują oprogramowanie jako narzędzie do automatyzacji tych zadań, zarządzania.
Na specjalnej stronie, którą Google zadedykował SRE możemy przeczytać, że „SRE jest tym, co dostajesz, kiedy zadania operacyjne zaczynasz traktować jak problem programistyczny do rozwiązania” (ang. „SRE is what you get when you treat operations as if it’s a software problem”). Jest to pojęcie, które zostało wymyślone przez Bena Treylora Slossa w Google w 2010 roku. To właśnie Ben był liderem pierwszego zespołu SRE. Nie oznacza to jednak, że ta koncepcja ujrzała światło dzienne w Google dopiero w 2010-tym roku. Tak naprawdę było to podejście, które zmieniało się ewolucyjnie już od pierwszych lat XXI wieku. To właśnie wtedy przy pracy nad Google web search pracownicy Google musieli stawić czoła następującemu problemowi:
Zespoły produktowe (deweloperskie) są mocno skoncentrowane na rozwoju biznesu i wypuszczaniu na produkcję coraz to nowych funkcjonalności. Zależy im na czasie wypuszczenia ich na produkcję. Chcą działać coraz szybciej. Nie znają się za bardzo na praktykach operatorów.
Jednocześnie operatorzy czyli zespoły odpowiedzialne za utrzymywanie kodu na produkcji, wdrażanie nowych deploymentów zwracają uwagę na stabilność całego rozwiązania, na bezproblemowe działanie całej implementacji w środowisku produkcyjnym. Nie rozumieją za bardzo nuansów implementacji. Chcąc podnosić jakość, optują za wolniejszym działaniem i wprowadzaniem mniejszej ilości zmian do bazy kodowej.
Myślę, że na podstawie powyższego opisu łatwo jesteś w stanie zrozumieć konflikt, jaki nieuchronnie musiał pojawić się pomiędzy operatorami a programistami. Właśnie, aby zasypać ten podział w Google wprowadzono pojęcie devopsa. Zrozumienia tej roli potrzebujemy koniecznie, aby później wyjasnić rolę SRE.
Devopsi w odpowiedzi na zaistniałe problemy
Devopsi czyli specjaliści działający na styku developmentu i operations mieli ułatwić komunikację pomiędzy programistami a operatorami. Uprościć współpracę i przeciwdziałać izolacji. Skrócić czas dostarczania oprogramowania i jednocześnie zwiększać jego stabilność i jakość. Postawiono im za zadanie skoncentrowanie się na pięciu głównych obszarach:
- Zredukowanie organizacyjnych silosów
- Postrzeganie porażki jako normalnego stanu rzeczy
- Implementacja stopniowych zmian
- Współwykorzystywanie narzędzi i automatyzacji (optymalizacja wykorzystania)
- Mierzenie wszystkiego
W definicji devops czytamy, iż jest to zbiór praktyk, swoista filozofia, która opiera się na wspomnianych powyżej filarach. Zauważmy jednak, że samo podejście devops niekoniecznie mówi nam, JAK powinnimy wymienione powyżej zasady wcielić w życie. Jak redukować organizacyjne silosy? Jak automatyzować, CO i JAK mierzyć?
Czym zajmuje się SRE?
Właśnie tutaj z pomocą przychodzi nam SRE. W poniższym filmie inżynierowie Google wyjaśniają różnicę pomiędzy tymi dwoma rolami:
Możemy powiedzieć, że SRE jest odpowiedzią na filozofię przedstawianą przez devops. Odpowiada na pytanie JAK chcemy tę filozofię wdrażać i realizować. Idąc kolejno:
- Zredukowanie organizacyjnych silosów – dzielenie odpowiedzialności za rozwiązanie programistyczne pomiędzy osoby będące częścią różnych zespołów, np. produktowych i operations
- Postrzeganie porażki jako normalnego stanu rzeczy – wprowadzanie SLIs, SLOs, SLAs oraz kultury nieobwiniania ( ang. blameless PM)
- Implementacja stopniowych zmian – wprowadzanie rozwiązań programistycznych (m.in. Blue/green deployments), które pozwalają na sprawne wycofanie deploymentu nowej wersji produkcyjnej, szybkie wychodzenie ze stanu, w którym kod nie działa (ang. easy recovery)
- Współwykorzystywanie narzędzi i automatyzacji (optymalizacja wykorzystania) – prowadzenie ewidencji wykorzystywanych narzędzi, wprowadzanie wykorzystywanych standardów, automatyzowanie
- Mierzenie wszystkiego – mierzenie i nazywanie ilości pracy do wykonania, obciążenia zespołów; mierzenie jakości dostarczanych rozwiązań, przygotowywanie automatycznych raportów i statystyk wspierających przyszły proces decyzyjny
Jeśli znasz Javę, przemówi do Ciebie następująca metafora:
class SRE implements devops
Zwróć uwagę, że SRE może być używane w różnych znaczeniach w zależności od kontekstu. Możemy określać je z różnych perspektyw- jako:
- rolę/stanowisko Site Reliability Engineer
- zespół dobrych praktyk inżynieryjno-programistycznych, które mają zapewnić dostarczanie niezawodnego oprogramowania o wysokiej szybkości rozwiązywania problemów
- mindset
Google jako propagator SRE
Do tej pory firma Google jest dużym propagatorem SRE. Na ich stronach możemy znaleźć informację, jak Google Cloud Platform wspiera stosowanie tego podejścia. Nie oznacza to jednak, że tylko oni jako jedyni według tego podejścia pracują. Coraz więcej firm zaczyna odnosić się do tego modelu.
W swojej pracy „Site Reliability Workbook” Stephen Thorn opowiada, jak duże i małe organizacje mogą wykorzystać SRE, aby zmniejszyć koszty operacyjne, zwiększyć niezawodność oprogramowania i przyczynić się do formowania produktywnych cross-funkcyjnych teamów. Bardzo istotną cechą, z którą należy kojarzyć SRE jest również nacisk położony na skalowalność. Wiele problemów operacyjnych jest dyktowanych takimi czynnikami jak koszty operacyjne lub nakład pracy.
Nie należy również zapominać o psychicznym dobrostanie zespołu deweloperskiego odpowiedzialnego za rozwiązanie produkcyjne, które cały czas jest modyfikowane. Google odnosi się do tego aspektu jako do psychological safety. Porusza się między innymi kwestię tak często występującą w projekcie – kiedy zespół nie nadąża z wykonywaniem swojej pracy/”obsługą” takiej produkcji, najgorszym rozwiązaniem jest odpowiedź „pracujcie ciężej i więcej”. Oczywiście w przypadku, kiedy taki stan rzeczy utrzymuje się przez dłuższy okres czasu.
Dla osób chcących zgłębić temat Google przygotował wiele ciekawycdh materiałów: