Site Reliability Engineering SRE (Inżynieria niezawodności), czyli jak dbać o niezawodność usług

Site Reliability Engineering SRE (Inżynieria niezawodności) to pojęcie, które zostało szybko spopularyzowane w branży IT przez Google'a. O co tak naprawdę chodzi w SRE i czym się różni od DevOps? Sprawdźcie nasz przewodnik po inżynierii niezawodności!

Jako Hostersi, zarządzając infrastrukturami od ponad 12 lat, już dawno odkryliśmy pewne niezwykle ważne zasady, pomagające utrzymywać serwisy i usługi. Współpraca z Developerem to podstawa. Oczekiwania biznesowe klienta w zakresie dostępności i jakości dostarczanej usługi zawsze były podstawą w naszej pracy - i to mimo panujących różnić w podejściu i stereotypów opowiadanych o współpracy programistów i adminów. Liczy się, jak dobrze działa usługa dla odbiorcy końcowego - czy zawsze jest dostępna i czy zawsze działa odpowiednio szybko. Dlatego nie jest dla nas żadnym zaskoczeniem kultura DevOps, jak również coraz popularniejsze określenie na proces utrzymania infrastruktur - tworzenie niezawodnie działających serwisów - Site Reliability Engeneering. Dla nas to określenie tego, co w całym procesie utrzymania powinno być oczywiste (w tym jasne ustalenie odpowiedzialności i kryteriów niezawodności). Samo SRE to swoista ewolucja w podejściu do zarządzania platformami IT i współpracy zarządu-biznesu-adminów-developerów.

Pojęcie SRE powstało w Google, które użyło go do nazwania podejścia do utrzymania infrastruktur. Zadaniem SRE jest stworzenie i utrzymanie skalowalnego i niezawodnego systemu. Cała ewolucja - od zwykłej administracji serwerami przez DevOpsów do SRE - odbyła się, ponieważ oczekiwania ludzi tworzących kod i tych od utrzymania systemów były odmienne i często polegały na poszukiwaniu winnych. Programiści (na których naciskał biznes) oczekiwali możliwości błyskawicznego wprowadzania zmian bez względu na ew. błędy i koszty. Z kolei administratorzy poszukiwali stabilności - jak najmniej zmian, dokonywanych w kontrolowany sposób, aby nie być zaskoczonym gwałtownymi problemami. Czyli spokój, nic nie ruszać i nie zmieniać, skoro do tej pory działało. Z drugiej strony, administratorzy chcieli dokonywać zmian dla nich wygodnych, które powodowały nieprzewidziane nakłady pracy u developerów (duże aktualizacje czy zmiany technologii). Developerzy odpowiedzialni za wprowadzanie nowych funkcjonalności musieli więc „walczyć” z administratorami, którzy chcieli robić wszystko spokojnie i wolniej. Dopiero kiedy działy IT przestały stać obok biznesów firmy, stając jej kluczową i integralną częścią, to wszyscy zrozumieli, że muszą się porozumieć w trosce o końcową usługę, od której przecież zależą ich pieniądze.

Pierwszą ewolucją było więc podejście DevOps, które opiera się na kilku założeniach:

• zlikwidować podziały w organizacji między developerami/administratorami i biznesem,
• awaria i problemy są normą, nie ma rzeczy idealnych, a najwięcej błędów popełnia człowiek,
• pozwolić na wprowadzanie często, wielu i małych zmian w aplikacjach, które można łatwo naprawić i namierzyć ew. problemy,
• wprowadzać narzędzia automatyzujące i właściwy monitoring,
• mierzyć wszystko, co się tylko da.

SRE opiera się na założeniach DevOps i wprowadza jej filozofię w życie. A cel jest jeden - dostarczanie lepszej jakości aplikacji najszybciej jak się da. 

