🥇Kim są DevOps?

W tej chwili jest to niemal najdroższa pozycja na rynku. Zamieszanie wokół inżynierów „DevOps” przekracza wszelkie możliwe granice, a w przypadku starszych inżynierów DevOps jest jeszcze większe.
Pracuję na stanowisku kierownika działu integracji i automatyzacji, zgadnijcie po angielsku – DevOps Manager. Jest mało prawdopodobne, aby transkrypcja w języku angielskim odzwierciedlała nasze codzienne działania, ale wersja rosyjska w tym przypadku jest dokładniejsza. Ze względu na charakter mojej działalności naturalnym jest, że muszę przeprowadzić wywiady z przyszłymi członkami mojego zespołu, a na przestrzeni ostatniego roku przewinęło się przeze mnie około 50 osób i tyle samo zostało wyciętych na prescreenie z moimi pracownikami.

Wciąż poszukujemy współpracowników, gdyż za etykietą DevOps kryje się bardzo duża warstwa inżynierów różnego rodzaju.

Wszystko co napiszę poniżej jest moją osobistą opinią, nie musisz się z nią zgadzać, ale przyznam, że doda to trochę kolorytu Twojemu podejściu do tematu. Mimo ryzyka wypadnięcia z łask, publikuję swoją opinię, bo uważam, że ma swoje miejsce.

Firmy w różny sposób rozumieją, kim są inżynierowie DevOps, i w celu szybkiego zatrudnienia zasobu przyklejają tę etykietę każdemu. Sytuacja jest o tyle dziwna, że firmy są gotowe wypłacać tym osobom nierealne wynagrodzenia, pozyskując dla nich najczęściej administratora narzędzi.

Kim więc są inżynierowie DevOps?

Zacznijmy od historii jego pojawienia się – Development Operations pojawił się jako kolejny krok w kierunku optymalizacji interakcji w małych zespołach, aby w oczekiwany sposób zwiększyć szybkość wytwarzania produktu. Ideą było wzmocnienie zespołu deweloperskiego wiedzą na temat procedur i podejść w zarządzaniu środowiskiem produktowym. Innymi słowy, programista musi rozumieć i wiedzieć, jak jego produkt działa w określonych warunkach, musi wiedzieć, jak wdrożyć swój produkt, jakie cechy środowiska można dostosować, aby poprawić wydajność. Tak więc od jakiegoś czasu pojawili się programiści z podejściem DevOps. Deweloperzy DevOps napisali skrypty kompilacji i pakowania, aby uprościć swoje działania i wydajność środowiska produkcyjnego. Jednak złożoność architektury rozwiązania i wzajemne oddziaływanie elementów infrastruktury z biegiem czasu zaczęły pogarszać wydajność środowisk; z każdą iteracją wymagane było coraz głębsze zrozumienie niektórych komponentów, zmniejszając produktywność programisty ze względu na dodatkowe koszty zrozumienia komponentów i dostrojenia systemów do konkretnego zadania. Koszt własny dewelopera wzrósł, a wraz z nim koszt produktu, wymagania dla nowych programistów w zespole gwałtownie wzrosły, ponieważ musieli oni również pokryć obowiązki „gwiazdy” rozwoju i, oczywiście, „gwiazdy” stały się mniej i mniej dostępne. Warto również zauważyć, że z mojego doświadczenia wynika, że niewielu programistów interesuje się specyfiką przetwarzania pakietów przez jądro systemu operacyjnego, regułami routingu pakietów i aspektami bezpieczeństwa hosta. Logicznym krokiem było pozyskanie znającego się na tym administratora i przypisanie mu podobnych obowiązków, co dzięki jego doświadczeniu pozwoliło osiągnąć te same wskaźniki niższym kosztem w porównaniu z kosztem inwestycji „gwiazdowej”. Administratorzy tacy byli umieszczani w zespole, a jego głównym zadaniem było zarządzanie środowiskami testowymi i produkcyjnymi, według zasad konkretnego zespołu, przy pomocy przydzielonych temu zespołowi zasobów. Tak faktycznie DevOps pojawił się w świadomości większości.

