Spis treści

Praca przez proxy prawie zawsze sprowadza się do jednego pytania: ile równoległych żądań realnie wytrzyma połączenie "Twój klient - proxy - serwer docelowy", zanim opóźnienia wzrosną, a błędy zaczną się pojawiać. Ten poradnik nauczy Cię mierzyć to z wyprzedzeniem, a nie w trakcie dużego eksportu danych, gdy czas liczysz w godzinach przestoju.

Wprowadzenie: po co znać limit z wyprzedzeniem, a nie w trakcie dużego eksportu

Wyobraź sobie typową sytuację. Uruchamiasz duże zadanie zbierania publicznych danych przez pulę proxy. Na początku wszystko działa dobrze, ale po pierwszych tysiącach żądań opóźnienia rosną, część żądań zaczyna kończyć się timeoutem, a Ty nie wiesz – czy winien jest Twój kod, proxy, czy serwer docelowy. W tym momencie straciłeś już czas i, być może, dane.

Znacznie rozsądniej jest wcześniej przeprowadzić kontrolowany test obciążeniowy i znaleźć punkt degradacji. Wtedy będziesz mógł dobrać bezpieczną liczbę wątków i poprawnie zaplanować czas eksportu.

Co czytelnik zyska na końcu

Po przejściu poradnika będziesz w stanie samodzielnie:

  • Przygotować poprawny scenariusz obciążeniowy w k6 i uruchomić go przez proxy.
  • Powtórzyć ten sam scenariusz w JMeter z konfiguracją proxy w planie testu.
  • Czytać raport: rozumieć RPS (żądań na sekundę), opóźnienia percentylowe i odsetek błędów.
  • Odróżniać limit proxy od limitu Twojego klienta i od limitu serwera docelowego.
  • Przeliczać wyniki na liczbę wątków, rozmiar puli i oczekiwany czas eksportu.

Dla kogo jest ten poradnik

Materiał jest przeznaczony dla inżynierów, analityków danych i programistów na średnim poziomie zaawansowania. Jeśli pisałeś już proste skrypty w JavaScript lub uruchamiałeś programy z linii poleceń, poradzisz sobie bez problemu. Dla początkujących wyjaśniamy każdy termin prostym językiem.

Co warto wiedzieć wcześniej

Wystarczą podstawowe umiejętności: otwieranie terminala, instalowanie programów i edycja plików tekstowych. Znajomość protokołu HTTP na poziomie "co to jest żądanie i odpowiedź" będzie atutem, ale nie jest wymagana.

Ile czasu to zajmie

Instalacja narzędzi zajmie około 30-40 minut. Pierwszy działający test w k6 uruchomisz w ciągu godziny. Pełny cykl z JMeter i analizą zajmie 3-4 godziny spokojnej pracy.

⚠️ Uwaga: Wszystkie przykłady w poradniku służą do testowania własnego środowiska lub zasobów, na które masz wyraźną zgodę. Testowanie obciążeniowe cudzych usług bez zgody jest niedopuszczalne. O etyce porozmawiamy osobno na końcu.

Przygotowanie: narzędzia, wymagania i dostęp

Zanim zaczniesz mierzyć, musisz przygotować środowisko pracy. Poniżej wypiszemy wszystko, czego potrzebujesz, i pokażemy, jak zainstalować każdy komponent.

Wymagane narzędzia i dostępy

  • k6 – lekkie narzędzie do testów obciążeniowych, scenariusze pisze się w JavaScript.
  • Apache JMeter – klasyczne narzędzie z interfejsem graficznym opartym na Javie.
  • Java 17 lub nowsza – wymagana do uruchomienia JMeter.
  • Dostęp do proxy od Proxeon: adres, port, login i hasło. Te dane otrzymasz w panelu klienta.
  • Cel testowy – Twoje własne środowisko lub uzgodniony zasób.

Wymagania systemowe

Do komfortowej pracy wystarczy komputer z 4 rdzeniami procesora i 8 GB RAM. Do dużego obciążenia (tysiące wirtualnych użytkowników) zalecamy 8 rdzeni i 16 GB RAM. System operacyjny – Windows, macOS lub Linux, wszystkie narzędzia są wieloplatformowe.

Wskazówka: Uruchamiaj generator obciążenia na osobnej maszynie lub w osobnym serwerze w chmurze. Dzięki temu nie pomylisz obciążenia swojego laptopa z obciążeniem proxy.

