Troubleshooting jarayoni

Bu modulda ko'rilgan har bir vosita — Linux loglari, dmesg, Loglarni tahlil qilish, Resurslar bo'yicha troubleshooting — muammoni o'zi hal qilmaydi. Har biri savol berish usuli; muammoni haqiqatan hal qiladigan narsa — bu vositalarni aniq metodologiyaga tayanib, to'g'ri tartibda qo'llash. Tajribali administrator bilan yangi boshlovchi o'rtasidagi haqiqiy farq ko'pincha buyruqlarni bilishda emas — tasodifiy urinishlar o'rniga izchil jarayonga amal qilishda. Bu maqola shu jarayonni har qanday turdagi muammoga — xizmat, tarmoq, saqlash yoki ilova muammosiga qo'llash mumkin bo'lgan umumiy shaklda taqdim etadi.

Nega tasodifiy urinishlar ishlamaydi

Muammo paydo bo'lganda eng tabiiy, lekin eng samarasiz munosabat — darhol biror narsani o'zgartirib ko'rish: "balki xizmatni qayta ishga tushirsam yordam berar", "balki serverni qayta yuklasam tuzalar". Bu yondashuvning uchta jiddiy kamchiligi bor:

• muammo tasodifan yo'qolib qolishi mumkin (masalan, qayta yuklash vaqtinchalik xotira oqishini tozalaydi), haqiqiy sabab esa qoladi va keyinroq yana paydo bo'ladi;
• bir vaqtda bir nechta o'zgarish kiritilsa, aslida qaysi biri yordam berganini bilib bo'lmaydi;
• muammo yo'qolgach, u nega umuman yuz berganini hech kim tushuntira olmaydi — bu esa xuddi shu muammoning takrorlanishiga hech qanday to'siq bo'lmaydi.

Tizimli jarayon — tasodifiy urinishlarga qarshi intizom. U nafaqat "to'g'ri" javobni tezroq topish, balki u nega to'g'ri ekanini isbotlash uchun ham kerak.

Besh bosqichli jarayon

flowchart TD
    A["1. Define the problem precisely"] --> B["2. Gather evidence"]
    B --> C["3. Form a hypothesis"]
    C --> D["4. Test with one change"]
    D --> E{"Resolved?"}
    E -->|No| C
    E -->|Yes| F["5. Document"]

1-bosqich: muammoni aniq, tekshirish mumkin bo'lgan shaklda belgilash

"Server sekin" — bu ta’rif emas, taassurot. To'g'ri ta’rif o'lchanadigan va qayta takrorlanadigan bo'lishi kerak:

Aniq ta’rif ikki savolga javob beradi: muammo qachon boshlangan va u qanday o'lchanadi. Ikkalasi ham keyingi har bir bosqichning poydevori.

2-bosqich: dalillar to'plash (gipotezadan oldin)

Bu bosqichning eng muhim qoidasi — hozircha hech narsani o'zgartirmaslik, faqat kuzatish va joriy holatni qayd qilish. Bu modulda ko'rilgan har bir vosita aynan shu bosqichga xizmat qiladi:

journalctl -u backend-demo.service --since "1 hour ago" --no-pager
dmesg -T | tail -n 30
vmstat 2 5
df -h /

Bu buyruqlarning hammasi faqat o'qiydi — ular hech narsani o'zgartirmaydi, faqat joriy holatning lahzalik ko'rinishini oladi. Loglarni tahlil qilish maqolasidagi grep/awk usullari va Resurslar bo'yicha troubleshooting maqolasidagi vmstat/iostat aynan shu dalil to'plash bosqichining vositalari.

3-bosqich: gipoteza tuzish

To'plangan dalillar asosida "menimcha, sabab X" ko'rinishidagi aniq, tekshirish mumkin bo'lgan taxmin tuzing. Yaxshi gipoteza quyidagi shaklda bo'ladi: "Agar sabab X bo'lsa, men Y ni kuzatishim kerak."

