Observability & SRE (Part 2)

SLI, SLO, SLA

Podążając ścieżką SRE dochodzimy do pojęć SLI, SLO oraz SLA, które pozwalają  uporządkować rozumienie niezawodności i ją mierzyć. SLI to miary (metryki), na podstawie których możemy obserwować kondycję naszego systemu zarówno technicznie jak i biznesowo. Możemy posługiwać się nimi w szerszej perspektywie, aby ocenić na dużym poziomie ogólności jak zachowuje się nasz system, ale możemy również zejść głębiej — obserwując parametry techniczne, niskopoziomowe. Przykładowymi metrykami mogą być:

• liczba błędów komunikacji HTTP, np. kodów 4xx lub 5xxx w całej komunikacji HTTP,
• API response latency – opóźnienie w czasie odpowiedzi API (liczba żądań do serwisu backendowego wykonanych w czasie niższym niż określony czas połączenia),
• liczba błędów transakcji kartą kredytową,
• czas załadowania wyników wyszukiwania,
• znane z tematyki Web Performance wskaźniki Web Vitals np. FID czyli First Input Delay
• liczba błędnych rezerwacji,
• liczba wyników wyszukiwania – taki wskaźnik może wykryć problemy z dostępnością naszego contentu lub silnika wyszukiwania,

Ważne jest to, aby każdy wskaźnik SLI był dobrze rozumiany i czemuś służył. Powinniśmy pamiętać o tym, że należy najpierw zastanowić się co tak naprawdę oznacza dla nas niezawodność i jak ją chcemy mierzyć, a następnie powinniśmy zdefiniować miary SLI, które nam to ułatwią, a nie odwrotnie.

SLO dają nam wewnętrzne porozumienie co do poziomu niezawodności, jaki chcemy utrzymać. Ustalamy, który wskaźnik SLI  jest dla nas bardzo istotny z biznesowego punktu widzenia. Następnie ustalamy jego oczekiwany poziom SLO. Dzięki temu osiągamy kontrakt na zapewnienie niezawodności danej usługi z biznesowego punktu widzenia. Dla przykładu, dla powyższych wskaźników SLI można zdefiniować następujące poziomy SLO:

Zapewne większość z Was zna powszechnie stosowane umowy SLA i pewnie wiecie, że są one tym, co gwarantujemy dochować, jako organizacja wobec naszych partnerów i klientów wewnętrznych lub zewnętrznych. W umowie SLA najczęściej gwarantujemy wartości wybranych parametrów SLI, czyli SLO.

Istnieje bardzo istotna zależność pomiędzy SLO i SLA. Jeżeli ustalimy nasze SLA na poziomie 97% to przekroczenie tego poziomu niesie za sobą konsekwencje dla organizacji, jak choćby kary finansowe czy utrata wiarygodności wobec naszych klientów. Naszym obowiązkiem jest za wszelką cenę starać się takie SLA spełnić, dlatego nasz wewnętrzny poziom SLO powinien być dużo bardziej rygorystyczny niż SLA, aby dać możliwość zareagowania z wyprzedzeniem na niepokojący sygnał przekroczenia SLO i nie dopuścić do naruszenia SLA! To bardzo ważna reguła. Pozwoli uniknąć wielu przykrych sytuacji. Teraz widać dokładnie, że w przypadku konieczności zwiększenia poziomu SLA, musimy bezwzględnie zrewidować nasze SLO aby zachować odpowiedni bufor bezpieczeństwa. SLO natomiast jest oczywiście oparte na SLI,  dlatego powinniśmy zrewidować jego historyczne poziomy i ocenić możliwość osiągnięcia wyższego poziomu SLO.

W przeciwieństwie do podnoszenia wartości wskaźników SLO, w konsekwencji dążąc do osiągnięcia zadanego poziomu wskaźników SLI , dobrą praktyką, jaką stosuje się w eSky.pl jest zachowanie poziomu SLO na zadanym poziomie i dążenie do osiągnięcia lepszych wyników SLI, o ile jest to uzasadnione biznesowo. Kiedy wskaźniki SLI ustabilizują się na wyższym poziomie niż według danych historycznych,  wówczas rozważana jest decyzja o podniesieniu SLO. Należy jednak zwrócić uwagę na to, że według SRE nie powinno się zmieniać wartości SLO tylko dlatego, że utrzymuje się na wyższym poziomie. Taka decyzja musi mieć swoje uzasadnienie biznesowe. Sytuacja, kiedy przekraczamy wartości SLI też nie jest sytuacją pożądaną. Przekroczenie wartości SLI możemy w takiej sytuacji spożytkować, np. na testowanie rozwiązania za pomocą chaos testów.

SRE zakłada istnienie budżetu błędów. Budżet błędów to zapas dostępności w ramach SLO, czyli taki poziom niespełnienia wskaźnika, który możemy bezpiecznie zużyć aby nie spaść poniżej zadanego SLO. Jeżeli nasze SLO dotyczy czasu odpowiedzi danej usługi i jest zdefiniowany jako: “97% żądań powinno być obsłużonych poniżej 1 sekundy” to oznacza, że 3% żądań może zostać obsłużonych powyżej tego czasu. Budżet błędów możemy wówczas (a według SRE nawet powinniśmy) wykorzystać na eksperymenty i testy aby móc doskonalić system lub weryfikować jego niezawodność, testować nowe rozwiązania itd.

Monitoring i Observability