Instalacja k6

  1. Otwórz oficjalny sposób instalacji dla swojego systemu: na macOS użyj menedżera pakietów Homebrew, komenda brew install k6.
  2. Na Windows użyj menedżera pakietów Chocolatey: choco install k6.
  3. Na Linux pobierz pakiet z repozytorium projektu i zainstaluj go przez menedżer pakietów.
  4. Sprawdź instalację komendą k6 version – zobaczysz numer wersji.

✅ Weryfikacja: Jeśli komenda k6 version wyświetla wersję i nie zgłasza błędu "nie znaleziono polecenia", narzędzie jest zainstalowane poprawnie.

Instalacja Java i JMeter

  1. Zainstaluj OpenJDK w wersji 17 lub nowszej i sprawdź komendą java -version.
  2. Pobierz archiwum Apache JMeter z oficjalnej strony projektu w sekcji pobierania.
  3. Rozpakuj archiwum do wygodnego folderu, np. do katalogu domowego.
  4. Przejdź do podfolderu bin w rozpakowanym JMeter.
  5. Uruchom plik jmeter (na Linux i macOS) lub jmeter.bat (na Windows).
  6. Poczekaj na pojawienie się okna graficznego z drzewem planu testu po lewej stronie.

✅ Weryfikacja: Jeśli otworzyło się okno JMeter z elementem "Test Plan" w drzewie po lewej, wszystko jest gotowe.

Kopie zapasowe i przygotowanie środowiska

Jeśli testujesz własny serwis, wcześniej zrób snapshot lub backup danych środowiska. Obciążenie nie powinno uszkodzić produkcji. Jeśli to możliwe, użyj kopii środowiska, a nie serwera produkcyjnego.

Podstawowe pojęcia prostym językiem

Aby czytać raporty i nie gubić się w terminach, omówimy kluczowe pojęcia.

Przepustowość i RPS

Przepustowość – to ile użytecznej pracy system wykonuje w jednostce czasu. W kontekście HTTP zwykle mierzy się ją w RPS – żądaniach na sekundę. Im wyższy RPS przy akceptowalnych opóźnieniach, tym lepiej.

Opóźnienie i percentyle

Opóźnienie (latency) – czas od wysłania żądania do otrzymania odpowiedzi. Jedna średnia wartość jest myląca, bo rzadkie wolne żądania w niej giną. Dlatego używa się percentyli.

Percentyl p95 oznacza: 95 procent żądań było szybszych niż ta wartość, a 5 procent – wolniejszych. Percentyl p99 pokazuje zachowanie najwolniejszych żądań. To właśnie p95 i p99 najlepiej oddają realne doświadczenie pod obciążeniem.

Odsetek błędów i moment degradacji

Odsetek błędów – procent żądań, które zakończyły się niepowodzeniem: timeouty, odmowy połączenia, kody odpowiedzi 5xx. Moment degradacji – punkt, w którym wzrost obciążenia przestaje zwiększać RPS, za to gwałtownie rosną opóźnienia i błędy. To jest właśnie poszukiwany limit.

Równoległość i wirtualni użytkownicy

Równoległość – ile żądań jest wykonywanych jednocześnie. W k6 definiuje się ją przez VU (virtual users, wirtualnych użytkowników), w JMeter – przez liczbę wątków w grupie (Thread Group). Jeden VU lub wątek wysyła żądania sekwencyjnie, a wiele z nich tworzy równoległe obciążenie.

Proxy w łańcuchu obciążenia

Proxy – pośredni węzeł, przez który przechodzą Twoje żądania. Ma on własny limit liczby jednoczesnych połączeń i przepustowości. Naszym celem jest zrozumienie, na jakim poziomie równoległości ten węzeł zaczyna być wąskim gardłem.

Wskazówka: Miej w głowie prawo Little'a: średnia liczba jednoczesnych żądań jest w przybliżeniu równa RPS pomnożonemu przez średnie opóźnienie w sekundach. Pomaga to szybko oszacować potrzebną równoległość.

Krok 1: Przygotowujemy cel testowy i dane proxy

