Inzynierowie po 40

[freel4ncer]

free4ncer, a jaki to jest tytul takiej pracy jesli mozna wiedziec? Przyszedles z ulicy na gotowy job spec czy ta role automatycznie wyewoluowala?

Tytul oficjalny pozycji to Software Engineer i spec byl konkretnie network automation.
Firma ma 15k pudelek i praktycznie zero automatyzacji.
Dotychczas byly jakies niesmiale proby w teamach ale ze nikt ze soba nie wspolpracowal to jest to raczej rozgardiasz na niskim poziomie.
Jest kila teamow w naszej grupie czyli Load balancery , dns , operations , engineering i zostal stworzony nowy team Network Relaibility Engineering w ktorym jestem leadem od automatyzacji
Kazdy team w teorii powinien posiadać leada/sme od automatyzacji i razem powinni tworzyc taka rade ktora ustala wspolny front, architekture, technologie , narzedzia , języki kakies zasady oczywiscie kazdy sie tez skupia na potrzebach swojego teamu
Niestety na chwile obecna sa takie braki kadrowe w tej dziedzinie (mowimy o calym swiecie) ze tak naprawde jestem Ja i jeden gosciu z innego teamu potem dlugo nic i pare sosob ktorzy cos tam proboja. Od pol roku nie dostalem ani jednego sensownego CV.

Stricte automatyzacja sieci zajmuje się już jakieś 6 lat wcześniej był data tech ->network infrastructure -> network deployment -> network automation
Od poczatku kariery mialem lenia i zawsze probowalem ulatwic sobie robote piszac jakies skrypty i robic proste toole najpierw cli a potem webowe

Generalnie polecam ta sciezke bo IMHO jest duzo ciekawsza od czystego Networkingu. Jest tez duze zapotrzebowanie i naprawde bardzo dobre pieniadze przez duze D.

[ksos]

Freel4ncer, dzieki za opdowiedz. Wow, to sie nazywa kariera. Tez mnie bardziej cieszy jak napisze jakis dzialajcy skrypt w Pythonie niz naprawianie VPN po raz setny .Jakie wymagania sa na network automation? W sensie na jaki poziom abstrakcji trzeba wejsc; mowimy o uzywaniu gotowych narzedzi typu Ansbile czy bardziej rzezba od podstaw w Pythonie i Django?

[freel4ncer]

Na dzień dzisiejszy to trzeb trzeba miec skille DevOpsa
Czyli Programowanie w Python/Go
frameworki typu Django/Flask a ostatnio FastAPI
Testy
REST
Git
Ci/CD
Docker/Helm/Kubernetes
Linux
Ansible/Terraform
Prometheus/Grafana
Bazy Danych SQL/NoSQL
Hashicorp Vault
Nginx/HaProxy/Apache
DNS

Fajnie tez znac
Javascript/React/NodeJs
RabbitMQ/Kafka

Dobrze tez znac chumry publiczne. Ja osobiscie pracowalem zarowno nad automatyzacja stricte on-prem jak i hybrid czyli on-prem/aws z

Trzeba oczywiście znać sie na sieciach- Nie potrzeba CCIE ale dobrze miec doswiadczenie na poziomie CCNP rozumiec zarowno operations jak i eng/deployemnt. Pomaga to nie tylko w samej automatyzacji poszczegolnych taskow ale tez przy projektowaniu source of truth i wprowadzaniu standaryzacji bez ktorej automatyzacja nie istnieje.


Ja w swojej pracy korzystam zarówno z gotowych rozwiązań jak AWX czy np NETBOX, pisze kod ktory rozszerza ich funkcjonalnosc.
Od prostych fixow np do niedawna AWX nie supportowal namespaces w Hashicorp Vaulcie wiec trzeba bylo to dopisac. Albo np jeden team zażyczył sobie zeby IDs w netboxsie byly UUID a nie standardowo kolejne integery bo to ulatwi migracje z innego systemu.
KIedys przyszlo mi napisac multifactor authentication do tacacsa (TOTP)
Ale pisze sie tez toole do audytowania biezacych konfiguracji vs generowanych automatycznie (real world vs intent)

