Три самых любимых бага

Бывают баги а бывают и БАГи. И если баги обычно фиксятся и забываются, то БАГи остаются с нами навсегда. Хочу поделиться с Вами тремя такими БАЖищами.

Первый такой казус произошел в 2005 году, когда я работал на фирме FriendScout24. У нас была тулза для мониторинга, в которой была хтмлная табличка и в каждой строчке по серверу. Если сервер отвечал нормально — он отрисовывался зеленным, если нет то красным. Обычно всё было спокойно зелененьким. И тут, в один прекрасный августовский день, сервера начали падать лесенкой. Пам-Пам-Пам — 4 сервера за 3 минуты. Через 5 минут всё снова позеленело, как будто ничего и не было.



Это повторилось на следующий день, через день и так всю неделю. После того как usual-suspects (loadbalancer, javascript) были исключены, Оливер (один из фронтенд девов) выставил гипотезу, что это какой-то юзер. Так как юзеров было около 2 миллионов и около 25.000 одновременно залогиненых, найти его оказалось сложно. Но в истории FriendScout24 уже была ситуация когда один юзер положил всю систему, поэтому мы решили не сдаваться.

И что же, в итого причиной всего зла оказалась фотография. Но не совсем простая. Одна девушка решила обогатить свой профиль фотографией, что само по себе похвально и приветствовалось. Однако фотография у неё была только в форме PDF. Как и все нормальные порталы того времени, мы PDF не принимали, а принимали JPEGи и разные там GIFы. Девушка — не дура — переименовала foto.pdf в фото.jpg. Тем самым она обошла mime-type check и её фотография поплыла в дебри системы. В этих дебрях сидел imagemagick, тогда state-of-the-art библиотека для обработки фотографий. Так вот imagemagick, тоже не дурак, вместо того чтобы сказать, что это никакой не jpg и послать фото назад, по содержанию распознал в фотографии pdf и вызвал своего кореша ghostscript для обработки этого pdf. А так как никто никогда не собирался обрабатывать PDFы на этих машинах, никакого ghostscript там и рядом не валялось что вызвало лёгкий seg fault в native либе, и благополучно положило JVM отдыхать рядом. Упс.

Девушка же не унывая пробовала всё заново уже на следующем сервере и убивала сервера один за другим. Большое ей кстати спасибо, что не хватило у неё терпения попробовать 12 раз, именно столько веб серверов у нас тогда было.

Второй баг произошёл в доисторические времена, когда я делал одну из первых версий этого сайта. На сайте информация о всяких машинах для хим-чисток и прачечных, и все эти машины задавались в content-management-system (cms) из которого и рисовался сайт. Сначала всё было отлично, довольный заказчик и все такое. Через неделю заказчик позвонил и пожаловался что добавление новых машин длиться как-то подозрительно долго. Я проверил, логи пустые, сервер простаивает, ничего не нашёл. Заказчик звонит снова, говорит добавил 100 машин, теперь каждая новая машина добавляется минуту. Посмотрел, проверил — правду говорит. В общем долго дело делается, да скоро сказка сказывается, поставил измерение времени чуть ли не на каждую строчку, нашёл подлеца. Долго глазам своим не верил: log.debug(cache).

При этом сам debug был выключен, поэтому ничего ни в каких логах не увидел, но toString метод этого cache просто вырисовывал содержимое во всех деталях. И длился всё больше и больше. Эдак три минутки на одну операцию. В общем с тех пор я всегда пользуюсь log.isDebugEnabled(). Хоть с пользой время потратил.

И наконец мой любимчик. Главный баг всех времен и народов. Это было эдак в 2003 году на том же FriendScout-e. До того как они меня наняли (может потому и наняли). Платформа в то время была очень не стабильная, падала частенько и поддерживалась людьми которые мало что понимали в том, что они делали. А когда люди не хотят или не могут понять причину плохого поведения системы, у них один метод ремонта — ctrl-alt-del. Ведь то что хорошо на Винде, должно быть хорошо всюду, не так ли?