Cel etapu: uzyskać działający adres celu i poprawnie sformatowany ciąg połączenia do proxy.

  1. Określ URL celu, który będziesz obciążać. Niech to będzie Twoje środowisko, np. adres typu https://stend.local/api/health.
  2. Upewnij się, że cel odpowiada szybko i stabilnie na pojedyncze żądanie przez zwykłą przeglądarkę lub narzędzie curl.
  3. Pobierz dane proxy Proxeon z panelu klienta: host, port, nazwę użytkownika i hasło.
  4. Skompletuj ciąg połączenia w formacie http://NAZWA:HASŁO@HOST:PORT. Na przykład: http://user:pass@proxy.proxeon.net:8000.
  5. Sprawdź proxy pojedynczym żądaniem curl, podstawiając swoje dane zamiast przykładu.

Przykład żądania weryfikacyjnego:

curl -x http://user:pass@proxy.proxeon.net:8000 -H "Accept: application/json" https://stend.local/api/health

⚠️ Uwaga: Nigdy nie przechowuj loginu i hasła proxy bezpośrednio w kodzie, który trafi do repozytorium. Używaj zmiennych środowiskowych. Pokażemy to w kolejnych krokach.

Oczekiwany rezultat: curl przez proxy zwraca poprawną odpowiedź z Twojego celu bez błędów połączenia.

Możliwe problemy: jeśli curl wisi – sprawdź port i zaporę sieciową. Jeśli pojawia się błąd autoryzacji 407 – sprawdź ponownie login i hasło.

✅ Weryfikacja: Widzisz treść odpowiedzi z celu, otrzymaną właśnie przez proxy. Czyli łańcuch działa.

Krok 2: Rozumiemy poprawną metodykę obciążenia

Cel etapu: zrozumieć, dlaczego pojedynczy przypływ żądań jest bezużyteczny i jak zbudować poprawny profil obciążenia.

Dlaczego pojedynczy przypływ wprowadza w błąd

Jeśli jednocześnie uruchomisz tysiąc żądań, otrzymasz ładną, ale bezsensowną liczbę. Taki przypływ nie pokazuje stabilnego zachowania. System może połknąć nagły skok dzięki buforom, a potem zdegradować się. Albo, przeciwnie, zakrztusić się na starcie z powodu zimnych połączeń.

Trzy fazy poprawnego testu

Poprawny test obciążeniowy składa się z trzech faz:

  1. Rozgrzewka (warm-up). Przez pierwsze 30-60 sekund płynnie zwiększamy obciążenie. Nagrzewają się pule połączeń, cache DNS i wewnętrzne struktury. Danych z rozgrzewki nie włączamy do końcowej statystyki.
  2. Stopniowy wzrost (ramp-up steps). Zwiększamy równoległość stopniami: np. 10, 25, 50, 100, 200 VU, zatrzymując się na każdym stopniu na 1-2 minuty. Dzięki temu widzimy, na którym stopniu zaczyna się degradacja.
  3. Stabilna półka (steady state). Ustalamy obciążenie na poziomie tuż poniżej limitu i utrzymujemy je przez 5-10 minut. Półka pokazuje, czy system jest stabilny pod stałym obciążeniem, czy nie ma wycieków i narastających kolejek.

Wskazówka: Nigdy nie wyciągaj wniosków z pierwszych 30 sekund testu. Poczekaj, aż system wejdzie w stan ustalony, dopiero potem patrz na liczby.

Co rejestrujemy na każdym stopniu

  • Osiągnięty RPS.
  • Opóźnienia p50, p95, p99.
  • Odsetek błędów.
  • Liczbę aktywnych VU lub wątków.

Moment degradacji określamy tak: znajdujemy stopień, po którym RPS przestał rosnąć, a p95 i odsetek błędów zaczęły gwałtownie wzrastać. Poprzedni stopień to Twoja bezpieczna punkt robocza.

✅ Weryfikacja: Potrafisz własnymi słowami wyjaśnić, czym różni się rozgrzewka od półki i po co jest stopniowy wzrost.

Krok 3: k6 – gotowy scenariusz z proxy i stopniami obciążenia

Cel etapu: utworzyć i uruchomić działający scenariusz k6, który przechodzi przez rozgrzewkę, stopnie i półkę przez proxy.

Jak k6 współpracuje z proxy

k6 czyta adres proxy ze zmiennych środowiskowych HTTP_PROXY i HTTPS_PROXY. To wygodne: nie musisz umieszczać danych w skrypcie, wystarczy przekazać je przy uruchomieniu.

