Strona Główna / Blog

Sekrety Wysokiej Dostępności w Twojej Sieci, Czyli Kto Jest Winny Za Ostatni FUCK-UP

Mirek Burnejko

Mirek Burnejko

Rozmawiam w języku Amazon Web Services, Microsoft Azure i Google Cloud Platform. Skontaktuj się z nim pisząc na ten adres.

Wpis ten bazuje na sesji BRKNMS-2518 z Cisco Live 2013. Znajdziesz tu podstawowe informacje o wysokiej dostępności w Twojej sieci kampusowej, systemu Cloud, Data Center, lub każdej innej. Jakże często proste decyzje w początkowej fazie projektu mają gigantyczne znaczenie na funkcjonowanie, koszt i awarie w naszej sieci.

Znajdziesz tu kilka wskazówek, które mogą Ci służyć do tłumaczenia nietechnicznym osobom, że decyzja którą podejmujesz opłaci się wszystkim.

Czym jest SLA?

„SLA jest formalizacją jakości usług w kontrakcie pomiędzy klientem a dostawcą usług” – Fred Baker, Fellow of Cisco Systems (Jeśli nie możesz czegoś zmierzyć – nie negocjuj tego…)

Umowa SLA najczęściej mówi nam, że akceptujemy gdy dany system/aplikacja nie działa przez X minut miesięcznie. Często (na przykład przy łączach) mówi o minimalnych maksymalnych opóźnieniach, minimalnych parametrach, etc. Co jest natomiast bardzo ważne, mówi też co się stanie, gdy warunki SLA zostaną przekroczone.

Podpisując umowę SLA upewnij się, że jesteś w stanie mierzyć (niezależnie od operatora) jakość usługi. Dobrze jest również, że operator zgadza się w pełni i na piśnie na formę Twojego pomiaru usułgi.

Dostawcy usług najczęściej używają tak zwanych „dziewiątek”. System 5 dziewiątek, to taki, który jest niedostępny przez 30 sekund rocznie. Spójrzmy na to liczbowo.

SLA w perspektywie:

  • 99.9999% – 30 sekund niedostępności rocznie
  • 99.999% – 5 minut niedostępności rocznie
  • 99.99% – 53 minuty niedostępności rocznie
  • 99.95% – 4 godziny i 23 minuty niedostępności rocznie (poziom instancji AWS EC2)
  • 99.9% – 8 godzin i 46 minut niedostępności rocznie
  • 99.5% – 1 dzień, 19 godzin i 48 minut niedostępności rocznie
  • 99% – 3 dni, 5 godzin i 36 minut niedostępności rocznie

Przyczyny Awarii i Jak Im Zapobiegać

Przyczyny awarii (bazuje na badaniach serwisów Cisco):

  • Błąd ludzki (sprzęt) – 9%
  • Błąd ludzki (konfiguracja) – 11%
  • Błąd oprogramowania – 30%
  • Awaria sprzętu – 50%

Jak zapobiegać awariom

Dilbert

Strategia projektowania, czyli wyeliminuj możliwość błędu. So simple.

  • Redundancja
  • Hierarchia
  • Różnorodność
  • Konfiguracja L2, L3
  • Funkcje HA
  • Optymizacja protokołów

Strategia sprzętowa, czyli na co uważać wybierając router i serwer.

  • Czy już warto wchodzić w dany sprzęt?
  • Czy już nie warto wchodzić w dany sprzęt?
  • Bazując na obecnych technologiach, politykach End of Life, etc

Strategia aplikacyjna, czyli co nam z serwera, skoro system leży.

  • Sprawdź funkcjonalność
  • Weź pod uwagę stabilność (SLA)
  • Miej w głowie cykl życia oprogramowania (koszt i zarządzanie)
  • No i oczywiście bezpieczeństwo

Strategia zarządzania zmianą, czyli co nam z samochodu bez dobrego mechanika.

  • Walidacja i testy w środowisku testowym (pilot)
  • Aktywności przez zmianą
  • Aktywności w oknie serwisowym
  • Aktywności po zmianie
  • Monitorowanie

Spędzaj więcej czasu na walidacji i testowaniu, a mniej czasu w oknie serwisowym.

Strategia zarządzania usługami i systemami

Zarządzanie reaktywne i proaktywne może ze sobą współgrać. Na nieszczęście większość firm idzie w zarządzanie reaktywne -> Był fuck-up -> Znajdźmy winnego -> potem znajdźmy problem. Nie zrozum mnie źle. Zarządzanie reaktywne jest bardzo ważne, jednak opieranie swoich decyzji zakupowych, organizacyjnych i etetowych wyłącznie na negatywnych wydarzeniach jest przegraną strategią.

  • Zarządzanie reaktywne
    • Koncentracja na głównych przyczynach wpływający na wydarzenie/problem w systemie
    • Proces zainicjowany przez wydarzenie (znajdźmy problem, znajdźmy winnych)
    • Często używane do wyjaśnienia „Dlaczego dany serwis został dotknięty”?
  • Zarządzanie proaktywne
    • Koncentracja na unikaniu problemów w systemie
    • Prace w regularnych, powtarzalnych cyklach
    • Wykorzystywanie historycznych danych do identyfikacji możliwych problemów
    • Wymaga potężnego zarządzania wiedzą o środowisku

NIE JESTEŚ PROBLEMEM… NIE JEST NIM TEŻ TEN STARY SERWER

Dilbert 2

Opracowanie strategii projektowej, sprzętowej, programowej, zarządzania zmianą i zarządzania usługami to podstawa stworzenia wysoko wydajnego systemu. Jest to o tyle ważne, gdyż pominięcie choćby jednej strategi może zrobić z Twojej 99.9999% wersję 99%.

Wiele razy widziałem genialne zaprojektowaną sieć, gdzie podczas nocnych zmian w oknie serwisowym, nikt nie przestrzegał żadnych zasad…. „Dobra zróbmy upgrade bez testów… powieszą nas za jaja, jak nie skończymy przed 2:00”.

Z drugiej strony wiele razy widziałem środowiska np. w AWS (podkreślę, że jedna instancja AWS EC2 ma SLA na poziomie 99.95%), które poprzez zastosowanie odpowiednich strategii i procesów, budowane były z myślą o 99.99999% i tak też działają (hint).

Nie sprzęt i nie ludzie są problemami. To brak myślenia, projektowania i procedur powodują największą liczbę problemów.

Już wkrótce otwieramy nowe kursy

Zostań specjalistą chmury publicznej

Dołącz do listy mailingowej!

Dołącz do naszego newslettera

Staramy się wysyłać tylko wartościowe informacje, np. co miesiąc dostaniesz spis najważniejszych nowości z chmur Azure, AWS i GCP, z krótkimi opisami i linkami.