Co jest potrzebne do sukcesu firmy IT w 2019 roku? Prelegenci na konferencjach i spotkaniach mówią wiele głośnych i nie zawsze zrozumiałych dla zwykłych ludzi słów. Walka o czas wdrożenia, mikroserwisy, rezygnacja z monolitu, transformacja DevOps i wiele, wiele innych kwestii. Jeśli porzucimy piękno słów i powiemy wprost, zrozumiale, to sprowadza się to do prostej tezy: twórzcie wysokiej jakości produkt, przy czym róbcie to w komfortowych warunkach dla zespołu.
To ostatnie stało się krytycznie ważne. Biznes w końcu zrozumiał, że komfortowy proces tworzenia oprogramowania zwiększa produktywność, a jeśli wszystko jest dopracowane i działa jak w zegarku, to daje również pewną przestrzeń na manewr w sytuacjach krytycznych. Kiedyś dla tego manewru jakiś mądry człowiek wymyślił kopie zapasowe, ale branża się rozwija, a my doszliśmy do inżynierów DevOps — ludzi, którzy przekształcają proces interakcji pomiędzy rozwojem a zewnętrzną infrastrukturą w coś sensownego i niezwiązanego z szamanizmem.
Cała ta historia o »modułach« jest piękna, ale... Tak się złożyło, że część administratorów nagle przekształciła się w DevOps, a od samych inżynierów DevOps zaczęto wymagać przynajmniej umiejętności telepatii i jasnowidzenia.
Zanim zaczniemy mówić o współczesnych problemach zapewnienia infrastruktury, określmy, co mamy na myśli, używając tego terminu. Do chwili obecnej sytuacja ukształtowała się w sposób, że mamy do czynienia z dwoistością tego pojęcia: infrastruktura może być warunkowo zewnętrzna i warunkowo wewnętrzna.
Pod zewnętrzną infrastrukturą rozumie się wszystko, co zapewnia funkcjonalność usługi lub produktu, nad którym pracuje zespół. To serwery aplikacji lub witryny, hosting i inne usługi zapewniające funkcjonalność produktu.
Wewnętrzna infrastruktura obejmuje usługi i sprzęt, z których korzysta sam zespół deweloperski oraz inni pracownicy, których zazwyczaj również jest sporo. To wewnętrzne serwery systemów przechowywania kodu, lokalnie wdrożony menedżer zadań i wszystko, co istnieje w ramach korporacyjnego intranetu.
Czym zajmuje się administrator systemów w firmie? Oprócz zarządzania intranetem, często spoczywa na nim również ciężar utrzymywania sprawności sprzętu biurowego. Administrator to ten facet, który szybko przyniesie z magazynu nowy komputer stacjonarny lub gotowy do pracy zapasowy laptop, wyda nową klawiaturę i będzie pełzał na czworakach po biurach, podciągając kabel Ethernet. Administrator to lokalny gospodarz i władca nie tylko wewnętrznych i zewnętrznych. serwerów, ale także gospodarz. Tak, niektórzy administratorzy mogą pracować tylko w obszarze systemów, bez sprzętu. Należy ich wyróżnić jako osobną podgrupę „infrastrukturalnych administratorów systemów”. A niektórzy specjalizują się wyłącznie w obsłudze sprzętu biurowego; na szczęście, jeśli firma ma ponad stu pracowników, praca nigdy się nie kończy. Ale ani jedni, ani drudzy nie są DevOpsami.
A kim są DevOps? DevOps to ludzie zajmujący się interakcją pomiędzy tworzeniem oprogramowania a zewnętrzną infrastrukturą. Dokładniej mówiąc, współcześni DevOps są zaangażowani w procesy tworzenia i wdrażania znacznie głębiej niż kiedykolwiek byli administratorzy, którzy po prostu przesyłali aktualizacje na FTP. Jednym z kluczowych zadań inżyniera DevOps obecnie jest zapewnienie komfortowego i efektywnie zorganizowanego procesu współpracy zespołów rozwojowych i infrastruktury produktu. To właśnie ci ludzie odpowiadają za wdrażanie systemów rollback i deploy, odciążają deweloperów i maksymalnie koncentrują się na swoim niezwykle ważnym zadaniu. Przy tym DevOps nigdy nie będzie podciągał nowego kabla ani wydawał nowego laptopa z magazynu (c) KO.
W czym tkwi haczyk?
Na pytanie „Kim jest DevOps?” połowa pracowników branży odpowiada coś w stylu „Cóż, to jest taki administrator, który...” i dalej według tekstu. Tak, dawno temu, gdy zawód inżyniera DevOps dopiero się rozwijał z najzdolniejszych administratorów usług, różnice między nimi nie były oczywiste. Jednak teraz, gdy funkcje DevOps i administratora w zespole zaczęły się radykalnie różnić, mylenie ich ze sobą, a nawet stawianie ich na równi — jest niedopuszczalne.
Ale co to oznacza dla biznesu?
Rekrutacja, to o nią chodzi.
Otwierasz ogłoszenie o pracę „Administrator systemów”, a tam wymienione są wymagania: „współpraca z programistami i klientami”, „system dostarczania CI/CD”, „serwisowanie serwerów i sprzętu firmy”, „administracja systemami wewnętrznymi” i tak dalej; rozumiesz, że pracodawca mówi bzdury. Pułapka polega na tym, że zamiast „Administrator systemów” w tytule ogłoszenia powinno być „Inżynier DevOps”, a jeśli ten tytuł zmienisz, wszystko wraca na swoje miejsce.
Jednak jakie wrażenie sprawia lektura takiego ogłoszenia? Że firma szuka człowieka-orchestrowa, który jednocześnie uruchomi system kontroli wersji i monitoringu, a nawet ugnie sprzęt zębami...
A przecież, aby nie zaostrzać problemów na rynku pracy, wystarczy nazywać oferty pracy po imieniu i dokładnie rozumieć, że inżynier DevOps i administrator systemów to dwie różne jednostki. Jednak nieustanne pragnienie niektórych pracodawców, aby przedstawić jak najszerszą listę wymagań wobec kandydata, prowadzi do tego, że „klasyczny” administrator systemów przestaje rozumieć, co dzieje się wokół niego. Co, zawód mutuje i zostali w tyle?
Nie, nie i jeszcze raz nie. Administratorzy infrastruktury, którzy będą zarządzać wewnętrznymi serwerami firmy, czy zajmować stanowiska wsparcia L2/L3 i pomagać innym pracownikom, nigdzie się nie wybierają i nie mają zamiaru znikać.
Czy ci specjaliści mogą zostać inżynierami DevOps? Oczywiście, że mogą. W rzeczywistości to pokrewne środowisko, które wymaga umiejętności z zakresu administracji systemowej, ale dodatkowo wymaga pracy z monitoringiem, systemami dostarczania oraz bliskiej współpracy z zespołem deweloperów i testerów.
Kolejny problem DevOps
Tak naprawdę, wynajęcie i ciągłe zamieszanie między administratorami a devopsami to nie wszystko. W pewnym momencie biznes zmagał się z problemem dostarczania aktualizacji i współpracy zespołu deweloperskiego z końcową infrastrukturą.
Być może to wtedy na scenę konferencji wszedł człowiek z płonącymi oczami i powiedział: „A my robimy to w ten sposób i nazywamy to DevOps. Ci goście rozwiążą wszystkie Wasze problemy” — i zaczął opowiadać, jak dobrze się żyje w firmie po wdrożeniu praktyk DevOps.
Jednak samo zatrudnienie inżyniera DevOps nie wystarczy, aby wszystko działało „jak należy”. Firma musi przejść przez pełną transformację DevOps, co oznacza, że rola i możliwości naszego devopsa muszą być jasno rozumiane również po stronie zespołu deweloperskiego i testującego produkt. Mamy na ten temat „cudowną” historię, która w pełni ilustruje całą tę czasami chaotyczną sytuację.
Sytuacja. Od devopsu wymagają wdrożenia systemu przywracania wersji, nie zagłębiając się w to, jak on będzie działał. Załóżmy, że w systemie Users znajdują się oddzielne pola pod imię, nazwisko i hasło. Pojawia się nowa wersja produktu, ale dla programistów „powrót” to po prostu magiczna różdżka, która wszystko naprawi, i nawet nie mają pojęcia, jak to działa. Oto przykład: programiści w kolejnym patchu połączyli pola imienia i nazwiska, wdrożyli to w produkcję, a wersja działa wolno z jakichś powodów. Co się dzieje? Kierownictwo przychodzi do devopsa i mówi „Przełącz przełącznik!”, a więc prosi go o powrót do poprzedniej wersji. Co robi devops? Wraca do poprzedniej wersji, ale ponieważ programiści nie chcieli zrozumieć, jak ten powrót się odbywa, nikt nie powiedział devopsowi, że należy także przywrócić bazę. W efekcie wszystko pada, a użytkownicy zamiast wolnej strony widzą błąd „500”, ponieważ stara wersja nie działa z polami nowej bazy. Devops o tym nie ma pojęcia. Programiści milczą. Kierownictwo zaczyna tracić nerwy i pieniądze oraz przypomina sobie o kopiach zapasowych, proponując powrót z nich, by „cokolwiek działało”. W rezultacie użytkownicy tracą wszystkie swoje dane za pewien okres czasu.
Oczywiście, dostaje się devopsowi, który „nie stworzył odpowiedniego systemu przywracania”, a to, że to programiści są winni w tej sytuacji, nikogo nie obchodzi.
Wniosek jest prosty: bez odpowiedniego podejścia do DevOps jako takiego, nie ma z tego żadnego większego pożytku.
Najważniejsze, co należy pamiętać: inżynier DevOps to nie czarodziej, i bez jakościowej komunikacji oraz dwukierunkowej interakcji z programowaniem nie poradzi sobie ze swoimi zadaniami. Devopsi nie mogą zostać pozostawieni sami ze swoimi „problemami” ani dostać polecenia „nie wtrącaj się do programistów, to ich zadanie kodować”, a potem mieć nadzieję, że w krytycznym momencie wszystko będzie działać jak należy. Tak to nie działa.
W istocie, DevOps to kompetencje na styku zarządzania i technologii. Co więcej, nie jest oczywiste, że w tej mieszance technologii powinno być więcej niż zarządzania. Jeśli naprawdę chcesz zbudować szybsze i bardziej efektywne procesy rozwoju, musisz zaufać swojemu devopsowi. On zna potrzebne narzędzia, realizował podobne projekty, wie, jak to robić. Pomóż mu, wysłuchaj jego rad, nie próbuj izolować go w jakieś autonomiczne jednostki. Jeśli administratorzy mogą pracować sami, to devopsy w takim przypadku są bezużyteczne; nie będą mogli pomóc ci stać się lepszym, jeśli sam nie zechcesz tej pomocy przyjąć.
I ostatnia rzecz: przestańcie obrażać administratorów-infrastrukturalnych. Mają oni swój, niezwykle ważny front pracy. Tak, administrator może stać się inżynierem DevOps, ale powinno to wynikać z jego własnej woli, a nie z przymusu. Nie ma nic złego w tym, że systemowy administrator chce pozostać systemowym administratorem — to jego oddzielny zawód i jego prawo. Jeśli jednak istnieje chęć przejścia profesjonalnej transformacji, należy w żadnym wypadku nie zapominać, że będziesz musiał rozwijać nie tylko umiejętności technologiczne, ale również menedżerskie. Wszystkich tych ludzi trzeba będzie połączyć i nauczyć komunikacji w jednym języku, raczej ty jako lider będziesz musiał to zrobić.
Źródło: habr.com