Gotowy skrypt load-test.js

Utwórz plik load-test.js i wklej do niego następujący kod. Zamień adres celu na swój.

import http from 'k6/http'; import { check, sleep } from 'k6'; import { Trend, Rate, Counter } from 'k6/metrics'; const latency = new Trend('req_latency', true); const errors = new Rate('req_errors'); const ok = new Counter('req_ok'); export const options = { discardResponseBodies: true, thresholds: { req_errors: ['rate<0.02'], http_req_duration: ['p(95)<1500', 'p(99)<3000'], }, scenarios: { ramp: { executor: 'ramping-vus', startVUs: 0, stages: [ { duration: '1m', target: 10 }, { duration: '2m', target: 25 }, { duration: '2m', target: 50 }, { duration: '2m', target: 100 }, { duration: '2m', target: 200 }, { duration: '5m', target: 200 }, { duration: '1m', target: 0 }, ], gracefulRampDown: '30s', }, }, }; const TARGET = __ENV.TARGET_URL || 'https://stend.local/api/health'; export default function () { const res = http.get(TARGET, { timeout: '10s', tags: { name: 'target' } }); latency.add(res.timings.duration); const good = check(res, { 'status is 200': (r) => r.status === 200 }); errors.add(!good); if (good) ok.add(1); sleep(0.5); }

Jak uruchomić scenariusz przez proxy

  1. Otwórz terminal w folderze ze skryptem.
  2. Ustaw zmienne środowiskowe z adresem proxy i celem. Na Linux i macOS wykonaj eksport zmiennych.
  3. Uruchom k6 komendą uruchomienia skryptu.

Przykład uruchomienia na Linux i macOS:

export HTTP_PROXY=http://user:pass@proxy.proxeon.net:8000 export HTTPS_PROXY=http://user:pass@proxy.proxeon.net:8000 export TARGET_URL=https://stend.local/api/health k6 run load-test.js

Na Windows w PowerShell zmienne ustawia się przez składnię $env:

$env:HTTP_PROXY="http://user:pass@proxy.proxeon.net:8000"; $env:HTTPS_PROXY="http://user:pass@proxy.proxeon.net:8000"; $env:TARGET_URL="https://stend.local/api/health"; k6 run load-test.js

Wskazówka: Parametr discardResponseBodies wyłącza przechowywanie treści odpowiedzi w pamięci. Zmniejsza to obciążenie samego generatora i pomaga nie pomylić jego przeciążenia z limitem proxy.

Czytanie raportu k6

Po zakończeniu testu k6 wyświetla podsumowanie. Zwróć uwagę na kluczowe linie:

  • http_reqs – całkowita liczba żądań i średni RPS w nawiasach. To Twoja przepustowość.
  • http_req_duration – opóźnienia, gdzie pokazane są avg, min, med, max oraz percentyle p(90), p(95).
  • req_errors i http_req_failed – odsetek błędów.
  • vus – liczba wirtualnych użytkowników w danym momencie.

Linia thresholds pokaże, czy Twoje progi zostały spełnione. Jeśli obok linii jest krzyżyk, próg został naruszony – oznacza to, że na tej konfiguracji limit został już osiągnięty lub przekroczony.

⚠️ Uwaga: Wartości target w stages dobieraj do swojego systemu. Wartość 200 VU jest podana jako przykład. Jeśli Twój cel lub limit planu proxy jest mniejszy, zacznij od skromniejszych stopni, na przykład do 50.

Oczekiwany rezultat: test zakończony, widzisz podsumowanie z RPS, percentylami i odsetkiem błędów.

Możliwe problemy: jeśli wszystkie żądania padają, sprawdź zmienne proxy. Jeśli generator zużywa 100 procent CPU – zmniejsz liczbę VU lub uruchom test na mocniejszej maszynie.

✅ Weryfikacja: W podsumowaniu k6 widać niezerowy http_reqs, a odsetek błędów jest poniżej Twojego progu przynajmniej na pierwszych stopniach.

Krok 4: JMeter – ten sam scenariusz z konfiguracją proxy w planie testu

Cel etapu: zbudować równoważny plan w JMeter z proxy, stopniami i zbieraniem metryk.

