Właśnie rozmawiałem z facetem DevOps, który podniósł kilka naprawdę dobrych argumentów na temat zmagań bycia Inżynierem DevOps i czasami czuję się armią jednoosobową, nawet jeśli jest w drużynie 16 inżynierów.

Nosi wiele różnych czapek, ale siedzi w zespole programistów i zajmuje się infrastrukturą. Uwielbia fajną technologię, z którą współpracuje - mnóstwo automatyzacji, chmury, konteneryzacji itp. Ale walczy o to, że jest jedyną osobą opsw devzespole. Podlega kierownikowi ds. Rozwoju, ale ściślej współpracuje z zarządcą infrastruktury.

Wydaje się, że tak jest w przypadku wielu specjalistów DevOps, z którymi rozmawiam. Co można zrobić, aby inżynierowie DevOps poczuli się mniej jak samotny wilk?

Moją pierwszą myślą jest: „dlaczego jest jedyną osobą, która robi operacje w zespole deweloperów, szczególnie gdy zaczyna pracować z dużą ilością automatyzacji?”. Myślę, że jest tam okazja, aby zająć się zespołem samotnego wilka; szczególnie w środowisku programistycznym infrastruktura jako kod stanowi doskonałą platformę do dzielenia obciążenia. Ludzie operacyjni powinni być ekspertami w określaniu i definiowaniu potrzeb infrastrukturalnych w zakresie aplikacji, ale powinni też być w stanie zbudować platformę, aby umożliwić programistom wykonywanie jak największej liczby zadań niezależnie.

To brzmi jak silos w zespole; stare zwyczaje umierają ciężko. Koder może nie czuć się komfortowo obracając i utwardzając serwer, ale w modelu czysto devops powinien mieć do tego odpowiednie narzędzia. Osoba działająca w zespole deweloperów nie powinna być odpowiedzialna za dostarczanie infrastruktury dla samej aplikacji, ale powinna zapewnić wgląd w to, co jest potrzebne, oraz wskazówki, jak twórcy aplikacji mogą to zrobić sami. To prawie model meta-infrastruktury; inżynierowie ops budują infrastrukturę, która może budować infrastrukturę na żądanie na żądanie zespołu programistów.

Konsultacje, komunikacja i łączenie obowiązków są kluczowe dla sukcesu zespołu deweloperów.

Myślę, że pierwszą wadą jest to zdanie:

Podlega kierownikowi ds. Rozwoju, ale ściślej współpracuje z zarządcą infrastruktury.

DevOps to zmiana kulturowa mająca na celu usunięcie silosów. Jeśli pozostaną silosy, to ten inżynier, jak chcesz go nazwać, nazwij go; inżynier zajmujący się rozwojem operacyjnym, ekspert automatyzacji, programista automatyzujący infrastrukturę - ale ten inżynier nie jest inżynierem DevOps.
W rzeczywistości „DevOps Engineer” nie jest prawdziwą rolą , jest raczej „chapeau”, ponieważ może obejmować programistów, administratorów systemu, testerów kontroli jakości i architektów pracujących we wspólnym zespole.

Problem, który często widzę, polega na tym, że ludzie wpadają w modne użycie DevOps, widząc to jako tytuł pracy, ale tak naprawdę nie rozumieją, czym jest DevOps. Oglądając DevOps w ten sposób, często kończą się izolacją i czują się osamotnieni, obwiniając niepowodzenia i niedociągnięcia za to, że są „samotnymi wilkami” bez wkładu menedżerskiego i organizacyjnego.

Jak to opisujesz, ten inżynier jako jedyny robi Ops w zespole deweloperów. To nie czyni go „inżynierem DevOps”. (Cokolwiek to oznacza w jego organizacji) Pracuje w izolacji, ponieważ zadanie jest przedstawiane jako „DevOps Engineer”, ale wygląda na to, że inne osoby w jego zespole nie chcą pracować nad operacjami.

Bądźmy szczerzy, zawsze będą ops i dev, główna idea devops polega na dzieleniu się obowiązkami, tak aby nie było przekazywania produktu z dev na ops lub po prostu dostarczanie platform przez ops dla dev. Podstawowym celem jest zwiększenie współpracy w zespole. Nazywanie tej roli „inżynierem DevOps” przełamuje ten pomysł, sugerując w nazwie, że możesz robić obie rzeczy na tym samym poziomie wiedzy - co rzadko jest prawdą.

Moim zdaniem pierwszą rzeczą byłoby przedstawienie zespołowi narzędzi operacyjnych i przekazanie wszystkim podstawowej wiedzy na temat narzędzi, a następnie przeniesienie odpowiedzialności za konfigurowanie / kodowanie narzędzi operacyjnych na cały zespół. Główną ideą tego jest przejście od „tego, który robi wszystkie operacje” do „tego, który wspiera i udziela referencji implementacjom zespołowi”.

