Niezawodność
Praktyki Inżynierskie Najlepszych Firm Produktowych
Aby zebrać w jednym miejscu praktyczną i aktualną wiedzę dotyczącą praktyk inżynierskich, postanowiłem swoje doświadczenia zebrać w serii artykułów pod wspólną nazwą Praktyk Inżynierskich. Mam nadzieję że to kompendium będzie miejscem, do którego możesz wracać po wskazówki i rozwiązania.
W cyklu Praktyk Inżynierskich:
Niezawodność [TEN ARTYKUŁ]
Ostatni artykuł był poświęcony analizie wdrażanych zmian i temu jakie wnioski z nich wyciągać. Dziś przyglądamy się innemu aspektowi praktyk inżynierskich.
Niezawodność w twoim produkcie
Gdy produkt nie ma podstaw
W świecie technologii, produkty cyfrowe wymagają solidnych podstaw zarówno w zakresie niezawodności, jak iobserwowalności. Brak tych fundamentów sprawia, że tworzenie projektu zaczyna przypomina budowanie domu na piasku: prędzej czy później, wszystko zacznie się walić.
Produkty, którym brakuje niezawodności nieodmiennie borykają się z przestojami, błędami i innymi nieoczekiwanymi zdarzeniami. System przestaje działać nagle, pozornie bez konkretnego powodu za tym stojącego. Zawieszki zdarzają się podejrzanie często, a błędy się nawarstwiają. Małe opóźnienie eskaluje do poważnego i trudnego do naprawienia zatrzymania pracy systemu.
W takich sytuacjach zespoły inżynierskie spędzają nieproporcjonalnie dużo czasu na gaszeniu pożarów, zamiast na rozwijaniu produktu. Jak opowiadał Aaron Rinehart w ramach Chaos Days:
Zespoły produktowe są zmuszone do ciągłego rozwiązywania problemów. Każda aktualizacja lub nowa funkcjonalność wiążą się z potencjalnym ryzykiem. A to tworzy atmosferę niepewności i strachu przed wprowadzaniem zmian.
Z drugiej strony brak obserwowalności powoduje sytuację przypominającą prowadzenie samochodu z opaską zawiązaną na oczach. Organizacja nie wie, co się dzieje w ich systemie. Identyfikowanie i rozwiązywanie problemów stają się niemal niemożliwe. Zespoły nie reagują efektywnie ani nie uczą się na błędach. Klienci doświadczają problemów, których nikt nie wykrył. Albo, co gorsza, problemy są ignorowane, aż do momentu, gdy stały się na tyle duże, że ich rozwiązanie wymaga znacznych zasobów.
Brak tych praktyk nie tylko utrudnia codzienną pracę, ale również odbija się na zyskach organizacji. Wydaje nam się, że pracujemy na 100%, a jednak - wyniki są prawie zerowe. Brak niezawodności i obserwowalności nie jest więc tylko problemem technicznym, ale staje się problemem biznesowym - może decydować o przetrwaniu firmy na rynku.
Wspaniale oddaje to cytat z State of DevOps Report z 2022:
When reliability is poor, improvements to software delivery have no effect — or even a negative effect — on organizational outcomes.
Firmy dobrymi praktykami postępują inaczej.
Organizacje z praktykami niezawodności
W świecie produktów cyfrowych, niezawodność jest nie tyle luksusem, co koniecznością.
Przy dzisiejszej złożoności produktów cyfrowych nie wystarczy już tylko wypchnąć funkcję na produkcję, a później o niej zapomnieć. Niestety, natychmiastowo pojawiają się problemy. Połączenia się zrywają, wiadomości nie docierają, serwisy umierają. Jak z tym sobie poradzić?
Sztuką jest utrzymywać niezawodny system, który jest w stanie oprzeć się głównym problemom i awariom. Musimy również obserwować jak funkcje się zachowują i przewidywać potencjalne problemy. Organizacje z praktykami niezawodności planują i wdrażają swoje produkty w oparciu o te właśnie praktyki.
Efekt? Każdy z interesariuszy zespołu produktowego wygrywa: Klienci – dostają produkt, z którego mogą korzystać będąc pewnymi, że będzie działać odpowiednio.
Biznes – niezawodny produkt generuje dla nich stabilne zyski.
Zespół – może spokojnie skupiać się na rozwoju projektu, zamiast oczekiwać na kolejny pożar - a jeśli już taki się pojawi, zauważa go i sprawnie reaguje. i reaguje szybko, gdy problemy się pojawiają.Czyli jednym zdaniem - więcej czasu spędzamy na pracę dowożącą wartość, a mniej na beznadziejną walkę z niekończącą się listą awarii i bugów. 🐛
Przykład z branży
W dzisiejszym wydaniu newsletteru, przykładem podzielił się Paweł Dawidowicz - Head of SRE w Ramp:
Q: Jakie macie praktyki dookoła niezawodności i obserwowalności?
A: Na początku skupiliśmy się, aby zrozumieć jakie procesy biznesowe są kluczowe dla osiągnięcia wymaganej wysokiej niezawodności. A następnie dla nich poznać pożądaną jakość, jakiej oczekują klienci i biznes. Wtedy wypracowaliśmy praktyki infrastrukturalne (np. Multi-Zone), programistyczne (np. Graceful Shutdown), wdrażania (np. pełny Continuous Deployment), które wbudowaliśmy w nasze rozwiązania. Wszystko to jest otoczone szeroką siecią metryk i logów, dzięki czemu widzimy i możemy zawczasu obserwować co nie działa.
Aby to zrealizować, poświęcamy dużo czasu pracy typowo zespołowej. Przeprowadzamy sesje brainstormingu z zespołami developerskimi, aby wbudowywać niezawodność w aplikację. Procesy zarządzania incydentami pozwalają nam stabilnie rozwiązywać nieprzewidywalne problemy. Inżynierzy jakości współpracują przy definiowaniu odpowiednich wymagań jakościowych. Uczymy osoby techniczne i biznesowe jak korzystać z narzędzi obserwowalności.
Nie wszystkie praktyki można od razu wdrożyć, więc mierzymy siły na zamiary. Wdrażamy to co jest aktualnie największą bolączką niezawodności systemu.Q: Jakie to benefity daje dla zespołu i organizacji?
A: Powyższe praktyki pozwoliły nam przyśpieszyć rozwiązywanie awarii i im zapobiegać w przyszłości. Mniej awarii zaś sprawia, że mamy więcej czasu na development funkcji biznesowym. Proces wdrażania na produkcję jest prawie bezbolesny – chcemy mieć nową funkcję to ją wdrażamy. Możemy też wychodzić na szersze rynki i proponować klientom jeszcze lepszą jakość i dostępność.
Prywatnie zaś największy benefit jest taki, że mogę spać spokojnie. Wiemy, że nasz system obsłuży 99% problemów jakie się pojawią. Robię update i wierzę, że nic się nie wywali. Z aplikacją żyje się łatwiej.
Niezawodność…, czyli tak właściwie co?
Rozmowę o niezawodności i obserwowalności warto rozpocząć od wyjaśnienia, o czym w ogóle będziemy mówić. Niestety dla tych pozornie prostych określeń, zadziwiająco trudno znaleźć jednozdaniowe wyjaśnienia. Musimy więc trochę poszperać. 😃
Niezawodność - Reliability
Najlepszą chyba definicję niezawodności znalazłem w Well-Architected Framework Microsoftu, ją która opisuje jako:
Outages and malfunctions are serious concerns for all workloads.
Coś, o czym często zapominamy - systemy informatyczne są naturalnie narażone na występowanie awarii. Wystarczy wspomnieć na przykład Fallacies of distributed computing czy CAP theorem.
A reliable workload must survive those events and continue to consistently provide its intended functionality.
Czyli niezawodność skupia się na tym, by pomimo problemów nadal spójnie realizować pożądane funkcje. Problemy oczywiście występują, ale różnica polega na tym, że nasz system mimo wszystko pracuje dalej.
It must be resilient so that it can detect, withstand, and recover from failures within an acceptable time period.
Niezawodność jest połączona z odpornością na problemy. Jakie kluczowe założenia musi spełniać odporny system?
Zauważyć, że problem wystąpił – np. wiadomość nie dotarła.
Obsłużyć problem bez zatrzymywania pracy – np. poinformować kogoś, że wiadomość nie dotarła.
Docelowo naprawić problem – np. wysłać daną wiadomość ponownie.
It must also be available so that users can access the workload during the promised time period at the promised quality level.
System niezawodny jest systemem dostępnym dla klienta – mówiąc kolokwialnie „klient może sobie wejść i poklikać “😃.
Pamiętajmy jednak, że mówimy tutaj o dostępności pożądanej przez klienta. A więc nie chodzi tylko o aspekty techniczne, ale również o biznesowe – w postaci oczekiwań naszych klientów. I je również trzeba rozumieć, aby móc je adekwatnie spełnić.
W skrócie – niezawodność zwykle stanowi wypadkową dwóch współgrających ze sobą aspektów: dostępności i odporności.
Obserwowalność – Observability
Aby lepiej nakreślić, czym charakteryzuje się obserwowalność, posłużymy się inną osobistością z branży. Dookoła obserwowalności nie sposób przecież nie zacytować CTO Honeycomb Charity Majors. W wywiadzie „What is observability…" , opisała ją w ten sposób:
Observability was just the ability to understand what’s going on in the inner workings of the system by observing it from the outside.
Czyli, w mowie ojczystej, obserwowalność to zdolność do zrozumienia stanu wewnętrznego systemu na podstawie tego, co widać z zewnątrz. Patrzymy na naszt system i na podstawie tylko i wyłącznie zaobserwowanych informacji jesteśmy w stanie zrozumieć, co i jak.
Idąc dalej można zacytować jeszcze definicję ze strony Honeycomb Learn about Observability:
We say that a system is “observable” to the extent that you can explain what is happening on the inside just from observing it on the outside, preferably without having to add new, special-case instrumentation to get your new question answered.
Czyli: przy wysokim poziomie obserwowalności, do diagnozy pracy systemu, nie potrzebujemy żadnego specjalnego hakowania. Patrzymy i już - mamy pełen pakiet informacji, które pokazują nam, co się dzieje. Zamiast działać post-factum, działamy więc pre-factum.
Do tematu można jeszcze dodać słowa z książki Achieving Observability:
Observability isn’t just for operations folks or just for “production incident response.” It’s also for answering the day-to-day questions we have about our systems, so the people who build and maintain the systems can form hypotheses, validate hunches, and make informed decisions all the time and not just when an exception is thrown, or a customer complains.
Czyli obserwowalność jest skupiona również na tym, aby pomóc nam w codziennych pracach zespołowych. Dzięki obserwowalności możemy budować lepsze zrozumienie tego w jaki sposób nasi klienci wykorzystują nasz system.
Praktyki dookoła niezawodności
W ramach praktyk niezawodności (i obserwowalności) celowo poruszę tylko kluczowe ich aspekty. Wiadomo, że można iść na hype-driven-development i proponować praktyki w stylu Chaos Monkey, czy Error Budget. Jeśli jednak nie umiemy się czołgać, to co dopiero się będziemy porywać na gonienie małp? 🐒
Jeśli jednak poszukujecie materiałów na poziomie eksperckim, to wspomniany wyżej z pewnością Wam się spodoba. Teraz natomiast skupimy się na poziomie Basic.
Wyprawę w świat niezawodności warto rozpocząć od wprowadzenia pojęcia ścieżki krytycznej.
Określenie ścieżki krytycznej
Nie wszystkie scenariusze i funkcje w naszym produkcie są tak samo ważne. Pewna część musi mieć wysoką dostępność, aby nasz system był uważany za niezawodny. Ale inne elementy mogą działać 50/50 i nikt nie wzruszy nawet ramionami 🤷.
Celem niezawodności jest ustalenie, co znajduje się na ścieżce krytycznej. Jakie komponenty, serwisy, bazy danych, serwisy zewnętrzne są nie do zastąpienia. A następnie zadbanie, by ta ścieżka działała tak, jak zaplanowaliśmy.
Jak diagnozować w takim razie ścieżkę krytyczną? Tutaj na pomoc raz jeszcze przychodzi Charity ze swoim artykułem Questionable Advice: “What’s the critical path?":
Right, critical path. What I said to Dan is this: “What makes you money?”
The idea here is to draw up a list of the things that are absolutely worth waking someone up to fix immediately, night or day, rain or shine.
And typically the right place to start on this list is by asking yourselves: “what makes us money?” as a proxy for the real questions, which are: “what actions allow us to survive as a business? What do our customers care the absolute most about? What makes us us?” That’s your critical path.'
Skupiamy się więc na tym co, ma na nas największy wpływ. Możemy to podsumować krótkim: „follow the money"💵
Kiedy mamy już wyznaczoną ścieżkę krytyczną to przychodzi pora, by skupić się na oczekiwaniach.
Pożądany poziom niezawodności
Omawiając oczekiwania w zakresie niezawodności, najczęściej wspomina się o wykorzystaniu:
SLI - (Service Level Indicators - SLI) onkretnie, mierzalne aspekty usługi, takie jak czas odpowiedzi czy procent niedziałających żądań. Bezpośrednio wpływają na doświadczenie użytkownika.
SLO (Service Level Objective) Cele SLI, jakie ma spełniać nasz produkt. Określają poziom usługi, do którego firma się zobowiązuje.
SLA (Service Level Agreements) Formalne umowy z klientami dotyczące poziomu usług. Jeśli ich nie spełnimy to klienci mogą oczekiwać np. zwrotu kosztów.
Podejście opisane powyżej jest świetne, ale dosyć mocno sformalizowane. Trudno jest rozpocząć z nim pracę, jeśli nikt wcześniej w zespole nie rozmawiał o niezawodności. Z tego właśnie powodu łatwo się skupić tutaj na technicznych aspektach pojedynczych żądań do systemu. Nie myślimy wtedy o niezawodności z punktu widzenia odbiorcy, a jedynie tej systemowej.
Zdecydowanie łatwiej jest rozpocząć pracę z niezawodnością poprzez zadawanie pytań bliższych biznesowi np.:
Czy 1 na 10/100/1000 transakcji, które się nie dokończą, będzie dla nas OK?
Przez jaki czas aplikacja może nie być dostępna? W jakich godzinach?
Jaki koszt przestoju ponosimy, jeśli dana funkcja nie działa?
Jak szybko klient wymaga odpowiedi? Natychmiastowo? Czy może pójść po kawę i wrócić i będzie OK?
Czy są jakieś wymagania regulacyjne lub prawne dotyczące działania tego procesu biznesowego?
Chcemy poznać oczekiwania wobec procesów, nad którymi pracujemy. Dzięki temu rozumiemy się lepiej zarówno wewnątrz zespołu, jak i z naszymi interesariuszami. Następnie obserwujemy te procesy w ramach naszych narzędzi. naszych narzędziach dookoła obserwowalności.
Pozostaje tylko pewien szkopuł 🪨:
W 95% organizacji to jest krok, który jest kompletnie pomijany. Efekt? Nie wiemy do czego dążymy i na czym się skupiamy. A jeśli tego nie wiemy, to stopniowo nasza niezawodność będzie degradować, bo nikt nie będzie tego sprawdzać na bieżąco. Dochodzi do tzw. .
To, o czym trzeba jeszcze powiedzieć, to jak systemy zewnętrzne wpływają na naszą ścieżkę krytyczną (i ogólnie niezawodność).
Minimalizacja wpływu zależności
Jeden z rozmówców rozbawił mnie ostatnio następującym zdaniem:
Mój system ma prawie 100% dostępności. Niestety zwykle nie odpowiada z zakładanym czasie, bo systemy zależne nie działają.
Muszę Cię zmartwić. To nie do końca tak.
Dostępność systemu twojego = twoja dostępność * wszystkie systemy, od których zależysz. Więc jeśli masz 99% dostępności, ale jednocześnie wykorzystujesz naraz pięć innych systemów z dostępnością 95%, to ostatecznie kończysz z 76% dostępności. Bardzo nisko, zwłaszcza biorąc pod uwagę poziom, z którego pozornie startowaliśmy.
W związku z powyższym, projektując system, musisz brać pod uwagę wpływ zewnętrznych podmiotów na twoją aplikację. Jeśli system zależny ma niską dostępność, to twój również będzie taką miał.
Pół żartem, pół serio, dostępność twojego systemu zostanie przejęta przez system zewnętrzny 😉
Kluczowe jest więc zapewnienie, że aplikacja może działać wydajnie bez swoich zależności. Albo przynajmniej realizować część wymaganych funkcji. Ostatecznie, przekazać minimalny, zrozumiały dla klienta komunikat. W efekcie, nawet jeśli system zewnętrzny nie działa, twoja dostępność nie spada.
Często pojawiającym się problemem jest także liczba zapytań, które wykonujemy. Na przykładzie konkretnej sytuacji:
W ramach naszego e-commerce, potrzebujemy konwertować cenę produktów na inną walutę.
Odpytujemy zewnętrzny serwis walut o kurs waluty…
…ale robimy to dla każdego produktu z zamówienia osobno…
…to, przy stanie naszego systemu, sprawia, że musimy wysłać średnio 10 zapytań na sekundę.
Nie brzmi zbyt zachęcająco, prawda? A przecież zamiast tego moglibyśmy np. odpytać raz na godzinę o kursy walut i przechować tę informację w naszym systemie. Efekt? Z 10 połączeń na sekundę, schodzimy do 1 na godzinę. Niestabilny system zewnętrzny nie spowoduje wtedy aż tylu problemów.
Przewidywanie problemów
Zamiast naprawiać pojawiające się problemy lepiej im jest zapobiegać jeszcze zanim zaczną stanowić zagrożenie. Jeśli już wiemy, co jest dla nas najważniejsze, to wokół tego możemy zbudować wymaganą niezawodność. Od pojedynczych komponentów po systemy zewnętrzne, projektujemy z myślą o awariach. I od razu planujemy poprawki.
W celu wprowadzenia tego rozwiązania w praktyce, świetnie sprawdzają się lekkie techniki modelowania dookoła C4, połączone np. z Risk-Storming:
Po uwzględnieniu tych wszystkich zależności, plan działania można skondensować do 4 kroków:
Wizualizujemy rozwiązanie.
Identyfikujemy potencjalne zagrożenia i problemy.
Oceniamy i wybieramy najważniejsze czynniki ryzyka.
Definiujemy potencjalne remedia, by im zaradzić.
Na tej podstawie jesteśmy w stanie przewidzieć zawczasu potencjalne problemy.
Na warsztaty poświęcone rozwojowi tego rozwiązania, warto zapraszać szerokie grono zespołowe: SRE, developerów, QA, PO, innych interesariuszy. Dzięki temu uzyskamy szerokie spojrzenie na to, co może się nie udać.
No to teraz trzeba zabrać się do stosowania rozwiązań w praktyce.
Praktyki programistyczno-infrastrukturalne
Ta sekcja będzie troszeczkę inna od pozostałych. Tu będę luźno rzucał różnorodnymi praktykami i zyskami z nich płynącymi. Zachęcam Cię do zapoznania się z nimi wszystkimi – może coś Ci podpasuje.😊
Praktyki dookoła stabilnego połączenia synchronicznego – Retry, Circuit Breaker, Timeout, Rate Limiter / Fallback – Sprawiają, że nawet jeśli pojawi się błąd HTTP to wiemy, jak go rozwiązać.
Migracja z komunikacji synchronicznej na asynchroniczną – dzięki niej unikamy czasowego złączenia (temporal coupling), gdy jedna i druga strona transakcji muszą działać w tym samym momencie.
Praktyki dookoła stabilnego połączenia asynchronicznego – Outbox Pattern, Idempotent Receiver, Dead Letter Queue, Compensating Transaction – Sprawiają, że wiadomości docierają do celu, bądź są naprawiane.
Praktyki redundancji – wiele instancji tej samej aplikacji / bazy i Load Balancing, Graceful Shutdown, Rolling Deployments, Database Migrations For Zero Downtime Deployments – wykorzystywane, aby w przypadku awarii lub wdrażania nowych wersji zawsze posiadać instancję która obsłuży wymagany ruch.
Praktyki stopniowego zastępowania funkcji
Feature Toggles, Dark Launching, Keystone Interface - nastawione na to, aby mogły równolegle działać kilka wersji danej funkcji.
Modularyzacja i dzielenie aplikacji – Bounded Contexts / Sharding / Bulkhead – aby potencjalne zmiany nie wpływały na całą aplikację.
Jest z czego wybierać, prawda? 🤔
Zarządzanie incydentami
Ostatnia praktyka, o której chcę dziś napisać, jest praktyką działania organizacyjnego.
Powiedzmy sobie szczerze - zawsze jest szansa, że coś się pochrzani. Nawet jeśli masz zaimplementowane wszystko, co powyżej napisałem, to i tak w pewnym momencie pojawią się tak absurdalne problemy, że żadna z technik opisanych powyżej nie pomoże.
W przypadku takiego incydentu, organizacja wariuje. Ludzie panikują, zaczepiają kogo się tylko da, piszą na wszystkich kanałach naraz, dzwonią do siebie bez ładu i składu. W takiej atmosferze nie da się naprawiać problemów. A to powoduje, że aplikacja jest jeszcze dłużej niedostępna.
To, co polecam zrobić, to przygotować się zawczasu na wystąpienie awarii. Pomaga sporządzenie prostego planu na zarządzanie incydentem . Poniżej opisałem, jak to może wyglądać:
Jasne uświadomienie organizacji, że mamy awarię w postaci komunikatu na wyznaczonym kanale.
Wyznaczenie osoby odpowiedzialnej za zarządzanie rozwiązywaniem i komunikacją.
Stopniowe informowanie o postępach pracy lub ich braku.
Po naprawie zebranie “na szybko” skutków awarii i informacji o źródle problemu.
Więcej o tej kwestii opowiedział Jarek Pałka podczas niesamowitego odcinka Better Software Design: O fuckupach w projektach IT. Świetnie opisane praktyki pracy w ramach incydentów.
Na końcu należy oczywiście również przeprowadzić Postmortem 😊
Na koniec do omówienia pozostają nam praktyki zespołowe.
Jak współpracować
Propagowanie wiedzy
Bardzo trudno jest pracować nad niezawodnością i obserwowalnością, jeśli członkowie zespołu nie znają tych pojęć, oraz tego, co się z nimi wiąże. A także zysków jakie one mogą generować.
Wracając do SLI/SLO/SLA. Członkowie zespołu i interesariusze muszą rozumieć jak ich codzienna praca przekłada się na te miary. Inaczej staje się to pustą praktyką, która nie jest w stanie realizować celów biznesowych. By temu zapobiec, warto skorzystać z branżowych case studies, czy szkoleń poświęconych mierzeniu procesu przez dokładne wskaźniki w produkcie.
Warto też pamiętać, że duża część praktyk dookoła niezawodności nie jest oczywista z perspektywy członków zespołu, a bez pełnego zrozumienia może sprawiać wrażenie uciążliwej. Odpowiednie wyjaśnienie, jak te praktyki wdrożyć i jak nam pomagają, pomoże przekonać do nich zespoły.
Last, but not least, zaskakująco liczna grupa osób nie potrafi korzystać z dashboardów, ani interpretować zawartych tam danych. Aby zacząć sprawnie się nimi posługiwać, potrzebują przynajmniej kilku przykładów, jeśli nie cyklu szkoleń. Nie zastanawiaj się jednak, czy warto. Inwestycja w edukację zwraca się przez większą samodzielność członków zespołu. I większą ilość czasu, kiedy nie musimy za każdym razem klikać i im pokazywać 😉.
Kultura organizacyjna
Podsumowując temat, warto jeszcze dodać dwa słowa o kulturze organizacyjnej dookoła niezawodności i obserwowalności.
Niezawodność i obserwowalność nie są dane raz na zawsze. Trzeba o nie stale dbać i rozwijać. Pojawiają się nowe procesy do wdrożenia. Wykonujemy kolejną integrację z systemem zewnętrznym. Przepisujemy serwisy infrastrukturalne na inne. Każda z tych zmian powoduje istotną zmianę w sposobie działania systemu.
W tak dynamicznym środowisku, każdy pracujący i wykorzystujący produkt członek zespołu, musi być świadomy znaczenia niezawodności. Gdy niezawodność jest powszechnie ceniona, pracujemy, by aktywnie zapobiegać powstawaniu błędów, a nie tylko reagować na ich wystąpienie. To podejście wymaga inwestowania w ciągłe doskonale narzędzi i technik pracy i otwartej komunikacji. Ostatecznie w obliczu awarii, staramy się dojść do sedna problemu, a nie zwalić winę i pójść dalej.
Długofalowa niezawodność wymaga czegoś co często nazywamy „incentive system” – systemem zachęt, nagród, czy bodźców. Praca dookoła niezawodności i obserwowalności powinna być tak samo nagradzana i poważana, jak każda inna. Przecież tak samo dowozi wartość dla ostatecznego klienta.
Jeśli brakuje takiej, przyjaznej niezawodności, kultury, możemy próbować wdrażać omawiane rozwiązania, ale rezultaty będą nikłe. Organizacja będzie działać w opozycji do naszych, nawet najlepszych chęci. Członkowie zespołu będą się skupiać na dowożeniu „ficzerków", a niezawodność będzie spadać w dół 📉.
A ja chciałbym Wam tego scenariusza oszczędzić. 😎
Materiały
Standardowo, dla zainteresowanych, mam do polecenia kilka materiałów pogłębiających temat:
Książka - Site Reliability Engineering https://sre.google/books/
Książka - Implementing Service Level Objectives https://www.amazon.com/Implementing-Service-Level-Objectives-Practical/dp/1492076813
Zbiór wiedzy - Microsoft Azure Well-Architected Framework – Reliability https://learn.microsoft.com/en-us/azure/well-architected/reliability/
Podsumowanie
Zbudowanie stabilnego środowiska operacyjnego i wdrożenie praktyk obserwowalności pozwala zespołom dostarczać wartość bez zakłóceń. Dzięki temu firma odnosi większe korzyści, a nasza praca staje się bardziej przewidywalna i spokojna.
A jak to wygląda u Ciebie? Produkcja działa jak w zegarku, czy raczej ciągle gasicie pożary? 🔥
Obserwowalność
Kolejne wydanie serii poświęcimy bardzo blisko powiązanemu tematowi - obserwowalności i temu, jak wspiera całościowe działanie produktu.