Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



25.10.2019

Skalowalna infrastruktura

Red Hat OpenStack Platform 15
25.10.2019

Cienki klient 2.0

Windows Virtual Desktop
25.10.2019

Nowy sprzęt Microsoftu

Rodzina Surface się powiększa
24.10.2019

Serwery ARM

Oracle stawia na Ampere Computing
24.10.2019

Wszechstronny i elegancki

Dell XPS 15
10.10.2019

CYBERSEC EXPO - największe w...

Bezpieczeństwo cyfrowe nie jest problemem dotyczącym jedynie działów IT. Obecnie stanowi...
30.09.2019

Nowości w wirtualizacji

VMware World 2019
30.09.2019

Bezpieczeństwo mobile-first

Android 10

One man army

Data publikacji: 26-09-2019 Autor: Maciej Lelusz

Poszukiwany Inżynier DevOps! Architekt DevOps, Ninja DevOps… mam wrażenie, że te twory językowe wymyślane przez HR-owców można wyliczać w nieskończoność. Hype na określenie DevOps jest tak potężny, że na listach płac zaraz pojawią się Kierowcy DevOps.

 

Porażająca jest ta bezmyślność w użyciu słowa oznaczającego kulturę pracy w kontekście roli jednej osoby. To tak jakby napisać, że poszukuje się Inżyniera Feudalności albo Architekta Niewolnictwa, gdy w obu przypadkach chodziłoby o gościa obrabiającego pole. Jeszcze raz – DevOps to kultura pracy, a w zasadzie kultura dzielenia się wiedzą w zespole, który to po pewnych manewrach staje się zespołem działającym zgodnie z zasadami DevOps. Nie jest natomiast zespołem złożonym z devopsów…

Ten błąd interpretacji jest poważny, ponieważ wpływa na kształtowanie specjalizacji ludzi. Wymaga się bowiem od takiego devopsa, aby był nadczłowiekiem – taki one-man-army. Taka siłaczka. Ma kodować, pakować, konfigurować i automatyzować. Tańczyć kankana na każdej warstwie w stosie technologicznym, i to jeszcze używając 300 produktów z prędkością 300 bps. Na początku to może nawet wychodzić, ale na dłuższą metę taki model się nie skaluje – za dużo wszystkiego, a wiedza, którą posiada zespół, jest płytka. A mówimy tu o specjalistach, którzy mają mieć wiedzą głęboką, a nie o influencerach – architektach, którzy wiedzą o wszystkim po trochu. Tu odkrywamy kolejną warstwę problemu. Otóż w zespole złożonym z siłaczek DevOps każdy chce być influencerem, mnożą się spotkania, modele budowy i w zasadzie zaczyna się spalać energię na samoafirmację zamiast na dostarczanie produktu. Wydaje się, że powodem tego jest właśnie spłaszczenie specjalizacji źle rozumianą definicją DevOps.

Tymczasem powinno to wyglądać tak, że jest sobie powiedzmy ośmioosobowy zespół produktowy działający w kulturze DevOps – Product Owner, Developer Fronted, Backend, DBA, Cloud Engineer (czy on-prem, czy chmura publiczna, to sprawa drugorzędna), Solution Architect, Site Reliability Engineer i Ops. Każdy z nich jest turbospecjalistą w swojej działce, a kultura DevOps realizowana jest w taki sposób, że DBA jest np. świadomy tego, że jak projektuje strukturę bazy, to musi brać pod uwagę limity architektoniczne storage’u i backupu, a Developer, pisząc fronted, jest świadomy, że będzie on musiał być monitorowany, a potem skalowany i możliwie jak najbardziej stateless, tak aby SRE mogli później sobie z nim poradzić. Tu chodzi o świadomość warstw, a nie specjalizację w nich. Ma to zaowocować tym, że orając swój ogródek, trzeba to robić tak, aby nie uprzykrzać życia wszystkim wokół. Tworzymy swoje rzeczy, mając świadomość całego ekosystemu dookoła. Tak jak dev musi być świadomy tego, że jego aplikacja będzie działać w określonym otoczeniu i musi być zrobiona tak, aby to było bezpieczne, skalowalne i sprawnie obsługiwane, tak inżynier od chmury czy SRE muszą znać trochę architekturę tej aplikacji, może nawet niektóre jej funkcje, aby jak najlepiej wykorzystać jej możliwości.

Idea DevOps w tym przypadku polega na tym, że cały zespół zajmuje się procesem wytworzenia produktu. Każdy z członków ma pewną wiedzę o pracy reszty i nie robi wszystkiego sam. Tu jest to piękno DevOps! Dzięki takiemu podejściu naturalnie tworzy się klarowny obraz przebiegu prac i wymiany wiedzy. Buduje się też dzięki temu zespół DevOps, który jest prawdziwym zespołem, a nie stadem siłaczek usadowionych w jednym pokoju. Zresztą nie ma co się oszukiwać, każdy z nas ma jakieś predyspozycje, specjalne umiejętności, czasami nawet talent, i właśnie to powinno się dostrzec, umieszczając danego człowieka w odpowiedniej roli w zespole. Zabawne jest to, że problem ten uwypukla się tak mocno w IT, podczas gdy idee DevOps można odnaleźć w pełni wdrożone w wielu procesach w produkcji czy działaniach metodami by-design. Weźmy za przykład stolarnię, w której pracuje sześciu chłopa. Jeden tnie, bo ma świetną rękę i zawsze równo mu wychodzi, drugi pomyka na obrabiarce, trzeci docina, czwarty klei, piąty szlifuje, szósty dorabia detale. Wszyscy wiedzą, co robią ich koledzy w zespole, ale każdy jest dobry w czymś innym i w tym obszarze działa. W momencie gdy zabraknie jednej osoby, dalej będzie można robić stoły, ale będą pewnie bardziej krzywe, może trochę gorzej poklejone albo niedokładnie wyszlifowane. Da się. Tak samo powinno być w IT – specjalizacja i współpraca w harmonii to podstawy.


Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT, specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"