Autorem wpisu jest Piotr "Czarny" Piotrowski, architekt rozwiązań SUSE w polskim oddziale firmy SUSE

Warszawa

June 30, 2016

Na całym świecie ludzie wykorzystują wsparcie techniczne do wykorzystywanych systemów, dlaczego więc u nas, w kraju nad Wisłą, zbyt często jeszcze to szef informatyki musi sam wszystkiego dotknąć i najlepiej samemu skompilować dystrybucję Linuksa? Jeżeli powyższe wynika z faktu, że chciałby być „niezamienialny”, lepiej by pozbył się takich złudzeń i zadbał nie tylko o większy komfort pracy w oparciu o już zbudowane rozwiązania, ale przede wszystkim o bezpieczeństwo organizacji, która go zatrudnia.

Temat bezpieczeństwa jest dość oczywisty. To przede wszystkim kwestia zachowania ciągłości pracy systemów biznesowych i ciągłości pracy „kadr”, które przy korzystaniu ze standardowych systemów łatwo uzupełnić. Wróćmy do komfortu pracy działu IT i zarazem komfortu trzymania w ryzach kosztów IT. 

W firmach, w których biznes jest oparty na nowych technologiach informatycznych, działy IT bywają bardzo rozbudowane i dość często używane są w nich dystrybucje Linuksa bez żadnej formy wsparcia technicznego producenta. Powód z pozoru wydaje się prosty – skoro programiści i informatycy są już zatrudnieni, a koszty ich czasu pracy poniesione, wobec tego po co płacić za wsparcie do wykorzystywanych systemów, skoro można to zadanie dodać do obowiązków działu IT? W końcu kod Linuksa jest otwarty, w razie problemu wszystko da się z nim zrobić.

Do takiej sytuacji oczywiście nie dochodzi, gdy mowa o zapewnieniu wsparcia dla wykorzystywanego sprzętu, gdzie bez mrugnięcia okiem płacimy za wsparcie producenta. Podobnie jest z oprogramowaniem zamkniętym, jak „uważane za prostsze” systemy firmy Microsoft. Przy czym to nie jest tak, że zatrudnieni „microsoftowi” informatycy są nastawieni wyłącznie na kasę i przychodzą do pracy za pieniądze, a linuksowi dla jakiś wyższych idei. Jeśli jednych administratorów obarczamy zadaniami wyręczenia producenta w zapewnieniu wsparcia dla systemów, a innych nie – przede wszystkim oznacza to, że ktoś nie potrafi kontrolować i wykorzystać zasobu, jakim jest czas swoich informatyków. Taniej w mojej opinii jest zdefiniować koszt utrzymania i wsparcia infrastruktury wspólnie z producentem,  jakim w przypadku systemów Linux jest np. SUSE, niż poświęcać zupełnie niezdefiniowane zasoby na tego typu czynności.

Oprogramowanie, mimo powszechności wirtualizacji czy chmury, nie obędzie się bez sprzętu. Jednym z ważniejszych zadań działu IT jest dbanie o to, by zasoby wewnątrz firmy były spójne technologicznie i współpracowały ze sobą. Dotyczy to oczywiście styku sprzętu i oprogramowania. Z tego powodu to producent sprzętu zwykle gwarantuje wsparcie dla określonych systemów. W przypadku Linuksa, są to od late dwie główne dystrybucje tzw. „komercyjne” - SUSE i Red Hat. I tu kolejne ważne pytanie: czy więc szef IT powinien brać na siebie więcej obowiązków w tym zakresie, niż firmy takie jak HP, Dell czy IBM?

Ważnym elementem mającym wpływ na komfort pracy jest odpowiedzialność za utrzymanie w ruchu wykorzystywanych systemów. Nawet największa, ogólnoświatowa społeczność skupiona nad jakimś projektem open source nie weźmie przecież odpowiedzialności za stabilność działania systemów, na których stoi dajmy na to nasza produkcja. Z drugiej strony dlaczego mamy całą tę odpowiedzialność włożyć na barki osoby, która zarządza infrastrukturą w firmie? Społeczność jest oczywiście bardzo ważnym wsparciem, ale głównie w rozwoju projektów open source. Często nie ma też problemu z tym, by uzyskać od społeczności wsparcie w rozwiązaniu jakiegoś problemu. Schody zaczynają się wtedy, gdy chcemy zdefiniować poziom SLA.

W firmach zwykle nie płaci się informatykom, by brali za producenta odpowiedzialność za utrzymanie stabilności działania systemów każdorazowo po zainstalowaniu wymaganych poprawek, ani tym bardziej za utrzymanie określonego poziomu SLA. Sami przecież nie zmodyfikują dajmy na to sterownika i nie wykonają niezbędnych testów przed jego implementacją. Jeśli zostaną do tego przymuszeni, konsekwencje mogą być groźne dla firmy. Czym kończy się samodzielne dłubanie w kodzie dobrze widać na przykładzie wielu aplikacji napisanych dla DBASE i wciąż istniejących w firmach. Na starcie wydawało się, że taniej jest zatrudnić „Pana Kazia” do napisania bazy, ale już koszty utrzymania systemu po latach lecą w przysłowiowy kosmos.
 
