SRE (Site Reliability Engineering) to podejście do udostępniania projektów internetowych. Jest uważany za ramy dla DevOps i mówi, jak odnieść sukces w stosowaniu praktyk DevOps. Ten artykuł jest tłumaczony książki od Google'a. Tłumaczenie to przygotowałem sam i oparłem się na własnym doświadczeniu w zrozumieniu procesów monitoringu. W kanale telegramu и Opublikowałem także tłumaczenie rozdziału 6 tej samej książki na temat celów poziomu usług.
Tłumaczenie przez kota. Miłego czytania!
Niemożliwe jest zarządzanie usługą, jeśli nie rozumie się, jakie wskaźniki faktycznie mają znaczenie oraz jak je mierzyć i oceniać. W tym celu definiujemy i zapewniamy naszym użytkownikom określony poziom usług, niezależnie od tego, czy korzystają oni z jednego z naszych wewnętrznych API, czy z produktu publicznego.
Wykorzystujemy naszą intuicję, doświadczenie i zrozumienie pragnień użytkowników, aby zrozumieć wskaźniki poziomu usług (SLI), cele poziomu usług (SLO) i umowy dotyczące poziomu usług (SLA). Wymiary te opisują główne metryki, które chcemy monitorować i na które będziemy reagować, jeśli nie będziemy w stanie zapewnić oczekiwanej jakości usług. Ostatecznie wybór właściwych wskaźników pomaga w podjęciu właściwych działań, jeśli coś pójdzie nie tak, a także daje zespołowi SRE pewność co do kondycji usługi.
W tym rozdziale opisano podejście, którego używamy do rozwiązywania problemów związanych z modelowaniem metryk, wyborem metryk i analizą metryk. Większość wyjaśnień będzie pozbawiona przykładów, dlatego w celu zilustrowania głównych punktów wykorzystamy usługę Szekspira opisaną w przykładzie jej realizacji (wyszukiwanie dzieł Szekspira).
Terminologia dotycząca poziomu usług
Wielu czytelników prawdopodobnie zna koncepcję SLA, ale terminy SLI i SLO zasługują na dokładne zdefiniowanie, ponieważ ogólnie termin SLA jest przeciążony i ma wiele znaczeń w zależności od kontekstu. Dla przejrzystości chcemy rozdzielić te wartości.
Indykatory
SLI to wskaźnik poziomu usług — dokładnie określona ilościowa miara jednego aspektu poziomu świadczonych usług.
W przypadku większości usług za kluczowy poziom SLI uważa się opóźnienie żądania – czas potrzebny na zwrócenie odpowiedzi na żądanie. Inne popularne SLI obejmują poziom błędów, często wyrażany jako ułamek wszystkich otrzymanych żądań, oraz przepustowość systemu, zwykle mierzoną w żądaniach na sekundę. Pomiary są często agregowane: najpierw zbierane są surowe dane, a następnie konwertowane na tempo zmian, średnią lub percentyl.
W idealnym przypadku SLI bezpośrednio mierzy poziom zainteresowania usługą, ale czasami do pomiaru dostępna jest tylko powiązana metryka, ponieważ pierwotna jest trudna do uzyskania lub zinterpretowania. Na przykład opóźnienie po stronie klienta jest często bardziej odpowiednią miarą, ale czasami opóźnienie można zmierzyć tylko na serwerze.
Innym rodzajem SLI ważnym dla SRE jest dostępność, czyli część czasu, w którym można korzystać z usługi. Często definiowany jako odsetek udanych żądań, czasami nazywany wydajnością. (Czas życia – prawdopodobieństwo, że dane będą przechowywane przez dłuższy okres czasu – jest również ważny w przypadku systemów przechowywania danych.) Chociaż 100% dostępności nie jest możliwe, często można osiągnąć dostępność bliską 100%; wartości dostępności wyraża się jako liczba „dziewiątek” » procent dostępności. Na przykład dostępność 99% i 99,999% może być oznaczona jako „2 dziewiątki” i „5 dziewiątek”. Aktualny cel dostępności Google Compute Engine to „trzy i pół dziewiątki”, czyli 99,95%.
Cele
SLO to cel poziomu usług: wartość docelowa lub zakres wartości poziomu usługi mierzony przez SLI. Normalną wartością SLO jest „SLI ≤ Target” lub „Dolny limit ≤ SLI ≤ Górny limit”. Na przykład możemy zdecydować, że wyniki wyszukiwania Szekspira „szybko” zwrócimy, ustawiając SLO na średnie opóźnienie zapytania wyszukiwania mniejsze niż 100 milisekund.
Wybór odpowiedniego SLO jest złożonym procesem. Po pierwsze, nie zawsze można wybrać konkretną wartość. W przypadku zewnętrznych przychodzących żądań HTTP do Twojej usługi wskaźnik zapytań na sekundę (QPS) jest określany przede wszystkim na podstawie chęci użytkowników do odwiedzenia Twojej usługi i nie można dla tego ustawić poziomu docelowego poziomu usług.
Z drugiej strony możesz powiedzieć, że chcesz, aby średnie opóźnienie każdego żądania było mniejsze niż 100 milisekund. Postawienie takiego celu może zmusić Cię do napisania frontendu z niskim opóźnieniem lub zakupu sprzętu, który zapewnia takie opóźnienie. (100 milisekund to oczywiście dowolna liczba, ale lepiej mieć jeszcze mniejsze opóźnienia. Istnieją dowody sugerujące, że duże prędkości są lepsze niż wolne prędkości i że opóźnienia w przetwarzaniu żądań użytkowników powyżej pewnych wartości w rzeczywistości zmuszają ludzi do trzymania się z daleka z twoich usług.)
Ponownie jest to bardziej niejednoznaczne, niż mogłoby się wydawać na pierwszy rzut oka: nie należy całkowicie wykluczać QPS z obliczeń. Faktem jest, że QPS i opóźnienia są ze sobą silnie powiązane: wyższa QPS często prowadzi do większych opóźnień, a usługi zwykle doświadczają gwałtownego spadku wydajności po osiągnięciu określonego progu obciążenia.
Wybór i publikacja SLO określa oczekiwania użytkowników co do sposobu działania usługi. Strategia ta może ograniczyć bezpodstawne skargi na właściciela usługi, takie jak niska wydajność. Bez wyraźnego SLO użytkownicy często tworzą własne oczekiwania dotyczące pożądanej wydajności, które mogą nie mieć nic wspólnego z opiniami osób projektujących i zarządzających usługą. Sytuacja ta może prowadzić do zawyżonych oczekiwań wobec usługi, gdy użytkownicy błędnie sądzą, że usługa będzie bardziej dostępna niż jest w rzeczywistości, oraz do braku zaufania, gdy użytkownicy będą uważać, że system jest mniej niezawodny niż jest w rzeczywistości.
Umowy
Umowa o poziomie usług to wyraźna lub dorozumiana umowa z użytkownikami, która obejmuje konsekwencje spełnienia (lub niespełnienia) zawartych w nich SLO. Konsekwencje najłatwiej rozpoznać, gdy mają one charakter finansowy – zniżka lub kara – ale mogą przybrać także inne formy. Łatwym sposobem omówienia różnicy między SLO i SLA jest zadanie sobie pytania „co się stanie, jeśli SLO nie zostaną spełnione?” Jeśli nie ma wyraźnych konsekwencji, prawie na pewno rozważasz SLO.
SRE zazwyczaj nie jest zaangażowany w tworzenie umów SLA, ponieważ umowy SLA są ściśle powiązane z decyzjami biznesowymi i produktowymi. SRE jest jednak zaangażowana w pomoc w łagodzeniu konsekwencji nieudanych SLO. Mogą również pomóc w określeniu SLI: oczywiście musi istnieć obiektywny sposób pomiaru SLO w umowie, w przeciwnym razie nie będzie zgody.
Wyszukiwarka Google to przykład ważnej usługi, która nie ma publicznej umowy SLA: chcemy, aby każdy korzystał z wyszukiwarki tak efektywnie, jak to możliwe, ale nie podpisaliśmy jeszcze umowy ze światem. Niedostępność wyszukiwania nadal jednak pociąga za sobą konsekwencje – niedostępność powoduje spadek naszej reputacji, a także zmniejszenie przychodów z reklam. Wiele innych usług Google, takich jak Google for Work, ma z użytkownikami wyraźne umowy dotyczące poziomu usług. Niezależnie od tego, czy dana usługa ma SLA, ważne jest zdefiniowanie SLI i SLO i wykorzystanie ich do zarządzania usługą.
Tyle teorii – teraz doświadczenie.
Wskaźniki w praktyce
Biorąc pod uwagę, że doszliśmy do wniosku, że ważny jest wybór odpowiednich wskaźników do pomiaru poziomu usług, skąd wiesz, które wskaźniki mają znaczenie dla usługi lub systemu?
Na czym zależy Tobie i Twoim użytkownikom?
Nie musisz używać każdej metryki jako SLI, którą możesz śledzić w systemie monitorowania; Zrozumienie, czego użytkownicy oczekują od systemu, pomoże Ci wybrać kilka wskaźników. Wybranie zbyt wielu wskaźników utrudnia skupienie się na ważnych wskaźnikach, natomiast wybranie małej liczby może spowodować pozostawienie dużych fragmentów systemu bez nadzoru. Zwykle używamy kilku kluczowych wskaźników do oceny i zrozumienia kondycji systemu.
Usługi można ogólnie podzielić na kilka części pod względem SLI, które są dla nich istotne:
- Niestandardowe systemy front-end, takie jak interfejsy wyszukiwania dla serwisu Shakespeare z naszego przykładu. Muszą być dostępne, nie mieć opóźnień i mieć wystarczającą przepustowość. W związku z tym mogą pojawić się pytania: czy możemy odpowiedzieć na żądanie? Ile czasu zajęło udzielenie odpowiedzi na żądanie? Ile żądań można przetworzyć?
- Systemy przechowywania. Cenią sobie niskie opóźnienia w odpowiedzi, dostępność i trwałość. Powiązane pytania: Ile czasu zajmuje odczyt lub zapis danych? Czy możemy uzyskać dostęp do danych na żądanie? Czy dane są dostępne wtedy, gdy ich potrzebujemy? Szczegółowe omówienie tych kwestii można znaleźć w rozdziale 26. Integralność danych: to, co czytasz, jest tym, co piszesz.
- Systemy Big Data, takie jak potoki przetwarzania danych, opierają się na przepustowości i opóźnieniach przetwarzania zapytań. Powiązane pytania: Ile danych jest przetwarzanych? Jak długo trwa podróż danych od otrzymania żądania do udzielenia odpowiedzi? (Niektóre części systemu mogą również wykazywać opóźnienia na niektórych etapach.)
Zbiór wskaźników
Wiele wskaźników poziomu usług jest gromadzonych w naturalny sposób po stronie serwera przy użyciu systemu monitorowania, takiego jak Borgmon (patrz poniżej). ) lub Prometheus, lub po prostu okresowo analizując logi, identyfikując odpowiedzi HTTP ze statusem 500. Niektóre systemy powinny być jednak wyposażone w zbieranie metryk po stronie klienta, gdyż brak monitorowania po stronie klienta może prowadzić do przeoczenia szeregu problemów wpływających użytkowników, ale nie mają wpływu na metryki po stronie serwera. Na przykład skupienie się na opóźnieniu odpowiedzi zaplecza naszej aplikacji testowej wyszukiwania Shakespeare może skutkować opóźnieniami po stronie użytkownika z powodu problemów z JavaScriptem: w tym przypadku lepszym miernikiem jest pomiar czasu potrzebnego przeglądarce na przetworzenie strony.
Zbiór
Dla prostoty i łatwości użytkowania często agregujemy surowe pomiary. Należy to zrobić ostrożnie.
Niektóre wskaźniki wydają się proste, jak liczba żądań na sekundę, ale nawet ten pozornie prosty pomiar domyślnie agreguje dane w czasie. Czy pomiar jest odbierany konkretnie raz na sekundę, czy też jest uśredniany w stosunku do liczby żądań na minutę? Ta ostatnia opcja może ukryć znacznie większą chwilową liczbę żądań, które trwają tylko kilka sekund. Rozważmy system, który obsługuje 200 żądań na sekundę z liczbami parzystymi i 0 przez resztę czasu. Stała w postaci średniej wartości 100 żądań na sekundę i dwukrotność chwilowego obciążenia to nie to samo. Podobnie uśrednianie opóźnień zapytań może wydawać się atrakcyjne, ale kryje w sobie ważny szczegół: możliwe, że większość zapytań będzie szybkich, ale będzie wiele zapytań powolnych.
Większość wskaźników lepiej postrzegać jako rozkłady niż średnie. Na przykład w przypadku opóźnienia SLI niektóre żądania będą przetwarzane szybko, inne natomiast będą zawsze trwać dłużej, czasem znacznie dłużej. Prosta średnia może ukryć te duże opóźnienia. Rysunek pokazuje przykład: chociaż obsługa typowego żądania zajmuje około 50 ms, 5% żądań jest 20 razy wolniejsze! Monitoring i alarmowanie oparte wyłącznie na średnich opóźnieniach nie pokazuje zmian w zachowaniu w ciągu dnia, podczas gdy w rzeczywistości zauważalne są zmiany w czasie przetwarzania niektórych żądań (najwyższa linia).
Opóźnienie systemu wynoszące 50, 85, 95 i 99 percentyli. Oś Y ma format logarytmiczny.
Stosowanie percentyli do wskaźników pozwala zobaczyć kształt rozkładu i jego charakterystykę: wysoki poziom percentyla, np. 99 lub 99,9, oznacza najgorszą wartość, natomiast percentyl 50 (zwany także medianą) pokazuje najczęstszy stan metryka. Im większe rozproszenie czasu odpowiedzi, tym bardziej długotrwałe żądania wpływają na wygodę użytkownika. Efekt jest wzmocniony przy dużym obciążeniu i w obecności kolejek. Badania doświadczeń użytkowników wykazały, że ludzie na ogół wolą wolniejszy system z dużą zmiennością czasu reakcji, więc niektóre zespoły SRE skupiają się wyłącznie na wysokich wynikach percentylowych, wychodząc z założenia, że jeśli zachowanie metryki na poziomie 99,9 percentyla jest dobre, większość użytkowników nie doświadczy problemów .
Uwaga dotycząca błędów statystycznych
Generalnie wolimy pracować z percentylami niż średnią (średnią arytmetyczną) zbioru wartości. Dzięki temu możemy uwzględnić wartości bardziej rozproszone, które często mają znacząco odmienne (i ciekawsze) cechy od średniej. Ze względu na sztuczny charakter systemów obliczeniowych wartości metryki są często wypaczone, przykładowo żadne żądanie nie może otrzymać odpowiedzi w czasie krótszym niż 0 ms, a limit czasu wynoszący 1000 ms oznacza, że nie mogą być pomyślne odpowiedzi z wartościami większymi niż limit czasu. W rezultacie nie możemy zaakceptować faktu, że średnia i mediana mogą być takie same lub blisko siebie!
Bez wcześniejszych testów i jeśli nie obowiązują pewne standardowe założenia i przybliżenia, staramy się nie wyciągać wniosków, że nasze dane mają rozkład normalny. Jeśli dystrybucja nie jest zgodna z oczekiwaniami, proces automatyzacji, który rozwiązuje problem (na przykład, gdy wykryje wartości odstające, ponownie uruchamia serwer z dużymi opóźnieniami w przetwarzaniu żądań), może robić to zbyt często lub niezbyt często (oba czynniki nie są bardzo dobry).
Standaryzacja wskaźników
Zalecamy ujednolicenie ogólnych cech SLI, aby nie trzeba było za każdym razem spekulować na ich temat. Każda funkcja spełniająca standardowe wzorce może zostać wyłączona ze specyfikacji indywidualnego SLI, na przykład:
- Interwały agregacji: „uśrednione w ciągu 1 minuty”
- Obszary agregacji: „Wszystkie zadania w klastrze”
- Częstotliwość wykonywania pomiarów: „Co 10 sekund”
- Jakie żądania są uwzględniane: „HTTP GET z zadań monitorowania czarnej skrzynki”
- Sposób pozyskiwania danych: „Dzięki naszemu monitoringowi mierzonemu na serwerze”
- Opóźnienie dostępu do danych: „Czas do ostatniego bajtu”
Aby zaoszczędzić wysiłek, utwórz zestaw szablonów SLI wielokrotnego użytku dla każdej popularnej metryki; ułatwiają także każdemu zrozumienie, co oznacza dany SLI.
Cele w praktyce
Zacznij od zastanowienia się (lub dowiedzenia się!), na czym zależy Twoim użytkownikom, a nie od tego, co możesz zmierzyć. Często to, na czym zależy Twoim użytkownikom, jest trudne lub niemożliwe do zmierzenia, więc w efekcie zbliżasz się do ich potrzeb. Jeśli jednak zaczniesz od tego, co jest łatwe do zmierzenia, otrzymasz mniej przydatne poziomy docelowego poziomu usług (SLO). W rezultacie czasami stwierdzaliśmy, że początkowe określenie pożądanych celów, a następnie praca z konkretnymi wskaźnikami działa lepiej niż wybieranie wskaźników, a następnie osiąganie celów.
Zdefiniuj cele
Dla maksymalnej przejrzystości należy określić sposób pomiaru SLO oraz warunki, na jakich są one ważne. Na przykład moglibyśmy powiedzieć co następuje (druga linia jest taka sama jak pierwsza, ale używa domyślnych ustawień SLI):
- 99% (średnio z ponad 1 minuty) wywołań Get RPC zostanie ukończonych w czasie krótszym niż 100 ms (mierzonym na wszystkich serwerach zaplecza).
- 99% wywołań Get RPC zakończy się w czasie krótszym niż 100 ms.
Jeśli kształt krzywych wydajności jest ważny, możesz określić wiele SLO:
- 90% wywołań Get RPC zostało ukończonych w czasie krótszym niż 1 ms.
- 99% wywołań Get RPC zostało ukończonych w czasie krótszym niż 10 ms.
- 99.9% wywołań Get RPC zostało ukończonych w czasie krótszym niż 100 ms.
Jeśli Twoi użytkownicy generują heterogeniczne obciążenia: przetwarzanie masowe (dla którego ważna jest przepustowość) i przetwarzanie interaktywne (dla którego ważne jest opóźnienie), warto zdefiniować osobne cele dla każdej klasy obciążenia:
- 95% żądań klientów wymaga przepustowości. Ustaw liczbę wykonanych wywołań RPC <1 s.
- 99% klientów dba o opóźnienia. Ustaw liczbę wywołań RPC z ruchem <1 KB i działającym <10 ms.
Nierealistyczne i niepożądane jest naleganie, aby SLO były realizowane w 100% przypadków: może to zmniejszyć tempo wprowadzania nowych funkcjonalności i wdrażania oraz wymagać kosztownych rozwiązań. Zamiast tego lepiej jest ustalić budżet błędów – procent dozwolonego przestoju systemu – i monitorować tę wartość codziennie lub co tydzień. Kierownictwo wyższego szczebla może chcieć ocen miesięcznych lub kwartalnych. (Budżet błędów to po prostu SLO do porównania z innym SLO.)
Procent naruszeń SLO można porównać do budżetu błędów (patrz rozdział 3 i sekcja ), a wartość różnicy jest używana jako dane wejściowe w procesie decydującym o tym, kiedy wdrożyć nowe wydania.
Wybór wartości docelowych
Wybór wartości planowania (SLO) nie jest czynnością czysto techniczną ze względu na interesy produktowe i biznesowe, które muszą być odzwierciedlone w wybranych SLI, SLO (i ewentualnie SLA). Podobnie może zaistnieć potrzeba wymiany informacji dotyczących kwestii związanych z personelem, czasem wprowadzenia produktu na rynek, dostępnością sprzętu i finansowaniem. SRE powinna być częścią tej rozmowy i pomóc zrozumieć ryzyko i wykonalność różnych opcji. Przygotowaliśmy kilka pytań, które mogą pomóc w zapewnieniu bardziej produktywnej dyskusji:
Nie wybieraj celu na podstawie bieżących wyników.
Chociaż zrozumienie mocnych stron i ograniczeń systemu jest ważne, dostosowywanie wskaźników bez uzasadnienia może uniemożliwić utrzymanie systemu: będzie to wymagało heroicznych wysiłków, aby osiągnąć cele, których nie można osiągnąć bez znaczącego przeprojektowania.
Bądź prosty
Złożone obliczenia SLI mogą ukryć zmiany w wydajności systemu i utrudnić znalezienie przyczyny problemu.
Unikaj absolutów
Chociaż posiadanie systemu, który byłby w stanie obsłużyć rosnące w nieskończoność obciążenie bez zwiększania opóźnień, jest kuszące, wymaganie to jest nierealne. System zbliżający się do takich ideałów będzie prawdopodobnie wymagał dużo czasu na zaprojektowanie i zbudowanie, będzie kosztowny w obsłudze i będzie zbyt dobry, aby sprostać oczekiwaniom użytkowników, którzy zgodziliby się na coś mniejszego.
Używaj jak najmniejszej liczby SLO
Wybierz wystarczającą liczbę SLO, aby zapewnić dobre pokrycie atrybutów systemu. Chroń wybrane SLO: jeśli nigdy nie uda się wygrać sporu dotyczącego priorytetów, określając konkretny SLO, prawdopodobnie nie warto rozważać tego SLO. Jednak nie wszystkie atrybuty systemu są dostępne dla SLO: trudno jest obliczyć poziom zadowolenia użytkownika przy użyciu SLO.
Nie goń za perfekcją
Zawsze możesz z czasem udoskonalić definicje i cele SLO, dowiadując się więcej o zachowaniu systemu pod obciążeniem. Lepiej zacząć od płynnego celu, który z czasem udoskonalisz, niż wybrać zbyt rygorystyczny cel, który trzeba złagodzić, gdy okaże się, że jest nieosiągalny.
SLO mogą i powinny być kluczowym czynnikiem w ustalaniu priorytetów pracy SRE i twórców produktów, ponieważ odzwierciedlają troskę o użytkowników. Dobry SLO jest użytecznym narzędziem egzekwowania prawa dla zespołu programistów. Jednak źle zaprojektowany SLO może prowadzić do marnotrawstwa pracy, jeśli zespół podejmie heroiczne wysiłki, aby osiągnąć zbyt agresywny SLO, lub do złego produktu, jeśli SLO jest zbyt niski. SLO to potężna dźwignia, używaj jej mądrze.
Kontroluj swoje pomiary
SLI i SLO to kluczowe elementy wykorzystywane do zarządzania systemami:
- Monitoruj i mierz systemy SLI.
- Porównaj SLI z SLO i zdecyduj, czy potrzebne jest działanie.
- Jeśli wymagane jest działanie, zastanów się, co musi się wydarzyć, aby osiągnąć cel.
- Zakończ tę akcję.
Na przykład, jeśli krok 2 wykaże, że upłynął limit czasu żądania i jeśli nic nie zostanie zrobione, spowoduje to przerwanie SLO w ciągu kilku godzin, krok 3 może obejmować sprawdzenie hipotezy, że serwery są obciążone procesorem, a dodanie większej liczby serwerów rozłoży obciążenie. Bez SLO nie wiedziałbyś, czy (i kiedy) podjąć działania.
Ustaw SLO - wtedy zostaną ustawione oczekiwania użytkowników
Publikowanie docelowego poziomu usług określa oczekiwania użytkowników dotyczące zachowania systemu. Użytkownicy (i potencjalni użytkownicy) często chcą wiedzieć, czego się spodziewać po usłudze, aby zrozumieć, czy nadaje się ona do użytku. Na przykład osoby chcące korzystać z witryny do udostępniania zdjęć mogą chcieć uniknąć korzystania z usługi, która obiecuje długowieczność i niski koszt w zamian za nieco mniejszą dostępność, mimo że ta sama usługa może być idealna dla systemu zarządzania dokumentacją archiwalną.
Aby ustalić realistyczne oczekiwania wobec użytkowników, zastosuj jedną lub obie z poniższych taktyk:
- Zachowaj margines bezpieczeństwa. Użyj bardziej rygorystycznego wewnętrznego poziomu docelowego poziomu usług niż ten reklamowany użytkownikom. Dzięki temu będziesz mieć możliwość zareagowania na problemy, zanim staną się widoczne na zewnątrz. Bufor SLO pozwala również zachować margines bezpieczeństwa podczas instalowania wydań wpływających na wydajność systemu i zapewnia łatwość konserwacji systemu bez konieczności frustrowania użytkowników przestojami.
- Nie przekraczaj oczekiwań użytkowników. Użytkownicy kierują się tym, co oferujesz, a nie tym, co mówisz. Jeśli rzeczywista wydajność Twojej usługi jest znacznie lepsza niż podany SLO, użytkownicy będą polegać na bieżącej wydajności. Można uniknąć nadmiernej zależności, celowo zamykając system lub ograniczając wydajność przy niewielkim obciążeniu.
Zrozumienie, w jakim stopniu system spełnia oczekiwania, pomaga podjąć decyzję o inwestycji w przyspieszenie systemu i uczynienie go bardziej dostępnym i odpornym. Alternatywnie, jeśli usługa działa zbyt dobrze, część czasu personelu należy przeznaczyć na inne priorytety, takie jak spłata długu technicznego, dodanie nowych funkcji lub wprowadzenie nowych produktów.
Umowy w praktyce
Utworzenie umowy SLA wymaga od zespołów biznesowych i prawnych określenia konsekwencji i kar za jej naruszenie. Rolą SRE jest pomoc w zrozumieniu prawdopodobnych wyzwań w zakresie spełnienia SLO zawartych w umowie SLA. Większość zaleceń dotyczących tworzenia SLO ma zastosowanie również do umów SLA. Rozsądnie jest zachować ostrożność w tym, co obiecujesz użytkownikom, ponieważ im więcej masz, tym trudniej jest zmienić lub usunąć umowy SLA, które wydają się nierozsądne lub trudne do dotrzymania.
Dziękuję za przeczytanie tłumaczenia do końca. Subskrybuj mój kanał telegramu o monitorowaniu и .
Źródło: www.habr.com