Сървърът не работи: какво да проверите първо и в какъв ред

Това ръководство е за самия сървър: VPS, dedicated или облачен сървър, който стопанисвате. Ако се е повредил отделен сайт, а всичко останало на машината работи, или сайтът Ви е на споделен хостинг, започнете вместо това с ръководството Сайтът не работи: какво да правите. Тук разглеждаме машината: отговаря ли изобщо, можете ли да влезете и какво е спряло.

Стъпка 1: какво точно не работи?

„Сървърът не работи“ може да означава три много различни неща и всяко има своя поправка. Първо разберете отвън, от мрежа, която не е Ваша. За сайтове на сървъра проверката дали сайтът не работи Ви казва за секунди дали името се разрешава, дали портът отговаря и какъв код на състоянието се връща. За машината ползвайте ping и тест на портове от Вашия собствен компютър:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Четете резултатите заедно:

• Няма ping, няма SSH, няма уеб порт: машината е изключена, замръзнала или мрежата пред нея не работи. Преминете към стъпка 2.
• Ping отговаря, SSH не: машината работи, но SSH е блокиран, спрян или сървърът е твърде претоварен, за да отговори. Преминете към стъпка 3.
• SSH работи, сайтът не: сървърът е наред, една услуга не е. Преминете към стъпка 4.

Някои сървъри нарочно пускат ping. Ако ping никога не е работил, разчитайте на тестовете на портове.

Стъпка 2: нищо не отговаря

Преди всичко друго отворете контролния панел или облачната конзола на доставчика си. Три въпроса уреждат повечето случаи за минута:

1. Работи ли сървърът? Спряна инстанция, спрян акаунт или неуспешно плащане изглеждат отвън точно като срив.
2. Има ли известен инцидент? Проверете статус страницата на доставчика за Вашия регион или център за данни.
3. Какво показва конзолата? Уеб или серийната конзола показва екрана на машината дори без мрежа. Kernel panic, „Out of memory: Killed process“ в цикъл или зареждане, заседнало на проверка на файловата система, всяко от тях Ви показва къде е проблемът.

Ако машината е замръзнала, рестарт от конзолата обикновено я връща. Преди да рестартирате, направете екранна снимка на конзолата: щом се рестартира, доказателствата изчезват. Ако не се зарежда, повечето доставчици предлагат rescue система, от която можете да монтирате диска, да прочетете логовете и да поправите /etc/fstab или повредена мрежова конфигурация.

Стъпка 3: ping отговаря, SSH не

Машината е жива, така че причината е на нея. Влезте през конзолата, после проверете обичайните заподозрени:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Правило на защитната стена, добавено набързо, Вашият собствен IP адрес, блокиран след няколко грешни паролата, или промяна в конфигурацията на SSH, която не е минала теста, са най-честите ключалки. Отблокирайте адреса си с sudo fail2ban-client set sshd unbanip YOUR_IP и винаги изпълнявайте sudo sshd -t, преди да рестартирате SSH. Ако SSH работи, но е просто много бавен, сървърът е претоварен: преминете към стъпка 4.

Стъпка 4: влезли сте, сега прочетете четири числа

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Натоварване (uptime): далеч над броя на ядрата на процесора означава, че машината е претоварена. top или htop показва кой процес е отговорен.
• Памет (free -m): няма свободна памет и няма swap, плюс „Killed process“ в dmesg, означава, че ядрото е спряло процес, за да оцелее. Обикновено това е била базата данни или PHP.
• Диск (df -h): пълният диск е най-честата причина за проблеми със сървъра. Базите данни спират да записват, логовете спират, сесиите се провалят. df -i проверява inode-овете: дискът може да е „пълен“ със свободни гигабайти, ако милиони малки файлове изчерпват всички inode-ове.
• I/O грешки или файлова система само за четене в dmesg: самият диск има проблем. Спрете записа, направете резервно копие, ако още можете, и се свържете с доставчика си.

За да освободите място безопасно, започнете със системния журнал и старите архиви:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Никога не изтривайте файлове на базата данни или на сайта, за да направите място.

Стъпка 5: коя услуга е спряла и защо

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed изброява всяка услуга, спряла с грешка. Журналът на тази услуга назовава причината: порт, който вече се ползва, синтактична грешка в конфигурационен файл, липсващ сертификат, свършило място. Тествайте конфигурацията преди всеки рестарт (nginx -t, apachectl configtest, php-fpm -t), после я стартирайте със sudo systemctl restart SERVICE. Рестарт без теста може да свали услуга, която още е работила наполовина.

Стъпка 6: какво се е променило?

Сривовете имат причини и причината обикновено е последната промяна. Потърсете я:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Автоматични актуализации, ново ядро, което чака рестарт, внедряване, cron задача, която е напълнила диска с резервни копия, изтекъл сертификат или редакция на конфигурация от някой друг: ако един от тези редове съвпада с часа, в който е започнал сривът, имате следа.

Когато същите проблеми със сървъра се връщат

Сървър, който веднъж е спрял заради пълен диск или спряна база данни, ще го направи отново. Проверката отвън Ви казва кога не работи; проверката отвътре Ви казва преди това. Сървърният агент отчита натоварване, памет, дискове и услуги отвътре на машината и Ви известява, когато диск премине Вашия праг или услуга, която сте отметнали, спре, докато още има време да действате. Мониторингът на сървъри с агента е част от платените планове.

Когато не искате да го правите в 3 през нощта

Ако сървърът Ви не работи и предпочитате да бъде поправен, вместо да го дебъгвате сами, Quick Fix се справя с честите причини на фиксирана цена: рестартира спряла услуга, след като тестът на конфигурацията е успешен, освобождава пълен диск и подновява изтекъл сертификат, първо с резервно копие. Когато това не стига, Deep Fix поема денонощно, таксуван на блокове от 15 минути, с цена, показана преди да поръчате. И двата работят през Responder, SSH като root или SSH достъп до Вашето уеб пространство. Подробности на страницата поправка на сървър и спешна поддръжка.