СПАСИБО СИСАДМИНУ! 

Системный администратор часто заметен только, когда что-то сломалось. Но за каждым “упавшим продом” всегда есть рассказ про админов, которые ценой бессонной ночи и крепких нервов спасали данные, бизнес, а порой и людей! В честь Дня системного администратора мы публикуем сокращенные версии самых ярких историй о сисадминах, присланные в редакцию. Полные тексты историй - ищите в сдвоенном номере журнала "Системный администратор» №07-08, 2026, который выйдет в августе.

Как пинг спас жизнь в МГУ

«Это было в начале 2000-х, когда я учился в МГУ. В Главном здании на Воробьёвых горах студенты построили неофициальную сеть более чем на 500 устройств. Провода тянули по внешнему фасаду из комнаты в комнату, а небольшие неуправляемые коммутаторы лежали на подоконниках. Точной схемы сети не существовало: никто не знал всей топологии и не мог уверенно сказать, куда ведёт тот или иной кабель.

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

Поэтому посреди ночи сначала разбудили админа форума, который «вычислил IP-адрес», с которого девушка написала сообщение. Затем начался поиск по сети. На центральном коммутаторе перебором нашли нужный порт, проследили кабель до одной из комнат и разбудили живших там студентов. В комнате обнаружился следующий коммутатор — и всё повторилось: снова перебор портов, снова кабель, уходящий в темноту по фасаду, снова следующая комната. Иногда ребятам приходилось вылезать из окна, чтобы понять, куда он ведёт.

Через несколько часов цепочка привела к двери, которую никто не открывал. Дверь выломали, девушку нашли и на одеяле отнесли к медикам. Её успели спасти. Повезло, что компьютер всё это время был в сети и отвечал на пинги.

Позже в моей работе было много бессонных ночей: отказывали самые надёжные СХД в мире, сгорали дата-центры. Но ту ночь, когда админы с риском для жизни вылезали из окна, чтобы разглядеть в темноте, куда идёт кабель, я не забуду никогда. Беспорядочная студенческая сеть, у которой не было даже нормальной схемы, помогла найти и спасти человека».

Иван Кормачев, ныне гендиректор компании

Сисадмин держит бизнес над пропастью

«Расскажу про один случай из тех времен, когда сам еще был сисадмином. Ночью, часа в два, позвонил директор - упал основной сервер баз данных, предприятие встало. Приехал через двадцать минут, ситуация неприятная: RAID-массив посыпался, один из дисков умер, второй трещал. Резервная копия была, но последняя - за предыдущий день.

Три часа работы, холодный чай, пара крепких слов в адрес конкретного вендора жестких дисков - и всё поднялось. Потеряли данные примерно за четыре часа работы, но это было несравнимо лучше, чем полный крах. Вот тогда директор сказал: "Спасибо" так, что запомнилось. Хотя это было просто слово. Когда случается что-то похожее, каждый раз понимаешь: сисадмин не просто "чинит принтеры", он порой буквально держит бизнес за шиворот над пропастью».

Алексей Оносов, компания «Юнисофт»

Бордовый от стыда SMART

«Вспоминаю случай более чем десятилетней давности. Мы с другом и коллегой пришли работать в новую компанию — с небольшим багажом опыта, но с огромным желанием стать классными админами. Так уж получилось, что предыдущие сисадмины уволились, и дела нужно было срочно принимать без какого-либо сопровождения. Прошлые админы проработали много лет и, видимо, совсем уже не заморачивались по поводу инфраструктуры и её состояния.

Из мониторинга был только Nagios, который оказался практически пустым. Поэтому параллельно с изучением инфраструктуры мы решили поставить всё, что можно, на мониторинг Zabbix. И тут понеслось... В RAID-массивах — выпавшие диски, в блейд-шасси — отказавшие вентиляторы, на куче рабочих станций —бордовый от стыда SMART... И это только по железу!

Помимо этого, мы нашли дыры в файрволлах, отсутствие резервных копий большинства сервисов и, самое страшное, баз 1С. А падение баз и последующее «нападение» бухгалтерии там пережить бы не смог никто.

Срочно подбивали всю информацию в таблицу, согласовывали необходимые закупки с руководством и латали, латали, латали. И это, без сомнения, «героический кейс». Потому что, когда проблемы со всех сторон копятся годами, они обязательно начинают выстреливать каскадом, а это может привести к полному параличу всей компании!»

Глеб, Senior Devops-инженер AIOps-платформы

Как мы не «зависли» в пандемии

Самый интересный кейс, который точно спас компанию от больших проблем — это история с коронавирусом. Все сотрудники тогда работали в офисе, и вся инфраструктура была рассчитана именно на это. Когда появился запрет выходить из дома, компания теоретически могла вообще остановить деятельность.

