Dlaczego nie powinienem spróbować zatrudnić inżyniera DevOps?

Pomysł posiadania inżyniera DevOps stał się ostatnio dość popularny i wydaje się, że atrakcyjne jest po prostu posiadanie osoby, która może wpuszczać i zapewniać wiele korzyści DevOps, jak opisano na blogu Puppet :

Organizacje stosujące praktyki DevOps są w przeważającej mierze sprawnie działające: wdrażają kod do 30 razy częściej niż ich konkurenci, a 50 procent mniej wdrożeń kończy się niepowodzeniem, zgodnie z naszym raportem o stanie DevOps z 2015 roku.

Zauważyłem jednak duży sprzeciw wobec pomysłu Inżyniera DevOps, aby spróbować wprowadzić następujące ulepszenia:

Nawet przy szerokim porozumieniu co do podstawowych atrybutów DevOps, kontrowersje otaczają termin „inżynier DevOps”. Niektórzy twierdzą, że sam termin jest sprzeczny z wartościami DevOps. Jez Humble, współautor Continuous Delivery, zwraca uwagę, że po prostu nazywając kogoś inżynierem DevOps, oprócz dev i ops, można stworzyć trzeci silos - „... wyraźnie zły (i ironiczny) sposób na rozwiązanie tych problemów . ”

Dlaczego może nie być tak dobrym pomysłem dla firmy zatrudnienie inżyniera DevOps, aby spróbować „wdrożyć DevOps”, w przeciwieństwie do zmian organizacyjnych zalecanych przez takie blogi ? Czy korzyści zostaną zanegowane poprzez izolowaną rolę DevOps?

TL; DR : Nigdy nie powinieneś próbować zatrudnić zespołu DevOps

Istnieją zasadniczo trzy najczęstsze role do zatrudnienia:

1. DevOps Architect / Evangelist
2. DevOps Engineer
3. Inżynier CI / CD

Role te różnią się od 6 podstawowych ról programistycznych, które tradycyjnie składają się na organizację inżynierii oprogramowania:

1. Zarządzanie produktem
2. Rozwój oprogramowania
3. Rozwój narzędzi
4. Bezpieczeństwo i zgodność
5. Jakość i testowanie
6. Operacje systemowe (SRE)

Przejrzyjmy kolejno trzy role i zobaczmy, jak pasują

DevOps Architect lub Evangelist

• Dlaczego : Jeśli jesteś zagubiony, powolny, złamany i nie wiesz, co robić.
• Kiedy : na początku procesu na etapach planowania.
• Co : rola na poziomie zarządzania, która poprowadzi wszystkich menedżerów i liderów w całej organizacji ds. Inżynierii oprogramowania. Ta osoba zaplanuje całą transformację twojej organizacji inżynierskiej do wysoce funkcjonującego stanu.
• Kto : Członek konsultacyjny dobrze obeznany z teorią, praktykami zarządzania, tematami kultury i operacjami, który podlega bezpośrednio wiceprezesowi ds. Inżynierii oprogramowania.

W niektórych przypadkach oraz w przypadku mniejszych i średnich firm proces można rozpocząć od zatrudnienia organizacji konsultingowej, takiej jak DORA.

DevOps Engineer

• Dlaczego :
  1. Aby wypełnić luki między zespołami, jeśli są one zorganizowane zgodnie z wyżej wymienionymi rolami funkcjonalnymi, aby zapewnić współpracę między poziomami funkcjonalnymi.
  2. Aby współpracować z zespołami zorientowanymi na produkt, które mają każdą z 6 tradycyjnych ról wchodzących w skład zespołu, aby pomóc wypełnić luki w wiedzy oraz pomóc we wdrażaniu i wdrażaniu nowatorskich praktyk i narzędzi.
