ITIL w Oracleu - incydenty, problemy i monitorowanie systemu.pdf - ITIL - ro3son

XVI Konferencja PLOUG

Kościelisko

Październik 2010

ITIL w Oracle’u – incydenty, problemy

i monitorowanie systemu

Jarosław Przybyszewski

Accenture Services Sp. z o.o.

jarek.przybyszewski@gmail.com

Abstrakt. ITIL jest bez wątpienia najpowszechniej używanym standardem w zarządzaniu usługami IT. Popularność standardu wpływa

na sposób świadczenia usług, ale także na oprogramowanie. Wpływ ITIL’a na bazę danych Oracle jest widoczny od kilku lat. Najpierw

pojawiły się elementy CMDB a w najnowszej wersji incydenty i problemy. Niniejsze opracowanie przybliża najnowsze elementy

Oracle’a 11g wchodzące w skład Fault Diagnosability Infrastructure, które są bardzo mocno związane z ITIL-em i można je bezpośred-

nio przełożyć na język tego standardu..

Informacja o autorze. Jarek Przybyszewski jest administratorem baz danych w Accenture Services. Specjalizuje się w problematyce

związanej z eksploatacją systemów baz danych Oracle.

113

ITIL w Oracle’u – incydenty, problemy i monitorowanie systemu

1. ITIL i Oracle

Historia informatyki od początku jej istnienia jest nierozerwalnie związana z różnymi standar-

dami. Na przestrzeni ostatnich 10-20 lat trend ten został utrzymany a industrializacja całej branży

zasadniczo wpłynęła na daleko posuniętą standaryzację i unifikację sposobu dostarczania usług

przez większość dostawców. Jednak standaryzacja nie dotyczy jedynie samego sposobu świadcze-

nia usług, ale także urządzeń i oprogramowania zarówno tych dostarczanych użytkownikom ma-

sowym jak i tych przeznaczonych dla firm. Częściowo jest to wymuszone przez różnego rodzaju

urzędy (np. unifikacja ładowarek do telefonów komórkowych), w innych przypadkach wpływ

mają różnego rodzaju orgranizacje branżowe lub standaryzacyjne. Zdarza się również, że standar-

dami de facto stają się rozwiązania wprowadzone na rynek przez firmy komercyjne (np. BlueRay

vs. Drugi standard). Popularność danego standardu, podobnie jak inne rozwiązania, podlegają

prawom rynku oraz cyklowi życia produktów. Jedne standardy przegrywają z innymi, z kolei

część standardów staje się przestarzała i wychodzi z użycia. Niebagatelne znaczenie ma również

moda na dane rozwiązanie, która często wpływa na popularność konkretnego rozwiązania.

Starając się umiejscowić najważniejszy (kiedyś, teraz może już niekoniecznie) produkt Orac-

le’a w kontekście standardów i cyklu życia produktu można stwierdzić, że jest to przede wszyst-

kim dominujący produkt na rynku baz danych, praktycznie niezagrożony ze względu na stopień

zaawansowania oraz liczne przejęcia firm z nim konkurujących. Ponadto dzięki dominującej po-

zycji Oracle bardzo często wyznacza standardy i wprowadza nowe rozwiązania, które konkurenci

lepiej lub gorzej kopiują i włączają do swoich silników baz danych. Podobna sytuacja jest ze stan-

dardem ITIL (IT information library), który jest fundamentem i zbiorem najlepszych praktyk wy-

korzystywanych w zarządzaniu szeroko rozumianym IT. Nie jest to co prawda produkt i nie można

kupić ITIL-a w związku z tym trudno mówić o jego dominacji na rynku, jednakże większość du-

żych firm usługowych w różnym stopniu go wdrażają i z niego korzystają, a pozostałe organizacje

albo myślą o wdrożeniu ITIL-a, albo już go wykorzystują. Istnieje kilka innych konkurencyjnych

standardów, ale to właśnie ITIL wyróżnia się dominującą pozycją i aktualnie jest najmodniejszy.

Kierunek rozwoju bazy danych Oracle nie mógł pozstać obojętny na ogólne tendencje panujące

na rynku systemów i usług IT, w tym także na wykorzystanie standardów takich jak ITIL. Wpływ

ITIL-a na bazę danych Oracle oraz na sposób świadczenia usług przez firmę Oracle jest doskonale

widoczny i sam w sobie może być ciekawym materiałem analizy wdrożenia ITIL-a.

W wersji 10 pojawiła się wersja graficzna Enterprise Menager’a umożliwiająca zarządzanie in-

