Jesteś fanem DevOps? Poczekaj, aż poznasz SRE

Czym w ogóle jest SRE?

Inicjator koncepcji SRE po stronie Google, Ben Treynor, nie opublikował jeszcze zwartej definicji, ale opisuje niezawodność lokalizacji jako „wynik przydzielenia inżynierowi oprogramowania zadań tradycyjnie związanych z eksploatacją”.

Podstawowy problem jest następujący: Zespoły programistów chcą wydawać masowo fantastyczne nowe funkcje i obserwować, jak w wielkim stylu podbijają rynek. Zespoły operacyjne chcą mieć pewność, że te funkcje niczego nie zepsują. W przeszłości prowadziło to do wielkiej próby sił. Zespoły ds. eksploatacji IT starały się hamować dążenia do możliwie największej liczby wydań, a zespoły programistów poszukiwały sprytnych sposobów obchodzenia powstrzymujących je procesów. (Założę się, że to brzmi znajomo).

Koncepcja SRE eliminuje przypuszczenia i dyskusje na temat tego, co i kiedy można wdrożyć. Wprowadza wzór matematyczny określający uzyskanie przez wdrożenia zielonego lub czerwonego światła oraz wyznacza zespół ludzi kompetentnych w zakresie eksploatacji systemów (nazywanych inżynierami ds. niezawodności lokalizacji lub inżynierami SRE), którzy stale nadzorują niezawodność produktu. Andrew Widdowson pełniący funkcję inżyniera SRE w Google opisuje to w następujący sposób: „Nasza praca przypomina bycie członkiem najbardziej ekstremalnej załogi technicznej Formuły 1. Zmieniamy opony w samochodach wyścigowych pędzących z prędkością 160 km/h”.

Nie ma w tym jeszcze nic rewolucyjnego, prawda? Cała magia kryje się w sposobie działania. Poniżej przedstawiamy niektóre z podstawowych zasad, które równocześnie stanowią przykłady największych odstępstw od tradycyjnego podejścia do eksploatacji IT.

Po pierwsze nowe wdrożenia dostają zielone światło w oparciu o aktualną wydajność produktu

Większość aplikacji nie osiąga 100% dostępności. W związku z tym dla każdej usługi zespół SRE konfiguruje umowę o gwarantowanym poziomie świadczenia usług (SLA), w której określa wymaganą niezawodność systemu z perspektywy użytkowników końcowych. Jeśli zespół przystaje na umowę SLA z poziomem dostępności 99,9%, oznacza to, że jego budżet błędów wynosi 0,1%. Budżet błędów jest dokładnie tym, co sugeruje jego nazwa: maksymalnym dopuszczalnym progiem błędów i przerw w dostępie do usługi.

Fachowa porada: dzięki tej fajnej ściągawce dotyczącej czasu dostępności z łatwością przekonwertujesz parametry umów SLA na „minuty przestoju”.

A oto rozstrzygający argument: Zespół programistyczny może wykorzystać ten budżet błędów w dowolny sposób. Jeśli produkt działa obecnie bez zarzutu, a liczba błędów jest niewielka lub nie ma ich wcale, mogą wdrożyć, co tylko zechcą i kiedy zechcą. I odwrotnie, jeśli wyczerpali lub przekroczyli budżet błędów i funkcjonują na granicy lub poniżej granicy zdefiniowanych wskaźników SLA, wszystkie wdrożenia zostają wstrzymane do czasu zmniejszenia liczby błędów do poziomu umożliwiającego dalsze wdrażanie.

Genialne, prawda? Zarówno inżynierowie SRE, jak i programiści mają silną motywację do współpracy w celu zminimalizowania liczby błędów.

Inżynierowie SRE też mogą pisać kod

W starym modelu stawiało się ludzi przed problemem z niezawodnością i naciskało (czasami przez rok, a nawet dłużej), aż problem znikał lub zmieniał się w katastrofę.

