Dlaczego ciągle widzę oferty pracy na stanowisko " DevOps Engineer" skoro takie stanowisko pracy nie istnieje? Czyżby to był następny wymysł upośledzonych menedżerów?
1
2
Skoro kogoś tak tytułują, to takie stanowisko istnieje. A czy ma sens jego istnienie, to jakby inny temat.
0
mogą go sobie nawet nazwać dev ninja ops evangelist, z drugiej strony czego nie rozumiesz w tym stanowisku, bo chyba chcesz stworzyć problem, którego nie ma
3
Z tego, co mi wiadomo, to jest to metodyka pracy, polegająca na współzależność rozwoju i utrzymania. Co będzie następne SCRUM Engineer?
1
@BamBam123: jak programista, który tworzy kod biznesowy, ma zająć się procesem CI/CD ?
To nie takie proste, teraz mamy trend IaC i, żeby utrzymyć pipeliny jenkinsa, całe pliki Ansible, Kuberneteesa etc. to trzeba się napocić, dlatego oddelegowane są do tego konkretne osoby i tymi procesami się zajmują.
2
boska_cebula napisał(a):
mogą go sobie nawet nazwać dev ninja ops evangelist, z drugiej strony czego nie rozumiesz w tym stanowisku, bo chyba chcesz stworzyć problem, którego nie ma
To nie jest stanowisko. DevOps engineer brzmi mniej więcej jak Git engineer. Jedna osoba w zespole, która robiłaby commity za innych. Absurd, nieprawdaż?
2
Devops to mniej więcej taka nazwa na człowieka który umie programować a przy tym też zainstalować Apacha i go skonfigurować oraz sprawdzić jakie procesy są uruchomione na serwerze przy tym rozumieć czy coś się jebie w systemie jaki się buduje bo on nie umie skonfigurować Apacha, czy dlatego, że reszta developerów to idioci. Jeśli jesteś na poziomie mida, albo po prostu reszta zespołu to kretyni, przy tym ogarniasz system operacyjny z przyległościami na jakim się developuje na poziomie głębszym niż puszczenie forkbomby i nazywanie siebie z tego powodu hakjerem to nadajesz się na to stanowisko wyśmienicie.
0
somekind napisał(a):
boska_cebula napisał(a):
mogą go sobie nawet nazwać dev ninja ops evangelist, z drugiej strony czego nie rozumiesz w tym stanowisku, bo chyba chcesz stworzyć problem, którego nie ma
To nie jest stanowisko. DevOps engineer brzmi mniej więcej jak Git engineer. Jedna osoba w zespole, która robiłaby commity za innych. Absurd, nieprawdaż?
nie, to brzmi tak samo jak software engineer. Git to narzędzie, kiepski przykład.
Zastanów się jakie role łączy, co robi devops i dlaczego engineer tutaj pasuje.
4
Devops nie robi niczego, czego ja bym nie robił, a devopsem nie jestem. Wydzielanie oddzielnego stanowiska i nazywanie go "devops engineer" jest kompletnym wypaczeniem idei.
0
somekind napisał(a):
Devops nie robi niczego, czego ja bym nie robił, a devopsem nie jestem. Wydzielanie oddzielnego stanowiska i nazywanie go "devops engineer" jest kompletnym wypaczeniem idei.
To masz albo bardzo szerokie kompetencje, albo nie rozumiesz co robi devops. Zakładam też, że nie do ciebie dzwonią jak serwer padnie.
2
Jak serwer padnie, to zajmują się nim ludzie z Amazona. Tylko to jest bardzo daleko od moich problemów.
0
somekind napisał(a):
Jak serwer padnie, to zajmują się nim ludzie z Amazona. Tylko to jest bardzo daleko od moich problemów.
tak myślałem, że dla Ciebie praca devopsa kończy się na konfiguracji CI/CD
8
Po prostu niektóre firmy lubią patologiczne struktury z dziwnymi procesami, stanowiskami i korporacyjnymi standardami, a w innych ludzie odpowiadają za to, co tworzą, od początku do końca. Ja pracuję raczej w tym drugim modelu.
1
somekind napisał(a):
Devops nie robi niczego, czego ja bym nie robił, a devopsem nie jestem. Wydzielanie oddzielnego stanowiska i nazywanie go "devops engineer" jest kompletnym wypaczeniem idei.
Taksówkarz, szatniarz czy listonosz też nie zrobi niczego, czego ja bym nie zrobił, a nie jestem przedstawicielem żadnych z tych zawodów.
Nie chodzi o kompetencje, tylko o specjalizację. Ja np. chciałbym się skupić na programowaniu, a niestety muszę od czasu do czasu grzebać się w jakichś Jenkinsfile'ach, Dockerfile'ach, Ansible'ach, konfigurować Nagiosa, budować paczki debianowe itp. Wołałbym właśnie żeby tego typu zadania robił za mnie DevOps, bo mnie to średnio interesuje, dlatego istnienie tego stanowiska ma dla mnie jak najbardziej sens.
0
--------------------------------- / System's Engineer
Junior Admin --> Admin
--------------------------------- \ Site Reliability Engineer
Gdzie byście tutaj tego devopsa dali?
po adminie, a przed SRE?
4
GutekSan napisał(a):
Nie chodzi o kompetencje, tylko o specjalizację. Ja np. chciałbym się skupić na programowaniu, a niestety muszę od czasu do czasu grzebać się w jakichś Jenkinsfile'ach, Dockerfile'ach, Ansible'ach, konfigurować Nagiosa, budować paczki debianowe itp. Wołałbym właśnie żeby tego typu zadania robił za mnie DevOps, bo mnie to średnio interesuje, dlatego istnienie tego stanowiska ma dla mnie jak najbardziej sens.
Z mojego doświadczenia oddzielne role typu "devops" są charakterystyczne dla organizacji, w których wdrożenie robi się raz na kilka miesięcy/lat. Najpierw programiści żmudnie klepią kod, potem inni ludzie testują, a potem jeszcze inni ludzie wdrażają.
A celem działania inżyniera oprogramowania jest dostarczenie działającego produktu, a nie tylko naklepanie kodu, więc wdrażanie i monitorowanie działania produkcji jest po prostu nieodłączną częścią pracy. Jeśli nie wiesz co robisz, zapewne zrobisz to źle. A jeśli nie wiesz jak coś działa, to znaczy, że nie wiesz co robisz.
4
W prywatnych projektach bawię się trochę w różnego rodzaju automatyczne deploye itp, ale w dużych projektach bym się raczej nie podjął. To jest ogrom wiedzy z przekroju programowania/administracji wiele wyspecjalizowanych narzędzi. Dochodzą do tego rozwiązania providerów.
Gdyby każdy programista miał takie rzeczy ogarniać na wysokim poziomie, to by musiał dużą część swojego czasu poświęcać na samo bycie na bieżąco.
Jeśli mówimy o podstawowej konfiguracji serwera spoko. Jeśli mówimy o zbudowaniu środowiska składającego się z wielu usług rozproszonych po różnych maszynach, automatyzacji tego, skalowalności, zabezpieczeniu itp to dobrze jest jak się trafi na osobę, która potrafi to sama zrobić w pojedynkę.
1
Ok można zwalniać sieciowców, ludzi z security, adminów itd @somekind jest ekspertem od wszystkiego, można zamknąć temat
1
somekind napisał(a):
Z mojego doświadczenia oddzielne role typu "devops" są charakterystyczne dla organizacji, w których wdrożenie robi się raz na kilka miesięcy/lat. Najpierw programiści żmudnie klepią kod, potem inni ludzie testują, a potem jeszcze inni ludzie wdrażają.
Ale Devopsi nie są wykorzystywani tylko w momencie wdrażania, tylko przez cały czas. Od pewnego poziomu złożoności projektów, automatyzacja procesu produkcyjnego jest takim samym ciągłym procesem jak sam proces produkcji oprogramowania, dlatego programowanie może iść sobie jedną ścieżką, a zadania związane z wdrażaniem drugą.
A celem działania inżyniera oprogramowania jest dostarczenie działającego produktu, a nie tylko naklepanie kodu, więc wdrażanie i monitorowanie działania produkcji jest po prostu nieodłączną częścią pracy. Jeśli nie wiesz co robisz, zapewne zrobisz to źle. A jeśli nie wiesz jak coś działa, to znaczy, że nie wiesz co robisz.
Powiedziałbym, że dostarczenie działającego produktu jest celem zespołu a nie jednego inżyniera. A w każdym zespole robiącym nietrywialne zadania, ludzie mają swoją specjalizację. Oczywiście trudno pozwolić by każdy siedział tylko w swoim grajdołku, bo odpowiedzialności się przenikają. Jednak dobrą praktyką jest, że członkowie zespołu mają kompetencję w kształcie litery T - czyli wysoko rozwiniętą swoją specjalizację i jakieś dostatecznie rozwinięte umiejętności z pozostałych obszarów.
Wdrażanie i monitorowanie jest częścią pracy, ale niekoniecznie tej samej osoby, która napisała oprogramowanie. Co ma wiedza związana z napisaniem kawałka oprogramowania, które ma ściśle określone wejście, wyjście, z wiedzą na temat automatyzowania jego budowania, releasowania i wdrażania? Tak jak piekarz nie musi być jednocześnie młynarzem, mimo że pracują z tymi samymi ziarnami tylko na innych etapach, tak programista nie musi być devopsem.
1
boska_cebula napisał(a):
Ok można zwalniać sieciowców, ludzi z security, adminów itd @somekind jest ekspertem od wszystkiego, można zamknąć temat
Po prostu masz marne doświadczenie i niewiele rzeczy widziałeś. To nie jest mój wymysł, to jest model działania różnych firm.
GutekSan napisał(a):
Ale Devopsi nie są wykorzystywani tylko w momencie wdrażania, tylko przez cały czas. Od pewnego poziomu złożoności projektów, automatyzacja procesu produkcyjnego jest takim samym ciągłym procesem jak sam proces produkcji oprogramowania, dlatego programowanie może iść sobie jedną ścieżką, a zadania związane z wdrażaniem drugą.
Owszem, każdy proces można skomplikować tak, że potrzebne są oddzielne ścieżki i wyznaczeni ludzie do ich realizacji. Ale komplikowanie procesu w celu wprowadzenia dodatkowych etatów to już jest coś nawet ponad patologią.
Czym dla Ciebie jest "złożony projekt"? Bo u nas jest ze 200 serwisów i drugie tyle narzędzi pomocniczych, kilkaset wdrożeń produkcyjnych tygodniowo, a jedyne zespoły w firmie, które mają oddzielnych devopsów to te z Bangalore (no ale one robią raptem kilka wdrożeń miesięcznie, na dodatek przez QA, więc rola devopsów jest w ogóle niezrozumiała dla mnie w ich przypadku).
Powiedziałbym, że dostarczenie działającego produktu jest celem zespołu a nie jednego inżyniera. A w każdym zespole robiącym nietrywialne zadania, ludzie mają swoją specjalizację. Oczywiście trudno pozwolić by każdy siedział tylko w swoim grajdołku, bo odpowiedzialności się przenikają. Jednak dobrą praktyką jest, że członkowie zespołu mają kompetencję
w kształcie litery T- czyli wysoko rozwiniętą swoją specjalizację i jakieś dostatecznie rozwinięte umiejętności z pozostałych obszarów.
Nie rozumiem, czemu ta kompetencja w kształcie litery T uniemożliwia wdrożenie i monitorowanie działania aplikacji.
Wdrażanie i monitorowanie jest częścią pracy, ale niekoniecznie tej samej osoby, która napisała oprogramowanie. Co ma wiedza związana z napisaniem kawałka oprogramowania, które ma ściśle określone wejście, wyjście, z wiedzą na temat automatyzowania jego budowania, releasowania i wdrażania?
Czy Twoim zdaniem programista nie może znać biznesu produktu nad którym pracuje, bo nie ma to związku z pisaniem kodu?!
Wszytko to jest częścią inżynierii oprogramowania, a więc ktoś, kto się zawodowo zajmuje inżynierią oprogramowania powinien być w stanie to ogarniać.
I to nie znaczy, że każdy programista w firmie codziennie ma od nowa pisać skrypty wdrożeniowe. System wdrożeniowy buduje się raz, a potem się go używa. System taki mogą napisać programiści, oczywiście we współpracy z ludźmi od infrastruktury, security czy baz danych. A potem każdy zajmuje się swoją pracą. A praca programisty to dowiezienie taska do użytkownika. Bez wdrożenia się nie obejdzie.
Izolowanie programistów od efektów ich pracy często sprawia, że się nie starają (bo przecież i tak nie oni ponoszą odpowiedzialność), że obsługa błędów ssie, że logowanie jest biedne, że coś jest niekonfigurowalne, itp.
2
@somekind devOpsi czy tam specjaliści od konkretnej chmury przydają się najbardziej do jednej rzeczy :). Optymalizacji kosztów oraz przygotowania kosztorysu dla klienta. Chyba że Tobie jako developerowi, chce się spalać czas na zaznajamianie się z polityką cenową i kazdą jej zmianą. :)
6
somekind napisał(a):
Owszem, każdy proces można skomplikować tak, że potrzebne są oddzielne ścieżki i wyznaczeni ludzie do ich realizacji. Ale komplikowanie procesu w celu wprowadzenia dodatkowych etatów to już jest coś nawet ponad patologią.
Nie piszę o specjalnym komplikowaniu procesu. Nikt specjalnie nie komplikuje procesów.
Czym dla Ciebie jest "złożony projekt"? Bo u nas jest ze 200 serwisów i drugie tyle narzędzi pomocniczych, kilkaset wdrożeń produkcyjnych tygodniowo, a jedyne zespoły w firmie, które mają oddzielnych devopsów to te z Bangalore (no ale one robią raptem kilka wdrożeń miesięcznie, na dodatek przez QA, więc rola devopsów jest w ogóle niezrozumiała dla mnie w ich przypadku).
Możemy się licytować na liczbę serwisów przy których pracujemy, ale nie w tym rzecz, bo złożoność może wynikać z różnych rzeczy (nb. to nie oznacza, że tam gdzie ja pracuję jest ich mniej ;) ). Rzecz w tym, czy organizacja doszła do wniosku, czy w jej konkretnym procesie produkcyjnym efektywniej jest wydzielić stanowisko DevOpsa czy nie. Jeśli doszła, to w zasadzie to zamyka dyskusję, bo Twoje doświadczenia z Twojej organizacji nie przekładają się na specyfikę wszystkich możliwych produktów i procesów z nimi związanych.
Powiedziałbym, że dostarczenie działającego produktu jest celem zespołu a nie jednego inżyniera. A w każdym zespole robiącym nietrywialne zadania, ludzie mają swoją specjalizację. Oczywiście trudno pozwolić by każdy siedział tylko w swoim grajdołku, bo odpowiedzialności się przenikają. Jednak dobrą praktyką jest, że członkowie zespołu mają kompetencję
w kształcie litery T- czyli wysoko rozwiniętą swoją specjalizację i jakieś dostatecznie rozwinięte umiejętności z pozostałych obszarów.Nie rozumiem, czemu ta kompetencja w kształcie litery T uniemożliwia wdrożenie i monitorowanie działania aplikacji.
Niczego takie nie napisałem. Przecież aplikacja jest wdrażana i monitorowana. Tylko przez różne osoby.
Czy Twoim zdaniem programista nie może znać biznesu produktu nad którym pracuje, bo nie ma to związku z pisaniem kodu?!
Wszytko to jest częścią inżynierii oprogramowania, a więc ktoś, kto się zawodowo zajmuje inżynierią oprogramowania powinien być w stanie to ogarniać.
Ponownie, wszystko zależy od specyfiki produktu. W wielu projektach ogarnięcie wszystkiego jest po prostu niemożliwe. Jeśli programista ma po kokardę zadań z pisaniem feature'ów i naprawianiem bieżących bugów, które same z siebie wymagają dużej wiedzy i skupienia, to głupotą jest moim zdaniem wymagać jeszcze od niego, by zajmował się równocześnie automatyzowaniem różnych procesów dookoła, jeśli mogą to zrobić inne osoby. Zwłaszcza, jeśli on się na tym niespecjalnie zna i niezbyt mu zależy by to poznać, a tym inne osoby niespecjalnie potrafią rozwiązać jego zadania i taki podział będzie po prostu efektywniejszy.
"Powinien" to fajne słowo-wytrych. W ogóle wszyscy powinniśmy potrafić wszystko, powinniśmy nie robić błędów, być super-efektywni. Realia są jednak takie, że pracuje się z ludźmi o konkretnych umiejętnościach i konkretnych zainteresowaniach. Z tego co widzę próbujesz nagiąć zakres obowiązków do własnego widzimisię, tylko pamiętaj, że z niewolnika nie ma pracownika.
Izolowanie programistów od efektów ich pracy często sprawia, że się nie starają (bo przecież i tak nie oni ponoszą odpowiedzialność), że obsługa błędów ssie, że logowanie jest biedne, że coś jest niekonfigurowalne, itp.
A kto mówi o izolowaniu? Podział obowiązków i specjalizacja nie oznacza, że ktoś nie ponosi odpowiedzialności za swoją pracę.
3
Czyli z tego, co rozumiem z waszych co niektórych wypowiedzi i ogłoszeń. DevOps to taki gościu co zna Bash Script, Docker, Kubernetes, Jenkins, Azure i tp. Jest to osoba, która pracuje w odseparowaniu od programistów, po to, żeby programiści nie musieli się za dużo uczyć. Czyli to coś w stylu, jeśli mamy słaby zespół, który nie umie stosować TDD, to znaczy, że potrzebujemy Inżyniera od testów manualnych? DevOps pełną gębą. :D
5
Nie wyobrażam sobie pracy bez Devopsów. Jeśli mam apke składającą się z 30 serwisów, każdy z serwisów potrzebuje mieć dostęp do różnych zasobów, a polityka bezpieczeństwa nie daje mi możliwości konfiguracji zabezpieczeń (certyfikaty bezpieczeństwa ISO oraz wymagania bezpieczeństwa klienta wprowadzają bardzo duże ograniczenia), dodatkowo część serwisów korzysta z azure a cześć musi stać na vm czy innych zasobach. Dodatkowo Trzeba postawić poza dev jeszcze rc i prod. To sorry firma nie poświeci czasu developera na zdobywanie pozwoleń i stawianie takiego środowiska. Jak przyjdzie nowy developer i wdrażam go w nowy projekt, to nie musze go wdrażać w CI/CD bo od tego jest DevOps, który ma to zautomatyzowane. Nie mam czasu na monitorowanie kosztów i zużycia zasobów. Od tego jest DevOps. Przekazuje mi tylko info, że coś zabardzo nam zżera appserviceplan i trzeba tam kuknąć. Jak najbardziej srodowisko dev mogę opublikować sam, ale prod już nie. Build na prodzie zrobi się autoamtem. Ale klepnięcie publikacji wymaga zgody ownera produktu i publikacje może zrobić tylko devops bo taka jest polityka bezpieczenstwa. Duże korporacje (międzynarodowi producenci) naprawdę maja ogromne wymagania co do tego. Dla jednej z nich przez cały rok firma zewnętrzna wynajęta przez tą korporacje atakowała nasze systemy by sprawdzić bezpieczeństwo. Dodatkowo DevOps przyjdaj się jeszcze jako specjalista od czyszczenia ekspresu do kawy :D p.s. to nie zwalnia mnie z wiedzy na te tematy. Bo do własnych testów i szukania rozwiązań muszę sobie przygotowywać własne środowisko by Devopsom d**y z piersiami nie zawracać. To są naprawdę zajęci ludzie. U nas jest ich 2. Ma dojść jeszcze jeden ale bardziej administrator
P.s 2 200 serwisów to jak mówi mój kolega "pierd" do ogarniecia
0
Przecież wszyscy (@somekind) wiemy, że lepiej niech wdraża programista 120zł/h niż np. 50zł/h ninja :D
Bo to nie jest tak, że jest tylko jedno środowisko do obsłużenia, trzeba wgrać na te wszystkie bety/alphy/prod_internal_snapshot, a później na produkcję i to się po prostu lepiej kalkuluje ;)
0
DevOps jest potrzebny, jeśli mówimy o prawdziwie działajacym CI/CD i jeśli mamy dużo rzeczy do ogarnięcia. To sa ludzie którzy potrafia w jakimś stopniu programować, powinni znać bardzo dobrze narzędzia i Linuxa. Ogólnie zauważyłem tendencję do większych widełek dla DevOpsow niz dla programistow. Nie så to ludzie niepotrzebni jak Scrum Masterzy uwielbiani przez wszystkich, wręcz przeciwnie.
1
Schadoow napisał(a):
@somekind devOpsi czy tam specjaliści od konkretnej chmury
OK, a jaki jest powód nazywania specjalisty od chmury devopsem? Bo brzmi mądrze i modnie?
Chyba że Tobie jako developerowi, chce się spalać czas na zaznajamianie się z polityką cenową i kazdą jej zmianą. :)
Nie interesuje mnie to, od tego są właśnie wydzieleni ludzie. (Tylko nazywamy ich w sposób opisujący ich stanowisko, a nie buzzwordami. ;))
GutekSan napisał(a):
Możemy się licytować na liczbę serwisów przy których pracujemy, ale nie w tym rzecz, bo złożoność może wynikać z różnych rzeczy (nb. to nie oznacza, że tam gdzie ja pracuję jest ich mniej ;) ).
Nie chodziło mi o licytację, jedynie o pokazanie, że to podejście (programiści wdrażający swoje taski) działa w takiej skali, zanim ktoś mnie oskarży o pracę przy jakichś małych systemach albo monolitach.
Rzecz w tym, czy organizacja doszła do wniosku, czy w jej konkretnym procesie produkcyjnym efektywniej jest wydzielić stanowisko DevOpsa czy nie.
To do jakich wniosków doszła organizacja nie zmienia faktu, że nie może sobie wymyślić sobie stanowiska i przypisać mu nazwy pewnej koncepcji. Nazwać stanowisko "DevOps Engineer", to tak jakby nazwać "Agile Engineer" albo "DDD Engineer". Absurd i nonsens, a dodatkowo kuriozum, aberracja i zwykła ignorancja.
Niczego takie nie napisałem. Przecież aplikacja jest wdrażana i monitorowana. Tylko przez różne osoby.
Tak. A jeśli te osoby odpowiednio poukładają współpracę ze sobą, użyją odpowiednich procesów i narzędzi, to to jest właśnie DevOps. To co się dzieje, to jak to działa, a nie jakiś koleś.
Ponownie, wszystko zależy od specyfiki produktu. W wielu projektach ogarnięcie wszystkiego jest po prostu niemożliwe. Jeśli programista ma po kokardę zadań z pisaniem feature'ów i naprawianiem bieżących bugów, które same z siebie wymagają dużej wiedzy i skupienia, to głupotą jest moim zdaniem wymagać jeszcze od niego, by zajmował się równocześnie automatyzowaniem różnych procesów dookoła, jeśli mogą to zrobić inne osoby.
Ale ja nie pisałem o automatyzowaniu jakichś procesów. Ja pisałem o wdrażaniu swoich tasków. Wdrożenie to kilka chwil, nawet nie 5 minut. Przy tasku trwającym np. tydzień to jest nieznaczący odsetek czasu pracy.
Z tego co widzę próbujesz nagiąć zakres obowiązków do własnego widzimisię, tylko pamiętaj, że z niewolnika nie ma pracownika.
Yyy, co? Ty na pewno czytałeś moje posty?
Ja nigdzie nie napisałem, że ma nie być specjalizacji, adminów, chmurowców ;), ludzi od bezpieczeństwa, itd. To czyjeś urojenia w tym wątku, a nie moje słowa. Ja napisałem, że:
- DevOps to nie jest nazwa stanowiska/roli/osoby.
- Programista może wdrażać to, co napisał, nawet na produkcję i monitorować to w jakimś zakresie. (I to podejście jest już elementem DevOpsu.)
Natomiast, co do tej "specjalizacji", o której tak wiele słów tutaj padło. Tytułowy "devops" jak się okazuje z waszych wypowiedzi: wdraża aplikacje, pisze skrypty, konfiguruje systemy, zna się na cennikach chmurowych, jeździ do klienta, monitoruje i supportuje aplikacje. To gdzie tu jest ta słynna "specjalizacja"?
Kadzio napisał(a):
P.s 2 200 serwisów to jak mówi mój kolega "pierd" do ogarniecia
Biorąc pod uwagę to, jak wszyscy są obsrani na sam pomysł, żeby programista miał coś wdrażać, to coś zdecydowanie więcej niż pierd.
Ale zgodzę się, że 200 serwisów to nic, z jednym monolitem jest trudniej, i pewnie dlatego większość nadal pracuje w tym modelu, bo w życiu nie może być zbyt łatwo. ;)
0
somekind napisał(a):
To do jakich wniosków doszła organizacja nie zmienia faktu, że nie może sobie wymyślić sobie stanowiska i przypisać mu nazwy pewnej koncepcji. Nazwać stanowisko "DevOps Engineer", to tak jakby nazwać "Agile Engineer" albo "DDD Engineer". Absurd i nonsens, a dodatkowo kuriozum, aberracja i zwykła ignorancja.
Nie rozumiem tego "nie może wymyślić", Ty arbitralnie zabraniasz firmom takich rzeczy, nawet jak pozwala im to zarabiać? :-)
Rok prawie 2020, a ludzie wciąż przywiązują się do dziwnych nazw stanowisk, udowadniając, że nie wolno tak... podziwiam za brak innych problemów.
4
Chyba popularniejsze jest wykonywanie obowiazkow ktore pojawily sie wyzej jako
Software Engineer - Tools and Infrastructure
Software Engineer - Engineering Productivity
Software Engineer - Operations and Infrastructure
Itd
Stanowisko nazwane "devops" jest dla mnie niejasne.
1
"Pan Devops" w zespole to patologia.
Po pierwsze wprowadza to wąskie gardło w zespole. Bo tylko taka osoba ogarnia "infre". Na dodatek zwyczajni programiści nie mając kontekstu infry stają się code monkeys lub crud devs. Jak większość ludzi w zespole nie umie w CI/CD to robią to źle. Pan Devops co najwyżej może dostarczyć toole które zostaną użyte przez programistę.
Sensowniejsze nazwy stanowiska:
- SRE
- Platform Engineer
- software engineer - tooling
- developer efficiency engineer
itp.
Zazwyczaj jednak pracują nad cała platforma jako PaaS. Lub komponentami infrowymi w stylu monitoring albo dostarczają cały klaster kubernetesa. Itp.
ALE zdajmy sobie sprawę, że coś takiego występuje w dużych firmach albo bardzo dużych.
Ale obecnie do samej nazwy nie ma co się czepiać... Nawet AWS używa "devops engineer". Ale przy takiej nazwie trudno stwierdzić co się będzie robić.