frastrukturą bazodanową, a później innymi produktami w sposób graficzny i często pozwalała na

wykonanie wielu czynności administracyjnych bez znajomości szczegółów i sposobu w jaki dana

operacja jest wykonywana. EM umożliwił delegowanie części operacji do mniej doświadczaonych

i słabiej wykwalifikowanych działów lub tzw. tańszych lokalizacji. Można tu zauważyć analogię

do ITIL-owego podziału na kilka linii wsparcia i przekazanie wstępnej analizy do działu operacyj-

nego, niekoniecznie wyspecjalizowanego w danej dziedzinie.

W tej samej wersji Oracle wypuścił łatkę (poprawkę), którą przemycił razem z poprawką bez-

pieczeństwa, która jest właściwym fundamentem ITIL-a – OCM (Oracle Configuration Manage-

ment). Każdy kurs ITIL-a i każda osoba znająca ten standard potwierdzi, że pierwszym zadaniem

podczas tworzenia podejścia usługowego w dziale IT jest stworzenie bazy danych „jednostek kon-

figuracyjnych” (ang. Configuration items, configuration and management database – CMDB).

Zgodnie z tym zaleceniem Oracle wymusił na swoich klientach zebranie i dostarczenie informacji

dotyczących konfiguracji posiadanych systemów. Dzięki temu Oracle uzyskał dokładną listę śro-

dowisk dla każdego klienta ze wszystkimi istotnymi informacjami np. wersja bazy danych, system

operacyjny, zaaplikowane poprawki, parametry konfiguracyjne itd. Natomiast klienci mają uła-

twione zadanie w momencie wystąpienia problemów z bazą danych i konieczności otwarcia Servi-

ce Request-u (SR-a) w dawnym Metalinku.

114

Jarosław Przybyszewski

Kolejna wersja systemu bazy danych Oracle, 11g, to już cały pakiet istotnych zmian, które

wprowadzają pojęcie incydentu i problemu do świata, który już od dawna się nimi posługiwał.

W wersji 11g Oracle stworzył kolejny zestaw narzędzi nazywanych Fault Diagnosability Infra-

structure (FDI), która grupuje i porządkuje wiele elementów istniejących w poprzednich wersjach

(np. pliki zrzutów pamięci, pliki śladu, logi bazy danych) oraz dodaje nowe elementy (np. Incident

Packaging Service – IPS, ADR – Automatic Diagnostic Repository). Pojęcia incydentu i problemu

są doskonale znane w standardzie ITIL, posiadają dobrze zdefiniowane i opisane procesy powią-

zane ze sobą, których celem jest przywrócenie usługi do pełnej sprawności.

Kolejne punkty zostaną poświęcone dokładniejszemu przyjrzeniu się nowym cechom Oracle

11g w kontekście ITIL’a oraz w zastosowaniach praktycznych. Rozważania zostały podzielone na

wprowadzenie teoretyczne, czyli opis grupy nowych funkcjonalności w Oracle’u 11g – Fault Dia-

gnosability Infrastructury, następnie pokazany został sposób wykorzystania informacji gromadzo-

nych przez ADR do rozwiązania rzeczywistych problemów napotykanych w codziennej admini-

stracji bazami danych, a na koniec całość rozważań zostanie podsumowana i przedstawione zosta-

ną dalsze możliwości rozwoju tej części bazy danych.

2. Oracle Database Fault Diagnosability Infrastructure

Fault Diagnosability Infrastructure (FDI) w bazie danych Oracle ma za zadanie wspomagać za-

pobieganie, wykrywanie, analizę i rozwiązywanie problemów. Ze szczególną uwagą są traktowane

błędy krytyczne oraz wszelkiego rodzaju uszkodzenia danych. W przypadku wystąpienia błędu

Oracle automatycznie zbiera wszelkie dostępne informacje mogące wspomóc znalezienie przyczy-

ny błędu i zapisuje je w repozytorium zwanym Automatic Diagnostic Repository (ADR). Dzięki

takiemu podejściu możliwe ma być:

• łatwiejsza analiza wstępna problemu,

• szybsze znalezienie sposobu uniknięcia błędu,

• ograniczenie szkód wyrządzonych przez wystąpienie błędu,

• skrócenie czasu analizy problemu,

• skrócenie czasu rozwiązania problemu

• łatwiejsza komunikacja ze wsparciem Oracle’a.

Komponenty FDI

FDI składa się z kilku komponentów, które współtworzą nowy system rozwiązywania proble-

