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?
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?
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.
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
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.
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.
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:
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.
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?
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?
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.
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
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.
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.
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:
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.