Częściowo lub całkowicie, z biegiem czasu, ci administratorzy systemów zaczęli rozumieć potrzeby tego konkretnego zespołu w zakresie rozwoju, jak ułatwić życie programistom i testerom, jak wypuścić aktualizację i nie musieć nocować w biurze w piątek poprawianie błędów wdrożeniowych. Czas mijał i teraz „gwiazdami” zostali administratorzy systemów, którzy zrozumieli, czego chcą programiści. Aby zminimalizować wpływ, zaczęły pojawiać się narzędzia do zarządzania, wszyscy pamiętali stare i niezawodne metody izolowania poziomu systemu operacyjnego, które pozwoliły zminimalizować wymagania dotyczące bezpieczeństwa, zarządzania częścią sieciową i konfiguracją hosta jako całość i w rezultacie zmniejszyć wymagania dla nowych „gwiazd”.

Pojawiła się „cudowna” rzecz - doker. Dlaczego cudownie? Tak, tylko dlatego, że utworzenie izolacji w chroot lub więzieniu, a także OpenVZ wymagało nietrywialnej wiedzy o systemie operacyjnym, w przeciwieństwie do tego narzędzie pozwala po prostu stworzyć izolowane środowisko aplikacji na określonym hoście ze wszystkim, co niezbędne w środku i pod ręką ponownie w stery rozwoju, a administrator systemu może zarządzać tylko jednym hostem, zapewniając jego bezpieczeństwo i wysoką dostępność - logiczne uproszczenie. Ale postęp nie stoi w miejscu i systemy znów stają się coraz bardziej złożone, komponentów jest coraz więcej, jeden host nie zaspokaja już potrzeb systemu i konieczne jest budowanie klastrów, znów wracamy do administratorów systemów, którzy są w stanie zbudować takie systemy.

Cykl po cyklu pojawiają się różne systemy, które upraszczają rozwój i/lub administrację, pojawiają się systemy orkiestracji, które, dopóki nie zajdzie potrzeba odejścia od standardowego procesu, są łatwe w użyciu. Pojawiła się także architektura mikroserwisów, mająca na celu uproszczenie wszystkiego, co opisano powyżej – mniej relacji, łatwiejsze zarządzanie. Z mojego doświadczenia wynika, że nie znalazłem architektury całkowicie mikroserwisowej, powiedziałbym, że 50 do 50 – 50 procent mikrousług, czarnych skrzynek, weszło i wyszło przetworzonych, pozostałe 50 to rozdarty monolit, usługi nie mogą działać oddzielnie od innych składniki. Wszystko to ponownie nałożyło ograniczenia na poziom wiedzy zarówno programistów, jak i administratorów.

Podobne „wahania” w poziomie wiedzy eksperckiej na temat danego zasobu trwają do dziś. Ale trochę odejdziemy, jest wiele punktów wartych podkreślenia.

Inżynier kompilacji/inżynier wydania

Bardzo wysoce wyspecjalizowani inżynierowie, którzy pojawili się jako środek standaryzacji procesów tworzenia i wydań oprogramowania. Wydawałoby się, że w procesie wprowadzania powszechnego Agile przestało być na nie zapotrzebowanie, ale jest to dalekie od przypadku. Specjalizacja ta pojawiła się jako środek ujednolicenia montażu i dostarczania oprogramowania na skalę przemysłową, tj. przy użyciu standardowych technik dla wszystkich produktów firmy. Wraz z pojawieniem się DevOps, deweloperzy częściowo stracili swoje funkcje, gdyż to oni zaczęli przygotowywać produkt do dostarczenia, a biorąc pod uwagę zmieniającą się infrastrukturę i podejście do możliwie najszybszego dostarczania bez względu na jakość, z czasem zamienili się w hamulec zmian, gdyż przestrzeganie standardów jakości nieuchronnie spowalnia dostawy. W ten sposób stopniowo część funkcjonalności inżynierów ds. kompilacji/wydania została przeniesiona na barki administratorów systemów.

Operacje są bardzo różne

Idziemy dalej i znowu obecność dużego zakresu obowiązków i brak wykwalifikowanego personelu popycha nas w stronę ścisłej specjalizacji, jak grzyby po deszczu, pojawiają się różne Operacje:

