Detaljan, praktičan vodič za rešavanje problema na Linux serveru: kako sastaviti i koristiti runbook

Article Image

Rešavanje problema na Linux serveru: sistematski pristup i runbook za svakodnevne incidente

Ovaj vodič uvodi sistematski pristup rešavanju problema na Linux serveru i pokazuje kako sastaviti i koristiti runbook (operativni priručnik) koji ubrzava dijagnostiku i smanjuje greške pod pritiskom. Namenjen je administratorima, DevOps inženjerima, programerima i studentima koji žele da reše probleme brzo i sigurno — od neuspelih servisa do usporene I/O aktivnosti ili mrežnih problema.

Kako sastaviti runbook: struktura i osnovni elementi

Runbook je dokument sa jasno definisanim koracima koji se prate tokom incidenta. Njegova svrha je da standardizuje odgovore i olakša transfer znanja između timova. Dobar runbook sadrži:

  • Naslov incidenta i kratki opis očekivanog simptoma.
  • Prioritet i kriterijumi za eskalaciju.
  • Lista osnovnih provera (checklist) po prioritetima: usluge, procesi, mreža, disk/I/O.
  • Komande sa primerima, zahtevima (npr. sudo/root) i bezbednosnim upozorenjima.
  • Kontakt listu, lokaciju logova i korake za vraćanje u normalno stanje.

Primer jednostavnog koraka u runbooku:

1) Proveri stanje kritičnog servisa:
sudo systemctl status nginx
# Ako je servis down, pogledaj poslednje logove:
sudo journalctl -u nginx -n 200 --no-pager

Objašnjenje: systemctl status prikazuje stanje servisa; journalctl -u očitava systemd journal za dati unit. Obe komande zahtevaju sudo/root pristup za potpune informacije na većini sistema.

Prioriteti dijagnostike: redosled i ključni alati

Pravilno rangiranje provera štedi vreme. Preporučeni redosled: 1) usluge (da li su servisi aktivni), 2) procesi i opterećenje CPU/memorije, 3) mreža (povezivanje i socketi), 4) disk i I/O (performanse i greške). Za svaku oblast postoje standardni alati:

Usluge i logovi

Obavezni alati: systemctl, journalctl.

# Debian/Ubuntu/CentOS7+ (systemd):
sudo systemctl status apache2       # ili nginx
sudo journalctl -u apache2 -n 200 --no-pager

Šta rade: systemctl upravlja systemd servisima; journalctl čita logove systemd journala. Upozorenje: restartovanje servisa može prekinuti korisničke konekcije — uvek proveriti poslednje logove pre restart-a.

Procesi i resursi

Alati: top/htop, strace (za praćenje syscalls). htop zahteva instalaciju na većini servera.

# Instalacija (Debian/Ubuntu)
sudo apt update && sudo apt install htop sysstat -y

# Pregled procesa i opterećenja
htop
# Dinamička analiza sistema sa strace (oprez: utiče na performanse)
sudo strace -p  -o /path/to/trace.log

Objašnjenje: htop daje interaktivni prikaz procesa; strace beleži sistemske pozive procesa i može pomoći u identifikaciji zaglavljenih I/O ili čekanja. Upozorenje: strace može značajno usporiti proces; ne koristiti masovno u produkciji bez planiranja.

U narednom delu vodiča biće detaljno objašnjeni mrežni alati (ss, tcpdump), I/O alati (iostat, dmesg) i konkretne komande sa primerima za različite distribucije, kao i bezbednosne preporuke pre izvođenja kritičnih operacija.

Mreža: ss, tcpdump i koraci za brzo utvrđivanje problema konekcija

Pored osnovnih provera servisa i procesa, mrežna dijagnostika je sledeći logičan korak — proverite lokalne socket-e, zatim sniff-ujte saobraćaj kada treba potvrditi paketni tok ili odbacivanje konekcija.

Osnovne komande i primeri:

# Brzi pregled svih TCP/UDP socket-a i procesa koji ih drže
sudo ss -tulpen

# Sažetak mrežnog stanja
ss -s

# Prikaži samo uspostavljene konekcije sa timovima vremena čekanja
ss -o state established '( sport = :22 or dport = :22 )'

Šta rade: ss je brži i informativniji zamenski alat za zastareli netstat. Opcije: -t TCP, -u UDP, -l listening, -p proces, -e dodatne info, -n bez DNS obrada.

Kada je potrebno dublje — tcpdump za presretanje paketa:

# Osnovni capture: interfejs eth0, filter samo HTTP, snimi u fajl
sudo tcpdump -i eth0 tcp port 80 -w /tmp/http_capture.pcap

# Filtriraj po hostu i port (smanjuje veličinu capture-a)
sudo tcpdump -i eth0 host 10.0.0.5 and tcp port 443 -w /tmp/host_https.pcap

# Prikaži capture u realnom vremenu (bez binarnog fajla)
sudo tcpdump -i eth0 -n -vvv tcp and port 3306

Objašnjenje i bezbednosne napomene: tcpdump hvata sve pakete na interfejsu — capture može sadržati osetljive podatke (cookie-e, token-e, sadržaj zahteva). Ne snimajte u javne foldere; koristite ograničenja veličine (-C, -W) i brišite fajlove nakon analize. Izvođenje tcpdump-a zahteva root pristup. Na proizvodnim sistemima planirajte prostor na disku i obaveštavajte tim pre dužih capture-a.

Disk i I/O: iostat, dmesg, smartctl — kako prepoznati usko grlo ili greške

Problemi sa diskom često se manifestuju kao visoki iowait, degradirane performanse baze podataka ili kernel greške. Kombinujte alatke za metrike i kernel logove.

# Instalacija (primeri)
# Debian/Ubuntu
sudo apt update && sudo apt install sysstat smartmontools -y

# RHEL/CentOS 7/8
sudo yum install sysstat smartmontools -y   # ili dnf na novijim verzijama

# Pregled I/O metrike u realnom vremenu
iostat -x 1 5   # prikazuje proširene statistike svakih 1s, 5 uzoraka

# Pročitaj kernel poruke vezane za disk
sudo dmesg -T | tail -n 200
# Ako koristite systemd journal:
sudo journalctl -k -n 200 --no-pager

# SMART provera diska (brzi test)
sudo smartctl -a /dev/sda
sudo smartctl -t short /dev/sda

Šta rade: iostat prikazuje util (%util), await, svctm — vrednosti koje pomažu da se utvrdi da li disk ili put (controller) limita performanse. dmesg pokazuje kernel poruke — tražite “I/O error”, “buffer I/O”, ili greške kontrolera. smartctl očitava SMART atribute i pokreće self-testove.

Upozorenja: SMART testovi mogu povećati I/O; pokrenuti kratke testove van režima najviše potrošnje. dmesg izlaz može brzo rotirati — ako imate persistent logging (journal), koristite ga da ne izgubite informacije. Prilikom čitanja i interpretacije %util i iowait, uporedite sa normalnim šablonima sistema (uzmite baseline).

Primer dijagnostičke sekvence i distribucijske napomene

Tipičan tok za “spor web sajt” incident (primer):

  1. Proveri servis: sudo systemctl status nginx, sudo journalctl -u nginx -n 200
  2. Proveri procese: htop ili ps aux --sort=-%cpu | head
  3. Proveri socket-e: sudo ss -tulpen | grep :80
  4. Ako ima konekcija ali kašnjenja: sudo tcpdump -i eth0 host 10.0.0.5 and tcp port 80 -c 200 -w /tmp/trace.pcap
  5. Proveri disk/I/O: iostat -x 1 5 i sudo dmesg -T | tail -n 100

Instalacija alata (kratak rezime):

  • Debian/Ubuntu: apt install tcpdump sysstat smartmontools htop -y
  • RHEL/CentOS: yum/dnf install tcpdump sysstat smartmontools htop -y

