Poradnik planowania działania chmury prywatnej - Incydent  Udostępnij na: Facebook

Tłumaczenie na podstawie Private Cloud Planning Guide for Operations: Krzysztof Zdrojewski

Opublikowano: 2012-10-25

Wstęp

Proces zarządzania incydentem i problemem ma na celu jak najszybsze rozwiązanie zdarzeń wpływających na działanie usług. Zarządzanie incydentem jest procesem ciągłym, wynikającym z posiadanej infrastruktury, jej jednorodności, stopnia wirtualizacji, wiedzy pracowników oraz odporności na awarie. W artykule przedstawiono również pewne cechy fizyczne dotyczące komponentów tworzących infrastrukturę serwerową.

Zarządzanie Incydentem i Problemem

Zarządzanie Incydentem służy do rozwiązania zdarzeń, które wpływają lub mogą wpłynąć na działanie usług, tak szybko jak to możliwe, przy minimalnym zakłóceniu funkcjonowania usługi. Zarządzanie Problemem wspomaga identyfikację i rozwiązywanie głównych przyczyn incydentów, które się wydarzyły, jak również identyfikację i zapobieganie lub minimalizację wpływu incydentów, które dopiero mogą się wydarzyć.

Infrastruktura zwirtualizowana

Dokładne określenie głównej przyczyny incydentu może być wyzwaniem, gdy oddziela się obciążenie od infrastruktury, a fizyczna lokalizacja często się zmienia. Dodatkowo, zespoły odpowiedzialne za obsługę incydentów mogą nie posiadać odpowiedniej wiedzy dotyczącej technologii wirtualizacyjnych (przynajmniej na początku), co również może prowadzić do opóźnień w rozwiązywaniu incydentów. Ostatecznie, aplikacje mogą nie posiadać dokładnego modelu zdrowia lub mogą nie udostępniać wszystkich informacji wymaganych do proaktywnego monitorowania. Wszystko to może prowadzić do zwiększonej ilości reaktywnych (inicjowanych przez użytkownika) incydentów, co spowoduje zwiększenie średniego czasu do przywrócenia usługi (MTRS) i obniżenia zadowolenia klienta.

Może się wydawać, że stoi to w sprzeczności w wymogiem odporności infrastruktury, ale należy zauważyć, że sama wirtualizacja nie pozwoli osiągnąć wymaganej odporności w infrastrukturze do momentu, gdy nie zostanie wsparta przez dojrzały procesowo system zarządzania IT (ITSM) i szczegółowy system monitorowania zdrowia.

Odporność na awarie a redundancja

Pęd do infrastruktury odpornej na awarie wymaga innego podejścia do rozwiązywania incydentów. Wszechstronne poszukiwanie rozwiązania incydentów w środowisku produkcyjnym wpływa negatywnie na odporność na awarie. Dlatego, jeżeli incydent nie może zostać szybko rozwiązany, usługa może zostać cofnięta do poprzedniej wersji, zgodnie z opisem w procesie Zarządzania Wersją i Wdrożeniem. Dalsze rozwiązywanie problemu może być prowadzone w środowisku testowym, bez wpływu na środowisko produkcyjne. Poszukiwanie rozwiązania w środowisku produkcyjnym może zostać ograniczone do przeniesienia usługi na inne hosty (w celu wyeliminowania infrastruktury jako źródła) i restartu maszyny wirtualnej. Jeżeli podjęte czynności nie przyniosą rozwiązania, powinien zostać uruchomiony scenariusz cofnięcia wersji.

Minimalizacja zaangażowania człowieka

Minimalizacja zaangażowania człowieka w procesie zarządzania incydentem jest krytyczna dla osiągnięcia infrastruktury odpornej na awarie. Scenariusze rozwiązywania problemów, opisane wcześniej, mogą zostać zautomatyzowane, co umożliwi znacznie szybszą identyfikację przyczyny i naprawę niż proces niezautomatyzowany. Ale automatyzacja może ukryć prawdziwą przyczynę incydentu. Należy dokładnie przemyśleć, które etapy rozwiązywania problemów mogą być zautomatyzowane, a które wymagają analizy człowieka. Porównanie zalet i wad obu podejść przedstawiono w Tab. 3. Porównanie zalet i wad różnych podejść do analizy awarii.

Automatyczne rozwiązywanie problemów Analiza dotycząca rozwiązywania problemów, przeprowadzona przez człowieka
Zaleta Wada Zaleta Wada
  • maksymalizacja odporności na awarie,
  • mniej ludzi wymaganych do wykonania czynności związanych z zarządzaniem incydentem.
  • automatyzacja może nie rozwiązać głównych przyczyn,
  • może zamaskować problem leżący u podstaw.
  • bardziej wszechstronne podejście,
  • identyfikacja problemu leżącego u podstaw incydentu.
  • zwiększenie średniego czasu do przywrócenia usługi,
  • wymaga większej ilości osób z większymi umiejętnościami.