Tak wiec od sasa do lasa pisze sie generalnei wszystko czego nie ma out of the box
Pracuje tez nad integracja end to end roznych systemow tak by osiagnac np seamless deploymeent czy automatyczny incident handling.
W poprzedniej robocie mialem spory projekt gdzie stworzylem self service do konfiguracji firewalli juniperowych z integracja z Jira , Netboxem , specjalnymi formularzami dla developerow ktorzy dodawali aplikacje itp.
SLA spadlo z dwoch tygodni do 30min. DO tego w backendzie dodalem szereg narzedzi ktore na beirzaca poworwnywaly i napraiwaly konfiguracje oraz alertowaly jesli np ktos z palca cos skonfigurowal w policies a nie updatowal sorce of truth.
Konfiguracje srxow nagle staly sie przejrzyste i praktycznie zniknely jakiekolwiek problemy zwiazane z mismatched policies przy failoverach.


ale Generalnie nie ma co odkrywac kola na nowo. Jesli jest cos co można użyć to sie tego uyzwa.

Pisze sie pelno Restowych API, rozych bibliotek, modulow, backendow , frontendow ale geneeralnie wieszkosc pracy to krecenie sie wokol zbierania i przetwarzania jakis danych i przekazywania ich gdzie indziej a to source of truth a to cos z monitoring albo systemu ticketowego czy change management.
Budowanie jakis logcznych workflowow i duzo pisania dokumentacji oraz procesow. Jak chcesz cos zautomatyzowac to najpierw trzeba to zdefiniowac.

[mzb]

Na dzień dzisiejszy to trzeb trzeba miec skille DevOpsa
Czyli Programowanie w Python/Go
frameworki typu Django/Flask a ostatnio FastAPI
Testy
REST
Git
Ci/CD
...

Międy godziną 9 a 10 zaliczyłem już kontakt z połową wymienionych tooli i pewnie paroma innymi

[freel4ncer]

Na dzień dzisiejszy to trzeb trzeba miec skille DevOpsa
Czyli Programowanie w Python/Go
frameworki typu Django/Flask a ostatnio FastAPI
Testy
REST
Git
Ci/CD
...

Międy godziną 9 a 10 zaliczyłem już kontakt z połową wymienionych tooli i pewnie paroma innymi

Kurde ja dopiero sniadanie zjadlem , czas sie brac za robote
Zapomnialem dodac ze najwazniejsze jest uświadomienie sobie ze wszystko jest a jak jeszcze nie jest to ma byc kodem i jako kod traktowane! Nic nie moze istniec poza source controll (nawet dokumentacja) , wszystko ma byc peer reviewed, testy i w pipeline (uwielbiam ta nowomowe )
I na koniec polece jeszcze ta ksiazke Site Reliability Engineering: How Google Runs Production Systems

[martino76]

OK. Tylko stanowisko sieciowca jako takiego zanika, więc MUSIMY patrzeć szerzej...

Czy ja wiem czy zanika, sieci byly, sa i beda. Jak w każdej innej branży, technologia ewoluuje, wchodzą nowe rzeczy. Teraz uzywamy BGP, SR, MPLS, VXLAN, EVPN, IPsec name it może za 10 lat bedziemy uzywac czegos innego ale dalej trzeba będzie przekazać pakiet z punktu A do B i dalej bada to robiły sieci, czy to w obecnej lub innej formie, sieci będą niezbędne.

Co niektórzy panikowali, ze AWS, Azure zabije sieciowców nic bardziej mylnego, ktoś musi podłączyć to wszystko do tej chmury, zadbać o funkcjonowanie itd, po drugie nawet ci wielcy używają tych samych technologii, może i maja swoje protokoły itd, ale dalej są to sieci