TechOps - administratorzy systemu enikey, czyli inżynier HelpDesk
LiveOps – administratorzy systemów odpowiedzialni przede wszystkim za środowiska produkcyjne
CloudOps – administratorzy systemów specjalizujący się w chmurach publicznych Azure, AWS, GCP itp.
PlatOps/InfraOps/SysOps - administratorzy systemów infrastruktury.
NetOps - administratorzy sieci
SecOps - administratorzy systemów specjalizujący się w bezpieczeństwie informacji - zgodność z PCI, zgodność z CIS, łatanie itp.

DevOps to (w teorii) osoba, która z pierwszej ręki rozumie wszystkie procesy cyklu rozwojowego - development, testowanie, rozumie architekturę produktu, potrafi ocenić zagrożenia bezpieczeństwa, zna podejścia i narzędzia automatyzacji, przynajmniej na wysokim poziomie Oprócz tego rozumie również wsparcie przed i po przetwarzaniu w procesie wypuszczania produktu. Osoba potrafiąca pełnić funkcję rzecznika zarówno Operacji, jak i Rozwoju, co pozwala na korzystną współpracę pomiędzy tymi dwoma filarami. Rozumie procesy planowania pracy zespołów i zarządzania oczekiwaniami klientów.

Aby wykonywać tego rodzaju pracę i obowiązki, osoba ta musi posiadać środki do zarządzania nie tylko procesami rozwoju i testowania, ale także zarządzania infrastrukturą produktu, a także planowania zasobów. DevOps w tym rozumieniu nie może być umiejscowiony ani w IT, ani w R&D, ani nawet w PMO, musi mieć wpływ we wszystkich tych obszarach – dyrektor techniczny firmy, Chief Technical Officer.

Czy jest to prawdą w Twojej firmie? - Wątpię. W większości przypadków jest to IT lub R&D.

Brak środków i możliwości wpływu na choć jeden z tych trzech obszarów działania przesunie ciężar problemów w stronę miejsc, gdzie zmiany te są łatwiejsze do zastosowania, jak np. zastosowanie ograniczeń technicznych w wydaniach w związku z „brudnym” kodem według statyki systemy analizatorów. Oznacza to, że gdy PMO wyznacza ścisły termin udostępnienia funkcjonalności, R&D nie jest w stanie w tych terminach wygenerować wysokiej jakości wyniku i produkuje go najlepiej jak potrafi, pozostawiając refaktoryzację na później, DevOps związany z IT blokuje udostępnienie środkami technicznymi . Brak autorytetu do zmiany sytuacji w przypadku odpowiedzialnych pracowników prowadzi do przejawu nadmiernej odpowiedzialności za to, na co nie mają wpływu, zwłaszcza jeśli ci pracownicy rozumieją i widzą błędy oraz jak je poprawić – „Błogość to ignorancja”, a w konsekwencji do wypalenia i utraty tych pracowników.

Rynek zasobów DevOps

Przyjrzyjmy się kilku wakatom na stanowiska DevOps w różnych firmach.

Jesteśmy gotowi spotkać się z Tobą, jeśli:

Posiadasz Zabbix i wiesz, czym jest Prometeusz;

Iptables;

Doktorant BASH;

Profesor Ansible;

Guru Linuksa;

Wiedzieć, jak korzystać z debugowania i znajdować problemy z aplikacjami razem z programistami (php/java/python);

Routing nie powoduje histerii;

Zwróć szczególną uwagę na bezpieczeństwo systemu;

Utwórz kopię zapasową „wszystko i wszystko”, a także pomyślnie przywróć to „wszystko i wszystko”;

Wiesz, jak skonfigurować system tak, aby z minimum wydobyć maksimum;

Skonfiguruj replikację przed pójściem spać na Postgres i MySQL;

Konfigurowanie i dostosowywanie CI/CD jest tak potrzebne, jak śniadanie/lunch/kolacja.

Masz doświadczenie z AWS;

Gotowy do rozwoju wraz z firmą;

Tak więc:

