چک‌لیست پایش سرور ویندوز و لینوکس: هر روز چه چیزی را باید دید

بیشتر خرابی‌های سرور ناگهانی نیستند. دیسکی که امروز پر شد، دو هفته است با نرخ ثابت پر می‌شود؛ گواهی‌ای که امشب منقضی می‌شود، سه ماه پیش تاریخش معلوم بود؛ سرویسی که بعد از ریبوت بالا نیامد، از آپدیت ماه پیش منتظر همین ریبوت بود. فرق تیمی که شب آرام می‌خوابد با تیمی که مدام آتش خاموش می‌کند، معمولاً یک چک‌لیست ساده است که هر روز واقعاً دیده می‌شود.

این چک‌لیست برای سرورهای ویندوز و لینوکس است و برای هر مورد گفته‌ایم چه چیزی را و با چه آستانه‌ای باید دید. در آخر هم یک جدول مقایسه و چند نکته دربارهٔ اینکه هشدار چطور تنظیم شود که تیم از آن خسته نشود.

۱. منابع: CPU، رم، دیسک و شبکه

عدد لحظه‌ای تقریباً بی‌معناست؛ CPU صددرصد برای ده ثانیه هنگام فشرده‌سازی بکاپ طبیعی است. چیزی که مهم است، مقدار پایدار در یک بازه است: مثلاً CPU بالای ۹۰٪ برای ۱۰ دقیقه، یا رم آزاد زیر ۵٪ برای ۱۵ دقیقه. روی ویندوز page file و صف دیسک را هم ببینید؛ روی لینوکس load average را نسبت به تعداد هسته‌ها، و inode را که ممکن است پیش از فضای دیسک تمام شود.

نکتهٔ مهم‌تر، داشتن خط مبنا است. سرور دیتابیسی که همیشه ۸۵٪ رم را مصرف می‌کند احتمالاً سالم است، چون SQL Server عمداً حافظه را نگه می‌دارد؛ ولی سرور وبی که معمولاً ۳۰٪ مصرف داشت و حالا روی ۸۰٪ ثابت مانده، ارزش بررسی دارد. پس تاریخچه را دست‌کم چند هفته نگه دارید تا بتوانید بپرسید «از کِی این‌طور شده؟». آستانه‌ها را هم برای هر نقش سرور جدا تعریف کنید، نه یک عدد برای همه.

# Linux
uptime                      # load average vs. nproc
free -m
df -h ; df -i               # space and inodes
iostat -x 5 3               # disk utilisation and await

# Windows (PowerShell)
Get-Counter 'Processor(_Total)% Processor Time','MemoryAvailable MBytes',
            'PhysicalDisk(_Total)Avg. Disk Queue Length' -SampleInterval 5 -MaxSamples 3

۲. دیسک: پیش‌بینی، نه فقط درصد

هشدار «۹۰٪ پر» روی یک درایو ۴ ترابایتی یعنی هنوز ۴۰۰ گیگابایت جا هست؛ روی یک درایو ۶۰ گیگابایتی یعنی شاید چند ساعت. سؤال درست این است: با نرخ رشد فعلی، کی پر می‌شود؟ رشد هفت تا چهارده روز اخیر هر درایو را بگیرید و روز پر شدن را تخمین بزنید. هر درایوی که کمتر از دو هفته تا پر شدن فاصله دارد، کار این هفته است. در کنار فضا، سلامت فیزیکی دیسک هم مهم است: روی لینوکس smartctl و روی ویندوز وضعیت گزارش‌شدهٔ دیسک‌ها.

۳. آپدیت‌ها و ریبوت معوق

سه عدد را برای هر سرور بدانید: چند آپدیت امنیتی نصب‌نشده دارد، آخرین نصب موفق کِی بوده، و آیا منتظر ریبوت است. سروری که آپدیت را نصب کرده ولی ریبوت نشده، در عمل هنوز آسیب‌پذیر است.

# Debian / Ubuntu
apt list --upgradable 2>/dev/null | grep -i security
[ -f /var/run/reboot-required ] && echo "reboot required"

# RHEL / Rocky
dnf updateinfo list --security
needs-restarting -r

# Windows: pending reboot flags
Test-Path 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto UpdateRebootRequired'
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

۴. آنتی‌ویروس و فایروال

آنتی‌ویروسی که نصب است ولی محافظت بلادرنگش خاموش مانده، یا امضایش دو هفته به‌روز نشده، فقط حس امنیت می‌دهد. روی ویندوز با Get-MpComputerStatus فیلدهای RealTimeProtectionEnabled و AntivirusSignatureLastUpdated را ببینید. وضعیت فایروال هم همین‌طور: پروفایلی که «موقتاً» برای عیب‌یابی خاموش شده، معمولاً ماه‌ها خاموش می‌ماند. روی لینوکس وضعیت ufw، firewalld یا nftables را بررسی کنید.

۵. سرویس‌ها، گواهی‌ها و ساعت

• سرویس‌ها: هر سرویسی که StartType آن Automatic است ولی در حال اجرا نیست، روی ویندوز؛ و هر واحد failed در systemd روی لینوکس. SQL Server یا IIS که بی‌صدا متوقف شده، معمولاً اول از زبان کاربر شنیده می‌شود.
• گواهی‌ها: هر گواهی‌ای که کمتر از ۳۰ روز تا انقضا دارد، هم در مخزن گواهی ویندوز و هم گواهی‌های سایت‌ها و APIها.
• ساعت: اختلاف چند دقیقه‌ای ساعت، احراز هویت Kerberos را می‌شکند، توکن‌ها را نامعتبر می‌کند و ترتیب رویدادها را در لاگ‌ها به هم می‌ریزد.

