Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00358 005317 19045622 na godz. na dobę w sumie
Inżynieria niezawodnych baz danych. Projektowanie systemów odpornych na błędy - książka
Inżynieria niezawodnych baz danych. Projektowanie systemów odpornych na błędy - książka
Autor: , Liczba stron: 256
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-4426-6 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook (-35%), audiobook).

Informatyczna rewolucja dosięgła również systemy bazodanowe. Przez długi czas administrator bazy danych interesował się głównie wewnętrznymi mechanizmami bazy, optymalizacją zapytań czy analizą podsystemów składowania danych. Z kolei oprogramowaniem stron, infrastrukturą czy usługami sieciowymi zajmowali się zupełnie inni ludzie, pracujący w odmienny sposób. Nowe technologie wymuszają jednak zmianę sposobu pracy i myślenia. Trzeba położyć nacisk na automatyzację, inżynierię oprogramowania, ciągłą integrację i ciągłe udostępnianie. Poza tym trzeba zapewnić ochronę przetwarzanych danych - ich wartość i znaczenie wciąż szybko rosną.

W tej praktycznej książce dokładnie wyjaśniono współczesne podejście do tworzenia architektury baz danych i ich eksploatacji. Jeśli chcesz stać się znakomitym inżynierem niezawodności baz danych, czyli DBRE (z Database Reliability Engineer), znajdziesz tu schemat zasad i praktyk projektowania, budowania i eksploatacji magazynów danych zgodnie z paradygmatami inżynierii niezawodności i kultury DevOps. Zapoznasz się z podstawowymi zagadnieniami z obszaru eksploatacji, z metodami utrwalania baz danych, nauczysz się stosować najważniejsze technologie skalowalnego i wydajnego składowania oraz pobierania danych z zachowaniem odporności na błędy. Dzięki temu szybko i skutecznie zajmiesz się architekturą i eksploatacją każdej nowoczesnej bazy.

W książce między innymi:

Stań się znakomitym inżynierem niezawodności!


Laine Campbell od 18 lat zajmuje się środowiskami produkcyjnymi baz danych i systemów rozproszonych o dużej skali. Obecnie jest starszym dyrektorem ds. inżynierii środowisk produkcyjnych w firmie Fastly.