Site Reliability Engineer (pracownik) spędza do 50% czasu na wykonywaniu manualnych prac w systemach, rozwiązywaniu doraźnych problemów i obróbce zgłoszeń. Drugą połowę jego pracy (z tendencją rosnącą) powinny zajmować czynności automatyzujące pracę, usprawnianie monitoringu, dopracowywanie metryk, skalowanie oraz wdrażanie nowych funkcjonalności - czyli prace minimalizujące wykonywanie pracy, której nie lubimy (toil). W sumie dąży więc on do pełnej automatyzacji w każdym aspekcie i zminimalizowaniu incydentów i problemów (dąży, bo nigdy ich nie wyeliminuje). Do takiej roli świetnie nadaje się DevOps czy Administrator z umiejętnościami programistycznymi, a już na pewno rozumiejący developerów (lub programista z wiedzą o zarządzaniu serwerami).

W myśl zasady, że aby coś poprawić, to trzeba to zmierzyć, SRE wprowadza definicję samej niezawodności. Może być ona rozumiana na wiele sposobów, przy czym różnie przez developerów i administratorów. Dlatego najważniejsze jest określenie:

• definicji dostępności usługi,
• poziomu tej dostępności,
• planu działania na wypadek awarii.

Każdy w organizacji - od developera, przez administratora, aż po zarząd musi rozumieć te pojęcia i je akceptować. Jest to niezwykle ważne, gdyż świadomość, że koszty tworzenia usług, których dostępność zbliża się do 100% jest tym większy, im bliżej tych 100% jesteśmy. Być może wymarzone wartości nie są konieczne lub warte wysiłków, być może wymagania trzeba zwiększać stopniowo. Szczególnie, że każde narzędzie posiada swoją specyfikę i 100% niezawodność nie zawsze musi oznaczać to samo dla klienta, co dla twórcy systemu. 

Definicja dostępności usługi i wskaźniki

W celu ustalenia, czy usługa jest dostępna, posługujemy się wskaźnikiem SLI (Service Level Indicator). To on wskazuje nam, jaki parametr systemu jest dla nas akceptowalny, np. ilość błędnych żądań czy odpowiedzi aplikacji, ilość requestów w jednostce czasu, czy czas po jakim aplikacja wykonuje określoną czynność (np. załadowanie strony z produktem w sklepie). Musimy już sami ustalić czy dana wartość jest akceptowalna, czy nie. Dobry wskaźnik to taki, który odpowie nam np. na pytanie czy w ostatnich 5 minutach 99,9% requestów do strony zwróciło zawartość w czasie poniżej 100ms? Albo czy poziom błędów w ciągu ostatnich 15minut był niższy niż 0,1%? Na takie pytania dość łatwo odpowiadają nowoczesne i dobrze zbudowane systemy jak Prometheus, którego na przykład używamy w zespole Hostersi. Oczywiście wymaga to gromadzenia odpowiedniej ilości danych w systemach, które się dobrze skalują.

Po ustaleniu, co mierzymy, musimy ustalić cele wskaźników czyli SLO (Service Level Objectives), które powiedzą nam, czy w dłuższym okresie czasu (np. miesiąca) wybrany SLI utrzymuje się przez 99,9% czasu w ramach ustalonych jako cel w SLI. Pomiar tych rzeczy pozwala nam planować prace, mające na celu zwiększenie i zapewnienie żądanego SLO, a także pozwala nam utrzymywać usługę bardziej niezawodną niż oczekuje odbiorca (w zasadzie niż mu obiecaliśmy, bo oczekiwał będzie zawsze 100%), ale jednocześnie nie tworzyć jej zbyt dobrej, bo to zabiera nam czas, który moglibyśmy poświecić na inne, równie ważne zadania czy wprowadzanie nowych funkcji i rozwiązań. Czyli idealnie jeśli trzymamy się w okolicach SLO. Nie należy tego mylić z obiecanym odbiorcy poziomie bezawaryjności – to, co obiecaliśmy publicznie może być znacznie niższe od tego, co stawiamy sobie za cel wewnętrznie. I dochodzimy w końcu do najbardziej znanego określenia, czyli do SLA (Service Level Agreement). SLA funkcjonuje właśnie w ramach obietnicy biznesowej na rynku, czyli określa/gwarantuje poziom dostępności usługi w % w jednostce czasu (najczęściej miesięcznie, rocznie) dla klienta końcowego. Wartość wpisuje się w ramach umów i gwarancji - w rzeczywistości powinna być wypadkową SLI/SLO, które przyjęliśmy wewnętrznie i robimy wszystko aby dochować.

