showroute · sas
Program
Instruktor
Opinie
FAQ
Przekazanie powtarzalnych zadań do NOC
Aktualizacja polityk BGP na routerach brzegowych
Provisioning nowego klienta biznesowego
Backup i audyt konfiguracji firewalli jednocześnie
Dodanie sesji BGP + sprawdzenie stanu na wielu routerach
Masowa konfiguracja urządzeń sieciowych
Przekazanie powtarzalnych zadań do NOC
Aktualizacja polityk BGP na routerach brzegowych
Provisioning nowego klienta biznesowego
Backup i audyt konfiguracji firewalli jednocześnie
Dodanie sesji BGP + sprawdzenie stanu na wielu routerach
Masowa konfiguracja urządzeń sieciowych
Automatyczna inwentaryzacja urządzeń
Automatyczny backup konfiguracji
Wyszukiwanie interfejsu po adresie MAC
Dodanie nowego VLAN na switchach
Automatyczny szablon konfiguracji peera eBGP
Cykliczne raporty ze stanu sieci
Automatyczna inwentaryzacja urządzeń
Automatyczny backup konfiguracji
Wyszukiwanie interfejsu po adresie MAC
Dodanie nowego VLAN na switchach
Automatyczny szablon konfiguracji peera eBGP
Cykliczne raporty ze stanu sieci
Zautomatyzuj swoją sieć.
Bez nauki programowania.
Skończ z ręczną konfiguracją, literówkami w politykach i porannymi wiadomościami od szefa. W 9 tygodniach budujesz pipeline CI/CD, który wdraża i weryfikuje konfigurację na wszystkich routerach - zanim wyjdziesz z pracy w piątek.
PROBLEM
Piątek, 23:47. Urządzenie nr 38 z 40.
Wdrożenie nowych polityk BGP. Ręcznie. Przez SSH. Tak jak zawsze.
rtr-edge-38 od północy preferuje inną ścieżkę. ruch rozłożył się asymetrycznie.
Najgorszy błąd to taki, który nie zwraca żadnego komunikatu. Sesja BGP stoi. Router działa. Tylko BGP_IN na rtr-edge-38 nigdy nie została zmieniona — i nikt o tym nie wie przez godzinę.
Jeden playbook Ansible. Jedna komenda. Po każdym commicie weryfikuje aktualną konfigurację — literówka w nazwie polityki nie przeszłaby nigdy.
POSŁUCHAJ AUTORA
„Żeby automatyzować sieć, muszę umieć Pythona” — i dlaczego to nieprawda.
Piotr Wojciechowski w minutę o tym, czego naprawdę musisz wiedzieć, żeby zacząć: trochę systemu, trochę narzędzi, zero deep-dive w programowanie.
TRANSFORMACJA
Od ręcznej konfiguracji do automatyzacji.
ssh admin@rtr-edge-36 conf t route-policy BGP_IN set local-preference 150 ssh admin@rtr-edge-37 ... ...i tak dla 40 routerów
git commit -m "update BGP_IN local-preference" git push origin main # GitLab CI uruchamia pipeline # Ansible wdraża na wszystkich 40 # weryfikuje BGP_IN na każdym routerze
JAK TO DZIAŁA
Dziewięć modułów. Cały program to projekt.
Od teorii i wyboru projektu, przez infrastrukturę i Ansible, do pipeline'u CI/CD działającego w twojej sieci.
Wprowadzenie i wybór projektu
Rozumiesz gdzie automatyzacja pasuje do twojej sieci i jak mierzyć jej skuteczność. Wybierasz pierwszy projekt — konkretne zadanie z własnej infrastruktury.
Infrastruktura i repozytorium kodu
Stawiasz Docker i Docker Compose — środowisko, które będzie podstawą całego stosu. GitLab w kontenerze, pierwsze repozytorium, praca z branchami i merge requestami.
Ansible — pierwsze zmiany w sieci
Piszesz pierwszy playbook, odpytujesz urządzenia, wprowadzasz zmiany. NETCONF, RESTCONF, idempotentność — na swoim sprzęcie, nie na fikcyjnym labie.
CI/CD, Jinja2 i interfejsy programowalne
GitLab CI uruchamia Ansible po każdym commicie. Szablony Jinja2, dynamic inventory, Ansible Vault. Modele YANG, NETCONF Explorer, filtry danych. Pełny stos w produkcji.
DLA KOGO
SAS jest dla ciebie, jeśli:
✓ Jesteś inżynierem sieciowym - routery, switche, firewalle. ISP, enterprise, datacenter - branża nieważna.
✓ Nie chcesz uczyć się programowania - nie musisz. Ansible używa YAML, który czytasz jak zdanie po angielsku.
✓ Miałeś już taką noc - 40 urządzeń, SSH po kolei, commit który przeszedł bez błędu, problem odkryty rano z grafów. I wiesz, że następna jest tylko kwestią czasu.
✓ Masz ograniczony czas - każda lekcja kończy się czymś działającym w twojej sieci. Bez tygodni teorii zanim zobaczysz pierwszy wynik.
✓ Chcesz wyjść z działającą automatyzacją - nie z teorią do szuflady, ale z playbookiem działającym w twojej sieci.
DLACZEGO WARTO
Z SAS wychodzisz z automatyzacją działającą w twojej sieci.
Od pierwszego modułu pracujesz na realnym problemie ze swojej sieci. Po 9 tygodniach masz playbook - nie notatki.
Wychodzisz z gotowym playbookiem — nie z ćwiczeniami.
Od modułu 1. pracujesz na realnym problemie ze swojej sieci. Po SAS masz automatyzację działającą na twoich urządzeniach — nie na fikcyjnym lab.
Jeden program prowadzi cię od zera do działającego pipeline'u.
Docker, Git, Ansible, CI/CD, NETCONF — jeden spójny program, jeden wynik. Każdy moduł buduje na poprzednim. Zamiast zestawu narzędzi — działający pipeline.
Utknąłeś? Piszesz pytanie i dostajesz odpowiedź.
Nie od chatbota, nie po 2 tygodniach na forum — od kogoś, kto wdrażał automatyzację w ISP i Enterprise. Konkretna pomoc przy konkretnym problemie.
Ansible nie tylko wdraża — weryfikuje.
W produkcji ważniejsze od szybkości jest pewność. Playbook po każdej zmianie sprawdza że konfiguracja faktycznie trafiła na każde urządzenie i jest identyczna. Commit który przeszedł bez błędu, ale nic nie zmienił — nie istnieje.
Zmienisz dostawcę — playbook zostaje.
Ansible działa niezależnie od CLI. Piszesz logikę automatyzacji raz — działa na Cisco IOS-XR, Juniper Junos, Arista EOS. Przetarg rozstrzygnięty na Aristę? Drobne zmiany i działamy dalej.
ANSIBLE ≠ PYTHON
YAML czyta się jak zdanie po angielsku.
Spójrz na playbook obok. Nie musisz znać Ansible, żeby zrozumieć co robi - czytasz po nazwach. „Ustaw banner logowania na switchach". „Wgraj banner login". Tekst banera. Tyle.
Każdy task w YAML to dwie rzeczy: nazwa (po polsku, dla człowieka) i moduł (gotowy klocek, który robi robotę). Nie piszesz pętli, nie obsługujesz SSH, nie parsujesz outputu. Mówisz co ma się stać - Ansible wie jak.
To banner, ale playbook aktualizujący route-policy BGP_IN na 40 routerach wygląda tak samo: nazwa, moduł, parametry. Bez literówek BGP_IM, bo nazwę polityki wpisujesz raz.
Python pojawia się w SAS - ale jako kontekst, nie wymóg. Zobaczysz gdzie kończy się YAML i kiedy programowanie naprawdę się przydaje. Żebyś mógł świadomie zdecydować.
- name: Ustaw banner logowania na switchach
hosts: switches
gather_facts: no
tasks:
- name: Wgraj banner login
cisco.ios.ios_banner:
banner: login
text: "Dostep tylko dla uprawnionego personelu."
state: present
PROGRAM · 9 MODUŁÓW · 130+ LEKCJI
Co będziesz umiał po każdym module.
Kliknij moduł, żeby zobaczyć lekcje.
01 Organizacja i wstęp → wiesz, czego się uczysz i po co ⌄
Zanim ruszysz do narzędzi — dowiesz się, czym naprawdę jest automatyzacja sieci, jaki jest efekt końcowy SAS i co robić, żeby program faktycznie przyniósł ci wynik.
- Powitanie i o instruktorze
- O czym jest to szkolenie?
- O czym NIE jest to szkolenie?
- Efekt końcowy programu
02 Wprowadzenie do automatyzacji sieci → wybierasz swój pierwszy projekt ⌄
Skąd pochodzi automatyzacja sieci, jak ją mierzyć i — co najważniejsze — jak wybrać pierwszy realny projekt, który przyniesie wartość w twojej organizacji.
- Historia automayzacji z punktu widzenia inżyniera
- Jak mierzyć skuteczność wprowadzania automatyzacji
- Budowa środowisk do automatyzacji
- Programowanie- czy jest mi to potrzebne?
- Automatyzacja: skrypty
- Automatyzacja: CI/CD
- Automatyzacja: Zero Touch Provisioning
- Automatyzacja: Telemetria
- Narzędzia komercyjne vs open-source
- Jak wybrać pierwszy projekt do automatyzacji?
- Praca domowa
03 Różnorodność narzędzi automatyzacji → orientujesz się w ekosystemie ⌄
Przegląd narzędzi według cyklu życia i zadania: skrypty shell/Python, playbooki Ansible, Git, CI/CD, Terraform, RobotFramework. Widzisz cały obraz i wiesz, gdzie pasuje każde narzędzie.
- Powitanie
- Narzędzia do automatyzacji wg cyklu życia
- Narzędzia do automatyzacji wg zadania
- Narzędzia skryptowe - skypt shell, TCL
- Narzędzia skryptowe - skrypt Python
- Narzędzia do zarządzania konfiguracją - playbook Ansible
- Narzędzia do zarządzania kodem - GitHub, GitLab
- Narzędzia CI - Jenkins, TravisCI, CircleCI
- Narzędzia IaaC - Terraform
- Narzędzia do testów funkcjonalnych - RobotFramework
- Start small, grow big
- Uniwersalne zasady budowania własnej automatyzacji
- Nasz lab automatyzacji
- Narzędzia podstawowe
- pyCharm
- Visual Studio Code
- Podsumowanie i praca domowa
04 Infrastruktura do automatyzacji (Docker) → masz działające środowisko lab ⌄
Stawiasz środowisko z Dockerem — nie uczysz się na produkcji. Docker Compose, Docker Swarm, wolumeny, sieć, własne obrazy. Całe środowisko lab w jednym pliku.
- Powitanie
- Lab vs rozwiązanie produkcyjne
- Wirtualizacja vs. Konteneryzacja
- Dlaczego Docker, a nie Kubernetes?
- Docker - podstawa konterenyzacji
- Docker - sieć
- Docker - storage
- Instalacja Dockera
- Zarządzanie kontenerami za pomocą Dockera
- Zarządzanie zawartością kontenera
- Dołączanie lokalnych zasobów jako wolumeny
- Docker Compose
- Zarządzanie serwisami za pomocą Docker Compose
- Korzystanie z gotowych obrazów vs budowanie własnych
- Docker Swarm
- Funkcjonalności Secrets i Config w Docker Swarm
- Uruchamiamy Docker Swarm i aplikację w stosie
- Wykorzystanie Docker Secrets i Docker Config
- Podsumowanie i praca domowa
05 Git i kontrola wersji (GitLab) → twoja automatyzacja jest wersjonowana ⌄
Instalujesz GitLab w kontenerze, uczysz się pracy z repozytorium — przez WebIDE, CLI i pyCharm. Branche, merge requesty, konflikty. Żaden playbook nie idzie na sieć bez przeglądu.
- Powitanie
- Rola centralnego repozytorium
- Praca grupowa nad projektem
- Własny serwer czy publiczna usługa
- GitHub vs GitLab vs Bitbucket vs inne produkty
- Instalacja GitLab w kontenerze Docker
- Podstawowa konfiguracja GitLab
- Tworzymy pierwszy projekt
- Praca z repozytorium w WebIDE
- Praca z repozytorium w CLI
- Praca z repozytorium w pyCharm
- Praca z branchami
- Tworzenie i zarządzanie merge request
- Praca z forkiem projektu
- Podstawy rozwiązywania konfliktów
- Śledzenie zmian i zarządzanie repozytorium
- Podsumowanie i praca domowa
06 Ansible — część I → piszesz i uruchamiasz playbooki ⌄
YAML, inventory, pierwsze playbooki na urządzeniach sieciowych. NETCONF i RESTCONF. Zmienne, fakty, idempotentność, tryb check. Pierwsze zmiany w laboratorium — nie na produkcji.
- Powitanie
- Środowiska wirtualne w Python
- Tworzenie środowiska wirtualnego venv z linii poleceń i w pyCharm
- Czym jest Ansible
- YAML
- Podstawowe pliki projektu Ansible
- Pierwszy playbook - pobranie danych z urządzenia - część pierwsza
- Pierwszy playbook - pobranie danych z urządzenia - część druga
- Praca z inventory
- Wprowadzanie zmian na urządzeniu i idempotentność
- Testowanie playbooków i zadań za pomocą trybu check mode
- Zarządzanie urządzeniami za pomocą NETCONF
- Zarządzanie urządzeniami za pomocą RESTCONF
- Odczytywanie danych z pliku
- Zmienne
- Fakty
- Troubleshooting
- Korzystanie z dokumentacji
- Podsumowanie
07 CI/CD dla sieci → commit wdraża zmiany automatycznie ⌄
Budujesz pipeline w GitLab CI/CD, który uruchamia Ansible przy każdym commicie. Własny GitLab Runner w Docker, webhooks, integracja z Webex Teams. Prawdziwy projekt ISP jako case study.
- Powitanie
- Koncepcja CI/CD
- Czym jest pipeline
- Webhooks
- Problem fikcyjnego ISP - nasz projekt CI/CD
- Przekazywanie zmiennych do playbooka i proste filtry danych
- Pętla loop po liście w YAML
- Pętla loop po liście w JSON
- Pobieranie zmiennych z pliku
- Budowa własnego obrazu gitlab-runner za pomocą receptury Dockerfile
- Rejestrujemy GitLab Runner w GitLab
- Tworzymy pipeline do wykonania playbooka
- Błędy w wykonaniu pipeline
- Zdalne inicjowanie wywołania pipeline
- Przekazywanie danych w curl za pomocą atrybutu -F
- Przekazywanie danych w curl jako body zapytania API
- Wywoływanie pipeline między projektami GitLab
- Integracja z Webex Teams i innymi narzędziami
- Podsumowanie
08 Ansible — część II → projekt skalowalny i gotowy na zespół ⌄
Zaawansowane techniki: warunki, pętle po listach/dict/hash/inventory, bloki, zarządzanie błędami. Ansible Galaxy, dynamic inventory, szablony Jinja2, role, Vault. Twój projekt nabiera struktury.
- Powitanie
- Instrukcje warunkowe
- Złożone instrukcje warunkowe
- Wykorzystanie statusu wykonania zadania w instrukcjach warunkowych
- Wykorzystanie zmiennych w instrukcjach warunkowych
- Pętla po elementach listy
- Pętla po elementach dict
- Pętla po elementach hash
- Pętla po elementach inventory
- Rejestrowanie zmiennych w czasie wykonywania pętli
- Bloki
- Zarządzanie błędami
- Ansible Galaxy
- Dynamic inventory
- Szablony Jinja2
- Zarządzanie strukturą projektów Ansible
- Ansible Vault
- Podsumowanie
09 Programmable interfaces i modele danych → rozumiesz YANG, NETCONF, RESTCONF ⌄
Modele danych YANG, NETCONF z Advanced Netconf Explorer, RESTCONF. Filtry Ansible do konwersji danych: YAML↔JSON, adresy IP, URL, wyrażenia regularne. Finalizacja projektu i podsumowanie.
- Czym są modele danych i YANG
- NETCONF
- Instalacja i wykorzystanie Advanced Netconf Explorer
- RESTCONF
- Filtry Ansible - sprawdzanie typu danych
- Filtry Ansible - konwersja do YAML i JSON
- Filtry Ansible - operacje na adresach IP
- Filtry Ansible - operacje na URL
- Filtry Ansible - wyrażenia regularne
- Podsumwanie całego programu
PRZYKŁADOWE LEKCJE
Zajrzyj do środka - cztery lekcje za darmo.
Wybierz lekcję z listy i obejrzyj jak wygląda nauka w SAS. Bez rejestracji.
Wybierz lekcję z listy →
INSTRUKTOR
Piotr Wojciechowski
Niezależny konsultant IT, architekt rozwiązań sieciowych i contributor projektu Ansible. Pracuje z klientami z sektora Service Providers i Enterprise - routing, switching, IP/MPLS, SDN, automatyzacja i cloud. Nie jest to wiedza z kursu: to wiedza z projektów.
Twórca Szkoły DevNet.
UCZESTNICY
Co mówią inzynierowie po kursie.
★★★★★
„Świetny kurs, bardzo dobrze prowadzony. Mega poszerza horyzonty w kwestii automatyzacji i poznawania nowych nowych technologii.Polecam"
★★★★★
„Kurs pomógł mi rozwinąć moje umiejętności i otworzyć całą organizację na automatyzację. Doświadczenie Piotra i Tomka, przekazane w prosty, przystępny sposób, nawet dla osób, które nigdy nic nie zaprogramowały. Po ukończeniu kursu, każdy administrator sieci będzie w stanie uprościć swoją pracę, w końcu wszyscy jesteśmy programistami 😉"
★★★★★
„Jeśli potrzebujesz łagodnego wejścia w automatyzację, jeśli coś już wiesz, ale nie wiesz jak to poskładać razem to ten kurs jest dla Ciebie. Pełny profesjonalizm prowadzącego zapewnia, iż tematy są przedstawione w bardzo przystępny i zrozumiały sposób. Patrząc na inne kursy showroute.pl obietnica aktualizacji i poszerzania tematów nie jest czczą obietnicą. Gorąco polecam SAS."
★★★★★
„Dołączyłem do szkolenia z automatyzacji sieci z praktycznie zerową wiedzą na temat Ansible, gitlaba czy CI/CD. Moim celem jest zautomatyzowanie pewnych zagadnień w firmie, w której pracuję (ISP). Czy szkolenie jest dla zupełnych laików komputerowych? Nie. Czy jest dla osób, które nie miały styczności z automatyzacją na zasadzie Ansible? Zdecydowanie tak. Piotr merytorycznie przedstawia teorię związaną z automatyzacją i niezbędnymi w tym procesie narzędziami. W części praktyczniej skupia się na najważniejszych punktach i zachęca do samodzielnych ćwiczeń. Omawia podstawy automatyzacji w Ansiblu, zahaczając przy okazji o dobre praktyki związane z kontrolą wersji czy wirtualnym środowiskiem wykonawczym. Wartością dodaną jest Discord i możliwość konsultacji z Piotrem oraz innymi uczestnikami. Na pewno nie żałuję przystąpienia do SAS, bo z punktu widzenia rozwoju, jest na pewno doskonałym wstępem do dalszego rozwoju w temacie automatyzacji w mojej organizacji."
★★★★★
„Dla wszystkich niezdecydowanych - WARTO Do tematu automatyzacji zadań sieciowych podchodziłem wielokrotnie samemu. Każdy kto to robił zapewne wie, że nie jest to zadanie typu nauczenia się nowej funkcjonalności, wskoczenia na poziom CCNP z CCNA, czy nawet nauki FW startując z poziomu R&S. Wyobraź sobie całkiem nowy świat, pełny różnych zależności. Dla mnie to było coś w czym czułem się niekomfortowo, i każda próba kończyła się tak samo. Na poznawaniu kolejnej zależności, przy jednoczesnym odczuciu że główny cel jest daleko.Przerabiając kolejne lekcje z kursu czułem że posuwam się do przodu(nie tylko poprzez oznaczanie kolejnych lekcji 😉 ), rozumiejąc tematy. Przykłady są świetnie opisane, ale nie jest to też na zasadzie prowadzenia za rączkę czy metody copy&paste wcześniej przygotowanych poleceń bez zastanawiania się co w ogóle jest wykonywane.Sam jestem jeszcze w trakcie kursu. Samą formę uważam za bardzo dobrą, każdy może dostosować tempo do siebie i do swojego życia osobistego. Trenerzy są dostępni na kanale Discord i są bardzo responsywni. W przypadku pojawienia się wątpliwości/problemów starają się naprowadzić na odpowiedź, zamiast dać rozwiązanie od ręki.Szczerze mogę powiedzieć że jest to najlepszy kurs w, którym do tej pory brałem udział. Miła odmiana od oklepanych programów/skryptów, bardzo często prowadzonych przez osoby o małym zrozumieniu tematu. Zdecydowanie dobrze wydane pieniądze.Do zobaczenia na kanale Discord 🙂"
WDROŻENIENIA UCZESTNIKÓW
Co budują inżynierowie po SAS
Każdy uczestnik wychodzi z własnym projektem — oto kilka przykładów z poprzednich edycji.
Monitoring zgodności konfiguracji
Telco · Ansible check mode + alerting
Zero Touch Provisioning dla urządzeń klienckich (B2B)
Service Provider · Ansible + NETCONF
CI/CD dla zmiany community w polityce BGP
Data Center · GitLab pipeline + Ansible
Telemeteria i automatyczne reagowanie na wybranie zdarzenia
Enterprise · RESTCONF + pipeline
Backup konfiguracji 300 urządzeń
ISP · Ansible + GitLab CI
Szablony konfiguracji peera eBGP
ISP · Ansible + GitLab CI
Konfiguracja VLAN-ów na przełącznikach w sieci
Enterprise · Ansible + NetBox inventory
Pre-checki i post-checki na wybranych urządzeniach przed i po wprowadzeniu zmian w sieci
Enterprise · Ansible + NetBox inventory + GITLab CI
ALTERNATYWNA DROGA
Jeśli nie SAS - to co?
Uczciwa odpowiedź: SAS nie jest dla każdego. Oto alternatywy i kiedy mają sens.
Naucz się Pythona samodzielnie
Wiele tutoriali online, dużo elastyczności. Ale Python to tylko język - nie dostaniesz kontekstu sieciowego, gotowego stosu ani projektu.
Działa, jeśli masz czas i motywację
Kursy ogólne (platformy z wieczną promocją)
Dobre do nauki narzędzi osobno. Ansible bez Git bez CI/CD bez kontekstu sieciowego to wiedza, która zostaje w szufladzie.
Działa, jeśli masz czas i motywację
Dokumentacja i metoda prób i błędów
Darmowe, ale kosztowne czasowo. Bez mentora łatwo utknąć na tygodnie na problemie, który ktoś z doświadczeniem rozwiązuje w 5 minut.
Realistycznie: miesiące do wyników
#########↓ ALBO: WSZYSTKO W JEDNYM STOSIE #########
SAS - Szkoła Automatyzacji Sieci
Kompletny stack od Docker po NETCONF, własny projekt od pierwszego modułu, bezpośredni dostęp do instruktora z projektów produkcyjnych. Kolejny piątek o 23:47 - z playbookiem albo bez.
Gotowa automatyzacja w ~9 tygodni
CENNIK
Wybierz sposób wejścia do SAS
Ten sam program. Różny poziom dostępu i wsparcia.
Od 1 września: Solo 800 · Pro 1 800 · Mentoring 4 200 zł brutto
ceny brutto · VAT 23%
- Dostęp do wszystkich 130+ lekcji video
- Materiały do pobrania i ćwiczenia
- Certyfikat ukończenia
- Dostęp przez 12 miesięcy
- Dostęp bezterminowy i aktualizacje
- Społeczność i grupy dyskusyjne
- Konsultacje 1 na 1 z instruktorem
- Wszystko z pakietu Solo
- Dostęp bezterminowy do kursu
- Wszystkie przyszłe aktualizacje programu
- Dostęp do zamkniętej społeczności
- Możliwość zadawania pytań instruktorowi
- Konsultacje 1 na 1 z instruktorem
gwarancja zwrotu 14 dni
- Wszystko z pakietu Pro
- 5 godzin sesji 1 na 1 z instruktorem
- Wspólna praca nad na konkeretnym projektem
- Dostosowanie do twojej sieci
- ⚡ Ograniczona liczba miejsc
gwarancja zwrotu 14 dni
Przygotowaliśmy gotową ulotkę z opisem kursu, korzyściami biznesowymi.
Wyślij szefowi jednym kliknięciem — bez tłumaczenia od zera.
FAQ
Pytania, które pewnie masz.
Czy naprawdę nie muszę znać Pythona?
Naprawdę nie. Ansible używa YAML — deklaratywnego języka, który czytasz jak tekst. Python pojawia się w SAS jako kontekst — zobaczysz gdzie kończy się YAML i kiedy programowanie naprawdę pomaga. Ale żeby wdrożyć automatyzację w twojej sieci — Python nie jest wymagany.
Ile czasu tygodniowo muszę poświęcić?
Realistycznie — 3–5 godzin tygodniowo pozwala skończyć program w 9–12 tygodni. Możesz iść własnym tempem. W pakiecie Pro i Mentoring dostęp do lekcji nie wygasa — wracasz kiedy chcesz.
Jakie urządzenia są wspierane?
Ansible ma moduły dla Cisco IOS/IOS-XE/IOS-XR/NX-OS, Juniper Junos, Arista EOS i wielu innych. W SAS głównie Cisco w środowisku wirtualnym — ale zasady działają tak samo dla każdej platformy z modułem Ansible.
Czym różni się Solo od Pro?
Solo daje ci dostęp do wszystkich lekcji przez 12 miesięcy i certyfikat. Pro daje dostęp bezterminowy, wszystkie przyszłe aktualizacje programu i dostęp do społeczności. Jeśli planujesz wracać do materiałów lub kurs się rozwija — Pro opłaca się bardziej.
Dla kogo jest pakiet Mentoring?
Dla inżynierów, którzy chcą wdrożyć konkretny projekt automatyzacji w swojej organizacji i potrzebują indywidualnego wsparcia. 5 sesji 1 na 1 z Piotrem — skupione na twoim projekcie, twojej sieci, twoich problemach. Liczba miejsc jest ograniczona — jeśli widzisz Mentoring dostępny, nie czekaj.
Czy SAS to tylko Ansible?
Nie. Ansible jest głównym narzędziem do zarządzania konfiguracją, ale SAS to kompletny stack: Docker (środowisko lab), Git i GitLab (kontrola wersji), CI/CD (automatyczne wdrażanie), Ansible (konfiguracja), NETCONF/RESTCONF i modele danych YANG. Wychodzisz z pełnym pipeline'm, nie z jednym narzędziem.
Potrzebuję fakturę pro-forma, co mam zrobić?
Napisz maila na adres hi@showroute.pl z danymi, na jakie ma zostać wystawiona faktura proforma i ilością dostępów. W odpowiedzi dostaniesz fakturę proforma, którą możesz opłacić.
Jak jest realizowany program?
Cały program jest w formie lekcji video, które podzielone są na lekcje z teorią i praktyką. Nie ma spotkań na żywo. Realizujesz materiał w swoim tempie.
Następny piątek w nocy,
z playbookiem albo bez.
9 tygodni. Twoje urządzenia. Pipeline CI/CD który wdraża i weryfikuje każdą zmianę na każdym routerze.
showroute.pl & szkoladevnet.pl
Program SAS – Szkoła Automatyzacji Sieci
© 2026 Showroute.pl · Wszelkie prawa zastrzeżone