Pytania rekrutacyjne: scenariusze

Wstęp

„Dobra, to teraz sytuacja. Poniedziałek, 9:05, dzwoni księgowość, że system działa strasznie wolno. Co robisz?”

To nie jest pytanie o komendę. To pytanie o to, jak myślisz. Rekruter nie ma w głowie jednej poprawnej odpowiedzi. Chce usłyszeć metodę: od czego zaczynasz, co wykluczasz, w którym momencie przestajesz zgadywać i zaczynasz mierzyć.

Dziś ostatnia lekcja modułu. Scenariusze, czyli pytania, na których odpada najwięcej kandydatów. I przepis na odpowiedź, który działa nawet wtedy, gdy nie znasz konkretnej komendy.

Przepis na odpowiedź w scenariuszu

Pięć kroków. Zapisz je sobie na karteczce, tej samej co sort | uniq -c | sort -rn.

1. Dopytaj. „Wolno, czyli co? Cały serwer czy jedna aplikacja? Od kiedy? Czy coś się zmieniało?”. Dwa pytania, nie dwadzieścia.
2. Najpierw nie szkodź. Nie restartujesz w ciemno, bo restart kasuje dowody.
3. Od ogółu do szczegółu. Najpierw obraz całości, potem zawężanie: procesor, pamięć, dysk, sieć, logi.
4. Mów, co sprawdzasz i po co. „Sprawdzam uptime, żeby zobaczyć load i czy serwer się nie zrestartował”. Rekruter słyszy myślenie, nie listę komend.
5. Zamknij pętlę. Co naprawiasz od ręki, jak zapobiegasz na przyszłość i że to zapisujesz w zgłoszeniu albo raporcie po awarii.

Ten przepis to w zasadzie metoda z lekcji 100, tylko mówiona na głos i w dwie minuty.

Scenariusz 1: „Serwer jest wolny. Co robisz?”

Odpowiedź na głos: Najpierw dopytuję, czy wolny jest cały serwer, czy jedna aplikacja, i od kiedy. Potem na serwerze: uptime, żeby zobaczyć load average na tle liczby rdzeni i czy serwer nie wstał przed chwilą. Potem top, gdzie patrzę na zużycie procesora, a w nim na wa, czyli czekanie na dysk, i na pamięć. free -h i vmstat 1, czy nie swapuje. iostat -x 1, czy dysk nie jest zapchany. df -h, bo pełny dysk potrafi wszystko spowolnić. Na koniec logi: dmesg -T i journalctl -p err -b. Jak znajdę winowajcę, sprawdzam, czemu się tak zachowuje, zanim go zabiję.

Pokaz: uruchomiłem w tle pętlę, która kręci się bez sensu i zjada procesor, a potem przeszedłem ścieżkę:

uptime
ps -eo pid,user,%cpu,%mem,stat,cmd --sort=-%cpu | head -4
vmstat 1 3
iostat -x 1 2

 22:46:41 up  6:28,  0 user,  load average: 0.42, 0.97, 0.70
  PID USER     %CPU %MEM STAT CMD
24625 root     98.3  0.0 RN   sh -c while :; do :; done
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 4566548 314564 2632136    0    0     0     0  498  236 50  1 49  0  2  0
 1  0      0 4566548 314564 2632136    0    0     0     0  491  239 50  0 50  0  0  0

Czytamy: jeden proces bierze 98 procent jednego rdzenia. W vmstat us 50 i id 50, bo mam dwa rdzenie, a moja pętla zjada jeden. wa zero, czyli dysk niewinny. si i so zero, czyli bez swapowania. Load jeszcze niski, bo pętla ruszyła kilka sekund wcześniej, a load to średnia. Za minutę będzie bliżej jedynki. W iostat patrzyłbym na kolumnę %util i czasy oczekiwania r_await, w_await. U mnie dyski się nudziły.

Czego rekruter naprawdę szuka: kolejności i tego, że rozróżniasz cztery zasoby: procesor, pamięć, dysk, sieć. Plus „nie restartuję w ciemno”.

Zła odpowiedź: „Restart i patrzę, czy pomogło.” Czasem pomaga. Ale wtedy nie wiesz, co się stało, i w przyszły poniedziałek znowu dzwoni księgowość.

Scenariusz 2: „Procesor na 100 procent. Co dalej?”

