Tarkibga o'tish

Lab: aralash troubleshooting stsenariylari

Bu moduldagi har bir lab bitta sohani ajratib ko'rib chiqdi — ruxsatlar, foydalanuvchilar, xizmatlar, log'lar, tarmoq, SSH, cron, disk joyi. Haqiqiy hodisa ham, haqiqiy LFCS uslubidagi imtihon vazifasi ham kamdan-kam hollarda qaysi sohaga tegishli ekanini e’lon qiladi. Belgi shunchaki "ilova buzilgan" bo'ladi va birinchi vazifa — umuman qayerdan qidirishni boshlashni aniqlash. Bu yakunlovchi lab xuddi shunday farqlanmagan shakldagi beshta mustaqil, o'zi to'liq stsenariyni taqdim etadi. Ularning har biri faqat sohaga xos intuitsiya bilan emas, tashkil etuvchi usul sifatida besh bosqichli troubleshooting jarayoni yordamida hal qilinadi: muammoni aniq belgilash, dalillar to'plash, gipoteza tuzish, bitta o'zgarishni sinash va hujjatlashtirish.

Nimalarni mashq qilasiz

  • biror aniq vositaga murojaat qilishdan oldin noaniq belgi aslida qaysi sohaga tegishli ekanini to'g'ri aniqlash;
  • sohadan qat’i nazar bir xil besh bosqichli jarayonni qo'llash;
  • birinchi gipoteza noto'g'ri bo'lganda bir vaqtning o'zida bir nechta narsani o'zgartirish istagiga qarshi turish;
  • oldin ko'rilgan, tashqi tomondan o'xshash muammoga shablon bo'yicha moslashtirish o'rniga, gipoteza tuzishdan oldin har bir stsenariyning dalillarini to'liq o'qish.

Bu labdan qanday foydalanish kerak

Har bir stsenariy uchun belgi va dastlabki dalillar foydalanuvchi yoki monitoring tizimi xabar qilganidek aynan berilgan. Diagnostika bo'limini o'qishdan oldin o'z gipotezangizni va uni sinash uchun ishga tushiradigan yagona keyingi buyruqni yozib qo'ying. Bu muhim: bu labning qiymati yechimni o'qishda emas, noaniqlik sharoitida mulohaza yuritishni mashq qilishda. Har bir stsenariyga uni tuzata oladigan yagona odam siz bo'lgandek yondashing.

1-stsenariy: "Sayt vaqti-vaqti bilan 502 xatosini qaytaradi"

Belgi. Foydalanuvchilar sayt ba’zan normal yuklanishini, ba’zan "502 Bad Gateway" ko'rsatishini xabar qilmoqda. Bu doimiy emas — sahifani qayta yuklash ko'pincha muammoni hal qiladi.

Dastlabki dalillar:

curl -s -o /dev/null -w "%{http_code}\n" http://localhost/

502

curl -s -o /dev/null -w "%{http_code}\n" http://localhost/

200

Diagnostika. Reverse proxy’dan (ilova serveri oldidagi nginx) vaqti-vaqti bilan keladigan 502 proxy’ning o'zi ishlayotganini anglatadi — u faol javob beryapti, faqat xato javobi. U so'rovlarni uzatadigan backend esa ishonchli javob bermayapti. Bu har qanday reverse proxy sozlamasi hisobga olishi kerak bo'lgan, proxy qatlami va ilova qatlami bir-biridan mustaqil ishdan chiqishi o'rtasidagi o'sha farq.

sudo journalctl -u nginx --since "10 minutes ago" | grep -i "upstream"

connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://127.0.0.1:3000/"

systemctl status myapp.service

Active: active (running)

Xizmat ishlayotganini ko'rsatadi, lekin nginx unga ba’zan ulana olmaydi. Ilova aslida qayta-qayta ishdan chiqib, qayta ishga tushirilayotganini tekshiring — faqat joriy holatni ko'rsatadigan systemctl status buni o'tkazib yuborishi mumkin:

