Czym jest DevOps Engineer?

Na początek warto sobie wyjaśnić czym w ogóle jest stanowisko DevOps Engineer, kto to taki, gdyż jest to popularna kwestia do dyskusji. Obecnie trwają niezliczone spory co do tego stanowiska (i czy w ogóle to jest stanowisko, a nie np. metodyka pracy - Development & Operations), prawdopodobnie są one nierozwiązywalne, bo wszystko zależy od konkretnej firmy i jej sposobu postrzegania tego stanu rzeczy. W jednej firmie będzie to nazwa DevOps Engineer, w drugiej Sysadmin, w trzeciej “wynieś, przynieś, pozamiataj” w czwartej programista.

 

W dużym uproszczeniu i zgodnie z popularnym rozumieniem tego stanowiska, DevOps Enginner to osoba odpowiedzialna za infrastrukturę w projekcie, zwłaszcza od strony administracji serwerami (najczęściej oparte o systemy z kernelem Linux), bezpieczeństwa, której zadaniem jest “zdjąć” z developerów głównie zadania niezwiązane ściśle z samym pisaniem logiki biznesowej aplikacji, czyli:

  • wszelkiego rodzaju automatyzacja ciągłego dostarczania tej aplikacji na różne środowiska, jej testowania, itp
  • zarządzania infrastrukturą, jej dostosowywania pod potrzeby developerów
  • dbaniem o bezpieczeństwo aplikacji i infrastruktury
  • tuning systemu lub infrastruktury pod potrzeby związane z aplikacją

Przy czym na stanowisku typu DevOps jest mocny nacisk na automatyzację i robienie wszystkiego co możliwe w kodzie deklaratywnym (patrz: Infrastructure as code), który to kod może być później weryfikowany/testowany przez inne automatyczne narzędzia lub ludzi. Stąd też, często wymaga się na tym stanowisku umiejętności programowania w niektórych językach. Zobacz tutaj jakie są wymagania na stanowisko DevOps Engineer - czyli m.in. pytania rekrutacyjne

Czasem tego typu stanowiska mogą nazywać się jeszcze (nie zawsze będzie to oznaczać to samo, co DevOps Engineer):

  • Site Reliability Engineer (SRE)
  • Cloud Engineer
  • System Engineer
  • DevSecOps
  • Sysadmin (popularne dawniej)

Rola-przodek DevOps Engineer, czy to sysadmin, czy coś innego, dawniej oznaczała, że ktoś miał np. kilka serwerów do opieki i w jakiś tam sposób nimi sobie zarządzał. Wraz z popularyzacją oprogramowania do automatyzacji provisioningu (typu puppet), oraz infrastruktur tzw. cloudowych, w których ilość serwerów (instancji) może wynosić tysiące, dziesiątki tysięcy, a nawet więcej, sysadmin mozolnie logujący się swoimi “starymi” skryptami mógłby się zwyczajnie pogubić, dlatego DevOps Engineer przykłada dużo uwagi do dodatkowych narzędzi (tooling), które takie zarządzania ułatwiają.

 

Nie oznacza to jednak, że inżynier DevOps nie powinien zagłębiać się w niskopoziome aspekty działania systemów operacyjnych, które ma pod opieką. Często powinien (a wręcz się tego od niego wymaga), by mógł stanowić pomoc dla developerów, którzy takiej wiedzy mogą nie posiadać. Znajomość niektórych zagadnień związanych z danym systemem operacyjnym może mieć duże znaczenie dla programistów, których aplikacja nie działa lub nie będzie działać tak jak się tego oczekuje, jeśli nie zmieni się np. niektórych parametrów jądra systemu. Takie rzeczy też leżą w gestii DevOps Engineera, aby mieć minimalną wiedzę w tych tematach, a nie tylko polegać na automatycznych toolach, które coś w systemie robią.

Warto pamiętać, że niektóre zespoły nie mają u siebie osobnych ról typu DevOps Engineer w ogóle - wtedy takie “obowiązki” spadają zazwyczaj na samych developerów. Kwestią do dyskusji jest, czy jest to dobrze czy źle dla zespołu i/lub projektu, ale nie należy od razu zakładać, że jest to rola “obowiązkowa” przy tworzeniu oprogramowania, czyli jeżeli nie mamy u siebie tzw. DevOpsów, to projekt się nie uda lub będą z tego tytułu inne problemy.