Masalan: "Agar sekinlashishga disk I/O to'yinishi sabab bo'layotgan bo'lsa, iostat -x o'sha diskning %util qiymati doimiy ravishda 90% dan yuqori ekanini ko'rsatishi kerak."

Bu shakl muhim, chunki u gipotezani inkor qilish mumkin qiladi — agar %util past chiqsa, gipoteza noto'g'ri va uni quvib yana vaqt sarflamasdan yangisini tuzish kerak.

4-bosqich: bitta o'zgarish bilan sinash

Gipoteza tasdiqlangach, tuzatish qo'llanadi — lekin bir vaqtda faqat bitta o'zgarish. Agar bir vaqtda uchta narsa o'zgartirilsa — konfiguratsiya tahrirlansa, xizmat qayta ishga tushirilsa va server qayta yuklansa — muammo yo'qolsa ham, uni aynan qaysi o'zgarish tuzatganini bilishning imkoni bo'lmaydi. Bu esa o'z navbatida xuddi shu muammo boshqa serverda paydo bo'lganda tuzatishni takrorlashni imkonsiz qiladi.

sudo systemctl restart backend-demo.service
journalctl -u backend-demo.service -f

O'zgarishdan keyin natija darhol 1-bosqichda belgilangan o'sha o'lchanadigan mezon bilan tekshiriladi. Agar gipoteza noto'g'ri bo'lib chiqsa, jarayon 3-bosqichga qaytadi — bu jarayonning muvaffaqiyatsizligi emas, oddiy natija.

5-bosqich: hujjatlashtirish

Muammo hal bo'lgach, bu oxirgi bosqich eng ko'p tashlab ketiladi — lekin aynan u kelajakda vaqtni tejaydi. Qisqa yozuv quyidagilarni o'z ichiga olishi kerak:

• muammo dastlab qanday namoyon bo'lgani (boshlang'ich belgi);
• haqiqiy asl sabab nima bo'lgani;
• u qanday tuzatilgani;
• kelajakda xuddi shu muammoning oldini olish uchun nima qilish mumkinligi — monitoring qo'shish, resursni kengaytirish, konfiguratsiyani tuzatish.

Bu yozuv root cause analysis (RCA) deb ataladigan narsaning asosi. RCA’ning maqsadi aybdorni topish emas — tizimni shu turdagi muammolarga chidamliroq qilish.

Amaliy vaziyat: to'liq jarayon boshidan oxirigacha

1-bosqich. Ta’rif: "backend-demo.service soat 12:00 dan beri har 5 daqiqada qayta ishga tushyapti (Restart=on-failure orqali), garchi curl odatda muvaffaqiyatli javob qaytarsa ham."

2-bosqich. Dalillar:

journalctl -u backend-demo.service --since "12:00" --no-pager | grep -i "main process exited"

Jul 24 12:04:12 systemd[1]: backend-demo.service: Main process exited, code=killed, status=9/KILL
Jul 24 12:09:15 systemd[1]: backend-demo.service: Main process exited, code=killed, status=9/KILL

journalctl -k --since "12:00" --no-pager | grep -i "out of memory"

Jul 24 12:04:11 kernel: Out of memory: Killed process 8891 (python3) total-vm:412000kB, anon-rss:398200kB

3-bosqich. Gipoteza: "Agar sabab OOM killer bo'lsa, shu oraliqda xotira bosimi yuqori bo'lgan bo'lishi kerak."

vmstat 2 5

free past, si/so faol — gipoteza tasdiqlandi. Bu Jarayon xotirasi maqolasida chuqur ko'rilgan OOM mexanizmining aynan shu holatda namoyon bo'lishi.

4-bosqich. Sinov: yo xizmatga xotira cheklovi qo'shiladi (MemoryMax= direktivasi), yo ilovaning o'zidagi xotira oqishi tuzatiladi — ikkalasi birdaniga emas, bittasi tanlanadi va natija alohida kuzatiladi.