journalctl -u myapp.service --since "10 minutes ago" | grep -c "Started myapp.service"

14

O'n daqiqada o'n to'rt marta qayta ishga tushish ilova crash-loop’da ekanini tasdiqlaydi. nginx’ning 502 xatosi so'rov kelgan paytda faqat vaqti-vaqti bilan ishlab turadigan upstream xizmatning quyi oqimdagi belgisi.

Asl sabab va tuzatish. Bu stsenariy ilovaning o'z ishdan chiqish log'ini o'qish bilan davom etardi (journalctl -u myapp.service -n 50, tabiiy keyingi qadam). Bu yerdagi saboq e’tiborni proxy qatlamidan ilova qatlamiga to'g'ri yo'naltirish bilan tugaydi. Bu bosim ostida eng ko'p o'tkazib yuboriladigan qadam, chunki 502 xatosi ko'rinib turgan holda nginx’dan keladi.

2-stsenariy: "SSH orqali kira olaman, lekin sudo to'satdan hamma uchun ishlamay qoldi"

Belgi. Umumiy serverdagi har bir foydalanuvchi hamkasbi "bugun ertalab eski sudoers qoidalarini tozaladim" deganidan so'ng darhol sudo endi ruxsatlarga oid xato bilan muvaffaqiyatsiz tugayotganini xabar qilmoqda.

Dastlabki dalillar:

sudo whoami

sudo: /etc/sudoers.d/10-admins is owned by uid 1001, should be 0

Diagnostika. Bu xabar diqqat bilan o'qilganda g'ayrioddiy darajada aniq va o'zini o'zi tushuntiradi. sudo root bo'lmagan foydalanuvchining o'z imtiyoz qoidalarini o'zgartira olishiga qarshi himoya sifatida, root’ga tegishli bo'lmagan /etc/sudoers.d/ ostidagi har qanday faylni inobatga olishdan bosh tortadi. Hamkasbning "tozalashi" deyarli aniq faylni visudo -f o'rniga root bo'lmagan foydalanuvchi sifatida oddiy matn muharriri bilan tahrirlash yoki uning egaligini o'zgartiradigan tarzda nusxalashni o'z ichiga olgan.

ls -l /etc/sudoers.d/10-admins

-rw-r--r-- 1 colleague colleague 156 Jul 29 09:15 /etc/sudoers.d/10-admins

Tuzatish. Hozir sudo ning o'zidan hech kim foydalana olmagani uchun bu SSH konfiguratsiya labi davomida tilga olingan konsol/root zaxira kirishini talab qiladi. Root sessiyasidan:

chown root:root /etc/sudoers.d/10-admins
chmod 0440 /etc/sudoers.d/10-admins
visudo -c

Tekshirish:

sudo whoami

root

Saboq. Bu stsenariy aynan sudo xavfsizligi maqolasidagi faqat visudo orqali tahrirlash haqidagi ogohlantirishni mustahkamlash uchun mavjud. U shuningdek, sudo ning o'zi hamma uchun buzilganda tuzatish sudo dan mustaqil imtiyoz yo'lini talab qilishini ko'rsatadi. SSH konfiguratsiya labi da ta’kidlanganidek, root konsol kirishini saqlab turish aynan shuning uchun ixtiyoriy emas.

3-stsenariy: "Backup’lar bir hafta davomida jimgina muvaffaqiyatsiz bo'lib kelgan"

Belgi. Rejalashtirilgan backup vazifasi crontab -l da ko'rinadi, hech kim hech qanday xato xabarnomasi olmagan, lekin backup manzil katalogida sakkiz kundan yangiroq fayl yo'q.

Dastlabki dalillar:

ls -la /backups/ | tail -5

-rw-r--r-- 1 root root 48213932 Jul 21 02:00 backup-2026-07-21.tar.gz

