W czasach modeli współpracy i powszechnej wydajności w IT, termin Site Reliability Engineering (skrót: SRE) można znaleźć w wielu miejscach. Na czym polega takie podejście do obsługi systemów informatycznych?
Geneza Site Reliability Engineering
Jak to często bywa w przypadku nowoczesnych modeli i metod procesowych, Site Reliability Engineering wywodzi się z dużych amerykańskich firm technologicznych. W przypadku SER było to Google w 2003 roku. Istota modeli biznesowych Google i klucz do sukcesu firmy są ściśle związane z wewnętrznym IT.
Firma Google zawsze szukała w swojej organizacji IT metod i modeli procesowych tak, aby poradzić sobie z szybkim rozwojem. W 2003 roku w Google wszechobecny był ścisły podział między tworzeniem oprogramowania a operacjami IT. Zadawano wówczas następujące pytania dotyczące tych ostatnich: Jak blisko powinny być powiązane zespoły rozwojowe i operacyjne i jakie procesy są niezbędne dla udanej współpracy?
Z tych pytań i uzyskanych odpowiedzi wyłoniła się Site Reliability Engineering jako nowy model działania systemów IT w Google. Ale czym dokładnie jest SRE?
Czym dokładnie jest Site Reliability Engineering?
Site Reliability Engineering obejmuje kilka metod, które są również wykorzystywane w rozwoju oprogramowania lub DevOps. Po pierwsze, SRE traktuje operacje IT jako zadanie, którym należy się zająć za pomocą inżynierii oprogramowania. Dokładniej - systemy są dostarczane i zarządzane za pomocą kodu. Innymi słowy, infrastruktura, przepływy pracy i zadania ręczne są zautomatyzowane, dzięki zastosowaniu oprogramowania, a przez to bardziej niezawodne.
Oprócz automatyzacji istotną rolę w Site Reliability Engineering odgrywa monitoring systemów. Ważne wskaźniki systemowe są stale monitorowane i wizualizowane za pomocą pulpitów nawigacyjnych. Uzyskane dane są nie tylko przeglądane w sposób reaktywny, ale również stale analizowane, ponieważ błędy i podatności systemu są proaktywnie identyfikowane i eliminowane.
Idealna Site Reliability Engineer jest zakorzeniona w rozwoju oprogramowania, ma duże doświadczenie w operacjach IT i powiązanie z analizą danych systemowych. Posiadając ten zestaw umiejętności, skupia się na automatyzacji operacji, planowaniu i projektowaniu niezbędnej infrastruktury, monitorowaniu aktywnie działających systemów i analizowaniu ich wydajności. Wszystko to w celu zidentyfikowania potencjalnych obszarów do poprawy.
Site Reliability Engineers dzielą swój czas pomiędzy zadania operacyjne oraz rozwój oprogramowania i narzędzi do optymalizacji. W przypadku niepowodzenia poprawiają je, a następnie zwykle szczegółowo omawiają z osobami zaangażowanymi w projekt, aby dowiedzieć się, co zadziałało dobrze, a co wymaga poprawy. Ponadto Site Reliability Engineers gromadzą ważną, nieudokumentowaną wiedzę. Dzięki zrozumieniu dziedzin rozwoju i wsparcia wiedza ta może być wykorzystywana we wszystkich sektorach.
Oprócz opisanych już podstawowych elementów technologicznych Site Reliability Engineering, metodyka ta opiera się również na kilku podstawowych zasadach metodologicznych, które zostaną omówione bardziej szczegółowo poniżej.
Site Reliability Engineering opiera się na zestawie uznanych metod w tworzeniu oprogramowania. Ponadto, SRE ma wiele podobieństw do metod stosowanych w DevOps. Dwie najbardziej oczywiste różnice w stosunku do DevOps to fakt, że Site Reliability Engineering ustanawia niezawodność (systemu) głównym priorytetem będącym centrum działań oraz że specyfikacje muszą być przestrzegane w znacznie bardziej wiążący sposób. Największe podobieństwa z DevOps to podstawowe działania, takie jak ciągłe monitorowanie i konsekwentna automatyzacja procesów i przepływów pracy.
Centralną metodą, którą wykorzystuje SRE są tzw. obwody dodatnie. W ten sposób wyznacza się cele i określa wskaźniki ich pomiaru. Częścią obwodów dodatnich jest również radzenie sobie z błędami. W dalszej części artykułu opisano zasadę działania obwodów dodatnich w jej poszczególnych elementach.
SLO i SLI
Site Reliability Engineering definiuje dla każdego systemu, jak powinien wyglądać odpowiedni poziom niezawodności. „Service Level Objective" (SLO) wskazuje, jak niezawodnie musi działać system, aby spełnić wewnętrzne specyfikacje lub wymagania klienta. Może to oznaczać na przykład, że system powinien dostarczać 90% pomyślnych wyników w określonym czasie.
SRE wykorzystuje „Service Level Indicator" (SLI), aby określić czy ten cel, a także zdefiniowana powyżej niezawodność zostały osiągnięte. SLI to wskaźniki, które dostarczają informacji np. o tym, ile żądań zostało zrealizowanych pozytywnie i ile z tych żądań dotrzymało określonego terminu. Wykorzystując SLI można dokonać kwalifikowanego stwierdzenia, czy SLO zostanie osiągnięty, a jeśli nie, to na jakim etapie istnieje potrzeba optymalizacji
Budżet błędów
Aktualizacje i nowe wydania dostarczają nowych funkcji, ulepszają istniejące i usuwają luki w zabezpieczeniach. Podstawowym problemem tworzenia oprogramowania jest to, że nie da się zaplanować nieskończonej ilości czasu, aby w pełni przetestować każdy możliwy scenariusz przed wydaniem kolejnej wersji. Ponadto, w tym kontekście pojawia się pytanie czy i kiedy doskonała niezawodność systemu jest odpowiednia.
Site Reliability Engineering działa w oparciu o podstawową zasadę, zgodnie z którą w każdym systemie istnieje budżet błędów. Budżet ten jest obliczany z teoretycznie możliwej niezawodności 100% minus niezawodność faktycznie stosowana i odnosi się do określonego okresu, np. jednego miesiąca. Dlatego, posługując się powyższym przykładem, budżet błędów wynosiłby 10% (100% minus 90%). Zatem dopuszczalne byłoby, gdyby dana funkcjonalność miała poziom błędu do 10%.
Dlatego dopóki SLO ma kolor zielony, nie ma potrzeby tracić czasu i budżetu na tę metodę, szukając teoretycznej, idealnej sytuacji doskonałej niezawodności. Dopiero po wykorzystaniu budżetu błędów należy podjąć działania i wprowadzić usprawnienia, np. wstrzymać wydanie w celu zwiększenia niezawodności.
Uczenie się na błędach – bez orzekania o winie
W przypadku dużych błędów systemowych lub awarii o poważnych konsekwencjach, sensowne jest późniejsze, dokładne przeanalizowanie przyczyn tych błędów. Tylko w ten sposób można wyciągnąć z nich wnioski i w idealnej sytuacji uniknąć podobnych przypadków w przyszłości.
To co jest szczególne w Site Reliability Engineering to fakt, że te analizy błędów muszą świadomie odbywać się w sprzyjającym kontekście. Zamiast obwiniać jednostki lub zespoły za błąd, SRE skupia się na problemie i jego przyczynach. Pytanie nie brzmi "kto ponosi winę za ten błąd?", ale "jakie okoliczności doprowadziły do powstania tego błędu?".
W ten sposób można zidentyfikować przyczyny, takie jak brakujące informacje lub złe procesy operacyjne, które mogły przyczynić się do wystąpienia błędu. SRE bezwarunkowo zapewnia, że nikt nie zostanie ukarany za zaistniały błąd. Zamiast tego, należy znaleźć sposób na uniknięcie go w przyszłości poprzez podjęcie odpowiednich działań. W ten sposób cała organizacja może uczyć się na błędach i w dłuższej perspektywie poprawić niezawodność systemów.
Zalety Site Reliability Engineering
Jest oczywiste, że Site Reliability Engineering opiera się na zestawie narzędzi technicznych i jasnych zasadach. Jakie są jednak zalety SRE w stosunku do podobnych modeli operacyjnych? Poniżej przedstawiamy sześć głównych argumentów przemawiających za wdrożeniem SRE:
- Ulepszona sprawozdawczość: SRE zapewnia przejrzystość poprzez stałe monitorowanie ważnych parametrów, takich jak produktywność, stan usługi i poziom błędów. Konkretne elementy (np. średni czas przestoju) wynikają z pomiarów, które są poprawiane za pomocą rozwiązań;
- Proaktywne rozwiązywanie problemów: wiele organizacji IT skupia się przede wszystkim na wdrażaniu nowych zasobów. Jednak coraz szybszy rozwój i wdrażanie niosą ze sobą ryzyko wystąpienia błędów i luk. SRE przeciwdziała temu poprzez proaktywne wyszukiwanie błędów i problemów oraz rozwiązywanie ich, zanim dotrą do użytkownika;
- Wartość dodana: niezawodne systemy informatyczne oznaczają, że w korektę błędów można zainwestować mniejszy potencjał rozwojowy. Zespoły DEV automatycznie mają więcej czasu na rozwój nowych funkcjonalności. SRE wykrywa ewentualne problemy przed wdrożeniem;
- Zmiana kulturowa: Site Reliability Engineering przynosi nowe zrozumienie stanu systemów w organizacjach IT. Ciągłe poszukiwanie potencjału optymalizacyjnego ma pozytywny wpływ na wszystkie zaangażowane zespoły i sprzyja globalnej współpracy. Poczucie odpowiedzialności zbiorowej, które zapewnia SRE, odgrywa dużą rolę we współpracy między zespołami;
- Wysoki poziom automatyzacji: Site Reliability Engineers nieustannie starają się zautomatyzować odpowiednie przepływy pracy. Tę postawę stosują również we własnej pracy. Korzystając z nowoczesnego łańcucha narzędzi, stale optymalizują swoje procesy robocze. Dzięki temu, stopniowo zmniejsza się podatność na błędy spowodowane przez element „ludzki”;
- Zadowoleni klienci: W przeciwieństwie do innych modeli operacyjnych, SRE skupia się na poprawie doświadczenia klienta, przy czym „klientem” może być tutaj klient wewnętrzny i zewnętrzny lub użytkownik systemu. Wykorzystując SLO i SLI, SRE wyznacza jasne cele w zakresie niezawodności systemu, a tym samym satysfakcji klienta.
Wniosek
Jeszcze jedna metoda… Site Reliability Engineering to coś więcej. Podejście to stanowi wzbogacenie współczesnej kultury IT, ponieważ w bardzo pragmatyczny sposób wypełnia lukę pomiędzy rozwojem i operacjami IT. Tam, gdzie inne podejścia pozostają raczej teoretyczne lub co najwyżej zapewniają ramy działania, SRE staje się bardzo konkretne.
Dzięki ciągłemu monitorowaniu i analizie wydajności systemu, problemy są wcześnie identyfikowane i przyczyniają się do optymalizacji i niezawodności.
Interesująca pozostaje kwestia indywidualnej adaptacji podejścia w firmie i organizacji informatycznej.
Zasady Site Reliability Engineering mają zastosowanie od nowoczesnych start-upów do globalnych potęg technologicznych, takich jak Google czy Microsoft. Do wprowadzenia zalecana jest zasada koncentracji na poszczególnych artefaktach SRE (np. wdrożenie najpierw rozwiązania monitorującego).
Można powiedzieć, że Site Reliability Engineering ma potencjał, aby zwiększyć wartość organizacji IT, ponieważ podejście to kojarzy się właśnie z wartością dodaną dla biznesu.