W SRE jest inaczej. Zespoły programistyczny i SRE korzystają z tej samej puli personelu, dlatego każdy zatrudniony inżynier SRE oznacza jednego programistę mniej (i odwrotnie). To kończy odwieczną bitwę o poziom zatrudnienia między zespołem programistycznym i operacyjnym. Tworzy także system samokontroli, w którym programiści otrzymują nagrodę w postaci zwiększenia liczby członków zespołu, jeśli piszą lepiej działający kod (czyli kod, którego wsparcie może zapewnić mniejsza liczba inżynierów SRE).

Programiści nie siedzą z założonymi rękami

W Google Ben Treynor musiał walczyć o ten zapis i cieszy się, że to zrobił. W swoim fenomenalnym wystąpieniu na temat SRE w trakcie konferencji SREcon14 podkreślił, że uzyskanie takiego zobowiązania od kierownictwa wyższego szczebla powinno być obowiązkowe przed wdrożeniem SRE.

Zasadniczo zespół programistyczny wykonuje 5% wszystkich prac związanych z eksploatacją (czyli obsługą zgłoszeń, udzielaniem wsparcia w trakcie dyżurów domowych itp.). Dzięki temu programiści pozostają w bliskiej styczności ze swoim produktem, obserwują sposób jego działania i mogą podejmować lepsze decyzje dotyczące kodu oraz wydań.

Ponadto za każdym razem, gdy działalnością operacyjną przekracza potencjał wykonawczy zespołu SRE, nadmiarowe prace zawsze przypisuje się programistom. Gdy system funkcjonuje prawidłowo, programiści także zaczynają samodzielnie regulować swoją pracę, pisząc dobrze działający kod i uważnie planując wdrożenia, aby zapobiegać problemom w przyszłości.

Inżynierowie SRE są wolnymi agentami (których można odsunąć w razie potrzeby)

Aby atmosfera w zespołach była zdrowa, a ich członkowie zadowoleni, Treynor zaleca umożliwienie inżynierom SRE przechodzenia do innych projektów według własnego uznania, a nawet do innej organizacji. Koncepcja SRE zachęca do efektywnej pracy grupowej z wysokim poziomem zaangażowania i motywacji, dlatego żadnego członka zespołu nie powinno się powstrzymywać od realizacji osobistych celów.

Jeśli cały zespół inżynierów SRE i programistów po prostu się nie dogaduje i stwarza więcej problemów niż niezawodnego kodu, można podjąć drastyczne środki w postaci wyłączenia całego zespołu SRE z projektu i przypisania wszystkich prac związanych z eksploatacją zespołowi programistów. Treynor posunął się do tego tylko kilkakrotnie w swojej karierze, jednak sama groźba zastosowania takich środków zazwyczaj wystarczy, aby obydwa zespoły porozumiały się i wypracowały bardziej pozytywne relacje zawodowe między sobą.

O SRE można napisać trochę więcej niż to, co znalazło się w tym artykule — na przykład, jak SRE zapobiega incydentom w środowisku produkcyjnym, jak obsadza się zespoły wsparcia pełniące dyżur domowy oraz jakich reguł przestrzegają poszczególne zmiany itp.

Nasze podejście

Środowisko IT jest z pewnością pełne modnych haseł i trendów. W jednej chwili jest to chmura, w następnej DevOps, a jeszcze później doświadczenia klienta czy grywalizacja. SRE jest na dobrej drodze, aby stać się czymś więcej, zwłaszcza że w tej koncepcji chodzi w większym stopniu o ludzi oraz procesy, a nie o technologię, która leży u ich podstaw. Choć technologia z pewnością może zostać (i prawdopodobnie zostanie) dostosowana do tej koncepcji w miarę, jak zacznie ona dojrzewać, a liczba korzystających z niej zespołów będzie rosnąć, nie potrzebujesz nowych narzędzi, aby skoordynować działania zespołów programistycznego i operacyjnego zgodnie z zasadami SRE.

W kolejnych artykułach przyjrzymy się właśnie temu: praktycznym krokom, które należy podjąć, aby wdrożyć SRE, oraz roli, jaką może odgrywać technologia.