Runbook عیب‌یابی Linux: CPU، حافظه، دیسک، سرویس و شبکه

مقدمه

در رخداد Production، اجرای تصادفی restart یا حذف log می‌تواند شواهد را از بین ببرد. این runbook تشخیص را از symptom به resource و سپس وابستگی سرویس هدایت می‌کند.

مثال عملی

Nginx کند شده ولی CPU پایین است. تیم ابتدا memory، disk، inode و upstream را بررسی می‌کند؛ فرضیه پیش از تغییر ثبت می‌شود.

پیش‌نیازها

Ubuntu Server 24.04 LTS، Bash 5، systemd؛ package patch را پیش از تغییر با dpkg-query ثبت کنید.

سخت‌افزار و ظرفیت: برای مثال یک VM با ۲ vCPU، ۲ GiB RAM و ۲۰ GiB دیسک؛ این ظرفیت پیشنهادی آزمایشگاه است و sizing سرویس به بار واقعی وابسته است.

نرم‌افزار و دسترسی: coreutils، procps، iproute2، curl؛ دستورات read-only بدون sudo و مشاهده log محافظت‌شده با sudo.

Architecture / Design

Incident → زمان/اثر → CPU/RAM/IO → service log → network/DNS → dependency → تغییر محدود → validation. خروجی‌های timestampدار برای مقایسه قبل و بعد نگهداری شوند.

Installation / Configuration

ابزارها در سیستم موجودند؛ فقط در صورت نبود package از repository همان OS نصب شوند. ابتدا snapshot شواهد read-only بگیرید.

date -u --iso-8601=seconds
uptime
free -h
vmstat 1 5
df -hT
df -i
ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu | head -n 15
systemctl --failed --no-pager
ip -br address
ip route
ss -lnt

Load بالا را نسبت به CPU count و IO wait تفسیر کنید؛ RAM کم در free بدون توجه به available نشانه بحران نیست. df -i پر بودن inode را جدا نشان می‌دهد.

systemctl status nginx --no-pager
sudo journalctl -u nginx --since '15 minutes ago' --no-pager
curl --fail --max-time 5 -I https://example.com
sudo du -xhd1 /var/log

example.com مقصد آزمایش عمومی است؛ در رخداد با endpoint واقعی جایگزین کنید. curl فقط status endpoint مشخص را می‌سنجد. du -x از ورود به filesystemهای دیگر جلوگیری می‌کند ولی روی دیسک پربار همچنان هزینه دارد.

Security Hardening

sudo فقط برای داده محافظت‌شده باشد. خروجی env، config یا process args ممکن است secret داشته باشد. chmod/chown را به مسیر دقیق و مالک واقعی محدود کنید؛ recursive تغییر permission در رخداد راه‌حل عمومی نیست.

Monitoring

Prometheus node_exporter برای CPU، available memory، filesystem و inode؛ Zabbix برای service و reachability. برای ظرفیت، time-to-full از trend مفیدتر از درصد ثابت است. نمودار Grafana باید latency برنامه را کنار resource نشان دهد.

Troubleshooting

df پر ولی du کوچک: فایل حذف‌شده هنوز open است یا mount داده را پوشانده است. اگر lsof نصب است، خروجی زیر PID و اندازه فایل‌های deleted را مشخص می‌کند.

sudo lsof +L1
sudo ss -lntp
ip route get 1.1.1.1
resolvectl status

پس از شناسایی PID، روش reopen log یا reload مستند سرویس را اجرا کنید؛ kill کورکورانه نکنید. سرویس active با endpoint خراب نشان‌دهنده وابستگی یا config برنامه است. permission denied را با namei -l روی مسیر واقعی و policy AppArmor بررسی کنید.

Backup / Recovery

دستورهای تشخیص state جدید ایجاد نمی‌کنند. پیش از تغییر config نسخه مالکیت‌دار آن را حفظ کنید؛ داده برنامه با backup اختصاصی سرویس بازیابی می‌شود. در رخداد disk full، حذف فایل تا بررسی retention و backup انجام نشود.

Best Practices

ثبت زمان، exit code و نتیجه فرضیه در ticket؛ اول read-only و بعد تغییر قابل برگشت. reboot باید تصمیم مبتنی بر شواهد باشد.

نسخه‌های قدیمی و Compatibility

این runbook برای systemd و iproute2 است؛ ifconfig/netstat قدیمی در همه توزیع‌ها نصب نیستند. /proc و ابزارها روی container ممکن است فقط namespace همان container را ببینند.

پرسش‌های متداول

چرا df و du متفاوت‌اند؟

فایل حذف‌شده و باز، mount و محدوده پیمایش می‌توانند اختلاف ایجاد کنند.

آیا load بالا همیشه CPU bottleneck است؟

خیر؛ taskهای منتظر IO نیز می‌توانند load را افزایش دهند.