# Linux
systemctl --failed
timedatectl | grep -i synchronized

# Windows
Get-Service | Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' }
Get-ChildItem Cert:LocalMachineMy | Where-Object NotAfter -lt (Get-Date).AddDays(30)
w32tm /query /status

۶. لاگین ناموفق و تغییرات موجودی

حدس رمز روی RDP و SSH مدام در جریان است. هدف این نیست که هر لاگین ناموفقی را ببینید؛ هدف دیدن رگبار است: مثلاً بیش از ۲۰ تلاش ناموفق در یک دقیقه از یک آی‌پی، یا هر تلاش روی حساب Administrator و root. روی ویندوز Event ID 4625 و روی لینوکس journalctl -u ssh یا /var/log/auth.log منبع این داده‌اند.

موجودی سرور را هم فهرست کنید و تغییراتش را ببینید: نرم‌افزار تازه‌نصب‌شده، سرویس جدید، پورت تازه باز، و هر کسی که به گروه ادمین یا sudo اضافه شد. خیلی از این تغییرات کار همکاران است، ولی همین فهرست است که نصب ناگهانی rclone یا AnyDesk را لو می‌دهد. جزئیات این نشانه‌ها را در نشانه‌های اولیهٔ باج‌افزار روی ویندوز سرور نوشته‌ایم.

ویندوز و لینوکس کنار هم

مورد	ویندوز سرور	لینوکس
منابع	Performance Counters، page file، صف دیسک	load average، free، iostat، inode
آپدیت	Windows Update، کلید RebootRequired	apt / dnf / yum، فایل reboot-required
آنتی‌ویروس	Defender (Get-MpComputerStatus)	ClamAV یا EDR نصب‌شده
فایروال	Get-NetFirewallProfile	ufw، firewalld، nftables
سرویس‌ها	Get-Service، StartType Automatic	systemctl –failed
لاگین ناموفق	Event ID 4625 با آی‌پی مبدأ	auth.log یا journalctl برای sshd
ادمین جدید	Event ID 4732، اعضای Administrators	تغییر گروه sudo یا wheel
سلامت دیسک	وضعیت دیسک فیزیکی	smartctl
ساعت	w32tm	timedatectl، chrony

هشداری که تیم را خسته نکند

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

• هشدار روی وضعیت پایدار، نه جهش لحظه‌ای.
• یک مشکل، یک پیام؛ تا حل نشده دوباره نفرستید و وقتی حل شد خبر دهید.
• شدت را جدی بگیرید: بحرانی پیامک می‌شود، مهم در داشبورد می‌ماند.
• ساعت سکوت شبانه برای غیربحرانی‌ها، و ارجاع به نفر دوم اگر بحرانی تا چند دقیقه تأیید نشد.
• سقف روزانهٔ پیامک، تا یک قانون اشتباه هم هزینه نتراشد و هم کانال را کور نکند.

همین منطق در دیتابیس هم صادق است؛ نمونه‌اش را در پر شدن لاگ ترنزکشن SQL Server ببینید.

به‌جای چک دستی هر روز

اسکریپت‌های بالا برای یک یا دو سرور کافی‌اند. وقتی تعداد سرورها به ده‌ها می‌رسد، یا شما شرکت پشتیبانی هستید و سرور چند مشتری را نگه می‌دارید، چک دستی روزانه دیگر واقع‌بینانه نیست. سرورماگ همین چک‌لیست را با یک سنسور سبک روی ویندوز سرور ۲۰۱۶ به بعد و لینوکس اجرا می‌کند: منابع هر ۱۵ ثانیه با نمودار تا یک سال، آپدیت و ریبوت معوق، آنتی‌ویروس و فایروال، سرویس‌ها و systemd، سلامت دیسک، انقضای گواهی‌ها، ساعت، لاگین ناموفق با آی‌پی مهاجم، و تغییرات موجودی. هشدارها با پیامک و webhook می‌رسند، با ارجاع، ساعت سکوت، یک پیام به‌جای صد پیام و سقف روزانه. سنسور فقط به بیرون وصل می‌شود، پورتی روی سرور باز نمی‌کند و عمداً هیچ دستوری روی سرورها اجرا نمی‌کند. فعلاً فقط سرور پایش می‌شود، نه سوییچ و SNMP. جزئیات در servermug.ir.

پرسش‌های پرتکرار

فاصلهٔ نمونه‌برداری منابع چقدر باشد؟

برای عیب‌یابی، چند ثانیه تا یک دقیقه؛ برای هشدار، میانگین یا وضعیت پایدار در چند دقیقه. نمونه‌برداری خیلی ریز بدون منطق «پایدار بودن» فقط هشدار کاذب می‌سازد.

با کدام مورد شروع کنیم؟

اگر هیچ پایشی ندارید: پیش‌بینی پر شدن دیسک، سرویس‌های متوقف، و رگبار لاگین ناموفق. این سه بیشترین خرابی و نفوذ قابل پیشگیری را پوشش می‌دهند.

پایش سرور جای پایش اپلیکیشن را می‌گیرد؟

نه. سرور سالم ممکن است اپلیکیشنی داشته باشد که خطا می‌دهد. برای خطاهای سمت مرورگر باگ‌ماگ و برای لاگ بک‌اند لاگ‌ماگ مکمل این چک‌لیست‌اند.

جمع‌بندی

هر روز این‌ها را ببینید: منابع پایدار، روز پر شدن دیسک، آپدیت و ریبوت معوق، آنتی‌ویروس و فایروال، سرویس‌ها، گواهی‌های نزدیک به انقضا، ساعت، رگبار لاگین ناموفق و تغییرات موجودی. و هشدار را طوری تنظیم کنید که وقتی پیامک می‌آید، کسی واقعاً بخواندش.