mów z bazą danych. W Tabeli 1 znajduje się opis najważniejszych komponentów. Dokładniejsza

analiza możliwości poszczególnych komponentów znalazła się w kolejnych rozdziałach niniejsze-

go opracowania.

Tabela 1. Komponenty systemu Fault Diagnosability Infrastructure

Nazwa komponentu Opis

Automatic diagnostic reposi-

tory

Kluczowy element FDI, czyli repozytorium plików, w którym

przechowywane są wszystkie informacje zbierane przez kompo-

nenty FDI.

Automatic capture of diag-

nostic data upon first failure

Komponent jest odpowiedzialny za zebranie wszystkich możli-

wych informacji, które mogą ułatwić analizę problemu. Jest akty-

wowany automatycznie w przypadku wystąpienia krytycznego

błędu np. ORA-600 lub ORA-7445. Zbierane są podobne infor-

macje, jak w starszych wersjach Oracle’a, czyli zrzuty pamięci,

115

ITIL w Oracle’u – incydenty, problemy i monitorowanie systemu

pliki śladu oraz nowe elementy np. raporty dotyczące stanu sys-

temu.

Health checks

W przypadku wystąpienia poważnego incydentu Oracle może

automatycznie uruchomić zbieranie danych dotyczących stanu

systemu, przy czym jest to głównie analizy spójności różnych

elementów bazy danych np. plików dziennika powtórzeń, seg-

mentów wycofania, słownika.

Incident packaging services

(IPS)

IPS jest jednym z ciekawszych elementów FDI, gdyż umożliwia

automatyczne tworzenie paczek zawierających wszystkie dostęp-

ne pliki i raporty dotyczące konkretnego incydentu lub problemu.

Dzięki temu dużo łatwiej jest znaleźć pliki dotyczące konkretnego

problemu oraz szybciej można je dostarczyć do wsparcia tech-

nicznego firmy Oracle.

Data recovery advisor (DRA)

Ponieważ FDI ma za zadanie przede wszystkim wspomagać roz-

wiązywanie poważnych problemów w jej skład wchodzi DRA,

który analizuje raporty tworzone przez FDI dotyczące spójności

bazy danych i potrafi przedstawić możliwe sposoby rozwiązania

problemu, wpływ uszkodzeń na bazę danych oraz ich priorytet.

SQL Test Case Builder

Od bardzo dawna problemem było stworzenie reprodukowanego

przykładu zapytania, z którym występuje problem lub które ma

być zoptymalizowane. SQL Test Case Builder wspomaga ten

proces i umożliwia szybkie i łatwe zebranie wszystkich koniecz-

nych informacji.

Problemy i incydenty

W poprzednich rozdziałach pojawiły się już terminy problemu i incydentu, ale nie zostały one

wyjaśnione i często były używane wymiennie, co jest nie do końca precyzyjne i wymaga pewnych

wyjaśnień. W Tabeli 2 znalazły się wyjaśnienia obu pojęć zgodne ze Słownikiem Języka Polskie-

go.

Tabela 2. Pojęcia incydentu i problemu na podstawie SJP [SJP10]

Pojęcie

Znaczenie

Incydent

Nieprzyjemne wydarzenie

Wydarzenie mało ważne

Problem

Trudna sytuacja, z której należy znaleźć jakieś wyjście

Poważna sprawa, która wymaga przemyślenia i rozstrzygnięcia

Zarówno Oracle jak i standard ITIL definiują oba pojęcia i obie definicje są do siebie zbliżone.

Wydaje się, że Oracle wzorował się na ITIL’u i przełożył definicję ze standardu na język bazy

danych. W Tabeli 3 znajdują się definicje obu pojęć na podstawie dokumentacji Oracle’a i stan-

dardu ITIL wraz z krótkim komentarzem.

Tabela 3. Definicje problemu i incydentu wg Oracle’a i wg ITIL’a

Pojęcie

Definicja wg Oracle’a

Definicja wg ITIL’a

Incydent

Jest to pojedyncze wystąpienie problemu. Jeżeli pro-

blem występuje wiele razy incydent jest tworzony dla

każdego wystąpienia. Każdy incydent jest zapisywany

w repozytorium ADR i jest znakowany czasem. Incy-

denty są identyfikowane przez unikalny w skali ADR

Niezaplanowana przerwa w

działaniu usługi IT lub po-

gorszenie jej jakości. Defekt

w działaniu jednostki konfi-

guracyjnej, który jeszcze nie

ITIL w Oracleu - incydenty, problemy i monitorowanie systemu.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: