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

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

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

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.