Kto powinien być najbardziej zainteresowany tymi wskaźnikami? SLI to domena Product Ownera i SRE (inżyniera) - ustalają co znaczy, że usługa jest dostępna, SLO w zasadzie tak samo (Product Owner we wspólpracy z SRE określna czy wartości są wystarczające, aby uznać, że usługa jest niezawodna dla klienta), a SLA to już temat dla sprzedawców, biznesu i klientów. Te wskaźniki kładą podstawy do spełnienia założenia mierzenia parametrów w duchu DevOps czy SRE, jednocześnie tworząc wspólny język w całej firmie, który sprawia, że każdy w organizacji tak samo rozumie,  co oznacza, że usługa jest dostępna. To jest kluczowa rzecz, aby wystąpiło porozumienie ponad dawnymi podziałami - każdy w firmie musi tak samo rozumieć dostępność usługi - pojęcie musi być wspólne. Póki trzymamy się wskaźników, nie można narzekać czy naciskać.

Przy ustalaniu wysokości realnego SLA miejmy na uwadze, że wydające się super fajne 100% jest niezwykle drogie, bardzo trudne technicznie zarówno dla zespołu utrzymania, jak i dla projektantów funkcji i developerów, a co najgorsze - bardzo często użytkownik końcowy nie odczuje tej niemal 100% dostępności, bo po drodze ma bardziej awaryjne elementy, jak np. dostęp do sieci, który przy wyliczaniu SLA końcowego (mnożymy SLA przez siebie jeśli są to elementy szeregowo ułożone - jedna zależy od drugiej) będzie dla niego stanowił o realnym SLA bardziej niż SLA systemu, który mu dostarczamy.

Jednak jak pogodzić chęć do zmian z koniecznością utrzymania ustalonych wyżej parametrów w ustalonych granicach? 

Zawsze musimy przyjąć jakiś poziom ryzyka przy tworzeniu każdego rozwiązania - taką decyzję musi podjąć osoba odpowiedzialna za danych system lub cały zespół produktowy. Muszą rozumieć, co jest kosztowne finansowo i czasowo w procesie tworzenia dodatkowej redundancji zasobów wpływającej na niezawodność. W ideologii SRE pojawia się pojęcie Error Budget, czyli po prostu budżet błędów. Definiuje go ustalone SLO jako czas, kiedy nasz system może nie być dostępny w rozumieniu przyjętych wcześniej wskaźników. Jeśli więc developer chce wdrożyć jakąś bardzo nieprzetestowaną lub złożoną zmianę, szybko musi się liczyć z awarią, która skonsumuje jego "budżet błędów" i sprawi, że nie będzie mógł już niczego przez jakiś czas zmienić, albo będzie musiał to robić bardzo ostrożnie i powoli. Dzięki temu zyskujemy wskaźnik, który jest dzielony pomiędzy Product Managerów a zespół SRE, który pozwala im wspólnie balansować pomiędzy wdrażaniem zmian a stabilnością systemu. Pomiaru dokonujemy, mając dobrze dobrane SLI i system monitoringu. I całą sztuka polega na tym, aby pilnować tych wskaźników i ich nie przekraczać - wyjątki są możliwe, ale muszą wymagać akceptacji przez osoby będące poza zespołem projektowym - kogoś wyżej w organizacji, kto rozstrzygnie czy przekroczenie SLO jest warte uzyskanym efektom (nowe funkcjonalności). Niestety nie każdy podzespół ma wpływ na cały poziom SLO i Error Budget - developer nie będzie winny awarii sprzętowej w serwerowni. Dlatego SLO definiuje sumę wszystkich możliwych awarii, a już do zespołu należy podzielenie budżetu błędów na części adekwatne dla danego zespołu i prawdopodobieństwa wystąpienia. Zespół odpowiedzialny za sieć będzie miał bardzo mały budżet całości, gdy developer będzie mógł skonsumować bardzo istotny jego fragment. I niestety - liczymy tu wszystko, nawet prace planowe. Ma nas to motywować do tworzenia systemów, których utrzymanie nie powoduje przekraczania SLI.

