Что ещё делать в пятницу вечером накануне Хеллоуина, как не рассказывать страшные истории?
Эта статья — сборник ситуаций, в которые вы никогда не захотели бы попасть, но они произошли с нашими ребятами. Все имена вымышленные, все сюжеты — реальные. Авторский стиль рассказчиков сохранён.
Выключайте свет, зажигайте свечи. Настало время страшных и местами страшно-забавных историй из жизни айтишников. Бу!
***
На предыдущей работе был разработчик, назовём его Афанасий. Проработал он у нас недолго, но у меня сформировался рефлекс — когда я видел в коде какую-то дичь, то поднимал глаза на CodeLens, и если последним этот код правил Афанасий, то я не задавал лишних вопросов и не стеснялся исправлять/удалять.
Где-то через пару месяцев после работы в другой компании в недрах монолита я увидел какую-то дикую дичь, дикую даже для монолита. Поднял глаза — последним редактировал Афанасий. И фамилия совпала. Сразу появилось неприятное чувство, что меня преследуют.
***
Ситуация, когда на базе развалился диск, но ты не переживаешь, ведь у клиента RAID1. А после часа общения с железячниками выясняется, что они налажали и у них RAID0.
А на другом проекте сисадмин неудачно накатил обновление ОС на сервер БД, после чего откатил всё на точку восстановления на полгода назад. Вместе с данными в БД, конечно же.
***
Предыстория: в базах данных в Azure имена пользователей имеют формат name@server, например writer@prod-tracker или reader@dev-monolith.
Так же там есть багофича — если ты пытаешься подключиться к одному серверу, но с кренделями от пользователя другого сервера, то подключаешься к серверу из имени пользователя. Т.е. если пытаться подключиться к серверу prod-tracker с именем пользователя writer@dev-tracker и правильным паролем, то подключишься ты именно к dev-tracker.
История: как то под вечер были какие-то проблемы на проде, я попытался подключиться к БД трекера и посмотреть, что там творится, перепутал и взял dev-кренделя. Захожу в базу, а там пусто. Вообще пусто. Десять раз перепроверил адрес сервера — всё правильно. Чуть не поседел, пока понял, что не так.
***
(Рассказываю упрощённо, намеренно опуская всю биржевую терминологию и связанные с ней технические детали).
Представьте, что вы — джуниор-разработчик со стажем в полгода. Вы разрабатываете систему, которая торгует на бирже. У системы где-то в глубине есть сложный механизм автопродажи акций — на случай, если они вдруг начнут стоить меньше запланированного (или больше). Этот механизм считывает количество акций из одного места, а заявки на продажу шлёт в другое. Самое страшное, что может произойти — он может взбеситься и начать открывать позиции с огромной скоростью, проедая деньги компании.
А теперь представьте: вечер вторника, к вам подбегает вам риск-менеджер со смертельно бледным лицом и говорит, что там какой-то глюк с цифрами, скорее всего, потому что таких ужасных цифр быть просто не может.
Оказалось, что место, где механизм смотрел за тем, что количество акций должно было уменьшиться, перестало корректно отдавать ответ, и система продолжила нон-стоп закупать акции по всем убыточным позициям, делая их ещё более убыточными. Я поправил, что мог.
Страшный сон
Когда появился первый Raspberry Pi, мы с другом тут же заказали себе парочку из Америки. После того, как получили, несколько дней безвылазно сидели и изучали что можно интересного придумать. Сделали, например, трекер вахтёрши. Поставили камеру в коридоре общаги и когда вахтёрша выходила на этаж, он сигнализировал, что нужно затихнуть. Эта штука спасла от краха не одну вечеринку.
Так вот, на фоне всей этой истории мозг даже во сне думал о Raspberry, и снится мне однажды, как я в этом терминале что-то делаю и вдруг слышу будильник. Понимаю, что пора просыпаться, а для этого нужно ввести логин и пароль. Стандартные pi/raspberry почему-то не подходят, я не могу проснуться. Попытки с десятой получается таки ввести пароль и я просыпаюсь.
У друга был похожий сон: он заснул в двух потоках, после будильника один поток завершился, а второй завис. Чтобы проснуться, пришлось открыть диспетчер задач и убить зависший процесс.
История про сервер-лунатик
Декабрьское утро админа не предвещало ничего плохого. Обычные задачи: зайди на сервер, настрой что-то, зайди на другой сервер и сверь, что там сделано аналогично. И вот зайти на боевой сервер БД почему-то с ходу не получилось.
Первый ввод пароля, второй… Вдумчивый и внимательный ввод пароля. Проверка себя на дурака: а не забыл ли пароль, который у тебя много месяцев на кончиках пальцев? Нет, не забыл. И в чём же тогда проблема?
Ладно, самое время посмотреть, что же пишет консоль. Ага! Пароль, в общем-то, изначально был не при чём, сервер отвечает Connection refused. Проверил в Гугле свои опасения — да, это точно означает, что с одной стороны все пули вылетели, а вот на стороне мишени какие-то проблемы. А узнать, что это за проблемы, можно только подключившись. Круг замкнулся.
Окей, Хьюстон, у нас проблемы. Все возможные решения упираются в то, что к серверу нужен физический доступ, вот только сервер расположен в безымянной стойке в другой стране. К счастью, остался доступ к серверу по виртуальному KVM, но через него можно сделать немного, из полезного — ну разве что перезагрузить. А если у сервера проблемы, и он просто не поднимется после рестарта? А это, на минуточку, основной сервер БД всей информационной системы, и если с ним что-то случится, то ляжет вообще всё.
При этом вот прямо сейчас база в полном порядке, обслуживает запросы, позволяет к себе подключиться, никаких нареканий. Но если что-то пойдёт не так, нельзя будет сделать ничего. Со стороны всё мирно и прекрасно, и только одному админу известно, какая тень нависла над системой.
Несколько дней составлялся план по возвращению контроля над сервером-лунатиком. К счастью, всё это время он вёл себя хорошо и не требовал экстренной реанимации. А через неделю как раз наступал Новый год, и система отключалась на всю праздничную ночь. Этим и решил воспользоваться наш герой.
Пока счастливые люди разливали шампанское по бокалам и садились перед телевизором, один грустный админ, многажды перекрестившись, ребутал сервер, держа наготове план экстренного переезда на случай проблем. Но, к счастью, обошлось. После перезагрузки сервер вышел на связь, а все системы продолжили работать штатно, так что даже бой курантов удалось послушать уже без ноутбука на коленях.
P.S. На разборе полётов решили, что, скорее всего, база резко подросла по потребляемой памяти и сервер, пытаясь высвободить ресурсы, начал прибивать все процессы, попавшиеся под руку, зацепив сервис удалённого доступа.
Никого не наградили и не наказали, всё прошло без последствий для бизнеса, да и победителей не судят. Но неделя бок-о-бок с сервером-зомби до сих пор вспоминается как одна из самых ярких в карьере.
***
И напоследок ещё одна реально страшная история про день, когда Dodo IS остановилась.
Возможно, кому-то эти зарисовки покажутся не страшными, но нас они немного напугали, а местами и повеселили. И теперь ваша очередь — рассказывайте в комментариях свои страшилки.
Комментарии (38)
G3k0S
29.10.2021 17:06+2Что может быть страшнее, чем откат БД на пол года назад :(
yoz
29.10.2021 17:08+1Отсутствие ежедневных бэкапов БД?
tvr
29.10.2021 17:35+7Присутвтвие ежедневных бэкапов из которых ничего не восстанавливается, ибо никто и никогда не проверял их на этот предмет.
Ненуачо, бэкапится? — Бэкапится!yoz
29.10.2021 17:43+5Делать бэкапы это джун. Делать бэкапы и проверять их уже мидл. Делать бэкапы бэкапов и проверять оба — сеньор!
saboteur_kiev
30.10.2021 01:33+2админы делятся на тех, кто не делает бэкапы, тех кто уже делает и тех кто уже делает и проверяет их целостность.
NiGMa4Habr
30.10.2021 21:07Нет, те кто не делает бэкапы -- это "ещё не админы".
saboteur_kiev
30.10.2021 23:21+1Даже у админов со стажем бывают случаи, когда надо что-то поменять на удаленном сервере, или мигрировать данные и из-за простоты операции может не сработать инстинкт бэкапа. Вот недавно в ФБ такое случилось. Там тоже не админы?
NiGMa4Habr
30.10.2021 23:46Вот недавно в ФБ такое случилось. Там тоже не админы?
Там гораздо хуже.
Свои внутренние данные, включая систему контроля доступа, хостить и DNS'ить вместе с пользовательскими базами -- это уже не ошибка и не поспешность. Это, как минимум, вредительство.
lunacyrcus
02.11.2021 06:06Свои внутренние данные, включая систему контроля доступа, хостить и DNS'ить вместе с пользовательскими базами -- это уже не ошибка и не поспешность. Это, как минимум, вредительство.
Может быть в этом есть смысл с точки зрения защиты, проще защищать и админить один объект и использовать для этого одни и те же ресурсы и системы, чем распылять команды на несколько (и вдобавок еще получать дополнительные сложности и риски со взаимодействием между ними).
NiGMa4Habr
02.11.2021 15:49+1Да, в этом чувствуется рука "эффективного менеджера".
Сэкономили на копейку, а ущерб получили на многие миллионы.
Нечто подобное было, например, в аварии на Фукусиме: при проектировании этой АЭС возможную потерю электроснабжения собственных нужд сочли "невероятным событием". А оно случилось и повлекло катастрофически последствия.
ACO-Andrew
29.10.2021 17:34Накатить вчерашний бэкап дазы банных, не? А нету?! Тогда обновляем резюме и вперед! :-)
vlreshet
29.10.2021 17:34+4Несколько лет тому назад. Вечер пятницы. Мой джуниор прям на продакшне правит php файл. Проект достался видимо от индусов, системы контроля версий там не было, сам код — мешанина фронта и бека, классика PHP-фриланса короче. Но нужно было изменить буквально одно int значение, ну и я решил что уж это то можно доверить ему самому, это уж нельзя запороть. Как бы не так. Парень решил что будет хорошей идеей заодно запустить плагин IDE, который поправит форматирование кода. Плагин с задачей справился «на ура» — PHP отформатировал, а всё остальное (html, css, js) минифицировал в одну строчку, сломав всё что можно и нельзя. А джун это каким-то образом не заметил, и сохранился. На проде. Без Git-а. Благо у меня нашёлся бекап за этот день, но осадочек остался)
zuborg
29.10.2021 18:07+1У друга был похожий сон: он заснул в двух потоках, после будильника один поток завершился, а второй завис.
Могу предположить, что второй поток завис потому что первый не освободил мьютекс до того как завершился по SIGALRM.
Aleksandr-JS-Developer
29.10.2021 19:06+1... снится мне однажды, как я в этом терминале что-то делаю и вдруг слышу будильник. Понимаю, что пора просыпаться, а для этого нужно ввести логин и пароль. Стандартные pi/raspberry почему-то не подходят, я не могу проснуться. Попытки с десятой получается таки ввести пароль и я просыпаюсь.
А пароль в диспетчере паролей
Fitrager
29.10.2021 19:31+1История один. Предыдущий админ рулил инфраструктурой и при падении основного контроллера домена восстановил копию из реплики полугодичной давности. Я работал в другом отделе и случайно обнаружил проблему когда сменил пароль и не смог авторизоваться на основном контроллере домена, так как репликация не работала полгода. С ужасом потом восстанавливал все после него и еще около года проблемы вылазили после его действий.
История два. Действие на пару месяцев позже. Два старых сервера. Без RAID, так как гипервизор не поддерживает контроллер, но есть бэкапы. Я уже админ и решаю провести ТО сервера. Мигрировав все с сервера, который я хотел обслужить и внимательно посмотрев на два сервера, (а они отличались внешне) я начинаю вытаскивать диски. Я немного задумался и вытащил диск из работающего сервера. Причем диск, где был гипервизор. Сервер продолжил работать, но начал тормозить. Я в ужасе "что делать?", так как там были достаточно важные ВМ. Воткнул диск обратно и побежал перезагружать сервер. К счастью помогло.
История три. Я только начинаю работать в организации и мне доверили сервера учебного сектора. Один сервер начал работать нестабильно и я решил из дома вечером его перезагрузить. Он перезагрузился, но потерял связь с vcenter. Я в ужасе пытался решить проблему, но ничего не помогало. А там были ВМ с серверами лицензий и с утра могли бы не начаться занятия. Всю ночь маялся и в шесть утра меня осенило, что я могу подключиться напрямую к гипервизору. Подключился, стартанул ВМ и со спокойной душой пошел на работу.
Действия происходили пять-шесть лет назад и сейчас эти истории вызывают улыбку, так как как все проблемы достаточно просто решаются.
TigerClaw
29.10.2021 22:39+21) Пятница полчаса до конца рабочего дня и отпуск. Хостер отрубает почту на рабочем проекте из-за подозрений в спаме. Благо быстро отвечали и удалось все включить назад.
2) Из той же серии. Проект сдан в пятницу и отпуск. Все проверено быстро. Первый день на море и сообщение о баге, который пропустил. А у тебя только планшет и хреновый интернет. Правишь через админку прям в браузере.
3) Взяли проект, который не работал нормально, а их админ гадил ибо не хотел, что бы проект уходил. Да опять пятница и я на свадьбе двоюродного брата. Самопальный кривой обмен с 1с не проходит. Обмен писала другая контора. И клиент выносит мозг, что у него в магазине пропал товар. Мне предлагают даже привести ноут, а я объясняю, что поправить в конфигах PHP что бы обмен все же прошел и что это не наше и код быстро не поправить. Потом меня еще в субботу доставали, но вроде как то обмен прошел. В понедельник я посмотрел чужой говнокод и оптимизировал его. А потом нас послали на три буквы и проект вернулся к старым разработчикам.
baldr
29.10.2021 23:49+3Пишем систему управления деплойментами. Выпустили нас на продакшн. Примерно 4000 серверов обслуживаем.
Внезапно прибегает к нам слегка бледный админ из Operations и, нервно дергая глазом, говорит что он нажал кнопку сохранения плана обычного деплоя, и на его глазах оба кластера продакшена написали что успешно удалены.
Разобрались - в этот момент протухла сессия пользователя и при обновлении страницы через ajax не получили списка серверов. Ну и написали что их нет. Все было цело, но нас чуть не побили.
Прости, Миша.
Latrommy
30.10.2021 01:46+1История, подобная "Сервер-лунатик" случилась у нас 31 декабря 2017 в 23:51. Позвонил управляющий базы отдыха, говорит "У нас отключали электричество. Когда подключили, точки продаж перестали работать". Примерно догадавшись, что произошло, подключаюсь к БД ERP. Holy shi... "Suspect"! Смотрю eventlog. Damn!.. disk, disk, disk... Упал RAID1. Но HDD сервера, куда делались инкрементные бэкапы каждые 2 минуты, выжил. Восстановил БД на том сервере, поставил MSSQL, подцепил БД, запустил ERP. 23:58. Новый Год встретил под бой курантов :)
restlesss
31.10.2021 07:02Поставить MS SQL и восстановить БД менее чем за 7 минут - это круто! Нереально круто, я бы сказал.
third112
30.10.2021 05:48Когда портировал IDE Dr. Pascal с MS DOS на Mac OS 7.0.1, то там была процедура SaveFile, которая, если файл под таким именем уже есть, переименует его заменив расширение .pas на .bak. И запишет новый, вызвав процедуру NewFile. Казалось, что тривиальная задача, но процедуры видимо писали разные люди, и в них был вызов closeFile стандартной функции ОС. Оказалось, что для Mac OS это недопустимо, и двойное закрытие файла может привести к его потере. Шеф из Штатов позвонил мне в Москву и минут 5 кричал. Каждая фраза начиналась с You have to… Потом специально смотрел документацию на ОС — не нашел предупреждения на повторное закрытие файла, только позже где-то прочел о такой распространенной ошибке.
astenix
30.10.2021 06:45+1«Немного напугали»?
От «ты не переживаешь, ведь у клиента RAID1. А после часа общения с железячниками выясняется, что они налажали и у них RAID0» у меня внутрях немного задёргалось.
CodeHolder
30.10.2021 15:59Жизненная ситуация. Недавно случайно обнаружил, что на гипервизоре 0, а не 1. Забыл mirror при создании дописать, а zfs при отсутствии параметров молча стрип делает.
Wesha
01.12.2021 00:57А то, что откуда-то образовалось вдвое больше, чем планировалось — не насторожило?
MaxAhmed
30.10.2021 09:38+2У заказчика сервер под Hpux c софтовым зеркалом, собранным через lvm. А там забавный прикол второй диск включённый в зеркало показывается как не смонтированный. Приходит к заказчику новый админ, начинает разбираться что к чему
- о! диск не смонтированный, сча посмотрим. Хм, не монтируется. Не порядок. Надо его переразметить.
Ну и переразметил…. Бэкап был (с)
Кстати про бекапы. Сдает мне одна уважаемая организация настроенное ПО мониторинга. На сдаче ничего не работает. Мне начинают рассказывать ну это ваши чего-то изменили, мы намедни проверяли - все работало. А доступ к серверу у нас действительно был. Ладно, говорю, вы вроде как позавчера бекап делали - тогда все работало. Радостно кивают. Ну ок говорю, накатывайте. Накатывают и все становиться раком. Вообще все. Начинаем разбираться - добрый человек, который бекап делал, забекапил с опцией сохранять линки как файлы. Потом неделю лазили по системе вручную восстанавливали линки. И что сука характерно мониторинг так и не за работал …
esisl
30.10.2021 13:56О да! Истории с автосделками - это что-то с чем-то.
Однажды в понедельник рано утром на корпоративной автостоянке столкнулись два бентли и мерседес. Потому, что в пятницу запустили робота автоматической докупки недостающего на складе, и за выходные, без человеческого присмотра ЭТО накупило барахла на ярд евро...
К счастью у продавцов в выходные тоже были выходные и сделки не успели подтвердить :)
simplix
30.10.2021 14:13К счастью, остался доступ к серверу по виртуальному KVM, но через него можно сделать немного, из полезного — ну разве что перезагрузить.
KVM обеспечивает полный доступ к серверу через консоль, так можно поставить другую программу удалённого управления и уже с комфортом исправлять неполадки. Если админ заранее не продумал, как он получит доступ к удалённому серверу когда всё сломается, он сам себе буратино.CodeHolder
30.10.2021 16:02Вот да. Прод сервер без физического доступа и без нормального квм это ссзб абсолютное.
f000
30.10.2021 20:15+5а что, никто на проде update без where никогда не делал? )))
Akdmeh
02.11.2021 13:43Делал ALTER TABLE на 10 миллионах записей с блокировкой базы прода на несколько часов. Сделал как-то field = REPLACE(str1, str2, field), т.е., перепутал порядок аргументов в функции MySQL. Это с первого, что вспомнил.
mariner
30.10.2021 22:48+3У нас однажды она коллекция из монги периодически удалялась. Поначалу думали, что баг в коде, пока не отловили в логах сервера следы гуглобота, который индексировал нашу почему-то открытую наружу базу и переходил по ссылке delete, которая удаляла базу по GET запросу. Вроде robomongo был, год эдак 2012.
kvazimoda24
30.10.2021 23:53Как-то включил на пограничном маршрутизаторе Juniper watchdog, и из-за глюка в прошивке он ушёл в вечный ребут. Не помогли ни кластер из двух железок (применил сразу на обеих нодах), ни commit confirm...
Пришлось срочно ехать в ДЦ. Всё лежало около двух часов.
yoz
Я думаю подобных историй у каждого специалиста с разнообразным опытом лет хотя бы в 5 полно.
Помню мне надо было на выходах сортировочной линии организовать рабочие места, по 2 на каждом(тонкий клиент+сетевой принтер), а линию ту сдавали подрядчики и мимо ИТ. Так вот на каждом выходе линии было 2(две) сетевых розетки RJ45. Благо сделаны они были нормальной четырехпарной витой парой. Переделка кросса и обжим огромной коробки патчкордов-гидр(четырехпарка бьется на две двухпарки, через одну розетку можно два порта подключить) заняла уйму времени, аж пальцы болели потом.
gayka_m8 Автор
Да, историй много, но не все их рассказывают. Спасибо, что поделились своей.
Пальцам пришлось нелегко.
yoz
Часто за годы все в кашу смешивается. Хорошо запоминаются только какие-то яркие моменты по юности в начале карьеры, первые пару лет.