od 1 do 6 - administrator systemu
7 - mała administracja siecią, która pasuje również do administratora systemu, poziom średni
8 - trochę bezpieczeństwa, które jest obowiązkowe dla administratora systemu średniego poziomu
9-11 – Środkowy administrator systemu
12 — W zależności od przydzielonych zadań średni administrator systemu lub inżynier budowy
13 - Wirtualizacja - Middle System Administrator, czyli tzw. CloudOps, zaawansowana wiedza na temat usług konkretnej witryny hostingowej, w celu efektywnego wykorzystania środków i zmniejszenia obciążenia konserwacyjnego

Podsumowując ten wakat, możemy powiedzieć, że dla chłopaków wystarczy średni/starszy administrator systemu.

Swoją drogą, nie należy mocno dzielić administratorów w systemie Linux/Windows. Oczywiście rozumiem, że usługi i systemy tych dwóch światów są różne, ale podstawa dla wszystkich jest taka sama i każdy szanujący się administrator zna i jedno, i drugie, a nawet jeśli nie jest zaznajomiony, to zapoznanie się z nim nie będzie trudne dla kompetentnego administratora.

Rozważmy inny wakat:

Doświadczenie w budowie systemów wysokoobciążeniowych;

Doskonała znajomość systemu operacyjnego Linux, ogólnego oprogramowania systemowego i stosu sieciowego (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);

Doświadczenie z systemami wirtualizacyjnymi (KVM, VMWare, LXC/Docker);

Znajomość języków skryptowych;

Zrozumienie zasad działania sieci protokołów sieciowych;

Zrozumienie zasad budowy systemów odpornych na awarie;

Niezależność i inicjatywa;

Spójrzmy na:

1 – Starszy Administrator Systemu
2 – W zależności od znaczenia przypisanego do tego stosu – Średni/Starszy Administrator Systemu
3 - Doświadczenie zawodowe, w tym może oznaczać - „Klaster nie podnosił, ale tworzył i zarządzał maszynami wirtualnymi, był jeden host Docker, nie było dostępu do kontenerów” - Środkowy Administrator Systemu
4 - Młodszy Administrator Systemu - tak, administrator, który nie umie pisać podstawowych skryptów automatyzujących, niezależnie od języka, a nie admin - enikey.
5 - Środkowy administrator systemu
6 – Starszy Administrator Systemu

Podsumowując - średni/starszy administrator systemu

Inny:

Doświadczenie Devopsa;

Doświadczenie w korzystaniu z jednego lub większej liczby produktów do tworzenia procesów CI/CD. Gitlab CI będzie zaletą;

Praca z kontenerami i wirtualizacją; Jeśli użyłeś okna dokowanego, dobrze, ale jeśli użyłeś K8s, świetnie!

Doświadczenie w pracy w zwinnym zespole;

Znajomość dowolnego języka programowania;

Zobaczymy:

1 - Hmm... Co ci goście mają na myśli? =) Najprawdopodobniej sami nie wiedzą, co się za tym kryje
2 - Inżynier budowy
3 - Środkowy administrator systemu
4 - Kompetencje miękkie, na razie nie będziemy się nimi zajmować, chociaż Agile to kolejna rzecz, którą interpretuje się w wygodny sposób.
5 - Zbyt gadatliwe - może to być język skryptowy lub skompilowany. Zastanawiam się, czy pisanie w szkole w Pascalu i Basicu będzie im odpowiadać? =)

Chciałbym również zostawić notatkę dotyczącą punktu 3, aby lepiej zrozumieć, dlaczego ten punkt jest objęty przez administratora systemu. Kubernetes to po prostu orkiestracja, narzędzie, które w kilku poleceniach łączy bezpośrednie polecenia kierowane do sterowników sieciowych i hostów wirtualizacji/izolacji i pozwala na abstrakcyjną komunikację z nimi, to wszystko. Weźmy na przykład „strukturę kompilacji” Make, której, nawiasem mówiąc, nie uważam za framework. Tak, wiem o modzie wpychania Make'a wszędzie tam, gdzie jest to konieczne i niepotrzebne - na przykład zawijanie Mavena w Make'u, serio?
Zasadniczo Make jest po prostu opakowaniem powłoki, upraszczającym kompilację, łączenie i polecenia środowiska kompilacji, podobnie jak K8s.