Podsumowując - ryzyko i budżet błędów leżą u podstaw projektowania systemów i zarządzania nimi i są znane DevOpsom. Oczywiste jest, że wypadki się zdarzają a SRE mierzy je poprzez budżet błędów, wymusza to wprowadzanie zmian stopniowo, gdyż wdrożenie dużej zmiany może tak naruszyć SLO dla projektu, że przez kwartał lub nawet dłużej nie będziemy mogli niczego w systemie zmienić. Jest to niezwykle proste i pomocne rozwiązanie, eliminujące przepychanki w firmie pomiędzy działami i związaną z tym odpowiedzialnością, bo wszyscy grają do jednej bramki.

Prowadząc szczegółową ewidencję, co konsumowało nasz czas niedziałania ujęty w budżecie błędów, możemy ocenić, które rzeczy zużywają go najwięcej i eliminować je, zaczynając od tych, które mają największy wpływ. Aż po te drobniejsze – tak, aby utrzymać ustalone wskaźniki.

Przy czym nie należy zbytnio iść w kierunku minimalizowania potencjalnych niedostępności poniżej ustalonych wartości, bo to jest kosztowne. Jeśli uznamy, że możemy coś poprawić, warto ocenić koszt poprawny naszych wskaźników i dopiero wtedy zdecydować o dalszym doskonaleniu systemu. Może się bowiem okazać, że zmarnowaliśmy czas na uzyskanie lepszych wyników niż oczekiwane, a jednocześnie zawaliliśmy rozwój nowych funkcji systemu.

Automatyzacja i rozwój a bieżące czynności utrzymania systemów

