Obecnie to jedna z najdroższych pozycji na rynku. Hossa wokół inżynierów „DevOps” przekracza wszelkie możliwe granice, a sytuacja jest jeszcze trudniejsza w przypadku Senior DevOps inżynierów.
Pracuję jako kierownik działu integracji i automatyzacji, zgadnijcie angielskie rozwinięcie — DevOps Manager. Czy angielskie określenie rzeczywiście odzwierciedla naszą codzienną działalność — wątpię, natomiast rosyjska wersja w tym przypadku jest znacznie dokładniejsza. W mojej pracy oczywiście muszę przeprowadzać rozmowy kwalifikacyjne z przyszłymi członkami mojego zespołu, a w minionym roku przeszło przez mnie około 50 osób, a jeszcze tylu samo zostało odrzuconych na preselekcji z moimi pracownikami.
Wciąż poszukujemy kolegów, ponieważ pod etykietą DevOps kryje się bardzo duża warstwa różnego rodzaju inżynierów.
Wszystko, co napiszę poniżej, jest moją osobistą opinią i nie musicie się z nią zgadzać, jednak dopuszczam, że może wprowadzić trochę dodatkowego kontekstu do waszego podejścia do tematu. Mimo ryzyka, że mogę narazić się na krytykę, publikuję swoją opinię, ponieważ uważam, że ma ona prawo istnieć.
Firmy różnie rozumieją, kim są inżynierowie DevOps i w celu szybkiego zatrudnienia nakładają tę etykietę na wszystkich. Sytuacja jest dość dziwna, ponieważ firmy są gotowe płacić niewyobrażalne wynagrodzenia tym ludziom, otrzymując w większości przypadków administratora narzędziowego.
Kim więc są inżynierowie DevOps?
Zacznijmy od historii powstania — Development Operations pojawił się jako kolejny krok w kierunku optymalizacji współpracy w małych zespołach, mając na celu zwiększenie szybkości produkcji produktu jako oczekiwany rezultat. Idea polegała na wzmocnieniu zespołu deweloperskiego wiedzą o procedurach i podejściu do zarządzania środowiskiem produktowym. Innymi słowy, programista powinien rozumieć i wiedzieć, jak jego produkt działa w różnych warunkach, powinien wiedzieć, jak wdrożyć swój produkt, jakie parametry środowiska dostosować, aby poprawić wydajność. W ten sposób, przez pewien czas, zaczęli pojawiać się deweloperzy z podejściem DevOps. Programiści DevOps pisali skrypty do budowy i pakowania, aby uprościć swoją działalność i funkcjonowanie środowiska produkcyjnego. Jednak złożoność architektury rozwiązań i wzajemny wpływ komponentów infrastruktury z czasem zaczęły pogarszać wyniki środowisk, z każdą iteracją wymagana była coraz głębsza wiedza na temat różnych komponentów, co obniżało produktywność samego programisty z powodu dodatkowego wysiłku w zrozumienie komponentów i dostosowania systemów do konkretnego zadania. Koszt pracy programisty wzrastał, a wraz z nim koszt produktu, wymagania wobec nowych programistów w zespole gwałtownie wzrosły, ponieważ musieli oni również pokrywać obowiązki "gwiazdy" w rozwoju, a naturalnie "gwiazdy" stawały się coraz mniej dostępne. Warto również zauważyć, że z mojego doświadczenia niewielu programistów interesuje specyfika przetwarzania pakietów przez jądro systemu operacyjnego, zasady routingu pakietów czy aspekty bezpieczeństwa hosta. Logicznym krokiem było zaangażowanie administratora, który znał się na tym i powierzenie mu takich obowiązków, co dzięki jego doświadczeniu pozwoliło osiągnąć te same wskaźniki po niższych kosztach w porównaniu do kosztów "gwiazdy" w rozwoju. Tacy administratorzy byli wprowadzani do zespołu, a ich głównym zadaniem było zarządzanie środowiskami testowymi i produkcyjnymi na zasadach konkretnego zespołu, z zasobami przypisanymi tej konkretnej ekipie. W ten sposób właściwie narodził się model DevOps w oczach większości.
Częściowo lub całkowicie, z biegiem czasu, administratorzy systemów zaczęli rozumieć potrzeby tej konkretnej grupy rozwojowej, jak uprościć życie programistom i testerom, jak wprowadzać aktualizacje i nie zostawać w biurze w piątek w nocy, naprawiając błędy związane z wdrażaniem. Czas mijał, a 'gwiazdami' stawali się administratorzy systemów, którzy rozumieli, czego chcą programiści. W celu minimalizacji wpływu zaczęły się pojawiać narzędzia zarządzające, wszyscy przypomnieli sobie stare i sprawdzone metody izolacji na poziomie systemu operacyjnego, które pozwalały na minimalizację wymagań dotyczących bezpieczeństwa, zarządzania siecią oraz konfiguracji hosta w całości, a co za tym idzie, zmniejszały wymagania wobec nowych 'gwiazd'.
Pojawiła się 'cudowna' rzecz — docker. Dlaczego cudowna? Bo stworzenie izolacji w chroot lub jail, a także OpenVZ, wymagało nietrywialnej wiedzy o systemie operacyjnym, podczas gdy narzędzie to umożliwiało łatwe utworzenie izolowanego środowiska aplikacji na danym hoście z całą niezbędną zawartością i oddanie władzy programistom, a administratorowi systemów zarządzanie tylko jednym hostem, zapewniającym jego bezpieczeństwo i wysoką dostępność — logiczne uproszczenie. Jednak postęp nie stoi w miejscu i systemy stają się coraz bardziej skomplikowane, komponentów przybywa, jeden host nie wystarcza już do zaspokojenia potrzeb systemu i konieczne staje się budowanie klastrów, wracamy zatem do administratorów systemów, którzy potrafią zbudować te systemy.
Cyklicznie pojawiają się różne systemy upraszczające rozwój i/lub administrację, które wreszcie wdrażają systemy orkiestracji, które, dopóki nie wymaga się odejścia od standardowego procesu, są proste w użyciu. Architektura mikroserwisowa również powstała w celu uproszczenia całego opisanego powyżej — mniej zależności, łatwiejsze w zarządzaniu. Z mojego doświadczenia nie doświadczyłem w pełni architektury mikroserwisowej, powiedziałbym, że 50 na 50 — 50 procent mikroserwisów, czarne skrzynki, co weszło, to przetworzone, inne 50 — rozdzielony monolit, usługi niezdolne do pracy oddzielnie od innych komponentów. To wszystko nałożyło znowu ograniczenia na poziom wiedzy zarówno programistów, jak i administratorów.
Podobne "huśtawki" poziomu wiedzy eksperckiej tego lub innego zasobu trwają do dziś. Ale trochę się rozproszyliśmy, jest wiele kwestii, które warto poruszyć.
Inżynier Budowy / Inżynier Wydania
Bardzo wąsko specjalizujący się inżynierowie, którzy pojawili się jako sposób standaryzacji procesów budowy oprogramowania i jego wydań. Podczas wprowadzenia powszechnego Agile wydawałoby się, że przestali być potrzebni, jednak to nieprawda. Ta specjalizacja powstała jako metoda standaryzacji właśnie budowy i dostarczania oprogramowania na przemysłową skalę, tzn. korzystając ze standardowych technik dla wszystkich produktów firmy. Z pojawieniem się DevOps deweloperzy częściowo stracili swoje funkcje, ponieważ to właśnie deweloperzy zaczęli przygotowywać produkt do dostarczenia, a uwzględniając zmieniającą się infrastrukturę oraz podejście do maksymalnie szybkiej dostawy bez patrzenia na jakość, z czasem stali się rzeczywistym hamulcem zmian, ponieważ przestrzeganie standardów jakości nieuchronnie spowalnia dostawy. W ten sposób, stopniowo, część funkcjonalności inżynierów Budowy/Wydania przeszła na barki administratorów systemów.
Ops-y są tak różnorodne
Idziemy dalej i znów obecność szerokiego zakresu obowiązków oraz brak wykwalifikowanych pracowników popychają nas w kierunku gwałtownej specjalizacji, pojawiają się różne Operations jak grzyby po deszczu:
- TechOps — administratorzy systemu eniki, znani również jako Inżynierowie HelpDesk
- LiveOps — administratorzy systemu, odpowiadający głównie za środowiska produkcyjne
- CloudOps — administratorzy systemu specjalizujący się w publicznych „chmurach” Azure, AWS, GCP, itd.
- PlatOps/InfraOps/SysOps — administratorzy systemu infrastruktury.
- NetOps — administratorzy sieci
- SecOps — administratorzy systemów specjalizujący się w bezpieczeństwie informacyjnym — zgodność z PCI, zgodność z CIS, łatanie, itd.
DevOps — (teoretycznie) osoba, która doskonale rozumie wszystkie procesy cyklu rozwoju — od tworzenia, przez testowanie, po architekturę produktu, potrafi ocenić ryzyko bezpieczeństwa, zna metody i narzędzia automatyzacji przynajmniej na wysokim poziomie; ponadto rozumie również wsparcie przed i po wydaniu produktu. Osoba, która potrafi działać na rzecz zarówno Operations, jak i Development, co pozwala na budowanie korzystnej współpracy między tymi dwoma filarami. Rozumie procesy planowania pracy zespołami i zarządzania oczekiwaniami klientów.
Aby wykonywać tego rodzaju prace i obowiązki, ta osoba powinna posiadać narzędzia do zarządzania nie tylko procesami tworzenia, testowania, ale także zarządzania infrastrukturą produktu oraz planowania zasobów. DevOps w tym rozumieniu nie może być ani w IT, ani w R&D, ani nawet w PMO; powinien mieć wpływ we wszystkich tych obszarach — dyrektor techniczny firmy, Chief Technical Officer.
Czy tak jest w Twojej firmie? — Wątpię. W większości przypadków to albo IT, albo R&D.
Brak narzędzi i możliwości wpływu chociażby na jeden z tych trzech kierunków działalności spowoduje przesunięcie ciężaru problemów w stronę, gdzie te zmiany można wprowadzić łatwiej, na przykład wskutek wprowadzenia technicznych ograniczeń dotyczących wydania związanych z "brudnym" kodem według danych systemów analizy statycznej. To znaczy, gdy PMO ustala sztywny termin na wydanie funkcjonalności, R&D nie jest w stanie dostarczyć jakościowego wyniku w tych ramach czasowych i dostarcza go na tyle, na ile może, zostawiając refaktoryzację na później; DevOps związany z IT, korzystając z narzędzi technicznych, blokuje wydanie. Brak uprawnień do zmiany sytuacji w przypadku odpowiedzialnych pracowników prowadzi do wystąpienia nadmiernej odpowiedzialności za to, na co nie mają wpływu, tym bardziej jeśli ci pracownicy rozumieją i widzą błędy oraz wiedzą, jak je naprawić — "Szczęście w niewiedzy"; a co za tym idzie, do wypalenia i utraty tych pracowników.
Rynek zasobów DevOps
Przyjrzyjmy się kilku ofertom pracy na stanowisko DevOps w różnych firmach.
Jesteśmy gotowi się z Tobą spotkać, jeśli:
- Znasz Zabbix i wiesz, czym jest Prometheus;
- Iptables;
- Asystent BASH;
- Profesor Ansible;
- Guru Linux;
- Potrafisz korzystać z debuggera i wspólnie z programistami znajdować problemy w aplikacjach (php/java/python);
- Routing nie wywołuje u Ciebie paniki;
- Zwracasz dużą uwagę na bezpieczeństwo systemu;
- Backupujesz „wszystko i wszystkich“, a także skutecznie przywracasz to „wszystko i wszystkich“;
- Potrafisz skonfigurować system tak, aby wycisnąć maksimum z minimum;
- Konfigurujesz replikacje przed snem w Postgres i MySQL;
- Konfiguracja i dostosowanie CI/CD dla Ciebie to konieczność jak śniadanie/obiad/kolacja.
- Masz doświadczenie z AWS;
- Jesteś gotowy rozwijać się razem z firmą;
A zatem:
- od 1 do 6 – administrator systemu
- 7 – trochę administracji sieciowej, co również mieści się w roli administratora na poziomie średnim
- 8 – trochę bezpieczeństwa, co jest niezbędne dla administratora na poziomie średnim
- 9-11 – Administrator Systemu na poziomie średnim
- 12 – W zależności od postawionych zadań, albo Administrator Systemu na poziomie średnim, albo Build Engineer
- 13 – Wirtualizacja – Administrator Systemu na poziomie średnim, albo tzw. CloudOps, rozszerzona wiedza na temat konkretnych usług hosting platformy, w celu efektywnego wykorzystania funduszy i zmniejszenia obciążenia obsługi
Podsumowując tę ofertę, można powiedzieć, że chłopakom wystarczy Administrator Systemu na poziomie średnim/seniorskim.
Tak przy okazji, nie warto zbytnio dzielić administratorów na Linux/Windows. Rozumiem, że usługi i systemy tych dwóch światów różnią się, ale ich podstawa jest wspólna, a każdy szanujący się administrator zna zarówno jeden, jak i drugi, a nawet jeśli nie zna, dla kompetentnego administratora nie będzie to problemem.
Rozważmy inną ofertę:
- Doświadczenie w budowie wysoko obciążonych systemów;
- Doskonała znajomość systemu operacyjnego Linux, oprogramowania systemowego i stosu webowego (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Doświadczenie w pracy z systemami wirtualizacji (KVM, VMWare, LXC/Docker);
- Znajomość języków skryptowych;
- Zrozumienie zasad działania sieci i protokołów sieciowych;
- Zrozumienie zasad budowy systemów odpornych na awarie;
- Samodzielność i inicjatywa;
Rozważmy:
- 1 – Senior Administrator Systemów
- 2 – W zależności od sensu, jaki wkładamy w tę stawkę – Administrator Systemu na poziomie średnim/seniorskim
- 3 – Doświadczenie obejmuje również sytuację, w której „Nie podnosiłem klastra, ale tworzyłem i zarządzałem wirtualkami, miałem jeden host Docker, konfiguracja dostępu do kontenerów“ – Administrator Systemu na poziomie średnim
- 4 — Junior System Administrator — tak, administrator, który nie potrafi pisać podstawowych skryptów automatyzacji, bez względu na język, nie jest administratorem — to po prostu pomocnik.
- 5 — Middle System Administrator
- 6 — Senior System Administrator
Podsumowując — Middle/Senior System Administrator
Jeszcze jedna:
- Doświadczenie w pracy jako devops;
- Doświadczenie w korzystaniu z jednego lub kilku produktów do tworzenia procesów CI/CD. Gitlab CI będzie dodatkowym atutem;
- Praca z kontenerami i wirtualizacją; Jeśli używałeś docker – świetnie, a jeśli k8s – doskonale!
- Doświadczenie w pracy w zespole agile;
- Znajomość dowolnego języka programowania;
Zobaczymy:
- 1 — Hmm… Co oni mają na myśli? =) Najprawdopodobniej sami nie wiedzą, co się za tym kryje.
- 2 — Build Engineer
- 3 — Middle System Administrator
- 4 — Umiejętności miękkie, na razie nie będziemy rozważać, chociaż Agile to jeszcze jedna rzecz, którą interpretują według własnych potrzeb.
- 5 — Zbyt ogólnie — to może być język skryptowy lub kompilowany. Ciekawe, czy pisali w szkole w Pascalu i Basicu, czy by ich to zadowoliło? =)
Chciałbym również dodać komentarz dotyczący punktu 3, aby wzmocnić zrozumienie, dlaczego ten punkt obejmuje administratora systemów. Kubernetes to tylko orkiestracja, narzędzie, które kończy proste polecenia dla sterowników sieci i hostów wirtualizacji/izolacji w kilka komend i ułatwia komunikację z nimi, to wszystko. Na przykład weźmy 'framework budowania' Make, którego osobiście nie uważam za framework. Tak, wiem o modzie, by wsadzać Make gdzie popadnie, gdzie to potrzebne i gdzie nie – obwiniać Maven w Make, na przykład, na poważnie?
Zasadniczo Make to po prostu powłoka na shell, która upraszcza polecenia kompilacji, linkowania oraz środowiska kompilacji, tak samo jak k8s.
Kiedyś przesłuchiwałem faceta, który używał k8s w swojej pracy na OpenStacku, i opowiadał, jak wdrażał usługi na nim, jednak, gdy zapytałem o OpenStack, okazało się, że jest administrowany, tak samo jak uruchamiany przez administratorów systemów. Czy naprawdę myślisz, że osoba, która uruchomiła OpenStack, niezależnie od tego, jaką platformę używa, nie jest w stanie używać k8s? =)
Ten kandydat tak naprawdę nie jest DevOps, lecz również Administratorem Systemów i, aby być precyzyjnym, Administratorem Kubernetes.
Podsumowując po raz kolejny — Middle/Senior System Administrator to wszystko, czego będą potrzebować.
Ile waga w gramach
Zakres proponowanych wynagrodzeń dla wskazanych stanowisk — 90k-200k
Teraz chciałbym przeprowadzić paralelę między wynagrodzeniami Administratorów Systemów a Inżynierami DevOps.
W zasadzie, dla uproszczenia, można rozrzucić stopnie według doświadczenia, chociaż nie będzie to dokładne, to na potrzeby artykułu wystarczy.
Doświadczenie:
- do 3 lat — Junior
- do 6 lat — Middle
- ponad 6 lat — Senior
Serwis poszukujący pracowników oferuje:
Administratorzy Systemów:
- Junior — 2 lata — 50k rub.
- Middle — 5 lat — 70k rub.
- Senior — 11 lat — 100k rub.
Inżynierowie DevOps:
- Junior — 2 lata — 100k rub.
- Middle — 3 lata — 160k rub.
- Senior — 6 lat — 220k rub.
W przypadku «DevOps» brane było pod uwagę doświadczenie, które w jakiś sposób dotyczyło SDLC.
Z powyższego wynika, że tak naprawdę firmy nie potrzebują DevOpsów, a także mogłyby zaoszczędzić co najmniej 50 procent początkowo zaplanowanych wydatków, zatrudniając Administratora; co więcej, mogłyby dokładniej określić obowiązki poszukiwanej osoby i szybciej zaspokoić potrzeby. Nie należy również zapominać, że wyraźny podział odpowiedzialności pozwala obniżyć wymagania wobec personelu, a także stworzyć bardziej sprzyjającą atmosferę w zespole, z uwagi na brak przecięć. W przytłaczającej większości ofert pracy roi się od narzędzi i etykiet DevOps, jednak nie mające w rzeczywistości wymagań wobec Inżyniera DevOps, a jedynie prośby o administratora narzędziowego.
Proces szkolenia inżynierów DevOps również ogranicza się jedynie do zestawu specyficznych prac, narzędzi, nie daje ogólnego zrozumienia procesów i ich zależności. Oczywiście dobrze, gdy osoba potrafi używając Terraform wdrożyć AWS EKS w powiązaniu z side-car Fluentd w tym klastrze oraz stos AWS ELK do systemu logowania w ciągu 10 minut, używając tylko jednej komendy w konsoli, ale jeśli nie będzie rozumieć samej zasady przetwarzania logów i po co są one potrzebne, nie będzie wiedzieć, jak zbierać metryki na ich podstawie i śledzić degradację usługi, to będzie to wciąż ten sam helpdeskowiec, który potrafi korzystać z niektórych narzędzi.
Popyt, jednak, rodzi podaż, i widzimy skrajnie przegrzany rynek pozycji DevOps, gdzie wymagania nie odpowiadają rzeczywistej roli, a jedynie pozwalają administratorom systemów zarabiać więcej.
To kim oni są? DevOpsami czy chciwymi administratorami systemów? =)
Jak dalej żyć?
Pracodawcy — precyzyjnie formułować wymagania i szukać dokładnie tych, którzy są potrzebni, a nie rozrzucać etykiety. Nie znasz się na DevOps — w takim przypadku nie są ci potrzebni.
Pracownicy — Uczyć się. Nieustannie doskonalić swoją wiedzę, patrzeć na całościowy obraz procesów i śledzić drogę do wyznaczonego celu. Można stać się tym, kim się chce, wystarczy tylko się postarać.
Źródło: habr.com
