Cześć, wystartowaliśmy z nowym cyklem podcastów Comarch Careeres. W każdym odcinku nie tylko przekazujemy Wam porcję informacji o różnych stanowiskach, ale także opowiadamy o ścieżkach kariery, projektach i możliwościach. Słuchając nas, dowiecie się, jakie umiejętności i doświadczenie warto posiadać.

Jakub Kisielewski: 

Zacznę od przedstawienia się…

Nazywam się Kuba Kisielewski i od prawie 15 lat pracuję w Comarch w Sektorze APUS przy realizacji dużych projektów dla klientów z sektora publicznego. Od 6 lat prowadzę zespoły Service Desk złożone m.in. z inżynierów systemowych. Obecnie mój zespół realizuje prace dla jednego z naszych największych klientów.

W dzisiejszym podcaście będę chciał opowiedzieć o specyfice pracy, czyli o tym jak praca zorganizowana jest w naszym zespole, jakie są nasze codzienne zadania, jakie technologie i umiejętności trzeba znać, aby pracować jako inżynier systemowy. Poruszę też temat wdrażania się do pracy w naszym zespole oraz możliwości rozwoju. Na koniec podzielę się z Wami co zrobić, aby nie wypaść z rynku, dam też parę rad tym, którzy chcą rozpocząć karierę w IT. Zaczynajmy!

Inżynier systemowy, czyli właściwie kto?

Zacznijmy od tego, że w ofertach pracy często funkcjonują trzy różne nazwy stanowisk, pod którymi kryje się podobny zakres obowiązków oraz podobny kierunek rozwoju. Pierwsza to inżynier systemowy, druga to administrator systemów, a trzecia to DevOps. Nie zapominajmy, że to ostatecznie od danego pracodawcy zależy, jak nazwie dane stanowisko i jaki zakres obowiązków do niego przypisze. Dla mnie inżynier systemowy to ktoś, kto na co dzień tworzy, konfiguruje i utrzymuje środowiska w różnych warstwach infrastruktury takich jak warstwa systemów operacyjnych, baz danych, czy serwerów aplikacyjnych. To ktoś, kto dba o dostępność, wydajność, ciągłość działania, pojemność i bezpieczeństwo elementów infrastruktury. Optymalnie to również ktoś, kto potrafi konfigurować systemy monitorowania i automatyzować procesy.

Jednakże charakterystyka pracy i codzienne obowiązki mogą się różnić w zależności od kilku czynników. Powiem o najważniejszych z nich.

Pierwszym czynnikiem jest z pewnością wielkość firmy, w jakiej się pracuje. Inaczej przecież wygląda praca inżyniera systemowego w kilku czy kilkunastoosobowej firmie, gdzie jest jedna lub dwie osoby odpowiedzialne za infrastrukturę, a inaczej w dużej firmie. Im większa firma, tym wyraźniejszy podział obowiązków, czy to ze względu na technologie, czy warstwy infrastruktury, czy obsługiwanych klientów, czy też utrzymywane systemy. W dużych firmach częściej również można spotkać się ze sprzętem klasy enterprise, mam tu na myśli sprzęt światowej klasy producentów taki jak urządzenia sieciowe, serwery, macierze, czy też płatne oprogramowanie. Sam miałem przyjemność brać udział w projektach, w których pracowaliśmy z wykorzystaniem technologii obecnych u tylko kilku klientów w Polsce. A więc było to unikalne doświadczenie.

Drugim czynnikiem determinującym pracę inżyniera systemowego jest wielkość i liczba projektów, w które jest zaangażowany. Przeważnie będzie tak, że albo dany inżynier pracuje przy jednym dużym projekcie, albo przy kilku mniejszych. Inaczej będzie wyglądać praca w dużym projekcie, w ramach którego utrzymywana jest rozległa infrastruktura przez kilkudziesięciu inżynierów, a inaczej w małych projektach. Większe projekty będą trwały od kilku miesięcy do nawet kilku lat, mniejsze często do kilku tygodni.

