Вчера у меня начались курсы по тестированию. В доп материалах есть отсылка на сам сайт Testbase — так я и получила баг-репорт от студента, сайт упал. База отвалилась.
Написала разработчику и в итоге поставили костылик:
Разработчик: Запустил, поставил перезапуск каждый день на 3:55.
Но я не настолько админ, чтобы понять чего там не хватает )
Разработчик: Там, судя по логам, кончается память.
Разработчик: sql-сервер наверное что-то кеширует.
Разработчик: Проще всего ребутать, потому что настраивать опухнешь там
Что в этой истории забавного — пару месяцев назад я услышала ровно о таком же хотфиксе от знакомого со своим небольшим сайтом. Та же проблема, но нагрузка побольше, поэтому сайт падал чаще. Покопались, покопались, обнаружили, что проще всего лечить ребутом. Поставили на таймер каждую ночь рестартить = проблема решена! 
В принципе, это действительно лучше, чем тратить кучу времени на настройку, администрирование и докрутку. Иногда проще обойти баг, чем его фиксить =)
Написала разработчику и в итоге поставили костылик:
Разработчик: Запустил, поставил перезапуск каждый день на 3:55.
Но я не настолько админ, чтобы понять чего там не хватает )
Разработчик: Там, судя по логам, кончается память.
Разработчик: sql-сервер наверное что-то кеширует.
Разработчик: Проще всего ребутать, потому что настраивать опухнешь там
В принципе, это действительно лучше, чем тратить кучу времени на настройку, администрирование и докрутку. Иногда проще обойти баг, чем его фиксить =)
О_О
ОтветитьУдалитьПомнится, Спольски когда то писал, что конечно же, есть эффективность, целесообразность, но есть уже и факторы гигиены. Ну вроде как в 2015 году не использовать VCS - все равно что лезть в рот немытыми руками.
Ощущение. что ребутать по таймеру из за утечки, это уже не эффективно, а негигиенично.
Что предложите? Тратить человеко-дни разработчика, чтобы искать корень зла? :)
УдалитьДа. Судя по описанному контексту (простой проект, не highload, не на 1 день) - именно так.
Удалить"Ради этого немытого яблока мне идти до колодца?"
Спрошу потом у знакомого, дошел ли он до колодца :)
УдалитьИ зачем мыть яблоко, если его не есть, а просто нести надо? Чем плох ребут, система разваливается?
Костыль хорош, пока мы лечимся. Пока мы ищем проблему - ребут спасает сайт. Но по тексту я понял, что это постоянное решение.
УдалитьДа, если я не планирую съесть яблоко, я пока не буду его мыть.
УдалитьЕсли проблем ребут не начнет приносить, то пусть остается
%)
УдалитьЧто там у нас с метафорой? Есть яблоко - заниматься разработкой сайта дальше.
Я не представляю себе, как он может не приносить проблем. Как минимум он маскирует проблемы и самое главное "я работаю на проекте с программистами, которые чинят лики ребутом по крону, аааа!!!"
1. Я пока не планирую "разрабатывать" сайт, вся нужная фнукциональность у меня уже есть.
Удалить2. Если его разрабатывать и всплывут проблемы — тогда и чинить.
Насчет "ааааа" — ну да, ппц какое "аааааа", разработчик предпочел заняться реальной работой, реальными багами на проекте, за который получает деньги, а не помочь мне бесплатно копаться и чинить баг, ни на что не влияющий. Аааааа, ооооооо, как так можно жить, когда ЕСТЬ БАГИ! Пока все не поправим, не быть покою!!!
И пока из нашего диалога весь смысл "зачем чинить" — "ну как же, баг же есть", это как то больше на начинающего тестировщика смахивает. "Я ВВЕЛ ДРОБНОЕ ЧИСЛО В ПОЛЕ С КОЛИЧЕСТВОМ СТРОК И СИСТЕМА НЕ ВЫДАЛА ОШИБКУ! ВСЕ, Я ЕЙ БОЛЬШЕ НЕ ВЕРЮ Я УШЕЛ ВЫ ПОТЕРЯЛИ ПОЛЬЗОВАТЕЛЯ! СРОЧНО ЧИНИТЕ БАГ!".
У меня не было столько контекста, Ольга ;) Про деньги и основную работу.
УдалитьА еще я говорил, если формализовать, о приоритизации баг по т.н. "гигиеническому фактору". То, с чем жить просто стыдно в приличном обществе. А не о просто "есть бага".
Ну так я же написала, что проблема возникла на Testbase :)
УдалитьА это или из моего кармана, или вообще бесплатно — так что лень разработчика меня вообще не смущает. Мне самой, например, лень покопаться в этом и поизучать, проблемы то нет. Чего и его дергать?
Понятие бага все равно в каждой компании немного разное, потому что разный круг тех, чье мнение имеет значение. Некоторые забивают на то, что система может упасть с дикими криками и не считать это багом, раз есть обходной путь и Заказчик не хочет платить за доработку
Согласна с Wolonter -- если лечить симптом, а не причину, это может привести к нехорошим последствиям. В данном примере, если нагрузка увеличится, то рестартовать может понадобиться не раз в сутки, а раз в час. Что уже может сказаться на пользователях. Да, иногда есть проблемы, которые сложно решить здесь и сейчас, и временно можно подпереть костылем. Но задача команды разработки в том, чтобы эти костыли не были забыты, и не висели грузом технического долга вечно.
УдалитьКлючевое слово "ЕСЛИ".
УдалитьЭто как делать высоконагруженный сервис, потратив кучу времени и денег НА СЛУЧАЙ, что туда будут ходить такие же толпы, как на амазон.
"Команда разработки", "задачи технического долга" — вы мыслите шаблоном работы, нормальной работы. А бывают еще фриланс проекты или свои собственные, как Testbase, например. Откуда там команда разработки? Откуда там вообще задачи. Я вам по секрету скажу, что у нас и, о ужас, багтрекера то небыло, без него сбацали сайт. Вот кошмар то, как можно работать без стандартных правил =(
Опыт подсказывает, что костыли имеют обыкновение не быть независимыми и разваливаться в один прекрасный момент все вместе. И часто это бывает ответственный момент. Например, один чувак забил на то, что течет память,а второй не подумал, и увеличил расход памяти. В результате, никто конкретно в проблеме не виноват, но продукт разломан.
УдалитьНу да, я мыслю шаблоном нормальной работы. Я стараюсь и какие-то вещи "для себя" делать не халтуря. Но вообще,позиция "мне за это не платят деньги напрямую, поэтому я буду делать плохо" мне не близка, но имеет право на существование.
Да да, разумеется, у меня позиция "мне за это не платят деньги, поэтому я буду делать плохо", ок. У продукта нарисовалось несколько разработчиков и он внезапно стал сломан :( Бедные юзеры, не переживайте, мы скоро все починим! И будем равняться на "нормальные работы", в которых никогда-никогда-никогда не ставят костылей. Ну, по крайней мере на словах...
УдалитьВ принципе, это действительно лучше, чем тратить кучу времени на настройку, администрирование и докрутку. Иногда проще обойти баг, чем его фиксить =)
ОтветитьУдалитьРегулярно слышу это от разработчиков :) Мол это не важно.
Я всегда отвечаю на это, зачем получать премию, проще ее обойти и получать только зарплату :)
Задача тестировщика — обосновать баг :)
УдалитьДоказать, что его стоит исправлять!
Но в данном случае — не стоит, потому что это не основная работа и не проект, который мы отдаем Заказчикам :) А то, что че-то там внутри Testbase ребутается — пользователи даже не заметят