Каморка

Marmot писал(а):http://news.com.com/Flickr+shows+a+litt ... 61469.html

самое главное пофиксили - молодцы.

Marmot писал(а):http://news.com.com/Flickr+shows+a+litt ... 61469.html

UUID были не unique enough ? :)

ajkj3em писал(а):

Marmot писал(а):http://news.com.com/Flickr+shows+a+litt ... 61469.html

UUID были не unique enough ?

Concurrency bug in mod_rewrite чтоб ему, самое трудное было понять что сломалось...
Баг проявился через 4 дня после того как изменения ушли в продакшн...

Это ты кажись говорил, что вы практически не тестируете код формально, а просто развертываете его на сервере?

aldep писал(а):Это ты кажись говорил, что вы практически не тестируете код формально, а просто развертываете его на сервере?

Ага, мы, потому как реальную нагрузку смоделировать очень сложно и дорого....
Так что, это скорее нормально Ошибки в нашем коде мы фиксим в течении минут, как правило...
А тут такой заковыристый баг, да еще и в апачевом коде, да к тому же у в Амерке long weekend был, пока всех нашли, то, се, короче влипли по полной
Теперь все в вазелине ходим

Marmot писал(а):

ajkj3em писал(а):

Marmot писал(а):http://news.com.com/Flickr+shows+a+litt ... 61469.html

UUID были не unique enough ? :)

Concurrency bug in mod_rewrite чтоб ему, самое трудное было понять что сломалось...
Баг проявился через 4 дня после того как изменения ушли в продакшн...

да, классическая жопа. я через пару таких прошел, одна
причем была 24 декабря :)

Marmot писал(а): Ага, мы, потому как реальную нагрузку смоделировать очень сложно и дорого....

Не так уж и сложно.
Записываете последовательность запросов и потом проигрываете их в на стенде в нормальном/ускоренном режиме.
Дорого - относительно.

aldep писал(а): Не так уж и сложно.
Записываете последовательность запросов и потом проигрываете их в на стенде в нормальном/ускоренном режиме.
Дорого - относительно.

Ага, для примера storage system, у нас только один файлер стоит, помоему полмиллиона, а их у нас сейчас ну скажем так >15, чтобы не выдавать секретов.
Для полноценного тестирования таких файлеров нужно как минимум 4 штуки. С базами данных тоже самое, они у нас распределены по 20 кластерам. При генерации страницы обращение может идти к 5-6 кластерам. Мы посидели, посчитали сколько времени, сил и денег у нас займет построение и поддержка полноценной тестовой системы и решили, что мы без нее проживем
Тем более в этом конкретном случае, она бы нас скорее всего не спасла...
Кроме того, для тестирования некоторых процессов нужен полный набор реальных данных, которые не в одну более и или менее разумную по цене тестовую систему просто не поместятся.
Вот такие вот дела, работа в некоторые моменты напоминает операцию на мозге Хотя, во всей команде, такого рода разработкой/поддержкой, занимаются только 3 человека, у остальных ошибки не так критичны.

Честно говоря ето конечно не факт. Хотя я ваших частностей не знаю, но мне каэется, что часть перформанс тестов можно промоделировать всегда (мне так кажется). Навернео не всю, но часть верняк можно. вопрос квалификации qa (мне так кажется)

aissp писал(а):Честно говоря ето конечно не факт. Хотя я ваших частностей не знаю, но мне каэется, что часть перформанс тестов можно промоделировать всегда (мне так кажется). Навернео не всю, но часть верняк можно. вопрос квалификации qa (мне так кажется)

A нет у нас QA у нас много чего нету, стиль разработки такой
Юзвери у нас QA. Release schedule у нас тоже нету, народ деплоится несколько раз на дню. У нас цена 99.9% ошибок не так высока, что бы из-за них QA заводить, а оставшиеся 0.01% как правило не того типа которые отлавливаются формальным тестированием. Типа отказ свича, или охреневший storage admin убивший на лету prоduction filer вместо остановленного