Jest to normalny proces zmian, gdzie niektóre technologie odchodzą do lamusa a wchodzą nowe, automatyzacja jest tego częścią, ale nie wszędzie i wszystko da się zautomatyzować.

Pozdro,

[ksos]

martinos, dokladnie wg mnie jest jeszcze wiecej roboty niz bylo. Z tego co czytam to zapotrzebowanie na sieciowcow rosnie 6% rocznie. Przeciez im wiecej urzadzen czy to w chmurze czy on-prem to wiecej roboty dla nas. A ludzi ktorzy ogarniaja sieci + jakas automatyzacje jest na lekarstwo.

[freel4ncer]

Sieciowy będą potrzebni bo mamy coraz wieksze potrzeby komunikacji(przesylu danych) ale wraz ze wzrostem automatyzacji będzie potrzeba mniej poczatkujacych(czy tez slabych ) sieciowcow. Poco zatrudniac horde ludzi na L1 support z CCNA jak wiekszosc roboty zalatwi automatyzacja.
Z czasem moze byc trudniej o wejscie i zdobycie doswiadczenia gdy wiekszosc zacznie porzebowac tylko ekspertow.

[Kyniu]

Chmura już wielu wychodzi bokiem ($$$) i coraz częściej słyszę, że klienci wracają lub planują wrócić przynajmniej w jakimś stopniu do rozwiązań on-prem ewentualnie kombinują z modelem mieszanym.

[martino76]

Chmura już wielu wychodzi bokiem ($$$) i coraz częściej słyszę, że klienci wracają lub planują wrócić przynajmniej w jakimś stopniu do rozwiązań on-prem ewentualnie kombinują z modelem mieszanym.

Dokładnie tak jest mali wracają do on-prem lub mniejszych firm które oferują cloud. Znam kilka takich firm, które po roku w AWS zrezygnowały ze względu na $$

Pozdro

[freel4ncer]

Bo w chumre to trzeba umiec a nie na pale.
Wiekszosc wali w chmure bo cool brzmi robia lift and shift a potem placz ze drogo.
Chmura jest mega jak zaczynasz od zera. Daje niewiarygodne mozliwosci skalowania biznesu.
Albo jak masz juz wszsytko na mikroserwisach.
Jesli migrujesz juz istniejacy biznes a twoje aplikacje to wielkie monolity to sorry ale tanio nie bedzie.
I nie ma tu zadnej winy chmury w tym , wine ponosza niekumaci architekci.
I zeby nie bylo to wiem co mowie bo pracowalem przy migracji duzego biznesu do AWS (migracja zreszta trwa juz 3 rok)

[Kyniu]

I nie ma tu zadnej winy chmury w tym , wine ponosza niekumaci architekci.

Problem w tym, że często gęsto decyzja zapada na kilku szczeblach wyżej, po pokazie wymuskanych slajdów dla CEO, CFO, .... i serwowaniu marketoidowej papki a architekci dostają polecenie A TERAZ ZRÓBCIE.

[freel4ncer]

I nie ma tu zadnej winy chmury w tym , wine ponosza niekumaci architekci.

Problem w tym, że często gęsto decyzja zapada na kilku szczeblach wyżej, po pokazie wymuskanych slajdów dla CEO, CFO, .... i serwowaniu marketoidowej papki a architekci dostają polecenie A TERAZ ZRÓBCIE.

Jasne czasami CTO , CEO czy inny O ale to nie zmienia faktu ze to nie jest wina chmury i chmura nie jest be a wręcz przeciwnie.

[ksos]

Rozumiem ze kazdy w temacie jest po 40?

[nowyk123]

Z czasem moze byc trudniej o wejscie i zdobycie doswiadczenia gdy wiekszosc zacznie porzebowac tylko ekspertow.

Sledze grupe na fejsie cos ,,Praca IT dla Juniorow, Stazystow" tam glownie ludzie pisza, ze bez doswiadczenia komercyjnego ciezko jakby sie teraz przebic juniorowi...