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. Buning uchun ps ga har jarayon qaysi systemd birligida yashayotganini ko'rsatadigan unit ustunini qo'shamiz:

ps -eo pid,etime,unit,args --sort=-etime | grep -E "session-|user@"

Natija taxminan shunday bo'ladi:

    592  412-03:11:45 session-15.scope    python3 /home/deploy/bot/bot.py
    608  230-19:02:10 session-16.scope    SCREEN -dmS bot2 python3 bot2.py
    453       00:05 user@1000.service   /usr/lib/systemd/systemd --user
    725       00:00 session-18.scope    sshd: deploy [priv]
    738       00:00 session-18.scope    ps -eo pid,etime,unit,args --sort=-etime

Nginx, gunicorn yoki postgres kabi systemd boshqaradigan jarayonlarda bu ustunda .service turadi, shuning uchun filtr ularni chiqarmaydi. session-N.scope esa jarayonni kimdir SSH sessiyasidan qo'lda ishga tushirib qoldirganini bildiradi (nohup, screen). ELAPSED ustunidagi 412-03:11:45 — 412 kun degani. user@1000.service qatorlarida systemd --user va (sd-pam) odatiy, lekin ulardan boshqa jarayon ham shubhali: masalan, tmux ichida ishga tushirilgan bot aynan shu yerga tushadi. Pastdagi yangi qatorlar — sizning hozirgi sessiyangiz (sshd, bash, ps), ularga e'tibor bermang.

Ro'yxatda qo'lda yurgan bot yoki skript 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 snap.certbot.renew.timer db-backup.timer

4-qismda certbot'ni snap orqali o'rnatganmiz, shuning uchun timer nomi snap.certbot.renew.timer. apt'dan o'rnatgan bo'lsangiz, uning o'rniga certbot.timer yozing. Nom xato bo'lsa, enabled o'rniga not-found chiqadi.

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; "degraded" — nimadir yiqilgan
curl -Is https://mysite.uz | head -1   # sayt domen orqali javob beradi
free -h                            # swap qaytdi

is-system-running degraded desa, yiqilgan unit'lar aynan systemctl --failed ro'yxatida turadi — sababini sudo journalctl -u <unit nomi> -b bilan o'qing. Server yonishda davom etayotgan bo'lsa, u starting deydi — bir necha soniyadan keyin qayta so'rang. Saytni o'z kompyuteringiz brauzerida ham bir ochib ko'ring.

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. Telegram bot tokeni va xabar boradigan chat ID kerak bo'ladi. Ularni xizmat /opt/mysite/.env dan oladi, shuning uchun u yerda BOT_TOKEN=... va ADMIN_CHAT_ID=... qatorlari bo'lsin. Chat ID'ni bilish uchun botga Telegram'da /start yozing va brauzerda https://api.telegram.org/bot<TOKEN>/getUpdates ni oching: javobdagi "chat":{"id":...} raqami — sizning chat ID'ingiz. /start ni o'tkazib yubormang: siz yozmaguningizcha bot sizga xabar yubora olmaydi. Shu token bilan bot serverda allaqachon ishlab tursa, u xabarlarni o'zi olib ketadi va getUpdates bo'sh "result":[] yoki xato qaytaradi — botni bir daqiqaga to'xtatib, /start ni qayta yozing.

# /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
# -sS: ortiqcha chiqish yo'q, lekin xato bo'lsa jurnalga yozilsin;
# --fail-with-body: Telegram xato qaytarsa (token yoki chat ID noto'g'ri),
# xizmat "muvaffaqiyatli" bo'lib ko'rinmasin
ExecStart=/usr/bin/curl -sS --fail-with-body -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

# reboot'ni kutmasdan hoziroq sinaymiz — telefoningizga xabar kelishi kerak:
sudo systemctl start boot-notify

Xabar kelmasa, sudo journalctl -u boot-notify -n 10 ni oching. Telegram javobi o'sha yerda turadi: "Unauthorized" — token noto'g'ri, "Bad Request: chat not found" — chat ID noto'g'ri yoki botga /start yozilmagan. --fail-with-body bo'lmaganida bu holatlarda ham xizmat "muvaffaqiyatli" tugagan bo'lib ko'rinardi va siz xabar nega kelmayotganini reboot'dan keyingina payqardingiz.

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.