5-bosqich. Hujjatlashtirish: "backend-demo.service xotira oqishi sababli har bir necha daqiqada OOM killer tomonidan o'ldirilgan. Vaqtinchalik yengillashtirish: Restart=on-failure allaqachon avtomatik tiklanishni ta’minlaydi. Doimiy tuzatish: ilova kodidagi oqishni patch qilish, keyingi haftaga rejalashtirilgan."

Keng tarqalgan xatolar

Dalil to'plamasdan gipoteza tuzish

Tekshirmasdan "bunga odatda X sabab bo'ladi" degan fikrga asoslanib to'g'ridan-to'g'ri tuzatishga o'tish ko'pincha noto'g'ri iz bo'ylab vaqt yo'qotishga olib keladi. Har doim avval kamida bitta dalil — log, resurs holatining lahzalik ko'rinishi — to'plang.

Bir vaqtda bir nechta narsani o'zgartirish

Konfiguratsiya, kod va resurs cheklovini bir vaqtda tahrirlab, keyin "ishladi" deb e’lon qilish qaysi o'zgarish haqiqiy tuzatish bo'lganini aniqlash imkonini qoldirmaydi.

Muammo yo'qolgandan keyin hujjatlashtirmaslik

Qayta yuklash yoki qayta ishga tushirish muammoni "yo'qotishi" mumkin, lekin uning asosidagi sabab qoladi. Hujjatlashtirilmasdan hal qilingan muammo ko'pincha haftalar yoki oylar o'tib, xuddi shu shaklda qayta paydo bo'ladi.

Mashqlar

1. O'tgan haftada duch kelgan texnik muammoingizni tanlang (yoki o'ylab toping) va uni yuqoridagi jadvaldagidek ham "yomon ta’rif", ham "yaxshi ta’rif" uslubida yozing.
2. Yuqoridagi amaliy vaziyatni o'z so'zlaringiz bilan bosqichma-bosqich qayta hikoya qiling — har bir bosqichda qaysi vosita ishlatilganini va nega aynan shu tartibda ekanini tushuntiring.
3. Sinov VM’ida unit’ni ataylab buzing (masalan, O'z systemd xizmatini yaratish maqolasida ko'rsatilgandek noto'g'ri ExecStart= bilan), barcha besh bosqichdan o'ting va oxirida qisqa hujjat yozing.
4. Aniq misol yordamida "bitta o'zgarish, bitta sinov" tamoyilini buzib, ikkita o'zgarishni birdaniga kiritish nega xavfli ekanini tushuntiring.

Mashqni bajardim deyish uchun: 3-mashqdagi 5-bosqich yozuvingiz asl sababni shunchalik aniq ifodalashi kerakki, faqat shu hujjatni o'qigan boshqa administrator tekshiruvingizni noldan takrorlamasdan tuzatishingizni qayta bajara olsin.

Sohaga xos troubleshooting bilan umumiy jihatlar

Yuqoridagi besh bosqichli jarayon ataylab umumiy qilingan — u muammo xizmatda, resursda, saqlashda yoki tarmoqda ekaniga bog'liq emas. Kursning boshqa joylarida ko'riladigan sohaga xos usullar, masalan Tarmoq diagnostikasi va Disk to'lganda troubleshooting, 2–4-bosqichlar uchun dalil to'plash va gipotezani sinash tafsilotlarini taqdim etadi. Umumiy tuzilish esa — ta’riflash, to'plash, gipoteza tuzish, bitta o'zgarishni sinash, hujjatlashtirish — muammo qaysi sohada bo'lishidan qat’i nazar o'zgarmaydi.

Manbalar

• Google SRE Book: Effective Troubleshooting: https://sre.google/sre-book/effective-troubleshooting/
• Red Hat: Root Cause Analysis asoslari: https://www.redhat.com/sysadmin/root-cause-analysis
• man7.org: journalctl(1): https://man7.org/linux/man-pages/man1/journalctl.1.html