• Kiedy : Po opracowaniu planów i rozpoczęciu transformacji organizacyjnej cały zespół zarządzający jest na pokładzie.
• Co : Włącz współpracę międzyfunkcyjną, upewnij się, że granice zespołów są przełamane, a lokalne optymalizacje wewnątrz zespołów nie stanowią bariery dla wysokiej przepustowości pracy w łańcuchach wartości, od życzeń klientów po dostawy do klientów.
• Kto : Doświadczony inżynier posiadający umiejętności zarówno w zakresie tworzenia oprogramowania, jak i obsługi systemu. Powinien być wykwalifikowany w zakresie najlepszych praktyk, zmian procesów i kultury związanych z transformacją DevOps.

Inżynier CI / CD

• Dlaczego : Aby pomóc we wdrożeniu potoków CI / CD, zintegruj łańcuch narzędzi, wprowadź narzędzia, które umożliwią lepszą pracę firmy.
• Kiedy : Podczas przejścia w większej organizacji, gdy powyższe role zostały już wypełnione.
• Co : Inżynier, który jest zasadniczo częścią zespołu narzędzi, który będzie w stanie skonfigurować potoki CI / CD i rozpocząć integrację systemów wewnętrznych w sposób, który usunie tarcie z przepustowości pracy.
• Kto : Doświadczenie inżyniera w zakresie narzędzi, procesu integracji, zarządzania wersjami i praktyk DevOps. Ktoś, kto rozumie, że zastępuje ludzkie bramy w procesie wydawania przez Automation.

Argumentowałbym, że Devops Engineer, jak opisano w łączu do pytania, jest głównie rolą sysadmin. Przytaczając tutaj umiejętności dla tła tej odpowiedzi:

Twój sprzęt wspinaczkowy.

• Silne doświadczenie w administrowaniu Linux / Unix w zakresie automatyzacji / zarządzania konfiguracją za pomocą Puppet, Chef lub równoważnego
• Możliwość korzystania z szerokiej gamy technologii open source i usług w chmurze (wymagane jest doświadczenie z AWS)
• Duże doświadczenie w SQL i MySQL (NoSQL to także plus, ponieważ używamy również Redis)
• Sprawne rozumienie kodu i skryptu (PHP, Python, Perl i / lub Ruby)
• Znajomość najlepszych praktyk i operacji informatycznych w ramach zawsze dostępnej usługi

W tym przykładowym opisie zadania DevOps Engineer to po prostu modne słowo dla sysadmina znającego infrastrukturę opartą na chmurze, automatyzację, potrafiącą odczytać kod, aby pomóc w diagnostyce, i świadomą praktyk i rozwiązań wysokiej dostępności.

Jest to luźno związane z praktykami DevOps i kulturą niszczenia silosów między deweloperami a operacjami, jak widać w tym pytaniu. Jaka jest różnica między Sysadmin a inżynierem DevOps?

To nie będzie dobry pomysł, ponieważ sysadmin, bez względu na to, jak swobodnie może czuć się z praktyką i kulturą deweloperów, nie jest odpowiednią osobą do przeprowadzenia transformacji firmy. Nie będziesz zatrudniać tej osoby z myślą o zmianie kultury, ale z widokiem konfiguracji narzędzia, co tak naprawdę nie pomoże w przerwaniu procesów. Może to również zostać źle odebrane przez jego / jej kolegów, a ty po prostu oprzesz się zmianie, jeśli wcześniej nie zaplanujesz zmiany kultury

Aby uzyskać udany wzorzec w kierunku zdobywania devops, odpowiedź @ Jiri Klouda daje doskonały przegląd dopuszczalnej roli Inżyniera DevOps wraz z krokiem w kierunku zmiany, która przyniosłaby wartość i pomogła w osiągnięciu sukcesu.

Zdaję sobie sprawę, że ta odpowiedź może nie być dla Ciebie idealna, ale oto co zrobiłem