Kolejnym ważnym czynnikiem jest rodzaj realizowanego projektu lub rodzaj prac realizowanych w projekcie. Inaczej będzie wyglądać praca inżyniera systemowego w projekcie polegającym na utrzymaniu infrastruktury dla klienta zewnętrznego, a inaczej w dziale zajmującym się rozwojem produktu. W przypadku klientów zewnętrznych musimy dostosować się lub nauczyć technologii i narzędzi wykorzystywanych przez Klienta oraz podporządkować się do jego procedur.

Teraz, zanim opowiem w szczegółach o pracy mojego zespołu, opowiem więcej o tym jak wygląda praca przy realizacji projektu dla jednego z największych klientów z sektora publicznego.

Po pierwsze utrzymaniem systemów tego klienta zajmuje się ponad 100 pracowników z COMARCH. Osoby te podzielone są na kilka kilkunastoosobowych zespołów.

Mamy tu kilka zespołów biznesowych specjalizujących się w utrzymaniu aplikacji – pracują w nich programiści, testerzy, analitycy. Każdy z tych zespołów specjalizuje się w innej grupie aplikacji. Przykładowo jeśli klient zgłosi błąd, że dana aplikacja działa niepoprawnie pod względem funkcjonalnym to taki zespół weryfikuje ten błąd i np. przygotowuje poprawkę programistyczną.

Kolejnym zespołem jest zespół I linii wsparcia, przez który przechodzą wszystkie zgłoszenia od Klienta. Zespół ten monitoruje również działanie poszczególnych elementów systemu.

Pozostałe kilka zespołów to zespoły inżynierów systemowych. Jeden z nich to właśnie mój zespół inżynierów systemowych stanowiący II linię wsparcia. Mój zespół specjalizuje się w realizacji procedur administratorskich w różnych technologiach.

Kolejne zespoły to już zespoły inżynierów III linii wsparcia, tu już występują węższe specjalizacje. I tak jeden z zespołów specjalizuje się w systemach operacyjnych i bazach danych, drugi w środowiskach zwirtualizowanych, trzeci w technologiach warstwy pośredniejntzw. middleware, czwarty w bazach danych na specjalizowanej enterprisowej platformie bazodanowej renomowanego producenta.

Każdy z wcześniej wymienionych zespołów ma zdefiniowany dość dokładnie zakres obowiązków, po kilkadziesiąt, a nawet kilkaset procedur i instrukcji, a wszystkie te zespoły ze sobą współpracują.

Teraz, zgodnie z wcześniejszą obietnicą, chciałbym opowiedzieć więcej o pracy w roli inżyniera systemowego w moim zespole. Nasza codzienna praca polega na realizacji procedur o charakterze administratorskim. Zdecydowana większość czynności realizowanych przez nas, bo ponad 80%, jest spisana w formie procedur i instrukcji, których w sumie jest ponad trzysta.

Jakie grupy procedur realizujemy?

Obecnie wyróżniamy trzy grupy procedur: procedury cykliczne-proaktywne, procedury awaryjne oraz procedury związane z instalacją nowych wersji oprogramowania.

Procedury cykliczne-proaktywne – czyli co? Na przykład rano przerestartowanie komponentów niezbędnych do działania jednego z systemów, wyłączenie wieczorem, weryfikacja logów, weryfikacja backupów, prace optymalizujące obiekty bazodanowe w celu utrzymania odpowiedniej wydajności baz danych i wiele, wiele innych. W efekcie realizacja tych procedur ma zapewnić, że nie będziemy odnotowywać awarii. Każda z procedur cyklicznych realizowana jest z określoną częstotliwością: przykładowo raz dziennie w dni robocze, jeden raz w tygodniu, dwa razy w tygodniu, jeden raz w miesiącu, jeden raz na kwartał.

