Ну почему же. Даже если проблема не решается со стороны сервера и есть подозрение на работу клиентского софта — в поддержке mail.ru есть выделенная группа, которая будет разбираться с подземным стуком у юзера вплоть до подключения к нему тимвьювером, если он к этому готов. И таким образом тоже отлавливались достаточно интересные проблемы. Но, естественно, для того чтобы «попасть» на такую поддержку надо очень четко описать симптомы «стука» и пройти через стандартные рекомендации типа очистки кэша.
Если ситуация диагностируема и воспроизводима — это, разумеется, стандартный случай, не требующий вмешательства менеджера.
Но пример — баг стабильно воспроизводится у 0.01% пользователей. Процент пострадавших небольшой. Ситуация может быть невоспроизводимой или сложно диагностируемой: race condition, кратковременный сбой в каком-нибудь сервисе из-за которого когда-то (возможно даже и не сегодня) куда-то попали не те данные, редкая конфигурация или сочетание нескольких факторов, проблема в какой-то граничной ситуации, например когда одновременно ребутятся два разных сервиса и т.д. и т.п.
Маленький сервис такую проблему может в принципе никогда не поймать проблему или забить на нее, т.к. пострадавших пользователей единицы. Крупный сервис не может себе позволить забивать ни на какую проблему, т.к. на нескольких миллионах юзеров и тысячах серверов любая редкая конфигурация или сбой обязательно повторятся. 0.01% в наших масштабах это несколько тысяч пострадавших, из которых в поддержку обратятся 5-10 человек, и вдвое больше начнут жаловаться в бложиках и на хабре.
Если состояние объекта предусмотрено бизнес-логикой, например например идет процесс регистрации из нескольких шагов и пользователь пытается на 2м шаге сделать действия доступные только после 3го, или просто тупо ввел рандомные данные с несуществующим идентификатором — то возвращать 400.
Если юзеру стал известен ID объекта, который физически не успел создаться и бизнес-логикой такого состояния не предусмотрено — то это рейс, который надо устранять.
Если это нормальная ситуация, например имеется очередь и пользователю не гарантируется немедленная реакция, то возвращать 200 и сообщение что попробуйте позже.
Если это race condition, то как раз в таких случаях правильно вернуть 500 и рассматривать именно как серверную ошибку, любые подобные рейсы требуют исправления.
Даже если проблема воспроизводима, то вот в этот момент:
" тим лид или тех лид ассайнит баг на разработчика"
проблема сводится к предыдущей. Если у вас можно заасайнить проблему на какого-то одного разработчика — это значит, что фактически он и занимается менеджментом. Если нельзя — то кто-то должен заниматься менеджментом проблемы. Это может быть и человек из QA с соответствующими полномочиями и компетенцией. В таком случае роль менеджера выполняет он.
Проблема может быть еще и невоспроизводимой в тестовых условиях. Например, по результатам разбирательств иногда выясняется, что проблема есть у пользователей зарегистрировавшихся более 7 лет назад, когда были другие требования к формату какого-либо поля, и есть символы которые невозможно получить в этом поле в текущей версии продукта.
Правильный ответ сервера в случае некорректных аргументов в запросе клиента, когда сервер корректно обнаруживает и обрабатывает такую ситуацию — 4xx. Вот она как раз допустима при редактировании URL.
500я ошибка это баг в любом случае, он означает, что сервер не готов к обработке какой-либо ситуации и ведет себя в ней некорректно, например возникает исключение в коде с непредсказуемыми последствиями.
Програмный RAID в любом случае будет не лучше аппаратного по производительности, но, справедливости ради, с RAID5 надо не забывать, что у него весьма ограниченная применимость. Часто его используют неправильно. Скорость записи с произвольным доступом на RAID5 ниже, чем скорость записи на отдельный диск. Т.е. он годится для редко перезаписываемых архивов, но не годится для рабочих наборов данных, где идут частые изменения, особенно небольшими порциями.
Рискну предположить, что Вы не очень много работали с аппаратным и программным RAID. На практике все обстоит с точностью до наоборот. Встроенные в чипсеты RAID полу-програмны и легко переносятся между платформами и операционными системами. В случае зеркала, как у автора, проблем вообще не возникает.
А вот как раз Microsoft'овский програмный RAID весьма капризен. Если случится перегрузить машинку reset'ом (что для домашнего сервера, согласитесь, не исключено), то с почти 100% долей вероятности пойдет процесс перестройки RAID'а, весьма неспешный на двухтерабайтных дисках, в течении процесса все тормозит и может отсутствовать отказоустойчивость. А есть шанс получить проблемы и похуже, особенно ребутнувшись несколько раз подряд.
Заметить проблемы с аппаратным RAID у необслуживаемой машины (а домашний сервер крайне редко кто-то обслуживает) достаточно просто — в момент перезагрузки BIOS будет подвисать и спрашивать что делать. С программным RAID вы легко можете пропустить момент выхода из строя одного из дисков и, не зная того, жить без отказоустойчивости. Ну и перенос данных под другую операционную систему не возможен без разбивания RAID.
Storage Spaces в Вашей конфигурации не требуются, т.к. диски одинакового размера — выгодней использовать аппаратный RAID или программный RAID на уровне раздела. Встроенный антивирус не будет проверять файлы при сетевом обращении к дискам, т.е. для сервера он бесполезен.
Да вообще вопросов очень много. Например, к чему делать Storage Spaces при наличии аппаратного RAID и двух одинаковых дисков. А если уже делать программный RAID, так можно было зазеркалировать отдельные разделы (например для семейных фотографий), а для фильмов оставить RAID 5. Хранить фильмы на зеркале — нет никакой надобности, двойная трата места. Для работы DLNA сам Mediaplayer через планировщик задач запускать не надо, надо поставить в автозапуск UPnP Device Host и Windows Media Player Sharing.
Представьте, что в какой-то момент вы видите запущенный xterm в котором bash с вашим стандартным юзернеймом в промте. Т.е. он выглядит как свежезапущенный xterm, имеет заголовок, как свежезапущенный xterm, пахнет свежезапущенным xterm. На ввод команды отвечает что надо сказать sudo. С какой долей вероятности вы скажете sudo и пароль в это окно? А на самом деле это окно чата.
То что окно чата не выглядит как окно чата — это секьюритная проблема, которая может привести к утечке данных. И я не уверен, что это единственная непродуманная вещь. Т.е. в любых вопросах связанных с безопасностью присоединюсь к противникам непродуманных наколенных решений, любое подобное решение может устранять параноидальную несущественную проблему, а приводить к вполне существенным.
Ну как же это не бывало, бывало. Сломать (сделать неюзабельным) можно почти всегда, а можно и что-то хуже. Например замечательный баг в Xfree86 с переполнением буфера через заголовок окна в сочетании с возможностью установить заголовок через ESC-последовательность в терминале становится чудесной дыркой с выполнением кода.
О том, что выводить себе в терминал нефильтрованные символы с удаленного конца это нехорошо для параноика, т.к. они могут содержать управляющие последовательности — не задумывались?
Судя по комментариям подвержен частично, т.к. для режима инкогнито используется отдельный кэш (net: split the SSL session cache between incognito and normal) хотя изначально патч предполагал полный отказ от идентификаторов сеанса (Incognito mode does not use TLS Session IDs at all — support for TLS Session Resumption is disabled completely). Причем до сих пор нет возможности сбросить кэш.
Есть еще один гораздо более близкий к кукам механизм, который активно используется трекерами типа TNS, но о котором почему-то мало бузят. Это TLS Session Ticket которые описаны в www.ietf.org/rfc/rfc5077 и поддерживаются и в Chrome и в Firefox. Суть весьма простая — фактически, это та же самая кука, но на уровне TLS, сервер скармливает любые данные и клиент их возвращает при следующем TLS-коннекте. Напишите статейку о нем, окружающим будет полезно знать.
Да, автор не видит разницы между генератором случайных чисел и генератором псевдослучайных чисел. Для псевдослучайного генератора вероятность получить какую-либо последовательность может быть нулевой. Причем в примере она таковой и является.
Но пример — баг стабильно воспроизводится у 0.01% пользователей. Процент пострадавших небольшой. Ситуация может быть невоспроизводимой или сложно диагностируемой: race condition, кратковременный сбой в каком-нибудь сервисе из-за которого когда-то (возможно даже и не сегодня) куда-то попали не те данные, редкая конфигурация или сочетание нескольких факторов, проблема в какой-то граничной ситуации, например когда одновременно ребутятся два разных сервиса и т.д. и т.п.
Маленький сервис такую проблему может в принципе никогда не поймать проблему или забить на нее, т.к. пострадавших пользователей единицы. Крупный сервис не может себе позволить забивать ни на какую проблему, т.к. на нескольких миллионах юзеров и тысячах серверов любая редкая конфигурация или сбой обязательно повторятся. 0.01% в наших масштабах это несколько тысяч пострадавших, из которых в поддержку обратятся 5-10 человек, и вдвое больше начнут жаловаться в бложиках и на хабре.
Если состояние объекта предусмотрено бизнес-логикой, например например идет процесс регистрации из нескольких шагов и пользователь пытается на 2м шаге сделать действия доступные только после 3го, или просто тупо ввел рандомные данные с несуществующим идентификатором — то возвращать 400.
Если юзеру стал известен ID объекта, который физически не успел создаться и бизнес-логикой такого состояния не предусмотрено — то это рейс, который надо устранять.
Если это race condition, то как раз в таких случаях правильно вернуть 500 и рассматривать именно как серверную ошибку, любые подобные рейсы требуют исправления.
" тим лид или тех лид ассайнит баг на разработчика"
проблема сводится к предыдущей. Если у вас можно заасайнить проблему на какого-то одного разработчика — это значит, что фактически он и занимается менеджментом. Если нельзя — то кто-то должен заниматься менеджментом проблемы. Это может быть и человек из QA с соответствующими полномочиями и компетенцией. В таком случае роль менеджера выполняет он.
Проблема может быть еще и невоспроизводимой в тестовых условиях. Например, по результатам разбирательств иногда выясняется, что проблема есть у пользователей зарегистрировавшихся более 7 лет назад, когда были другие требования к формату какого-либо поля, и есть символы которые невозможно получить в этом поле в текущей версии продукта.
500я ошибка это баг в любом случае, он означает, что сервер не готов к обработке какой-либо ситуации и ведет себя в ней некорректно, например возникает исключение в коде с непредсказуемыми последствиями.
А вот как раз Microsoft'овский програмный RAID весьма капризен. Если случится перегрузить машинку reset'ом (что для домашнего сервера, согласитесь, не исключено), то с почти 100% долей вероятности пойдет процесс перестройки RAID'а, весьма неспешный на двухтерабайтных дисках, в течении процесса все тормозит и может отсутствовать отказоустойчивость. А есть шанс получить проблемы и похуже, особенно ребутнувшись несколько раз подряд.
Заметить проблемы с аппаратным RAID у необслуживаемой машины (а домашний сервер крайне редко кто-то обслуживает) достаточно просто — в момент перезагрузки BIOS будет подвисать и спрашивать что делать. С программным RAID вы легко можете пропустить момент выхода из строя одного из дисков и, не зная того, жить без отказоустойчивости. Ну и перенос данных под другую операционную систему не возможен без разбивания RAID.
Одного не понимаю — почему не коту? Он склонен соглашаться.
, пахнет свежезапущенным xterm. На ввод команды отвечает что надо сказать sudo. С какой долей вероятности вы скажете sudo и пароль в это окно? А на самом деле это окно чата.То что окно чата не выглядит как окно чата — это секьюритная проблема, которая может привести к утечке данных. И я не уверен, что это единственная непродуманная вещь. Т.е. в любых вопросах связанных с безопасностью присоединюсь к противникам непродуманных наколенных решений, любое подобное решение может устранять параноидальную несущественную проблему, а приводить к вполне существенным.