Server o'chib yonsa nima tirik qoladi? Reboot'ga chidamlilik auditi

Bu mavzuga meni hayotning o'zi olib kelgan. Yaqinda serverlarimdan biriga reboot berildi — reja asosida, o'z qo'lim bilan. Saytlar qaytdi, systemd ostidagi botlar qaytdi. Bittasi esa jim qoldi: yillar oldin nohup bilan ishga tushirilgan bot faqat kimdir qo'lda yoqib qo'yishini kutib yotardi. Bu voqeani Aladdin seriyasida aytib bergan edim. O'shanda men uchun asosiy savol boshqacha bo'lib qoldi: serverda yana nimalar faqat qo'lda ishga tushirilgan-u, buni hech kim bilmaydi?

Gap shundaki, reboot vaqtini har doim ham siz tanlamaysiz. Kernel'dagi jiddiy zaiflik yangilanish talab qiladi, provayder uskuna almashtiradi, elektr yoki xotira muammosi serverni o'zi o'chirib yuboradi. Shunday paytda "nima o'zi qaytadi, nima qaytmaydi" degan savolga javob tayyor bo'lishi kerak — va bu javobni olishning yagona ishonchli yo'li audit.

Audit: to'rt savol#

1. Xizmatlar ro'yxati to'liqmi?#

Hozir ishlab turgan xizmatlar bilan reboot'dan keyin qaytadiganlari — ikki xil ro'yxat. Ularni solishtiramiz:

# hozir ishlab turganlar:
systemctl list-units --type=service --state=running --no-pager

# reboot'dan keyin qaytadiganlar:
systemctl list-unit-files --type=service --state=enabled --no-pager

Birinchi ro'yxatda bor-u ikkinchisida yo'q xizmat — xavf ostidagi nomzod. Har muhim xizmatni bittalab ham so'rash mumkin:

systemctl is-enabled mysite-web nginx postgresql db-backup.timer
# hammasi "enabled" qaytarishi kerak

Mening o'sha voqeamdagi bot esa bu ro'yxatlarning ikkalasida ham yo'q edi — u umuman systemd'dan tashqarida yashardi. Shuning uchun auditga bitta qadam qo'shiladi: systemd bilmaydigan jarayonlarni qidirish:

# uzoq yashayotgan, lekin unit'siz python/node jarayonlari shubhali:
ps -eo pid,etime,comm,args --sort=-etime | grep -vE "systemd|\[" | head -20

Ro'yxatda nohup yoki screen ichida yillab yurgan jarayon chiqsa — uni xizmatga aylantirish vaqti kelgan.

2. fstab yodida bormi?#

Diskka ulangan hamma narsa — swap, qo'shimcha disk, tashqi papka — mount buyrug'i bilan qo'lda ulangan bo'lsa, reboot'da yo'qoladi. Doimiy bo'lishi uchun /etc/fstabda yozuvi turishi kerak:

swapon --show          # swap hozir bor
grep swap /etc/fstab   # ...lekin bu qatorsiz reboot'dan keyin bo'lmaydi

1-qismda swap yaratganda fstab'ga yozgan edik — mana o'sha qatorning haqiqiy sababi.

3. Firewall va sertifikatlar-chi?#

Yaxshi yangilik: ufw qoidalari o'zi doimiy, alohida saqlash shart emas. Certbot'ning yangilanish timer'i ham enabled bo'lsa qaytadi. Lekin tekshirib qo'yish bir qatordan:

sudo ufw status | head -5
systemctl is-enabled certbot.timer db-backup.timer

4. Xizmatlar to'g'ri TARTIBDA qaytadimi?#

Hammasi enabled bo'lishi hali yetarli emas — bog'liqliklar ham to'g'ri bo'lishi kerak. Ilova bazadan oldin ko'tarilsa, birinchi urinishda yiqilib, restart bilan tiklanadi; bu ishlaydi, lekin loglarni har reboot'da bitta soxta xato bilan ifloslaydi. 2-qismdagi After= va Requires= qatorlari aynan shu tartibni kafolatlaydi — auditda ularni ham bir ko'zdan kechiring.

Mashq: rejali reboot#

Audit qog'ozda to'g'ri chiqishi mumkin, lekin haqiqiy javobni faqat amaliyot beradi. Shuning uchun tizimni sozlab bo'lgach — va keyin ham yiliga bir-ikki marta — rejali reboot qiling. Farqi shundaki, siz unga tayyor holda, kunduz kuni, checklist bilan kirasiz:

sudo reboot
# ... bir daqiqa kutamiz, keyin:
ssh deploy@SERVER_IP

systemctl --failed                 # bo'sh bo'lishi kerak
systemctl is-system-running        # "running" — hammasi joyida degani
curl -Is https://mysite.uz | head -1   # sayt tashqaridan ham javob beradi
free -h                            # swap qaytdi

systemctl --failed bo'sh chiqsa va sayt ochilsa — server o'chib-yonishga tayyor. Endi kutilmagan reboot ham kutilgan stsenariy bo'ladi.

Bonus: server qayta yonganini o'zi aytsin#

Kutilmagan reboot baribir bo'ladi, va u haqda serverning o'zi xabar bergani yaxshi. Buning uchun bitta mitti xizmat yetadi — u har yonishda Telegram'ga xabar yuboradi:

# /etc/systemd/system/boot-notify.service
[Unit]
Description=Reboot haqida adminga xabar
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/opt/mysite/.env
ExecStart=/usr/bin/curl -s -X POST \
    "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    -d chat_id=${ADMIN_CHAT_ID} \
    -d text="Server qayta ishga tushdi"

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload && sudo systemctl enable boot-notify

Endi server qachon o'chib yonmasin, telefoningizga xabar keladi — va siz buni mijozdan emas, serverning o'zidan birinchi bo'lib eshitasiz.

Yakun#

Reboot'ga chidamlilik alohida texnologiya emas, oldingi qismlarda qurilgan intizomning sinovi: xizmatlar systemd'da va enabled, disklar fstab'da, bog'liqliklar unit'larda, zaxira timer'da. Audit shularning hammasini bir aylanib chiqadi, rejali reboot esa qog'ozdagi javobni amalda tasdiqlaydi. Va server o'zi haqida o'zi xabar beradigan bo'lsa, kutilmagan hodisa ham boshqariladigan hodisaga aylanadi.

Keyingi qismda deploy'ning o'zini avtomatlashtiramiz: GitHub Actions bilan CI/CD — push qildingiz, testlar o'tdi, server o'zi yangilandi.