Automatyzacja procesu upgrade przełączników

Problemy z pozostałymi technologiami (SDH, IronPort, WAAS itp.)
Wiadomość
Autor
kefear
wannabe
wannabe
Posty: 76
Rejestracja: 19 lis 2009, 19:41

Automatyzacja procesu upgrade przełączników

#1

#1 Post autor: kefear »

Cześć,

650+ przełączników w sieci , 2/3 Arista, reszta Cisco, sieć odseparowana od internetu. Jak rozwiązujecie temat upgrade ?
Wiadomo sam upgrade to nie problem - bardziej chodzi o sprawdzenie czy stan się zgadza: statusy interfejsów, peery BGP, mlag/vpc, routing, PIM etc.

U nas robimy to z palca po ~10 przełączników w jeden dzień (np. sobota). Do tego mamy soft, który wyświetla ładne diffy jednak trzeba trochę poklikać myszką. Suma summarum jest to dosyć czasochłonne.

Jako że jestem leniwy fajnie byłoby coś zautomatyzować ;-) Ktoś coś robi w tym temacie ? Swoje skrypty czy komercyjny soft ? Jak robią to duzi gracze ?

Wojtek

freel4ncer
wannabe
wannabe
Posty: 581
Rejestracja: 27 wrz 2007, 01:13

#2

#2 Post autor: freel4ncer »

Duzi gracze pisza sobie sami takie narzedzia :)
masz tu modul do pythona do parsowania cli otuputu https://github.com/google/textfsm
uzywalismy tego w google . Oczywiscie musisz sobie napisac skrypt zeby podlaczal sie do urzadzen i wykonywal komendy i pobieral output (my mielismy juz gotowe biblioteki do tego ) mozesz wykozystac do tego np kolejny pythonowy modul paramiko https://pynet.twb-tech.com/blog/python/ ... part1.html

polacz to razem , i odpalaj na liscie hostow , jak bys chical przyspieszyc (sprawdzanie kiliku urzadzen na raz zamiast jeden za drugim ) to poczytaj o multiprocesingu albo threadingu


btw super latwo robi sie takie rzeczy na juniperach masz cala biblioteke pythonowa dla junosa
generalnie python twoim przyjacielem :)

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#3

#3 Post autor: lukaszbw »

Brałem raz udział w projekcie aktualizacji około 2.5tyś przełączników 3750G. My to robiliśmy ręcznie mając gotowe listy komend. Za pomocą securecrt możesz kilkanaście urządzeń naraz aktualizować. Do tego łatwo można sobie przygotować sesje ssh przed rozpoczęciem okna serwisowego. Skrypty też są możliwe. Bardzo ważne np. było delay na wprowadzanie komend, zbyt szybkie wpisywanie powodowało, że część uciekała.
Teraz jak masz 15 zakładek otwartych to po kolei wklejasz do każdej i on sobie stopniowo je wpisuje a ty tylko obserwujesz.

W sumie byliśmy w 4-5 osób po kilkadziesiąt przełączników na osobe na nocke. Zależy z iloma miało się problem bo i zdarzały się takie co wogóle nie wstawały po upgrade i trzeba było się wdzwaniać na centrale żeby dostać się do konsoli.

Czemu ręcznie? Było wiele problemów typu zbyt mały flash na niektórych urządzeniach, w zależności od softu różne komendy były wspierane (niektóre miały bardzo stary soft 12.2(25)). Generalnie mnóstwo różnych wersji bo jak były wdrażane to w różnych okresach. Do tego często unikalne problemy typu ftp source interface był zły i nie chciał pobierać pliku itp.

Automatyzacja jest teoretycznie możliwa ale jak często robisz taki uprade na przełącznikach accessowych? Raz, góra 2 w całym ich żywocie a musiałbyś wszystkie możliwe problemy przewidywać.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

freel4ncer
wannabe
wannabe
Posty: 581
Rejestracja: 27 wrz 2007, 01:13

#4

#4 Post autor: freel4ncer »

lukaszbw pisze:Brałem raz udział w projekcie aktualizacji około 2.5tyś przełączników 3750G. My to robiliśmy ręcznie mając gotowe listy komend. Za pomocą securecrt możesz kilkanaście urządzeń naraz aktualizować. Do tego łatwo można sobie przygotować sesje ssh przed rozpoczęciem okna serwisowego. Skrypty też są możliwe. Bardzo ważne np. było delay na wprowadzanie komend, zbyt szybkie wpisywanie powodowało, że część uciekała.
Teraz jak masz 15 zakładek otwartych to po kolei wklejasz do każdej i on sobie stopniowo je wpisuje a ty tylko obserwujesz.

