Niezawodność i obserwowalność2023-11-17Cześć! W dzisiejszym wydaniu skupimy się ponownie na Praktykach Inżynierskich Firm Produktowych. W poprzednim newsletterze rozmawialiśmy o dokumentacji. Ale, jak to mówią górnicy, trzeba zejść głębiej. ⛏️ Dziś na tapet bierzemy niezawodność i obserwowalność – czyli o tym, w jaki sposób zapewniać stabilne działanie produktu. Będzie dużo o praktykach technicznych i biznesowych. Oraz o tym, co się dzieje, gdy zapominamy o podstawach inżynierskich. Ale zanim to wszystko, jak co tydzień, przygotowałem też dla Ciebie 5 interesujących materiałów ze świata i branży. 🤔 A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówka1. Compliance standards should be modern development practices - Charity Majors Czy można połączyć standardy zgodności korporacyjnej z imponującą prędkością dostarczania? Charity pokazuje, że tak. Wyjaśnia również, jak nowoczesne praktyki dostarczania pozwalają uzyskać szybkie i bezpieczne pętle zwrotne: nasz kod <-> produkcja. Charity nie bez powodu promuje automatyzację obserwowalności, zgodności i aspektów prawnych. Krótko mówiąc świetna prezentacja. https://www.youtube.com/watch?v=tuunGZ-4wPQ 2. Task Processing, Aggregate Root and Projection - Yves Goeleven Jeśli jeszcze nie śledzicie Yvesa, to gorąco polecam. Na swoich SM i blogu opisuje, w jaki sposób zdefiniować dowolne procesy biznesowe za pomocą 3 podstawowych building blocków (Event / Command / State) i ich 9 wzajemnych interacji. W tym poście na LinkedIn opisuje, jak przełożyć te interakcje na procesy biznesowe i podejście Given-When-Then. https://www.linkedin.com/posts/goeleven_over-the-past-few-days-i-introduced-you-activity-7126900963495342081-ZVfm/ 3. The Product Model at Spotify - Joakim Sundén Ciekawy opis działania serwisu Spotify i tego, jak poznaje, a następnie spełnia potrzeby klienta. Przykładem jest Discover Weekly - innowacyjna funkcja Spotify, która wywodzi się z ryzyka i eksperymentów autonomicznych zespołów. Z opowieści wyłania się obraz firmy z silną kulturą zespołów produktowych i liderów https://joakimsunden.com/the-product-model-at-spotify/ 4. From Technical Debt to Design Integrity – Alberto Brandolini Nie ma jednej odpowiedzi na pytanie, czym jest dług techniczny. Ale być może to sama definicja jest błędna? Alberto krytykuje metaforę długu technicznego jako zbytnio skupioną na przeszłości. Proponuje zamiast tego pojęcie “integralności rozwiązania” - mierzące to, jak dobrze kod odpowiada swojemu przeznaczeniu. Takie podejście skupia się na gotowości kodu na nadchodzące wyzwania, zamiast na poczuciu winy związanym z długiem technicznym. https://medium.com/@ziobrando/from-technical-debt-to-design-integrity-48e7056b6776 5. Zmiany w ChatGPT i przejmowanie rynku - Colin Fitzpatrick OpenAI poszerza zakres działania ChatGPT, jednocześnie kanibalizując wiele konkurencyjnych projektów. W ramach chatu możemy teraz wykorzystywać niezależnych agentów, wytrenowanych i skupionych na konkretnym modelu działania. Już za rogiem czai się możliwość łączenia agentów w niezależne, wielowątkowe scenariusze biznesowe. Konkurencja albo nadrobi albo zostanie z tyłu. https://www.linkedin.com/feed/update/urn:li:activity:7127579494298583043/ Niezawodność w twoim produkcieGdy produkt nie ma podstawW ś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:
Firmy dobrymi praktykami postępują inaczej. Organizacje z praktykami niezawodnościW ś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.
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żyW dzisiejszym wydaniu newsletteru, przykładem podzielił się Paweł Dawidowicz - Head of SRE w Ramp:
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ść - ReliabilityNajlepszą chyba definicję niezawodności znalazłem w Well-Architected Framework Microsoftu, ją która opisuje jako:
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.
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.
Niezawodność jest połączona z odpornością na problemy. Jakie kluczowe założenia musi spełniać odporny system?
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ść – ObservabilityAby 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:
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:
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:
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ściW 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 krytycznejNie 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?":
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ściOmawiając oczekiwania w zakresie niezawodności, najczęściej wspomina się o wykorzystaniu:
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.:
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ściJeden z rozmówców rozbawił mnie ostatnio następującym zdaniem:
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:
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ówZamiast 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:
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-infrastrukturalneTa 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.😊
Jest z czego wybierać, prawda? 🤔 Zarządzanie incydentamiOstatnia 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ć:
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, ale o tym już było w pierwszym newsletterze 😊. Praktyki dookoła obserwowalnościRozpoczniemy od mema:
Obserwowalność trzeba zaplanować i wdrożyć. No niestety, taka jest prawda, nie da się jej kupić na straganie. Gdy na ślepo wdrażamy narzędzie do obserwowalności, to nasze koszta rosną znacząco, ale nic nie zyskujemy. Pozdrawiam wszystkich użytkowników DataDog😉. Jeśli odrobiliśmy naszą lekcję o ścieżce krytycznej, to wiemy, co jest dla nas istotne. Jeśli odrobiliśmy lekcję o pożądanym poziomie niezawodności, to rozumiemy, jak ocenić, czy najważniejsze procesy działają, czy nie. Pozostaje nam tylko zaplanować obserwowalność dookoła tych procesów. Wybór elementów mierzeniaWarto rozpocząć od kategoryzacji tego, jakie informacje możemy analizować. Na informacje zbierane można spojrzeć z dwóch stron – wewnętrznej i zewnętrznej tzw. white-box i black-box:
W kolejnym kroku chcemy dokładnie zrozumieć, jakie elementy wchodzą w skład naszej ścieżki krytycznej. Celowo mówię tutaj szeroko o elementach – to mogą być aspekty programistyczne (serwisy aplikacyjne, fasady zapytania zewnętrzne), ale też infrastrukturalne (baza danych, aplikacja, klaster). W pojęciu tego konceptu, pomaga odpowiednia wizualizacja. Przykład takiej, w kontekście aplikacji do zarządzania produktami, znajdziesz w artykule Health modeling and observability od Microsoftu:
Już na pierwszy rzut oka możemy dostrzec zależności pomiędzy poszczególnymi elementami ścieżki krytycznej. Następnie łączymy oba zbiory informacji (co możemy zbierać i co chcemy obserwować) i przekładamy na konkretne aspekty procesu, które chcemy monitorować. Zwykle są to aspekty:
Na koniec łączymy je w bardziej ogólne metryki np.:
To podsumowanie niezawodności naszej ścieżki krytycznej. Następnym krokiem jest wdrożenie mierzenia wybranych aspektów. Rozpoczniemy od prostszej ścieżki: Wdrażanie mierzenia infrastrukturyDzisiejsze serwisy infrastrukturalne (czy to chmurowe, czy to dookoła Kubernetesa), w większości pozwalają udostępnić dalej dane o wykonanym działaniu. Możemy je skonfigurować tak, by przesyłały te dane do odpowiedniego narzędzia monitoringu – poniżej przykład dla:
O czym należy pamiętać, wprowadzając to rozwiązanie?
Więcej wysiłku czeka nas z mierzeniem pracy elementów programistycznych. Wdrożenie mierzenia aplikacjiPierwszą i najważniejszą kwestią jest monitorowanie tego, czy w ogóle aplikacja żyje i odpowiada. Zwykle nazywa się to mierzeniem zdrowia aplikacji (health checks). Zgodnie ze standardami Kubernetesa, wyróżniamy tutaj 3 wartości (sondy – probes):
W 95% przypadków odpowiedzi na te pytania są związane z naszą ścieżką krytyczną. Więc, aby zwracać te odpowiedzi do serwisów monitorujących, musimy odpowiednio zaprogramować odpowiedź z naszej aplikacji. Bez tego będziemy zwracać wartości domyślne – nieskupione na tym, jaki cel realizujemy. Następnie przychodzi kolej na mierzenie procesu biznesowego. W tym celu musimy dodać odpowiednie informowanie w naszym kodzie. Zwykle jest to związane z dodawaniem tzw. . O czym warto pamiętać?
Mogą pojawić się głosy, że zwykle narzędzia do obserwowalności w aplikacjach automatycznie logują informacje o przeprowadzanych procesach. Ale prawdą jest też, że zwykle jest to zdecydowanie za mało, by odpowiadać na kluczowe pytania dotyczące systemu. Może i żyjemy w erze AI, ale w tym wypadku automat wciąż nie odrobi za nas roboty. 🤖 Dashboardy i alertyDo tworzenia dashboardów i alertów można usiąść dopiero, gdy zadbaliśmy już wszystko opisane wyżej. Inaczej narażamy się na przetestowanie w praktyce niezawodnej reguły shit-in -> shit-out 💩. Tworzone dashboardy powinny w założeniu natychmiastowo odpowiadać na kluczowe pytania dotyczące niezawodności:
Jeśli odpowiednio logowaliśmy informacje dotyczące procesów, to powinniśmy być również w stanie pogrupować je pod względem wspólnych wymiarów. To natomiast pozwoli zauważyć, że np.
Pracę z alertami warto rozpocząć od przyswojenia sobie niesamowicie trafnego zdania z książki Site Reliability Engineering:
Jeśli chcemy kogoś powiadomić, to powinniśmy przekazać mu dokładną informację, na co zwrócić uwagę. Nie ma chyba nic gorszego niż alerty, które są zbyt ogólne – otwieramy zgłoszenie i wzruszamy ramionami. O czym jeszcze nie powinniśmy zapominać?
Na koniec do omówienia pozostają nam praktyki zespołowe. Jak współpracowaćPropagowanie wiedzyBardzo 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 organizacyjnaPodsumowują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łyStandardowo, dla zainteresowanych, mam do polecenia kilka materiałów pogłębiających temat:
PodsumowanieWbudowanie niezawodności i obserwowalności w produkt pozwala nam stabilnie dostarczać wartość klientom. Dzięki temu biznes ma z tego większe zyski, a my możemy spokojnie pracować. A jak to wygląda u Ciebie? Ciągłe awarie, czy raczej spokój na produkcji? PS. Autor oświadcza, że nie jest sponsorowany przez Google, Microsoft ani Honeycomb 😃. Po prostu mają świetne materiały dookoła niezawodności i obserwowalności. 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
