Skanowanie /24 w 11 sekund zamiast 9 minut
ddibPrzy skanowaniu pingiem każdy nieosiągalny host kosztuje ~2 sekundy oczekiwania (2 pakiety × timeout 1s). W /24 masz 254 hosty. Przy 7 osiągalnych i 247 nieosiągalnych: 247 × 2s ≈ 513 sekund. CPU przez cały ten czas nic nie robi — czeka.
To klasyczny problem I/O-bound. Ping nie obciąża procesora — obciąża cierpliwość.
Python od dawna ma w bibliotece standardowej concurrent.futures. Wystarczy dodać:
from concurrent.futures import ThreadPoolExecutor, as_completed
Kluczowa zmiana w logice skanowania to zastąpienie pętli for następującym blokiem:
with ThreadPoolExecutor(max_workers=50) as executor:
futures = [executor.submit(ping_host, str(ip)) for ip in hosts]
for i, future in enumerate(as_completed(futures), 1):
ip, is_up = future.result()
Zamiast czekać na każdy ping z osobna, wysyłamy 50 jednocześnie. Wynik: 11 sekund zamiast 513.
Trzy elementy, które warto rozumieć
executor.submit() — nieblokujące. Zwraca Future natychmiast i rusza dalej. Nie czeka na ping.
as_completed() — iterator event-driven, bez pollingu. Yielduje Future w kolejności ukończenia, nie wysłania. Dlatego w logach .1 pojawi się przed .2 — bo odpowiedział szybciej.
future.result() — blokuje tylko dla konkretnego Future, który już zakończył pracę. Nie ma busy-waiting.
Dlaczego wątki zamiast procesów? Ping czeka na odpowiedź sieciową — to I/O-bound. ThreadPoolExecutor wystarczy. ProcessPoolExecutor opłaca się przy zadaniach CPU-bound (np. kryptografia, parsowanie dużych plików).
Dlaczego twój agent działa na demo i pada na produkcji
Javier Antich Romaguera
Demo pokazuje, że agent wykonał zadanie przy konkretnych danych wejściowych, w kontrolowanych warunkach, podczas jednego uruchomienia. To nie jest walidacja niezawodności. To jest cherry-picking.
Produkcja wygląda inaczej: token limits, błędy narzędzi, halucynacje generowane z pełnym przekonaniem, zły dobór narzędzia z powodu niejednoznacznych opisów, kaskadowe błędy z jednej literówki w poleceniu użytkownika. Nikt nie pokazuje tego na demo.
Większość zespołów budujących agenty pyta: "Ile tasków agent rozwiązuje poprawnie?"
To pytanie jest niekompletne. Ważniejsze są:
- Dlaczego pozostałe zadania się nie udały?
- Czy agent wiedział, że popełnia błąd?
- Czy halucynował z pewnością siebie?
- Czy awaria mogła być wykryta i zawarta lokalnie?
- Czy system zdegradował się bezpiecznie?
To są pytania o niezawodność. I każdy wystarczająco złożony system operacyjny na nie trafia — prędzej czy później.
Branża przerabiała już ten schemat. Gdy systemy rozproszone stały się zbyt złożone dla klasycznych operacji, Google odpowiedział Site Reliability Engineering. Kluczowy insight SRE: awaria jest nieuchronna — niezawodność polega na jej rozumieniu, izolowaniu i uczeniu się z niej.
Systemy agentowe potrzebują analogicznego podejścia. Autor proponuje termin Agent Reliability Engineering (ARE). Fundamentalna zmiana filozofii: zamiast pytać "jak zrobić agenta bardziej imponującym?" — pytamy "jak sprawić, żeby agent failował bezpiecznie i poprawiał się ciągle?"
Praktycznie oznacza to projektowanie z założeniem nieuchronnej awarii: observability decyzji agenta (nie tylko finalnej odpowiedzi, ale dlaczego wybrał dane narzędzie, jakie miał alternatywy, jak ewoluowała jego pewność), izolacja blast radius błędów, mechanizmy recovery, postmortemy, i ciągłe uczenie z failure patterns.
Multi-agent architectures przestają być wtedy tylko skalowaniem możliwości — stają się mechanizmem niezawodności. Agenci wzajemnie weryfikują swoje wyjścia, kwestionują założenia, porównują wnioski.
Jeśli budujesz lub oceniasz systemy agentowe dla operacji sieciowych, jedno konkretne działanie: zacznij dokumentować przypadki porażek, nie sukcesów. Zbuduj wewnętrzny rejestr: kiedy agent zawiódł, dlaczego, czy wykrył własny błąd, jak system zareagował.
To jest fundament ARE. Organizacje wkrótce przestaną pytać "czy twój agent rozwiązuje zadania?" — zaczną pytać "czy twój system można ufać na produkcji, gdy coś pójdzie nie tak?" To zdecydowanie trudniejsze pytanie. I zdecydowanie ważniejsze.
Projekt NERD
tonybourke
NERD to zestaw poradników i narzędzi (plików, playbooków, skryptów) do tworzenia VM i kontenerów wspomagających automatyzację sieci, szczególnie do laboratoriów. Instrukcje są skierowane do domowych laboratoriów, ale mogą też służyć jako podstawa do produkcyjnych środowisk. Dzięki NERD łatwiej zbudujesz środowisko do nauki automatyzacji sieci z containerlab, VS Code (jako aplikacja webowa) i Ansible/Pythonem.
Deszyfruj hasła Juniper w Python
antoinekh
Pythonowa biblioteka, która pozwala na szyfrowanie i deszyfrowanie haseł $8$. Jeśli korzystasz z uv możesz całość odpalić bez instalacji.
uvx juniper8-crypt --master 'MySecretMasterPw' --decrypt '$8$aes256-gcm$hmac-sha2-256$100$p8XEvHtxRNE$d/hqRmh5etkBzo7WSdtvjg$7w1eMTYXkz4RdzMF9CAkJQ$qVLunbFwBWwyxln2Vg'GitOps zmienia zasady gry
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