Uzupełnia to inne odpowiedzi, zapewniając coś, co można wykonać w prostszy sposób, jako pierwszy krok niż reorganizacja zarządzania.

Najważniejszą rzeczą dla inżynierów DevOps w takich sytuacjach jest uzyskanie (a) zobowiązania do zarządzania i (b) wymaganych budżetów . Czytaj dalej, aby uzyskać więcej informacji na temat obu ...

Uzyskaj zaangażowanie w zarządzanie

Gdy to nastąpi, inżynierowie DevOps stają się łatwiejsi. Zwłaszcza za każdym razem, gdy pojawia się opór (z różnych stron). Zaufaj mi, pojawi się taki opór, który stawi wyzwania:

• Dlaczego musimy się zmienić? Chcę robić to, co robiłem już od X lat!
• Nie chcę tracić mocy (technicznej), którą mam, i wykonywać wszelkiego rodzaju procedury przepływu pracy, aby uzyskać głupie poprawki w produkcji, które powinny zająć mi około 5 minut zamiast 5 godzin (lub dni ...).
• ... (Mógłbym tu dodać jeszcze kilkanaście pocisków ...).

Za każdym razem, gdy pojawiają się te wyzwania, wszyscy inżynierowie DevOps powinni powiedzieć:

Przepraszam, po prostu wykonuję swoją pracę ... na podstawie instrukcji od kierownictwa wyższego szczebla.

Uzyskaj wymagane budżety

Skutecznym sposobem na uzyskanie wymaganych budżetów jest stworzenie / przesłanie odpowiedniego uzasadnienia biznesowego, które wyjaśnia namacalne i niematerialne korzyści wynikające z różnych praktyk DevOps poprzez zastosowanie ich do niektórych rzeczywistych przypadków, które dotyczą samej firmy.

Poniżej znajdują się przykłady prawdziwych przypadków, których sam doświadczyłem, jako konsultant SCM zatrudniony przez niektóre firmy, w których takie rzeczy miały miejsce. Wiem, że SCM jest tylko częścią DevOps, ale w tym obszarze mam trochę wiedzy ...

1. Korzyści z automatyzacji

Ze względu na strajk tylko od 2 (!!!) operatorów komputerowych (którzy nie wpisywali już poleceń konsoli, które, jak się spodziewali, będą pisać), pociągi musiały zostać zatrzymane gdzieś w połowie drogi między dwiema fabrykami (od czasu fabrycznego systemu tam, gdzie pociąg jechał, przestały istnieć istotne dane dotyczące obsługi pociągu).

Dzięki wdrożeniu systemu SCM wiele poleceń operatora zostało zautomatyzowanych.

2. Zmniejsz koszty licencji oprogramowania

Niektórzy dostawcy oprogramowania postanowili podnieść niektóre roczne opłaty za (nieaktualne) oprogramowanie SCM, na co kierownictwo nie wyraziło zgody. Dlatego stworzyli specjalny projekt, aby zastąpić je jakimś alternatywnym oprogramowaniem SCM.

Budżet projektu był równy rocznej opłacie, której nie chcieli płacić. Obejmowało to latanie inżynierem z innych kontynentów (takich jak ja), aby projekt odniósł sukces.

3. Zmniejsz koszty operacyjne

Pewna duża firma ubezpieczeniowa używała oprogramowania FTP do przesyłania poprawek oprogramowania do około 13 000 komputerów średniej klasy (AS / 400) w całym kraju, i to za każdym razem, gdy stała się dostępna „poprawka”. Koszt 1 takiego przelewu wynosił około 4 USD (13 000 x 4 = 52,000 USD za pojedynczy przelew ...). Oprogramowanie składało się ze 120 000 komponentów, opracowanych / obsługiwanych przez około 150 programistów. Zrób matematykę na temat prawdopodobieństwa, że ​​1 deweloper popełnił 1 (malutki) błąd w którymkolwiek z tych 120 000 komponentów, co doprowadziło go do produkcji, i wymagał pilnej naprawy, która kosztowałaby kolejne 52 000 USD (tylko za transfer!).

Dzięki wdrożeniu odpowiedniego systemu SCM (z zarządzanymi środowiskami testowymi, zatwierdzeniami itp.) Firma osiągnęła znaczną redukcję kosztów. Pomyśl o tym, jeśli system SCM mógłby zapobiec potrzebie tylko 20 przeniesień pilnych poprawek, spowodowałoby to redukcję kosztów o 52 000 x 20 = 1 040 000 USD (dość duży budżet na wdrożenie systemu SCM, potrzebowali tylko ułamka tej kwoty, aby wykonać zadanie).

4. Zmniejsz koszty niedostępności

