Home Usługi Jak pracuję Abonament O mnie Blog Kontakt Napisz do mnie
Viktor Pashaiev, Senior Linux & DevOps Engineer, Kraków
Senior Linux, SRE & DevOps Engineer

Viktor Pashaiev

Zaczynałem od Slackware na żywej sieci w 2005 roku. Dziś buduję infrastrukturę która faktycznie działa - automatyzacja, Kubernetes, cloud, niezawodność systemów. Dla firm, które nie chcą dzwonić po nocach.

Historia

Kim jestem

Moja zawodowa kariera zaczęła się od Linuksa w 2005 roku od nieco szalonego zadania: migracji całego biura z pirackiego Windows NT na Linuksa na żywej sieci. Wybraliśmy Slackware. Do dziś nie wiem dlaczego, ale zadziałało. Kiedy pierwszy serwer DHCP rozdał adresy IP, poczułem się jak magik. Zmieniłem kolor czcionki w terminalu PuTTY na zielony, poczułem się trochę jak Neo z Matrixa i już nigdy nie oglądałem się za siebie.

Przez ostatnie 20 lat budowałem, automatyzowałem i ratowałem infrastrukturę IT. Zarządzałem wszystkim – od fizycznych serwerów po potężne klastry Kubernetes i środowiska chmurowe. Przez dużą część mojej kariery byłem ostatnią deską ratunku – inżynierem, do którego dzwoniono, gdy krytyczny system produkcyjny padał, nic nie miało sensu, a wszyscy zaczynali panikować.

Okazało się, że w sumie lubię takie sytuacje. Jest pewien specyficzny rodzaj zen w zachowaniu spokoju i czytaniu logów strace czy analizie pakietów sieciowych o 3 nad ranem.

"System zawsze mówi prawdę. Musisz tylko wiedzieć, gdzie szukać."

Przez te wszystkie lata nauczyłem się kilku uniwersalnych prawd:

  • Kopia zapasowa, której nikt nigdy nie przetestował, to tylko plik zajmujący miejsce na dysku.
  • Jeśli konfigurujesz serwer ręcznie więcej niż raz, powinieneś był to zautomatyzować.
  • Im mądrzej wygląda sieć, tym częściej prawdziwa przyczyna problemu jest śmiesznie prosta.

Dziś, jako niezależny konsultant, biorę pełną odpowiedzialność za infrastrukturę moich klientów. Mój cel jest prosty: sprawić, by Twoje serwery były tak stabilne, bezpieczne i przewidywalne, by IT stało się najnudniejszą i najbardziej niezauważalną częścią Twojego biznesu.

Tier-3 Escalation
Gdy wszyscy inni się poddali - dzwonili do mnie. Strace, tcpdump, gdb na poziomie kernela. Większość incydentów okazywała się czymś innym.
Ansible Library → standard
Napisałem bibliotekę ról która stała się standardem wewnętrznym. Czas setup serwera: z kilku dni do godziny. Manual work o 50%+ mniej.
Security jako bloker CI/CD
Build nie przechodzi przy krytycznych podatnościach. Nie jako opcjonalny krok - jako bloker. Teraz wszyscy zapomnieli że było inaczej.
EN C1 · PL C1/C2 · UA/RU native
Dokumentacja, incydenty, komunikacja z klientem po angielsku i polsku - bez bariery językowej.
Umiejętności

Stack technologiczny

IaC & Automatyzacja
TerraformAnsibleGitLab CI/CDGitHub ActionsArgoCDFluxJenkins
Cloud & Containers
AWS (EKS)GCP (GKE)AzureKubernetesOpenShiftDockerKubeVirtVMware vSphere
Monitoring & SRE
PrometheusGrafanaLokiZabbixELK StackNew Relic
Linux & Debugging
RHELUbuntuDebian / SUSE / FreeBSDstracetcpdumpgdbHugePages / NUMA
Sieć & Security
TCP/IPBIND / PowerDNSHAProxy / NginxWireGuardnftables / iptablesCIS Hardening
Programming
PythonBashboto3TerratestMolecule
E-commerce & Web
WooCommerceWordPressPrestaShopStripeRevolut PayInPost / bramki płatnościReactNext.jsTypeScriptREST APISEO & Analytics
Doświadczenie

Gdzie byłem, co robiłem

2019 - teraz
Senior DevOps & Infrastructure Consultant
Freelance / B2B · Remote
  • Pełny stack jednocześnie: architektura, IaC, Tier-3 support, incydenty produkcyjne - dla kilku klientów naraz
  • Terraform + Ansible: czas setup serwera z kilku dni do poniżej godziny
  • Kubernetes na AWS (EKS) i GCP (GKE), ArgoCD, GitOps - setki węzłów, wiele regionów
  • Observability od zera: Prometheus + Grafana + Loki, SLO, dashboardy które działają o 3 w nocy
  • Security scanning jako bloker CI/CD, Linux kernel tuning na poziomie NUMA i HugePages
2016 - 2019
IT Infrastructure Consultant
  • Migracje on-premise → AWS i Azure bez przerw w działaniu usług
  • Biblioteka ról Ansible - wewnętrzny standard, redukcja manual work o >50%
  • Tier-3 debugging: strace, tcpdump, gdb, problemy których vendor nie mógł rozwiązać
  • Zarządzanie dużymi środowiskami VMware vSphere (ESXi / vCenter)
2010 - 2016
Senior SAP Basis & Infrastructure Consultant
  • Linux kernel tuning pod SAP HANA i NetWeaver: HugePages, NUMA, storage I/O
  • Klastry HA 24/7 na Pacemaker i Corosync - zero nieplanowanych przestojów przez kilka lat
  • Kubernetes i OpenShift - setki węzłów, wiele regionów
2005 - 2010
System & Network Administrator
  • Migracja z Windows NT na Linuxa - na żywej sieci. Slackware. Daliśmy radę.
  • Linux i FreeBSD, DHCP, DNS, email, VPN - od zera
Filozofia

Jak podchodzę do pracy

01 - Automatyzacja
Jeśli robisz to drugi raz - zautomatyzuj
Ludzie się męczą i robią błędy, szczególnie w nocy. Skrypty nie. Gdy skrypt się wysypie, przynajmniej zawsze wysypuje się tak samo.
02 - Komentarze
Pisz dlaczego, nie tylko co
Dwa miesiące później patrzysz na swój własny parametr sysctl i nie pamiętasz dlaczego tam jest. Komentarz z kontekstem to list do przyszłego siebie.
03 - Observability
Monitoring od pierwszego dnia
Nie jest to coś co dodajesz później. Później jest zawsze za późno. Dobry dashboard to taki z którego możesz korzystać gdy wszystko się sypie.
04 - Niezawodność
SLO zanim cokolwiek wdrożysz
Jeśli nie zdefiniowałeś co znaczy "działa normalnie", każdy incydent staje się kłótnią. Długą, brzydką kłótnią o 4 w nocy.
05 - Security
Hardening jako część infrastruktury
CIS przez Ansible. Security scanning jako bloker CI/CD. Narzędzia które sprawiają, że robienie tego dobrze jest najłatwiejszą ścieżką.
06 - Głębokość
Nie zatrzymuj się na warstwie aplikacji
Gdy wszystko oczywiste sprawdzone i nie znalezione - strace, tcpdump, gdb. Większość ciekawych problemów leży poniżej miejsca gdzie wszyscy patrzą.
Kontakt

Porozmawiajmy o projekcie

20 lat doświadczenia, pełen stack od architektury po produkcję.

Kraków i remote. B2B, faktura VAT.
Szybki czas reakcji, pełna odpowiedzialność za projekt.