۱۸. راهنمای سریع رخدادها¶

این فصل درخت تصمیم و چک‌لیست اولیه است؛ نسخهٔ گام‌به‌گام و کامل‌تر هر سناریو در راهنماهای عملیاتی زیرساخت آمده است. پیش از تغییرات مخرب، شواهد را ثبت و تأثیر سرویس را بسنجید.

قواعد طلایی رخداد¶

آرام و مرحله‌ای. کاربر ناراحت است، ولی عجله بیشترین خرابی را می‌سازد.
اول شواهد: scripts/incident-snapshot.sh را اجرا کنید (فقط‌خواندنی؛ خروجی در /var/tmp).
محدودهٔ اثر: کدام سرویس/کاربر/میزبان؟ از کِی؟ بعد از چه تغییری؟
کم‌خطرترین اقدام برای بازگرداندن سرویس (rollback، failover، آزادکردن فضا) پیش از «ریشه‌یابی کامل».
یک تغییر در هر زمان، با ثبت ساعت و دلیل.
تأیید از دید کاربر، نه فقط «فرمان بدون خطا بود».
ارتباط: وضعیت را مرتب به ذی‌نفعان بگویید؛ سکوت از خود خرابی بدتر است.
پس از رخداد: گزارش (قالب templates/INCIDENT-TEMPLATE.md).

شدت	تعریف نمونه	واکنش
S1	قطع کامل سرویس حیاتی / نفوذ فعال	فوری، همهٔ دست‌ها، ارتباط هر ۱۵–۳۰ دقیقه
S2	افت شدید یا بخشی از کاربران	فوری، مسئول مشخص
S3	کندی/خطای محدود، راه‌حل موقت دارد	ساعات کاری
S4	هشدار/ریسک آینده	تیکت

جمع‌آوری سریع شواهد¶

sudo ./scripts/incident-snapshot.sh            # خروجی: /var/tmp/incident-HOST-DATE/ (+ فایل tar.gz)
# اگر اسکریپت در دسترس نیست:
date -Is; hostnamectl --static; uptime; free -h; df -hT; df -ih; systemctl --failed --no-pager; ss -s

دیسک پر شده است¶

df -hT
df -ih
sudo du -xhd1 /var 2>/dev/null | sort -h
sudo journalctl --disk-usage
sudo lsof +L1

فایل بزرگ را بدون شناخت مالک و کاربرد حذف نکنید. فایل حذف‌شده‌ای که هنوز توسط پردازش باز است ممکن است در lsof +L1 دیده شود (فضا آزاد نشده). برای لاگ systemd از سیاست vacuum متناسب با نگهداری سازمان استفاده کنید.

اقدام‌های کم‌خطر (به ترتیب):

sudo apt clean                           # یا dnf clean all
sudo journalctl --vacuum-size=500M       # فقط اگر لاگ قدیمی ارزش ممیزی ندارد
docker system df                         # لاگ/ایمیج کانتینرها ([Docker](15-docker.md))
# فایل حذف‌شدهٔ باز: بهتر است سرویس مالک را restart کنید؛ اضطراری:
#   sudo ls -l /proc/PID/fd | grep deleted   سپس   : | sudo tee /proc/PID/fd/N   (محتوا را صفر می‌کند)

سرویس بالا نمی‌آید¶

systemctl status SERVICE
journalctl -u SERVICE -b --no-pager -n 200
systemctl cat SERVICE
sudo ss -lntup
systemd-analyze verify /etc/systemd/system/SERVICE.service

فایل تنظیمات را validate کنید (nginx -t، sshd -t…)، وابستگی‌ها و مجوز فایل‌ها را بررسی کنید و فقط بعد از ثبت لاگ‌ها اقدام به restart کنید. اگر پیام start-limit-hit/repeated too quickly دیدید: علت را رفع کنید، سپس sudo systemctl reset-failed SERVICE. کد status= را در جدول سرویس‌ها ببینید.