Komfort pracy zapewnia więc korzystanie z rozwiązaniach uznawanych obecnie i w perspektywie najbliższych lat za standard na rynku. W przypadku systemów Linux sprawa wydaje się prosta, gdyż mimo dziesiątek dostępnych na rynku dystrybucji wiodące od ponad 20 lat lat są dokładnie dwie. Problemem dla firmy mogą być jednak przyzwyczajenia samych informatyków. Ktoś powie „używam dystrybucji XYZ, bo się przyzwyczaiłem i lubię, i taką będę wdrażał z firmie”. Jeśli jest to jednak dystrybucja bez komercyjnego wsparcia, ryzyko związane z tym, że osoba odpowiedzialna - „lubiąca dany system” - jest na urlopie  chwilowo poza zasięgiem, może być zbyt duże dla firmy.

Konkluzją dla wszystkich przytoczonych przykładów nie jest zdanie „Każdy system wykorzystywany w firmie musi mieć zapewnione wsparcie producenta”. Jeśli je trzeba wykupić no to trzeba. Dotyczy to wszystkich systemów produkcyjnych, a w uzasadnionych przypadkach również systemów testowych, gdzie alternatywnie można korzystać z bezpłatnych systemów pochodnych. Dobrym wyborem będzie skorzystanie z systemów komercyjnych SUSE, gdzie do obsługi środowisk testowych można wykorzystać system openSUSE LEAP. Całością środowiska da się wówczas spójnie zarządzać z poziomu narzędzia SUSE Manager, które dba o odpowiednią konfigurację każdego systemu.

Jak więc zapewnić komfort pracy w dziale IT i trzymanie w ryzach koszty?

  • Stosować systemy uznawane za standard na rynku i mające zapewnione wsparcie producenta.

  • Wybierać rozwiązania, dla których dział HR przy zatrudnianiu nowego pracownika będzie mógł wymagać od niego posiadania stosownego certyfikatu zawodowego, dzięki czemu informatyk będzie mógł pójść na urlop podobnie jak księgowa.

  • Wdrażać systemy zapewniające spójność technologiczną posiadanego środowiska IT, dla których nie będzie problemem np. zdefiniowanie wymagań sprzętowych.


Na koniec jeszcze kilka liczb - twardych argumentów obrazujących, dlaczego w biznesie stosuje się komercyjne dystrybucje Linuksa. Przy okazji są to również argumenty za stosowaniem systemów SUSE Linux.

  • Aplikacje SAP – najbardziej biznesowe z biznesowych – są najczęściej wdrażane na platformie Linux. Ponad 70% takich wdrożeń jest zrealizowana na platformie systemowej SUSE, a jeszcze więcej, gdy mowa o wdrożeniach na SAP HANA.
  • Największe komputery od lat stosowane wyłącznie do celów biznesowych, mowa o maszynach typu mainframe, do obsługi aplikacji wykorzystują również systemy Linux. Ponad 80% takich maszyn na świecie działa w oparciu o SUSE Linux.
  • Najwyższe standardy bezpieczeństwa obowiązują w branży lotniczej i obronnej. Dlatego już niemal wszystkie duże firmy (notowane na liście Fortune 500 w Stanach) wykorzystują systemy SUSE Linux. Na światowej liście Fortune 100 mamy już blisko 70% firm – użytkowników oprogramowania SUSE.
  • Sam system operacyjny z punktu widzenia biznesu jest bezużyteczny, jeśli nie da się na nim uruchomić wymaganych aplikacji. Dlatego SUSE tak duży nacisk kładzie na certyfikację oprogramowania uruchamianego na SUSE. Obecnie na liście jest już ponad 8500 certyfikowanych aplikacji.
  • Podobnie ma się sprawa ze sprzętem. Tu również certyfikacja jest gwarancją poprawności i ciągłości działania systemu. Obecnie pod kątem poprawności działania z systemami SUSE zostało sprawdzonych i certyfikowanych ponad 13.500 urządzeń.

I na koniec rzecz nie bez znaczenia. W szybkim rozwiązywaniu problemów bariera językowa nie może być problemem. Systemy Linux są powszechnie stosowane przez firmy bardzo duże, gdzie pracownicy zwykle biegle posługują się językiem angielskim, ale też przez firmy mniejsze z sektora MŚP, obsługiwane często przez zewnętrznych informatyków. Dlatego SUSE od lat zapewnia wsparcie techniczne w języku polskim. Pomagamy też na etapie projektowania rozwiązań opartych rozwiązaniach SUSE, co jest z kolei moją rolę jako architekta w polskim oddziale SUSE.