Odpowiedź na głos: W top sortuję po procesorze i patrzę, czy to jeden proces, czy wiele. Sprawdzam, czyj on jest, od kiedy działa i co robi: ps -o pid,etime,cmd -p PID, jego logi, a w razie potrzeby strace -p PID albo top -H -p PID, żeby zobaczyć wątki. Jeśli procesor w top jest zajęty w sy, to praca jądra, jeśli w us, to program. Jeśli to legalne zadanie, na przykład backup, mogę obniżyć mu priorytet przez renice. Jeśli zapętlona aplikacja, zgłaszam programistom z dowodami, a na teraz grzecznie kill -15 i restart usługi. Jeśli to coś, czego nie znam, na przykład dziwny proces z /tmp, traktuję to jak incydent bezpieczeństwa: koparka kryptowalut też lubi 100 procent.

ps -eo pid,user,%cpu,etime,cmd --sort=-%cpu | head
sudo top -H -p <PID>
sudo renice +10 -p <PID>
ls -l /proc/<PID>/exe

/proc/PID/exe pokazuje, jaki plik naprawdę działa. Jeśli to /tmp/.x/kworker (deleted), to nie jest proces jądra, tylko ktoś, kto bardzo chce go udawać.

Czego rekruter naprawdę szuka: że wysokie CPU nie zawsze jest problemem (serwer jest od tego, żeby pracował) i że bierzesz pod uwagę bezpieczeństwo.

Zła odpowiedź: „kill -9 na wszystko, co jest na górze w top.” Na górze w top bywa baza danych. Ta, z której księgowość robi przelewy.

Scenariusz 3: „Dysk jest pełny. Co robisz?”

Odpowiedź na głos: df -h, który system plików. Potem df -i, bo mogą się skończyć i-węzły, a nie miejsce. Szukam, co urosło: du -xh --max-depth=1 od góry i schodzę w największy folder, zwykle kończy się na /var/log, /var/lib albo czyimś folderze domowym. Jeśli df i du się nie zgadzają, lsof +L1 szuka usuniętych, a otwartych plików. Na szybko zwalniam miejsce bezpiecznie: kompresuję albo zeruję stare logi, czyszczę dziennik przez journalctl --vacuum-size, cache pakietów. Na przyszłość rotacja logów, monitoring z progiem ostrzegawczym i, jeśli trzeba, powiększenie woluminu LVM.

df -h
df -i
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -rh | head
sudo lsof +L1
sudo journalctl --disk-usage
sudo journalctl --vacuum-size=500M

1.5G	/var/lib
1.5G	/var
8.7M	/var/cache
4.5M	/var/log

I ciekawostka, która robi wrażenie: na ext4 część miejsca jest domyślnie zarezerwowana dla roota. Sprawdziłem na moim małym obrazie dysku:

sudo tune2fs -l ino.img | grep -E "Block count|Reserved block count"

Block count:              5120
Reserved block count:     256

256 z 5120 to 5 procent. Dlatego zwykły użytkownik widzi „pełny dysk”, a root jeszcze coś zapisze i może się zalogować, żeby posprzątać.

Czego rekruter naprawdę szuka: df -i, lsof +L1 i tego, że nie kasujesz w panice. Logi są dowodem tego, co się stało.

