@ 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
...
Przykro mi panowie ale sieci to juz nie tylko klepanie komend z palca w terminalu czas sie obudzic
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>