Aby w ogóle mówić o możliwości zastosowania praktyk SRE, musimy najpierw mieć wgląd w nasze systemy. Monitorowanie jest sposobem na obserwowanie tego, co dzieje się w naszych rozwiązaniach. Mówimy tutaj o gromadzeniu, przetwarzaniu, agregowaniu i wyświetlaniu mierzalnych danych na temat funkcjonowania naszych systemów w czasie pozwalającym na bieżącą ocenę kondycji systemu. W zasadzie ten czas powinien być zbliżony do czasu rzeczywistego. W praktyce jednak zależy to również od potrzeb i podjętych decyzji, ponieważ pozyskiwanie takich informacji również wiąże się z kosztem.

Monitorowanie stanowi podstawę do:

• wyświetlania informacji o stanie systemu,
• alertowania na podstawie ustalonych warunków,
• diagnozowania i śledzenia problemów w systemie,
• obserwowania kondycji i zachowania systemów w dłuższej perspektywie (obserwowanie trendów),
• porównywania stanu systemu przed i po dokonanej zmianie.

Observability jest rozszerzeniem koncepcji monitorowania. Jest nie tylko mierzeniem parametrów systemów, jest sposobem holistycznego podejścia do badania tego, w jakiej kondycji jest system. Jest również budowaniem umiejętności efektywnego wykrywania aktualnych i potencjalnych problemów, a także ciągłego uczenia i usprawniania. Observability opiera się na korelacji i wnioskowaniu zachowań całego systemu i wielu wskaźników jednocześnie. Zbudowanie dobrego Observability jest zadaniem złożonym i trudnym, a w dużych systemach trudno jest obejść się bez zestawu specjalnych narzędzi przeznaczonych do tego celu. Niektóre z nich mają wbudowane mechanizmy oparte o sztuczną inteligencję (min. Machine Learning) i pozwalają z coraz większą prędkością i precyzją automatycznie wykrywać takie korelacje i tym samym zwiększają efektywność tychże procesów. Wdrożenie takich narzędzi ma swoją cenę, ale im większy system, tym inwestycja w tego typu narzędzia bardziej się opłaci. Wdrożenie narzędzi observability jest również możliwe za pomocą darmowych usług, ale jest to zdecydowanie bardzo długa i trudna droga. W eSky.pl zdecydowaliśmy się pójść właśnie tą ścieżką ze świadomością złożoności tego procesu oraz czasu potrzebnego na implementację. Nasza decyzja była w pełni świadoma, poparta wcześniejszą analizą oraz przede wszystkim zbudowaniem odpowiednich kompetencji do wdrożenia i utrzymania takiego rozwiązania. Jestem przekonany, że jest to dobry temat na osobny artykuł, więc jeżeli będziecie nim zainteresowani to napiszcie o tym w komentarzach pod artykułem.

W zasadzie koncepcje Observability leżą u podstaw zapewnienia niezawodności, natomiast SRE nadaje szerszy kontekst tym zagadnieniom. Obudowując ją w koncepcje wskaźników SLI/SLO, dążenie do automatyzacji powtarzających się czynności podczas wdrożeń, współodpowiedzialności, sprzężenia zwrotnego dotyczącego incydentów w celu ciągłego doskonalenia oraz podejścia blameless, gwarantującego pełną otwartość, umożliwiamy efektywne dochodzenie do rzeczywistych przyczyn problemów bez obaw i zasłaniania się niewiedzą lub przerzucaniem odpowiedzialności za awarie.

Blameless postmortem

Kolejnym filarem jest wyciąganie nauki z incydentów oraz kultura blameless. Takie działania przejawiają się w spotkaniach następujących po incydencie, zwanych Postmortem. Służą one dokładnej analizie incydentu i zidentyfikowaniem jego przyczyn, wyciągnięciem wniosków oraz uzgodnieniem działań mających na celu przeciwdziałanie im w przyszłości. Podczas awarii i w trakcie analizy koncentrujemy się na działaniach i rozwiązaniach, a nie na szukaniu winnych. Wypracowanie takiej kultury przyczynia się do otwartości, szczerości oraz zaangażowania. Doskonalimy rozwiązanie systemowe, a nie koncentrujemy się na poszukiwaniu winowajcy.

Automatyzacja DevOps

Niezawodność według SRE osiągana jest również dzięki automatyzowaniu powtarzających się czynności podczas procesów wdrażania, konfiguracji, skalowania, uruchamiania systemów i wszelkich innych czynności. Automatyzacja według SRE jest remedium na błędy ludzkie, ponieważ łatwiej jest doskonalić procesy automatyczne i eliminować w nich błędy, niż stale dokonywać manualnych operacji. Wraz ze wzrostem skali systemu operacje, ręczne wręcz przestają być możliwe do zrealizowania w sensownym czasie i bez rosnącego ryzyka pomyłek ludzkich. Automatyzacja wymusza również ustandaryzowanie systemu, stosowanie podobnych rozwiązań, wypracowania pewnego schematu wdrożeń, użycia podobnych technologii i komponentów. W heterogenicznym systemie, gdzie ilość technologii jest bardzo duża, automatyzacja jest znacznie trudniejsza. Automatyzacja to nie tylko automatyczne wdrożenia ale również automatyczne skalowanie systemu, automatyczne wykrywanie awarii, jak również automatyczne naprawianie systemu. Wszystkie te procesy da się automatyzować i warto to robić, o ile to się opłaca.

Automatyzacja daje wzrost niezawodności pod warunkiem, że zwrot z tej automatyzacji pokrywa jej koszty. Wszystko to znowu sprowadza się do podejmowania świadomych decyzji w porozumieniu z biznesem. Warto po raz kolejny podkreślić jak przełomowe jest podejście SRE, dając platformę porozumienia i współodpowiedzialności dla interesariuszy biznesowych oraz dla zespołów technologicznych. Jeżeli chciałbyś dowiedzieć się więcej na temat wdrożenia SRE w Organizacji zapraszam Cię do przeczytania trzeciej części artykułu.