W sumie byliśmy w 4-5 osób po kilkadziesiąt przełączników na osobe na nocke. Zależy z iloma miało się problem bo i zdarzały się takie co wogóle nie wstawały po upgrade i trzeba było się wdzwaniać na centrale żeby dostać się do konsoli.

Czemu ręcznie? Było wiele problemów typu zbyt mały flash na niektórych urządzeniach, w zależności od softu różne komendy były wspierane (niektóre miały bardzo stary soft 12.2(25)). Generalnie mnóstwo różnych wersji bo jak były wdrażane to w różnych okresach. Do tego często unikalne problemy typu ftp source interface był zły i nie chciał pobierać pliku itp.

Automatyzacja jest teoretycznie możliwa ale jak często robisz taki uprade na przełącznikach accessowych? Raz, góra 2 w całym ich żywocie a musiałbyś wszystkie możliwe problemy przewidywać.

Pozdr.
Yyy to co napisales to taka troche lipa ;)
Nie chodiz o to zeby wszystki mozliwe problemy przewidywac .
Musisz wziasc pod uwage ile czasu zajmie ci napisanie takiego skryptu vs ile czasu zajmie wykonanie recznie calosci recznie . Jesli np napiszesz skrypt w 2 dni ktory i tak polegnie w 20-30% przypadkow ale te poprawnie wykonane 70-80% zaoszczedzi ci tydzien pracy to juz sie oplaca pisac . Reszte dokonczysz recznie. Zawsze bedzie jakis corner case i generalnie na usuniecie ich spedza sie wiecej czasu niz na zaskryptowanie powtarzalnych czynnosci dlatego czasem poporstu warto olac te szczegolne przypadki

Btw fajna mozliwosc podszkolenia sie z pythona , zamiast pisac hello world n-ty raz lepiej wziasc sie za cos takiego co ma jakis konkretne zastosowanie ( a potem jaka satysfakcja no i mozesz isc do szefa powiedziec szefie zoszczedzilem tyle i tyle godzin inzynieryjnych : ) )

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#5

#5 Post autor: lukaszbw »

Gdyby coś miało trwać wiele miesięcy to tak ale w pare tygodni można wszystko ogarnąć. Inna sprawa, że ograniczają cię okna serwisowe w centralach. Nie możesz w jeden dzień zrobić upgrade całej sieci. Ryzyko jest zbyt duże i do tego przerwa by dotyczyła nagle dużej ilości klientów. Zaczynasz od kilkunastu co nocke a kończysz na 100-200 na team jak już ludzie nabiorą pewności.

Jak w gre wchodzą miliony $ to wierz mi, zatrudnienie paru kontraktorów z CCIE żeby to zrobili jest warte tego. Wiem, że ciśnie się na usta, że po co do tego CCIE ale jak można zmniejszyć ryzyko o pare procent niewielkim kosztem to nie ma co się bawić.

Oczywiście zależy jak twoja firma chce taki upgrade rozwiązać. W omawianym przypadku takimi rzeczami (migracjami, upgrade, większymi modyfikacjami konfiguracjami) zajmowali się kontraktorzy a NOC skupiał się na ticketach. Za dnia siedział inny team planujący zadania na noc.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

kefear
wannabe
wannabe
Posty: 76
Rejestracja: 19 lis 2009, 19:41

#6

#6 Post autor: kefear »

Z wielu względów nie jesteśmy w stanie robić upgrade większej ilości urządzeń niż 10-12 co weekend także jakiś bulk upgrade generalnie odpada.

Tak jak podejrzewałem i kolega freel4ncer napisał python będzie moim przyjacielem w tym zadaniu. Mimo wszystko jest to task, który będzie się u nas ciągle przewijał, więc może warto poświęcić trochę czasu na kodowanie i ogarnięcię sobie tego np w django, by finalnie któryś z kolegów z niższych leveli mógł kliknąć w przysłowiowego weba aby zrobić upgrade.

Oczywiście wszystko ładnie wygląda na papierze, bo tak jak wspomniał kolega lukaszbw różne wersje softu mają różne komendy, a co do parsowania to różne wersje softu mają także różne wersje outputu (np show int status różni się w różnych wersja EOS Arista).

