📬 ISN 197: DEVCOR Znika, AUTOCOR Wkracza: Czy Juniper Cię Sabotuje?

Znika DEVCOR pojawia się AUTOCOR

https://learningcontent.cisco.com/documents/marketing/exam-topics/350-901-AUTOCOR-v2.0-7-9-2025.pdf

W maju Cisco ogłosiło zmiany w certyfikacji DevNet, przekształcając ją w certyfikację z zakresu automatyzacji. W efekcie egzamin DEVCOR został zastąpiony nowym testem AUTOCOR, a jednocześnie wprowadzono szereg aktualizacji, między innymi 300-435 v2.0 ENAUTO: Automating and Programming Cisco Enterprise Solutions oraz 300-635 v2.0 DCNAUTO: Automating and Programming Cisco Data Center Networking Solutions.

Zobaczmy zmiany i nowości w AUTOCOR:

1.0 Software Development and Design (20%)

Te części zostaną usunięte/przesunięte lub ograniczone:

Ogólne koncepcje front-end/back-end, load balancing, architektura aplikacji.
Szczegółowa ocena wzorców architektonicznych aplikacji.
Wybór typów baz danych względem wymagań aplikacji.
Nie będzie nacisku na tworzenie diagramów sekwencji ani release packaging.
Diagnostyka aplikacji na podstawie logów zostanie ograniczona – pojawi się natomiast diagnostyka automatyzacji sieciowej.
Obsługa Git jest uproszczona i skupiona bardziej na automatyzacji niż na zaawansowanych operacjach developerskich.

2.0 Using APIs (20%)

Usunięte/ograniczone:

Szczegółowe implementacje error handling API REST i kontrole przepływu klienta.
OAuth2 i paginacja jako szczegóły aplikacyjne nie są już głównym tematem.
Ogólna optymalizacja HTTP cache kontrolowana przez API nie jest już osobnym punktem.

3.0 Cisco Platforms (20%)

Usunięte:

Szczegółowa praca z platformami Webex Teams, Firepower, Meraki, UCS, DNA Center.
Programowanie skryptów Python dedykowanych konkretnym platformom Cisco.
Tematy związane z AppDynamics oraz custom dashboardami.

4.0 Application Deployment and Security (20%)

Usunięte/ograniczone:

Ogólne praktyki CI/CD dla aplikacji (debugowanie pipeline).
Docker i Kubernetes w kontekście aplikacji.
Zasady 12-factor app.
Szczegółowe zagadnienia bezpieczeństwa aplikacji jak OWASP oraz end-to-end encryption.

5.0 Infrastructure Automation (20%)

RESTCONF konfiguracja IOS XE
Ansible playbook i Puppet manifest do konfiguracji sieci
Zarządzanie konfiguracją sieci i hostowanie aplikacji na urządzeniach Catalyst 9000 oraz Cisco IOx

Zachowane/zmodyfikowane:

Automatyzacja konfiguracji sieci za pomocą Ansible pozostaje, ale rozszerzona o Terraform i Python.
RESTCONF nadal obecny, ale z większym naciskiem na model-driven telemetry.
Puppet manifest zostaje przesunięty lub zastąpiony innymi narzędziami IaC.
Hostowanie aplikacji na urządzeniach mniej eksponowane lub inaczej ujęte.

Co zostanie dodane w Designing, Deploying and Managing Network Automation Systems v2.0?

1.0 Network Automation (30%)

Automatyzacja sieciowa z Ansible, Terraform, RESTCONF (YANG model), Python do konfiguracji VLAN, OSPF, ACL itp.
Wybór podejścia automatyzacji (infrastructure as code, low-code/no-code, custom apps)
Konsumpcja REST API z obsługą paginacji, zaawansowanymi mechanizmami autoryzacji i rate limitingiem

2.0 Infrastructure as Code (30%)

Zaawansowane operacje Git rozszerzone o cherry-pick i squash merge
Diagnostyka CI/CD pipeline w GitLab CE z etapami build/prevalidation/deploy/post-validation
Tworzenie symulacji sieciowej w Cisco Modeling Labs (CML)
Interpretacja Docker Compose file (services, networks, volumes)
Integracja source of truth w automatyzacji sieciowej
Tworzenie YAML/JSON wg YANG-based modeli

3.0 Operations (20%)

Model-driven telemetry: architektura i wykorzystanie danych telemetrycznych
Logging strategii dla automatyzacji sieciowej (syslog, webhooki)
Diagnostyka problemów automatyzacji na podstawie logów i outputu
Change validation dla automatyzacji z pyATS CLI tools
Proces uzyskiwania i wdrażania certyfikatów TLS CA-signed
Bezpieczne praktyki programistyczne: walidacja wejścia, uwierzytelnianie, zarządzanie sekretami

4.0 AI in Automation (20%)

Korzyści i ryzyka AI w automatyzacji sieci (prywatność danych, własność IP)
Analiza ryzyk bezpieczeństwa AI w automatyzacji sieciowej
Budowa MCP servera dla AI-agentów (Python FastMCP)
Tworzenie agentów konwersacyjnych wykorzystujących LLM do automatyzacji sieci
Ocena dokładności rekomendacji AI w automatyzacji

Problem kosztów w nowoczesnym monitoringu sieciowym

W celu lepszego zrozumienia problemów spójrzmy na cenniki najpopularniejszych rozwiązań. Oczywiście rzeczywiste ceny mogą się różnić po negocjacjach dla środowisk produkcyjnych.

New Relic

35 centów za GB przesłanych danych
Strona cenowa nie czyni tego szczególnie jasnym