Tworzymy grupę wątków

  1. W otwartym JMeter kliknij prawym przyciskiem myszy na element Test Plan.
  2. Wybierz Add - Threads (Users) - Thread Group.
  3. W polu Number of Threads ustaw maksymalną liczbę wątków, np. 200.
  4. W polu Ramp-up period podaj czas wejścia na pełne obciążenie w sekundach, np. 540, aby powtórzyć stopniowy wzrost z k6.
  5. W polu Loop Count zaznacz Infinite, a długość określimy timerem i planistą.

Konfiguracja proxy w HTTP Request Defaults

Aby nie wpisywać proxy w każdym żądaniu, ustawimy je raz.

  1. Kliknij prawym przyciskiem myszy na Thread Group i wybierz Add - Config Element - HTTP Request Defaults.
  2. W otwartym elemencie znajdź zakładkę z ustawieniami serwera proxy.
  3. W polu Server Name or IP (w bloku Proxy) wpisz host proxy, np. proxy.proxeon.net.
  4. W polu Port Number (Proxy) wpisz port, np. 8000.
  5. W polach Username i Password (Proxy) wpisz swój login i hasło.

Dodajemy samo żądanie HTTP

  1. Kliknij prawym przyciskiem myszy na Thread Group, wybierz Add - Sampler - HTTP Request.
  2. W polu Protocol wpisz https.
  3. W polu Server Name or IP wpisz domenę celu, np. stend.local.
  4. W polu Path wpisz ścieżkę, np. /api/health.
  5. W polu Method zostaw GET.

Dodajemy opóźnienie między żądaniami

  1. Kliknij prawym przyciskiem myszy na HTTP Request i wybierz Add - Timer - Constant Timer.
  2. W polu Thread Delay wpisz 500 milisekund, aby powtórzyć sleep z k6.

Konfigurujemy zbieranie metryk

  1. Kliknij prawym przyciskiem myszy na Thread Group i dodaj Add - Listener - Summary Report.
  2. Dodaj także Add - Listener - Aggregate Report – pokazuje percentyle.
  3. Do długich testów nie używaj graficznych słuchaczy, bo zajmują pamięć. Zamiast tego zapisuj wyniki do pliku.

Wskazówka: Do ciężkich testów uruchamiaj JMeter w trybie bez graficznego interfejsu. Wtedy generator zużywa zasoby na obciążenie, a nie na rysowanie wykresów.

Przykład uruchomienia w trybie bez graficznego interfejsu:

jmeter -n -t plan.jmx -l results.jtl -e -o report

Tutaj -n uruchamia bez grafiki, -t wskazuje plik planu, -l – plik z surowymi wynikami, a -e -o tworzy raport HTML w folderze report.

Czytanie raportu JMeter

Otwórz index.html z folderu report. Kluczowe wskaźniki:

  • Throughput – przepustowość w żądaniach na sekundę.
  • Response Times Percentiles – wykres percentyli opóźnienia.
  • Error percentage – odsetek błędów.
  • Active Threads Over Time – jak rosła równoległość.

⚠️ Uwaga: W autoryzacji proxy JMeter czasem wymaga dodatkowej konfiguracji Basic. Jeśli widzisz masowe błędy 407, dodaj element HTTP Authorization Manager z danymi proxy.

Oczekiwany rezultat: raport HTML JMeter otwiera się i pokazuje throughput, percentyle i odsetek błędów.

✅ Weryfikacja: Wartości throughput i percentyli w JMeter są porównywalne z wynikami k6 przy tych samych stopniach. Niewielkie różnice są normalne.

Krok 5: Odróżniamy limit proxy od limitu klienta i limitu serwera – trzy testy

Cel etapu: dokładnie określić, który z trzech węzłów stał się wąskim gardłem.

Kiedy widzisz degradację, ważne jest zrozumienie jej źródła. Przeprowadź trzy testy kontrolne.

Test 1: czy Twój klient nie jest ograniczeniem

  1. Podczas testu otwórz monitor systemu na maszynie-generatorze.
  2. Obserwuj zużycie CPU i pamięci RAM procesu k6 lub JMeter.
  3. Sprawdź limit otwartych deskryptorów plików na Linux komendą ulimit -n.

Jeśli CPU generatora jest blisko 100 procent lub osiągasz limit deskryptorów – winowajcą jest klient, a nie proxy. Podnieś limit deskryptorów, zmniejsz liczbę VU lub użyj mocniejszej maszyny.