Charity Majors jest CEO i założycielką firmy honeycomb.io. Wcześniej zajmowała się eksploatacją należącej do Facebooka platformy Parse, gdzie zarządzała rozbudowanym zestawem replik baz MongoDB, a także bazami Redis, Cassandra i MySQL.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Database Reliability Engineering: Designing and Operating Resilient Database Systems Tłumaczenie: Tomasz Walczak ISBN: 978-83-283-4426-6 © 2018 Helion S.A. Authorized Polish translation of the English edition of Database Reliability Engineering ISBN 9781491925942 © 2018 Laine Campbell, Charity Majors This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/inbazd Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Przedmowa ................................................................................................................ 7 Wprowadzenie ............................................................................................................ 9 1. Wprowadzenie do inżynierii niezawodności baz danych ............................................. 15 16 20 24 Podstawowe zasady inżyniera niezawodności baz danych Przegląd podstaw eksploatacji Podsumowanie 2. Zarządzanie poziomem jakości usług ......................................................................... 25 25 27 29 35 40 Dlaczego potrzebne są cele z zakresu poziomu jakości usług? Wskaźnik SLI (ang. service-level indicator) Definiowanie celów SLO Monitorowanie celów SLO i przekazywanie informacji o nich Podsumowanie 3. Zarządzanie ryzykiem ................................................................................................ 41 42 44 45 45 54 56 Kwestie związane z ryzykiem Co możemy zrobić? Czego nie robić? Funkcjonujący proces — uruchamianie Bieżące iteracje Podsumowanie 4. Monitorowanie operacyjne ........................................................................................ 57 59 63 64 67 71 74 Nowe reguły monitorowania operacyjnego Platforma monitorowania operacyjnego Dane wyjściowe Uruchamianie monitorowania Instrumentacja aplikacji Instrumentacja serwera lub instancji 3 Poleć książkęKup książkę Instrumentowanie magazynu danych Warstwa połączeń z magazynem danych Wewnętrzne monitorowanie bazy danych Obiekty bazodanowe Zapytania bazodanowe Asercje i zdarzenia w bazie danych Podsumowanie 76 76 79 83 84 84 85 5. Inżynieria infrastruktury ........................................................................................... 87 87 Hosty 98 Wirtualizacja 100 Kontenery Baza danych jako usługa 100 102 Podsumowanie 6. Zarządzanie infrastrukturą ...................................................................................... 103 104 104 106 107 109 112 112 113 114 114 System kontroli wersji Definicja konfiguracji Budowanie na podstawie konfiguracji Konserwacja konfiguracji Definiowanie i koordynowanie infrastruktury Testy akceptacyjne i zgodność z prawem Katalog usług Łączenie wszystkich elementów Środowiska programistyczne Podsumowanie 7. Tworzenie kopii zapasowych i przywracanie stanu ................................................... 117 118 119 120 126 131 135 Podstawowe zagadnienia Uwagi do przywracania danych Scenariusze przywracania stanu Struktura strategii przywracania stanu Strategia przywracania stanu Podsumowanie 8. Zarządzanie udostępnianiem ................................................................................... 137 137 142 145 149 155 Edukacja i współpraca Integracja Testy Wdrażanie Podsumowanie 4  Spis treści Poleć książkęKup książkę 9. Bezpieczeństwo ...................................................................................................... 157 157 159 163 171 181 Cel stosowania zabezpieczeń Zabezpieczanie baz danych jako zadanie Luki i eksploity Szyfrowanie danych Podsumowanie 10. Przechowywanie, indeksowanie i replikacja danych ................................................. 183 183 191 209 Przechowywanie struktur danych Replikacja danych Podsumowanie 11. Atlas magazynów danych ........................................................................................ 211 211 221 226 Koncepcyjne cechy magazynów danych Wewnętrzne cechy magazynu danych Podsumowanie 12. Przegląd architektur danych .................................................................................... 227 227 235 240 Komponenty architektoniczne Architektury danych Podsumowanie 13. Uzasadnienie zatrudniania inżyniera niezawodności baz danych .............................. 241 241 248 Kultura niezawodności baz danych Podsumowanie Skorowidz .............................................................................................................. 249 Spis treści  5 Poleć książkęKup książkę 6  Spis treści Poleć książkęKup książkę ROZDZIAŁ 3. Zarządzanie ryzykiem Eksploatacja obejmuje zestaw obietnic i pracę potrzebną do ich spełnienia. W rozdziale 2. opisa- no, jak tworzyć takie obietnice, monitorować je i informować o ich realizacji. Zarządzanie ryzy- kiem polega na identyfikowaniu, ocenie i określaniu priorytetów związanych z niewiadomymi, które mogą skutkować naruszeniem tych obietnic. Ważne jest tu także wykorzystanie zasobów (technologii, narzędzi, ludzi i procesów) do monitorowania tych niewiadomych, łagodzenia ich skutków i ograniczania prawdopodobieństwa ich wystąpienia. Nie jest to nauka ścisła. Celem nie jest wyeliminowanie wszystkich zagrożeń — to nierealny cel, który prowadzi do marnowania zasobów. Zadanie polega na wbudowaniu oceny i zmniejszaniu wpływu zagrożeń we wszystkie procesy oraz na stopniowym ograniczaniu skutków tych zagrożeń za pomocą technik łagodzenia problemów i zapobiegania im. Ten proces należy wykonywać stale na podstawie danych z obserwacji incydentów, wprowadzania nowych komponentów w architektu- rze i wzrostu lub spadku wpływu skutków wraz ze zmianami w organizacji. Przebieg tego procesu można podzielić na siedem etapów.  Identyfikowanie możliwych zagrożeń i niebezpieczeństw, które generują ryzyko operacyjne dotyczące usługi.  Ocena każdego ryzyka z uwzględnieniem prawdopodobieństwa i skutków.  Kategoryzowanie prawdopodobieństwa i skutków zagrożeń.  Określanie mechanizmów kontrolnych służących do łagodzenia skutków lub zmniejszania prawdopodobieństwa zagrożeń.  Ustalanie priorytetów, czyli tego, którymi zagrożeniami trzeba się zająć w pierwszej kolejności.  Implementowanie mechanizmów kontrolnych i monitorowanie efektywności.  Powtarzanie procesu. Powtarzając ten proces, stosujesz podejście Kaizen, czyli ciągłe usprawnianie. Nigdzie nie jest ono tak ważne jak przy ocenie ryzyka, gdzie konieczne jest stopniowe modyfikowanie strategii. 41 Poleć książkęKup książkę Kwestie związane z ryzykiem Jest wiele zmiennych, które mogą wpływać na jakość procesu oceny ryzyka (http://www.au.af. mil/au/awc/awcgate/usmc/orm.pdf). Można je podzielić na następujące kategorie:  nieznane czynniki i złożoność,  dostępność zasobów,  czynniki ludzkie,  czynniki grupowe. Trzeba uwzględnić każdą z tych kategorii, aby zdefiniować realistyczny proces dla zespołu. Dlatego w kolejnych punktach omawiamy pokrótce każdą z nich. Nieznane czynniki i złożoność Czynnikiem zwiększającym trudność procesu oceny ryzyka jest złożoność współczesnych syste- mów. Im bardziej złożona i skomplikowana dziedzina, tym trudniej ludziom przenieść ich wiedzę na sytuacje, z którymi wcześniej się nie zetknęli. Tendencja do nadmiernego upraszczania zagad- nień, aby można było łatwo sobie z nimi poradzić, jest nazywana błędem redukcji. To, co sprawdza się na etapie początkowej nauki, nie działa w trakcie nabywania zaawansowanej wiedzy. Występuje wiele nieznanych zagrożeń, a liczne z nich pozostają poza naszą kontrolą. Oto kilka przykładów.  Wpływ innych klientów w środowiskach z hostingiem, takich jak rozwiązania Amazonu lub Google’a.  Wpływ dostawców narzędzi zintegrowanych z infrastrukturą.  Przesyłanie kodu przez inżynierów oprogramowania.  Działania marketingowe skutkujące skokami obciążenia roboczego.  Usługi na wcześniejszych i dalszych etapach przetwarzania.  Łatki, zmiany w repozytorium i inne stopniowo wprowadzane modyfikacje oprogramowania. W trakcie oceny zagrożeń w takich środowiskach pomocne jest rozwiązywanie problemów z danej dziedziny. Zespół ds. eksploatacji musi wykorzystać swoje grupowe doświadczenia i stale rozwijać wiedzę, aby tworzyć dokładniejsze modele na potrzeby planowania. Zespoły muszą też pogodzić się z tym, że nie da się uwzględnić wszystkich możliwości. Dlatego trzeba planować z myślą o nie- znanym, tworząc odporne systemy. Dostępność zasobów Jeśli pracowałeś kiedyś w dziale, gdzie brakowało zasobów, lub w niedoinwestowanym startupie, wiesz, że próby zdobycia zasobów na potrzeby bieżących, proaktywnych procesów bywają… no cóż, trudne (czytaj: to syzyfowa praca). Dlatego możliwe, że będziesz miał cztery godziny lub mo- że tylko 30 minut miesięcznie na zajęcie się procesami zarządzania ryzykiem. Dlatego musisz za- pewnić wartość. Cena Twojego czasu i zasobów, jakie wykorzystujesz do łagodzenia problemów, musi być niższa niż koszty niepodejmowania tych działań. Oznacza to, że musisz bezwzględnie ustalać priorytety na podstawie prawdopodobieństwa i wpływu zagrożeń oraz dostępnego czasu. Twórz odporne systemy i wyciągaj wnioski z zachodzących incydentów. 42  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę Czynnik ludzki Gdy ludzie zaczynają wykonywać zadania, może wystąpić wiele problemów (http://bit.ly/2zyoBmm). Jesteśmy genialni, ale w naszym podręczniku użytkownika znajduje się wiele rzeczy zapisanych małą czcionką. Oto kilka czynników, które mogą zakłócać procesy. Syndrom bierności Wiele osób zajmujących się eksploatacją pracuje pod kierownictwem menedżera lub razem z ludźmi bojącymi się ryzyka. Tacy ludzie cechują się inercją i wybierają bierność, ponieważ uważają, że zmiany niosą ze sobą większe ryzyko niż bezczynność. Ważne jest, aby w obliczu nieznanego przeprowadzić obliczenia, zamiast uciekać w bezczynność. Ignorowanie znanych zagrożeń Doświadczeni inżynierowie często ignorują znane zagrożenia, a koncentrują się na bardziej „egzotycznych” i rzadkich zdarzeniach. Przykładowo ktoś przyzwyczajony do radzenia sobie z przepełniającymi się dyskami może w większym stopniu koncentrować się na zdarzeniach z poziomu centrum danych i nie planować w odpowiedni sposób mechanizmów kontrolnych związanych z przestrzenią dyskową. Lęk Lęk — w zależności od osoby — można uznać zarówno za pozytywny, jak i za negatywny stresor. Niektórzy ludzie najlepiej funkcjonują w wysoce stresujących środowiskach, gdzie gra toczy się o wysoką stawkę, i wtedy dużo wnoszą w planowanie, łagodzenie skutków i pracę produkcyjną. Z kolei osoby przejawiające reakcje lękowe nieraz z powodu swoich obaw igno- rują najgorsze scenariusze. Może to prowadzić do braku przygotowania w obszarze istotnych, narażonych na duże ryzyko komponentów i systemów. Ważne, aby dostrzegać takie reakcje w zespole. Nadmierny optymizm Inną ludzką tendencją w kontekście oceny ryzyka jest nadmierny optymizm. Często myślimy o sobie i o innych osobach z zespołu w jak najlepszy sposób. Może to powodować, że oce- niamy sytuację przez pryzmat idealnych warunków — brak zmęczenia, nie rozpraszają nas inne incydenty, dostępni są młodsi pracownicy. Dotyczy to nie tylko ludzi, ale także zdarzeń. Czy pomyślałeś sobie kiedyś: „Nie ma możliwości, aby trzy dyski zawiodły tego samego dnia”, a później doświadczyłeś takiej sytuacji z powodu partii niesprawnych dysków? Trzeba też uwzględnić czynniki fizyczne (takie jak zmęczenie) zwiększające ryzyko, a także utrudnia- jące ręczne radzenie sobie z problemami („gaszenie pożarów”). Gdy analizujesz pracę ludzi (np. ręczne wprowadzanie zmian i badania) oraz nieodłączne od niej zagrożenia, musisz zakładać, że pracownicy odpowiedzialni za eksploatację zajmujący się poważnym problemem zostali właśnie obudzeni po ciężkim dniu pracy. Prawdopodobnie tak nie będzie, ale trzeba rozważyć taką ewentual- ność. Ponadto w trakcie projektowania mechanizmów kontrolnych na potrzeby łagodzenia lub eliminowania zagrożeń trzeba uwzględnić to, że osoba ręcznie rozwiązująca problem będzie bardzo zmęczona, a może nawet będzie musiała gasić wiele pożarów jednocześnie. Kwestie związane z ryzykiem  43 Poleć książkęKup książkę Zmęczenie wezwaniami Zmęczenie wezwaniami (ang. pager fatigue; http://bit.ly/2zyfqCv) następuje, gdy niepotrzebne lub zbyt częste wezwania skutkują znużeniem i przytłoczeniem. Powinieneś to uwzględnić, gdy decydujesz, ile alarmów (wymagających ręcznej reakcji i interwencji) zostanie wbudo- wanych w procesy monitorowania. Zmęczenie wezwaniami często wynika z fałszywych alarmów (dotyczących sytuacji, które nie są rzeczywistymi problemami; nieraz powodem tego są źle dobrane wartości progowe) lub ze stosowania alarmów zamiast ostrzeżeń dla trendów, które mogą stać się niebezpieczne w bliskiej przyszłości. Czynniki grupowe Podobnie jak u ludzi pojawiają się „ślepe punkty”, tak i grupy cechują się dynamiką, która zakłóca proces zarządzania ryzykiem. Oto niektóre czynniki, o których warto pamiętać. Polaryzacja grupy Polaryzacja grupy, którą można nazwać też przesunięciem punktu ryzyka, następuje, ponie- waż grupy zwykle podejmują bardziej skrajne decyzje niż pojedynczy ich członkowie. To zja- wisko często powoduje zmianę pierwotnych poglądów. Jeśli np. pojedyncze osoby początkowo były ostrożne, po osiągnięciu konsensusu stają się dużo bardziej odporne na ryzyko. Z kolei odporność na ryzyko może się przerodzić w jego unikanie. Poszczególne osoby często nie chcą okazać się najbardziej konserwatywne w środowisku grupy. Może to spowodować, że zespół będzie akceptował ryzyko w znacznie większym stopniu niż to wskazane. Przekazywanie ryzyka Grupy zwykle cechują się też większą akceptacją ryzyka, gdy mogą obarczyć nim inne zespo- ły. Jeśli np. opracowuję plany dla zespołu ds. eksploatacji, mogę podejmować większe ryzyko, gdy wiem, że mam w odwodzie zespół ds. baz danych. W rozwiązaniu tego problemu pomaga budowanie poczucia odpowiedzialności i praca w wielofunkcyjnych zespołach, które nie mogą obarczać ryzykiem innych. Przekazywanie podejmowania decyzji Przekazywanie podejmowania decyzji może zachodzić, gdy zespoły przeszacowują ryzyko, aby można było przenieść na innych odpowiedzialność za konkretne wybory. Jeśli np. bardzo ryzykowne zmiany wymagają zgody CTO, który bierze tym samym odpowiedzialność za nie, ludzie mają tendencję do zawyżania ryzyka, co pozwala im przekazać odpowiedzialność za decyzję w górę hierarchii. Ten problem można ograniczyć, tworząc bardziej autonomiczne zespoły, polegające na wiedzy eksperckiej i doświadczeniu jednostek oraz zespołów zamiast na hierarchicznych procesach zatwierdzania decyzji. Co możemy zrobić? Faktem jest to, że proces zarządzania ryzykiem może stać się nadmiernie obciążający. Nawet wte- dy, gdy zaangażowano dużo zasobów, zespoły nie są w stanie uwzględnić wszystkich zagrożeń, które mogą wpływać na dostępność, wydajność, stabilność i bezpieczeństwo. Dlatego sensowne jest opracowanie iteracyjnego procesu usprawnianego wraz z czasem. Dążenie do zapewnienia od- porności na zagrożenia zamiast eliminowania ich wszystkich pozwala też w inteligentny sposób podejmować ryzyko w celu zapewnienia innowacji i usprawnień. 44  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę Naszym zdaniem cel polegający na wyeliminowaniu wszystkich zagrożeń nie jest właściwy. Systemy bez stresorów zwykle nie są wzmacniane i usprawniane. Ostatecznie stają się wrażliwe na niezna- ne i niezaplanowane czynniki. Systemy, które regularnie doświadczają stresorów i dlatego zostały zaprojektowane z myślą o odporności, zwykle łatwiej radzą sobie z nieznanymi zagrożeniami. Zdaniem niektórych w systemach należy „wykorzystywać budżet przestojów”, jak jest to określa- ne w Google’u, i ryzykować w sytuacjach, gdzie można uzyskać znaczne korzyści przy akcepto- walnym poziomie ryzyka. W Google’u jeśli budżet wynosi 30 minut przestojów na kwartał i nie został wykorzystany, zespół jest gotów podejmować większe ryzyko, aby udostępnić nowe funkcje, usprawnienia i dodatki. Jest to doskonały sposób na wykorzystanie całego budżetu na innowacje zamiast stosowania podejścia zupełnie pozbawionego ryzyka. Jak przełożyć to na praktyczny proces oceny ryzyka? Zacznijmy od tego, czego nie robić! Czego nie robić? Trzeba pamiętać o wielu kwestiach. Oto kilka ostatnich wskazówek, które należy rozważyć w pro- cesie zarządzania ryzykiem.  Nie pozwól na to, by subiektywne przekonania zaszkodziły procesowi.  Nie pozwól na to, by historyjki i plotki były głównym źródłem oceny ryzyka.  Nie koncentruj się wyłącznie na dawnych incydentach i problemach. Patrz w przyszłość.  Nie popadaj w stagnację. Analizuj wcześniejsze dokonania.  Nie ignoruj czynnika ludzkiego.  Nie ignoruj zmian w architekturze i przepływie pracy.  Nie zakładaj, że obecne środowisko jest takie samo jak wcześniejsze.  Nie twórz delikatnych mechanizmów kontrolnych i nie ignoruj najgorszych scenariuszy. Jesteśmy przekonane, że z czasem dodasz do tej listy nowe pozycje. Jest to jednak dobry wykaz, o któ- rym warto pamiętać, aby uniknąć pułapek, jakie czekają na Ciebie w trakcie analizowania systemów. Funkcjonujący proces — uruchamianie Niezależnie od tego, czy proces ma dotyczyć nowej, czy odziedziczonej usługi, zaczyna się od po- czątkowego uruchomienia. W trakcie uruchamiania procesu (zob. rysunek 3.1) celem jest ziden- tyfikowanie głównych niebezpieczeństw, które mogą zagrozić spełnieniu celów SLO stawianych usłudze i których wystąpienie jest najbardziej prawdopodobne. Ponadto należy uwzględnić najgorsze scenariusze, które mogą zagrozić powodzeniu usługi w dłuższej perspektywie. Pamiętaj, dzielny inżynierze baz danych, że celem nie jest tu próba opracowania kompletnego spisu zagrożeń. Za- danie polega na utworzeniu listy wstępnej na potrzeby łagodzenia i eliminowania problemów oraz planowania tego, jak — operacyjnie — zapewnić największą wartość za pomocą dostępnych obecnie zasobów. Funkcjonujący proces — uruchamianie  45 Poleć książkęKup książkę Rysunek 3.1. Początkowe uruchamianie procesu zarządzania ryzykiem Ocena ryzyka dla usługi Mając listę usług i mikrousług, którymi się opiekujesz, powinieneś usiąść z właścicielami produktu i ocenić tolerancję ryzyka dla każdej z nich. Oto pytania, na które warto odpowiedzieć.  Jakie cele SLO z zakresu dostępności i opóźnienia są zdefiniowane dla danej usługi, gdy:  wszyscy użytkownicy są dotknięci;  dotknięty jest podzbiór użytkowników; 46  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę  usługa działa w trybie awaryjnym (tylko do odczytu, z wyłączonymi niektórymi funkcjami itd.);  wydajność usługi jest obniżona.  Jaki jest koszt przestoju danej usługi?  Utrata przychodów?  Utrzymanie klientów?  Usługa jest płatna czy darmowa?  Czy działa konkurencja, do której klient może łatwo przejść?  Czy przestoje mają skutki, które mogą wpłynąć na całą firmę?  Utrata danych?  Naruszenie prywatności?  Przestój w trakcie jakiegoś wydarzenia lub dni wolnych od pracy?  Przedłużający się przestój? Przyjrzyjmy się przykładowi. UberPony to firma udostępniająca kucyki na żądanie. W jej serwisie działa sześć usług. 1. Rejestrowanie nowego klienta. 2. Składanie i realizacja zamówień kucyków na żądanie. 3. Rejestrowanie opiekunów kucyków. 4. Logistyka dla opiekunów kucyków. 5. Obsługa płatności dla opiekunów kucyków. 6. Wewnętrzne mechanizmy analityczne. Przyjrzyjmy się teraz dwóm usługom — rejestrowaniu nowych klientów oraz składaniu i realizacji zamówień. UberPony — rejestrowanie klientów Cel SLO — dostępność Cel SLO — opóźnienie Nowi klienci dziennie Cel SLO — dozwolone błędy Koszt infrastruktury dziennie Koszt infrastruktury na złotówkę przychodów Wartość życiowa klienta Wartość życiowa dziennie Szczytowa liczba klientów na minutę Odsetek klientów rezygnujących po błędzie Szczytowy poziom utraty wartości na minutę 99,90 1 sekunda 5000 5 13 698 zł 0,003 zł 1 000 zł 5 000 000 zł 100 60 60 000 zł Funkcjonujący proces — uruchamianie  47 Poleć książkęKup książkę UberPony — składanie i realizacja zamówień Cel SLO — dostępność Cel SLO — opóźnienie Liczba zamówień dziennie obecnie Cel SLO — dozwolone błędy Koszt infrastruktury dziennie Koszt infrastruktury na złotówkę przychodów Przychód na zamówienie Przychód dzienny Szczytowa liczba zamówień na minutę Odsetek rezygnacji z zamówienia po błędzie Odsetek utraconych klientów po błędzie Szczytowa utrata przychodów na minutę Utrata wartości generowanej przez klienta na minutę Łączna utrata na minutę 99,90 1 sekunda 500 000 500 30 000 zł 0,006 zł 10 zł 5 000 000 zł 1000 25 1 2500 zł 10 000 zł 12 500 zł Wygląda więc na to, że usługa rejestrowania klientów może kosztować aż do 4,8 razy więcej przycho- dów na minutę niż usługa składania i realizacji zamówień. 75 klientów ponowi zamówienie, jednak tylko 40 wróci, jeśli nie będzie mogło się zarejestrować. Najwyraźniej chętnie skorzystają z usługi UberDonkey. Zauważ, że próbowaliśmy uwzględnić zmienne, takie jak utrata klientów po błędzie w trakcie składania zamówienia, a także odsetek ponawianych prób rejestracji i złożenia zamówienia po wystąpieniu problemu. Ustalenie tych wartości bez solidnych danych analitycznych może być trudne, jeśli jednak takie informacje są niedostępne, wystarczające mogą być szacunki. Lepsze to niż nic. Dane się zmieniają, dlatego koniecznie aktualizuj dane, gdy stosujesz opisany proces. Jeśli np. firma UberDonkey stanie się bardziej konkurencyjna i UberPony zacznie tracić 5 klientów po błędzie w czasie składania zamówienia, koszty minuty przestoju w usłudze składania i realizacji za- mówień nagle wzrosną do 52 500 zł. To zdecydowanie zwiększy priorytet tej usługi. Jednak obecnie znacznie sensowniejsze jest skupienie się na usłudze rejestrowania klientów. Spis architektury Po zdefiniowaniu zakresu prac należy spisać systemy i środowiska, za które odpowiadasz. Uwzględnij:  centra danych;  komponenty i warstwy architektury (np. MySQL, równoważniki obciążenia Nginx, instancje aplikacji J2EE, sieć, zapory, Hadoop/HDFS, sieć CDN);  role przydzielone tym komponentom (np. węzeł zapisujący/główny, replika);  ścieżki interakcji i komunikacji między usługami (zapytania z aplikacji do bazy MySQL czy z równoważnika obciążenia do aplikacji, przesyłanie danych przez aplikację do bazy Redis);  zadania (proces pobierania, przekształcania i wczytywania, ang. extract, transform, load — ETL, wczytywanie danych z sieci CDN, odświeżanie pamięci podręcznej, zarządzanie konfiguracją, koordynacja, tworzenie kopii zapasowych i odzyskiwanie danych, agregacja dzienników). 48  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę Oto uproszczony spis dotyczący priorytetowej usługi. UberPony — rejestrowanie klientów Komponent Równoważniki obciążenia frontonu Serwery WWW Równoważniki obciążenia dla Javy Serwery Javy Serwery pośredniczące bazy danych Sieć CDN CloudFront Serwery z pamięcią podręczną bazy Redis Serwery zapisujące klastra z bazą MySQL Serwery odczytujące klastra z bazą MySQL Replikacja bazy MySQL Odświeżanie zawartości sieci CDN Odświeżanie pamięci podręcznej bazy Redis Tworzenie kopii zapasowych bazy MySQL Proces ETL Hurtownia danych RedShift Liczba w centrum danych 1 2 20 2 10 2 Usługa 4 1 2 Usługa Zadanie Zadanie Zadanie Zadanie Usługa Liczba w centrum danych 2 2 20 2 10 2 Usługa 4 1 2 Usługa Zadanie Zadanie Brak Brak Brak Następny krok polega na ocenie w tej architekturze zagrożeń, które mogą wpływać na usługę. Priorytety Jak zidentyfikować zagrożenia, które mogą spowodować naruszenie celów SLO, i ustalić priory- tety tych niebezpieczeństw? W ramach zarządzania ryzykiem zagrożenia są definiowane w kate- goriach prawdopodobieństwa spowodowania niekorzystnych skutków przez dany problem pomno- żonego przez konsekwencje danej sytuacji. W tabeli poniżej pokazano spektrum możliwości. Prawdopodobieństwo/ skutki Prawie pewne Prawdopodobne Możliwe Mało prawdopodobne Rzadkie Poważne Bardzo poważne Nieakceptowalne Nieakceptowalne Wysokie Nieakceptowalne Wysokie Wysokie Wysokie Umiarkowane Niewielkie Pomijalne Nieakceptowalne Wysokie Wysokie Umiarkowane Umiarkowane Akceptowalne Umiarkowane Umiarkowane Umiarkowane Umiarkowane Umiarkowane Akceptowalne Akceptowalne Akceptowalne Akceptowalne Akceptowalne Akceptowalne Akceptowalne W celu wyeliminowania niejasności ważne jest, aby liczbowo określić poziomy prawdopodobień- stwa i skutków. Skutki zmieniają się w zależności od dziedziny problemu. Niejasności w kwestii prawdopodobieństwa zostały dobrze opisane w artykule Describing probability: The limitations of natural language (http://www.risk-doctor.com/pdf-files/emeamay05.pdf). Ustalmy poziomy prawdopodobieństwa w następujący sposób. Funkcjonujący proces — uruchamianie  49 Poleć książkęKup książkę Skala Prawie pewne Prawdopodobne Możliwe Mało prawdopodobne Rzadkie Przedział 50 26 – 50 11 – 25 5 – 10 5 Uznajmy, że jest to procent czasu naruszania celów SLO w danym okresie, np. tygodniowym. Jeśli chodzi o skutki, to uwzględniamy cele SLO w ramach określania ich kategorii, a także w trakcie analizy innych problemów, które grożą upadkiem firmy (są to np. uszkodzenie danych, naruszenie prywatności i incydenty związane z bezpieczeństwem). Większość takich problemów należy do ka- tegorii bardzo poważne lub poważne. Warto przypomnieć, że tu przedstawiamy tylko przykłady. Bardzo poważne skutki (natychmiastowe naruszenie celu SLO) Oto definicja bardzo poważnych skutków.  Cała usługa staje się niedostępna lub działa z opóźnieniem powyżej 100 milisekund przez przynajmniej 10 minut dla 5 lub więcej użytkowników. W tygodniu jest 10 080 minut, dlatego 10 minut przestoju narusza cel SLO mówiący o 99,9 dostępności.  Zbliżające się lub mające już miejsce ujawnienie danych jednych klientów innym.  Pozwolenie nieupoważnionym osobom na dostęp do systemów i (lub) danych produkcyjnych.  Uszkodzenie danych transakcyjnych. Każdy z tych punktów oznacza przypisanie problemów do kategorii bardzo poważne. Poważne (zbliżające się naruszenie celów SLO) Oto cechy poważnych skutków.  Cała usługa jest niedostępna lub działa z opóźnieniem powyżej 100 milisekund przez trzy do pięciu minut dla przynajmniej 5 użytkowników (aż do zużycia 50 budżetu niedostępności).  Spadek wydajności systemu do 100 wymaganej (z docelowych 200 ). Każdy z tych punktów oznacza przypisanie problemów do kategorii poważne. Umiarkowane (może skutkować naruszeniem celów SLO, jeśli w tym samym okresie wystąpią też inne incydenty) Oto cechy umiarkowanych skutków.  Cała usługa jest niedostępna lub działa z opóźnieniem powyżej 100 milisekund przez minutę do trzech minut dla przynajmniej 5 użytkowników (aż do zużycia 33 budżetu niedostępności).  Spadek wydajności systemu do 125 wymaganej (z docelowych 200 ). Każdy z tych punktów oznacza przypisanie problemów do kategorii umiarkowane. 50  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę Niewielkie Oto cechy niewielkich skutków.  Cała usługa jest niedostępna lub działa z opóźnieniem powyżej 100 milisekund przez okres do minuty dla przynajmniej 5 użytkowników (aż do zużycia 10 budżetu niedostępności).  Spadek wydajności systemu do 150 wymaganej (z docelowych 200 ). Każdy z tych punktów oznacza przypisanie problemów do kategorii niewielkie. Warto przypomnieć, że nie próbujemy uwzględnić każdego możliwego zagrożenia. Ten spis będzie stale rozwijany w wyniku zarządzania incydentami i procesów zarządzania ryzykiem. Tworzymy tu tylko schemat o ograniczonym zakresie, aby zapewnić podstawy do pragmatycznych działań. W tym scenariuszu budujemy schemat na podstawie scenariuszy, które są najbardziej prawdopodobne i mają najpoważniejsze skutki. Wiemy np., że awarie komponentów i instancji są częste w publicznych chmurach, takich jak ta, której firma UberPony używa do hostingu. Oznacza to, że występuje w nich niski średni czas między awariami (MTBF). Dla grup instancji serwerów WWW i Javy kategoryzujemy takie awa- rie jako „prawdopodobne”, ponieważ cały czas korzystamy z umiarkowanej liczby takich instancji (20 lub 10). Oznacza to, że awaria jednej instancji serwera WWW dotyka 5 klientów. Z kolei awaria instancji Javy wpływa na 10 klientów. Wynikiem jest naruszenie celów SLO, a ponieważ uruchomienie nowej instancji może zająć od trzech do pięciu minut, skutki są poważne. Dla prawdo- podobieństwa na poziomie prawdopodobne i skutków na poziomie poważne ryzyko jest wysokie. Po wprowadzeniu zautomatyzowanych działań naprawczych (wycofywania danej instancji z usługi i uruchamiania nowej) przeprowadzamy testy i okazuje się, że ten proces zajmuje średnio pięć sekund. Poziom skutków zmienia się wtedy na niewielkie, a tym samym kategoria ryzyka ulega zmianie na umiarkowane. Jeśli przeanalizujesz awarie na poziomie usługi lub instancji na podstawie spisu, możesz uzyskać następującą listę. UberPony — usługa rejestrowania klientów Komponent Równoważniki obciążenia frontonu Serwery WWW Równoważniki obciążenia dla Javy Serwery Javy Serwery pośredniczące bazy danych Sieć CDN CloudFront Serwery z pamięcią podręczną bazy Redis Serwery zapisujące klastra z bazą MySQL Serwery odczytujące klastra z bazą MySQL Replikacja bazy MySQL Odświeżanie zawartości sieci CDN Odświeżanie pamięci podręcznej bazy Redis Tworzenie kopii zapasowych bazy MySQL Proces ETL Hurtownia danych RedShift Prawdopodobieństwo Możliwe Prawdopodobne Możliwe Prawdopodobne Możliwe Rzadkie Możliwe Mało prawdopodobne Możliwe Możliwe Mało prawdopodobne Mało prawdopodobne Mało prawdopodobne Mało prawdopodobne Rzadkie Skutki Bardzo poważne Poważne Poważne Poważne Poważne Poważne Poważne Bardzo poważne Poważne Poważne Niewielkie Niewielkie Niewielkie Niewielkie Niewielkie Ryzyko Nieakceptowalne Wysokie Wysokie Wysokie Wysokie Umiarkowane Umiarkowane Wysokie Wysokie Wysokie Akceptowalne Akceptowalne Akceptowalne Akceptowalne Akceptowalne Funkcjonujący proces — uruchamianie  51 Poleć książkęKup książkę Na podstawie takiego schematu należy w pierwszej kolejności dokładniej zająć się wszystkimi kom- ponentami z ryzykiem z poziomu nieakceptowalne i wysokie, potem przejść do komponentów o umiarkowanym ryzyku itd. Po omówieniu podstaw eksploatacji, w punkcie poświęconym bazom danych, przeprowadzimy szczegółową analizę ryzyka dla baz danych. Tu celem jest ułatwienie zro- zumienia procesu. Inna uwaga dotyczy tego, że trzeba też uwzględnić zagrożenia z poziomu całego centrum danych. Choć takie problemy są rzadkie, należą do tej samej kategorii, co naruszenie pry- watności, utrata danych i inne niebezpieczeństwa wymagające przemyślenia z powodu skutków mo- gących zagrozić przetrwaniu firmy. Mechanizmy kontrolne i podejmowanie decyzji Po określeniu priorytetów na podstawie listy analizowanych zagrożeń przyjrzymy się technikom decydowania o mechanizmach kontrolnych pozwalających łagodzić, a czasem nawet eliminować niebezpieczeństwa. Zaczęłyśmy omawianie tego tematu już w poprzednim punkcie, wprowadzając automatyczne zastępowanie serwerów WWW i Javy, aby skrócić średni czas do przywrócenia stanu (MTTR) po awarii. Pamiętaj, że koncentrujemy się na błyskawicznym przywracaniu stanu i skraca- niu MTTR, a nie na unikaniu awarii. Ważniejsza jest odporność niż krucha wysoka dostępność! Dlaczego przedkładamy MTTR nad MTBF? Gdy tworzysz system, który rzadko się psuje, będzie on z natury kruchy. Czy zespół będzie gotowy do naprawy systemu po awarii? Czy w ogóle będzie wiedział, co ma robić? W syste- mach, w których awarie są częste, ale kontrolowane i naprawiane w taki sposób, by ich skut- ki były pomijane, wiadomo, co zrobić, gdy coś się zepsuje. Procesy są dobrze udokumento- wane i pielęgnowane, a zautomatyzowane działania naprawcze stają się przydatne, zamiast ukrywać się w mrocznych zakamarkach systemu. Dla każdego możliwego zagrożenia zespół może wybrać jedno z trzech podejść:  unikanie (znalezienie sposobu na wyeliminowanie zagrożenia);  ograniczanie skutków (ustalenie, jak zmniejszyć wpływ problemu, gdy już wystąpi);  akceptacja (uznanie zagrożenia za akceptowalne i odpowiednie zaplanowanie reakcji na nie). W technicznym sensie w kręgach specjalistów od zarządzania ryzykiem istnieje też czwarte podejście — podział ryzyka za pomocą outsourcingu, wykupienia ubezpieczenia lub innych metod przeniesie- nia ciężaru na kogoś innego. Żadna z tych metod nie ma jednak zastosowania do ryzyka w branży informatycznej, dlatego nie będziemy tu analizować tego podejścia. Każdy komponent należy przeanalizować pod kątem rodzajów awarii, ich skutków i zestawu mecha- nizmów kontrolnych pozwalających na automatyczne przywracanie stanu, skrócenie czasu przywra- cania stanu i zmniejszenie częstotliwości występowania problemu. Określane są też koszty i wysiłek związane z tymi mechanizmami. W wyniku ich porównania z kosztami przestoju można podjąć decyzje dotyczące właściwego sposobu radzenia sobie z zagrożeniami. Identyfikowanie W trakcie analizy ryzyka w firmie UberPony zidentyfikowaliśmy kilka warstw usług bazodano- wych MySQL cechujących się wysokim ryzykiem. Jest to bardzo typowe w warstwie bazy danych. 52  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę Zobaczmy teraz, co można zrobić, aby ograniczyć to ryzyko. W usłudze wykryliśmy cztery główne rodzaje awarii:  awaria instancji zapisującej,  awaria instancji wczytującej,  awaria replikacji,  awaria tworzenia kopii zapasowych. Są to rodzaje awarii często występujące w magazynach danych. Ocena Jeśli chodzi o awarie zapisu, zespół ds. eksploatacji w UberPony ocenia możliwości automatyzacji przywracania stanu po awarii serwera zapisującego bazy MySQL. Po wystąpieniu takiej awarii usługa rejestrowania klientów nie może tworzyć ani modyfikować żadnych danych. To oznacza brak nowych klientów i brak możliwości modyfikowania ich danych przez nich samych lub przez firmę. Stwierdziliśmy, że jeśli usługa rejestrowania przestanie działać przy szczytowym obciążeniu, możemy tracić 60 000 zł wartości życiowej klienta na minutę. Dlatego bardzo ważne jest rozwiązanie tego problemu. Oznacza to, że akceptacja ryzyka nie wchodzi w grę. Łagodzenie skutków i mechanizmy kontrolne Gotowe są już pewne mechanizmy eliminowania ryzyka. Używany jest 10-dyskowy system RAID, który zapewnia nadmiarowe dyski. Dlatego awaria dysku nie prowadzi do awarii bazy. W środowisku występują też inne podobne nadmiarowe komponenty. Inna proponowana technika eliminowania to zastąpienie podstawowego silnika MySQL-a narzędziem Galera, którego architektura umożliwia zapis danych w dowolnym węźle klastra bazy MySQL. To wymaga znacznych zmian architektury, a nikt w zespole nie ma dużego doświadczenia w korzystaniu z Galery. Po zastanowieniu okazuje się, że zagrożenia powodowane przez nowy system zdają się przeważać nad korzyściami z jego wprowadzenia. Gdyby odpowiednio zaprojektować aplikację, klienci nadal mogliby logować się do usługi i wyświe- tlać dane z instancji odczytujących. Na tym polega łagodzenie skutków zagrożeń. Po rozmowie z in- żynierami oprogramowania okazuje się, że planują wprowadzić takie rozwiązanie. Jednak w trybie awaryjnym nowi klienci i tak nie mogą się rejestrować, dlatego ten mechanizm nie zapewnia fir- mie istotnych korzyści (rezygnacja z rozwijania nowych funkcji to poważny koszt na konkuren- cyjnym rynku). Ostatecznie zespół decyduje się zastosować automatyczne działania naprawcze. Tu polegają one na automatycznym przełączaniu awaryjnym na inny serwer główny. Zespół wybiera przełączanie awaryjne zamiast ręcznego, ponieważ 10 minut przestojów dopuszczalne w celach SLO nie wystarcza, aby człowiek zdążył wykonać odpowiednie czynności. W trakcie zarządzania zapisem może nastąpić utrata danych, dlatego proces musi działać bezbłędnie. Implementacja Zespół decyduje się zastosować technologię MySQL MHA do automatycznego przełączania awa- ryjnego. MySQL MHA (ang. MySQL High Availability) to oprogramowanie do zarządzania przełą- Funkcjonujący proces — uruchamianie  53 Poleć książkęKup książkę czaniem awaryjnym i wprowadzania zmian w topologii replikacji potrzebnych w wyniku takiego przełączania. Zespół opracowuje plan dokładnych testów przed zaimplementowaniem tak waż- nego procesu. Testy są wykonywane etapowo — początkowo w środowisku testowym bez ruchu, potem w środowisku testowym z symulowanym ruchem, a ostatecznie w środowisku produkcyjnym, gdzie są ściśle monitorowane. Testy są przeprowadzane wielokrotnie, aby mieć pewność, że dany wynik nie jest wyjątkiem. Oto, co obejmują testy.  Kontrolowane zamykanie głównej bazy danych w środowisku testowym.  Zamykanie procesu MySQL w środowisku testowym.  Zamykanie w środowisku testowym instancji serwera, na którym działa MySQL.  Symulowanie podziału sieci. Po każdym teście zespół wykonuje następujące czynności.  Rejestrowanie czasu, jaki zajęło przełączanie awaryjne.  Rejestrowanie opóźnienia dla symulowanego i produkcyjnego ruchu, aby ocenić wpływ procesu na wydajność.  Upewnianie się, że tabele nie zostały uszkodzone.  Upewnianie się, że dane nie zostały utracone.  Sprawdzanie dzienników błędów u klientów, aby zobaczyć wpływ procesu. Gdy zespół jest usatysfakcjonowany tym, że system działa i spełnia cele SLO, zastanawia się, jak włączyć nowy proces w inne standardowe czynności. Wymaga to upewnienia się, że proces jest do- brze przećwiczony, udokumentowany i wolny od błędów. Zespół początkowo decyduje się powiązać nowe działania z procesem wdrażania i wykorzystać przełączanie awaryjne do wprowadzania stop- niowych zmian w obiektach bazodanowych, aby nie zakłócać jednowątkowego procesu replikacji baz MySQL. Gdy zespół kończy pracę, przełączanie awaryjne zajmuje nie więcej niż 30 sekund. W trakcie sprawdzania procesu przełączania awaryjnego inżynierowie oprogramowania odkryli też, że w czasie 30 sekund, jakie zajmuje to zadanie, może nastąpić utrata danych. Dlatego zespół wprowadza podwójny zapis w aplikacjach. Oznacza to, że wszystkie operacje wstawiania, aktualizacji i usuwania danych są kierowane do brokera zdarzeń na wypadek, gdyby trzeba było je odtworzyć. Są to dodatkowe działania łagodzące skutki przełączania awaryjnego głównego serwera zapisującego. Te mechanizmy kontrolne tworzy się na potrzeby wstępnego uruchamiania programu. Ważne jest, by pamiętać, że nie muszą być idealne. Jest to tylko początkowy zestaw mechanizmów, powiąza- nych z najbardziej priorytetowymi kwestiami i generujących największą wartość. Opracowanie początkowej wersji procesu oznacza, że przeszedłeś już długą drogę w kierunku uwzględnienia najczęstszych źródeł ryzyka. Od tego momentu prace przebiegają iteracyjnie. Bieżące iteracje Gdy początkowy proces jest już gotowy, priorytetem w zakresie eliminowania i łagodzenia skut- ków zagrożeń staje się związany z architekturą potok projektowania, budowania i bieżącej eksplo- atacji rozwiązań. Wspomniałyśmy wcześniej, że zarządzanie ryzykiem to proces ciągły. Nie trzeba 54  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę więc od razu uwzględniać wszystkiego, ponieważ realizowane procesy pozwalają rozbudować listę zagrożeń i zapewnić lepsze pokrycie systemu, co ilustruje rysunek 3.2. Oto te procesy.  Przeglądy dostarczania usługi.  Zarządzanie incydentami.  Potok architektoniczny. Rysunek 3.2. Stale powtarzający się cykl i dane wejściowe w procesie zarządzania ryzykiem Przeglądy dostarczania usługi to okresowe analizy ewolucji usługi z naciskiem na zmiany w tole- rancji ryzyka, przychodach, kosztach skutków i bazy użytkowników. Gdy te aspekty znacznie się zmieniają, trzeba ponownie przyjrzeć się wcześniejszym poziomom akceptacji ryzyka, działaniom naprawczym i technikom eliminowania zagrożeń, aby mieć pewność, że nadal są one akceptowalne. Procesy zarządzania incydentami zapewniają dane wejściowe do określania priorytetów. Gdy analiza zdarzenia ujawnia nowe luki, trzeba się im przyjrzeć i uwzględnić je na liście priorytetów. Ponadto w ramach budowania potoku architektonicznego trzeba wprowadzić do procesu zarządzania ryzy- kiem nowe komponenty, aby zidentyfikować zagrożenia, które mogły zostać pominięte na etapie projektowania. Bieżące iteracje  55 Poleć książkęKup książkę Podsumowanie Poznałeś już znaczenie włączania zarządzania ryzykiem w codzienne procesy informatyczne. Za- poznałeś się też z różnymi zagadnieniami i czynnikami, które mogą wpływać na proces zarządzania ryzykiem, oraz przeanalizowałeś realistyczny model uruchamiania zarządzania ryzykiem w połą- czeniu z codziennymi procesami, co pozwala z czasem stopniowo rozwijać ten proces. Jednak nawet po zrozumieniu zobowiązań związanych z poziomem jakości usług i potencjalnych zagrożeń w ich realizacji brakuje bardzo istotnego elementu, czyli monitorowania operacyjnego. Wgląd w obecną sytuację, a także wiedza na temat wcześniejszej wydajności i charakterystyki syste- mu będą potrzebne, aby zapobiegać problemom i podejmować decyzje związane z tym, jak stale usprawniać system, którym zarządzasz. 56  Rozdział 3. Zarządzanie ryzykiem Poleć książkęKup książkę Skorowidz połączenia, 175 przechowywanie danych, 176 bezpieczne blokady, 82 błędy, 78 aplikacji, 123, 127 sprzętu, 124, 127 systemu operacyjnego, 124, 127 użytkownika, 58, 123, 126 cele SLO, 29 monitorowanie, 35 chmura, 76 CQRS, 239 czas odpowiedzi, 27 C D dane biznesowe, 173 finansowe, 172 o zdrowiu pacjentów, 172 osobowe, 172 w bazie, 177 w systemie plików, 179 wojskowe lub rządowe, 173 wyjściowe, 64, 67 DBA, database administrator, 18 DBaaS, 101 DBRE, database reliability engineer, 15 definiowanie celów SLO, 29 infrastruktury, 109 konfiguracji, 104 deterministyczne transakcje, 194 A administrator baz danych, 242 algorytmy szyfrujące, 174 analiza kodu, 73 skutków, 150 architektura danych, 227, 235 Kappa, 237 Lambda, 236 NUMA, 91 RAID, 96 SMP, 90 asercje, 84 atak DoS, 166 atomowość, 216 automatyczne przełączanie awaryjne, 53 szyfrowanie bazy danych, 178 awarie centrów danych, 124 sprzętu, 124 B BASE, 220 baza danych jako usługa, 100 MySQL, 91 wewnętrzne monitorowanie, 79 zdarzenia, 84 b-drzewa, 185, 190 bezawaryjność, 32 bezpieczeństwo, 21, 157 danych, 69 na poziomie aplikacji, 177 249 Poleć książkęKup książkę dobór wskaźników, 62 dostęp niejednolity do pamięci, 90 dostępność, 27, 32, 201, 223, 230–233 monitorowanie, 36 pamięci masowej, 96 zasobów, 42 dozwolony przestój, 33 DREAD, 164 drzewo binarne, 186 LSM, 187 dziedzina działania organizacji, 139 dzienniki, 66, 73, 75, 190 oparte na instrukcjach, 193 replikacji, 193 WAL, 193 edukacja, 137, 159 eksploatacja, 19, 20 eksploity, 163 ETL, 121 Event Sourcing, 238 filtry Blooma, 188 fragmentacja, 89 hierarchia potrzeb, 20 hipernadzorca, 99 hosty, 87 E F H I indeksowanie, 189 indeksy bitmapowe, 190 z haszowaniem, 189 infrastruktura, 87 definiowanie, 109 inżynieria, 87 koordynowanie, 109 projektowanie, 246 wdrażanie, 246 zarządzanie, 103 250  Skorowidz instrumentacja aplikacji, 71 instancji, 74 magazynu danych, 76 serwera, 74 systemu operacyjnego, 163 warstwy aplikacji, 162 warstwy bazy danych, 162 integracja, 142 integralność danych, 230, 232, 234, 248 inżynier niezawodności, 15 uzasadnienie zatrudniania, 241 zasady, 16 inżynieria infrastruktury, 87 iteracje, 54 izolacja, 217 jakość usług, 25 jądro systemu, 88 J K katalog usług, 112 klastry produkcyjne, 121 klucze sesji, 176 komponenty architektoniczne, 227 bazy danych, 68 komunikacja poza siecią, 175 w ramach sieci, 175 konfiguracja, 104, 106 budowanie, 106 konserwacja, 107 wymuszanie zgodności, 108 konserwacja konfiguracji, 107 kontenery, 100 kopie fizyczne, 118 logiczne, 118 pełne, 119 przyrostowe, 119 różnicowe, 119 w trybie online i offline, 118 zapasowe, 117 fizyczne przyrostowe, 130 pełne fizyczne, 129 Poleć książkęKup książkę pełne logiczne, 130 przyrostowe logiczne, 130 koszty i ekonomiczność, 39 kronikowanie, 80 kultura niezawodności baz danych, 242 luki, 163 L M magazyn danych, 76 BASE, 220 cechy koncepcyjne, 211 cechy wewnętrzne, 221 frontonu, 227 połączenia, 76 transakcje, 215 w pamięci RAM, 232 w trybie offline, 128, 133 w trybie online, 128, 131, 132 magazyny obiektowe, 130 mechanizmy eliminowania ryzyka, 53 migracje, 150 w środowisku produkcyjnym, 245 model ACID, 215 danych, 212 DBaaS, 101 oparty na dokumentach, 214 oparty na nawigacji, 214 relacyjny, 212 replikacji, 192 z parami klucz-wartość, 213 monitorowanie celów SLO, 35 dostępności, 36 kosztów i ekonomiczności, 39 operacyjne, 57, 59, 63, 162 opóźnienia, 38 przepustowości, 39 replikacji z jednym liderem, 199 tradycyjne, 58 uruchamianie, 67 wewnętrzne bazy danych, 79 zdarzeń, 169 N nasycenie, 77 NUMA, non-uniform memory access, 91 O obciążenie robocze, 62 obiekty bazodanowe, 83 ocena ryzyka dla usługi, 46 ochrona danych, 16 jako zadanie, 159 przed celowymi szkodami, 158 przed kradzieżą, 157 przed przypadkowymi uszkodzeniami, 158 przed ujawnieniem, 158 odporność, 32 na rozpad, 223 ograniczanie obciążenia, 168 zasobów, 88 operacje wejścia-wyjścia, 88 opóźnienie, 27, 29, 79, 224, 230, 232, 235 monitorowanie, 38 pamięci masowej, 95 replikacji, 199 średnie, 30 oprogramowanie, 19 optymalizowanie obciążenia roboczego, 169 P pamięć masowa, 93, 99 dostępność, 96 opóźnienie, 95 pojemność, 94 przepustowość, 94 nietrwała, 16 obiektowa, 129, 134 podręczna, 232 platforma monitorowania operacyjnego, 63 pliki SST, 187 pobieranie danych, 90 podejmowanie decyzji, 52, 247 podział definicji według usług, 110 według warstw, 111 Skorowidz  251 Poleć książkęKup książkę pojemność pamięci masowej, 94 połączenia z magazynem danych, 76 ponawianie operacji, 80 pośredniki baz danych, 229 poziom jakości usług, 25 wykorzystania zasobów, 77, 81 proces ręczny, 154 zautomatyzowany, 154 procesy potokowe, 121 produkcyjne magazyny danych, 16 protokoły sieciowe, 171 uwierzytelniania, 171 protokół NTP, 101 SSL, 177 przechowywanie danych, 221 struktur danych, 183 surowych danych, 184 przełączanie awaryjne, 198 przepustowość, 28, 34, 79 monitorowanie, 39 pamięci masowej, 94 przestój dozwolony, 33 przydział pamięci, 89 przywracanie danych, 119, 248 stanu, 117 nieplanowane scenariusze, 122 planowane scenariusze, 120 strategia, 131 struktura strategii, 126 zasięg scenariusza, 124 R RAID, 96 reguły monitorowania, 59 rejestrowanie zdarzeń, 169 replikacja danych, 80, 191 dostępność, 196, 201 lokalność, 196 na poziomie bloków, 195 oparta na wierszach, 194 opóźnienie, 199 procesy operacyjne, 202 252  Skorowidz przenośność, 196 skalowalność, 196 spójność, 202 stan, 80 z jednym liderem, 191 formaty dzienników, 193 modele, 192 monitorowanie, 199 trudności, 197 zastosowania, 195 z wieloma liderami, 203 przypadki użycia, 203 zapis w dowolnym węźle, 207 rozwijanie baz danych, 244 ryzyka czynnik ludzki, 43 czynniki grupowe, 44 dla usługi, 46 dostępność zasobów, 42 mechanizmy kontrolne, 52 nieznane czynniki, 42 podejmowanie decyzji, 52 uruchamianie procesu, 45 złożoność, 42 S samoaktualizacja, 23 samoobsługa, 17, 160 SAN, storage area network, 97 scenariusze przywracania stanu, 120 semafor, 83 serwer fizyczny, 87 wady, 98 zalety, 98 sieć, 92 SAN, 97 skalowalność, 21, 230, 232, 234 składowanie danych, 243 SLA, service-level agreement, 25 SLI, service-level indicator, 27 SLO, service-level objective, 25 cele, 29 SMP, symmetric multiprocessing, 90 spójność, 216, 223, 224 replikacji, 202 SRE, site reliability engineering, 17 stan replikacji, 80 STRIDE, 164 Poleć książkęKup książkę synchronizacja konfiguracji, 108 replik, 197 system, 88 kontroli wersji, 104 obsługi zdarzeń, 231 ORM, 213 szeregowanie operacji wejścia-wyjścia, 88 szyfrowanie automatyczne bazy danych, 178 danych, 171 algorytmy, 174 na poziomie urządzenia, 181 nad poziomem systemu plików, 180 przesyłanych, 173 połączenia, 176 systemu plików, 180 z użyciem wtyczki, 178 Ś śledzenie rozproszone, 72 środki zapobiegawcze, 166 środowiska programistyczne, 114 T techniki samoobsługowe, 17 technologia VPN, 177 telemetria, 65 teoria kolejek, 64 testowanie kodu, 161 warstwy uwierzytelniania, 161 testy, 130, 145 akceptacyjne, 112 czarnoskrzynkowe, 64 migracji, 153 na dalszych etapach przetwarzania, 148 operacyjne, 121, 148 po zatwierdzeniu zmian, 146 wycofywania zmian, 154 z użyciem pełnego zbioru danych, 147 transakcje, 215 trwałość, 28, 97, 219 twierdzenie CAP, 222 tworzenie kopii zapasowych, 117, 197 U udostępnianie, 137 uruchamianie monitorowania, 67 usługi, 23 gwarantowany poziom, 25 infrastrukturalne, 123, 127 katalog, 112 ocena ryzyka, 46 poziom jakości, 25 SLA, 25 SLI, 27 SLO, 25 testy stanu, 70 uwierzytelnianie, 171 W warstwa aplikacji, 162 bazy danych, 162 dostępu do danych, 228 wdrażanie, 149 wersjonowanie, 150 węzły, 121 wirtualizacja, 98 wskaźnik SLI, 27 ekonomiczność, 28, 34 dostępność, 27 koszt, 28, 34 opóźnienie, 27 przepustowość, 28 trwałość, 28 wskaźniki, 65 aktywności semaforów, 83 dostępności, 32 opóźnienia, 79 przepustowości, 34, 79 współbieżność, 82, 99 współczynnik trafień, 81 współpraca, 137, 159 wstrzykiwanie kodu, 161, 169 wydajność obsługi zapytań, 178 wymiana, 90 danych, 81 wzorce migracji, 151 skalowania, 21 Skorowidz  253 Poleć książkęKup książkę wzorzec operacje powodujące blokady, 152 operacje z wysokim wykorzystaniem zasobów, 152 stopniowe migracje, 153 Z zabezpieczenia, 157 zapisywanie danych, 90 zapytania bazodanowe, 84 zarządzanie infrastrukturą, 103 poziomem jakości usług, 25 ryzykiem, 41 udostępnianiem, 137 zasobami, 168 zatwierdzanie operacji, 80 zdarzenia, 66, 73, 75, 84 254  Skorowidz Poleć książkęKup książkę
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Inżynieria niezawodnych baz danych. Projektowanie systemów odpornych na błędy
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: