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.

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.