Wskazówka: Oznaką przeciążenia klienta jest wzrost opóźnień jednocześnie ze wzrostem zużycia CPU generatora przy stałym RPS. Proxy nie ma z tym nic wspólnego.

Test 2: czy serwer docelowy nie jest ograniczeniem

  1. Uruchom krótki test bezpośrednio, bez proxy, usuwając zmienne HTTP_PROXY i HTTPS_PROXY.
  2. Porównaj RPS i percentyle z wynikami przez proxy.

Jeśli zarówno bezpośrednio, jak i przez proxy limit RPS jest prawie taki sam – wąskie gardło znajduje się na serwerze docelowym. Proxy dodaje jedynie niewielkie stałe opóźnienie.

⚠️ Uwaga: Test bezpośredni wykonuj tylko wobec własnego środowiska. Nie obciążaj cudzych zasobów bez zgody, nawet w celach diagnostycznych.

Test 3: izolujemy samo proxy

  1. Postaw na swoim środowisku lekki atrapę, która natychmiast odpowiada 200 OK z pustym ciałem.
  2. Przepuść test przez proxy przeciwko tej atrapie.

Atrapa odpowiada niemal natychmiast, więc opóźnienia i limit RPS zależą teraz głównie od proxy i sieci. Jeśli RPS osiąga sufit właśnie na atrapie – znalazłeś limit proxy.

Podsumujmy logikę prostą tabelą decyzyjną:

  • CPU generatora wysokie, RPS nie rośnie – limit klienta.
  • Bezpośrednio i przez proxy tak samo – limit serwera docelowego.
  • Na szybkiej atrapie przez proxy RPS osiąga sufit – limit proxy.

Oczekiwany rezultat: wskazujesz konkretny węzeł, który ogranicza Twoje połączenie.

✅ Weryfikacja: Przeprowadziłeś wszystkie trzy testy i potrafisz uzasadnić, gdzie dokładnie jest wąskie gardło.

Krok 6: Co zrobić z wynikiem – wątki, pula i czas eksportu

Cel etapu: zamienić liczby z testu na praktyczne ustawienia Twojego zadania roboczego.

Wybór bezpiecznej liczby wątków

Weź stopień przed momentem degradacji. Załóżmy, że przy 100 VU uzyskałeś stabilne 180 RPS, p95 około 900 ms i błędy poniżej 1 procenta, a przy 200 VU RPS nie wzrósł, za to p95 skoczyło do 4 sekund. Wtedy punkt roboczy to około 100 VU, a dla zapasu weź 80-90.

Obliczanie rozmiaru puli proxy

Jeśli jeden węzeł proxy stabilnie utrzymuje N równoległych połączeń, a potrzebujesz M jednoczesnych, to minimalny rozmiar puli wynosi M podzielone przez N z zaokrągleniem w górę plus zapas. Zapas 20-30 procent pokrywa momenty, gdy część połączeń jest zajęta przez wolne odpowiedzi.

Wskazówka: Zawsze kalkuluj zapas puli. Rzeczywiste odpowiedzi są wolniejsze niż atrapy, a więc połączenia są utrzymywane dłużej i równoległość faktyczna jest wyższa niż teoretyczna.

Szacowanie czasu eksportu

Formuła jest prosta: czas w sekundach równa się całkowitej liczbie żądań podzielonej przez stabilny RPS. Jeśli potrzebujesz zebrać 1 000 000 żądań przy stabilnym 180 RPS, to około 5556 sekund, czyli około 1 godziny 33 minut bez uwzględnienia pauz i powtórzeń.

  1. Weź stabilny RPS z roboczego stopnia.
  2. Podziel całkowity wolumen zadania przez ten RPS.
  3. Dodaj 15-20 procent na powtórki nieudanych żądań i pauzy.

Przykład obliczenia w pseudokodzie dla poglądowości:

total = 1000000; rps = 180; base_sec = total / rps; final_sec = base_sec * 1.2; 












O autorze







Roman Melnikov












Roman Melnikov


Technical Writer and System Administrator














Doświadczenie zawodowe:
Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.













Wykształcenie:

Bauman Moscow State Technical University. Information Systems and Technologies














Ekspertyza:


Technical Documentation
DevOps
System Administration
Linux
Docker and Kubernetes
CI/CD
Infrastructure Automation
Cloud Technologies
System Monitoring
Bash and Python Scripting























Podziel się artykułem: