Бывают баги а бывают и БАГи. И если баги обычно фиксятся и забываются, то БАГи остаются с нами навсегда. Хочу поделиться с Вами тремя такими БАЖищами.
Первый такой казус произошел в 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" (роковая женщина).
Занавес.
Первый такой казус произошел в 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" (роковая женщина).
Занавес.