Anyway jak uda mi się coś ciekawego wymyślić to na pewno się podzielę :)

Seba
CCIE/CCDE Site Admin
CCIE/CCDE Site Admin
Posty: 6223
Rejestracja: 15 lip 2004, 20:35
Lokalizacja: Warsaw, PL

#7

#7 Post autor: Seba »

Z perspektywy Cisco, jeśli masz LMS, a bardziej już Prime Infrastructure, to możesz bulk upgrade zapuścić, wybierając podgrupy urządzeń, lub pojedyncze sztuki. Ustawiasz opcje, że zatrzymujesz job, jak coś się wywala, np. przełącznik nie da się zaktualizować, etc.
Multivendor już nieco gorzej i skryptowanie lub manualne podejście, jak już wspomnieli przedmówcy, może być jedyną opcją.

Skoro macie ograniczenie 10-12 urządzeń na jeden weekend, to pytanie wyciągające, co zajmie więcej czasu, napisanie skryptu, po którym i tak pewnie jakiś manualny check wykonasz, czy też obsługa manualna, czyli ręczne wrzucenie softu i weryfikacja. Przy zastosowania narzędzi takich jak wspomniane przez Łukasza SecureCRT, gdzie do wszystkich otwartych okienek możesz wysłać te same komendy i tym samym odpalać upgrade, robić te same weryfikacje i obserwować output.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe."
A. Einstein

freel4ncer
wannabe
wannabe
Posty: 581
Rejestracja: 27 wrz 2007, 01:13

#8

#8 Post autor: freel4ncer »

O moj boze nie wierze ze CCIE takie rady daja :lol:

Wszyscy daza do zmniejszania ilosci inzynierow a tutaj sugeruje sie zatrudnienie dodatkowych ccie zeby upgrady softu robili :lol:

Albo setki czy tysiace urzadzen z apalca upgradowac dzieki wielu okienkom i wysylaniu tych samych komend , (tu do piero mozna bledy popelnic ) :D

panie siadaj do pythona i nie sluchaj tych glupot , automatyzacja i tylko automatyzacja
Nie trzeba byc programista zeby takie taski zautomatyzowac.
Bawiac sie przytym sporo sie nauczysz a doswiadczenie zdobyte bedzie ci procentowac , zboaczysz ze jak raz sie za to wezmiesz to nagle zaczniesz patrzecz na sieci inaczej .
Np jak budowac sieci / konfiguracje zeby je bylo wlasnie latwiej automatyzowac.

A taka znajomosc praktyczna pythona w sieciach predzej zapewni Ci robote w takich firmach jak Google Facebook czy Amazon niz papierek CCIE. (gdybys kiedys chcial zmienic ofcorz)

Ja ostatnio zmienialem robote i dostalem senior network engineera za naprawde dobra kase nie za to ze jestem super inzynierem sieciowym (bo mam nie seniorow w teamie ktorzy sa lepsi z sieci ) tylko za to ze umiem autmatyzowac pewne rzeczy czy np wlasnie podczas rozmow nad wdrozeniem konfiguracji potrafie wskazac co trzeba zmienic by latwiej bylo to automatyzowac

Przykro mi panowie ale sieci to juz nie tylko klepanie komend z palca w terminalu czas sie obudzic :lol: ciekawe ile czasu zajmuje wam rotacja hasel na urzadznieach , czy moze nei robicie bo za dlugo trwa ;)

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#9

#9 Post autor: lukaszbw »

freel4ncer pisze:ciekawe ile czasu zajmuje wam rotacja hasel na urzadznieach , czy moze nei robicie bo za dlugo trwa ;)
Nic nie zajmuje bo używamy TACACS albo RADIUS :) Obyś kiedyś jakiegoś błędu nie popełnił w tej automatyzacji bo potem firme możesz narazić na milionowe straty. Trzeba zachować złoty środek. Co innego jest dopisanie jedej komendy do urządzenia a co innego żąglowanie wokół operacji typu format czy reload.

Nie wiem jak Google czy Amazon bo nie pracowałem ale w ISP jeżeli mówimy o tysiącach urządzeń to na ogół ich okres wdrażania był wieloletni. Różne wersje oprogramowania, różni ludzie projektowali konfiguracje dla nich, jest sporo różnic. Trzeba nawet brać pod uwagę takie rzeczy, że wczytywanie oprogramowania w niektórych urządzeniach/wersjach oprogramowania może powodować zmiany w OSPF adjacency (jak jest błąd w scheduler i switch nie odpowiada na OSPF hello na czas) bo takie sytuacje też miałem. Czasami też pojawi się istotny komunikat, który przy automatyzacji może zostać przeoczony a potem wpłynąć na stabilność urządzenia.