سرور کند است¶

uptime
free -h
vmstat 1 5
iostat -xz 1 5
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
df -hT
cat /proc/pressure/{cpu,memory,io}

به‌جای restart فوری، مشخص کنید گلوگاه CPU، حافظه، I/O، شبکه یا خود برنامه است (کارایی).

اتصال شبکه قطع است¶

ip -br a
ip route
ip route get SERVER_IP
getent hosts HOSTNAME
nc -vz SERVER_IP PORT

در دسترسی راه دور، تغییر firewall یا شبکه را بدون مسیر کنسول/rollback انجام ندهید (شبکه).

پورت اشغال است¶

sudo ss -lntup
sudo lsof -i :PORT

سرویس مالک پورت را شناسایی کنید؛ کشتن پردازش به‌صورت کور ممکن است باعث اختلال یا راه‌اندازی مجدد خودکار شود.

کشته شدن پردازش توسط OOM Killer¶

sudo dmesg -T | grep -iE 'out of memory|killed process' | tail
sudo journalctl -k -b | grep -i 'killed process' | tail
free -h
ps -eo pid,comm,rss --sort=-rss | head
systemctl show SERVICE -p MemoryMax -p OOMPolicy

بفهمید چه کسی کشته شد و چه کسی حافظه را خورد (لزوماً یکی نیستند).
نشت حافظه برنامه، حد پایین (cgroup)، یا کمبود واقعی RAM؟ (کارایی)
اقدام موقت: ریستارت سرویس پرمصرف و افزودن swap؛ اقدام دائمی: رفع نشت/افزایش RAM/تنظیم محدودیت.

فایل‌سیستم فقط‌خواندنی شده است¶

findmnt -O ro
sudo dmesg -T | grep -iE 'error|remount|I/O|ext4|xfs' | tail -30
sudo smartctl -H /dev/sdX

معمولاً نشانهٔ خطای دیسک است. اول بکاپ/کپی داده‌های حیاتی؛ بعد ترمیم روی unmount (دیسک). mount -o remount,rw علت را حل نمی‌کند.

سرور بوت نمی‌شود¶

از کنسول (IPMI/ابر):

در GRUB نسخهٔ هستهٔ قبلی را انتخاب کنید (بعد از ارتقای هسته).
اگر به emergency/rescue mode افتاد: journalctl -xb ، systemctl --failed ؛ علت رایج: خط اشتباه /etc/fstab (دیسک نیست) → اصلاح یا nofail.
fsck فقط روی فایل‌سیستم unmount‌شده.
فراموشی رمز root: روش‌های rescue (rd.break / init=/bin/bash) به دسترسی کنسول نیاز دارد و باید طبق سیاست و با ثبت انجام شود.

ساعت اشتباه / NTP¶

timedatectl
chronyc tracking
chronyc sources -v

ساعت اشتباه = گواهی نامعتبر، لاگ بی‌ربط، Kerberos و cron خراب. chronyc makestep (پرش ساعت) روی سرویس‌های حساس به زمان با احتیاط.

پس از رفع رخداد¶

علت ریشه‌ای و اثر کاربر را ثبت کنید.
زمان شروع، کشف، رفع و تأیید را ثبت کنید.
تغییر انجام‌شده و روش rollback را مستند کنید.
اقدام پیشگیرانه، هشدار و مالک پیگیری را مشخص کنید.
هشدار مانیتورینگ جدید برای «دفعهٔ بعد زودتر بفهمیم».

ارجاع به سناریوهای دیگر¶

مشکل	جا
Nginx/وب پاسخ نمی‌دهد، DNS/TLS	Runbook ۱ و ۴
SSH قفل شد	Runbook ۵
دیتابیس پایین است	Runbook ۷
مشکوک به نفوذ	امنیت
بکاپ/بازیابی	پشتیبان‌گیری