Tab. 3. Porównanie zalet i wad różnych podejść do analizy awarii.*

Czas życia infrastruktury

Jeżeli zasób informatyczny będzie miał awarię, niekoniecznie należy traktować tę awarię jako incydent, który musi zostać naprawiony natychmiast. Bardziej efektywne może być potraktowanie tej awarii jako części procesu zarządzania, czasem życia puli zasobów. Zamiast traktować uszkodzony serwer jako incydent, który wymaga natychmiastowego rozwiązania, lepiej potraktować go jako naturalnego kandydata do wymiany podczas normalnego okna serwisowego lub gdy pula zasobów osiągnie określony wskaźnik końca czasu życia zasobów. Każda organizacja musi osiągnąć równowagę pomiędzy kosztami, wydajnością i ryzykiem, które określają stopień zużycia infrastruktury i dokonać wyboru możliwej ścieżki:

  • wymiana wszystkich uszkodzonych serwerów w regularnych odstępach serwisowych,
  • wymiana wszystkich uszkodzonych serwerów, gdy został osiągnięty wskaźnik uszkodzonych serwerów,
  • wymiana całej jednostki skalowania, gdy wewnątrz tej jednostki zostanie osiągnięty określony wskaźnik zestarzenia sprzętu,
  • traktowanie uszkodzenia serwera jako incydentu.

Wady i zalety każdej z tych opcji przedstawiono w Tab. 4. oraz wady w odniesieniu do wymiany komponentów infrastruktury ze względu na czas życia:

Opcja 1. Wymiana w regularnych odstępach serwisowych.
Zalety Wady
  • przewidywalne planowanie zakupów,
  • mniejsze koszty wymiany (wymiana awaryjna jest droższa w ujęciu kosztów zasobów i umów suportowych).
  • pula zasobów może osiągnąć wcześniej wskaźnik zestarzenia niż termin wymiany, co może skutkować incydentem,
  • wymaga większej infrastruktury zapasowej, aby uwzględnić starzenie się zasobów.
Opcja 2. Wymiana przy określonym procencie zestarzenia.
Zalety Wady
  • poziom zestarzenie nie przekroczy planowanego zestarzenia zasobów,
  • niższe koszty wymiany (wymiana awaryjna jest droższa w ujęciu kosztów zasobów i umów suportowych).
  • mniej przewidywalne planowanie zakupów,
  • wymaga większej infrastruktury zapasowej, aby uwzględnić starzenie się zasobów.
Opcja 3. Wymiana, gdy zostanie osiągnięty poziom zestarzenia.
Zalety Wady
  • może być efektywna kosztowo, gdy używane są duże jednostki skalowania,
  • jedyna opcja przy niezależnych jednostkach skalowania.
  • korzystna jedynie dla dużych centrów danych/jednostek skalowania.
Opcja 4. Traktowanie awarii komponentu jako incydentu.
Zalety Wady
  • wymaga utrzymania mniejszej puli Pojemności Zapasowej,
  • nie wymaga żadnych zmian w istniejących procesach.
  • wyższe koszty osobowe,
  • droższe umowy suportowe z producentami.

Tab. 4. Porównanie opcji i ich zalet oraz wad w odniesieniu do wymiany komponentów infrastruktury ze względu na czas życia.*

Opcja 4. jest najmniej pożądana, gdyż nie wykorzystuje atuty odporności na awarie i redukcję kosztów w Chmurze Prywatnej. Dobrze zaplanowana strategia Puli Zasobów i Pojemności Rezerwowej będzie ujęta w procesie starzenia zasobów.

Opcja 1. jest rekomendowana najczęściej. Przewidywalne okno serwisowe umożliwia lepsze zaplanowane zakupów i może pozwolić uniknąć konfliktów z innymi czynnościami serwisowymi, jak np. aktualizacja oprogramowania. Co więcej, dobrze zaplanowana strategia Puli Zasobów i Pojemności Zapasowej będzie ujęta w procesie starzenia zasobów i zminimalizuje ryzyko przekroczenia krytycznych wskaźników przed planowanym przeglądem serwisowym.

Opcja 3. będzie prawdopodobnie jedyną możliwością dla zamkniętych jednostek skalowania, gdyż w takim wypadku, gdy zostanie osiągnięty wskaźnik zestarzenia, musi zostać wymieniony cały kontener.

Podsumowanie

Artykuł ten przedstawił proces zarządzania incydentem oraz pewne wytyczne, które umożliwiają minimalizację zagrożeń. Należy jednak zwrócić uwagę, że im większe są zabezpieczenia, tym większe są ponoszone koszty. Należy uważnie rozpatrzyć wszystkie za i przeciw, a następnie wybrać model, który najlepiej spełnia oczekiwania.