Brałem udział w ostatnim wątku w społeczności OTN, w którym ktoś zadawał pytania dotyczące obniżenia wersji po aktualizacji bazy danych. W jednej z odpowiedzi zapytano, ile osób faktycznie ćwiczy obniżanie wersji bazy danych. Stworzyłem tę ankietę, aby się tego dowiedzieć.
Byłem zaskoczony, gdy znalazłem jeden wkład do tego wątku, który mówił:
Teraz ten plakat nie powiedział tego wprost, ale wyglądało to prawie tak, jakby ta osoba mówiła, że ćwiczenie obniżania jest stratą czasu, ponieważ nigdy tego nie będzie potrzebować. Dam plakatowi korzyść z wątpliwości i tego, że ten pracownik Oracle tak naprawdę tego nie powiedział. Nie próbuję czepiać się tej osoby. Pozwolę, aby ten wątek zapewnił mi możliwość omówienia tematu z bardziej ogólnego punktu widzenia. (Aktualizacja:autor, który skłonił mnie do napisania tego wpisu na blogu, wrócił do wątku w czasie, który zajęło mi napisanie tego i powiedział:„nie oznaczało to sugerowania, że nie powinniśmy „testować” obniżania ocen”.)
W lipcu napisałem wpis na blogu o The Data Guardian. W tym poście na blogu powiedziałem:
DBA musi chronić dane. To jest praca nr 1. Zadanie nr 2 polega na zapewnieniu przez administratora wydajnego i terminowego dostępu do danych. Po co mieć dane, jeśli osoby, które potrzebują do nich dostępu, nie mogą się do nich dostać? Jeśli ci ludzie mają straszną wydajność podczas interakcji z danymi, równie dobrze mogą nie mieć dostępu.
Jako DBA musimy zarządzać ryzykiem. Musimy określić, jakie zagrożenia mogą stać się rzeczywistością. Zadaniem administratorów baz danych jest zmierzenie tych zagrożeń i określenie dwóch planów działania. Jakie kroki można podjąć, aby uniknąć urzeczywistnienia się tego ryzyka i jakie kroki muszę podjąć, aby rozwiązać problem, gdy to ryzyko stanie się rzeczywistością?
Nawet administrator na niższym poziomie zrozumie znaczenie kopii zapasowych. Kopie zapasowe to strategia zarządzania ryzykiem. W przypadku utraty danych możemy je odzyskać z kopii zapasowej. Nawet administrator baz danych na niższym poziomie rozumie, jak ważna jest możliwość przywracania danych z kopii zapasowej.
W tym wątku OTN napisałem to:
Dla mnie jest to coś w rodzaju Prawa Murphy'ego. W przeszłości mówiłem podobne rzeczy. Pomysł (i cały sens tego wpisu na blogu) jest taki, że jeśli nie podejmę odpowiednich kroków w zakresie zarządzania ryzykiem, to po prostu proszę bogów, aby urzeczywistnili to ryzyko. Jeśli odmówię regulacji lusterka wstecznego i używania go podczas cofania pojazdu, to jest dzień, w którym wracam do czegoś. Jeśli odmówię wiązania sznurowadeł, cóż, to jest dzień, w którym na nie wchodzę i potykam się. W dniu, w którym odmawiam noszenia okularów ochronnych podczas korzystania z elektronarzędzia, dostaję coś w oku. Dzień, w którym pójdę na plażę i odmówię nałożenia kremu przeciwsłonecznego, to dzień, w którym wrócę do domu z poparzeniem słonecznym. Masz pomysł.
Niektórzy czytelnicy mogą myśleć, że jestem szalony i że wszechświat nie ma tego głównego planu, żeby mnie spieprzyć tylko dlatego, że jestem zadowolony z siebie. I zgodziłbym się. Więc powiem to w inny sposób, jeśli nie planuję łagodzenia ryzyka, to nie zrobiłem nic, aby powstrzymać to przed urzeczywistnieniem się. Szanse na to, że stanie się rzeczywistością, nie maleją z powodu mojej bezczynności.
Zarządzanie ryzykiem składa się z dwóch głównych elementów. 1) określenie prawdopodobieństwa wystąpienia tego elementu ryzyka oraz 2) określenie wpływu, gdy to ryzyko wystąpi. Przedmioty o najwyższym prawdopodobieństwie występowania są łagodzone w pierwszej kolejności. Jest to łatwe i często robi to wiele osób zajmujących się zarządzaniem ryzykiem. Umieszczają pozycje ryzyka w arkuszu kalkulacyjnym i wpisują pewną wartość dla prawdopodobieństwa wystąpienia tego ryzyka. Po zakończeniu sortują według kolumny prawdopodobieństwa i rozpoczynają ograniczanie ryzyka od góry do dołu. Wiele strategii zarządzania ryzykiem rysuje linię gdzieś pośrodku listy i decyduje, że jakikolwiek element ryzyka poniżej tej linii ma zbyt małe prawdopodobieństwo, że nie będziemy się martwić o ten element ryzyka. Nie możemy złagodzić wszystkich możliwych zagrożeń we wszechświecie. Po prostu nie ma wystarczająco dużo czasu, aby sobie z tym wszystkim poradzić. Więc musimy gdzieś narysować linię.
Jedną z wad, którą widzę przez cały czas, jest to, że zarządzanie ryzykiem nie poświęca wiele czasu na skupienie się na wpływie to ryzyko staje się rzeczywistością. Arkusz kalkulacyjny musi zawierać podobną kolumnę z oceną wpływu tego elementu ryzyka na biznes. Menedżer ds. ryzyka musi również posortować arkusz kalkulacyjny w tej kolumnie. Wszelkie elementy, które mają duży wpływ, muszą mieć działania łagodzące ryzyko, nawet jeśli istnieje małe prawdopodobieństwo wystąpienia tego elementu! Niestety zbyt wiele osób zajmujących się zarządzaniem ryzykiem nie uwzględnia tego etapu oceny wpływu ryzyka. Ponownie, gdy arkusz kalkulacyjny jest sortowany według wpływu na firmę, gdzieś rysowana jest linia.
Może się okazać, że ryzykowne pozycje mają WYSOKIE prawdopodobieństwo mieć NISKI lub nawet BARDZO NISKI wpływ do firmy. Lubię arkusze kalkulacyjne zarządzania ryzykiem, które zawierają trzecią kolumnę „Prawdopodobieństwo x wpływ”. Ta kolumna pomaga zrozumieć związek między dwoma składnikami ryzyka.
Wróćmy do pytania o aktualizację bazy danych, które wywołało ten wpis na blogu. Myślę, że każdy, kto czyta ten artykuł na blogu, powinien zgodzić się, że aktualizacja bazy danych Oracle jest ryzykowną propozycją. Jest tak wiele różnych rzeczy, które mogą się nie udać podczas aktualizacji bazy danych Oracle. Prawdopodobieństwo błędu aktualizacji jest WYSOKA. Elementy łagodzące ryzyko często obejmują między innymi przećwiczenie uaktualniania na produkcyjnych klonach i wykonanie kopii zapasowej bazy danych przed rozpoczęciem procesu uaktualniania. Dlaczego to robimy? Cóż, wpływ do firmy jest BARDZO WYSOKA. Jeśli nie uda nam się zaktualizować naszej produkcyjnej bazy danych, nasi użytkownicy biznesowi nie będą mieli dostępu do danych. Nie jesteśmy dobrymi strażnikami danych, jeśli nie możemy ominąć tej porażki. Jeśli wystarczająco przećwiczymy aktualizację w środowiskach nieprodukcyjnych, możemy zmniejszyć prawdopodobieństwo pozycji ryzyka do ŚREDNIEGO. Ale najprawdopodobniej nie możemy zmniejszyć tego konkretnego prawdopodobieństwa ryzyka do NISKIEGO. Dlatego wykonujemy kopię zapasową przed rozpoczęciem aktualizacji. Powinien nadal mieć problemy, mimo że zrobiliśmy wszystko, co w naszej mocy, aby zmniejszyć prawdopodobieństwo tego elementu ryzyka, wpływ do biznesu jest nadal BARDZO WYSOKI. Tak więc strategia przeciwdziałania ryzyku stosowana przez administratora baz danych polega na robieniu notatek na temat tego, gdzie i co spowodowało niepowodzenie aktualizacji, oraz przywracania danych z kopii zapasowej. Baza danych działa i wyeliminowaliśmy wpływ do firmy. DBA następnie wraca do deski kreślarskiej, aby ustalić, jak rozwiązać problem. DBA próbuje zmniejszyć prawdopodobieństwo ten problem pojawia się ponownie, gdy wracają w późniejszym czasie, aby ponownie przeprowadzić proces aktualizacji.
Wróćmy więc do komentarza w wątku OTN, w którym wydawało się, że ćwiczenie obniżania poziomu bazy danych nie jest warte czasu. Nie zgadzam się. A moja niezgoda ma wiele wspólnego z wpływem do firmy. Zgadzam się z komentarzem podanym przez autora w odpowiedzi.
Zgadzam się z tym w 100%. Dlaczego przeprowadzamy tę „dokładną próbę”? To wszystko z powodu ograniczania ryzyka. Staramy się zmniejszyć prawdopodobieństwo że aktualizacja spowoduje słabą wydajność lub przerwę w działaniu aplikacji. Ale nawet jak powiedział ten plakat:„Zawsze pojawią się problemy, które pojawiają się w produkcji po aktualizacji, ponieważ niemożliwe jest przetestowanie aplikacji w 100%”. Ponownie zgadzam się w 100% z tym, co mówi ten plakat. Ale co z wpływem? do firmy? Zajmę się tym za chwilę, ale najpierw muszę trochę posunąć się w następnym akapicie…
Niedawno zaktualizowałem krytyczny system produkcyjny z wersji 11.2.0.4 do wersji 12.1.0.2. Tam, gdzie pracuję, mamy więcej testów aplikacji niż kiedykolwiek widziałem na innych stanowiskach. Mamy pełny zespół QA, który przeprowadza dla nas testy. Mamy nawet zespół, który odpowiada za nasze zautomatyzowane testy. Mamy zautomatyzowane roboty, które co noc wykonują nasz kod aplikacji. Oprócz tego mamy inną zautomatyzowaną procedurę, która za każdym razem, gdy ludzie wpychają zmiany w kodzie do Test lub Prod, ta procedura szybko sprawdza krytyczne ścieżki kodu. Zaktualizowałem środowiska programistyczne (ponad 15 z nich) do 12.1.0.2 i czekałem miesiąc. Następnie uaktualniłem Test i czekałem 3 tygodnie, zanim uaktualniłem produkcję. Wystąpiły problemy, które zostały znalezione i rozwiązane, zanim zaktualizowaliśmy produkcję. Ale nawet po tym wszystkim miałem duże problemy po aktualizacji produkcji. Możesz odwiedzić moje posty na blogu od połowy października do połowy grudnia, aby zobaczyć niektóre z tych problemów. Byłem bardzo bliski obniżenia poziomu tej bazy danych, ale zamiast tego udało mi się rozwiązać problemy. Wracając do punktu, o którym mówiłem…
Po zakończeniu aktualizacji baza danych jest otwierana dla biznesu. Użytkownicy aplikacji mogą teraz korzystać z aplikacji. Co w tym momencie dzieje się w bazie danych? Transakcje! A transakcje oznaczają zmiany danych. W momencie, gdy administrator DBA otwiera bazę danych dla biznesu po zakończeniu uaktualniania, zaczynają się pojawiać zmiany danych. Po tym wszystkim o to właśnie chodzi w bazie danych, prawda? Przechwytuj zmiany danych i udostępniaj dane użytkownikom końcowym aplikacji.
Więc co się stanie, jeśli znajdziesz się na łodzi, na której byłem ostatniej jesieni z aktualizacją mojej bazy danych? Uderzałem w rzeczy, których nie widzieliśmy poza produkcją, nawet po wszystkich naszych testach. Wpływ do biznesu był WYSOKI. Muszę być w stanie zredukować ten wpływ na biznes. Miałem trzy opcje. 1) Rozwiąż problemy, jeden po drugim. 2) Przywróć z kopii zapasowej, którą zrobiłem przed aktualizacją, aby móc przywrócić bazę danych do starej wersji. 3) Zdegraduj bazę danych i wróć do deski kreślarskiej. Wybrałem pierwszą opcję. jak zawsze w mojej karierze. Ale co, jeśli to nie wystarczy? Rozwiązanie problemów może zająć trochę czasu. Niektóre firmy po prostu nie mogą sobie pozwolić na taki czas z takim negatywnym wpływem do firmy. Ile witryn zostało porzuconych, ponieważ wydajność była słaba lub coś nie działało poprawnie? W przypadku zdecydowanej większości produkcyjnych baz danych opcja 2 ma bardzo straszny wpływ do biznesu! Stracisz transakcje po zakończeniu aktualizacji! DBA nie będzie w stanie przejść dalej po aktualizacji, zachowując starą wersję bazy danych, więc dane zostaną utracone, co w przypadku wielu produkcyjnych baz danych jest niedopuszczalne. Firma może pozwolić sobie na utratę danych przez godzinę, ale ile osób uruchomiłoby to działanie w ciągu godziny od uaktualnienia? Najprawdopodobniej to działanie zostanie wykonane kilka dni po uaktualnieniu i wpływie dla firmy za tego rodzaju utratę danych jest znacznie powyżej BARDZO WYSOKI. Pozostaje więc opcja 3 jako opcja o najmniejszym wpływie firmie, aby pomóc rozwiązać wszelkie problemy, jakie firma odczuwa po uaktualnieniu.
Na podstawie tego ostatniego akapitu prawdopodobnie możesz powiedzieć, że moim zdaniem ważne jest, aby administrator bazy danych Oracle wiedział, jak obniżyć poziom swojej bazy danych po zakończeniu aktualizacji. Przyznam, że prawdopodobieństwo DBA potrzebnych do zmiany na starszą wersję jest BARDZO NISKA. Ale wpływ brak obniżenia ratingu może mieć katastrofalne skutki dla firmy. (Znowu te dwa słowa). Ponieważ prawdopodobieństwo jest niski, nie ćwiczę często obniżania wersji, ale ponieważ wpływ brak możliwości obniżenia poziomu jest bardzo wysoki, ćwiczę je raz na jakiś czas.
Na zakończenie jeszcze raz wrócę do tego prawa Murphy'ego. Wszechświat nie spiskuje przeciwko mnie, ale jako Data Guardian muszę stosować dobre zasady zarządzania ryzykiem. Oznacza to ocenę prawdopodobieństwa i wpływu pozycji ryzyka nałożonych przez moją zmianę. Chociaż wszechświat i bogowie mogą nie sprawić, by Prawo Murphy'ego lub jego kuzyni wkroczyli w ruch, nie robię sobie żadnej przysługi, łagodząc ryzyko. Nie zmniejszam prawdopodobieństwa ani trochę.
