Webinar ma słaby dźwięk, dlatego go przepisaliśmy.
Nazywam się Miedwiediew Eduard. Dzisiaj porozmawiam o tym, czym jest SRE, jak pojawił się SRE, jakie kryteria pracy mają inżynierowie SRE, trochę o kryteriach niezawodności, trochę o jego monitorowaniu. Będziemy chodzić po szczytach, bo za godzinę niewiele można powiedzieć, ale materiały przekażę do dodatkowej recenzji, a my wszyscy na Was czekamy . w Moskwie pod koniec stycznia.
Najpierw porozmawiajmy o tym, czym jest SRE - Inżynieria niezawodności miejsca. I jak to wyglądało jako odrębne stanowisko, jako odrębny kierunek. Wszystko zaczęło się od tego, że w tradycyjnych kręgach deweloperskich Dev i Ops to dwa zupełnie różne zespoły, zwykle mające dwa zupełnie różne cele. Celem zespołu programistów jest wdrażanie nowych funkcji i zaspokajanie potrzeb biznesowych. Celem zespołu operacyjnego jest upewnienie się, że wszystko działa i nic się nie psuje. Oczywiście cele te są ze sobą bezpośrednio sprzeczne: aby wszystko działało i nic się nie psuło, wdrażaj jak najmniej nowych funkcji. Z tego powodu istnieje wiele wewnętrznych konfliktów, które stara się rozwiązać metodologia zwana obecnie DevOps.
Problem w tym, że nie mamy jasnej definicji DevOps i jasnej implementacji DevOps. Występowałem na konferencji w Jekaterynburgu 2 lata temu i do tej pory sekcja DevOps zaczynała się od raportu „Co to jest DevOps”. W 2017 roku Devops ma prawie 10 lat, ale wciąż spieramy się, co to jest. I to jest bardzo dziwna sytuacja, którą Google próbował rozwiązać kilka lat temu.
W 2016 roku firma Google wydała książkę zatytułowaną Inżynieria niezawodności witryny. I tak naprawdę to właśnie dzięki tej książce rozpoczął się ruch SRE. SRE to specyficzna implementacja paradygmatu DevOps w konkretnej firmie. Inżynierowie SRE dokładają wszelkich starań, aby systemy działały niezawodnie. Pochodzą głównie od programistów, czasem administratorów z dużym doświadczeniem programistycznym. I robią to, co kiedyś robili administratorzy systemów, ale duże doświadczenie w rozwoju i znajomość systemu pod kątem kodu powoduje, że osoby te nie są skłonne do rutynowych prac administracyjnych, ale skłonne do automatyzacji.
Okazuje się, że paradygmat DevOps w zespołach SRE realizowany jest poprzez fakt, że istnieją inżynierowie SRE, którzy rozwiązują problemy strukturalne. Oto to samo połączenie między Dev i Ops, o którym ludzie mówią od 8 lat. Rola SRE jest podobna do roli architekta, ponieważ nowicjusze nie stają się SRE. Osoby na początku swojej kariery nie mają jeszcze żadnego doświadczenia, nie mają niezbędnego zakresu wiedzy. Ponieważ SRE wymaga bardzo subtelnej wiedzy o tym, co i kiedy dokładnie może pójść nie tak. Dlatego z reguły potrzebne jest tutaj pewne doświadczenie, zarówno wewnątrz firmy, jak i na zewnątrz.
Pytają, czy zostanie opisana różnica między SRE a devopsem. Właśnie została opisana. Można mówić o miejscu SRE w organizacji. W przeciwieństwie do klasycznego podejścia DevOps, gdzie Ops jest nadal odrębnym działem, SRE jest częścią zespołu programistów. Są zaangażowani w rozwój produktu. Istnieje nawet podejście, w którym SRE jest rolą przekazywaną z jednego programisty na drugiego. Uczestniczą w przeglądach kodu na tej samej zasadzie, co na przykład projektanci UX, sami programiści, czasem menedżerowie produktu. SRE działają na tym samym poziomie. Musimy je zatwierdzić, musimy je przejrzeć, aby przy każdym wdrożeniu SRE powiedział: „OK, to wdrożenie, ten produkt nie wpłynie negatywnie na niezawodność. A jeśli tak, to w pewnych akceptowalnych granicach. Porozmawiamy również o tym.
W związku z tym SRE ma prawo weta w sprawie zmiany kodeksu. Ogólnie rzecz biorąc, prowadzi to również do pewnego rodzaju małego konfliktu, jeśli SRE zostanie nieprawidłowo zaimplementowany. W tej samej książce o inżynierii niezawodności witryny wiele części, nawet żadna, nie mówi, jak unikać tych konfliktów.
Pytają, jak SRE odnosi się do bezpieczeństwa informacji. SRE nie jest bezpośrednio zaangażowana w bezpieczeństwo informacji. Zasadniczo w dużych firmach zajmują się tym osoby fizyczne, testerzy, analitycy. Ale SRE współdziała z nimi również w tym sensie, że niektóre operacje, niektóre zatwierdzenia, niektóre wdrożenia mające wpływ na bezpieczeństwo mogą również wpływać na dostępność produktu. Dlatego SRE jako całość współpracuje z dowolnymi zespołami, w tym zespołami ds. bezpieczeństwa, w tym z analitykami. Dlatego SRE są potrzebni głównie wtedy, gdy próbują wdrożyć DevOps, ale jednocześnie obciążenie programistów staje się zbyt duże. Oznacza to, że sam zespół programistów nie może już poradzić sobie z faktem, że teraz musi być również odpowiedzialny za operacje. I jest osobna rola. Rola ta jest przewidziana w budżecie. Czasami ta rola jest określona w wielkości zespołu, pojawia się osobna osoba, czasami zostaje nią jeden z programistów. Tak w drużynie pojawia się pierwszy SRE.
Złożoność systemu, na który wpływa SRE, złożoność wpływająca na niezawodność działania, jest konieczna i przypadkowa. Z konieczną złożonością mamy do czynienia wtedy, gdy złożoność produktu wzrasta do poziomu wymaganego przez nowe cechy produktu. Losowa złożoność ma miejsce wtedy, gdy złożoność systemu wzrasta, ale cechy produktu i wymagania biznesowe nie mają na to bezpośredniego wpływu. Okazuje się, że albo programista popełnił gdzieś błąd, albo algorytm nie jest optymalny, albo wprowadzone zostały dodatkowe zainteresowania, które bez specjalnej potrzeby zwiększają złożoność produktu. Dobry SRE powinien zawsze zaradzić tej sytuacji. Oznacza to, że każde zatwierdzenie, każde wdrożenie, każde żądanie ściągnięcia, w przypadku którego trudność wzrasta z powodu losowego dodania, powinno zostać zablokowane.
Pytanie brzmi, dlaczego nie zatrudnić po prostu inżyniera, administratora systemu z dużą wiedzą w zespole. Mówi się, że programista w roli inżyniera nie jest najlepszym rozwiązaniem kadrowym. Programista w roli inżyniera nie zawsze jest najlepszym rozwiązaniem kadrowym, ale chodzi o to, że programista zajmujący się operacjami ma trochę większe pragnienie automatyzacji, ma trochę większą wiedzę i umiejętności, aby wdrożyć ta automatyzacja. I odpowiednio skracamy nie tylko czas niektórych konkretnych operacji, nie tylko rutynowych, ale także tak ważnych parametrów biznesowych, jak MTTR (Mean Time To Recovery, czas regeneracji). W ten sposób, o czym również porozmawiamy nieco później, oszczędzamy pieniądze dla organizacji.
Porozmawiajmy teraz o kryteriach działania SRE. A przede wszystkim niezawodność. W małych firmach, start-upach często zdarza się, że ludzie zakładają, że jeśli usługa zostanie napisana dobrze, jeśli produkt zostanie napisany dobrze i poprawnie, to będzie działać, nie będzie się psuć. I tyle, piszemy dobry kod, więc nie ma co zepsuć. Kod jest bardzo prosty, nie ma się co łamać. To mniej więcej ci sami ludzie, którzy mówią, że nie potrzebujemy testów, bo spójrz, to są trzy metody VPI, po co tu przerywać.
To wszystko jest oczywiście błędne. A ci ludzie bardzo często w praktyce gryzą się z takim kodem, bo coś się psuje. Rzeczy psują się czasami w najbardziej nieprzewidywalny sposób. Czasami ludzie mówią nie, to się nigdy nie stanie. I to się dzieje cały czas. Zdarza się to wystarczająco często. I dlatego nikt nigdy nie dąży do 100% dostępności, ponieważ 100% dostępności nigdy się nie zdarza. To jest norma. Dlatego też, gdy mówimy o dostępności usługi, zawsze mówimy o dziewiątkach. 2 dziewiątki, 3 dziewiątki, 4 dziewiątki, 5 dziewiątek. Jeśli przełożymy to na przestój, to np. 5 dziewiątek, to jest to nieco więcej niż 5 minut przestoju rocznie, 2 dziewiątki to 3,5 dnia przestoju.
Ale oczywiste jest, że w pewnym momencie następuje spadek POI, zwrot z inwestycji. Przejście z dwóch dziewiątek na trzy dziewiątki oznacza mniej przestojów o ponad 3 dni. Przejście z czterech dziewiątek na pięć skraca przestoje o 47 minut rocznie. I okazuje się, że dla biznesu może to nie być krytyczne. Ogólnie rzecz biorąc, wymagana niezawodność nie jest kwestią techniczną, jest to przede wszystkim kwestia biznesowa, jest to kwestia produktowa. Jaki poziom przestojów jest akceptowalny dla użytkowników produktu, czego oczekują, ile płacą, np. ile pieniędzy tracą, ile pieniędzy traci system.
Istotnym pytaniem jest tutaj jaka jest niezawodność pozostałych podzespołów. Bo różnica między 4 a 5 dziewiątkami nie będzie widoczna na smartfonie z niezawodnością 2 dziewiątek. Z grubsza rzecz biorąc, jeśli 10 razy w roku coś zepsuje się na smartfonie w Twoim serwisie, najprawdopodobniej 8 razy awaria wystąpiła po stronie systemu operacyjnego. Użytkownik jest do tego przyzwyczajony i nie będzie zwracał uwagi na to jeszcze raz w roku. Konieczne jest skorelowanie ceny rosnącej niezawodności i rosnących zysków.
Właśnie w książce o SRE jest dobry przykład zwiększania do 4 dziewiątek z 3 dziewiątek. Okazuje się, że wzrost dostępności jest nieco mniejszy niż 0,1%. A jeśli przychód z usługi wynosi 1 milion dolarów rocznie, to wzrost przychodów wyniesie 900 dolarów. Jeśli zwiększenie przystępności cenowej o dziewięć kosztuje nas mniej niż 900 dolarów rocznie, podwyżka ma sens finansowy. Jeśli to kosztuje więcej niż 900 dolarów rocznie, to nie ma już sensu, bo wzrost przychodów po prostu nie rekompensuje kosztów pracy, kosztów zasobów. I wystarczą nam 3 dziewiątki.
Jest to oczywiście uproszczony przykład, w którym wszystkie żądania są równe. A przejście z 3 dziewiątek na 4 dziewiątki jest dość łatwe, ale jednocześnie na przykład przejście z 2 dziewiątek na 3 to już oszczędność 9 tysięcy dolarów, może to mieć sens finansowy. Oczywiście w rzeczywistości niepowodzenie żądania rejestracji jest gorsze niż brak wyświetlenia strony, żądania mają inną wagę. Może mają zupełnie inne kryterium z biznesowego punktu widzenia, ale tak czy siak, co do zasady, jeśli nie mówimy o jakichś konkretnych usługach, to jest to w miarę wiarygodne przybliżenie.
Otrzymaliśmy pytanie, czy SRE jest jednym z koordynatorów przy wyborze rozwiązania architektonicznego dla usługi. Powiedzmy pod kątem integracji z istniejącą infrastrukturą, tak aby nie doszło do utraty jej stabilności. Tak, SRE w ten sam sposób, w jaki pull requesty, commity, releases wpływają na architekturę, wprowadzenie nowych usług, mikroserwisów, wdrożenie nowych rozwiązań. Dlaczego mówiłem wcześniej, że potrzebne jest doświadczenie, potrzebne są kwalifikacje. W rzeczywistości SRE jest jednym z głosów blokujących w każdym rozwiązaniu architektonicznym i programowym. W związku z tym SRE jako inżynier musi przede wszystkim nie tylko rozumieć, ale także rozumieć, w jaki sposób niektóre konkretne decyzje wpłyną na niezawodność, stabilność oraz rozumieć, jak to się ma do potrzeb biznesowych i z jakiego punktu widzenia może to być akceptowalne i które nie.
Dlatego teraz możemy mówić już tylko o kryteriach niezawodności, które w SRE tradycyjnie definiowane są jako SLA (ang. Service Level Agreement). Najprawdopodobniej znane określenie. SLI (wskaźnik poziomu usług). SLO (cel poziomu usług). Umowa dotycząca poziomu usług jest być może terminem symbolicznym, zwłaszcza jeśli współpracowałeś z sieciami, dostawcami lub hostingiem. Jest to ogólna umowa opisująca wykonanie całej usługi, kary, niektóre kary za błędy, metryki, kryteria. A SLI jest samym miernikiem dostępności. Czyli czym może być SLI: czas odpowiedzi z usługi, liczba błędów w procentach. Może to być przepustowość, jeśli jest to jakiś rodzaj hostingu plików. Jeśli chodzi o algorytmy rozpoznawania, wskaźnikiem może być np. nawet poprawność odpowiedzi. SLO (ang. Service Level Objective) to odpowiednio kombinacja wskaźnika SLI, jego wartości i okresu.
Załóżmy, że umowa SLA może wyglądać następująco. Usługa dostępna jest przez 99,95% czasu przez cały rok. Lub 99 zgłoszeń do krytycznej pomocy technicznej zostanie zamkniętych w ciągu 3 godzin na kwartał. Lub 85% zapytań otrzyma odpowiedzi w ciągu 1,5 sekundy każdego miesiąca. Oznacza to, że stopniowo zaczynamy rozumieć, że błędy i awarie są czymś zupełnie normalnym. Jest to sytuacja akceptowalna, planujemy ją, a nawet w pewnym stopniu na nią liczymy. Oznacza to, że SRE buduje systemy, które mogą popełniać błędy, które muszą normalnie reagować na błędy, które muszą je uwzględniać. I o ile to możliwe, powinny tak obsługiwać błędy, aby użytkownik albo ich nie zauważył, albo zauważył, ale jest jakieś obejście, dzięki któremu wszystko nie runie do końca.
Na przykład, jeśli prześlesz film do YouTube, a YouTube nie będzie mógł go natychmiast przekonwertować, jeśli film jest za duży, jeśli format nie jest optymalny, wówczas żądanie oczywiście nie zakończy się niepowodzeniem z powodu przekroczenia limitu czasu, YouTube nie wyświetli błędu 502 , YouTube powie: „Stworzyliśmy wszystko, Twój film jest w trakcie przetwarzania. Będzie gotowe za około 10 minut.” To zasada łagodnej degradacji, znana na przykład z front-end developmentu, jeśli kiedykolwiek to robiłeś.
Kolejnymi terminami, o których będziemy mówić, a które są bardzo ważne w pracy z niezawodnością, z błędami, z oczekiwaniami, są MTBF i MTTR. MTBF to średni czas między awariami. MTTR Mean Time To Recovery, średni czas regeneracji. Czyli ile czasu minęło od momentu wykrycia błędu, od momentu pojawienia się błędu do momentu przywrócenia usługi do pełnej normalnej pracy. MTBF jest ustalany głównie poprzez pracę nad jakością kodu. Oznacza to, że SRE mogą powiedzieć „nie”. Trzeba też zrozumieć cały zespół, że kiedy SRE mówi „nie”, mówi to nie dlatego, że jest szkodliwy, nie dlatego, że jest zły, ale dlatego, że w przeciwnym razie wszyscy będą cierpieć.
Ponownie, jest wiele artykułów, wiele metod, wiele sposobów, nawet w samej książce, do której tak często się odwołuję, jak sprawić, by inni programiści nie zaczęli nienawidzić SRE. Z drugiej strony MTTR polega na pracy nad SLO (celem poziomu usług). I to głównie automatyzacja. Bo np. nasz SLO to uptime na poziomie 4 dziewiątek na kwartał. Oznacza to, że w ciągu 3 miesięcy możemy pozwolić na 13 minut przestoju. I okazuje się, że MTTR nie może być dłuższy niż 13 minut. Jeśli w ciągu 13 minut zareagujemy choćby na 1 przestój, oznacza to, że wyczerpaliśmy już cały budżet na kwartał. Łamiemy SLO. 13 minut na reakcję i naprawienie awarii to dużo dla maszyny, ale bardzo krótko dla człowieka. Bo dopóki dana osoba nie otrzyma ostrzeżenia, dopóki nie zareaguje, dopóki nie zrozumie błędu, to już kilka minut. Dopóki dana osoba nie zrozumie, jak to naprawić, co dokładnie naprawić, co zrobić, to jeszcze kilka minut. I tak naprawdę, nawet jeśli wystarczy zrestartować serwer, jak się okazuje, lub założyć nowy węzeł, to ręcznie MTTR wynosi już około 7-8 minut. Podczas automatyzacji procesu MTTR bardzo często sięga sekundy, czasem milisekund. Google zwykle mówi o milisekundach, ale w rzeczywistości oczywiście nie wszystko jest takie dobre.
W idealnym przypadku SRE powinien niemal całkowicie zautomatyzować swoją pracę, ponieważ wpływa to bezpośrednio na MTTR, jego wskaźniki, SLO całej usługi, a co za tym idzie, zysk biznesowy. Jeśli czas zostanie przekroczony, zostaniemy zapytani, czy wina leży po stronie SRE. Na szczęście nikt nie jest winny. I to jest osobna kultura, zwana pośmiertną bez balsamu, o której dzisiaj nie będziemy mówić, ale przeanalizujemy ją na Slurmie. To bardzo ciekawy temat, o którym można dużo rozmawiać. Z grubsza rzecz biorąc, jeśli przekroczony zostanie przydzielony czas na kwartał, wówczas winni będą wszyscy po trochu, co oznacza, że obwinianie wszystkich nie jest produktywne. Zamiast tego może nie obwiniajmy nikogo, ale poprawmy sytuację i pracujmy z tym, co mamy. Z mojego doświadczenia wynika, że takie podejście jest nieco obce większości drużyn, zwłaszcza w Rosji, ale ma sens i działa bardzo dobrze. Dlatego na koniec polecę artykuł i literaturę, którą możesz przeczytać na ten temat. Lub przyjedź do Slum SRE.
Pozwól mi wyjaśnić. Jeśli przekroczony zostanie czas SLO na kwartał, jeśli przestój nie wyniósł 13 minut, ale 15, kto może być za to winien? Oczywiście SRE może być winny, ponieważ najwyraźniej dokonał jakiegoś złego zatwierdzenia lub wdrożenia. Winę za to może ponosić administrator centrum danych, ponieważ mógł przeprowadzić jakąś nieplanowaną konserwację. Jeśli winę za to ponosi administrator centrum danych, to winę ponosi osoba z Ops, która nie kalkulowała kosztów utrzymania, koordynując SLO. Winę za to ponosi menadżer, dyrektor techniczny lub ktoś, kto podpisał umowę na centrum danych i nie zwrócił uwagi na to, że umowa SLA centrum danych nie jest zaprojektowana pod kątem wymaganych przestojów. W związku z tym wszyscy stopniowo w tej sytuacji są winni. A to oznacza, że w tej sytuacji nie ma sensu zrzucać winy na kogokolwiek. Ale oczywiście trzeba to poprawić. Dlatego przeprowadza się sekcje zwłok. A jeśli czytasz na przykład posty z GitHuba i jest to zawsze bardzo ciekawa, krótka i nieoczekiwana historia w każdym konkretnym przypadku, możesz zastąpić to, że nikt nigdy nie mówi, że ta konkretna osoba była winna. Winą zawsze obarcza się określone, niedoskonałe procesy.
Przejdźmy do następnego pytania. Automatyzacja. Kiedy mówię o automatyzacji w innych kontekstach, często odwołuję się do tabeli, która informuje, jak długo możesz pracować nad automatyzacją zadania, nie poświęcając na jego automatyzację więcej czasu, niż faktycznie oszczędzasz. Jest szkopuł. Problem polega na tym, że automatyzacja zadania przez SRE nie tylko oszczędza czas, ale także pieniądze, ponieważ automatyzacja bezpośrednio wpływa na MTTR. Ratują, że tak powiem, morale pracowników i programistów, które również jest zasobem wyczerpywalnym. Ograniczają rutynę. A to wszystko pozytywnie wpływa na pracę i w efekcie na biznes, nawet jeśli wydaje się, że automatyzacja nie ma sensu ze względu na koszty czasu.
W rzeczywistości prawie zawsze tak jest i jest bardzo niewiele przypadków, w których coś nie powinno zostać zautomatyzowane w roli SRE. Następnie porozmawiamy o tak zwanym budżecie błędów, budżecie błędów. Tak naprawdę okazuje się, że jeśli wszystko jest dla Ciebie dużo lepsze niż SLO, które sobie ustawiłeś, to też nie jest zbyt dobrze. Jest to raczej złe, ponieważ SLO działa nie tylko jako dolna, ale także przybliżona górna granica. Gdy ustawisz sobie SLO na 99% dostępności, a tak naprawdę masz 99,99%, okazuje się, że masz trochę miejsca na eksperymenty, które wcale nie zaszkodzą biznesowi, bo sam to wszystko wspólnie ustaliłeś i jesteś nie korzystaj z tej przestrzeni. Masz budżet na błędy, który w Twoim przypadku jest niewykorzystany.
Co z tym zrobić. Używamy go dosłownie do wszystkiego. Do testowania w warunkach produkcyjnych, do wdrażania nowych funkcji, które mogą mieć wpływ na wydajność, do wydań, do konserwacji, do planowanych przestojów. Obowiązuje również zasada odwrotna: jeśli budżet się wyczerpie, nie możemy wypuścić niczego nowego, bo inaczej przekroczymy SLO. Budżet został już wyczerpany, wypuściliśmy coś, jeśli negatywnie wpływa to na wydajność, czyli jeśli nie jest to jakiś fix, który sam w sobie bezpośrednio zwiększa SLO, to wychodzimy poza budżet i to jest zła sytuacja , wymaga analizy, sekcji zwłok i ewentualnie wprowadzenia pewnych poprawek procesowych.
Czyli okazuje się, że jeśli sama usługa nie działa dobrze, a SLO jest wydawane i budżet jest wydawany nie na eksperymenty, nie na jakieś wydania, ale na samo to, to zamiast jakichś ciekawych poprawek, zamiast ciekawych funkcji, zamiast ciekawych publikacji. Zamiast jakiejkolwiek pracy twórczej będziesz musiał uporać się z głupimi poprawkami, aby uporządkować budżet, lub edytować SLO, a to także proces, który nie powinien zdarzać się zbyt często.
Okazuje się zatem, że w sytuacji, gdy dysponujemy większym budżetem na błędy, zainteresowani są wszyscy: zarówno SRE, jak i deweloperzy. Dla programistów duży budżet na błędy oznacza, że można sobie poradzić z wydaniami, testami, eksperymentami. Dla SRE budżet na błędy i zapisanie tego budżetu oznacza, że bezpośrednio dobrze wykonują swoją pracę. A to wpływa na motywację do jakiejś wspólnej pracy. Jeśli będziesz słuchać swoich SRE jako programistów, będziesz miał więcej miejsca na dobrą pracę i znacznie mniej rutyny.
Okazuje się, że eksperymenty na produkcji są dość ważną i niemal integralną częścią SRE w dużych zespołach. Zwykle nazywa się to inżynierią chaosu i pochodzi od zespołu Netflix, który wydał narzędzie o nazwie Chaos Monkey.
Chaos Monkey łączy się z potokiem CI/CD i losowo powoduje awarię serwera produkcyjnego. Ponownie w strukturze SRE mówimy o tym, że wyłączony serwer sam w sobie nie jest zły, jak można się spodziewać. A jeśli mieści się w budżecie, jest akceptowalne i nie szkodzi biznesowi. Oczywiście Netflix ma wystarczająco dużo nadmiarowych serwerów, wystarczającą replikację, aby to wszystko można było naprawić, a użytkownik jako całość nawet tego nie zauważył, a tym bardziej, aby nikt nie opuszczał jednego serwera za żadne pieniądze.
Netflix miał przez jakiś czas cały zestaw takich narzędzi, z których jedno, Chaos Gorilla, całkowicie zamyka jedną ze Stref Dostępności Amazona. A takie rzeczy pomagają ujawnić, po pierwsze, ukryte zależności, gdy nie do końca wiadomo, co wpływa na co, co zależy od czego. A to, jeśli pracujesz z mikroserwisem, a dokumentacja nie jest całkiem idealna, może ci to być znane. I znowu, bardzo pomaga to w wyłapaniu błędów w kodzie, których nie można wychwycić podczas przemieszczania, ponieważ żaden etap nie jest dokładnie dokładną symulacją, ze względu na fakt, że skala obciążenia jest inna, wzór obciążenia jest inny, sprzęt jest najprawdopodobniej także inne. Obciążenia szczytowe mogą być również nieoczekiwane i nieprzewidywalne. A takie testowanie, które ponownie nie wykracza poza budżet, bardzo dobrze pomaga wyłapać błędy w infrastrukturze, których inscenizacja, autotesty, potok CI/CD nigdy nie wyłapią. I dopóki to wszystko jest ujęte w Twoim budżecie, nie ma znaczenia, że Twoja usługa tam upadła, chociaż wydawałoby się to bardzo przerażające, serwer padł, co za koszmar. Nie, to normalne, to dobrze, to pomaga łapać robaki. Jeśli masz budżet, możesz go wydać.
P: Jaką literaturę mogę polecić? Lista na końcu. Literatury jest sporo, polecę kilka raportów. Jak to działa i czy SRE sprawdza się w firmach nieposiadających własnego oprogramowania lub z minimalnym rozwojem. Na przykład w przedsiębiorstwie, którego główną działalnością nie jest oprogramowanie. W przedsiębiorstwie, w którym główną działalnością nie jest oprogramowanie, SRE działa dokładnie tak samo jak wszędzie indziej, ponieważ w przedsiębiorstwie trzeba także używać, nawet jeśli nie jest rozwijane, oprogramowania, trzeba wprowadzać aktualizacje, trzeba zmieniać infrastrukturę, trzeba ją rozwijać, trzeba ją skalować. SRE pomagają identyfikować i przewidywać możliwe problemy w tych procesach oraz kontrolować je po rozpoczęciu wzrostu i zmianie potrzeb biznesowych. Ponieważ absolutnie nie jest konieczne angażowanie się w rozwój oprogramowania, aby mieć SRE, jeśli masz co najmniej kilka serwerów i oczekuje się przynajmniej pewnego wzrostu.
To samo dotyczy małych projektów, małych organizacji, ponieważ duże firmy mają budżet i przestrzeń do eksperymentowania. Ale jednocześnie wszystkie te owoce eksperymentów można wykorzystać wszędzie, czyli SRE pojawiło się oczywiście w Google, w Netfliksie, w Dropboxie. Ale jednocześnie małe firmy i startupy mogą już czytać skondensowane materiały, czytać książki, oglądać raporty. Coraz częściej o tym słyszą, patrzą na konkretne przykłady, myślę, że to w porządku, to naprawdę może się przydać, my też tego potrzebujemy, jest super.
Oznacza to, że cała główna praca nad standaryzacją tych procesów została już wykonana za Ciebie. Pozostaje Ci określić rolę SRE konkretnie w Twojej firmie i zacząć faktycznie wdrażać wszystkie te praktyki, które znowu zostały już opisane. Oznacza to, że z przydatnych zasad dla małych firm jest to zawsze definicja SLA, SLI, SLO. Jeśli nie zajmujesz się oprogramowaniem, będą to wewnętrzne umowy SLA i wewnętrzne SLO, czyli wewnętrzny budżet na błędy. Prawie zawsze prowadzi to do ciekawych dyskusji w zespole i w biznesie, bo może się okazać, że wydasz na infrastrukturę, na jakąś organizację idealnych procesów, idealny rurociąg to znacznie więcej niż to konieczne. A te 4 dziewiątki, które masz w dziale IT, tak naprawdę ich teraz nie potrzebujesz. Ale jednocześnie możesz spędzić czas, wydać budżet na błędy na coś innego.
W związku z tym monitorowanie i organizacja monitoringu jest przydatna dla firmy dowolnej wielkości. I w ogóle taki sposób myślenia, gdzie błędy są czymś akceptowalnym, gdzie jest budżet, gdzie są Cele, znowu przydaje się firmie dowolnej wielkości, zaczynając od startupów dla 3 osób.
Ostatnim z niuansów technicznych, o którym należy wspomnieć, jest monitorowanie. Bo jeśli mówimy o SLA, SLI, SLO, to nie zrozumiemy bez monitorowania, czy mieścimy się w budżecie, czy realizujemy nasze Cele i jak wpływamy na ostateczne SLA. Widziałem wiele razy, że monitorowanie odbywa się w ten sposób: istnieje pewna wartość, na przykład czas żądania do serwera, średni czas lub liczba żądań do bazy danych. Ma standard określony przez inżyniera. Jeśli metryka odbiega od normy, przychodzi e-mail. To wszystko jest z reguły zupełnie bezużyteczne, bo prowadzi do takiego nadmiaru alertów, nadmiaru komunikatów z monitoringu, kiedy człowiek najpierw musi je za każdym razem zinterpretować, czyli ustalić, czy wartość metryki oznacza potrzeba jakiegoś działania. Po drugie, po prostu przestaje zauważać wszystkie te alerty, kiedy w zasadzie nie jest wymagane od niego żadne działanie. Jest to dobra zasada monitorowania, a pierwszą zasadą przy wdrażaniu SRE jest to, że powiadomienie powinno nastąpić tylko wtedy, gdy wymagane jest podjęcie działań.
W przypadku standardowym występują 3 poziomy zdarzeń. Są alerty, są zgłoszenia, są dzienniki. Alerty to wszystko, co wymaga podjęcia natychmiastowych działań. Oznacza to, że wszystko jest zepsute, musisz to teraz naprawić. Bilety wymagają opóźnionego działania. Tak, musisz coś zrobić, musisz coś zrobić ręcznie, automatyzacja się nie udała, ale nie musisz tego robić przez najbliższe kilka minut. Dzienniki to wszystko, co nie wymaga działań i ogólnie rzecz biorąc, jeśli wszystko pójdzie dobrze, nikt ich nigdy nie przeczyta. Logi będziesz musiał przeczytać dopiero wtedy, gdy z perspektywy czasu okaże się, że coś się popsuło, o czym nie wiedzieliśmy przez jakiś czas. A może potrzebujesz zrobić jakieś badania. Ale ogólnie wszystko, co nie wymaga żadnej akcji, trafia do dzienników.
Jako efekt uboczny tego wszystkiego, jeśli zdefiniowaliśmy, jakie zdarzenia wymagają działań i dobrze opisaliśmy, jakie te działania powinny być, oznacza to, że akcję można zautomatyzować. To znaczy, co się dzieje. Wychodzimy ze stanu gotowości. Przejdźmy do działania. Przechodzimy do opisu tej akcji. A potem przechodzimy do automatyzacji. Oznacza to, że każda automatyzacja zaczyna się od reakcji na zdarzenie.
Od monitorowania przechodzimy do terminu zwanego obserwowalnością. Od kilku lat wokół tego słowa także narosło sporo szumu. I niewiele osób rozumie, co to znaczy wyrwane z kontekstu. Ale najważniejsze jest to, że obserwowalność jest miarą przejrzystości systemu. Jeśli coś poszło nie tak, jak szybko można określić, co dokładnie poszło nie tak i jaki był stan systemu w tym momencie. Jeśli chodzi o kod: która funkcja się nie powiodła, która usługa się nie powiodła. Jaki był stan np. zmiennych wewnętrznych, konfiguracji. Jeśli chodzi o infrastrukturę, jest to informacja, w której strefie dostępności wystąpiła awaria, a jeśli masz zainstalowany Kubernetes, to w którym podu wystąpiła awaria i jaki był stan podu. W związku z tym obserwowalność ma bezpośredni związek ze MTTR. Im wyższa Obserwowalność usługi, tym łatwiej jest zidentyfikować błąd, tym łatwiej naprawić błąd, łatwiej zautomatyzować błąd, tym niższy MTTR.
Wracając do małych firm, nawet teraz bardzo często zadaje się pytanie, jak poradzić sobie z wielkością zespołu i czy mały zespół musi zatrudniać osobnego SRE. Mówiłem już o tym nieco wcześniej. Na pierwszych etapach rozwoju startupu czy np. zespołu nie jest to wcale konieczne, gdyż SRE można uczynić rolą przejściową. A to trochę ożywi zespół, bo jest przynajmniej pewna różnorodność. A ponadto przygotuje ludzi na fakt, że wraz z rozwojem ogólnie obowiązki SRE zmienią się bardzo znacząco. Jeśli zatrudniasz osobę, to oczywiście ma ona pewne oczekiwania. I te oczekiwania nie ulegną zmianie w czasie, ale wymagania zmienią się bardzo mocno. Dlatego zatrudnienie SRE jest dość trudne na wczesnych etapach. Własna uprawa jest dużo łatwiejsza. Ale warto o tym pomyśleć.
Być może jedynym wyjątkiem są sytuacje, w których istnieją bardzo rygorystyczne i dobrze określone wymagania dotyczące wzrostu. Oznacza to, że w przypadku startupu może to być pewnego rodzaju presja ze strony inwestorów, jakaś prognoza wzrostu kilka razy na raz. Zatem zatrudnienie SRE jest zasadniczo uzasadnione, ponieważ może być uzasadnione. Mamy wymagania do rozwoju, potrzebujemy osoby, która będzie odpowiedzialna za to, że przy takim wzroście nic się nie zepsuje.
Jeszcze jedno pytanie. Co zrobić, gdy programiści kilkakrotnie wycinają funkcję, która przechodzi testy, ale psuje produkcję, ładuje bazę, psuje inne funkcje, jaki proces wdrożyć. Zatem w tym przypadku wprowadzany jest budżet na błędy. A niektóre usługi, niektóre funkcje są już testowane w fazie produkcyjnej. Może być kanarkowo, gdy tylko niewielka liczba użytkowników, ale już w fazie produkcyjnej, wdrażana jest funkcja, ale już z oczekiwaniem, że jeśli coś się zepsuje, na przykład dla pół procenta wszystkich użytkowników, to nadal będzie spełniać wymagania budżet na błędy. W związku z tym tak, wystąpi błąd, dla niektórych użytkowników wszystko się zepsuje, ale powiedzieliśmy już, że jest to normalne.
Było pytanie o narzędzia SRE. To znaczy, czy jest coś szczególnego, z czego skorzystałyby SRE, a czego nie zrobiliby wszyscy inni. W rzeczywistości istnieją pewne wysoce wyspecjalizowane narzędzia, istnieje oprogramowanie, które na przykład symuluje obciążenia lub zajmuje się testami A/B kanarków. Zasadniczo jednak programiści już korzystają z zestawu narzędzi SRE. Ponieważ SRE współpracuje bezpośrednio z zespołem programistów. A jeśli masz różne narzędzia, okaże się, że synchronizacja wymaga czasu. Zwłaszcza jeśli SRE pracują w dużych zespołach, w dużych firmach, gdzie może być kilka zespołów, to standaryzacja ogólnofirmowa bardzo tutaj pomoże, ponieważ jeśli w 50 zespołach używanych jest 50 różnych narzędzi, oznacza to, że SRE musi je znać Wszystko. I oczywiście nigdy to się nie stanie. A jakość pracy, jakość kontroli przynajmniej części zespołów znacznie spadnie.
Nasz webinar dobiega końca. Udało mi się powiedzieć kilka podstawowych rzeczy. Oczywiście niczego o SRE nie można powiedzieć i zrozumieć w ciągu godziny. Mam jednak nadzieję, że udało mi się przekazać ten sposób myślenia, główne kluczowe punkty. A wtedy będzie można, jeśli będziecie zainteresowani, zagłębić się w temat, dowiedzieć się na własną rękę, popatrzeć, jak jest to realizowane przez inne osoby, w innych firmach. I w związku z tym na początku lutego przyjdź do nas do Slum SRE.
Slum SRE to trzydniowy intensywny kurs, który będzie mówił o tym, o czym teraz mówię, ale z dużo większą głębią, z prawdziwymi przypadkami, z praktyką, cały intensywny kurs jest nastawiony na praktyczną pracę. Ludzie zostaną podzieleni na zespoły. Wszyscy będziecie pracować nad prawdziwymi sprawami. W związku z tym mamy instruktorów Booking.com Ivana Kruglova i Bena Tylera. Mamy wspaniałego Eugene’a Barabasza z Google, z San Francisco. I ja też ci coś powiem. Koniecznie nas więc odwiedź.
Zatem bibliografia. Istnieją odniesienia do SRE. w tej samej książce, a raczej w 2 książkach o SRE napisanych przez Google. Inny , gdzie warunki i ich zastosowanie są nieco bardziej szczegółowe. Kolejne 3 to raporty dotyczące SRE w różnych spółkach. Pierwszy - , to przemówienie Bena Trainera z Google. Drugi - . Trzeci jest znowu . Czwarty raport z , która zatrudnia tylko 5 kluczowych pracowników SRE w 190 krajach. Przyglądanie się temu wszystkiemu jest bardzo interesujące, ponieważ tak jak DevOps oznacza bardzo różne rzeczy dla różnych firm, a nawet różnych zespołów, tak SRE ma bardzo różne obowiązki, nawet w firmach podobnej wielkości.
Jeszcze 2 linki na temat zasad inżynierii chaosu: , . A na koniec 3 zestawienia z serii Awesome Lists o około i około . Lista na SRE jest niesamowicie ogromna, nie trzeba przeglądać wszystkiego, jest około 200 artykułów. Gorąco polecam artykuły na temat planowania pojemności i bezbłędnej sekcji zwłok.
Interesujący artykuł:
Dziękuję, że mnie wysłuchałeś przez cały ten czas. Mam nadzieję, że się czegoś nauczyłeś. Mam nadzieję, że masz wystarczająco dużo materiału, aby dowiedzieć się jeszcze więcej. Do zobaczenia. Mam nadzieję, że w lutym.
Seminarium internetowe poprowadził Eduard Miedwiediew.
PS: dla tych, którzy lubią czytać, Eduard podał listę referencji. Zapraszamy tych, którzy wolą rozumieć w praktyce .
Źródło: www.habr.com