Co jest potrzebne, aby firma IT odniosła sukces w 2019 roku? Wykładowcy na konferencjach i spotkaniach wypowiadają wiele głośnych słów, które nie zawsze są zrozumiałe dla zwykłych ludzi. Walka o czas wdrożenia, mikroserwisy, porzucenie monolitu, transformacja DevOps i wiele, wiele więcej. Jeśli odrzucimy piękno werbalne i zaczniemy mówić bezpośrednio i po rosyjsku, to wszystko sprowadza się do prostej tezy: stworzyć produkt wysokiej jakości i robić to w komforcie dla zespołu.
To ostatnie stało się niezwykle ważne. Biznes w końcu doszedł do wniosku, że wygodny proces deweloperski zwiększa produktywność, a jeśli wszystko zostanie odbugowane i działa jak zegar, to daje też pewne pole manewru w krytycznych sytuacjach. Kiedyś na potrzeby tego manewru pewna mądra osoba wymyśliła kopie zapasowe, ale branża się rozwija, a my doszliśmy do inżynierów DevOps – ludzi, którzy zamieniają proces interakcji pomiędzy developmentem a infrastrukturą zewnętrzną w coś odpowiedniego i niezwiązane z szamanizmem.
Cała ta „modułowa” historia jest cudowna, ale… Tak się złożyło, że część administratorów została nagle nazwana DevOps, a od samych inżynierów DevOps zaczęto wymagać posiadania przynajmniej umiejętności telepatii i jasnowidzenia.
Zanim porozmawiamy o współczesnych problemach zapewnienia infrastruktury, zdefiniujmy, co rozumiemy pod tym pojęciem. W chwili obecnej sytuacja rozwinęła się w taki sposób, że doszliśmy do dwoistości tego pojęcia: infrastruktura może być warunkowo zewnętrzna i warunkowo wewnętrzna.
Przez infrastrukturę zewnętrzną rozumiemy wszystko, co zapewnia funkcjonalność usługi lub produktu, nad którym pracuje zespół. Są to serwery aplikacji lub stron internetowych, hosting i inne usługi zapewniające funkcjonalność produktu.
Infrastruktura wewnętrzna obejmuje usługi i sprzęt, z którego korzysta sam zespół programistów oraz inni pracownicy, których jest zwykle wielu. Są to wewnętrzne serwery systemów przechowywania kodów, lokalnie wdrażany menedżer zadań i wszystko, wszystko, co istnieje w korporacyjnym intranecie.
Czym zajmuje się administrator systemu w firmie? Oprócz pracy związanej z administracją tym bardzo korporacyjnym intranetem, często dźwiga on ciężar kwestii ekonomicznych związanych z zapewnieniem sprawności sprzętu biurowego. Administratorem jest ten sam facet, który szybko przeciągnie z zaplecza nową jednostkę systemową lub zapasowy laptop gotowy do użycia, rozda świeżą klawiaturę i czołga się na czworakach po biurze, rozciągając kabel Ethernet. Administrator to lokalny właściciel i władca nie tylko serwerów wewnętrznych i zewnętrznych, ale także dyrektor biznesowy. Tak, niektórzy administratorzy mogą pracować tylko na płaszczyźnie systemowej, bez sprzętu. Należy ich wydzielić w odrębną podklasę „administratorów systemów infrastruktury”. A niektórzy specjalizują się wyłącznie w serwisowaniu sprzętu biurowego, na szczęście, jeśli firma zatrudnia więcej niż sto osób, praca nigdy się nie kończy. Ale żaden z nich nie jest devopem.
Kim są DevOps? Devops to goście, którzy mówią o interakcji tworzenia oprogramowania z infrastrukturą zewnętrzną. Mówiąc dokładniej, współcześni devopsowie są zaangażowani w procesy programowania i wdrażania znacznie głębiej niż kiedykolwiek byli zaangażowani administratorzy, którzy po prostu przesyłali aktualizacje na FTP. Jednym z kluczowych zadań inżyniera DevOps jest obecnie zapewnienie wygodnego i efektywnie ustrukturyzowanego procesu interakcji pomiędzy zespołami deweloperskimi a infrastrukturą produktową. To właśnie ci ludzie są odpowiedzialni za wdrażanie systemów wycofywania i wdrażania, to oni odciążają programistów i maksymalnie skupiają się na ich niezwykle ważnym zadaniu. Jednocześnie devops nigdy nie poprowadzi nowego kabla ani nie wyda nowego laptopa z zaplecza (c) KO
Jaki jest haczyk?
Na pytanie „Kim jest DevOps?” połowa pracowników w terenie zaczyna odpowiadać coś w stylu „No cóż, w skrócie, to jest administrator, który…” i dalej w tekście. Tak, kiedyś, gdy zawód inżyniera DevOps dopiero wyłaniał się z grona najbardziej utalentowanych administratorów pod względem utrzymania usług, różnice między nimi nie były dla wszystkich oczywiste. Ale teraz, gdy funkcje devopsa i admina w zespole radykalnie się od siebie różnią, niedopuszczalne jest mylenie ich ze sobą, a nawet utożsamianie.
Ale co to oznacza dla biznesu?
Zatrudnianie, to wszystko.
Ogłaszasz wakat na „Administratora systemu”, a wymagania tam wymienione to „interakcja z rozwojem i klientami”, „system dostarczania CI/CD”, „utrzymanie serwerów i sprzętu firmy”, „administracja systemami wewnętrznymi” i tak dalej. NA; rozumiesz, że pracodawca opowiada bzdury. Problem w tym, że zamiast „Administratora systemu” wakat powinien brzmieć „Inżynier DevOps”, a jeśli ten tytuł zostanie zmieniony, wszystko się ułoży.
Jakie jednak wrażenie można odnieść czytając taki wakat? Że firma szuka operatora wielu maszyn, który wdroży zarówno system kontroli wersji, jak i monitoringu i będzie ściskał twistera zębami...
Aby jednak nie zwiększać stopnia narkomanii na rynku pracy, wystarczy nazwać wolne stanowiska po imieniu i jasno zrozumieć, że inżynier DevOps i administrator systemu to dwa różne podmioty. Jednak niepohamowana chęć części pracodawców do przedstawienia kandydatowi jak najszerszej listy wymagań powoduje, że „klasyczni” administratorzy systemów przestają rozumieć, co się wokół nich dzieje. Co, zawód się zmienia, a oni są w tyle?
Nie, nie i jeszcze raz nie. Administratorzy infrastruktury, którzy będą zarządzać serwerami wewnętrznymi firmy, bądź zajmować stanowiska wsparcia L2/L3 i pomagać innym pracownikom, nie odeszli i nie odejdą.
Czy ci specjaliści mogą zostać inżynierami DevOps? Oczywiście, że mogą. W rzeczywistości jest to powiązane środowisko, które wymaga umiejętności administrowania systemem, ale oprócz tego dodana jest praca z systemami monitorowania, dostarczania i, ogólnie rzecz biorąc, ścisła interakcja z zespołem programistów i testerów.
Kolejny problem DevOps
Tak naprawdę wszystko nie ogranicza się do zatrudniania i ciągłego zamieszania pomiędzy administratorami a devopami. W pewnym momencie firma stanęła przed problemem dostarczania aktualizacji i interakcji zespołu programistów z finalną infrastrukturą.
Być może było tak, gdy wujek o błyszczących oczach stanął na scenie jakiejś konferencji i powiedział: „Robimy to i nazywamy to DevOps. Ci goście rozwiążą wszystkie Twoje problemy” – i zaczął opowiadać, jak dobrze żyje się w firmie po wdrożeniu praktyk DevOps.
Jednak nie wystarczy zatrudnić inżyniera DevOps, aby wszystko działało tak, jak powinno. Firma musi przejść całkowitą transformację DevOps, czyli rola i możliwości naszego DevOps muszą być jasno rozumiane także po stronie zespołu rozwoju i testowania produktu. Mamy „cudowną” historię na ten temat, która w pełni ilustruje całą brutalność, która ma miejsce w niektórych miejscach.
Sytuacja. DevOps jest wymagany do wdrożenia systemu przywracania wersji bez zagłębiania się w jego działanie. Załóżmy, że w systemie Użytkownicy istnieją osobne pola na imię, nazwisko i hasło. Pojawia się nowa wersja produktu, ale dla programistów „wycofanie” to po prostu magiczna różdżka, która wszystko naprawi, a oni nawet nie wiedzą, jak to działa. Na przykład w następnej łatce programiści połączyli pola imienia i nazwiska, wdrożyli je do produkcji, ale z jakiegoś powodu wersja jest powolna. Co się dzieje? Kierownictwo przychodzi do devopsa i mówi „Pociągnij za przełącznik!”, to znaczy prosi go o przywrócenie poprzedniej wersji. Co robi devops? Przywraca poprzednią wersję, ale ponieważ programiści nie chcieli dowiedzieć się, jak to przywrócenie zostało wykonane, nikt nie powiedział zespołowi devops, że baza danych również wymaga przywrócenia. W efekcie wszystko nam się zawiesza, a zamiast powolnej strony użytkownicy widzą błąd „500”, bo stara wersja nie współpracuje z polami nowej bazy. Devops o tym nie wie. Twórcy milczą. Kierownictwo zaczyna tracić nerwy i pieniądze i pamięta o kopiach zapasowych, oferując wycofanie się z nich, aby „przynajmniej coś zadziałało”. W rezultacie użytkownicy po pewnym czasie tracą wszystkie swoje dane.
Szajki oczywiście trafiają do devopsów, które „nie stworzyły odpowiedniego systemu wycofywania zmian” i nikogo nie obchodzi, że łosiem w tej historii są programiści.
Wniosek jest prosty: bez normalnego podejścia do DevOps jako takiego na niewiele się to zda.
Najważniejszą rzeczą do zapamiętania: inżynier DevOps nie jest magikiem i bez wysokiej jakości komunikacji i dwustronnej interakcji z rozwojem nie poradzi sobie ze swoimi zadaniami. Deweloperów nie można zostawiać samych ze swoimi „problemami” lub wydawać poleceń „nie wtrącaj się w dyskusję z programistami, ich zadaniem jest kodowanie”, a potem mieć nadzieję, że w krytycznym momencie wszystko będzie działać tak, jak powinno. To nie tak to działa.
Zasadniczo DevOps to kompetencja z pogranicza zarządzania i technologii. Co więcej, wcale nie jest oczywiste, że w tym koktajlu powinno być więcej technologii niż zarządzania. Jeśli naprawdę chcesz budować szybsze i wydajniejsze procesy programistyczne, musisz zaufać swojemu zespołowi devops. Zna odpowiednie narzędzia, realizował podobne projekty, wie jak to zrobić. Pomóż mu, słuchaj jego rad, nie próbuj izolować go w jakiejś autonomicznej jednostce. Jeśli administratorzy potrafią pracować samodzielnie, to devopy są w tym przypadku bezużyteczne; nie będą w stanie pomóc ci stać się lepszym, jeśli sam nie będziesz chciał przyjąć tej pomocy.
I ostatnia rzecz: przestańcie obrażać administratorów infrastruktury. Mają swój własny, niezwykle ważny front pracy. Tak, administrator może zostać inżynierem DevOps, ale powinno to nastąpić na prośbę samej osoby, a nie pod presją. I nie ma nic złego w tym, że administrator systemu chce pozostać administratorem systemu – to jego odrębny zawód i jego prawo. Jeśli chcesz przejść transformację zawodową, nie możesz zapominać, że będziesz musiał rozwijać nie tylko umiejętności technologiczne, ale także zarządcze. Najprawdopodobniej do Ciebie, jako lidera, będzie należało zebranie wszystkich tych ludzi i nauczenie ich porozumiewania się w tym samym języku.
Źródło: www.habr.com