Diagnostika. Xato xabarnomasining yo'qligi xato sodir bo'lmaganini anglatmaydi. cron muhiti va log'lari maqolasida ko'rib chiqilganidek, cron vazifasining chiqishi faqat MAILTO to'g'ri sozlangan va hostda pochta yetkazib berish haqiqatan ishlayotgan bo'lsagina kimgadir yetib boradi. Bu hayratlanarli darajada keng tarqalgan jim bo'shliq: jimgina buzilgan pochta yetkazib berish infratuzilmasi (mahalliy MTA sozlanmagan) cron chiqishini biror narsa noto'g'ri ketgani haqida hech qayerda hech qanday belgisiz tashlab yuboradi.

crontab -l | grep backup

0 2 * * * /usr/local/bin/backup.sh

Umuman chiqish yo'naltirish yo'q. cron automation labi dagi aynan o'sha diagnostika instinktiga amal qilib, birinchi tuzatish — nosozliklarni ko'rinadigan qilish, keyin haqiqiy sababni topish:

sudo bash /usr/local/bin/backup.sh

tar: /data: Cannot open: No such file or directory

Asl sabab. /data ehtimol sakkiz kun oldin mount qilinmay qolgan mount nuqtasi (fstab yozuvi olib tashlangan, tarmoq share’i uzilgan) — bu xronologiyaga aynan mos keladi. Tasdiqlang:

mount | grep /data
findmnt /data

findmnt: /data: not found

