Kluczowe reguły i praktyki w inżynierii SRE: pozytywne cykle rozwoju
- 10 min
Jeśli to naprawdę prawda, że w pewnym sensie "jesteś tym, co robisz", to doszliśmy do serca tego modułu. W tej lekcji przyjrzymy się dwóm praktykom, które są często uważane za podstawowe w praktyce SRE. Oba pochodzą z zasady, że ważne jest, aby stworzyć "cnotliwe cykle". Pozytywne cykle w tym kontekście to praktyki, które tworzą pętle opinii w organizacji, które pomagają organizacji w ciągłym ulepszaniu. Mamy wszystkie kolejne moduły dotyczące dokładnie tych dwóch rozwiązań, więc będziemy tylko skąpować powierzchnię z omówieniem każdego z tych rozwiązań.
Pozytywny cykl rozwoju nr 1: SLI oraz SLO
We wcześniejszej części tego modułu podkreśliliśmy nasz punkt dotyczący pracy nad "odpowiednim poziomem niezawodności". Ta sekcja jest właśnie miejscem, w którym ta koncepcja zostanie doprowadzona do zniesienia.
Załóżmy, że masz nową usługę, którą planujesz przenieść do środowiska produkcyjnego (taką, która została skonstruowana lub taka, która jest nadal w procesie planowania). W ramach tego procesu ważne jest podjęcie pewnych decyzji dotyczących żądanej niezawodności. Jeśli nie piszesz całego kodu samodzielnie, te decyzje są podejmowane (i ma to kluczowe znaczenie) we współpracy z deweloperami podejmującymi tę czynność.
Pierwszą decyzją jest to, co powinniśmy użyć jako wskaźników kondycji usługi (wskaźnik poziomu usług lub wskaźnik SLI)? Innym sposobem zadawania tego pytania jest "Jak wiesz, kiedy działa i działa dobrze?". Istnieje wiele sposobów śledzenia SLI i omówimy niektóre szczegółowo później. Jednak te wskaźniki są zwykle następujące:
- Miary sukcesu a porażki: Czy usługa pomyślnie ukończy operację w pewnym procencie przypadków?
- Miary czasu: Czy zwróciliśmy odpowiedź w określonym przedziale czasu?
- Miary przepływności: Czy przetworzyliśmy pewną ilość danych?
Lub niektóre kombinacje wszystkich tych miar.
Aby użyć prostego przykładu, możemy powiedzieć, że wskaźnikiem SLI dla naszej usługi jest częstotliwość pomyślnego zakończenia operacji, wskazywanego przez zwrócenie kodu HTTP 200 (w odróżnieniu od kodu 500 lub innego).
Teraz, gdy mamy jasny wskaźnik informujący nas o tym, jak działa usługa, chcemy zdecydować, jakiego poziomu niezawodności oczekujemy lub czego chcemy. Czy na przykład spodziewamy się, że w ciągu dnia wskaźnik awarii wynosi 20% od usługi? Używamy tutaj dużych i zaokrąglonych liczb, ponieważ z początku są łatwiejsze do uzasadnienia. W kolejnych modułach zwiększamy złożoność i precyzję instrukcji w ten sposób ("którzy użytkownicy widzą ten współczynnik błędów? niektóre z nich? większość z nich?" i tak dalej). To oczekiwanie, opracowane we współpracy z deweloperem usługi, jest celem poziomu usługi (Service Level Objective, SLO).
Cel SLO musi być czymś, co daje się dokładnie zmierzyć i przedstawić w systemie monitorowania. Ma to być cel, dobrze zrozumiały cel niezawodności usługi. Jaka jest liczba, która jest wystarczająco dobra? Nie ma tutaj miejsca na odpowiedzi w stylu „Cóż, wydaje mi się, że usługa działała całkiem dobrze w ciągu ostatniego tygodnia albo nieco dłużej, ale raczej ciężko to stwierdzić”. Usługa spełnia swój cel slo lub nie jest. Dane powinny być jasne. Jeśli nie spełnia celu SLO (zwłaszcza wielokrotnie w danym przedziale czasu), coś jest nie tak i trzeba się tym zająć.
Budżety błędów
Możemy zrozumieć, że organizacja może zawęźć działanie, jeśli usługa nie spełnia celu slo. Jednak SRE przyjmuje tę całość koncepcji kolejny krok naprzód w przypadkach, w których cel slo jest spełniony lub przekroczony. Niektóre organizacje używają celów SLO, aby konstruować tzw. „budżety błędów”.
Aby zademonstrować tę koncepcję, użyjemy przykładowej, omawianej usługi z celem SLO na poziomie 80% powodzeń (pomyślmy o nim następująco: „usługa powinna działać przez 80% czasu”). Dzięki celowi SLO na 80% czasu pracy zadeklarowaliśmy, że nasza usługa musi wynosić 80% czasu. Ale co z pozostałymi 20%? Jeśli usługa nie działa przez pozostałe 20% czasu, jest to dla nas „nieważne”, ponieważ podjęto decyzję, że dodatkowe 20% czasu pracy jest nieistotne w kontekście celu usługi.
Jeśli nie zależy nam na tym, co się stanie w tym czasie, co możemy zrobić z usługą? Przykładowo możemy z pewnością popracować nad uruchomioną usługą poprzez jej uaktualnienie, być może przy użyciu nowego wydania, które będzie dodawać pewne funkcje. Jeśli to nowe wydanie będzie działać i nie spowoduje dodania przestojów, to świetnie. Jeśli to nowe wydanie powoduje, że usługa będzie mniej stabilna i zwraca błędy kolejne 10% czasu podczas debugowania, nadal jest w porządku. Mieścimy się w budżecie dozwolonej zawodności.
Budżet błędów to różnica pomiędzy potencjalną idealną niezawodnością usługi oraz żądaną niezawodnością (100% - 80% = 20%). W tym przypadku budżet błędu daje nam fundusz 20% niereacyjności 20% czasu, w którym "nie obchodzi nas, czy to jest w górę, czy nie, ponieważ jest nadal w specyfikacji". Możemy czerpać i spędzać ten 20% czasu w dowolny sposób chcielibyśmy (być może z większą liczbie wydań), dopóki nie zostanie wyczerpany tak samo jak każdy inny budżet.
Budżety błędów są również używane w niektórych organizacjach w mniej pozytywnych przypadkach, w których cel SLO nie zostaje zrealizowany. W takim przypadku możesz zdecydować się na zrobienie czegoś nieco bardziej rygorystycznego niż tylko "podjęcie działania". Załóżmy, że usługa miała pewne problemy i działała tylko przez 60% czasu zgodnie z wcześniej wybranym wskaźnikiem SLI. Nie zrealizowaliśmy celu (SLO). Nasza usługa wykorzystała budżet błędów. Organizacja może zdecydować się wstrzymać planowaną wersję, ponieważ wie, że jeszcze bardziej wypaczenie systemu w tym momencie może tylko pogorszyć sytuację niezawodności. Zazwyczaj budżety błędów są obliczane dla określonego okresu czasu; miesiąc, kwartał itd. Jest to obliczane na zasadzie stopniowej, więc ostatecznie, jeśli niezawodność usługi się poprawi, budżet zostanie zwrócony.
W tym czasie wydania z bramą organizacja może zdecydować się na przestawienie niektórych zasobów inżynieryjnych od opracowywania funkcji w kierunku pracy nad niezawodnością. Mając na celu pomoc w odkryciu i poprawieniu źródła problemów, które spowodowały, że usługa wysadziła swój cel slo.
W przypadku budżetów błędów mówimy o „niektórych organizacjach” ze względu na ich wdrażanie. Zwłaszcza przypadek stosowania budżetu do dopuszczania wydań wymaga pewnego zaangażowania instytucjonalnego. W obliczu decyzji o wydaniu organizacja musi być skłonna wstrzymać wydanie, jeśli niezawodność usługi do tej pory nie była do ściągnięcia. Ta decyzja nie jest taka, że wszystkie organizacje są skłonne do podjęcia. Ta decyzja nie jest również jedyną możliwą odpowiedzią na wyczerpany budżet błędów, ale jest to jedna, o której najczęściej mówi się.
W osobnym module omówimy znacznie więcej szczegółów na temat wskaźników SLA, celów SLO i budżetów błędów. Warto jednak tutaj podkreślić zjadliwy aspekt cyklu tych praktyk. Teoretycznie umożliwia organizacji opisywanie, komunikowanie się i działanie na temat niezawodności usługi. Robiąc to w taki sposób, aby wszyscy pracowali nad lepszą niezawodnością. Ta pętla informacji zwrotnych może być niezwykle ważna.
Pozytywny cykl rozwoju nr 2: analiza post mortem bez winy
Idea postmortem — retrospektywnej analizy znaczącego, zwykle niepożądanego zdarzenia — nie jest nawet zdalnie specyficzna dla inżynierii niezawodności lokacji. Właściwie nie jest nawet typowa dla świata operacji. Jeden element, który jest bardziej zbliżony do inżynierii SRE, to nacisk na to, aby analiza była przeprowadzana „bez winy”. Musi skupiać się na niepowodzeniu procesu lub technologii, które odpowiada za powstanie incydentu, a nie na działaniach konkretnych osób. „Jaki zastosowany element procesu, który umożliwił wykonanie tej czynności przez X, doprowadził do niepowodzenia? Jakie informacje były niedostępne dla tej osoby lub nawet były widoczne w momencie, w którym doszło do sformułowania błędnego wniosku? Jakie bariery ochronne powinny być w miejscu, aby nie było możliwe, aby mieć taką katastrofalną awarię?" Te pytania są posortowane w bez winy pośmiertnie.
Treść i kierunek tych pytań ma kluczowe znaczenie. Szukamy sposobów ulepszania systemów lub procesów, a nie sposobów karania osób, których użycie tych systemów lub procesów w dobrej wierze przyczyniło się do awarii. Ważne jest, aby pamiętać: "Nie można uruchomić sposobu na niezawodność". W naszym doświadczeniu organizacja, która uruchamia osobę za każdym razem, gdy występuje incydent produkcyjny (z kilkoma wyjątkami), nie uczy się z tych zdarzeń. Zamiast tego, pozostają z jedną osobą, potrząsając w rogu, bojąc się wprowadzać wszelkie zmiany w ogóle.
Niemniej dobrze funkcjonujący proces analizy post mortem w organizacji tworzy pozytywny cykl rozwoju. Pozwala organizacji uczyć się od awarii i stale ulepszać swoje systemy (zapewniając właściwą analizę i kontynuację).
Ta relacja z błędami i błędami, które są przyjęte przez organizację jako możliwości uczenia się i ulepszania, jest podstawową zasadą inżynierii niezawodności lokacji. Kolejną jest tworzenie pozytywnych cykli rozwoju w celu wykorzystania tych szans oraz kierowania organizacji ku lepszej niezawodności.
Przyjrzyjmy się innym zasadom i praktykom, skoncentrowanym na ludzkiej stronie inżynierii SRE, w następnej lekcji.