Wspominałem, że zadaniem inżyniera SRE jest dążenie do automatyzacji. Idea SRE w celu zmierzenia tego rezultatu nazwała wszystko, co nie jest tą pracą toil czyli trud. Trud to nic innego, jak działania wykonywane powtarzalnie, ręcznie, które mogłyby być zautomatyzowane i takie, które nie przynoszą długoterminowych wartości dla infrastruktury. Gdyby nie automatyzacja (ale nie tylko) - trud rósłby liniowo wraz z rozrostem zarządzanej infrastruktury. Świadomość tego, co kwalifikować jako toil jest niezwykle ważna. To właśnie z likwidacji tej części biorą się systemy zbudowane jako IaC (Infrastructure as code), gdzie nie ma bezpośredniego dotykania czegokolwiek w systemie. Niemal oczywiście.  Poszukiwanie miejsc do automatyzacji wymaga analizowania, jak często dana czynność jest wykonywana - im częściej, tym ma większy wpływ na nasz trud. Praca nad minimalizacją części określanej jako trud sama w sobie zalicza się już do zadań pożytecznych i sama w sobie nie jest trudem, ponieważ z czasem doprowadza do redukcji czasu poświęcanego na prace ręczne. Nie należy tu jednak wrzucać do jednego worka czynności takich jak spotkania, odpowiadanie na maile itp. Mierzenie, co wysiłkiem jest, a co nie to kwestia poprawnego raportowania prac przez inżyniera - musi to odpowiednio oznaczyć w czasie raportowania. Bez tego nie zmierzymy. Nie da się wyeliminować trudu całkowicie choćby dlatego, że będą się pojawiały zadania, których automatyzacja się zwyczajnie nie opłaca – coś, co robimy raz na rok i trwa godzinę, a wymaga 20h prac projektowych najpewniej nie będzie tego warte. Realnie więc trud będzie to oscylować wokół 50% czasu, ale wynikać to będzie z faktu, że dzięki coraz lepszej automatyzacji tak naprawdę robimy coraz więcej rzeczy, albo nasza infrastruktura się rozrasta i tymi samymi zasobami jesteśmy w stanie obsłużyć większą ich ilość. Ważne jest, aby nie popadać w tendencję do szukania redukcji na siłę - trud, mimo tej swojej nieciekawej nazwy, nie jest zły i musi istnieć. Czasem wymagane jest zrozumienie działania systemu, a odbywa się to tylko poprzez ręczne wykonywanie nawet już zautomatyzowanej czynności. Dodatkowo, jesteśmy jednak ludźmi i czasem chcemy zobaczyć wyniki swojej pracy od razu i bezpośrednio, a nie jako wynik działań coraz mniej zrozumiałych automatyzacji. Zbytnie skupienie i pokładanie wiary w automaty może sprawić, że z czasem w zespole nowe osoby nie będą nic wiedziały o działaniu i podstawach działania systemu, którym się opiekują, bo nigdy w nim nic ręcznie nie zrobiły. Czyli jeśli okazuje się, że nasz trud to 80% pracy, to jest to raczej źle. Ale tak samo źle, jeśli to tylko 20%. Trud może nie ma bezpośredniego odniesienia do zadań, które spoczywają na DevOpsach, ale jest to kolejny wskaźnik, który warto mierzyć, aby wiedzieć, jak bardzo udaje się pracować projektowo, by utrzymać równowagę pomiędzy administracją infrastrukturą a jej usprawnianiem i automatyzacją. Tę czynność tak na prawdę od zawsze mierzymy, dzieląc utrzymanie systemu na prace rozwojowe i utrzymanie. Te pojęcia w podziale prac w administracji infrastrukturą istnieją od zawsze. Dlatego SRE to tylko ewolucja i nazwanie znanych, ale niemierzonych czy nienazwanych działań.

Jeśli system, który tworzycie jest platformą dla wielu klientów, dostarcza usługi na bazie których klienci budują swoje rozwiązania, czy posiada API, musicie ich także nauczyć ideologii SRE, a przynajmniej wyjaśnić jakie macie SLIs i SLOs, aby rozumieli czego się spodziewać, jak projektować swoje rozwiązania i liczyć swoje parametry niezawodności i aby nie wpadali w panikę, że coś nie działa lub zawodzi zbyt często (według nich), a jest w zgodzie z obiecanymi przez Was parametrami. Działanie waszego API wliczy się do wskaźników użytkownika API (tak samo, jeśli sami z takowych API korzystacie).

Monitoring i zbieranie danych

U podstaw podejścia SRE leży również racjonalizacja alertów i reakcji na nie. Skoro zbudowaliśmy redundantne elementy, to po co reagować w środku nocy na awarię, która nijak nie wpływa na działanie systemu? Dlatego można śmiało uznać część alertów za niekrytyczne. Co więcej, pojawianie się nieistotnych, bądź fałszywych alertów prowadzi do znieczulicy. SRE wie, że otrzymany alert nie jest istotny, bo dostał go już wiele razy i nie miał nic do zrobienia krytycznego. Ignoruje go więc, co samo w sobie może doprowadzić z czasem do błędu, bo kiedyś alert może jednak okazać się ważny a zostanie "rutynowo" zignorowany. Dlatego dopiero system alertowy oparty o SLI/SLO, sprawdzający możliwość dokonania konkretnych biznesowych akcji w systemie, uzyskania określonej wydajności przez system, ma sens. Reagujmy na to, co wpływa na nasze wskaźniki (to pewne uproszczenie). Oczywiście monitoring powinien wykrywać potencjalne przyczyny problemów, czy zbliżanie się awarii i o nich informować, ale głównie powinien się skupić na wykrywaniu prawdziwych problemów, które wpływają na odbiór serwisu przez użytkowników. Dlatego alertowanie należy powiązać sensownie z budżetem błędów, a ten należy rozpatrywać w różnych okresach czasu (w czasie doby, tygodnia, miesiąca czy kwartału), aby zapobiec nadmiernej jego konsumpcji przez problemy. A te należy szybko eliminować (jeśli te konsumują go dużo), albo można to robić spokojniej, jeśli zużywają budżet powoli. Czyli na koniec sprowadza się to także do alertowania, czy nasz budżet błędów (a co za tym idzie ustalone wskaźniki) nie jest zagrożony przekroczeniem. I to zanim okaże się, że jego dotrzymanie nie jest już możliwe lub wpłynie radykalnie na możliwość wprowadzania zmian w systemie, które zawsze podnoszą ryzyko konsumpcji rezerwy budżetu.