Tuzatish. Manbani qayta mount qiling (yoki fstab maqolasiga ko'ra asosiy /etc/fstab yozuvini tuzating), keyin bunday turdagi nosozlik hech qachon yana jim qolmasligi uchun crontab yozuviga chiqishni yozib olishni qo'shing:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Saboq. "Xato haqida xabar berilmadi" va "xato sodir bo'lmadi" — bir xil gap emas. Monitoring bo'shlig'i (yo'q chiqish yozib olish, buzilgan pochta yetkazib berish) haqiqiy nosozlikni ixtiyoriy uzoq vaqt yashirishi mumkin. Darhol muammo uchun tuzatish (/data ni qayta mount qilish) tuzatishning o'z ko'rinuvchanligini ham tuzatmasdan to'liq bo'lmaydi.

4-stsenariy: "Yangi server internetga ulana oladi, lekin ichki ma’lumotlar bazamizga emas"

Belgi. Yangi tayyorlangan ilova serveri tashqi saytlarga curl bilan muvaffaqiyatli ulanadi, lekin xuddi shu xususiy tarmoqdagi ichki ma’lumotlar bazasi serveriga ulanishda vaqti tugaydi.

Dastlabki dalillar:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com

200

psql -h db-internal.local -U app -d appdb

psql: error: connection to server at "db-internal.local" ... timeout expired

Diagnostika. Internetga ulanish mumkinligi asosiy routing va DNS resolve qilish umuman ishlashini tasdiqlaydi — nosozlik bitta ichki manzilga xos. Tarmoq diagnostikasi maqolasidagi qatlamli yondashuvga amal qilib, ma’lumotlar bazasi xizmatining o'zi aybdor deb taxmin qilishdan oldin nomni resolve qilish va ulanish mumkinligini alohida tekshiring:

getent hosts db-internal.local

10.0.4.15       db-internal.local

Nomni resolve qilish muvaffaqiyatli — manzil xato yozilgan yoki eskirgan DNS yozuvi emas, qonuniy ichki manzil.

ping -c 3 10.0.4.15

3 packets transmitted, 3 received, 0% packet loss

Hostning o'ziga tarmoq qatlamida ulanish mumkin — bu routing muammosini chiqarib tashlaydi va gipotezani aynan ma’lumotlar bazasining tinglash portiga toraytiradi.

nc -zv 10.0.4.15 5432

nc: connect to 10.0.4.15 port 5432 (tcp) failed: Connection refused

Asl sabab. Bu Tarmoq troubleshooting labi dagi 2-holat uslubidagi belgi — hostga ulanish mumkin, lekin aniq portga emas. Bu yo ma’lumotlar bazasi o'sha interfeysda tinglamayotganiga, yo ma’lumotlar bazasi hostining o'zidagi firewall qoidasi aynan shu yangi serverning IP’sini bloklayotganiga ishora qiladi (ikkinchisi ehtimolroq, chunki boshqa ilova serverlari, taxminan, muvaffaqiyatli ulanadi). Ma’lumotlar bazasi hostining firewall’ini tekshiring:

# on db-internal.local
sudo ufw status verbose | grep 5432

5432/tcp    ALLOW    10.0.4.10, 10.0.4.11

Yangi ilova serverining IP’si (aytaylik, 10.0.4.20) u tayyorlanganda bu ruxsat ro'yxatiga hech qachon qo'shilmagan.

Tuzatish va tekshirish:

sudo ufw allow from 10.0.4.20 to any port 5432 proto tcp

# back on the application server
nc -zv 10.0.4.15 5432

Connection to 10.0.4.15 5432 port [tcp/postgresql] succeeded!

Saboq. Image yoki IaC shablonidan tayyorlangan yangi server shablonning dasturiy ta’minotini meros qilib oladi, lekin mavjud qo'shni serverga alohida berilgan tarmoq istisnolarini har doim ham meros qilib olmaydi. Bu aynan Infrastructure as Code asoslari maqolasi muhokama qiladigan bo'shliq turi: bittadan serverga qo'lda qo'shilgan firewall qoidalari aynan deklarativ, versiyalar nazorati ostidagi infratuzilma yo'q qilishi kerak bo'lgan siljish.

5-stsenariy: "Log tahlili skripti har safar turli natija beradi"

Belgi. Oxirgi bir soatdagi muvaffaqiyatsiz SSH login urinishlarini sanashi kerak bo'lgan skript har safar ishga tushganda boshqa, go'yo tasodifiy sonni ko'rsatadi, hatto ketma-ket ikki marta, oraliqda (ko'rinishidan) yangi login urinishlarisiz ishga tushirilganda ham.

Dastlabki dalillar:

./count-failed-logins.sh

14

./count-failed-logins.sh

9

Diagnostika. Asosiy ma’lumotlar o'zgarmagan holda chiqishi o'zgaradigan skript odatda ma’lumotlar haqiqatan farq qilishini emas, skriptning vaqt oynasi o'zi ishga tushirishlar orasida siljiyotganini anglatadi. Loglarni tahlil qilish labi dagi vaqt oynalarini aniq bog'lash haqidagi urg'uga amal qiling:

cat count-failed-logins.sh

#!/bin/bash
journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"

Asl sabab. --since "1 hour ago" har safar skript ishga tushgan aniq lahzaga nisbatan yangidan hisoblanadi. Bir necha daqiqa oraliqdagi ikki ishga tushirishning bir soatlik oynalari haqiqatan farq qiladi va ularning har biri chegara yaqinidagi turli muvaffaqiyatsiz login hodisalarini o'z ichiga olishi yoki chiqarib tashlashi mumkin. Bu journalctl dagi xato emas. Bu skript muallifi "oxirgi bir soat"ni qat’iy, taqqoslanadigan oyna deb taxmin qilgani, aslida esa u doimiy siljib turadigan oyna.

Tuzatish — agar takrorlanuvchanlik muhim bo'lsa, oynani aniq bog'lang:

#!/bin/bash
WINDOW_START="$(date -d '1 hour ago' '+%Y-%m-%d %H:%M:%S')"
journalctl -u ssh --since "$WINDOW_START" | grep -c "Failed password"

Bu tuzatish ham faqat oynani aniq va log'ga yoziladigan qiladi. U turli vaqtdagi ikki ishga tushirish bir xil sonni qaytarishini ta’minlamaydi, chunki asosiy hodisalar oqimi ular orasida haqiqatan farq qiladi. Tuzatishning haqiqiy qiymati shundaki, skriptning o'zi log'ga yozgan WINDOW_START endi ikki ishga tushirish nega farq qilishini sir bo'lib qoldirmasdan tushuntirib beradi.

Saboq. Izchil bo'lmagan natijalar beradigan skript albatta buzilgan emas. U muallifi siljib turishini tushunmagan siljuvchi nishonga qarshi aynan unga aytilgan ishni qilayotgan bo'lishi mumkin. Vositaning o'zidan shubhalanishdan oldin buyruqning kirish ma’lumotlari aslida nima ekanini (bu yerda --since resolve qiladigan aniq vaqt oynasi) tasdiqlash — bu kursdagi har bir sohada qayta-qayta foydali bo'ladigan diagnostika instinkti.

Mashqlar: bularni yo'riqnomasiz hal qiling

Quyidagi stsenariylar faqat belgi va dastlabki dalillar sifatida berilgan. Besh bosqichli jarayonni o'zingiz qo'llang va berilgan javob bilan solishtirish o'rniga mashqni tugagan deb hisoblashdan oldin diagnostikangiz to'g'riligini tekshiring.

  1. "Serverda xotira tugadi va ilovamizni o'ldirdi, lekin free -h hozir ko'p bo'sh xotira borligini ko'rsatyapti." Dastlabki dalillar: dmesg | grep -i "out of memory" yigirma daqiqa oldingi, ilovangiz jarayonini nomlagan OOM-killer yozuvini ko'rsatadi. Hozirgi, sog'lom ko'rinadigan free -h chiqishi nega allaqachon sodir bo'lgan va kernel aybdor jarayonni o'ldirib allaqachon hal qilgan haqiqiy OOM hodisasiga zid emasligini diagnostika qiling. Tekshirish: siz journalctl va dmesg vaqt belgilarini birga ishlatib, o'ldirishga sabab bo'lgan aniq jarayon va taxminiy xotira iste’molini ayta olishingiz kerak.
  2. "Oylar davomida ishonchli ishlagan systemd timer vazifasi konfiguratsiyada hech qanday o'zgarishsiz to'satdan ishlashdan to'xtadi." Dastlabki dalillar: systemctl --user list-timers timer’ni faol ko'rsatadi, lekin journalctl --user -u <service> uch kun davomida yangi ishga tushirishlarni ko'rsatmaydi. Aynan foydalanuvchi (tizim emas) timer’lari va sessiya hayot sikli bilan bog'liq eng ehtimoliy sababni diagnostika qiling. Tekshirish: diagnostikangiz tizim darajasidagi (root) timer’da nega bunday nosozlik bo'lmasligini tushuntirishi kerak.
  3. "Ikki administrator har biri o'z ssh_config dagi Host alias’i to'g'ri deb turib oladi, lekin ulardan faqat bittasi ulana oladi." Dastlabki dalillar: ikkala konfiguratsiya ham turli HostName qiymatlari bilan Host db-server ni belgilaydi. SSH konfiguratsiyasi maqolasidagi konfiguratsiya ustuvorligi haqidagi qismga tayanib, qaysi konfiguratsiya fayli aslida kuchga kirishini va nega ekanini diagnostika qiling. Tekshirish: siz ssh -v chiqishidagi aynan qaysi konfiguratsiya fayli va qaysi Host bloki aslida qo'llanilganini ochib beradigan aniq qatorni ko'rsata olishingiz kerak.

Xulosa

Bu labdagi har bir stsenariy, oxir-oqibat qaysi sohaga tegishli bo'lib chiqishidan qat’i nazar, bir xil besh qadam bilan hal qilinishi mumkin edi: muammoning aniq bayoni, gipotezadan oldin to'plangan dalillar, bitta o'zgarish bilan sinalgan bitta gipoteza va hujjatlashtirilgan natija. Aniq vositalar farq qildi — journalctl, ufw, ls -l, nc, dmesg — lekin ularni bog'lab turadigan mulohaza intizomi o'zgarmadi. LFCS uslubidagi vazifa ham, haqiqiy production hodisasi ham aslida yodlangan buyruq sintaksisini emas, aynan shu intizomni tekshiradi.

Manbalar