Ostatnio tego typu reklamy zalały Internet. Pomimo przyjemnej pensji nie można powstrzymać się od wstydu, że w środku zapisana jest dzika herezja. Na początku zakłada się, że „DevOps” i „inżynier” można w jakiś sposób skleić w jedno słowo, a następnie pojawia się losowa lista wymagań, z których część jest wyraźnie skopiowana z wakatu administratora systemu.
W tym poście chciałbym trochę opowiedzieć o tym jak dotarliśmy do tego momentu w życiu, czym tak naprawdę jest DevOps i co teraz z nim zrobić.
Takie wakaty można potępiać w każdy możliwy sposób, ale faktem jest, że jest ich wiele i tak obecnie działa rynek. Zorganizowaliśmy konferencję devops i otwarcie deklarujemy: „ - nie dla inżynierów DevOps.” Dla wielu będzie to dziwne i szalone: dlaczego ludzie, którzy organizują całkowicie komercyjne wydarzenie, sprzeciwiają się rynkowi. Teraz wszystko wyjaśnimy.
O kulturze i procesach
Zacznijmy od tego, że DevOps nie jest dyscypliną inżynierską. Wszystko zaczęło się od tego, że historycznie utrwalony podział ról nie przekłada się na jakość produktów. Kiedy programiści tylko programują, ale nie chcą słyszeć nic o testowaniu, oprogramowanie jest zaśmiecone błędami. Kiedy administratorów nie interesuje, jak i dlaczego oprogramowanie jest napisane, wsparcie zamienia się w piekło.
Na przykład opisanie różnicy pomiędzy administratorem systemu a podejściem SRE do zarządzania usługami . Przeprowadzono w nim ciekawe badania — jasne jest, że najlepszym programistom udaje się wdrażać nowe zmiany na produkcję szybciej niż raz na godzinę. Testują rękami nie więcej niż 10% (można to zobaczyć z ). Jak oni to robią? „Excel or die” – głosi jeden z nagłówków raportu. Szczegółowe omówienie tych statystyk w kontekście testów można znaleźć w przemówieniu Barucha Sadogursky'ego na naszej drugiej konferencji, Heisenbug.
„Kiedy nie ma zgody wśród towarzyszy,
Ich biznes nie pójdzie dobrze,
I z niego nie wyjdzie, tylko mąka.
Dawno, dawno temu łabędź, rak i szczupak..."
Jak myślisz, która część programistów internetowych naprawdę rozumie warunki, w jakich ich aplikacje są wykorzystywane w środowisku produkcyjnym? Ilu z nich trafi do administratorów i spróbuje dowiedzieć się, co się stanie, jeśli baza danych ulegnie awarii? A który z nich pójdzie do testerów i poprosi ich, aby nauczyli ich, jak poprawnie pisać testy? Są też ochroniarze, menedżerowie produktu i mnóstwo innych osób.
Ogólną ideą DevOps jest stworzenie współpracy pomiędzy rolami i działami. Przede wszystkim osiąga się to nie za pomocą sprytnie skonfigurowanego oprogramowania, ale poprzez praktykę komunikacji. DevOps to kultura, praktyki, metodologia i procesy. Nie ma specjalności inżynierskiej, która mogłaby odpowiedzieć na te pytania.
Błędne koło
Skąd w takim razie wzięła się dyscyplina „devops Engineering”? Mamy wersję! Pomysły DevOps były dobre – tak dobre, że stały się ofiarami własnego sukcesu. Wokół całego tematu zaczęli kręcić się podejrzani rekruterzy i handlarze ludźmi, którzy mają swoją własną atmosferę.
Wyobraź sobie: wczoraj robiłeś shawarmę w Chimkach, a dziś jesteś już dużym mężczyzną, starszym rekruterem. Jest cały proces poszukiwania i selekcji kandydatów, wszystko nie jest proste, trzeba to zrozumieć. Załóżmy, że kierownik działu mówi: znajdź specjalistę w X. Przypisujemy X słowo „inżynier” i gotowe. Potrzebujesz Linuksa? Cóż, to zdecydowanie inżynier Linuksa, jeśli chcesz DevOps, to inżynier DevOps. Wakat składa się nie tylko z tytułu, ale także należy w nim wpisać tekst. Najłatwiej jest wpisać zestaw słów kluczowych z Google, w zależności od Twojej wyobraźni. DevOps składa się z dwóch słów – „Dev” i „Ops”, co oznacza, że musimy skleić w jeden stos słowa kluczowe związane z programistami i administratorami. Tak pojawiają się wakaty dotyczące znajomości 42 języków programowania i 20 lat jednoczesnego korzystania z Kubernetesa i Swarma. Schemat działania.
W ten sposób bezsensowny i bezlitosny obraz pewnego superbohatera „devops” zakorzenił się w umysłach ludzi, którzy skonfigurują wszystkich, aby wysłali do Jenkinsa, a szczęście nadejdzie. Ach, gdyby wszystko było takie proste. „I w ten sposób można też dopaść administratorów systemów” – uważa dział HR. „To modne słowo, słowa kluczowe są takie same, powinni chwycić przynętę”.
Popyt tworzy podaż, a wszystkie te śmieciowe wakaty zostały obsadzone przez szaloną liczbę administratorów systemu, którzy zdali sobie sprawę: możesz robić wszystko tak samo jak wcześniej, ale zyskać kilka razy więcej, nazywając siebie „devops”. Tak jak konfigurowałeś serwery pojedynczo ręcznie przez SSH, będziesz je nadal konfigurował, ale teraz jest to podobno praktyka devops. Jest to pewnego rodzaju złożone zjawisko, częściowo związane z niedocenianiem klasycznych adminów i szumem wokół DevOps, ale ogólnie rzecz biorąc, stało się, co się stało.
Mamy więc podaż i popyt. Błędne koło, które samo się napędza. Z tym właśnie walczymy (m.in. tworząc konferencję DevOops).
Oczywiście oprócz administratorów systemu, którzy zmienili nazwę na „devops”, są też inni uczestnicy – na przykład profesjonalni SRE lub programiści zajmujący się infrastrukturą jako kodem.
Co ludzie robią w DevOps (naprawdę)
Chcesz więc osiągnąć postęp w uczeniu się i stosowaniu praktyk DevOps. Ale jak to zrobić, w którą stronę patrzeć? Oczywiście nie należy ślepo polegać na popularnych słowach kluczowych.
Jeśli jest praca, ktoś powinien ją wykonać. Dowiedzieliśmy się już, że to nie są „inżynierowie Devops”, w takim razie kim są? Bardziej słuszne wydaje się sformułowanie tego nie w kategoriach stanowisk, ale konkretnych obszarów pracy.
Po pierwsze, możesz zająć się sercem DevOps — procesami i kulturą. Kultura to powolny i trudny biznes i choć tradycyjnie należy do obowiązków menedżerów, wszyscy są w to zaangażowani w ten czy inny sposób, od programistów po administratorów. Kilka miesięcy temu Tim Lister :
„Kulturę wyznaczają podstawowe wartości organizacji. Zwykle ludzie tego nie zauważają, ale po wielu latach pracy w konsultingu jesteśmy przyzwyczajeni, że to zauważamy. Wchodzisz do firmy i dosłownie po kilku minutach zaczynasz czuć, co się dzieje. Nazywamy to „smakiem”. Czasami ten zapach jest naprawdę dobry. Czasami powoduje nudności. (...) Nie da się zmienić kultury, dopóki nie zrozumie się wartości i przekonań stojących za konkretnymi działaniami. Zachowanie jest łatwe do zaobserwowania, ale poszukiwanie przekonań jest trudne. DevOps to świetny przykład tego, jak sprawy stają się coraz bardziej złożone.”
Oczywiście jest też część techniczna problemu. Jeśli Twój nowy kod zostanie przetestowany w ciągu miesiąca, ale zostanie wydany dopiero rok później, a przyspieszenie tego wszystkiego jest fizycznie niemożliwe, możesz nie spełniać dobrych praktyk. Dobre praktyki są wspierane dobrymi narzędziami. Na przykład, mając na uwadze ideę Infrastructure-as-Code, możesz użyć wszystkiego, od AWS CloudFormation i Terraform po Chef-Ansible-Puppet. To wszystko trzeba wiedzieć i umieć, a to już dość dyscyplina inżynierska. Ważne jest, aby nie mylić przyczyny ze skutkiem: najpierw pracuje się według zasad SRE, a dopiero potem wdraża się te zasady w postaci konkretnych rozwiązań technicznych. Jednocześnie SRE jest bardzo wszechstronną metodologią, która nie mówi, jak skonfigurować Jenkinsa, ale o pięciu podstawowych zasadach:
- Poprawiona komunikacja pomiędzy rolami i działami
- Akceptowanie błędów jako integralnej części pracy
- Wprowadzanie zmian stopniowo
- Korzystanie z narzędzi i innej automatyzacji
- Mierzyć wszystko, co da się zmierzyć
To nie jest jakiś zestaw stwierdzeń, ale konkretny . Na przykład na drodze do zaakceptowania błędów będziesz musiał zrozumieć ryzyko, zmierzyć dostępność i niedostępność usług za pomocą czegoś takiego jak SLI () i SLO (), naucz się pisać sekcje zwłok i spraw, aby ich pisanie nie było straszne.
W dyscyplinie SRE wykorzystanie narzędzi to tylko część sukcesu, choć istotna. Musimy stale rozwijać się technicznie, patrzeć co się dzieje na świecie i jak można to zastosować w naszej pracy.
Z kolei rozwiązania Cloud Native stały się obecnie bardzo popularne. Według dzisiejszej definicji Cloud Native Computing Foundation technologie Cloud Native umożliwiają organizacjom tworzenie i uruchamianie skalowalnych aplikacji w dzisiejszych dynamicznych środowiskach, takich jak chmury publiczne, prywatne i hybrydowe. Przykłady obejmują kontenery, siatki usług, mikrousługi, niezmienną infrastrukturę i deklaratywne interfejsy API. Wszystkie te techniki pozwalają luźno powiązanym systemom pozostać elastycznymi, łatwymi w zarządzaniu i wysoce obserwowalnymi. Dobra automatyzacja pozwala inżynierom na częste wprowadzanie dużych zmian i uzyskanie przewidywalnych wyników, nie czyniąc tego uciążliwym. Wszystko to wspierane jest przez stos znanych narzędzi, takich jak Docker i Kubernetes.
Ta dość skomplikowana i szeroka definicja wynika z faktu, że obszar ten jest również dość złożony. Z jednej strony argumentuje się, że nowe zmiany w tym systemie należy wprowadzić po prostu. Z drugiej strony, aby dowiedzieć się, jak stworzyć rodzaj kontenerowego środowiska, w którym luźno powiązane usługi działają w infrastrukturze zdefiniowanej programowo i są tam dostarczane przy użyciu ciągłego CI/CD, oraz zbudować wokół tego praktyki DevOps – wszystko to wymaga więcej niż ktoś zje psa.
Co z tym wszystkim zrobić
Każdy rozwiązuje te problemy na swój sposób: na przykład możesz opublikować normalne oferty pracy, aby przerwać błędne koło. Możesz dowiedzieć się, co oznaczają słowa takie jak DevOps i Cloud Native, i używać ich poprawnie i na temat. Możesz rozwijać się w DevOps i demonstrować właściwe podejścia na swoim przykładzie.
Robimy konferencję , co daje możliwość głębszego zagłębienia się w kwestie, o których właśnie rozmawialiśmy. W tym celu istnieje kilka grup raportów:
- Procesy i kultura;
- Inżynieria niezawodności miejsca;
- Natywny w chmurze;
Jak wybrać, dokąd pojechać? Jest tu pewien subtelny punkt. Z jednej strony DevOps polega na interakcji i bardzo zależy nam na tym, abyś uczestniczył w prezentacjach z różnych bloków. Z drugiej strony, jeśli jesteś menadżerem ds. rozwoju, który przyszedł na konferencję, aby skoncentrować się na jednym konkretnym zadaniu, to nikt Cię nie ogranicza – oczywiście będzie to blokada na procesach i kulturze. Pamiętaj, że po konferencji będziesz mieć nagrania (po wypełnieniu formularza opinii), dzięki czemu zawsze będziesz mógł obejrzeć mniej ważne prezentacje później.
Oczywiście na samej konferencji nie można iść trzema torami na raz, dlatego program organizujemy w taki sposób, aby w każdym przedziale czasowym tematyka była na każdy gust.
Pozostaje tylko zrozumieć, co robić, jeśli jesteś inżynierem DevOps! Najpierw spróbuj ustalić, czym właściwie się zajmujesz. Zwykle lubią nazywać to słowo:
- Deweloperzy pracujący nad infrastrukturą. Najbardziej odpowiednie dla Ciebie będą grupy raportów o SRE i Cloud Native.
- Administratorzy systemu. Tutaj jest to bardziej skomplikowane. DevOops nie polega na administrowaniu systemem. Na szczęście w Internecie jest mnóstwo znakomitych konferencji, książek, artykułów, filmów itp. na temat administracji systemami. Z drugiej strony, jeśli jesteś zainteresowany rozwojem w zakresie zrozumienia kultury i procesów, poznania technologii chmurowych i szczegółów życia z Cloud Native, to czekamy na Ciebie! Pomyśl o tym: zajmujesz się administracją i co wtedy będziesz robić? Aby uniknąć nagłego znalezienia się w nieprzyjemnej sytuacji, powinieneś uczyć się już teraz.
Jest inna opcja: upierasz się i nadal twierdzisz, że tak jest konkretnie inżynier DevOps i nic więcej, cokolwiek to znaczy. W takim razie musimy Cię rozczarować, DevOops nie jest konferencją dla inżynierów DevOps!
Przesuń z w Monachium
DevOops 2020 Moskwa odbędzie się w dniach 29-30 kwietnia w Moskwie, bilety są już dostępne .
Alternatywnie możesz do 8 lutego. Pamiętaj, że wypełniając formularz, musisz wybrać grupę docelową, która odniesie największe korzyści z Twojego raportu (na liście ukryta jest niespodzianka).
Źródło: www.habr.com