Nadzór systemu dla SRE to także zbieranie danych nazywane Observability, na które składają się logi o odpowiedniej strukturze, metryki oraz inne zebrane wskaźniki. Logi o odpowiedniej strukturze pozwalają je łatwo analizować i łączyć z odpowiednimi usługami. Metryki pokazują nam wybrane wartości np. ilość zapytań na sekundę (w formie wykresów), czas odpowiedzi (np. w formie heatmapy - patrz możliwości Prometheusa). Wykresy zależności (traces) pokazują pewne zachowania systemu z uwzględnieniem zależności czasowych - co następuje po czym i na co czeka. Wszystkie te dane nie są niczym nowym w sumie, dobrze wybrane pozwalają jednak szybciej odnaleźć ew. przyczyny niedotrzymywania przez system wskaźników - np. uszkodzenie jednej instancji, problemy sprzętowe z określonym elementem platformy, czy niespójne wersje aplikacji lub komponenty systemów. Wykresy te pozwalają namierzy ewentualne zależności, a logi - na szczegółowe namierzenie źródła problemu. Nie ma więc znaczenia, że tak naprawdę jesteśmy alertowani dopiero w momencie, gdy mamy problem wysokiego poziomu, wpływający na SLI/SLO/SLA, bo w diagnozie pomogą nam stworzone elementy monitoringu, czyniące system "obserwowalnym". W rozbudowanym systemie przesuwamy więc wagę nadzoru nad niezliczoną ilością danych-  z alertu informującego o wszystkim do alertów problemów, które wpływają na nasz budżet błędów. Nowoczesne rozwiązania chmurowe oferują wiele takich wbudowanych mechanizmów, a takie systemy jak Prometheus czy Grafana dają nieograniczone już możliwości. SRE powinien odesłać grepowanie logów w przeszłość.

Zarządzanie incydentami

Aby uniknąć chaosu w obsłudze systemów, zajmowania się przypadkowymi zadaniami, spędzaniu niezliczonej ilości czasu na dyskusjach, niezbędny jest sprawny system zarządzania incydentami. Dobry system zarządzania incydentami składa się z procedur definiowania incydentów (kto może, jakie systemy dostarczają zdarzenia, kiedy przekroczenie jakiegoś parametru staje się incydentem), procedur ich rozwiązywania i eskalacji do odpowiednich zespołów/osób oraz dashboardu wspierające przegląd prowadzonych incydentów. Nadzór nad systemem sprawuje Incydenta Commander (Incydent Manager), a detaliczne techniczne szczegóły rozwiązuje Operations Lead, który wie jak konkretnie postąpić z danym incydentem. W skład mechanizmu wchodzą oczywiście inne osoby, od osób technicznych, przez osoby odpowiedzialne za kontakt z klientami (w wypadku konieczności poinformowania klientów o incydencie wpływającym na dostępność usług) aż po osoby z biznesu, jeśli tego wymaga powaga problemu. W dużych organizacjach mogą pojawić się większe ilości osób, w tym nawet odpowiedzialne za zaopatrzenie pracującego nad incydentem zespołu w napoje i żywność. Podział ról odpowiada skali incydentu, wielkości firmy i ilości pracy do wykonania. W rozwiązanie pojedynczego incydentu może być zaangażowana jedna osoba albo 30. W zależności od specyfiki organizacji zespół w zasadzie jest nieograniczony a IC/IM ma prawo delegować dowolne zadania i dołączać dowolne osoby, aby sprawnie zakończyć incydent. Osoba ta musi mieć szeroką wiedzę i kompetencje. Nawet sama zewnętrzna komunikacja może wymagać osobnych osób do wsparcia klientów, obsługi newsów i raportów oraz obsługi sieci społecznościowych czy innych kanałów komunikacji. Rolą IMa jest też usuwanie zbędnych osób z procesu, aby ograniczyć zasoby i czas na komunikację. Wszystko, by zmniejszyć chaos w obsłudze incydentów.