Byłem pierwszym programistą pracującym przy bardzo zajętym startupie e-commerce, z niewiarygodnie dużym ruchem. Zdaję sobie sprawę, że firma była jeszcze młoda i przez jakiś czas byłbym jedynym wewnętrznym zasobem technicznym.

Wiedząc o tym, zdecydowałem się na taką strukturę infrastruktury, że będę musiał zarządzać systemami ZERO.

Zdecydowałem się hostować w chmurze, ponieważ zwolniło mnie to z konserwacji systemów. Szukałem inżyniera AWS z doświadczeniem marionetkowym. Wspólnie zaprojektowaliśmy infrastrukturę skalowalną automatycznie, zapisaną jako kod w formacji chmurowej. Wszystkie pliki konfiguracyjne zostały wersjonowane w ramach marionetki.

To pozwoliło mi, jako programistom, przejąć rolę programistów. Zbudowałem narzędzia do uwalniania kodu, w Pythonie, w tkaninie. Użyłem tego samego skryptu, aby uruchomić aplikację na nowych serwerach, które są skalowane automatycznie.

Działa to bardzo dobrze, a dziś, 3 lata później, nadal nie wykonuję żadnej konserwacji systemu. Mamy administratora systemu (tego samego inżyniera AWS) przez 10 godzin miesięcznie, a ja próbuję zbudować jego sprinty w taki sposób, aby nie denerwować go. W ten sposób szanuję jego czas i najlepiej zarządzam jego sprintami.

Jeśli system ma obniżoną wydajność, po prostu go przerywam, a na jego miejscu obraca się inny.

Mam nadzieję, że ta odpowiedź może jakoś ci pomóc

Nie powinieneś zatrudniać inżyniera DevOps, ponieważ DevOps obejmuje tak szeroki zakres dyscyplin, że jedna osoba nie może być ekspertem we wszystkich aspektach tych dyscyplin. Zatrudniając Jacka wszystkich branż, zatrudniłbyś mistrza żadnego.

DevOps z konieczności jest przedsięwzięciem zespołowym i nie można oczekiwać, że jedna osoba spełni oczekiwania całego zespołu. Rozważ zakres DevOps. Jedna osoba nie może:

• Zostań programistą rockstar w [języku]
• Bądź guru sieci, znając wszystkie wymagane RFC
• Bądź exert Administratorem systemów
• Bądź ekspertem od testowania jakości
• Być administratorem bazy danych
• Specjalizujemy się w przechowywaniu i tworzeniu kopii zapasowych
• Poznaj inżynierię niezawodności witryny
• Potencjalnie także inne dyscypliny

Niektóre z wyżej nawet sub dyscyplin, takich jak Windows Systems Administrator vs. Administrator Linux / Unix system lub może użyć więcej niż jeden język kodowania w twojej.

Żadna osoba nie może być ekspertem w tym zakresie, co oznacza, że ​​jeśli reklamujesz się dla inżyniera DevOps, kiedy najsłabszym obszarem w zespole DevOps jest Networking, nie radzisz sobie zbyt dobrze z reklamowaniem swojej potrzeby specjalisty ds. Sieci dla twojego zespołu DevOps . Chociaż żadna osoba nie powinna być zaszufladkowana do konkretnej roli w zespole DevOps, zrobiłbyś swojemu zespołowi przysługę, udając, że nie ma żadnych specjalistów ani ekspertów merytorycznych (MŚP) w zakresie DevOps. Przesuwanie wahadła z jednej skrajności do drugiej - od silosu do udawania, jak każda rola w zespole DevOps jest taka sama - może powodować tyle samo problemów.

Podczas gdy członkowie zespołu trenują w więcej niż jednej dyscyplinie - szczególnie w nakładających się obszarach, dobrze jest oczekiwać, że będą w stanie biegle posługiwać się tak dużą ilością wiedzy, po prostu nie jest praktyką.

