چک لیست نگهداری سرور: کارهای روزانه، هفتگی و ماهانه

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

بیشتر چک‌لیست‌های فارسی موجود درباره اتاق سرور هستند: دما، گردوغبار و برق. آن موارد برای سرور فیزیکی لازم‌اند، ولی قطعی‌ها و نفوذها معمولاً از لایه سیستم‌عامل و سرویس‌ها شروع می‌شوند. اگر هنوز مطمئن نیستید سرورتان به نگهداری منظم نیاز دارد، ابتدا نشانه‌های نیاز به مدیریت حرفه‌ای سرور را ببینید؛ نقش فردی که این کارها را انجام می‌دهد هم در مدیر سرور کیست آمده است.

پیش از شروع: چه چیزهایی باید آماده باشد

• سامانه پایش که در دسترس بودن سرویس، CPU، رم، دیسک و گواهی SSL را بررسی کند و هشدار را به یک فرد مشخص بفرستد. اگر ابزار انتخاب نکرده‌اید، مقایسه Zabbix، Prometheus و Nagios را ببینید.
• بکاپ خودکار با گزارش موفقیت یا شکست، و دست‌کم یک نسخه بیرون از خود سرور.
• یک دفترچه نگهداری (فایل مشترک یا سامانه تیکت) که هر بررسی با تاریخ، نتیجه و نام انجام‌دهنده در آن ثبت شود.
• پنجره زمانی توافق‌شده برای به‌روزرسانی و ری‌استارت، که صاحبان سرویس از آن باخبر باشند.

بدون پایش خودکار، بخش روزانه این چک‌لیست به ده دقیقه اتصال دستی به هر سرور تبدیل می‌شود که در روزهای شلوغ انجام نمی‌شود. توضیح مفصل‌تر پایش را در راهنمای مانیتورینگ سرور نوشته‌ایم.

کارهای روزانه نگهداری سرور

هشدارها و سرویس‌های متوقف‌شده

اول داشبورد پایش را ببینید: هشدارهای شب گذشته، سرویس‌هایی که ری‌استارت شده‌اند و میزبان‌هایی که مدتی پاسخ نداده‌اند. هر هشدار باید یا رفع شود یا علت بی‌اهمیت بودنش ثبت شود؛ هشداری که هر روز نادیده گرفته می‌شود، آستانه‌اش اشتباه است. در لینوکس سرویس‌های خطادار و خطاهای لاگ را این‌طور ببینید:

systemctl --failed
journalctl -p err --since yesterday --no-pager | tail -n 50

در ویندوز سرور خطاهای System در ۲۴ ساعت گذشته:

Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2; StartTime=(Get-Date).AddDays(-1)} | Select-Object TimeCreated, ProviderName, Message

نتیجه بکاپ شب گذشته

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

فضای دیسک و inode

پر شدن دیسک رایج‌ترین علت توقف ناگهانی دیتابیس و وب‌سرور است. در لینوکس علاوه بر فضا، inode را هم ببینید؛ هزاران فایل کوچک Session یا Cache می‌توانند inode را تمام کنند درحالی‌که فضای خالی دیسک زیاد است:

df -h
df -i
du -xh / --max-depth=1 2>/dev/null | sort -h | tail -n 10

اگر دیسک سرور رو به پر شدن است و از LVM استفاده می‌کنید، روش بزرگ کردن بدون توقف در افزایش حجم دیسک لینوکس با LVM آمده است.

Get-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining, Size

کارهای هفتگی

وصله‌های امنیتی

فهرست به‌روزرسانی‌های در انتظار را ببینید، از سرور بکاپ یا Snapshot بگیرید و در پنجره زمانی توافق‌شده نصب کنید. بعد از نصب، نیاز به ری‌استارت را بررسی کنید؛ کرنل یا کتابخانه‌ای که وصله شده ولی سرور ری‌استارت نشده، هنوز نسخه آسیب‌پذیر را اجرا می‌کند.

# Ubuntu و Debian
sudo apt update
apt list --upgradable
ls /var/run/reboot-required

# Rocky، AlmaLinux و RHEL
sudo dnf check-update --security
sudo dnf needs-restarting -r

در ویندوز سرور، به‌روزرسانی‌ها از SConfig یا WSUS بررسی و در همان پنجره زمانی نصب می‌شوند. سرور وب یا دیتابیس اصلی را هم‌زمان با سرور پشتیبان آن وصله نکنید.

لاگ ورودهای ناموفق و حساب‌های مشکوک

تعداد تلاش‌های ناموفق SSH یا RDP را با هفته قبل مقایسه کنید. عدد بالا روی سرور متصل به اینترنت عادی است؛ ورود موفق از آدرس یا ساعت غیرعادی عادی نیست. در Ubuntu نام سرویس ssh و در خانواده RHEL معمولاً sshd است:

sudo journalctl -u ssh --since "7 days ago" | grep -c "Failed password"
last -n 20

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-7)} | Measure-Object

اگر ورود با رمز عبور SSH هنوز باز است، بستن آن را در برنامه قرار دهید؛ مراحلش در آموزش SSH Key و اتصال امن به سرور لینوکس آمده است.

انقضای گواهی SSL و سلامت دیسک‌ها

تمدید خودکار گواهی Let’s Encrypt گاهی بی‌صدا شکست می‌خورد. تاریخ انقضا را از بیرون بررسی کنید، و در سرور فیزیکی وضعیت RAID و SMART دیسک‌ها را هم ببینید:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
cat /proc/mdstat
sudo smartctl -H /dev/sda