Мы с айтишниками сделали единый совместный звонок и придумали достаточно элегантную схему удалённого доступа сотрудников к своим рабочим компьютерам. В итоге примерно 250 человек за два, максимум три рабочих дня мы полностью перевели на удалённую работу. Сотрудники подключались из дома к компьютерам в офисе, телефонию перенастроили на домашние номера. Мы не остановили работу компании, а для клиентов всё прошло практически прозрачно, многие сильно удивлялись, когда узнавали, что наш сотрудник сидит дома.

Евгений Мезенцев, Бридж Групп

Переехали быстро и без потерь

Одна из самых сложных задач, за которые брался наш ИТ-отдел — это полный переезд серверов компании без остановки работы сотрудников. Инфраструктура компании: домен Active Directory, файловый сервер, терминальные серверы под удалённую работу сотрудников, виртуализация на Hyper-V, плюс дополнительные сервисы для проектировщиков — в частности, Revit Server.

Задача была: перенести всё быстро и без потерь для пользователей. Спланировали каждый шаг заранее — сделали всё с нуля, протестировали, перенесли Hyper-V, настроили домен, файловый сервер, терминальный доступ и REvit Server. Сделали бэкапы всего.

Все работы проводили после 18-00, чтобы не отрывать сотрудников. В итоге переехали без болезненных потерь и с минимальным простоем сотрудников.

Александр Косачев, ИТ-директор

Админы работали без перерыва 30 часов, чтобы отбить DDoS- атаку

Однажды на нашу сетевую инфраструктуру началась мощная DDoS атака. Часть сервисов была доступна из интернета, и полностью закрыть к ним внешний доступ мы не могли. Компания должна была продолжать работать. Это происходило в то время, когда сервисы проксирования и фильтрации трафика еще не были настолько распространены. Сейчас при подобных атаках первым делом вспоминают про внешнюю защиту от DDoS, а тогда многие отбивались своими силами. Мы тоже сначала пытались справиться самостоятельно.

Нам повезло, что примерно за полгода до этого мы полностью обновили межсетевые экраны. Они работали в отказоустойчивом кластере. Сама схема работала правильно, но даже новое оборудование не было рассчитано на такой объем вредоносного трафика. Файрволлы держались, но нагрузка продолжала расти.

Просто отключить внешний доступ мы не могли, поэтому пришлось искать более гибкое решение. Именно тогда мы впервые по-настоящему познакомились с серьезным проксированием и очисткой трафика. Нам помогла одна известная в России лаборатория. Трафик удалось перенаправить через их инфраструктуру, отфильтровать основную часть атаки и заметно разгрузить наши файрволлы.

Казалось, что ситуация начинает выравниваться, но затем мы обнаружили, что одна из системных учетных записей была скомпрометирована. Кто-то достаточно хорошо знал нашу инфраструктуру, а сама атака была подготовлена заранее. Здесь нам помог подход, на котором изначально строилась система безопасности компании. Разные рабочие среды были изолированы друг от друга, файловая инфраструктура находилась отдельно, действовали строгие правила разграничения доступа. Серверная инфраструктура тоже была построена с учетом возможных отказов. В обычное время такая архитектура может казаться избыточной. Во время реальной атаки она стала нашим главным преимуществом.

В пересказе все звучит достаточно просто. Проксировали трафик, отключили атакованные серверы, заблокировали учетные записи и переключились на резервную площадку. На практике все это заняло около 30 часов непрерывной работы команды. В итоге компания продолжила работу, критические данные не пострадали, а атакованную часть инфраструктуры удалось полностью изолировать.

Иван Дегтярев, NetCost

Красные алерты тревоги

Это случилось в субботу, глубокой ночью. Телефон превратился в новогоднюю гирлянду, потому что система мониторинга буквально взорвалась красными алертами: один из ключевых серверов в кластере «лег». Произошел критический сбой на уровне ядра, и машина не отвечала даже на ping. На этом сервере находилось 70 виртуальных машин, включая тестовые среды разработчиков и часть боевых сервисов наших клиентов. Восстановление каждой системы вручную означает 8+ часов без работы, а для компании, которая зарабатывает на мониторинге, 8 часов без мониторинга — это репутационная катастрофа.

Через удаленный интерфейс управления мы быстро проверили сервер и выявили, что сбой связан с программной частью. Вместо того, чтобы запускать долгое восстановление, мы переключили нагрузку на резервный узел. Для «виртуалок» это выглядело как короткая пауза, но уже не как смерть. Через 45 минут упавший хост вернулся в строй. Все 70 сервисов даже не заметили переезда, бизнес ничего не потерял, а разработчики узнали об аварии только утром из отчета.

Никита Синюков, Senior DevOps-инженер, НТЦ Веллинк

От редакции: присылайте истории о сисадминах, которые спасают компании и людей, в редакцию на адрес: chief@samag.ru