Oznacza to, że każdy, kto mówi ci, że zna wszystkie aspekty DevOps, prawdopodobnie cię okłamuje. Zatrudnij specjalistę w dziedzinie, w której jesteś najsłabszy, a która pracowała w zespole DevOps - a nie „Inżyniera DevOps”.

Miałem właśnie takie wyzwanie podczas wdrażania w ASOS. Naszym celem jest posiadanie zespołów, które są samowystarczalne, więc pełnienie dedykowanej roli może być anty-wzorcem, jednak żyjemy w prawdziwym świecie i dla wielu programistów myślenie o dobrych praktykach DevOps nie jest ich podstawową sprawą, dlatego potrzebują pomocy dostać się tam.

To, co zrobiliśmy, to:

• stracić kadencję inżynierów DevOps, DevOps to coś, co powinniśmy wszyscy zrobić, a nie nasz tytuł zawodowy, dlatego nazwaliśmy ich czymś innym.

• wdrożyłem je do zespołów, ale tylko 1 na 3, co oznaczało, że nie mogli być wykonawcami, ale musieli być postrzegani jako kompetencja, aby pomóc drużynom poprawić się i rozwiązać własne problemy (z wytycznymi)

• utrzymywał także centralną funkcję pełniącą rolę centrum kompetencji i zajmując się kwestiami związanymi z przedsiębiorstwem, wszystko, co dotyczy wszystkich zespołów

W trakcie ewolucji dokonujemy przeglądu tego modelu, ale dla nas działa on do tej pory skutecznie

Nie sądzę, że będziesz w stanie uzyskać ostateczną odpowiedź na to pytanie, ponieważ wydaje się, że bierze to pod uwagę wiele czynników.

• Jak na pokładzie firmy jest praktyka DevOps
• Jaki rodzaj aplikacji lub usługi zapewnia firma
• Struktura Twojej firmy

Właśnie skończyłem rozmowę kwalifikacyjną na stanowisko i skończyłem z tytułem inżyniera DevOps, ale część tego, co robię, to praca Sys Admin. Jest to po prostu konieczne z uwagi na wielkość firmy i charakter zarządzanych aplikacji. Niektóre stanowiska, z którymi przeprowadzałem wywiady, miały podobny tytuł i bardziej szukały kogoś ze strony programistycznej. Spodziewali się więcej pisania kodu, a nie administratora systemu, który zajmuje się automatyzacją. Wydaje się, że SRE zyskuje na popularności, więc może to być właściwa droga. Miałem siebie jako Administratora Systemu i Inżyniera Automatyki jako moją ostatnią pracę, ponieważ pisałem ansible, a szef kuchni stosował przez pewien czas. Firma stosowała całkiem dobry model devops, w którym wszyscy byli na pokładzie, a devs pracowali razem z ops, ale myślę, że ich przyszłość nie

Teraz, gdy jestem w tej pozycji, próbuję podnieść klakson w jakiejś automatyzacji i mamy problemy z ludźmi, które będziemy musieli rozwiązać. Ludzie przychodzą i odchodzą, a niektóre przepływy pracy zostały zaprojektowane, ponieważ ktoś inny zaprojektował to w ten sposób, a nie dlatego, że pasuje do tego, jak ludzie pracują.

Zasadniczo uważam, że powinieneś zorientować się w opisie stanowiska pracy i nie przejmować się tak bardzo tytułem, chyba że wiąże się to z jakimś zapłatą lub uważasz, że jeden lub drugi przyciągnie odpowiednie osoby.

Jeśli masz na myśli znaczenie DevOps i podążasz „jedną prawdziwą ścieżką”. Nie powinieneś zatrudniać inżyniera DevOps. Powinieneś zatrudnić inżyniera automatyzacji, inżyniera wdrażania, architekta platformy lub szereg innych ról, które robią to, czego potrzebujesz.

Jeśli bycie prawdziwym praktykiem DevOps nie jest dla ciebie ważne, możesz nazwać to jak chcesz.