а круто блин не кто я к тому, что сколько контор столько подходов. Мой опыт показывает, что пре всей тщательности моего собственного тестинга (а ето в период имплементации новых фич достигает процентов 30 вермнеи наверное) я все равно баги пропускаю, где то намеренно срезаешь углы, чтобы уложиться в срок и считая ошибки не важными, где то конфигурации бывают такими что фиг придумаешь, и когда qa тебе баг ассанит прифигиваешь ека нашли мерзавцы конфигурацию. О да тут лиричиское отступление, по багу обычно сразу видно, то ли кастомер баг заасанил а qa его причесал и переслал, то ли, тестирую какую-нибудь хитрую конфигурацию кастомера баг выполз как побочный еффект, то ли qa инженеру было совесем делать нечего и он полез туда куда не надо, либо, самая мерзкая категория багов, когда qa хочет выслужится и начинает производить баги которые ни к селу ни к городу. Мне с русским менталитетом, с последним сложно, первое желание написать к репорту нот что qa соотвественно козел, увольте его нафик, приходится себя сдерживать... О ето вообще отдельные истории из последних, на мне висит ьаг уже месяца 4 наверное, пофиксит его я нужным не считаю, следущая версия сама его убьет, а делать его сейчас ето кроме меня еще напрягать как минимум еще одну группу, а точнее две, и проводить все ето через бюрократическую волокиту (баг один а группы три...) ну я и занял позиию выжидания, опять же плох тот девелопер на которм не висят баги - он слишком умен или гад делает вид что работает. И вдруг статус етого бага меняется с опен на феедбак, а ето надо видеть феедбак в принипе означает, что девелопер сказал что баг пофиксен но по сути соврал и он не пофиксен - баг тутже подсвечивается красным и на всех митингах девелопера начинают мягко насиловать всякие прожек манагеры, прожект лидеры и прочие лидеры, могет отнносидовать сто если перед етим его относиловал сео... так я 3 дня отписывался от етого статуса объясняя что я не верблюд и так надо... А все потому что какой то qa очень хочет стать манагером. Вобщем хорошо вам - у вас нет етих ребят, а кастомерам плохо ваши м:)

Marmot писал(а):

aldep писал(а): Не так уж и сложно.
Записываете последовательность запросов и потом проигрываете их в на стенде в нормальном/ускоренном режиме.
Дорого - относительно.

Ага, для примера storage system, у нас только один файлер стоит, помоему полмиллиона, а их у нас сейчас ну скажем так >15, чтобы не выдавать секретов.
Для полноценного тестирования таких файлеров нужно как минимум 4 штуки. С базами данных тоже самое, они у нас распределены по 20 кластерам. При генерации страницы обращение может идти к 5-6 кластерам. Мы посидели, посчитали сколько времени, сил и денег у нас займет построение и поддержка полноценной тестовой системы и решили, что мы без нее проживем
Тем более в этом конкретном случае, она бы нас скорее всего не спасла...
Кроме того, для тестирования некоторых процессов нужен полный набор реальных данных, которые не в одну более и или менее разумную по цене тестовую систему просто не поместятся.
Вот такие вот дела, работа в некоторые моменты напоминает операцию на мозге Хотя, во всей команде, такого рода разработкой/поддержкой, занимаются только 3 человека, у остальных ошибки не так критичны.

Не убедил:
1. Согласимся с цифрами. У вас 20 файлеров и 20 кластеров, а для тестирования надо 4-5, т.е. для тестирования надо затратить на 20% больше. Вполне разумная цена.
2. Совсем не обязательно решать задачу в лоб. Файлеры можно эмулировать гораздо более дешевыми компьютерами, скажем посылать одни и теже файлы не зависимо от того что запрошено.
Или просто эмулировать их ответы программно на кластере.
Кластеры тоже заменить можно более дешевым оборудованием, сойдут и компьютеры собранные на коленке.
3. Не верю, что поймать баг в mod_rewrite нельзя было unit test'ом сделанным грамотно.

aldep писал(а):У вас 20 файлеров и 20 кластеров, а для тестирования надо 4-5, т.е. для тестирования надо затратить на 20% больше. Вполне разумная цена.

Сразу видно опытного бизнесмена

aissp писал(а): а кастомерам плохо ваши м:)

А большинство из них так не думает
Ты, похоже, не совсем в курсе современной интернет моды