В нашем случае один из админов написал супер-вумный скрипт, который читал системные логи и если находил там keyword FATAL, то рестартовывал всю аппликуху. Со всеми 25ю серверами, причалами и пароходами. Когда рестарты зачастили им пришлось пересмотреть свою политику. А произошло это так:
В службу поддержки звонит женщина и говорит:

Женщина: «А почему когда я логинюсь в Вашу систему она тут же выключается?»
Агент поддержки: «Какой у вас логин?»
Женщина: "femme-fatale" (роковая женщина).

Занавес.
Share post

Similar posts

Comments 58

    +41
    Я бы этому дяде, с большими ушами, уши бы да пооткручивал. (с) Простоквашино.
    Хочется немного подправить это выражение для последнего случая.
      +27
      А ещё лучше никогда не судить, услышав только одну точку зрения.

      Может там админу дали сырое ПО, быстро написанное левой ногой, и сказали: «держи». А оно падает от хлопков дверью. И он уже замучался писать девелоперам багрепорты и просить их сделать хоть что-то, а ничего не фиксят. Потому что кризис программистов, и менеджеры с целью выполнить задачу на квартал отправили хороших девелоперов писать и запускать другой денежный проект, а на поддержку уже проданного оставили дешевых интернов-студентов, которым просто не хватает опыта и знаний ни на что, кроме как починить опечатку в сообщении об ошибке.

      Ни доки ни инструкций быстро слинявшие с проекта авторы не успели оставить, админу разбираться в ПО совсем не сруки, у него свои задачи, которые надо сделать, бекапы настроить протестировать.

      И вот в очередной раз отправив багрепорт в /dev/null он, в запарке (надо там кластер расширить, там бекапы поднять), одной рукой делает facepalm, а другой быстро пишет скрипт который бы хоть как-то сэкономил время с этим говноПО. И оказался в итоге дураком в поучительной истории ;)

      Конечно я тут навыдумывал, но очень часто слышал очень однобокие пересказы историй, которым самым был свидетелем.
        –9
        Я сторонник такого подхода — не можешь делать хорошо, по тем или иным причинам — не делай. Ну вот держал его кто-то за руку на этом говняном месте, что ли? Приковали к батарее и сказали — держи? Не думаю. Не дали девелоперов, не создали условий, не обеспечили необходимым — надо валить. Иначе останешься крайним и никто не спросит почему и зачем. Крайним останешься и вполне заслуженно.

        Есть такие заказчики/работодатели, которые с авторами поссорились, денег не доплатили или просто сэкономили и наняли непонятно кого, получили на выходе какашку, а потом хотят опять же за дешево и чужими руками эти горячие угли (или какашки?) загребать. Не надо им потокать, не наша это война и не надо героически платить за чужие (руководства) ошибки.
          +26
          Всё, конечно верно. Но в теории.

          Я, ведь, ещё могу придумать ипотеку, трёх детей, и жену которая после последних родов не сможет работать ещё пол года. И в таких обстоятельствах просто страшно менять даже плохого, но платящего, работадателя на кота в мешке. Вдруг пролетит, не соберёшь данег на очередной платёж и лишишься квартиры.

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

          Но пол года назад родители на одной машине попали в тяжелое ДТП, и на операцию пришлось продать квартиру, потом серия других неприятностей с родственниками и тяжелые роды (стрессы и всё такое) заставили продать и другие машины чтобы оплатить операции и лечение за рубежом. Со второй работы его выгнали, пока он ездил по операциям (им пофиг было). Чёрная полоса может спустить на землю любого.

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

            >>и ещё одну ипотеку.
            >>И не надо думать, что парень — дибил
            Ну не знаааю. :D Надеялся что ближайшие 10 (или 20?) лет все будет так же хорошо? Надеяться, конечно, надо на лучшее, а вот готовиться — к худшему.

            Вообще свои ошибки полезно признавать. Оправданий и причин можно найти миллион — это не так сложно. Но это ничего не изменит, а вот признание ошибки — очень даже изменит и в лучшую сторону.
            Я же не говорю, что в подобной ситуации я бы не допустил подобной ошибки. Очень может быть, что допустил бы. Я же не лучше — сам иногда такое творю, что аж страшно. Но стараюсь признавать, что косячу и это позволяет двигаться дальше и развиваться. А обложившись оправданиями и утвердившись в уверенности, что ты ничего не мог сделать, что ты не виноват а виноват кто-то там — нет причин что-то менять. Все ведь хорошо, я ведь сделал все что мог, я не виноват. Нет мотивации к движению и изменениям. Это плохо.
              +2
              Опять же согласен! Празнавать ошибки надо, и это правильно и полезно. Но мы же не знаем, признал свою ошибку админ или нет?

              Может он услышав жалобу клиентки, сам понял причину, исправил и в тот же день написал начальству, какой он дурак и что вот за эти и эти рестарты виноват только он, это обошлось компании в такую-то сумму и они могут вычесть её из зарплаты ;)

              И больше никогда так не делал.
                –2
                Да, не знаем. Да и не так это для нас важно :). Важно что ошибку он таки допустил. Ну в данном конкретном случае это для нас важно. И как правильно заметили — я никого не судил. Даже если бы мой подчиненный допустил подобную ошибку и было в моих силах его наказать, я бы этого не делал. Опять же из-за соображений указанных выше.
          +5
          Ну в данном случае налицо, всё-таки, некомпетентность или пофигизм админа, написавшего кривой скрипт:
          а) видимо неверная регулярка
          б) сам скрипт не писал в свой лог из-за чего он ребутает систему
          в) если даже писал, то админ не следил за тем, что он туда писал

          И если первая ошибка простительна (все мы человеки, все ошибаемся), то вот вторая и третья — либо некомпетентность, либо пофигизм. После первого же логина этой женщины и последовавшего ребута он должен был обнаружить ошибку в своей регулярке.
            +4
            Я согласен, ошибка была.

            б, в не факт :) Вполне возможно, что и логи были и админ их мониторил, но только первые месяцы (пока роковая женщина не зарегистрировалась). Убедившись, что скрипт работает, он переключился на другие задачи, а на это больше не было времени.

            Вообще, админы обычно не читают логи по утрам. Не эффективно. В лучшем случае краткую выдержку из скрипта, который ищет нестандартные записи (взлом, подбор пароля, нестандартные ошибки). А в логи лезут когда появляется проблема. Для поиска проблем помогают всякие графики загрузки и мониторилки.

            А то, что эта проблема обнаружилась после звонка женщины, может говорить о том что ПО было настолько сырым, или рестарт настолько быстрым, что ещё два-три рестарта в сутки погоду не делали.

              +1
              То есть ребут системы из 25 серверов перешел в разряд стандартных ситуаций? Конечно, если ребуты из-за фатальных ошибок каждые 5 минут, то да, смотреть смысла нет.
              +1
              > в) если даже писал, то админ не следил за тем, что он туда писал

              Круто было бы если он писал после перезагрузки в лог: System will rebooted because FATAL error in bla-bla-bla…
              Сори за мой хреновый ангельский.
              +2
              Почему разговор зашёл про «судить»?
              По-моему, автор никого не судит, он просто рассказал нам несколько весёлых историй. Последняя история действительно весёлая, должна войти в анналы.
                0
                Я не автору статьи отвечал ;)
                0
                Богатый жизненный опыт!
            • UFO just landed and posted this here
                +61
                Роковая женщина убивающая сервера — это жесть! :)
                  +18
                  Ну кто же содержимое по расширению-то проверяет?
                    +1
                    Ну так один из лучших методов перед загрузкой на сайт это пропустить через magic. Там можно и пережать и превью сделать и скрипты не пройдут.
                    • UFO just landed and posted this here
                        0
                        Так и делали, и из-за этого был весь сыр-бор. Потом перевели на JAI — это решило много проблем.
                      +17
                      Последний случай, по-мому, достоен того, чтобы войти в историю золотыми буквами :)
                        –3
                        Какие глупые все ошибки-то…
                          +4
                          Я у скаутов (в германии) админом поработал. Очень они хаотичные ребята, но было весело…
                          В первый раз кстати убило: у них есть такая рекламная наклейка — сексапильная девушка в полный рост. Так вот эти гады прилепили эту наклейку на дверь в туалете. Отходим от писсуара, поворачиваемся к выходу и ВДРУГ оказывемся лицом к лицу с девушкой. В первый раз так нехило шокирует.
                            +6
                            Вдогонку второй анекдот:
                            У них в комнатах для совещаний были проведены специальные линии связи для конференций. Сам великий и могучий аппарат стоял в серверной а в комнату для совещаний выводился только невзрачный нло-подобный динамик с микрофоном. Так вот, вывод был сделан под RJ45, но распиновка, сила тока и напряжение были «немножко» другими. Несколько человек успело угробить сетевые карты в ноутбуках втыкая их туда вместо динамика, даже бумажка с жирно написанным предупреждением типа «НОУТ СЮДА НЕ ВТЫКАТЬ!» не всегда помогала.
                              +8
                              За такие технические решения надо кастрировать. В совке тоже были радиоприемники с подключением к радиоточке, но с обычной вилкой как на 220В. Наверное половину таких девайсов спалили в первый же день покупки.
                                +3
                                Если бы это делал я, то я бы добровольно убился бы об стену.
                                  +2
                                  Втыкал старенький радиоприемник по ошибке в 220, не спалил :) Только гул из динамика шел
                                    0
                                    Возможно у вас был уже приемник с защитой %) У меня точно дома валялся на антресолях такой погорелец.
                                      +1
                                      Не было там ни какой защиты. Обычный понижающий трансформатор. Обычно, они выдерживали подключение к сети. Видимо, вам просто очень сильно не повезло или ваш «абонентский громкоговоритель» (а вовсе ни какой не радиоприёмник), был китайским барахлом или перестроечной инновацией с целью экономии.
                                      0
                                      Ха, будучи ребенком, я наушники для радиоточки в 220V втыкал!
                                      0
                                      Ох… вспомнил детство )
                                  +1
                                  Баг и недоработка немного отличаются, неверную работу чего либо из-за некомпетентности разработчика я называю хренью, а не багом. Баги встречаются постоянно, хрени все реже :)
                                  «Роковая женщина» — улыбнуло. Это одна из причин веры некоторых админов в бубен.
                                    +62
                                    К третьей истории, наверное тут должен бытьт этот боян
                                      –2
                                      Папашка разработчик ))
                                      +9
                                      «переименовала foto.pdf в фото.jpg. Тем самым она обошла mime-type check»

                                      Таким образом проверка mime-type не обходится. Таким образом обходится проверка на расширение файла. Методы для получения mime-type не должены зависеть от расширения и / или заголовка «Content-Type» http-запроса.
                                        +3
                                        В http-запросе есть mime-type отправляемого файла. Видимо, его обход и описывается. Естественно, проверять нужно и по содержимому.
                                        –7
                                        Кто это все через песочницу стал пропускать? Истории, конечно, неплохие, но ведь для этого есть другие сайты, правда?
                                          –3
                                          Это какие же? оО
                                            –2
                                            Ну для этого поста «IT Happens» замечательно подходит. Для поста «Взлом с продолжением» я даже не знаю. Там нет ничего, кроме морали, что не надо запускать exe-файлы. Еще недавно был топик про музыку к игрушке, который из песочницы пошел сразу в «Я пиарюсь». Т.е. человеку дали инвайт за то, что он пропиарил свою игрушку.

                                            Конечно, из песочницы выходят хорошие статьи, но в последнее время их стало как-то маловато.
                                              0
                                              По моему вы слишком строго судите. Если статья понравилась, то наверное можно же дать инвайт? Ведь не каждый же может быть самым-самым в своей профессии, а вот работа и жизнь каждого уникальна. Давайте просто порадуемся за коллегу у которого в професииональной жизни случились вот такие интересные анекдоты.
                                                –2
                                                Против коллеги я ничего не имею, просто хотелось бы ужесточить модерацию. Вы правы, наверное, я слишком строг.
                                          +4
                                          Мой самый нелюбимый и серьёзный баг, это когда я свою контору случайно кинул на ~700к.р.
                                          Разрабатывал одну партнёрскую программу и часто нужно было менять в ней разные вещи, например нужно было ставить в холд деньги из определённых стран. В холд деньги ставились, но всё-равно как оказалось выплачивались (забыл в условие добавить параметр). В итоге один добропорядочный партнёр (и по совместительству друг) сообщил о том, что слишком уж много денег ему мы платим каждый раз. В итоге примерно ~300к.р. он нам вернул, остальные 400 естественно партнёры не вернули. Такие дела)
                                            +10
                                            По мне так самый шикарный баг в истории — это удаление папки usr из-за случайного пробела в пути для команды rm -rf в Bumblebee
                                              0
                                              А не удаление ли с корня?
                                              rm / usr/shared/... -rf

                                              Кстати, полезная привычка дописывать -rf в конец строки, когда взглядом проверишь то, что уже написал. :)
                                                0
                                                А вот собственно сам коммит, исправляющий этот баг, и мегадоставляющая лента комментариев к нему:
                                                github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6
                                                  0
                                                  Я всегда буду пролистывать комменты до конца. Я всегда буду пролистывать комменты до конца. Я всегда буду пролистывать комменты до конца.
                                                0
                                                у меня свеженький баг, оставшийся от прошлого программиста.

                                                У нас пассажир стабильно ложился раз в час. Вычислили, что это рейктаск, который по крону запускается. Ну а там update_all на модельке, в которой десятки тысяч записей, причем не простой UPDATE, а с SELECT внутри, в общем он блокировал эту таблицу на полминуты, со всеми вытекающими :)
                                                  0
                                                  Не знаю, насколько это может быть интересно, но мне запомнился один баг. Делал расширение для браузера, где данные отображались в табличном виде, и это дело нужно было экспортировать в Excel. Сделал экспорт в csv, все работало нормально, но через некоторое время заказчик начал жаловаться на искаженные данные при экспорте: в таблице был столбец «телефоны», где иногда было по 2 телефона (через запятую), — у второго телефона обрезались все цифры, кроме первых 4, последняя могла меняться. Хрен поймешь, в чем дело.

                                                  Оказалось, что Excel — очень умная программа, поэтому при открытии csv-формата без доп. настроек она устанавливает типы ячеек, если информация похожа на какой-то формат. В данном случае запись вида «89161234567,89102345678» определяла числовой тип ячейки, а стандартные установки при отображении такого типа: отображение 4-х знаков после запятой, округление. :)
                                                    +10
                                                    Да, уж как эксель достал со своим автоопределением форматов, это никакого валидола не хватит!
                                                      0
                                                      Я обычно стараюсь такие моменты предугадывать и ставлю пробел.
                                                      +1
                                                      Последний баг улыбнул)))
                                                        +9
                                                          0
                                                          Ну это вообще подстава! xD
                                                          0
                                                          Принес сотый плюс :) Поздравляю!
                                                          Последний баг конечно шикарен, прямо в книгу.
                                                          • UFO just landed and posted this here
                                                              0
                                                              update users set password='?'

                                                              Звонок в три часа ночи из штатов, недоуменный голос — а чего это у нас когда один пользователь меняет свой пароль, потом никто другой залогиниться не может? Смотрим код… а где же:

                                                              … where id=?

                                                              FUUUUUUUUUUUUU…
                                                                0
                                                                У нас у одного клиента была похожая ситуация в январе:
                                                                Время от времени база с продуктивной системы переносится на пре-продакшен, ну и анонимизируется, чтобы не играться с настоящими данными. В процессе анонимизации убираются пароли, имена, имэйлы и.т.д. Так вот после переноса один из админов перепутал консоль и запустил update users set password = '101010' на продакшен. Было очень весело, но благодаря извращённой многоуровневой системы бэкапов, за час всё восстановили из netapp-snapshot.
                                                              • UFO just landed and posted this here

                                                                Only users with full accounts can post comments. Log in, please.