Zła odpowiedź: „rm -rf /var/log/*.” Miejsce wróciło? Nie, bo programy trzymają te pliki otwarte. Za to dowody zniknęły na pewno.

Scenariusz 4: „Użytkownik mówi, że nie może się zalogować”

Odpowiedź na głos: Dopytuję: gdzie się loguje, przez SSH, konsolę, aplikację, i jaki dokładnie widzi komunikat. Potem sprawdzam konto: czy istnieje (getent passwd), czy ma normalną powłokę, a nie nologin, czy nie jest zablokowane (passwd -S), czy nie wygasło hasło albo konto (chage -l), czy nie zablokowały go nieudane próby (faillock --user). Potem log logowań, [Ubuntu] auth.log, [RHEL] secure, bo tam zwykle jest napisane wprost, czemu. Na końcu rzeczy dookoła: pełny dysk, plik /etc/nologin, który blokuje logowanie wszystkim poza rootem, i przy SSH wszystko z poprzedniej lekcji.

Sprawdziłem to na koncie nobody, które z założenia nie powinno się logować:

getent passwd nobody
su nobody -c true
sudo chage -l nobody | head -4
sudo passwd -S nobody

nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
This account is currently not available.
Last password change					: Oct 24, 2026
Password expires					: never
Password inactive					: never
Account expires						: never
nobody L 2026-10-24 0 99999 7 -1

Dwie przyczyny naraz: powłoka nologin, która grzecznie mówi „This account is currently not available”, i litera L w passwd -S, czyli hasło zablokowane. Dla nobody to dobrze. Dla księgowej w poniedziałek rano już nie.

Czego rekruter naprawdę szuka: że zaczynasz od komunikatu i logu, a nie od resetu hasła. I że znasz chage, passwd -S, faillock.

Zła odpowiedź: „Resetuję hasło.” A konto było zablokowane po pięciu próbach, więc nowe hasło też nie działa. I masz drugi telefon.

Scenariusz 5: „Skrypt działa, jak go uruchamiam ręcznie, a z crona nie. Dlaczego?”

Odpowiedź na głos: Bo cron uruchamia go w zupełnie innym świecie. Raz: bardzo krótki PATH, na Debianie i Ubuntu w crontabie użytkownika tylko /usr/bin:/bin, więc komendy z /usr/local/bin czy /usr/sbin nie są znajdowane. Dwa: inny folder roboczy, zwykle domowy, więc ścieżki względne prowadzą gdzie indziej. Trzy: powłoka /bin/sh, a nie Bash, i brak moich zmiennych z .bashrc. Cztery: znak % w linijce crontaba oznacza nową linię, więc date +%F trzeba pisać jako date +\%F. Pięć: uprawnienia i inny użytkownik. Naprawa: pełne ścieżki albo PATH na początku skryptu, cd do właściwego folderu i przekierowanie wyjścia do logu, żeby widzieć błędy.

Skrypt testowy, który używa shellcheck z /usr/local/bin:

#!/bin/bash
# raport sieci i jakości skryptów
ip -brief address > raport.txt
shellcheck --version | head -2 >> raport.txt
echo "OK"

A tak podrabiam świat crona: puste środowisko, krótki PATH, inny folder.

env -i HOME=/root LOGNAME=root SHELL=/bin/sh PATH=/usr/bin:/bin /bin/sh -c 'cd /root && /opt/skrypty/raport.sh'

/opt/skrypty/raport.sh: line 4: shellcheck: command not found
OK

I teraz uwaga, bo są tu trzy lekcje naraz. Raz: „command not found”, bo /usr/local/bin nie ma w PATH. Dwa: skrypt i tak wypisał „OK” i skończył się kodem 0, bo nie ma set -euo pipefail. Cron niczego nie zauważy. Trzy: plik raport.txt wylądował w /root, a przy ręcznym uruchomieniu w folderze, w którym stałem. Dwa pliki, dwie wersje prawdy.

Poprawiony początek skryptu:

#!/bin/bash
set -euo pipefail
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
cd "$(dirname "$0")"

I w crontabie wyjście do logu:

*/15 * * * * /opt/skrypty/raport.sh >> /var/log/raport.log 2>&1

Czego rekruter naprawdę szuka: PATH jako przyczyna numer jeden, % jako bonus i nawyk logowania wyjścia z crona.

Zła odpowiedź: „Cron jest zepsuty, przestawiłbym to na systemd timer.” Timery systemd są świetne, ale mają dokładnie ten sam problem z innym środowiskiem. Zmiana budzika nie pomoże, jeśli śpisz w innym mieszkaniu.

Scenariusz 6: „Strona nie działa, ale port 443 odpowiada”

Odpowiedź na głos: Skoro port odpowiada, sieć i zapora są w porządku, problem jest wyżej: w aplikacji, w konfiguracji serwera WWW, w certyfikacie albo w tym, co jest za nim, czyli w bazie. Używam curl -v, żeby zobaczyć kod odpowiedzi HTTP i nagłówki. Kod 5xx to błąd serwera, więc logi błędów serwera WWW i aplikacji. 4xx to problem z żądaniem albo uprawnieniami, czyli 404 brak pliku, 403 brak dostępu, często przez uprawnienia albo SELinux. Błąd certyfikatu sprawdzam przez openssl s_client.

Postawiłem mały serwer WWW ze stroną sklepu:

nc -zv 127.0.0.1 18090
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:18090/
curl -sv http://127.0.0.1:18090/koszyk 2>&1 | grep -E '^[<>] (GET|HTTP)'

