Как часто при просмотре фильмов ужасов хочется закричать: «Не ходи туда!», «Обернись!» или «Беги!»? Будете удивлены, но в работе IT-специалистов такие истории тоже случаются. О том, что для айтишников страшнее маньяка с пилой или монстра в подвале, рассказывают сами айтишники.
Евгений Коланда, руководитель группы технической поддержки ключевых клиентов
Вечером в пятницу, в тихом уютном офисе, два опытных инженера Алекс и Марк подключали новый хост к кластеру. После тщательного планирования и множества проверок они были уверены в силах.
Операция, по сути, простая. Выполнялась много раз. Процесс автоматизирован: подключи, сделай несколько простых первоначальных настроек, запусти скрипт на добавление. С перерывом на кофе — максимум 30 минут. Поэтому выбранное время никого не смущало. Сетевые настройки верны, порты на коммутаторе проверены и подключены, даже на всякий случай несколько раз заменены патч-корды. Но нода кластера никак не желала видеть новый хост, и новая нода была невидима для всего кластера. Что делать?
Часы бесплодных попыток исчерпали силы инженеров. Они подумали, что сделать все сегодня не получится. Когда надежда почти угасла, Алексу позвонила жена. Он не был готов к разговору, но все же ответил. Так началась история, которая перевернула ход событий.
Жена рассказала, что только что купила туфли. Пошла в продуктовый магазин, но по пути увидела пару, которую давно искала. Померила 37 размер — малы. 38 — велики. Ничего не понятно. Но вдруг она увидела вторую коробку с размером 37. Примерила еще раз, и все подошло. Оказалось, на первой паре была неправильная маркировка.
После разговора Алекс и Марк внимательно осмотрели все настройки новой ноды. Неожиданно они обнаружили ошибку в IP-адресе — во втором октете, который, казалось бы, не мог стать причиной проблемы. Подобно тому, как туфли в коробке с неверным размером усложнили выбор, ошибка в IP-адресе ноды привела к часам потерянного времени.
Новый хост был успешно подключен. Инженеры поняли, что даже в мире технологий иногда важно прислушиваться к намекам судьбы и уделять внимание мельчайшим деталям.
Тимофей Михайловский, руководитель технической поддержки линии L2
Случай произошел в одну из моих первых ночных смен в должности техсаппорта одного очень крупного хостинг-провайдера. Был май-июнь, на улице жарко.
Сижу в офисе один и слышу назойливый писк из серверной. На панели управления кондиционерами вижу отказ одного из устройств. Второй кондиционер незадолго до этого отправили на техобслуживание. На его месте в потолке дыра. Температура в серверной начала повышаться. В помещении стояло железо, обеспечивающее работу очень крупного новостного и не только портала.
Я начал бегать по всему офису и собирать обычные вентиляторы из кабинетов, чтобы организовать хоть какую-нибудь циркуляцию прохладного воздуха. Результат был похож на ферму вентиляторов, дующих в серверную.
Было стрессово, но обошлось без потерь.
В начале карьеры после университета я работал в компании, где руководитель проверял все «от и до» в макете сайта. Я старался понять, что ему нужно, но он придирался даже к абсолютным мелочам, и приходилось вносить существенные изменения в код. Тогда я понял, что человеку нужно чувствовать, что он все «улучшает», и без его правок любой проект пойдет ко дну.
Я начал вставлять в код намеренно ужасные цветовые схемы, помещал кнопку «Отправить» в самые неожиданные места. Я нарушал весь UX, как мог.
Естественно, нормальный код тоже был. Но для этого человека я всегда посылал специальное издание 🙂 Мне давались очевидные правки, я выжидал время и отсылал заготовку, которую всегда принимали без замечаний.
Мой руководитель был очень счастлив, меня повысили и называли «продуктивным». Но спустя время я все равно оттуда уволился.
Пароль для доступа к IT-системе подходил у одного заказчика только тогда, когда тот сидел на определенном кресле. Когда заказчик вводил пароль, стоя рядом с рабочим местом, зайти не получалось. Как оказалось, кто-то поменял местами клавиши на клавиатуре у компьютера. Когда заказчик сидя вводил пароль, то делал это слепым методом, не глядя на буквы. В итоге все было верно. А когда стоял рядом, то смотрел на клавиши и, по факту, ошибался. То, что он вводил, не было видно в обоих случаях — пароль был скрыт звездочками.
Еще одна история — про «мышку с телепатическим управлением». В какой-то момент моя компьютерная мышь начала реагировать на движения руки. Когда я держал ладонь в десяти сантиметрах от устройства, в браузере на экране передо мной начинала прокручиваться страница. Если я убирал ладонь, прокрутка заканчивалась. Фокус оказался в том, что внутрь мыши попал тонер от лазерного принтера. Вещество обладает магнитоэлектрическими свойствами, из-за чего и случился удивительный эффект.
Есть и история про «заботливый компьютер». У коммерческого директора компании ERP-система на компьютере работала только тогда, когда человек пил кофе или выходил на перекур перед началом работы. Если директор приходил и сразу садился за дела, система зависала. Не помогали даже перезагрузки. Такие ситуации происходили только в утреннее время. Компьютер управленца оказался ни при чем, ERP-система — тоже. Секрет так и не разгадали, но спустя пару лет с новой серией Windows проблема решилась сама собой.
Пасмурным осенним утром я начала тестировать новый продукт. Открыв задачу, увидела скромный заголовок и единственную ссылку на документацию. Выглядело это довольно странно, даже подозрительно.
Перейдя по ссылке, поняла: она вела на родительскую спецификацию, объединяющую семь документаций. Каждая объемом 6 000 знаков. И это только описание фичи со стороны бизнеса. Чтобы протестировать, нужно найти документацию на архитектуру, менеджмент, бэк, UI. И отдельно, конечно, дизайн в трех версиях, который в итоге окажется менее актуален, чем в спецификации.
По спине пробежали мурашки, на лбу выступил пот. Шли часы поисков, раскапываний, уточнений в различных инстанциях… День сменялся очередным днем. Старые комментарии коллег к спецификации приходилось аккуратно, чтобы не повредить, вытаскивать из архивов, а вместе с ними — ссылки на запросы и структуры ответов, порты для обращений, сервисы логирования, ключевые поля и параметры.
Седые волосы, пустырник вместо воды в организме, ночные кошмары с пустыми задачами… А таких задач не две, не три, а все! Первая спецификация в задаче оказалась архивной, вторая — на стадии ревью, остальные — недописанные. Волнами накатывала паника.
Но самое страшное оказалось в конце. Задача была не реализована. В документации не указали, что логику работы приложения решили поменять, от половины фич отказаться, а саму задачу забыли зареджектить, написав новую. Такую же, но с актуальной ссылкой на спецификацию.
И когда, наконец, я из последних сил написала архитектору, что документацию нужно переписать, то узнала, что это невозможно. Автор ушел из компании больше шести месяцев назад, никто не знает, как связаны сервисы, на чьей стороне начинать работу, если вообще начинать. Более того, часть приложения оказалась завязана на два сторонних программных обеспечения, разработчики которых давно не отвечают, а сервис работает на моковых данных, которые, естественно, залиты без комментариев.
Не самый счастливый финал, зато честный.
А с вами случались «страшные» истории на работе? Делитесь в комментариях.