Datadog

Prawdziwa lista zakupów z opcjami:

15-34 USD za host
60 centów - 1,22 USD za milion rekordów NetFlow
1,06-3,75 USD za milion rekordów logów
1,27-3,75 USD za milion spanów

Dynatrace

15 centów za 100 000 metryk + 0,07 centa za GB dziennie za przechowywanie
2 centy za GB logów + 0,07 centa za GB dziennie za przechowywanie + 0,035 centa za GB zapytań
0,014 centa za 1000 spanów

Grafana

8 USD za 1000 metryk (do 1/minutę)
50 centów za GB dla logów i trace'ów z 30-dniowym przechowywaniem

Te pozornie trywialne stawki szybko przekształcają się w prawdziwe pieniądze w środowiskach produkcyjnych. Oto kilka przykładów z życia:

Przypadek 1: Jedna organizacja porównywała New Relic z Datadog dla aplikacji na Fargate. New Relic był znacznie tańszy do momentu, gdy zaczęli wysyłać logi. Wtedy Datadog stał się 30-40% tańszy.

Przypadek 2: Słynny już przypadek rachunku za 65 milionów USD od Datadog.

Przypadek 3: Jak ujął to jeden anonimowy administrator: "Jedyne co pamiętam to minę CFO, gdy zobaczył rachunek."

W początkach 2000 roku głównym wyzwaniem było identyfikowanie potrzebnych danych i zmuszenie systemów do ich udostępnienia. Koszty spoczywały głównie na infrastrukturze - raz kupionej, praktycznie "darmowej".

Rezultat? Przyjęliśmy praktykę zbierania maksymalnej ilości danych i przechowywania ich na zawsze. Mimo zmian technologicznych, nasze podejście pozostało takie samo.

Alec Isaacson z Grafana opisuje typową rozmowę z klientem:

"Zbieramy metryki CDM z najbardziej krytycznych systemów co 5 sekund, bo kiedyś ktoś został skrzyczany, gdy system był wolny, a metryki nie wyjaśniały dlaczego."

OTel doskonale rozwiązuje problem vendor lock-in. Możliwość przełączania między dostawcami przez prostą zmianę endpointu to rewolucja.

Ale - OTel ma ukrytą wadę: nie zawsze działa EFEKTYWNIE pod względem kosztów.

Przykład 1: Wiadomości logów

Standardowa wiadomość syslog:

<134>1 2018-12-13T14:17:40.000Z myserver myapp 10 - [http_method="GET"; http_uri="/example"; http_version="1.1"; http_status="200"; client_addr="127.0.0.1"; http_user_agent="my.service/1.0.0"] HTTP request processed successfully

Rozmiar: 228 bajtów

Ta sama wiadomość w formacie OTLP:

{
   "resource": {
      "service.name": "myapp",
      "service.instance.id": "10",
      "host.name": "myserver"
   },
   "instrumentationLibrary": {
      "name": "myapp",
      "version": "1.0.0"
   },
   "severityText": "INFO",
   "timestamp": "2018-12-13T14:17:40.000Z",
   "body": {
      "text": "HTTP request processed successfully"
   },
   "attributes": {
      "http_method": "GET",
      "http_uri": "/example",
      "http_version": "1.1",
      "http_status": "200",
      "client_addr": "127.0.0.1",
      "http_user_agent": "my.service/1.0.0"
   }
}

Rozmiar: 520 bajtów (o 25% większy niż JSON, ponad 2x większy niż oryginał)

Przykład 2: Metryki Prometheus

Typowa metryka Prometheus w JSON: 291 bajtów
Ta sama metryka w formacie OTLP: 751 bajtów (2,5x większa)

W celu optymalizacji kosztów zadaj sobie kluczowe pytania:

Co zrobię z tymi danymi?
Kto będzie ich używać?
Jak długo muszę je przechowywać?
Kto za to zapłaci?

Praktyczne rekomendacje:

1. Segmentacja danych

Nie wszystkie dane wymagają przetwarzania przez OTel
Bezpieczeństwo może korzystać z tradycyjnych standardów
Różne zespoły mogą potrzebować różnych narzędzi

2. Optymalizacja zbierania

Unikaj zbierania metryk co 5 sekund bez uzasadnienia
Implementuj inteligentne filtrowanie
Regularnie przeglądaj retention policies

3. Analiza ROI

Przeprowadź szczegółową analizę kosztów przed implementacją
Porównaj koszty z korzyściami biznesowymi
Monitoruj wydatki w czasie rzeczywistym

Juniper Cię nienawidzi?

Większość producentów oznacza porty na obudowie sprzętu sieciowego, jednak Juniper tego nie robi. Dlaczego tak jest? Nie jestem pewien, ale w załączonym linku znajdziesz zdjęcia urządzeń działających na systemie Junos z wyraźnie oznaczonymi numerami portów. Dzięki temu technik nie będzie miał wątpliwości, czy port 1 znajduje się u góry, czy u dołu.

Monitorowanie ruchu sieciowego

Sniffnet to narzędzie do monitorowania ruchu internetowego, które pozwala na wygodne śledzenie i analizę danych przesyłanych przez Twoją sieć. Aplikacja wyróżnia się łatwością obsługi oraz dbałością o prywatność użytkownika, oferując m.in. filtrowanie ruchu, identyfikację ponad 6000 protokołów i usług, a także geolokalizację hostów.

Czy CNAME to Twój wróg?

Przeczytaj całą historię

Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.

Subskrybuj

Masz już konto? Zaloguj się