Jeżeli chodzi o porównywanie output to można się przejechać, najlepiej mieć najważniejsze rzeczy monitorowane po SNMP i na tej podstawie robić porównania jak już.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Seba
CCIE/CCDE Site Admin
CCIE/CCDE Site Admin
Posty: 6223
Rejestracja: 15 lip 2004, 20:35
Lokalizacja: Warsaw, PL

#10

#10 Post autor: Seba »

@ kefear - masz kilka opcji podanych przez różne osoby, dostosuj to do swoich potrzeb i możliwości, patrząc na ten projekt indywidualnie lub wręcz przeciwnie, patrząc na to co Twoja decyzja może wpłynąć również na przyszłe projekty.

<OT>
freel4ncer pisze:O moj boze nie wierze ze CCIE takie rady daja :lol:
...
Przykro mi panowie ale sieci to juz nie tylko klepanie komend z palca w terminalu czas sie obudzic :lol: ciekawe ile czasu zajmuje wam rotacja hasel na urzadznieach , czy moze nei robicie bo za dlugo trwa ;)
W jednym z wątków pisałeś coś o swojej arogancji, w innych przedstawiałeś swoją "miłość" do papierka CCIE, więc zakładam, że jest to przejaw obu tych elementów w pigułce. Oczywiście masz prawo do swoich opinii, żyjemy w wolnym kraju, natomiast chyba Twoje doświadczenie w Google, którym się chwalisz (IMHO jest to raczej powód do dumy) nieco przysłania Ci trzeźwe spojrzenie na to co piszą inni i jak dane problemy można rozwiązać. Nie bój się, nie jesteś w takim podejściu sam, znam kilka osób, które po odejściu z firm, które wymieniłeś, próbowały do każdego projektu podchodzić Amazon way/FB way/Google way, etc i wielokrotnie to się sprawdzało, natomiast czasami tak nie było.

Z tego co przejrzałem ten wątek, żaden z występujący w nim CCIE, mnie wliczając, nie napisał, że automatyzacja, czy też skryptowanie to złe opcje z jakiejkolwiek perspektywy, i że CLI jest the only way. Jakbyśmy tak napisali, to faktycznie mała chłosta by się Nam należała, głównie za ignorancję.

Faktem jest, że od jakiegoś czasu automatyzacja w sieciach stała się jednym z istotnych elementów kontroli pracy środowiska sieciowego i możliwości dynamicznego reagowania na zmiany w innych obszarach biznesu organizacji, czy też tego z czym mamy do czynienia w tym wątku, optymalizacji powtarzalnych procesów. Zwłaszcza jest to istotne i widoczne w środowiskach o dużej skali, ale coraz częściej również w środowiskach średniej, czy małej wielkości. Natomiast też nie zawsze.

Rzeczywistość, zwłaszcza kiedy NIE jest to środowisko tzw. green field, czyli jest to już istniejąca i działająca sieć, jest taka, że nie zawsze automatyzacja jest najlepszą opcją, przynajmniej nie w pierwszym podejściu. To nie znaczy, że nie należy jest wprowadzać, ale czasami po prostu się nie da. Pewne przykłady podał już Łukasz, czasami jest to kwestia polityki firmy i tego jak zdefiniowane są procesy change management bez uwzględnienia procesów automatyzacji, czasami jest to tak trywialna kwestia jak brak dostępu zdalnego in-band czy Out-of-band do urządzenia i trzeba działa takie jak upgrade zrobić "na piechotę", nie możemy też zapomnieć o różnorodności sprzętowej, programowej i konfiguracyjnej, które mogą spowodować, że wytworzenie skryptów, które nam zautomatyzują pewne procesy będzie na danym etapie bardziej czasochłonne i bardziej skomplikowane niż zrobienie czegoś na piechotę, czytaj przez CLI.

Oczywistym jest, że wszystko trzeba robić z głową, i zmiany w sieciówce, które obserwujemy już od jakiegoś czasu, związane z "nowymi" trendami jak wirtualizacja, SDN, automatyzacją, analityka, etc będą stawały się coraz istotniejsze i znacząco wpłyną na to jak będzie wyglądał praca "sieciowca" za rok, pięć czy dziesięć lat.

