Ostatnio takie ogłoszenia zalały internet. Pomimo atrakcyjnego wynagrodzenia, nie może nie niepokoić, że w środku zapisano dziką bzdurę. Na początku zakłada się, że „DevOps” i „inżynier” można jakoś połączyć w jedno słowo, a potem idzie losowa lista wymagań, z których część jest oczywiście skopiowana z ogłoszenia o pracy dla administratora systemów.
W tym poście chciałbym trochę porozmawiać o tym, jak doszliśmy do tego etapu, czym tak naprawdę jest DevOps i co teraz z tym robić.
Takie oferty pracy można różnie oceniać, ale fakt pozostaje faktem: jest ich wiele, a rynek jest obecnie taki, a nie inny. Zorganizowaliśmy konferencję DevOps i otwarcie mówimy: „ — nie dla inżynierów DevOps”. Tu wielu wyda się to dziwne i szalone: dlaczego ludzie, organizujący całkowicie komercyjne wydarzenie, idą pod prąd rynku. Teraz wszystko wyjaśnimy.
O kulturze i procesach
Zacznijmy od tego, że DevOps to nie jest dyscyplina inżynieryjna. Wszystko zaczęło się od tego, że historycznie ustalone podziały ról nie działają na jakość produktów. Kiedy programiści tylko programują, ale nie chcą nic wiedzieć o testowaniu — oprogramowanie jest pełne błędów. Kiedy administratorzy ignorują, jak i dlaczego napisano oprogramowanie — wsparcie staje się piekłem.
Na przykład opis różnicy między podejściem administratora systemów a SRE do zarządzania usługami . Ciekawe badania przeprowadzono w ramach — widać, że najlepsi deweloperzy w jakiś sposób są w stanie wprowadzać nowe zmiany na produkcji szybciej niż raz na godzinę. Oni również testują ręcznie nie więcej niż 10% (co widać po ). Jak oni to robią? „Excel lub umrzyj” – mówi jeden z tytułów raportu. Po szczegółowe omówienie tej statystyki w kontekście testowania można zwrócić się do keynote'u Barucha Sadogurskiego na naszej innej konferencji, Heisenbug.
„Kiedy w towarzystwie brak zgody,
Na ich sprawę nie pójdzie,
I nie będzie z niej rzeczy, tylko męka.
Pewnego razu Łabędź, Rak i Szczupak…”
Jak myślicie, która część programistów webowych naprawdę rozumie, w jakich warunkach ich aplikacje działają na produkcji? Ile z nich podejdzie do administratorów i spróbuje zrozumieć, co się stanie w przypadku awarii bazy danych? A kto z nich pójdzie do testerów i poprosi, żeby nauczyli, jak poprawnie pisać testy? A na dodatek są jeszcze specjaliści ds. bezpieczeństwa, menedżerowie produktów i cała masa innych osób.
Ogólna idea DevOps polega na poprawie współpracy między rolami i działami. Przede wszystkim osiąga się to nie za pomocą jakiegoś zaawansowanego oprogramowania, ale przez praktykę komunikacji. DevOps dotyczy kultury, praktyki, metodologii i procesów. Nie ma takiego zawodu inżynieryjnego, który odpowiadałby na te pytania.
Błędne koło
Skąd zatem wzięła się dyscyplina «inżynierii devops»? Mamy swoją wersję! Pomysły DevOps okazały się tak dobre — na tyle dobre, że stały się ofiarą własnego sukcesu. Wokół tej tematyki zaczęli kręcić się jacyś podejrzani rekruterzy i handlarze ludźmi, którzy mają swoją specyficzną atmosferę.
Wyobraźcie sobie: wczoraj w Chimkach przygotowywaliście shawarmę, a dzisiaj — jesteście już wielką osobą, senior rekruterem. Jest cały proces poszukiwania i selekcji kandydatów, to wszystko nie jest proste, trzeba zrozumieć. Załóżmy, że kierownik działu mówi: znajdź specjalistę od X. Dopisujemy do X słowo «inżynier», i sprawa załatwiona. Potrzebny Linux? No to na pewno inżynier Linuxa, chcesz DevOps — to inżynier DevOps. Reklama pracy składa się nie tylko z tytułu, ale w środku trzeba wpisać jakiś tekst. Najłatwiej wpisać zestaw słów kluczowych z Google, kto ile ma wyobraźni. DevOps składa się z dwóch słów — «Dev» i «Ops», więc trzeba skleić słowa kluczowe dotyczące programistów i administratorów, wszystko w jedną całość. Tak powstają oferty pracy, które wymagają znajomości 42 języków programowania i 20-letniego doświadczenia w używaniu Kubernetes i Swarm jednocześnie. Tak działa system.
W świadomości ludzi ugruntował się bezsensowny i bezlitosny obraz pewnego superbohatera-«devopsa», który skonfiguruje wszystkim wdrożenia na Jenkinsie, a wtedy zapanuje szczęście. Ach, gdyby wszystko było tak proste. „A jeszcze tak można łapać administratorów sieciowych — myśli HR, — to modne słowo, słowa kluczowe te same, powinni złapać”.
Popyt rodzi podaż, a na te absurdalne oferty pracy napotkała szaloną ilość administratorów systemów, którzy zauważyli: można robić to samo, co wcześniej, ale zarabiając znacznie więcej, nazywając siebie "devopsami". Jak serwery były konfigurowane za pomocą SSH ręcznie jeden po drugim, tak i dalej będą, ale teraz to rzekomo praktyka devopsowa. To jakieś skomplikowane zjawisko, częściowo związane z niedocenianiem tradycyjnych adminów oraz z hype'em wokół DevOps, ale ogólnie — co wyszło, to wyszło.
Zatem mamy popyt i podaż. Zamyklony krąg, który sam się napędza. Z tym właśnie walczymy (m.in. tworząc konferencję DevOops).
Oczywiście, oprócz administratorów systemów, którzy przekształcili się w "devopsów", są również inni uczestnicy — na przykład profesjonalni SRE lub programiści Infrastructure-as-Code.
Czym ludzie zajmują się w DevOps (w rzeczywistości)
Zatem chcesz posunąć się naprzód w nauce i stosowaniu praktyk DevOps. Ale jak to zrobić, w którą stronę patrzeć? Oczywiście nie warto ślepo kierować się popularnymi słowami kluczowymi.
Jeśli praca istnieje, ktoś musi się nią zająć. Już ustaliliśmy, że to nie są "inżynierowie devops", więc kto? Wydaje się, że lepiej to sformułować nie w terminach stanowisk, lecz w konkretnych kierunkach pracy.
Po pierwsze, można zajmować się samym sercem DevOps — procesami i kulturą. Kultura to sprawa niełatwa i czasochłonna, a chociaż tradycyjnie jest to odpowiedzialność liderów, w tym uczestniczą wszyscy, od programistów po adminów. Kilka miesięcy temu Tim Lister :
"Kultura jest określana przez podstawowe wartości organizacji. Zwykle ludzie tego nie zauważają, ale my, pracując w konsultingu przez wiele lat, przyzwyczailiśmy się to dostrzegać. Wchodzisz do firmy i dosłownie po kilku minutach zaczynasz odczuwać, co się dzieje. Nazywamy to "aromatem". Czasami ten aromat jest naprawdę dobry. Czasami powoduje mdłości. (...) Nie możesz zmienić kultury, zanim nie zostaną zrozumiane wartości i przekonania, które stoją za konkretnymi działaniami. Zachowanie można łatwo obserwować, a znalezienie przekonań — trudno. DevOps to doskonały przykład tego, jak wszystko staje się coraz bardziej skomplikowane."
Jest też techniczna strona tego zagadnienia. Jeśli twój nowy kod trafia na testy za miesiąc, a w wydaniu pojawia się dopiero po roku, a przyspieszenie tego fizycznie jest niemożliwe — może się okazać, że do dobrych praktyk nie dojdzie. Dobre praktyki są wspierane przez dobre narzędzia. Na przykład, trzymając w głowie ideę Infrastructure-as-Code, można używać wszystkiego, od AWS CloudFormation i Terraform po Chef-Ansible-Puppet. Wszystkiego tego trzeba znać i umieć, i to już jest całkiem inżynieryjna dyscyplina. Ważne, aby nie mylić przyczyny ze skutkami: najpierw pracujesz według zasad SRE, a dopiero potem wcielasz te zasady w życie w postaci konkretnych rozwiązań technicznych. Przy tym SRE to bardzo złożona metodologia, która nie mówi o tym, jak skonfigurować Jenkins, ale o pięciu podstawowych zasadach:
- Ulepszanie współpracy między rolami i działami
- Akceptacja błędów jako nieodłącznej części pracy
- Stopniowe wprowadzanie zmian
- Wykorzystanie narzędzi i innych automatyzacji
- Pomiar wszystkiego, co można zmierzyć
To nie tylko zestaw stwierdzeń, lecz konkretne . Na przykład, w procesie akceptacji błędów trzeba będzie zająć się ryzykiem, zmierzyć dostępność i niedostępność usług za pomocą czegoś takiego jak SLI () oraz SLO (), nauczyć się pisać postmortemy i sprawić, aby pisanie ich nie było przerażające.
W dyscyplinie SRE używanie narzędzi to tylko jedna z części sukcesu, aczkolwiek nie mniej istotna. Musimy ciągle rozwijać się technicznie, obserwować, co dzieje się w świecie i jak można to zastosować w naszej pracy.
Obecnie bardzo popularne stały się rozwiązania Cloud Native. Zgodnie z nowoczesnym rozumieniem Cloud Native Computing Foundation, technologie Cloud Native umożliwiają organizacjom tworzenie i uruchamianie skalowalnych aplikacji w nowoczesnych dynamicznych środowiskach, takich jak chmury publiczne, prywatne i hybrydowe. Przykładem mogą być kontenery, service meshes, mikroserwisy, infrastruktura niezmienna i deklaratywne API. Wszystkie te techniki pozwalają na utrzymanie słabo powiązanych systemów elastycznymi, zarządzanymi i dobrze obserwowalnymi. Dobra automatyzacja pozwala inżynierom wdrażać duże zmiany często i z przewidywalnymi rezultatami, nie czyniąc z tego morderczego zadania. Wszystko to wspierane jest przez znane narzędzia, takie jak Docker i Kubernetes.
To dość skomplikowana i rozbudowana definicja, związana z tym, że obszar jest dość złożony. Z jednej strony twierdzi się, że nowe zmiany w tym systemie powinny być wprowadzane stosunkowo prosto. Z drugiej strony, aby zrozumieć, jak stworzyć pewne środowisko konteneryzowane, w którym słabo powiązane usługi funkcjonują w infrastrukturze zdefiniowanej programowo i są dostarczane tam za pomocą ciągłej integracji/ciągłego dostarczania (CI/CD), a wokół tego zbudować praktyki DevOps, trzeba sporo się nauczyć.
Co z tym wszystkim zrobić
Każdy rozwiązuje te problemy na swój sposób: na przykład można publikować normalne ogłoszenia o pracę, aby przerwać zamknięty krąg. Można zrozumieć, co znaczą słowa takie jak DevOps i Cloud Native, i używać ich poprawnie oraz sensownie. Można rozwijać się w obszarze DevOps i swoim przykładem demonstrować właściwe podejścia.
Organizujemy konferencję , która daje możliwość głębszego zrozumienia kwestii, o których właśnie rozmawialiśmy. W tym celu zaplanowano kilka grup wystąpień:
- Procesy i kultura;
- Site Reliability Engineering;
- Cloud Native;
Jak wybrać, dokąd iść? Jest tu subtelny moment. Z jednej strony, DevOps to kwestia interakcji, i chcemy, żebyś uczestniczył w wykładach z różnych bloków. Z drugiej strony, jeśli jesteś kierownikiem zespołu zajmującym się rozwojem, który przyjechał na konferencję, aby skupić się na jednym konkretnym zadaniu, nikt cię nie ogranicza – oczywiście, to będzie blok dotyczący procesów i kultury. Pamiętaj, że po konferencji otrzymasz nagrania (po wypełnieniu formularza zwrotnego), więc zawsze możesz obejrzeć mniej ważne wykłady później.
Oczywiste jest, że na samej konferencji nie możesz uczestniczyć jednocześnie w trzech ścieżkach, dlatego tak formujemy program, aby w każdej sesji były tematy na każdą zachciankę.
Pozostało tylko zrozumieć, co robić, jeśli jesteś inżynierem DevOps! Po pierwsze, spróbuj określić, czym tak naprawdę się zajmujesz. Zwykle to słowo lubi się używać do opisania:
- Programistów zajmujących się infrastrukturą. Dla ciebie najlepiej pasować będą grupy wykładów na temat SRE i Cloud Native.
- Administratorów systemów. Tutaj jest trudniej. DevOops to nie o administracji systemami. Na szczęście istnieje mnóstwo wspaniałych konferencji, książek, artykułów, filmów w internecie itp. na temat administracji systemami. Z drugiej strony, jeśli interesuje cię rozwój w obszarze kultury i procesów, zgłębiania technologii chmurowych oraz szczegółów życia z Cloud Native, to chętnie cię zobaczymy! Pomyśl o tym: zajmujesz się administracją, a co dalej? Aby nagle nie znaleźć się w nieprzyjemnej sytuacji, warto uczyć się już teraz.
Jest jeszcze jedna opcja: upierasz się i nadal twierdzisz, że jesteś właśnie inżynierem DevOps i w żaden inny sposób, cokolwiek to oznacza. W takim razie musimy cię zasmucić, DevOops to konferencja nie dla inżynierów DevOps!
Slajd z w Monachium
DevOops 2020 Moscow odbędzie się 29-30 kwietnia w Moskwie, bilety są już dostępne .
Ponadto możesz do 8 lutego. Zwróć uwagę, że przy wypełnianiu formularza musisz wybrać docelową grupę odbiorców, której twój wykład przyniesie największą korzyść (w liście ukryta jest niespodzianka).
Źródło: habr.com