Jeśli powyższe przypadki nie są wystarczająco przekonujące, pomyśl o tym, że system (y) jednej z głównych firm obsługujących karty kredytowe są niedostępne na całym świecie. Powiedziano mi, że 1 sekunda niedostępności kosztuje ich 1.000.000 USD.

Jest to prawdopodobnie również powód, dla którego takie firmy już od wielu dziesięcioleci dysponują zaawansowanymi narzędziami DevOps. Ponieważ w każdej sekundzie nie ma ich w biznesie, kosztuje ich fortunę.

TL; DR: Ponieważ kierownictwo jest zwykle kapryśne i podatne na gniew, sugerowałbym, aby spróbować nieco pochylić umysł, aby uzyskać inną perspektywę, stopniowo zmieniając rzeczy na lepsze.

(Jestem przy założeniu, że jego problem jest głównie z niechętnych deweloperów , a nie inne jego ops kolegów, którzy zdają się robić operacji klasycznych głównie).

IMO, nawet jeśli masz DevOps, nie musi to oznaczać, że każdy programista musi być pełnoprawnym guru DevOps. Uważam, że to normalne, że w danej grupie ludzi będzie jeden lub dwóch prawdziwych ekspertów, a reszta będzie mniej więcej taka. Tak długo, jak obciążenie nie jest zbyt duże dla tego faceta i dopóki uda mu się zgromadzić swoją wiedzę w skryptach itp. Zamiast budować własny silos, nie mam nic przeciwko.

Jedyną rzeczą, która nie powinna się zdarzyć, jest to, że facet DevOps wykonuje swoją automatyzację, a wszyscy inni starają się jak najlepiej ominąć wspomnianą automatyzację (tzn. Ominąć potok CI / CD i robić rzeczy ręcznie w jednym ze środowisk). To, IMO, jest najważniejsze, aby się zatrzymać. Jednym z rozwiązań byłoby bardzo mocno naciskać na podejście zwierząt bez zwierząt domowych, tj. Nieubłaganie burzyć maszyny wirtualne lub pojemniki w lewo i w prawo tak szybko, jak to możliwe, i ciągle obracać nowe.

Po drugie, oczywiście wszyscy muszą być świadomi tego, co robi automatyzacja, a przynajmniej teoretycznie, przy odrobinie przekopania, być może być w stanie uruchomić maszynę automatyzacji (tj. Jeśli wszystko działa od zatwierdzenia / wypchnięcia, wtedy deweloperzy muszą być świadomi i bardzo na bieżąco z faktem, że w tle będą się działo rzeczy, które popełnią). Potok CI (/ CD) musi być dość widoczny i powinien być czymś, o czym wszyscy są stale świadomi (tj. Kiedy deweloper go zepsuje).

Po trzecie, „jeden facet” oczywiście musi uważać, aby nie wykonywał dla swoich kolegów codziennych zadań (np. Tworzenie Dockerfile po Dockerfile dla ich artefaktów ...).

Po czwarte, rozwiązania, które tworzy facet DevOps, muszą być rzeczywiście lepsze niż ręczne podejścia z przeszłości w jakiś wymierny sposób. W takim przypadku powinien mieć możliwość wykazania swoich ulepszeń; tzn. zademonstruj, jak wszystko staje się łatwiejsze dla wszystkich, lub jak wydaje się niemożliwe wprowadzanie błędów na późniejszych etapach potoku itp. Jeśli nie wydaje się to możliwe, to facet DevOps musi dobrze się przyjrzeć on robi. Jeśli to możliwe, to wymaga sesji brownbag i dużo ewangelizacji w swoim zespole.

Oczywiście, w tak niechętnym środowisku, prawdopodobnie w najbliższym czasie nie dojdziesz do całkowicie zautomatyzowanego rozwiązania CD lub rozwoju opartego na bagażniku. Ale nie martwiłbym się zbytnio wyróżnieniem. Jest ekspertem, a jeśli dobrze wykonuje swoją pracę, cały zespół będzie się stopniowo poprawiał.

I wreszcie, jeśli po latach pracy nie widać widocznej poprawy u jego kolegów, zawsze można szukać innych dróg (czy to wewnątrz czy na zewnątrz firmy). Posiadanie za sobą całego doświadczenia DevOps jest doskonałą bazą do szukania pracy, w dzisiejszych czasach ...

Widzę tu wiele świetnych odpowiedzi na temat DevOps jako kultury, sugestie dotyczące pracy z kierownictwem oraz pomoc w definiowaniu czynności i działań zespołu lub inżyniera DevOps. Myślę, że każda z nich jest świetna i naprawdę ilustrująca wiele odpowiedzi może być w 100% słuszna i nadal być bardzo odmienna, a nawet całkowicie dwuznaczna ... To DevOps!