Myślę, że jesteśmy teraz w takim ciekawym punkcie, że potrzebujemy znajomości obu podejść, zarówno konsola/CLI jak i skryptowanie/automatyzacja. I nie ma tu sztywnego wskazania, które podejście jest lepsze, czy gorsze, czy też częściej używane, ponieważ wszystko zależy od konkretnego środowiska. Chodzi o to, aby używać najlepszego narzędzia biorąc pod uwagę wszystkie czynniki, albo możliwie ich dużo, aby na koniec dnia projekt zakończył się sukcesem. Czy programowalności i automatyzacji w sieciach będzie coraz więcej? Nie mam żadnych wątpliwości, że tak, natomiast jest jeszcze za wcześniej, aby zapomnieć o innych, starszych metodach podejścia do tematu.
No, ale może jestem oczadziały od tego CLI co go dzisiaj używałem ;)
</OT>
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe."
A. Einstein

freel4ncer
wannabe
wannabe
Posty: 581
Rejestracja: 27 wrz 2007, 01:13

#11

#11 Post autor: freel4ncer »

lukaszbw pisze:
Nic nie zajmuje bo używamy TACACS albo RADIUS :)


Pozdr.
Seriously ? Powiedz ze to zart i to nie jest odpowiedz na moje pytanie :P

Kolega Seba tez mi nie napisal jak sie sprawy maja z haslami u niego :D

A wiec tak
Nalezy wam sie chlosta , bo caly czas probojecie zniechecic kolege do proby oskryptowania pewnych powtarzalnych czynnosci , pokazujac swoje manualne rozwiazania tylko z dobrej perspektywy a skryptowe ze zlej. Zasada jest prosta wszedzie i zawsze jesli sie cos oskryptowac da to powinno sie to zrobic .

To nie jest arogancja tylko zdrowe podejscie do problemu.
Ja nie kaze koledze wdrazac odrazu zero touch provisioning czy skryptow ktore same beda siec naprawialy ale sadzac po ilosci urzadzen ktore ma automatyzacja to jedyna droga. Sooner ol later ( better sooner ) kazdy bedzie musial stawic czolo temu tematowi , mysle ze kolega ma swietna mozliwosc zeby sie pobawic .

Stosunek do CCIE ? mam szacunek dla ludzi ktorzy go zdobyli bo wymaga to kupe pracy i napewno posiadaja pewna wiedze ktorej ja nie posiadam .
Czy sam sie tego podejme ? mozliwe ze kiedys lecz teraz mam troche ciekawsze w moim mniemaniu tematy i brak motywacji do pracy nad tym Certyfikatem
Czy mam posiadaczy CCIE za guru wyrocznie , not really ;)
Dlaczego powtarzam ze tak robilismy w Google , oczywiscie z tego samego powodu dla ktorego wy wrzucacie tytul CCIE wszedzie gdzie mozecie :D

Awatar użytkownika
PatrykW
wannabe
wannabe
Posty: 1742
Rejestracja: 31 paź 2008, 16:05
Lokalizacja: UI.PL / Ubiquiti Polska.pl
Kontakt:

#12

#12 Post autor: PatrykW »

freel4ncer pisze:
lukaszbw pisze:
Nic nie zajmuje bo używamy TACACS albo RADIUS :)


Pozdr.
Seriously ? Powiedz ze to zart i to nie jest odpowiedz na moje pytanie :P

Kolega Seba tez mi nie napisal jak sie sprawy maja z haslami u niego :D

A wiec tak
Nalezy wam sie chlosta , bo caly czas probojecie zniechecic kolege do proby oskryptowania pewnych powtarzalnych czynnosci , pokazujac swoje manualne rozwiazania tylko z dobrej perspektywy a skryptowe ze zlej. Zasada jest prosta wszedzie i zawsze jesli sie cos oskryptowac da to powinno sie to zrobic .

To nie jest arogancja tylko zdrowe podejscie do problemu.
Ja nie kaze koledze wdrazac odrazu zero touch provisioning czy skryptow ktore same beda siec naprawialy ale sadzac po ilosci urzadzen ktore ma automatyzacja to jedyna droga. Sooner ol later ( better sooner ) kazdy bedzie musial stawic czolo temu tematowi , mysle ze kolega ma swietna mozliwosc zeby sie pobawic .