Procedury awaryjne oczywiście realizujemy znacznie rzadziej niż procedury cykliczne proaktywne, tym bardziej że po każdej awarii staramy się utworzyć nową procedurę cykliczną proaktywną, która zapewni, że dana lub podobna awaria się nie powtórzy. Przykładowa procedura awaryjna? Wypięcie danego elementu infrastruktury z klastra, zrestartowanie go i ponowne wpięcie do klastra. Czyli taka realizacja restartu, która nie będzie miała wpływu na użytkowników pracujących na systemach biznesowych. Jeśli procedura awaryjna nie rozwiąże awarii to stosujemy technikę swarmingu, czyli kilku inżynierów wspólnie analizuje i rozwiązuje problem.

Trzecia i ostatnia grupa procedur to instalacja nowych wersji oprogramowania. Technika idzie do przodu, prawo ciągle się zmienia, dlatego również systemy biznesowe są rozwijane – ich wykonawcy opracowują nowe wersje oprogramowania, przygotowują patch’e czy też bugfix’y. Naszym zadaniem jest wgrać zmiany do elementów i warstw infrastruktury, za które odpowiadamy.

Mamy procedury i instrukcje, a co oprócz tego trzeba robić? Oczywiście, aby procedury i instrukcje były aktualne to trzeba je ciągle przeglądać i aktualizować. Ponieważ infrastruktura techniczno-systemowa to żywe, ciągle zmieniające się środowisko, inne zespoły przekazują do nas coraz to nowe procedury do realizacji. Abyśmy mogli je realizować, to musimy je przeanalizować, w razie potrzeby spisać, dostosować do naszych potrzeb, zweryfikować, czy mamy odpowiednie kompetencje, a w razie potrzeby doszkolić się, a na koniec zweryfikować, czy mamy niezbędne do realizacji nowych procedur uprawnienia. Oprócz tego wszystko to co musimy robić ręcznie, staramy się automatyzować – m.in. implementujemy skrypty. Dzięki temu oszczędzamy czas, podwyższamy jakość naszych usług, szybciej wiemy o symptomach zwiastujących awarie i skuteczniej możemy im zapobiegać.

A w jakich technologiach pracujemy?

Otóż nasze procedury realizowane są w różnych technologiach dotyczących warstw infrastruktury od poziomu systemów operacyjnych, poprzez bazy danych do oprogramowania standardowego. I tak w warstwie systemów operacyjnych mamy systemy uniksopodobne, a także systemy serwerowe z rodziny Windows. W warstwie baz danych mamy bazy renomowanych producentów. W warstwie middleware - oprogramowanie klastrujące, serwery aplikacyjne, LDAPy, oprogramowanie stanowiące monitory transakcji, czy też platformę dla aplikacji kontenerowych.

A z jakich narzędzi pomocniczych korzystamy?

Korzystamy z systemu ticketowego JIRA, który mamy szeroko skonfigurowany, z bazy wiedzy budowanej przy pomocy platformy confluance, systemów monitorowania rozwijanych zarówno przez klienta jak i przez nas, m.in. opartych o Zabbixa i Grafanę. Oprócz tego oczywiście do komunikacji wykorzystujemy oprogramowanie telekonferencyjne, klienty pocztowe, komunikatory oraz telefony komórkowe.

Jak zorganizowana jest praca w naszym zespole?

Nasz kilkunastoosobowy zespół pracuje w trybie 24/7, oznacza to, że przez cały czas w pracy jest co najmniej jedna osoba. Pracujemy po osiem godzin na trzy zmiany. Mamy zmianę poranną od 6:00 do 14:00, zmianę popołudniową od 14:00 do 22:00 oraz zmianę nocną od 22:00 do 6:00. Obecnie nasz grafik pracy wygląda tak, że co najmniej dwie osoby mamy na rano, dwie na popołudnie, jedną na noc i w weekendy. Pozostałe wolne moce pracujemy w godzinach roboczych od 10:00 do 18:00. Nasz zespół pracuje niczym sztafeta, gdy zmiana poranna kończy pracę to przekazuje najważniejsze zadania i informacje tym, którzy zaczynają o 14:00, podobnie Ci którzy kończą pracę o 22:00 przekazują zmianę osobie, która będzie pracować w nocy.