در سرورهای HPE و Dell، هشدارهای کارت مدیریت (iLO یا iDRAC) خرابی منبع تغذیه، فن یا دیسک را زودتر از سیستم‌عامل نشان می‌دهند؛ ارسال این هشدارها به ایمیل مسئول را فعال کنید.

کارهای ماهانه

تست بازیابی بکاپ

هر ماه یک فایل، یک دیتابیس یا یک ماشین مجازی را در محیط جدا بازیابی کنید و مدت زمان آن را ثبت کنید. این عدد همان زمانی است که در روز بحران لازم دارید. تست را هر بار روی یک بخش متفاوت انجام دهید تا در طول سال همه سرویس‌ها پوشش داده شوند. اگر می‌خواهید وضعیت فعلی بکاپ‌ها را یک کارشناس بیرونی ارزیابی کند، بررسی وضعیت بکاپ سرور و تست بازیابی را ببینید.

بازبینی کاربران، کلیدها و قواعد فایروال

کاربرانی که همکاری‌شان تمام شده، کلیدهای SSH بی‌صاحب و قواعد فایروالی که برای یک کار موقت باز شده بودند را پیدا و حذف کنید:

# کاربران دارای شل ورود
grep -vE "nologin|false" /etc/passwd
# کلیدهای SSH همه کاربران
sudo find / -name authorized_keys -path "*/.ssh/*" 2>/dev/null -exec wc -l {} +
# قواعد فایروال
sudo ufw status numbered
sudo firewall-cmd --list-all

Get-LocalUser | Where-Object Enabled
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly
Get-NetFirewallRule -Enabled True -Direction Inbound | Select-Object DisplayName, Profile

روند مصرف منابع و ظرفیت

نمودار یک ماه CPU، رم، دیسک و ترافیک را با ماه قبل مقایسه کنید. دیسکی که ماهانه چند درصد پر می‌شود، تاریخ پر شدنش قابل محاسبه است و ارتقا را می‌توان پیش از بحران برنامه‌ریزی کرد. استفاده دائمی از Swap یا مصرف رم نزدیک به سقف هم نشانه نیاز به بهینه‌سازی یا منابع بیشتر است.

گزارش ماهانه

خلاصه یک‌صفحه‌ای بنویسید: وصله‌های نصب‌شده، هشدارها و رخدادها با علت، نتیجه تست بازیابی، تغییرات دسترسی و پیشنهادهای ماه بعد. مدیری که این گزارش را می‌خواند، بدون ورود به سرور وضعیت را می‌فهمد.

کارهای فصلی و سالانه

• تست کامل بازیابی بحران: راه‌اندازی یک سرویس کامل از بکاپ روی سرور دیگر، طبق برنامه بکاپ و بازیابی بحران.
• بررسی تاریخ پایان پشتیبانی سیستم‌عامل، PHP، دیتابیس و کنترل‌پنل و برنامه‌ریزی ارتقا.
• تعویض رمز حساب‌های سرویس و کلیدهای API که مدت‌ها ثابت مانده‌اند.
• تمدید دامنه، گواهی‌های غیرخودکار، لایسنس نرم‌افزارها و قرارداد سرور یا دیتاسنتر.
• به‌روزرسانی Firmware سرور فیزیکی، کارت شبکه و کنترلر RAID، و در اتاق سرور بررسی UPS و تهویه.
• مرور تنظیمات امنیتی سرویس‌ها با یک فهرست امن‌سازی سرور و به‌روزرسانی مستندات.

جدول خلاصه چک لیست نگهداری سرور

چه کارهایی را خودکار کنیم و چه کارهایی را نه

جمع‌آوری داده را خودکار کنید: پایش، هشدار پر شدن دیسک، اجرای بکاپ، بررسی انقضای گواهی و گزارش لیست به‌روزرسانی‌ها. نصب خودکار وصله‌های امنیتی با unattended-upgrades در Ubuntu یا dnf-automatic در RHEL برای سرورهای کم‌حساسیت مناسب است، ولی ری‌استارت خودکار سرور دیتابیس اصلی بدون هماهنگی ریسک قطعی دارد.

تست بازیابی، بازبینی دسترسی‌ها، تحلیل علت قطعی و تصمیم درباره ارتقا به قضاوت انسانی نیاز دارند. اگر تیم داخلی زمان این بخش‌ها را ندارد، معمولاً همین کارها اول کنار گذاشته می‌شوند و مشکل‌ها درست در همین نقطه‌ها پیدا می‌شوند.

سوالات متداول

برای یک سرور مجازی کوچک هم این همه کار لازم است؟

بخش سخت‌افزاری و اتاق سرور برای سرور مجازی حذف می‌شود، ولی بکاپ، وصله امنیتی، فضای دیسک و دسترسی‌ها همان‌قدر لازم‌اند. با پایش خودکار، بخش روزانه برای یک سرور چند دقیقه طول می‌کشد.

هر چند وقت سرور را ری‌استارت کنیم؟

ری‌استارت دوره‌ای بدون دلیل لازم نیست. بعد از وصله‌های کرنل یا Cumulative Update ویندوز که ری‌استارت می‌خواهند، در پنجره زمانی نگهداری ری‌استارت کنید. سروری که برای پایدار ماندن به ری‌استارت منظم نیاز دارد، مشکل حل‌نشده‌ای مثل نشت حافظه دارد.

نتیجه بررسی‌ها را کجا ثبت کنیم؟

جایی که فرد دوم هم به آن دسترسی دارد: سامانه تیکت، ویکی داخلی یا یک صفحه‌گسترده مشترک. هر ردیف تاریخ، سرور، کار، نتیجه و نام انجام‌دهنده داشته باشد.