doku doku
48
BLOG

Informatyka w cywilizacji śmierci - ciemna strona infrastruktury

doku doku Technologie Obserwuj notkę 2

Tytułem wstępu podsumuję 35 lat pracy w IT. To była standardowa ścieżka kariery: programista, projektant, tester, analityk, ITILowiec - typowa dla pracy w wielkich projektach informatyzacji. Dzielę ten czas na dwa okresy: przed ITIL i po. Szybko zrozumiałem, że przed ITIL był chaos, a po zastosowaniu ITIL wszystko zaczęło się układać. Przypomnę, że ITIL jest zbiorem najlepszych praktyk w IT. W 2001 powstał ITIL v2, która nadawała się już do popularyzacji, jako najlepsze praktyki.

Kiedy zrozumiałem, dlaczego praktyki ITIL są najlepsze, zrozumiałem także, co jest największą przewagą kapitalizmu nad socjalizmem - to przewaga usług nad produkcją. Ta sama rzecz może służyć wielu ludziom, pod warunkiem, że właścicielem tej rzeczy jest usługodawca. Po co kupować maszyny, kiedy można mieć to, czego się pragnie, bez towarzystwa maszyn? Zasada ta obowiązuje też w produkcji - nie warto kupować maszyny do szycia, kiedy można kupić ubranie w sklepie - jednak model usługowy o wiele klarowniej pokazuje, w jaki sposób zarabia właściciel infrastruktury, dlaczego zarabiają usługodawcy i dlaczego klienci, dzięki usługom, wydają mniej, a mają więcej luksusu.

W IT mamy wielopiętrową hierarchię usług, które pozwalają wszystkim oszczędzać i zarabiać: hoteling,, hosting, sieć,  aplikacje, chmury, interfejsy... To wszystko sprawia, że przez ostatnie 20 lat informatyka dogoniła w rozwoju, a w niektórych przypadkach przegoniła inne rodzaje usług i gałęzi produkcji. Aby ludzie spoza branży mogli sobie uzmysłowić ten skok, dam porównanie.

Wyobraźcie sobie, że nikt nie ma samochodu. Zamiast tego każdy, kiedy chce, może wsiąść do samochodu i pojechać nim dokąd chce. Żadne prawo jazdy nie jest potrzebne ludziom, którzy nie pracują, jako kierowcy. Nie trzeba samochodu parkować - wysiadasz i zapominasz. Po załatwieniu sprawy, po imprezie, po pracy, po nocy w domu, po wakacjach, po kinie, po spacerze... - wychodzisz i czeka na ciebie samochód. Nie trzeba płacić za ubezpieczenie, naprawy, paliwo. Możesz wybrać abonament, jeśli jeździsz często, a możesz płacić za każdy kurs, jak za taksówkę. Jeżeli sobie wyobrazisz organizację i infrastrukturę usługodawców (flota samochodów), zrozumiesz też, dlaczego ten komfort kosztuje cię o wiele mniej, niż jeżdżenie i zajmowanie się własnym samochodem. Model usługowy wydaje się nieuchronną przyszłością.

Pamiętam początki stosowania ITIL... nie oprę się w tym miejscu pokusie dywagacji, jakim szokiem było odkrywanie, że nierozwiązywalne zagadnienia - zmory IT - okazywały się, w miarę wprowadzania ITIIL bardzo proste. Przykładowo, chaos procedur, procesów, pomysłów, zwyczajów... obsługi zgłoszeń błędów - jak ten chaos staje się pięknym porządkiem, kiedy zrozumiemy, czym różni się pracownik klienta od pracownika usługodawcy. Nagle staje się jasne, że zgłoszenia błędów nie istnieją. Pracownicy klienta mogą zgłaszać "incydenty", czyli skargi i (w ITIIL v3) "wnioski", czyli zamówienia. Klient może zgłaszać wymagania (żądania zmian). A pracownik usługodawcy nie może nic zgłaszać - usługodawca jest od naprawiania, a nie od skarżenia się.

Kluczem jest zrozumienie, czym jest rola. Pracownik usługodawcy w rzeczywistości może zgłaszać incydenty... ale nie swoim kolegom w firmie, ale firmie (zewnętrznej), która jest dla niego usługodawcą. Zgłaszający występuje tu w roli pracownika klienta. Pracuje sobie taki ktoś w pracy przy komputerze i nagle coś nawaliło... Klika więc na przycisk "Zgłoś to". Do kogo to zgłoszenie leci (przez sieć)? Do przełożonego? Do administratora? Nie - to leci do zewnętrznej firmy serwisującej aplikację, która nawaliła. Nie możesz też zgłosić kolegom incydentu, czyli skargi na aplikację, której używa twój klient. A kiedy pojawia się słowo błąd? Błąd jest czymś, co powstaje z analizy zarejestrowanych problemów. Problemy rejestrują pracownicy usługodawcy obsługujący incydenty.

