Страшные истории дата-центров. Реальные, к сожалению.
Бывает, в самую тёмную ночь в серверной случается нечто, от чего кровь стынет в жилах даже у бывалых. Это не призраки и не демоны — куда страшнее.
Это непроверенные бэкапы, пароли «на минуточку» и мониторинг, который молчит. Потому что никакая тыква не спасёт, если самый жуткий монстр в стойке — это человеческое «авось».
Это непроверенные бэкапы, пароли «на минуточку» и мониторинг, который молчит. Потому что никакая тыква не спасёт, если самый жуткий монстр в стойке — это человеческое «авось».
💀 История 1: Король паролей
«Это было не в нашем дата-центре, но эта легенда кочует из уст в уста, как предупреждение».
Один админ поднимал тестовый сервер для нового микросервиса. Чтобы не морочиться, выставил для рута пароль root/root. Мысль была проста: «Щас быстренько всё подниму, а потом сменю».
Сервис прижился, пошла нагрузка, «тест» незаметно стал «продом». Месяц всё летало, инцидентов — ноль. Пока однажды в четыре утра графики не упёрлись в потолок.
В логах — нечитаемая каша из команд, входы с подозрительных IP и одинокий readme.txt в корневой директории. Внутри было лаконично:
Thanks for the minecraft server, bro.
Thanks for the minecraft server, bro.
Утром проект лег. На восстановление из последнего рабочего бекапа ушла неделя. А пароль root/root навсегда прописался в корпоративных ЧС рядом со словами «и так сойдёт» и «работает же».
⚡ История 2: Тихий ужас мониторинга
«Эта история — о том, как тишина может быть оглушительной».
В одном ЦОДе решили «почистить» систему алертов — убрали часть уведомлений по температуре, чтобы ночные смены не дергались из-за ложных срабатываний. Логика железная: кондеи исправны, питание дублировано, всё под контролем.
Так было до той ночи, когда один из чиллеров тихо скончался от глюка в контроллере. Температура в серверном зале поползла вверх — медленно, по градусу в час.
На дашбордах всё ещё было зелёным, а письмо с алертом CRITICAL: Temperature threshold exceeded ушло... на общий ящик support@company.com, который ночью не проверял никто.
К утру стойки были горячими, как гриль. Десяток SSD отправились в лучший из миров, а в логах десятков машин красовалась одна и та же зловещая запись:
kernel: CPU package thermal throttle initiated
kernel: CPU package thermal throttle initiated
С тех пор в той компании правило простое: «Ложный алерт — это не повод его выключить, а повод его починить». И теперь каждый раз, когда мониторинг молчит дольше пяти минут, у инженеров начинается лёгкая паника.
⚙️ История 3: Звенящая тишина
«Самая страшная история — не та, где всё взрывается, а та, где всё замирает».
Ранним утром, в плановое тех.окно, проводили рутинный тест АВР (Автоматического Ввода Резерва). Всё по регламенту: щёлк — переключились на город, щёлк — вернулись на ДГУ.
По крайней мере, так должно было быть. Один неверный щелчок рубильника — и вместо теста дежурный электрик снял питание со всего зала. Гул кондиционеров и вентиляторов сменился оглушительной тишиной.
ИБП дружно подхватили нагрузку, но их хватало на 15 минут — ровно до запуска дизель-генераторов. ДГУ должны были завестись автоматически.
Они не завелись.
Они не завелись.
Пока команда в панике искала причину, ИБП начинали пищать всё настойчивее, а вольтметры показывали просадку. И только тогда, в предсмертной агонии систем, выяснилось: топливо в баках ДГУ было на нуле. Его слили на прошлых учениях и... забыли заправить.
Ровно через 12 минут последний ИБП издал предсмертный «бип» — и в зале воцарилась абсолютная, звенящая тишина. Ни света, ни гула, только тиканье часов на руке у охранника и тяжёлое дыхание дежурного инженера.
Питание вернули через 40 минут. Но для тех, кто был внутри, эти минуты показались вечностью. Теперь в регламенте этой компании первые два пункта:
- Перед любым тестом ДГУ — лично посмотреть и пощупать щупом уровень топлива.
- После любого теста ДГУ — повторить пункт 1.
🌋 История 4: «Тест, который стал реальностью»
Команда разработки готовила новый функционал к Чёрной Пятнице. Решили провести стресс-тест на продакшн-среде (логика «так точнее же!»), предварительно сняв все лимиты и ограничения, чтобы «увидеть реальный потолок».
В 2:00 ночи запустили скрипт, имитирующий пиковую нагрузку. Нагрузка пошла. Графики упёрлись в потолок. А потом... не остановились. Из-за бага в логике скрипт начал рекурсивно создавать запросы, превратившись в самогенерирующуюся DDoS-атаку изнутри.
Через 3 минуты легла не только тестируемая служба, а всё, что было в одной VLAN — от баз данных до сервиса авторизации. Остановить это можно было только физическим отключением серверов. Команда 40 минут в панике искала, какой же именно сервер является источником хаоса, пока не прибегли к «лечению» — отрубили всю стойку.
Мораль: Никогда не играйте с живым продом. У нагрузочного теста должна быть аварийная кнопка, которая бьёт по рукам.
Да, эти истории пугают. Но только до тех пор, пока у вас нет чётких регламентов, надёжного мониторинга и дата-центра, где о таких сценариях думают заранее.
Кстати, в нашем дата-центре ESTT всё под контролем:
- Бэкапы, из которых действительно можно восстановиться;
- Мониторинг, который кричит туда, куда нужно;
- Тесты, которые не превращаются в кошмар;
- И топливо в ДГУ, которое всегда на уровне.
Приходите к нам — и вам будут не страшны никакие хоррор-сторики. 👻
С наступающим Хэллоуином! 🎃
Пусть ваши системы будут стабильнее, чем пульс сисадмина при виде CRITICAL в 3:00 ночи.
Пусть ваши системы будут стабильнее, чем пульс сисадмина при виде CRITICAL в 3:00 ночи.
P.S. Объединяет все эти истории одно: призраки не шалят в серверных стойках. Там обитают куда более страшные сущности — недосмотр, самоуверенность и тихая надежда на "авось". Пусть ваши логи будут чисты, а мониторинг — бдителен!
31.10.2025