Три Моих Любимых Жука

Есть ошибки и есть ОШИБКИ.

И если ошибки обычно исправляют и забывают, то ОШИБКИ остаются с нами навсегда.

Хочу поделиться с вами тремя такими СУМКАМИ.

Первый такой случай произошел в 2005 году, когда я работал в FriendScout24. У нас был инструмент мониторинга, в котором была HTML-таблица, и в каждой строке был сервер.

Если сервер отвечал нормально, он рисовался зеленым, если нет, то красным.

Обычно все было спокойно-зеленым.

И вот, в один прекрасный августовский день, сервера начали падать, как лестница.

Пам-Пам-Пам - 4 сервера за 3 минуты.

Через 5 минут все снова стало зеленым, как ни в чем не бывало.

Это произошло снова на следующий день, на следующий день и так до конца недели.

После того, как обычные подозреваемые (балансировщик нагрузки, javascript) были исключены, Оливер (один из разработчиков интерфейса) предположил, что это был какой-то пользователь.

Поскольку пользователей было около 2 миллионов и одновременно заходили около 25 000, найти оказалось сложно.

Но в истории FriendScout24 уже была ситуация, когда один пользователь уничтожил всю систему, поэтому мы решили не сдаваться.

И вот, в конце концов, фотография оказалась причиной всех зол.

Но не совсем просто.

Одна девушка решила дополнить свой профиль фотографией, что само по себе похвально и приветствуется.

Однако у нее была только фотография в формате PDF. Как и все нормальные порталы того времени, мы не принимали PDF-файлы, а принимали JPEG и различные GIF-файлы.

Девушка - не дура - переименовала foto.pdf в photo.jpg. Таким образом она обошла проверку по мим-типу и ее фото уплыло в дебри системы.

Сидя в этих дебрях имиджмагия , а затем современную библиотеку для обработки фотографий.

Итак, вот оно имиджмагия , тоже не дурак, вместо того, чтобы сказать, что это не jpg и отправить фото обратно, он распознал на фото контент как pdf и вызвал своего кореша Ghostscript для обработки этого pdf. А поскольку никто никогда не собирался обрабатывать PDF-файлы на этих машинах, не было никакого Ghostscript, что вызвало небольшую ошибку сегментации в собственной библиотеке и благополучно остановило JVM поблизости.

Упс.

Девушка, не унывая, попробовала все еще раз на следующем сервере и убила серверы один за другим.

Кстати, я ей огромное спасибо за то, что не хватило терпения попробовать 12 раз, именно столько веб-серверов у нас тогда было.

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

этот сайт .

На сайте размещена информация о всевозможных машинах для химчисток и прачечных, и все эти машины были указаны в системе управления контентом (cms), из которой был нарисован сайт. Поначалу все было отлично, клиент доволен и все такое.

Через неделю позвонил заказчик и пожаловался, что добавление новых машин занимает подозрительно много времени.

Проверил, логи пустые, сервер простаивает, ничего не нашел.

Клиент снова звонит, говорит, что добавил 100 машин, теперь каждая новая машина добавляется за минуту.

Я посмотрел, проверил, и он говорит правду.

В общем, работа выполняется долго, но вскоре сказка рассказана, я почти на каждой строчке установил мерку времени, и нашел подлеца.

Я долго не мог поверить своим глазам: log.debug(кэш) .

При этом сама отладка была отключена, поэтому ни в каких логах я ничего не увидел, а метод toString этого кэша просто вытягивал содержимое во всех подробностях.

И это длилось все дольше и дольше.

Примерно три минуты на одну операцию.

В общем, с тех пор я всегда пользовался log.isDebugEnabled() .

По крайней мере, я провел время с пользой.

И, наконец, мой фаворит. Главный баг всех времен.

Это было ещё в 2003 году на том же FriendScout-е.

До того, как меня наняли (может, поэтому и наняли).

Платформа на тот момент была очень нестабильной, часто выходила из строя и поддерживалась людьми, мало разбиравшимися в том, что делают. А когда люди не хотят или не могут понять причину плохого поведения системы, у них есть один метод ремонта — ctrl-alt-del. В конце концов, то, что хорошо в Windows, должно быть хорошо и везде, верно? В нашем случае один из админов написал суперумный скрипт, который читает системные логи и находит там ключевое слово ФАТАЛЬНЫЙ , затем перезапустил все приложение.

Со всеми 25 серверами, причалами и кораблями.

Когда перезапуски стали более частыми, им пришлось пересмотреть свою политику.

А произошло это так: Женщина звонит в службу поддержки и говорит: Женщина: «Почему, когда я захожу в вашу систему, она сразу выключаетсяЭ» Агент службы поддержки: «Какое у вас имя пользователяЭ» Женщина: " роковая женщина "(роковая женщина).

Занавес.

Теги: #ошибки #ошибки #программирование #программирование

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.