Na tym skończę tę dywagację i wracamy do infrastruktury. ITIL nie przypadkiem ma nazwę Biblioteki Infrastruktury. To coś, co zrozumiałem o wiele później niż najlepsze praktyki... chociaż od samego początku było w ITIL coś niezdrowego, co czuliśmy już od początku, kiedy uczyliśmy się ITILa. Pamiętam te dyskusje o naprawianiu "błędów". Przecież wiemy, że jest błąd: "brakuje dobrego indeksu - tablica mogłaby chodzić dużo szybciej". Zasada ITIL mówiła, że dopóki klient się nie skarży, nie naprawiamy. "A rejestrowanie wszystkich incydentów? Nie szkoda miejsca na powtarzające się rekordy"? ITIL mówi, że automatyzacja bardziej się opłaca niż oszczędzanie pamięci - pamięć jest tańsza niż dodatkowy pracownik rejestrujący incydenty w sposób przemyślany.

Kiedy się dobrze przyjrzeć, większość najlepszych praktyk bazuje na założeniu o taniości infrastruktury. W rzeczywistości to paradoks. Taniość infrastruktury sprawia, że infrastruktura na wszelki wypadek jest zbyt wielka, a większość problemów rozwiązuje się przez wzmacnianie komputerów, rozszerzanie klastrów, kolejne coraz lepsze systemy balansujące... Przestaliśmy poprawiać wydajność, zamiast tego zwiększamy potencjał infrastruktury. Paradoks polega na tym, że ITIL zaczął od oszczędzania na infrastrukturze. Idea jest prosta - duża infrastruktura usługodawcy jest wielokrotnie mniejsza niż suma małych infrastruktur u wszystkich klientów, a liczba informatyków zatrudnionych przez usługodawcę jest wielokrotnie mniejsza niż suma liczb informatyków zatrudnionych przez wszystkich klientów. ITIL łączy te koszty wspólnym pojęciem "konfiguracja", gdyż nie wypada ludzi zaliczać do infrastruktury (mimo podobieństw procesów zarządzania, np. balansowanie składami grup wsparcia) .

Wróćmy na chwilę do przykładu floty samochodów. Dla klientów nie ma znaczenia, czy samochód prowadzi żywy kierowca czy samochód jest automatyczny. Flota samochodów z kierowcami jest częścią infrastruktury usługodawcy, ale grzeczni ITILowcy nazywają to "elementami konfiguracji usługi". To zresztą tylko kosmetyka, gdyż kluczowe jest zrozumienie, dlaczego usługodawcy IT inwestują tak dużo w infrastrukturę - to jest tańsze niż zatrudniać projektantów i programistów od optymalizacji.

Oczywiście, nadal taka nadmiarowa infrastruktura jest tańsza niż gdyby każdy klient sam musiał na własnej zbyt małej infrastrukturze utrzymywać aplikacje, z których korzysta... ale cała branża staje się coraz bardziej energożerna... i te coraz potężniejsze systemy chłodzenia... Dochodzą do tego kopalnie kryptowalut - "skoro mamy wolne moce i dobre systemy balansujące, to dlaczego ich nie wykorzystać i nie zarobić". Elektrownie też się cieszą, że mogą sprzedawać więcej energii...

I tak oto cywilizacja śmierci się rozkręca... Ale na szczęście ITIL od jakiegoś czasu widzi ten problem i dodał optymalizację do najlepszych praktyk. Na razie używają terminu z leśnictwa "sustainability ", który niezbyt dobrze oddaje istotę sprawy. Tłumaczenie na polski jest lepsze:: "zrównoważony rozwój", ale nadal brzmi jak abstrakcja, szczególnie że chodzi o to, aby po prostu zużywać mniej prądu i przy okazji poprawić wydajność usług. Na szczęście ITIIL ma wśród najlepszych praktyk generowanie incydentów wydajnościowych przez systemy monitorowania, nawet jeśli użytkownicy nie zgłaszają takich incydentów. Coraz lepiej rozumiemy, że problemy istnieją, nawet jeśli nikt nie zgłasza incydentów...

doku
O mnie doku

Nowości od blogera

Komentarze

Pokaż komentarze (2)

Inne tematy w dziale Technologie