"Серверные призраки: когда техника ведёт себя странно"⁠⁠

Введение: Когда логи не объясняют аномалии

Каждый сисадмин сталкивался с ситуациями, которые нельзя объяснить рационально. Серверы, которые сами перезагружаются по ночам, свитчи, передающие пакеты с выключенных портов, и жёсткие диски, на которых данные появляются из ниоткуда.

В этой статье мы соберём самые загадочные истории из мира IT, которые не поддаются логике. Возможно, это просто баги. А может, в сети живёт что-то ещё…

Глава 1. "Фантомные процессы" – кто запускает то, чего не должно быть?

1.1. Таинственный PID 666

Один администратор рассказывал, что на его сервере периодически появлялся процесс с PID 666, который исчезал при попытке его убить. В логах не было ни имени, ни владельца – только пустота.

• Теория 1: Это демон (в прямом и переносном смысле), который мониторит систему.

• Теория 2: Артефакт ядра ОС особенно Linux, который проявляется только при определённых условиях.

1.2. Процесс [kworker/0:0], который нагружает CPU на 100%

Многие видели его, но никто не знает, чем он на самом деле занимается.

• Миф: Если попытаться его остановить, система зависнет.

• Реальность: Это часть ядра, но иногда он ведёт себя слишком активно без причины.

Глава 2. "Сеть, которая помнит" – аномалии маршрутизации

2.1. Пакеты с несуществующего IP

Бывали случаи, когда сервер получал SYN-запросы с IP-адресов, которых никогда не существовало в этой подсети.

• Объяснение?
  Ошибка ARP-кэша?
  Кто-то эмулирует трафик?
  Или сеть "помнит" старые адреса?

2.2. Свитч, который передаёт данные без питания

История из форума: после аварийного отключения электричества один свитч продолжал мигать и даже пропускал трафик, хотя был физически отключён от сети.

• Возможные причины:
  Остаточный заряд в конденсаторах?
  Или что-то более странное?

Глава 3. "Жёсткие диски, которые знают слишком много"

3.1. Файлы, которые возвращаются после удаления

Один администратор клялся, что удалил лог-файл, но через неделю он снова был на месте. Проверка fsck не показала ошибок, а inode был новым.

• Мистика или баг?
  Возможно, это работа скрытого бекап-скрипта.
  Или файловая система "помнит" слишком много.

3.2. Диск, который "предсказывает" ошибки

Некоторые HDD начинают сыпать SMART-ошибками за несколько дней до реального падения. Но есть случаи, когда диск выдавал предупреждения, потом работал годами, а в итоге умирал ровно в предсказанный день.

Глава 4. "Сервер, который не хотел умирать"

4.1. Машина, которая загружалась без процессора

На одном форуме описан случай: сервер продолжал работать (с ошибками, но работал!) после того, как из него вынули CPU.

• Как? Возможно:
  Остаточные заряды в кэше.
  Ошибка BMC/IPMI.
  Или сервер никогда не был настоящим…

4.2. Система, которая отвечала после rm -rf /

Один бедолага случайно удалил корень, но сервер продолжал работать. Оказалось, что некоторые процессы остались в памяти, а init не завершился.

• Мораль: Даже после апокалипсиса Linux может держаться.

Заключение: "Вы уверены, что это просто глюк?"

IT-инфраструктура — сложная штука, и иногда она ведёт себя так, как не должна. Но что, если некоторые аномалии — не баги, а особенности?

Совет: Если ваш сервер начинает вести себя странно — сначала проверьте логи. А если их нет… может, лучше не копать глубже?

P.S. Если у вас есть подобные истории — пишите в комментарии. Но помните: иногда техника знает больше, чем нам кажется.