Wnioski ze zwolnień w Cisco
Cisco właśnie ogłosiło kolejną falę zwolnień — tym razem ~4000 pracowników, czyli około 5% załogi. Paradoks? Dzieje się to w kwartale z rekordowymi przychodami: $15,8 mld, wzrost 12% r/r, zysk netto $3,4 mld (+35%).
CEO Chuck Robbins wprost powiedział, że cięcia nie wynikają ze słabości finansowej. Chodzi o realokację kapitału w kierunku obszarów o największym potencjale wzrostu. Cisco koncentruje inwestycje na czterech filarach:
- Silicon i optics — własna produkcja układów scalonych i technologie optyczne
- Security — rozbudowa portfolio cybersecurity
- AI infrastructure — już $5,3 mld sprzedaży w tym roku, cel roczny: $9 mld
- Wdrożenia AI wewnętrznie — automatyzacja procesów w samej firmie
To klasyczny pivot platformowy: mniej ludzi w tradycyjnych obszarach, więcej zasobów tam, gdzie marże będą rosły.
Wzrost zamówień na produkty Cisco wyniósł 35% r/r, w tym spektakularne 105% od hyperscalerów. Sprzęt Wi-Fi urósł o 40%. Cisco nie znika z rynku — wręcz przeciwnie, przyspiesza.
Ale kierunek jest czytelny: tradycyjne role sieciowe, które nie mają komponentu bezpieczeństwa ani AI, będą pod presją. Robbins sygnalizuje, że firmy wygrywające erę AI będą tymi z "fokusem i dyscypliną w alokacji inwestycji". Przekładając to na język inżynierski: generaliści bez specjalizacji w bezpieczeństwie lub automatyzacji stają się mniej konkurencyjni.
Warto też odnotować jeden cyniczny szczegół: zwalnianym pracownikom Cisco "hojnie" oferuje roczny dostęp do szkoleń Cisco U — czyli do platformy, która generuje przychody dla samego Cisco. Marketing w czystej postaci, ale i sygnał, że certyfikaty z obszarów AI, Security i Networking nadal będą walutą na rynku pracy.
Cisco wykonuje ten ruch z pozycji siły, nie słabości — i właśnie dlatego warto go obserwować jako barometr rynku. Jeśli lider segmentu enterprise networking przesuwa ciężar w stronę silicon, optics i security, to znaczy, że tam będzie popyt na kompetencje w ciągu najbliższych 2-3 lat.
Dlaczego użytkownicy zawsze mówią "to problem z siecią"?
Ron Buchalski
Każdy inżynier zna ten scenariusz. Problem zgłoszony jako "awaria sieci" okazuje się czymś zupełnie innym — a Ty i tak jesteś tym, który musi to naprawić.
Użytkownicy operują na poziomie efektu, nie przyczyny. "Aplikacja nie działa" = "sieć nie działa", bo sieć jest tym magicznym medium, przez które wszystko przepływa. To uproszczenie jest dla nich logiczne — i będzie trwać wiecznie.
Problem pogłębia to, że użytkownicy często nie znają szczegółów własnego środowiska. Nie wiedzą, z jakiego serwera korzystają, jaką mają konfigurację, gdzie są ich dane. Oczekują, że Ty to wiesz. Albo że sprawdzisz.
Gdzie tracimy czas
Znajoma sekwencja każdego troubleshootingu z użytkownikiem:
- Diagnoza bez danych — "sprawdź coś, może zadziała"
- Fałszywe tropy
- Cofanie się do tego samego błędnego założenia
- Rozwiązanie problemu, który leży poza Twoją domeną
Każdy z tych kroków kosztuje czas. Twój czas.
Nie zmienisz użytkowników. Ale możesz zmienić proces pierwszego kontaktu.
Zanim ruszysz do konsoli — wymuś minimum informacji. Jaka aplikacja, jaki serwer lub endpoint, od kiedy, czy cokolwiek się zmieniło po stronie użytkownika. Te cztery pytania eliminują połowę fałszywych tropów zanim w ogóle zaczniesz sprawdzać logi.
I jeszcze jedno: kiedy rozwiążesz problem, który nie był sieciowy — udokumentuj. Nie dla siebie. Dla następnego incydentu. Masz dowód, co naprawdę się stało.
Bo użytkownik i tak powie wszystkim, że był problem z siecią.
Cisco Group Based Policy na Nexus
nmodenaRepozytorium zawiera zestaw laboratoriów dotyczących różnych tematów sieciowych. Przykładem jest prosty lab pokazujący zastosowanie Cisco GBP (Group Based Policy) na platformie Nexus.
Monitoring dla OT/ICS
CompSciFutures
APMonitor.py to narzędzie do monitoringu on-premises warstw 2 i 4, stworzone z myślą o sieciach NOC oraz sensorach OT/ICS. Program napisany jest w czystym Pythonie, co pozwala na łatwą modyfikację i działa lokalnie w sieci LAN, zapewniając dostępność monitoringu zasobów niedostępnych z internetu lub wymagających gwarancji dostępności samego monitoringu.
Dlaczego DNS ma dokładnie 13 serwerów root?
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