Ta odpowiedź jest po prostu moją wyjątkową perspektywą z doświadczenia i może nie wskazywać norm lub najlepszych praktyk ...

Ale na co narzekał twój kolega z DevOps, to właśnie natura sprawia, że ​​DevOps jest trudny i trudny , zwłaszcza gdy zostaje mianowany inżynierem DevOps, a nie tylko kulturowym nastawieniem.

Osobiście lubię być samotnym wilkiem, ponieważ wciąż wnoszę cenny wkład, ale także potrafię wyznaczać własne granice, jednocześnie przekonując innych do pomocy sobie, pomagając mi w ten sposób rozbić silosy IT.

Niektóre silosy pozostają nienaruszone , i to jest w porządku, misją DevOps jest obejście tego i próba uczynienia tych silosów tak nieznacznymi lub niewidocznymi, jak to możliwe.

Możliwe, że twój współpracownik zdaje sobie sprawę lub jeszcze nie zdawał sobie sprawy, że nie lubi być inżynierem DevOps .

Mówiąc relatywnie, koncepcja devops jest nowa i nadal moim zdaniem się określa. Obecnie pełnię rolę inżyniera Devopsa. Dla mnie oznacza to, że ułatwiam i rozwijam narzędzia i procesy stosowane zarówno przez nasze zespoły programistów, jak i operatorów, pozwalając im skupić się na produkcie, który generuje przychody dla firmy. Zespoły operacyjne i deweloperskie uruchamiają własne serwery i tak dalej, jak to konieczne. Po prostu podłączam CI do naszych produktów, upewniam się, że nasze procesy mają sens i szukam, który proces można ulepszyć / zautomatyzować. Spotykam się ze wszystkimi naszymi działami, od sprzedaży, przez magazyn, po deweloperów i operacje (kierownicy ds. Kontroli jakości i wydania), aby zobaczyć, co robią i jak mogę usprawnić ich proces.

Dla mnie DevOps oznacza, że ​​rozwój i działanie systemu oprogramowania staje się obowiązkiem jednego zespołu, a nie oddzielnych zespołów programistów i operacyjnych. To ulica dwukierunkowa. Najlepsze zespoły składają się z osób w kształcie litery „ T ”, które są ekspertami w jednej dziedzinie i znają kilka powiązanych dziedzin.

• Oczekuje się, że członkowie zespołu z doświadczeniem Ops będą robić to, co robią najlepiej (tj. Ops), uczyć podstaw tego, co robią najlepiej (tj. Ops) innym, a także uczyć się i wykonywać prace w powiązanych dziedzinach (tj. Zadania deweloperskie).
• Oczekuje się, że członkowie zespołu z doświadczeniem deweloperów będą robić to, co robią najlepiej (tj. Deweloperzy), nauczać innych tego, co robią najlepiej (tj. Deweloperzy), a także uczyć się i wykonywać prace w powiązanych dziedzinach (tj. Zadania operacyjne).

Aby więc inżynier DevOps poczuł się mniej jak samotny wilk, poproś go, aby nauczył programistów obsługi systemów, jednocześnie uznając, że jest ekspertem w projektowaniu infrastruktury.

Zaangażuj go od samego początku w architekturę wysokiego poziomu, aby mógł przedstawić obawy związane ze swoją specjalizacją. (Zanim mieliśmy DevOps, nasze rysunki architektury zawsze błyszczały na „drobiazgach”, takich jak usługi równoważenia obciążenia i nadmiarowe serwery. Teraz takie rzeczy są częścią pierwszych szkiców.)

Spodziewaj się, że deweloperzy podejmą się niektórych codziennych rutynowych zadań operacyjnych, zarówno w celu zapewnienia redundancji zespołowi, jak i sprawiedliwego rozłożenia zadań „znużenia”.

Spodziewaj się, że przyczyni się do wysiłku deweloperów, jeśli nie będziesz musiał wykonać podobnych do Ops zadań. Niektóre DevOps, które znam, uważają, że praca z bazą danych jest naturalnym rozszerzeniem ich zakresu wiedzy, nie jestem pewien, czy można to uogólnić.

Co można zrobić, aby inżynierowie DevOps poczuli się mniej jak samotny wilk?

Parafrazując - co może inżynierem devops zrobić sam / sama się czuć mniej jak samotny wilk?

Brak wsparcia w zakresie kultury i zarządzania to tylko jedna część równania. Z drugiej strony moim zdaniem szczegółowość wiedzy DevOps często odnosi się do skomplikowanych kontekstów i ważne jest, aby mieć porady i odniesienia do przykładów roboczych.

Dlatego - nie czuj się samotnym wilkiem; uczestniczyć w społecznościach DevOps, takich jak ta tutaj, lub grupach narzędzi i GitHub - przynajmniej tak nie jest, nie jesteś jedynym samotnym wilkiem ;-)