Что ещё делать в пятницу вечером накануне Хеллоуина, как не рассказывать страшные истории?
Эта статья — сборник ситуаций, в которые вы никогда не захотели бы попасть, но они произошли с нашими ребятами. Все имена вымышленные, все сюжеты — реальные. Авторский стиль рассказчиков сохранён.
Выключайте свет, зажигайте свечи. Настало время страшных и местами страшно-забавных историй из жизни айтишников. Бу!
***
На предыдущей работе был разработчик, назовём его Афанасий. Проработал он у нас недолго, но у меня сформировался рефлекс — когда я видел в коде какую-то дичь, то поднимал глаза на 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 остановилась.
Возможно, кому-то эти зарисовки покажутся не страшными, но нас они немного напугали, а местами и повеселили. И теперь ваша очередь — рассказывайте в комментариях свои страшилки.
Комментариев нет:
Отправить комментарий