Kiedyś przeprowadziłem wywiad z gościem, który używał k8s w swojej pracy na OpenStacku i opowiadał o tym, jak wdrażał na nim usługi, jednak gdy zapytałem o OpenStack, okazało się, że był on administrowany, a także wychowywany przez system administratorzy. Czy naprawdę myślisz, że osoba, która zainstalowała OpenStack, niezależnie od tego, z jakiej platformy za nim korzysta, nie jest w stanie korzystać z k8s? =)
Osoba ta nie jest tak naprawdę DevOpsem, ale Administratorem Systemu, a dokładniej Administratorem Kubernetesa.

Podsumujmy jeszcze raz - wystarczy im średni/starszy administrator systemu.

Ile ważyć w gramach

Przedział proponowanych wynagrodzeń dla wskazanych wakatów wynosi 90 tys.-200 tys
Teraz chciałbym narysować porównanie pomiędzy nagrodami pieniężnymi administratorów systemów i inżynierów DevOps.

W zasadzie dla uproszczenia można rozłożyć oceny na podstawie doświadczenia zawodowego, choć nie będzie to dokładne, ale na potrzeby artykułu będzie wystarczające.

Doświadczenie:

do 3 lat – Junior
do 6 lat – średni
powyżej 6 – Senior

Witryna wyszukiwania pracowników oferuje:
Administratorzy systemu:

Junior - 2 lata - 50 tys. rub.
Średni - 5 lat - 70 tys. rub.
Senior – 11 lat – 100 tys. rub.

Inżynierowie DevOps:

Junior - 2 lata - 100 tys. rub.
Średni - 3 lata - 160 tys. rub.
Senior – 6 lat – 220 tys. rub.

Z doświadczeń „DevOps” wynika, że wykorzystano doświadczenia, które przynajmniej w jakiś sposób wpłynęły na SDLC.

Z powyższego wynika, że tak naprawdę firmom DevOps nie jest potrzebny, a ponadto, zatrudniając Administratora, mogłyby zaoszczędzić przynajmniej 50 procent pierwotnie planowanych kosztów, a ponadto mogłyby jaśniej określić obowiązki osoby, której szukają i szybciej zaspokoić potrzebę. Nie powinniśmy również zapominać, że jasny podział obowiązków pozwala nam zmniejszyć wymagania wobec personelu, a także stworzyć korzystniejszą atmosferę w zespole, ze względu na brak nakładania się obowiązków. Zdecydowana większość wolnych stanowisk jest pełna narzędzi i etykiet DevOps, ale nie opierają się one na rzeczywistych wymaganiach dla Inżyniera DevOps, a jedynie na prośbach o administratora narzędzi.

Proces szkolenia inżynierów DevOps również ogranicza się jedynie do zestawu konkretnych prac, narzędzi i nie zapewnia ogólnego zrozumienia procesów i ich zależności. Na pewno dobrze jest, gdy ktoś może wdrożyć AWS EKS przy użyciu Terraforma, w połączeniu z wózkiem bocznym Fluentd w tym klastrze i stosem AWS ELK dla systemu logowania w 10 minut, używając tylko jednego polecenia w konsoli, ale jeśli nie rozumie zasada przetwarzania samych logów i do czego są potrzebne, jeśli nie wiesz jak zbierać na nich metryki i śledzić degradację usługi, to nadal będzie ten sam enikey, który wie, jak korzystać z niektórych narzędzi.

Popyt tworzy jednak podaż i widzimy wyjątkowo przegrzany rynek na stanowisko DevOps, gdzie wymagania nie odpowiadają faktycznej roli, a jedynie pozwalają administratorom systemów zarabiać więcej.

Kim oni są? DevOps czy chciwi administratorzy systemu? =)

Jak żyć dalej?

Pracodawcy powinni bardziej precyzyjnie formułować wymagania i szukać dokładnie tych, którzy są potrzebni, a nie rzucać etykietkami. Nie wiesz, czym zajmuje się DevOps – w takim razie nie potrzebujesz ich.

Pracownicy - uczcie się. Stale pogłębiaj swoją wiedzę, patrz na całościowy obraz procesów i śledź drogę do celu. Możesz stać się kimkolwiek chcesz, wystarczy spróbować.

Źródło: www.habr.com

Kim są DevOps?