Blameless postmortems

Aby incydenty się nie powtarzały proces wymaga analizy przyczyn i rozwiązań. Analiza postmortem jest wpisania w ideologię SRE. Aby analiza była pełna i szczera, musi się skupić na przyczynach i rozwiązaniach - bez szukania winnych. Wymaga ona zebrania danych, poczynając ustalenia którego systemu dotyczył problem, a kończąc na analizie, kto był zaangażowany w rozwiązanie.

Trzeba zebrać maksimum dostępnych danych, jak dowiedzieliśmy się o incydencie (zgłoszenie, automatyczny monitoring, inna droga), ile zajęła reakcja i jak wyglądała, jak i kiedy zakończył się incydent. W zbieraniu danych uczestniczy każdy, kto brał w nim udział i ma wiedzę o nim, cały zespół współpracuje, aby zebrać maksimum potrzebnych danych. Podkreślamy tutaj konieczność działania w kulturze bezkonsekwencyjnej - nikt nie może się bać, że zostanie o coś obwiniony lub wręcz zwolniony - inaczej ryzykujemy zatajenie ważnych danych i powtórzenie się identycznego incydentu w czasie. Uczy się firma, usprawniamy procesy, a nie szukamy winnych. Incydent to problem z systemem, procesem czy procedurą a nie problem z człowiekiem. Ludzi nie da się naprawić, procedurę tak. Incydnet powinniśmy dobrze udokumentować, gdyż mało kiedy udaje się dotrzeć do głównej przyczyny, bo też mało kiedy jest jedna przyczyna incydentu. W przyszłości wyniki analizy mogą wyeliminować problem całkowicie lub pomóc w wyeliminowaniu innych problemów. Wyniki analiz z pewnością doprowadzą do konieczności dokonania zmian - powstaną więc zadania do wykonania, zmiany do wprowadzenia. Rozwiązanie problemów w przyszłości i czynienie systemów lepszymi działa jako pozytywna motywacja, a nie motywacja oparta o strach, że na mnie nakrzyczą jak coś znowu padnie. Trzeba się tego nauczyć. Na końcu całego mechanizmu mamy możliwości śledzenia statystyk incydentów, ilości wniosków i usprawnień oraz wynikających z nich zmian parametrów systemów (lepsze SLA, krótszy czas odpowiedzi, mniej incydentów w jednostce czasu lub spadek tych krytycznych itp.). Mierzymy, usprawniamy i znowu mierzymy.

Jeśli wydaje ci się, że to nic nowego, to w pewnym sensie dobrze Ci się wydaje. SRE to ewolucja, ale systematyzująca podejście i nazywająca pewne znane działania. SRE pozwala jednak głębiej i przejrzyściej ustalić parametry istotnych wskaźników działania systemu, wzięcie przez biznes odpowiedzialności za ich ustalenie (koszty - przychody), a inżynierom ich dotrzymanie.

Szczegółowo o metodologii SRE według Google można przeczytać tutaj: https://landing.google.com/sre/sre-book/toc/

PYTANIA? SKONTAKTUJ SIĘ Z NAMI

Zobacz również:

Wysoka dostępność serwisu. Jak ją ustalić i wyliczyć?

Skąd się bierze wysoka dostępność (HA) w chmurze?

Jak realizować projekty IT w modelu DevOps?