Finalna bezbednosna preporuka: uvek dokumentujte svaku naredbu u runbooku, navodite ko ima pravo da pokreće kritične komande (restart, capture), i koristite audit/logging (auditd, centralni log server) da biste zadržali tragove izmena tokom incidenta.

Sigurnosna upozorenja pre kritičnih akcija

Pre nego što izvedete bilo koju kritičnu intervenciju (restart servisa, live tcpdump, strace ili SMART test), imajte u vidu bezbednosne i operativne rizike. Sledeći principi i praktične smernice umanjuju mogućnost pogrešaka i nepredviđenih posledica.

Pristup i privilegije

  • Koristite princip najmanjih privilegija: omogućite sudo samo onima kojima je stvarno potreban pristup za određene komande.
  • Izbegavajte dugotrajne root sesije; kada su neophodne, koristite vremenski ograničene mehanizme (sudo session timeout) i beležite ko je pokrenuo komandu.
  • Pokretanje alata koji presreću ili modifikuju proces (strace, gdb) radiči uticati na stabilnost servisa — primenjujte ih pažljivo i po mogućstvu na replika/standby instancama.

Backup i snapshot pre promena

  • Pre resetovanja, nadogradnje ili izvođenja disk-intensive testova osigurajte aktuelne bekape ili snapshotove za kritične podatke i konfiguracije.
  • SMART i drugi dijagnostički testovi mogu povećati I/O — izvršavajte ih van vršnog opterećenja i obezbedite rezervni kapacitet diska.
  • Za baze podataka obavezno napravite konzistentan dump ili snapshot pre eksperimenata koji menjaju stanje.

Audit i logovanje

  • Koristite auditd i centralizovano logovanje da zadržite sled promena tokom incidenta i olakšate kasniju analizu.
  • Documentujte svaku kritičnu naredbu u runbooku ili incidentnom zapisu: ko je izvršio, kada i zašto.
  • Ograničite snimanje mrežnog saobraćaja na ono što je neophodno; izbegavajte snimke koji sadrže poverljive podatke bez odgovarajuće zaštite.

Planiranje i komunikacija

  • Pre restartovanja servisa ili promena na mrežnim uređajima obavestite pogođene timove i korisnike kad god je to moguće.
  • U runbooku jasno definišite ko ima ovlašćenje za izvođenje kritičnih koraka i kako se vrši eskalacija.
  • Na produkciji izvodite promenе u dogovorenim prozorima održavanja, osim u slučaju hitnih incidenata uz odgovarajuću koordinaciju.

Završne smernice za primenu runbooka i timski rad

Runbook je živi alat — ne samo dokument za krizne situacije. Redovno ga ažurirajte nakon svake izmene infrastrukture, svakog incidenta i svake vežbe. Uspostavite ritam post-incidentnih pregleda bez traženja krivice, fokusiranih na učenje i poboljšanje procesa.

  • Vežbajte runbook kroz simulative incidente (chaos testing, tabletop exercises) kako bi tim bio brz i uigran kada se problem zaista pojavi.
  • Verzionisanje runbooka (git) i jasni zapisi o promenama omogućavaju brzo vraćanje na poznatu dobru konfiguraciju i trasiranje odgovornosti.
  • Automatizujte ponovljive, sigurnosno proverene korake pomoću skripti ili alata za orkestraciju — ali ostavite jasne manualne prekidače i rollback procedure.
  • Investirajte u monitoring i alerting koji se integrišu sa runbookom: jasni, relevantni alarmi smanjuju „noise“ i usmeravaju pažnju na prave korake.
  • Održavajte kulturu transparentnosti i dokumentovanja: beležite šta je rađeno i zašto, kako bi se sutra greške lakše ispravile i izbegle ponovne intervencije.

Dosledna primena ovih smernica povećaće brzinu i sigurnost rešavanja incidenata, smanjiće sekundarne posledice i učiniti tim otpornijim na neočekivane kvarove.

By Linux