Developer > Inżynier DevOps

Witam,

Otrzymałem ostatnio ofertę na Inżyniera DevOps, przeszedłem rekrutację, zaproponowano mi pracę no i zacząłem się zastanawiać : ) Generalnie widzę siebie w przyszłości jako osoba odpowiedzialna za działkę DevOps'ową, a dalej pewnie coś w stylu Cloud Architecta i to chyba jest całkiem rozsądna droga, natomiast chciałem Was zapytać czy mieliście okazję przejść ze stanowiska deva na coś związanego z devopsem? Czego się nauczyliście, czy żałowaliście? Czy po przejściu do działu wsparcia i utrzymania nie żałowaliście, że jednak tego developmentu jest mniej? Wszystko oczywiście zależy od firmy, ale jak dużo np. spędzaliście czasu na typowym wsparciu, jakieś debugowanie, fixowanie bugów itp.? Zależy mi głównie na poznaniu jak największej ilości usług Azure'owych i to mnie głównie motywuje do zmiany, a przy okazji pewnie wizja jakiejś lepszej kariery dla zagranicznego klienta za te kilka lat (mimo że teraz zszedłbym z pensji o prawie 4k, to jednak sufit dla deva, a sufit dla takiego cloud architecta jest jednak trochę wyżej). Ofert pracy dla Clouda jest znacznie więcej niż tego w czym obecnie programuje : )

MatD napisał(a):

chciałem Was zapytać czy mieliście okazję przejść ze stanowiska deva na coś związanego z devopsem?

Zostałem zmuszony do współuczestniczenia w utrzymywaniu serwera developerskiego. Raczej normalne, ale zostałem programistą żeby programować, a nie zmieniać yamle

Czego się nauczyliście

Kubernetesa i pisania oraz formatowania yamli o 3 w nocy

żałowaliście?

Trochę, wolałbym programować, ale wiedza z kubernetesa też mi jest potrzebna

Czy po przejściu do działu wsparcia i utrzymania nie żałowaliście, że jednak tego developmentu jest mniej?

Jak już pisałem, żałowałem

No dobra, a z DevOpsa nie da się przejść na SRE? tam to już chyba jest fajne kodzenie - narzędzia itp.

Z devopsem i SRE trzeba uważać bo to są teraz modne nazwy stanowisk, a firmy nie koniecznie w ogóle stosują podejście w stylu devops. Tak z pamięci obowiązki różnych osób które miały "devops" w nazwie stanowiska:

• ręczne releasowanie rzeczy na serwerach bo automatyzacja jest be a developerzy się nie znają więc sami nie mogą
• kierownik ITILowego CABu (podklepywał change requesty w produktach o których wiedział dokładnie nic)
• provisionowanie infrastruktury dla zespołów na podstawie ticketów (brak bezpośredniej współpracy z zespołem produktowym)
• utrzymanie jiry przy życiu (stricte ops)
• utrzymywanie jenkinsa przy życiu (stricte masochizm)
• klepanie yamli dla konkretnego zespołu produktowego
• zarządzanie infrastrukturą cloudową - konta na AWSie, k8s, monitoring tego wszystkiego itp (zespół infra/platforma)
• klepanie różnych mniej lub bardziej użytecznych tooli na użytek devów w całej firmie (np libki które od strzała konfigurują metryki, logowanie i tracing o ile napiszesz apkę w technologii X)
• oncall 24/7/365 bez wpływu na zespoły produktowe ("SRE")
• SRE zbliżone do Googlowego, gdzie faktycznie były budżety oparte o SLO i inne wymagania do zespołu produktowego
• klepanie exceli związanych z security compliance
• solutions architect (czyli sprzedawanie klientom jakiejś architektury do ich problemów w ramach clouda, w tym przypadku to tak pół na pół z sales bo to konsultanci)

Pamiętam początki DevOpsowania. Pensje gdzieniegdzie były bardzo niskie albo bardzo wysokie. Znałem temat bardzo dobrze ale nie zawiesiłem się jako junior devops nigdzie i to był mój błąd.
Lekką ręką bym sobie poradził i dał radę z tak małą kasą. A potem już wymagano lat doświadczenia i nie chciano brać bez. Tak samo z Go Langiem, Pythonem i R.
Generalnie jak człowiek szybko złapał się na szerzej znaną nowinkę to zawsze mógł się nauczyć i zrobić większą kasę, potem powtórzyć w innej technologii.
Kumpel tak się załapał na specjalistę od RODO/GDPR, kupił dzięki temu kolejne mieszkanie.
Ale jak ktoś podchodzi do wszystkiego tradycyjnie i oczekuje że za kompetencje też dostanie kasę, to niestety mylne myślenie i w Polsce to nie działa.