Z punktu widzenia członka zespołu praca wygląda tak, że tydzień pracuje się na rano, tydzień na popołudnie, tydzień na noc, tydzień w środku dnia. 4 dni spośród tych zmian przypadają w weekendy. Grafik ustalamy z miesięcznym wyprzedzeniem, po jego ustaleniu jest możliwość zamiany z innymi osobami z zespołu.

Czego wymagamy od kandydatów?

Oczywiście podstawowej wiedzy informatycznej, w szczególności w zakresie systemów operacyjnych, sieci czy baz danych. Wiedzy i umiejętności, jakie powinien posiadać absolwent studiów informatycznych lub pokrewnych. Natomiast z naszego punktu widzenia absolutnie kluczowa jest umiejętność pracy w systemach uniksopodobnych z poziomu konsoli, wykorzystując wiersz poleceń, bo tak najwięcej pracujemy na co dzień. Przyda się również umiejętność pisania zapytań w języku SQL.

Jakie umiejętności miękkie są potrzebne?

Przede wszystkim umiejętność priorytetyzacji prac i zdolności komunikacyjne. Umiejętność priorytetyzacji prac, bo są sytuacje, w których mamy górkę zadań, którą trzeba umieć rozładować zgodnie z odpowiednią kolejnością – od najbardziej do najmniej ważnych. Zdolności komunikacyjne są potrzebne zarówno w codziennej pracy – bo w danej chwili jest kilka osób w pracy i zwyczajnie trzeba się z nimi podzielić zadaniami, skonsultować niejasności czy problemy, czy o 14:00 i o 22:00 gdy kończący pracę muszą przekazać najważniejsze zadania i informacje, jak i Ci, którzy wtedy rozpoczynają pracę muszą się szybko zapoznać z sytuacją i umiejętnie zadać pytania tym, którzy kończą pracę. Zdolności komunikacyjne przydają się również wtedy, gdy jest się samemu na zmianie, wystąpiła poważna awaria i trzeba wybudzić ekspertów technologicznych z III linii wsparcia. Skoro już wspomniałem o awariach, to przydaje się również odporność na stres, po prostu w przypadku awarii trzeba zachować zimną krew, nie panikować i postępować zgodnie z procedurami.

Jakie wykształcenie jest wymagane?

Szukamy absolwentów kierunków informatycznych lub pokrewnych. Ważniejsze jednak od wykształcenia są dla nas umiejętności. A więc jeśli ktoś skończył inny kierunek techniczny czy ścisły, a podczas rozmowy potwierdzi wymagane umiejętności, to również ma szansę pozytywnie zakończyć proces rekrutacji.

Czy doświadczenie jest wymagane?

Oczywiście doświadczenie w pracy jest mile widziane, czy ktoś pracował w zespole administratorów w dużej firmie, czy jako pojedynczy administrator w małej firmie. Wszelkie doświadczenie w administrowaniu systemami operacyjnymi czy bazami danych, jak i doświadczenie w instalacji nowych wersji oprogramowania będzie procentować. Jednakże jeśli ktoś nie ma doświadczenia, a chce rozwijać się w ścieżce administratorsko-inżyniero-systemowej oraz posiada odpowiednie umiejętności – może spróbować swoich sił w procesie rekrutacji – ocenimy wtedy jego potencjał.

Jak wygląda ścieżka kariery?

