Ндаа, это была ж... :(

[Marmot]

http://news.com.com/Flickr+shows+a+litt ... 61469.html

[папа Карло]

http://news.com.com/Flickr+shows+a+litt ... 61469.html

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

[ajkj3em]

http://news.com.com/Flickr+shows+a+litt ... 61469.html

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

[Marmot]

http://news.com.com/Flickr+shows+a+litt ... 61469.html

UUID были не unique enough ?

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

[aldep]

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

[Marmot]

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

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

[ajkj3em]

http://news.com.com/Flickr+shows+a+litt ... 61469.html

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

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

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

[aldep]

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

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

[Marmot]

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

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

[aissp]

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

[Marmot]

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

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

[aissp]

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

[aldep]

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

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

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

[не местный]

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

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

[Marmot]

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

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