Connection to 127.0.0.1 18090 port [tcp/*] succeeded!
200
> GET /koszyk HTTP/1.1
< HTTP/1.0 404 File not found

Port działa, strona główna daje 200, a koszyk 404. Sieć zrobiła swoje. Teraz to rozmowa z aplikacją, nie z zaporą.

Czego rekruter naprawdę szuka: że odróżniasz warstwę sieci od warstwy aplikacji i znasz grupy kodów HTTP.

Zła odpowiedź: „Sprawdzę zaporę.” Zapora właśnie wpuściła Twoje połączenie. Ona swoje zrobiła. Daj jej spokój.

Scenariusz 7: „Każda komenda mówi command not found. Co się stało?”

Odpowiedź na głos: Prawie na pewno ktoś zepsuł zmienną PATH, na przykład przez PATH=/moj/folder zamiast PATH=/moj/folder:$PATH w .bashrc albo .profile. Komendy dalej istnieją, Bash po prostu nie wie, gdzie szukać. Ratunek: uruchamiam programy pełną ścieżką, /usr/bin/ls, naprawiam PATH w bieżącej sesji, a potem szukam winnej linijki w plikach startowych.

PATH=/nic
ls
/usr/bin/ls -d /etc
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ls -d /etc

bash: line 1: ls: command not found
/etc
/etc

Czego rekruter naprawdę szuka: „PATH” w pierwszym zdaniu i pełnej ścieżki jako ratunku.

Zła odpowiedź: „Ktoś usunął wszystkie programy, reinstaluję system.” Dwie godziny reinstalacji zamiast jednej linijki. Szef będzie pod wrażeniem. Innym niż byś chciał.

Scenariusz 8: „Co się dzieje od chwili, gdy wpisujesz komendę i naciskasz Enter?”

Odpowiedź na głos: Bash czyta linię i dzieli ją na słowa. Potem robi rozwinięcia: nawiasy klamrowe, tyldę, zmienne, podstawienia komend, arytmetykę, dzielenie na słowa i gwiazdki, na końcu usuwa cudzysłowy. Ustawia przekierowania. Potem szuka, czym jest pierwsze słowo, w kolejności: alias, słowo kluczowe, funkcja, komenda wbudowana, na przykład cd, a na końcu program w folderach z PATH, z pamięcią podręczną, którą pokazuje hash. Komendę wbudowaną wykonuje sam. Dla zewnętrznego programu robi fork, czyli kopię siebie, w kopii wywołuje execve, które zamienia kopię w nowy program, a sam czeka przez wait na kod wyjścia. Kod ląduje w $? i Bash pokazuje nowy znak zachęty.

alias ls='ls --color=auto'
type -a ls
type cd
hash
strace -f -e trace=execve bash -c 'ls / > /dev/null; echo koniec'

ls is aliased to `ls --color=auto'
ls is /usr/bin/ls
ls is /bin/ls
cd is a shell builtin
hits	command
   1	/usr/bin/ls
execve("/usr/bin/bash", ["bash", "-c", "ls / > /dev/null; echo koniec"], ...) = 0
strace: Process 25758 attached
[pid 25758] execve("/usr/bin/ls", ["ls", "/"], ...) = 0
[pid 25758] +++ exited with 0 +++
koniec
+++ exited with 0 +++

Zobacz, co pokazał strace. Dla ls jest nowy proces i execve("/usr/bin/ls"). Dla echo koniec nie ma nic, bo echo to komenda wbudowana, Bash zrobił to sam, bez wołania nikogo. I zabawne: type -a znalazł ls dwa razy, w /usr/bin i w /bin, bo /bin to dziś tylko drogowskaz do /usr/bin, pamiętasz z lekcji 8.

Czego rekruter naprawdę szuka: słów „rozwinięcia”, „PATH”, „fork i exec”, „kod wyjścia”. Jeśli dodasz, czemu cd musi być wbudowane (bo zewnętrzny program zmieniłby katalog tylko sobie, a nie Twojej powłoce), masz punkt ekstra.

Zła odpowiedź: „Komputer wykonuje komendę.” Prawda. Tak jak „kuchnia robi obiad”. A rekruter pyta o kucharzy.

Scenariusz 9: „Co robi :(){ :|:& };: ?”

Bomba fork. Pokazuję ją tylko na ekranie, nie uruchamiam. Ty też nie uruchamiaj, nawet „tylko na chwilę”.

:(){ :|:& };: z podpisami pod każdym kawałkiem

Odpowiedź na głos: To funkcja Basha o nazwie dwukropek. :() definiuje funkcję, w klamrach jest jej treść: :|:&, czyli wywołaj siebie, przekaż wynik rurą do drugiego wywołania siebie i całość puść w tle. Średnik kończy definicję, a ostatni dwukropek ją uruchamia. Każde wywołanie tworzy dwa nowe procesy, te tworzą kolejne, liczba rośnie wykładniczo, aż skończy się limit procesów albo pamięć. System przestaje odpowiadać, bo nie da się uruchomić nawet kill. Ochrona: limit liczby procesów na użytkownika, czyli nproc w limits.conf albo ulimit -u, i limit zadań w systemd, TasksMax, który działa przez kontroler pids w cgroups. Jeśli bomba już wybuchła, często najszybszy ratunek to restart. Ważniejsze jest to, żeby limity były ustawione wcześniej.

ulimit -u
systemctl show user-1000.slice -p TasksMax

32022

ulimit -u to maksymalna liczba procesów dla mnie. Na Ubuntu 24.04 systemd domyślnie daje też każdemu użytkownikowi TasksMax=33% w jego wycinku, więc jeden użytkownik nie zje wszystkich numerów procesów. Sprawdź to systemctl show na swojej maszynie wirtualnej.

Czego rekruter naprawdę szuka: wyjaśnienia składni kawałek po kawałku i ochrony: ulimit -u, limits.conf, TasksMax.

Zła odpowiedź: „Nie wiem, odpalę i zobaczę.” Na serwerze firmowym. Na rozmowie. To byłaby najkrótsza kariera admina w historii.

Pytanie 10: „Opowiedz o awarii, którą naprawiłeś”

To pytanie pada prawie zawsze i junior często myśli, że nie ma co opowiedzieć. Masz. Każde „zepsuj i napraw” z tego kursu to historia.

Jak budować odpowiedź: metoda STAR, cztery kroki.

• Sytuacja: „Na mojej maszynie wirtualnej z Apache strona przestała działać po zmianie konfiguracji.”
• Zadanie: „Miałem ją przywrócić i dowiedzieć się, czemu padła.”
• Akcja: „Sprawdziłem systemctl status, w journalctl -u był błąd składni w linijce 12, apachectl configtest to potwierdził, poprawiłem literówkę.”
• Rezultat: „Strona wróciła, a od tamtej pory przed każdym restartem robię configtest, a konfigurację trzymam w Gicie.”

Nie musi to być awaria w banku. Ważne, żeby była prawdziwa i żebyś umiał odpowiedzieć na dopytanie. Rekruter zawsze dopytuje.

Czego rekruter naprawdę szuka: metody i ostatniego zdania: co zmieniłeś, żeby to się nie powtórzyło.

Zła odpowiedź: zmyślona historia o wielkim centrum danych. Drugie dopytanie i cała konstrukcja się sypie, jak domek z kart w przeciągu.

Pytanie 11: Kiedy nie znasz odpowiedzi

Prędzej czy później padnie pytanie, na które nie znasz odpowiedzi. I to dobrze, bo rekruter właśnie tego szukał: granicy Twojej wiedzy.

Odpowiedź na głos, wzór: „Nie wiem tego na pewno. Strzelałbym, że chodzi o…, bo…. A sprawdziłbym to tak: zajrzałbym do man, do dokumentacji dystrybucji i przetestował na maszynie wirtualnej.”

Trzy elementy: uczciwe „nie wiem”, rozumowanie na głos, plan sprawdzenia. To brzmi lepiej niż pewna siebie błędna odpowiedź. Admin, który zgaduje z pewną miną, jest groźniejszy od admina, który mówi „sprawdzę”.

Zła odpowiedź: cisza przez trzydzieści sekund. Albo pewne siebie bzdury. Rekruter i tak wie.

Jak to działa pod spodem

Wszystkie dzisiejsze scenariusze sprowadzają się do kilku rzeczy, które już znasz, tylko widzianych z boku.

• Wolny serwer to zawsze kolejka do jednego z czterech zasobów: procesora (us, sy), dysku (wa, %util), pamięci (si, so) albo sieci. Narzędzia tylko pokazują, gdzie stoi kolejka.
• Pełny dysk to brak bloków albo brak i-węzłów, a czasem bloki zajęte przez plik, który ma zero nazw, ale wciąż otwartego czytelnika.
• Logowanie przechodzi przez kilka bramek: konto w /etc/passwd, hasło i jego ważność w /etc/shadow, PAM z blokadą po nieudanych próbach, powłoka na końcu. Każda bramka może powiedzieć „nie” i każda zostawia ślad w logu.
• Cron to budzik, który uruchamia program w pustym pokoju, z krótkim PATH i bez Twoich ustawień.
• Każda komenda to rozwinięcia, szukanie, fork, execve, wait. A bomba fork to ta sama maszyneria, tylko puszczona w nieskończoność bez hamulca.

Jak widzisz, rekruter nie pyta o nic nowego. Pyta o to samo, tylko od strony awarii. Dlatego cały kurs był zbudowany tak, żebyś najpierw psuł, a potem naprawiał.

Ściąga flag