Stosunek do CCIE ? mam szacunek dla ludzi ktorzy go zdobyli bo wymaga to kupe pracy i napewno posiadaja pewna wiedze ktorej ja nie posiadam .
Czy sam sie tego podejme ? mozliwe ze kiedys lecz teraz mam troche ciekawsze w moim mniemaniu tematy i brak motywacji do pracy nad tym Certyfikatem
Czy mam posiadaczy CCIE za guru wyrocznie , not really ;)
Dlaczego powtarzam ze tak robilismy w Google , oczywiscie z tego samego powodu dla ktorego wy wrzucacie tytul CCIE wszedzie gdzie mozecie :D
Nie bardzo rozumiem? co masz do TACACS czy RADIUS ?
Czy tez moze powiesz ze lepiej dawac haslo root, niz robic sudo czy tez moze robic na zasadzie kluczy ssh ?

Nie kumam....
.ılı..ılı.

http://www.linkedin.com/in/pwojtachnio
Potrzebujesz projektu na studia z zakresu Cisco Packet Tracer & GNS ? Just give me call :)

Integrujemy i wspieramy IT :)
https://www.ui.pl | https://facebook.com/UIPolska

Jedyne rozwiązania Ubiquiti Networks w Polsce!
https://ubiquitipolska.pl | https://www.facebook.com/groups/Ubiquiti.Polska

freel4ncer
wannabe
wannabe
Posty: 581
Rejestracja: 27 wrz 2007, 01:13

#13

#13 Post autor: freel4ncer »

Ja nie mam nic do Tacacs i Radius ciekawi mnie tylko jak Radius i Tacacs zrobi rotacje hasel do serverow radius i tacacs , local user , snmp , ospf , vrrp , Ipsec itd. :lol:
Niemow mi ze nie macie np local userow na urzadzeniach na wypadek problemow z tacacsem i ze nie rotujecie tych hasel. Przeciez to jest security 101

martino76
CCIE
CCIE
Posty: 883
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Barczewo

#14

#14 Post autor: martino76 »

freel4ncer pisze: Zawsze bedzie jakis corner case i generalnie na usuniecie ich spedza sie wiecej czasu niz na zaskryptowanie powtarzalnych czynnosci dlatego czasem poporstu warto olac te szczegolne przypadki
Te szczególny przypadki, mogą kosztować Cie zbyt wiele :) i raczej powinieneś być na nie przygotowany.
freel4ncer pisze:Ja ostatnio zmienialem robote i dostalem senior network engineera za naprawde dobra kase nie za to ze jestem super inzynierem sieciowym (bo mam nie seniorow w teamie ktorzy sa lepsi z sieci ) tylko za to ze umiem autmatyzowac pewne rzeczy czy np wlasnie podczas rozmow nad wdrozeniem konfiguracji potrafie wskazac co trzeba zmienic by latwiej bylo to automatyzowa
To, moze podzielisz się z kolegami takim skryptem by wszystkim żyło sie łatwiej :P, nie wszyscy musza być programistami. Sam chętnie bym skorzystał z dobrego skryptu, ale nie potrafię go sam napisać bo kiepski ze mnie programista, dlatego własnie wybrałem sieci. A dobry skrypt to nie to samo co plink :)

Pozdro,

freel4ncer
wannabe
wannabe
Posty: 581
Rejestracja: 27 wrz 2007, 01:13

#15

#15 Post autor: freel4ncer »

wiesz wszedzie od lat podpisuje NDA i nie moge sie dzielic zadnym kodem wszystko co kiedykolwiek stworze nalezy do firmy ktora mnei zatrudnia i moglbym miec niemale problemy przez upowszechnianie kodu. Moge natomiast zawsze wskazac droge , tak jak w tym temacie podalem moduly.
Kazda firma rozni sie pod wzgledem reprezentacji intent / state_of_the_world danych
wiec nawet jak bym wam wkleil jakis skrypt to nieskozystalibyscie z niego
niezmienia to faktu ze z checia odpowiem na pytanie jesli potrafie

Wszystko to o czym mowimy jest w zasiegu reki kazdego z was , to nie jest czarna magia zrobcie jakis kurs online z pythona np na courserze , wystarczy ze bedziecie znac podstawy i dzieki spolecznosci pythona i bibliotekom oraz czytaniu takiego stackoverflow jestescie w stanie stworzyc sami skrypty ktore wam wielce pomoga. NIe wierze ze ktos kto zrobil CCIE nie jest wstanie nauczyc sie podstaw pythona !

ODPOWIEDZ