W naszym zespole realizujemy procedury w różnych technologiach i warstwach infrastruktury. Jest to zatem świetne miejsce, aby poszerzać swoją wiedzę, umiejętności oraz nabywać doświadczenia. Osoby, które rozpoczynają karierę, pracując w naszym zespole mogą nie tylko poszerzyć podstawowe umiejętności w administrowaniu i utrzymaniu systemów, ale również przekonać się w jakim kierunku chcą dalej podążać – czy np. chcą specjalizować w administracji bazami danych, czy administracji komponentami middleware, czy też skoncentrować się na automatyzacji. Gdy nowa osoba trafia do mojego zespołu, to naukę rozpoczyna od procedur cyklicznych i awaryjnych – to zajmuje od trzech do sześciu miesięcy. Gdy już okrzepnie, to realizuje bardziej zaawansowane procedury dotyczące instalacji nowych wersji oprogramowania. Następnie, gdy taka osoba prezentuje wysoki poziom, to ustalana jest z nią dalsza ścieżka rozwoju – zaczyna współpracować z inżynierami trzeciej linii, aby rozwijać się w wybranych technologiach np. w administracji bazami danych jednego konkretnego producenta. Gdy jest gotowa – przechodzi do tego zespołu trzeciej linii wsparcia. Oczywiście proces ten ma przełożenie na zmiany stanowisk. Ścieżka wygląda tak: konsultant ds. asysty technicznej, następnie młodszy inżynier systemowy, następnie inżynier systemowy, następnie starszy inżynier systemowy. Jednak nie stanowiska, a umiejętności i doświadczenie są dziś moim zdaniem najważniejsze.

Co zrobić, aby nie wypaść z rynku?

Przede wszystkim świat i technologie w zastraszającym tempie idą do przodu. Zupełnie inaczej to wyglądało gdy zaczynałem pracę w COMARCH pod koniec 2006 roku, a zupełnie inaczej wygląda dziś. Na przestrzeni lat obserwowałem popularyzację metodyk zwinnych oraz DevOps. Coraz większą popularność zyskują rozwiązania chmurowe. Coraz więcej czasu i uwagi poświęca się na automatyzację, również w utrzymaniu i administracji systemów. W ostatnim roku, w czasach pandemii, informatyzacja jeszcze przyspieszyła. Obserwuję to nie tylko w pracy, ale również jako obywatel – w życiu codziennym, w którym coraz częściej załatwiam sprawy przez Internet, a coraz rzadziej fizycznie odwiedzam urzędy. Kandydaci do pracy w IT muszą również wziąć pod uwagę, że mają silną konkurencję w postaci swoich koleżanek i kolegów. Dziś dostęp do wiedzy jest znacznie łatwiejszy niż kilkanaście lat temu. Mamy tysiące blogów, książek, filmów na YouTube i dostępnych kursów, a wciąż pojawiają się nowe. I to dostępne dla wszystkich. Jeśli zatem dana osoba chce pracować w IT i nie chce być maruderem, to musi być nastawiona na ciągłą naukę i ciągły rozwój. I to nie tylko w pracy, ale również we własnym zakresie.

Jaką radę dałbym osobie, która rozpoczyna karierę w IT?

Ja oczywiście polecam rozwój w ścieżce administratorsko-inżyniero-systemowej. Ktoś przecież musi tworzyć środowiska deweloperskie, testowe, produkcyjne pod te wszystkie systemy informatyczne, o których wcześniej powiedziałem, a następnie je utrzymać na odpowiednim poziomie. W szczególności ciekawe w tej pracy jest rozwiązywanie problemów, automatyzacja, strojenie wydajności, wprowadzanie nowych procedur i później obserwacja jak te wszystkie czynności wpływają na infrastrukturę i systemy. Polecam też naukę systemów uniksopodobnych, języka SQL, baz danych czy pisania skryptów w językach takich jak Bash, czy Python. To są uniwersalne umiejętności, które z pewnością przydadzą się w pracy na stanowisku inżyniera systemowego, ale i nie tylko.