Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
Расскажите про принцип fail fast в отношении операционной системы. Итак, у вас код операционной системы обнаружил, что драйвер звуковой карты на сервере некорректно заполнил структуру данных, отвечающих за обработку пятиканального звука при работе с bluetooth устройствами.
Ваши предложения?
Ваши предложения?
Цель вашего вопроса показать, что fail fast не применим в 100% случаев?
Ну так об это и в тексте написано. Никто не предлагает пихать fail fast без разбору везде.
Ну так об это и в тексте написано. Никто не предлагает пихать fail fast без разбору везде.
Ответ достаточно очевиден:
Выгрузить драйвер, написать в журанл об этом, сообщить пользователю что в драйвере произошла ошибка.
Если есть информацию о разработчиках драйвера — отослать им отчет об ошибке.
fail fast тут не применим, потому что задача fail fast обрабатывать ситуации нерпедсказуемые, а не полностью заменять обработку ошибок.
Выгрузить драйвер, написать в журанл об этом, сообщить пользователю что в драйвере произошла ошибка.
Если есть информацию о разработчиках драйвера — отослать им отчет об ошибке.
fail fast тут не применим, потому что задача fail fast обрабатывать ситуации нерпедсказуемые, а не полностью заменять обработку ошибок.
Ну так ведь смысл не в том, что ОС должна сразу упасть, а в том, что не должна пытаться эту неправильную структуру интерпретировать, при этом падать совсем не обязательно, как писали выше, достаточно выгрузить драйвер и честно сообщить об ошибке.
Я думаю, что Fail Fast должен работать на уровне независимых модулей. В данном случае на уровне драйвера.
Ну кроче применять этот принцип надо с умом.
Ну кроче применять этот принцип надо с умом.
Все принципы надо применять с умом. :)
В программировании подругому и не бывает.
В программировании подругому и не бывает.
Если еще точнее — граница применения fail fast ограничивается зоной затронутого операцией состояния (которое в результате неожиданной ошибки становится неопределённым — т.е., в частности, неизвестно, выполняются ли контрактные инварианты). В идеале, разумеется, для этого используются механизмы гарантированной изоляции изменений состояния — и это могут быть и грубые средства вроде процессов, и более легковесные альтернативы вроде дотнетовских аппдоменов, и языковые фичи типа монад или STM.
Fail Fast — не означает что нужно обязательно приложению падать. Речь о том, чтобы прервать выполнение текущей операции, чтобы избежать неопределенности ее дальнейшего выполнения. В реальности случаи, когда можно забыть о том, что произошла ошибка и исполнять код дальше — очень редки в софтверной индустрии. Хотя код такой пишут очень часто. Особенно грешат этим создатели автоматизированных скриптов. Поэтому можно более менее уверенно говорить что в общем Fail Fast это хорошо, а Forgive это плохо.
Хотя конечно есть исключения.
Что же касается того, нужно ли обрабатывать ошибки на местах — то есть нужно ли тратить ресурсы на обработку описанной вами ситуации — то совершенно другая тема. В целом главный вопрос в том — является ли ошибка внешней или внутренней по отношению к программе. Если она внешняя — значит это тоже часть интерфейса (возможного поведения) внешнего использованного сервиса (у вас драйвера) и нужно конечно ее обрабатывать и правильно на нее реагировать.
Хотя конечно есть исключения.
Что же касается того, нужно ли обрабатывать ошибки на местах — то есть нужно ли тратить ресурсы на обработку описанной вами ситуации — то совершенно другая тема. В целом главный вопрос в том — является ли ошибка внешней или внутренней по отношению к программе. Если она внешняя — значит это тоже часть интерфейса (возможного поведения) внешнего использованного сервиса (у вас драйвера) и нужно конечно ее обрабатывать и правильно на нее реагировать.
BSOD
Насколько я понимаю, именно так и появилась микроядерная архитектура :);
И где эта ваша микроядерная архитектура irl?
В QNX?
И где этот ваш qnx?
Я вижу обратное — практически всё сетевое оборудование и схд работают на базе freebsd, linux, вендоры автомобилей массово переползают на линукс.
Про то, как «вендоры автомобилей массово переползают на линукс» особенно хотелось бы ссылочку.
А вы дальше заголовка-то читали?
:D
...Linux will quickly grow to represent 20 percent of automotive computers by 2018, pulling closer to Microsoft behind industry-leading QNX.
Currently, BlackBerry’s QNX Software and Microsoft’s Windows Embedded Automotive together account for around 75 to 80 percent of the market, says ABI.
:D
Это я и называл «переползают». Кратковременный взлёт проприентарной системы перед тем, как люди уткнутся в проблему невозможности самим почесать себе чешущееся место. После чего приходят свободные системы.
Диванные аналитики такие диванные…
А вот что говорят реальные аналитики:
К тому же мы ушли от темы. Вы спрашивали «где этот вам QNX?», после чего сами же привели ссылку, которая гласит, что QNX и Microsoft владеют от 75% до 80% рынка автомобильных систем. Плюс к этому там утверждается, что года через 4 «Linux приблизится к Microsoft и будет иметь около 20%». То есть получается, что Microsoft имеет ненамного больше этого. То есть можно смело сделать вывод, что QNX владеет примерно половиной рынка автомобильных систем.
Полагаю, уже одно это отвечает на ваш вопрос «где этот ваш QNX».
“With the pace of change in automotive still being quite slow, the mid-term future for QNX still looks bright. Plus QNX has the important advantage of having a tried and tested optimized solution. Hence, QNX is still an attractive solution for a risk-averse automotive industry.”Что как бы слегка противоречит вашему «авторитетному» мнению по данному вопросу.
К тому же мы ушли от темы. Вы спрашивали «где этот вам QNX?», после чего сами же привели ссылку, которая гласит, что QNX и Microsoft владеют от 75% до 80% рынка автомобильных систем. Плюс к этому там утверждается, что года через 4 «Linux приблизится к Microsoft и будет иметь около 20%». То есть получается, что Microsoft имеет ненамного больше этого. То есть можно смело сделать вывод, что QNX владеет примерно половиной рынка автомобильных систем.
Полагаю, уже одно это отвечает на ваш вопрос «где этот ваш QNX».
Плюс к этому там утверждается, что года через 4 «Linux приблизится к Microsoft и будет иметь около 20%»
Google уже запустил Open Automotive Alliance, поэтому вслед за смартфонами и планшетами, Google выдавит Blackberry ещё с одного рынка. Засекайте, через 4 года QNX на фронтенде и мультимедийных системах в авто не будет, останется только в кишках. :)
Засекаю, мне не сложно. Google Calendar отлично работает для таких вещей :)
Очень уж люблю «аналитиков», которые увидев знакомые слова «Google» и «BlackBerry», моментально проецируют ситуацию на одном рынке на другой, несмотря на то, что между ситуациями различий куда больше, чем сходств.
Очень уж люблю «аналитиков», которые увидев знакомые слова «Google» и «BlackBerry», моментально проецируют ситуацию на одном рынке на другой, несмотря на то, что между ситуациями различий куда больше, чем сходств.
>>>Засекайте, через 4 года QNX на фронтенде и мультимедийных системах в авто не будет
Итак, прошло 4 года (без одного дня).
Mairon, не хотите признать, что были неправы? ;)
blogs.blackberry.com/2018/01/blackberry-qnx-at-ces-2018-featuring-safe-and-secure-foundational-software-for-the-automotive-future
AllexIn, отписываюсь, как обещал.
Итак, прошло 4 года (без одного дня).
Mairon, не хотите признать, что были неправы? ;)
blogs.blackberry.com/2018/01/blackberry-qnx-at-ces-2018-featuring-safe-and-secure-foundational-software-for-the-automotive-future
AllexIn, отписываюсь, как обещал.
ССыль залочена по решению роскомпозора. :(
Вкратце, если кто из России: на CES Blackberry выкатили версию QNX для демонстрации с Астон мартином и Ренджровером. Добавлены всякие фишечки, типа запуска Андроид приложений и использования в ситема автопилота.
Хренасе события развиваются в «великой и могучей»… о_О
Чем им BlackBerry-то «икстримизьмом» запахло?
(кликабельно)
Чем им BlackBerry-то «икстримизьмом» запахло?
(кликабельно)
Цитата из ru.wikipedia.org/wiki/QNX:
Ещё вопросы :)?
На март 2009 года решения на базе QNX лицензированы для использования на более, чем 10,1 миллионах единиц техники от практически всех ведущих производителей автомобилей, включая BMW, Chrysler, Daimler, Fiat, Ford, General Motors, Honda, Hyundai, Mazda, Mitsubishi, Nissan, Saab, SsangYong, Toyota и Volkswagen. В частности, такие автомобили выпускаются под марками Acura, Alfa Romeo, Audi, Buick, Cadillac, Chevrolet, Dodge, Honda, Hummer, Infiniti, Jeep, Lancia, Mini, Mercedes, Opel, Pontiac, Saturn и другими.
Ещё вопросы :)?
Итого, 10 миллионов единиц техники. Сколько у нас автомобилей с компьютерами продаётся ежегодно? Гугление, вроде бы, показывает около 80 миллионов. Допустим, средний срок эксплуатации 5 лет. Итого — 400 к 10. 2.5% рынка. Круто!
10 миллионов — это кагбэ только в 2009-м году. Список кагбэ растет и ширится. Например, Ford drops Microsoft, will use BlackBerry’s real-time OS for next Sync. Даже эппловский iCar под капотом имеет QNX.
А вообще вы очень удобно из 30 пунктов выбрали несколько штук, снабдили это «авторитетным» источником «Я вижу обратное» и почему-то уверены, что у вас получилось весомое возражение. Жжоте, однако :D
А вообще вы очень удобно из 30 пунктов выбрали несколько штук, снабдили это «авторитетным» источником «Я вижу обратное» и почему-то уверены, что у вас получилось весомое возражение. Жжоте, однако :D
«Я вижу» — это Juniper, разумеется. И остальной коммутационно-схдшный бизнес.
А цифру «10 миллионов» привёл не я. Даже если предположить, что это «10 миллионов в год», то это всего лишь 12.5% машин в год.
А цифру «10 миллионов» привёл не я. Даже если предположить, что это «10 миллионов в год», то это всего лишь 12.5% машин в год.
См. выше. Вы сами же и привели отличную ссылку :)
Как разработчик я, может быть и одобряю Fail Fast, но как пользователь — ненавижу. Потому что в 999 случаях из 1000 у пользователя нет возможности дождаться исправления ошибки программистом в адекватное время, а результат работы программы нужен здесь и сейчас, пусть и с ошибкой, которую пользователь может попытаться исправить самостоятельно.
Тут есть нюанс.
Под виндой, особенно раньше, не было никакого смысла в релиз ПО с fail fast. Потому что без поддержки отчетов об ошибках отсылаемых разработчикам нет никакого смысла от того, что программа на стороне пользователя упала.
Но сейчас ситуация иная.
Есть множество инструментов, которые автоматизируют обработку ошибок на Windows и можно быть уверенным, что падение не будет бесполезным.
На Андроиде так вообще уже встроенная система отчетов используется.
Ну и исправление ошибки пользователем очень уж специфичная вещь не так уж часто встречается, чтобы при разработке на этот момент обращать внимание.
Под виндой, особенно раньше, не было никакого смысла в релиз ПО с fail fast. Потому что без поддержки отчетов об ошибках отсылаемых разработчикам нет никакого смысла от того, что программа на стороне пользователя упала.
Но сейчас ситуация иная.
Есть множество инструментов, которые автоматизируют обработку ошибок на Windows и можно быть уверенным, что падение не будет бесполезным.
На Андроиде так вообще уже встроенная система отчетов используется.
Ну и исправление ошибки пользователем очень уж специфичная вещь не так уж часто встречается, чтобы при разработке на этот момент обращать внимание.
Исключения — наши друзья )
После того как написал текст про исключения мне были представлены два факта:
1) Текст получился сумбурным
2) Я описал Fail fast! подход.
Хорошенько разобравшись в ситуации понял, что лучше мне не пытаться рассказывать об этом самостоятельно, а перевести уже существующую статью. Тем более что на русском материалов на эту тему парктически нет.
1) Текст получился сумбурным
2) Я описал Fail fast! подход.
Хорошенько разобравшись в ситуации понял, что лучше мне не пытаться рассказывать об этом самостоятельно, а перевести уже существующую статью. Тем более что на русском материалов на эту тему парктически нет.
>> Делаем вывод: подход Forgive! работает плохо!
Я сделал только один вывод: автор склонен предоставлять примеры однобоко, дабы поспешные выводы из них не противоречили сути статьи.
Существует бесчисленное множество примеров когда Forgive спасало жизнь (например полёт Гагарина). Также немало примеров когда Fail fast позволило предотвратить катастрофические ситуации и тоже спасало жизнь.
Поэтому говорить, что подход X нужно чаще использовать нельзя.
Единственное за что нужно агитировать, чтобы разработчики чаще включали мозг.
Я сделал только один вывод: автор склонен предоставлять примеры однобоко, дабы поспешные выводы из них не противоречили сути статьи.
Существует бесчисленное множество примеров когда Forgive спасало жизнь (например полёт Гагарина). Также немало примеров когда Fail fast позволило предотвратить катастрофические ситуации и тоже спасало жизнь.
Поэтому говорить, что подход X нужно чаще использовать нельзя.
Единственное за что нужно агитировать, чтобы разработчики чаще включали мозг.
До конца не читал, зато коммент написал?
Пример про Гагарина — один в один пример про ракету на Марсе из статьи. Где как раз и говорится, что в этой ситуации надо использовать Forgive.
Действительно создается ощущение что статьюв ы не дочитали.
Действительно создается ощущение что статьюв ы не дочитали.
Не знаю как там у Гагарина или где то еще в космосе.
Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко. Это практически всегда специфика предметной области. Типичная ошибка в программе как правильно приводит к неопределенному поведению, которое дальше уже нельзя контролировать. А значит нужно остановить.
Исключения в прикладной софтверной индустрии не часты. Поэтому мы и можем сказать что хорошо, а что плохо.
А то, что принцип Fast Fail по ошибке воспринимают как необходимость «уронить» все приложение — это отдельная песня.
Что касается вашей последней фразы — знаете — знания и практические шаблоны как раз и создают для того, чтобы не включать мозг. Потому что его можно задействовать где то еще — не задумываясь над каждой строчкой — нужно ли тут применять Forgive. А вместо этого уделив больше внимания чему нибудь другому на проекте на каком нибудь более высоком уровне абстракции.
Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко. Это практически всегда специфика предметной области. Типичная ошибка в программе как правильно приводит к неопределенному поведению, которое дальше уже нельзя контролировать. А значит нужно остановить.
Исключения в прикладной софтверной индустрии не часты. Поэтому мы и можем сказать что хорошо, а что плохо.
А то, что принцип Fast Fail по ошибке воспринимают как необходимость «уронить» все приложение — это отдельная песня.
Что касается вашей последней фразы — знаете — знания и практические шаблоны как раз и создают для того, чтобы не включать мозг. Потому что его можно задействовать где то еще — не задумываясь над каждой строчкой — нужно ли тут применять Forgive. А вместо этого уделив больше внимания чему нибудь другому на проекте на каком нибудь более высоком уровне абстракции.
У нас с вами противоречие в терминологии, что делает бесполезным всю дальнейшую дисскусию.
Вот например:
>> Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко.
Да, ладно, весь веб на динамических языках(PHP, JS, Python, Ruby) + HTML + CSS — это один большой Forgive.
В оконном софте неработоспособность одной фичи — не значит, что нужно убивать приложение.
А вот в любом потоковом процессе, где нас интересует или конечный результат или отсутствие деструктивных действий, там нужен Fail fast (банковские транзакции, кодирование/декодирование). И вот, на мой взгляд, софт обычно включает такие процессы а не полностью состоит из них.
С большой печалью прочитал ваш последний абзац. Не согласен:
* Знания не создают, а накапливают, приобретают
* Шаблоны создают для стандартизации подходов, что приводит к лучшей передачи знаний. Да, шаблон напоминает тебе о чём нужно не забыть подумать, но это скорее побочный эффект. Да и далеко не все ньансы этим описываются. Кроме того теперь нужно ломать голову над тем, какой шаблон выбрать.
* Ну и мозг это не 100 минералов. Типа сэкономили в одном месте и можем лучше подумать в другом. Можно задумываться над всеми ньансами софта. И чем больше мы будем думать и чем меньше мы напишем кода, тем будет лучше.
Вот например:
>> Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко.
Да, ладно, весь веб на динамических языках(PHP, JS, Python, Ruby) + HTML + CSS — это один большой Forgive.
В оконном софте неработоспособность одной фичи — не значит, что нужно убивать приложение.
А вот в любом потоковом процессе, где нас интересует или конечный результат или отсутствие деструктивных действий, там нужен Fail fast (банковские транзакции, кодирование/декодирование). И вот, на мой взгляд, софт обычно включает такие процессы а не полностью состоит из них.
С большой печалью прочитал ваш последний абзац. Не согласен:
* Знания не создают, а накапливают, приобретают
* Шаблоны создают для стандартизации подходов, что приводит к лучшей передачи знаний. Да, шаблон напоминает тебе о чём нужно не забыть подумать, но это скорее побочный эффект. Да и далеко не все ньансы этим описываются. Кроме того теперь нужно ломать голову над тем, какой шаблон выбрать.
* Ну и мозг это не 100 минералов. Типа сэкономили в одном месте и можем лучше подумать в другом. Можно задумываться над всеми ньансами софта. И чем больше мы будем думать и чем меньше мы напишем кода, тем будет лучше.
Не вижу никакого противоречия в терминологии. Что вы имеете ввиду?
Вы правы — в вебе часто работает Forgive — а вот хорошо это или плохо — вопрос хороший. Лично я считаю, что например в случае с HTML — это просто наследие, от которого мы не можем отказаться из-за уже созданных приложений. Для меня было бы сказкой — если бы разметка «падала» в случае поломки — тогда не понадобилось бы затрачивать такие усилия по определению UI проблемы в авто тестах на UI. Вообще дополнительные валидации динамического кода на статическую корректность — это необходимость.
В большинстве динамических языков (PHP, Javascript и т.д.) есть исключения останавливающие выполнение работы программы. И если они применяются для разработки интерпрайз решений — то уход от Forgive подхода — обычно необходимый и правильный шаг.
В оконном софте тоже есть поведение верно? И там тоже есть операции которые подразумевают какой то результат. Вот как раз Fast Fail и подразумевает что операция не будет завершена если произошло исключение. Я еще раз повторю — что это не значит что нужно убивать приложение. Забудьте уже про этот стереотип. Но обработка ошибок тут будет комплексная на уровне приложения, а не локализованная. Можно сделать так, что этом внешне это не затронет других фич. Это не проблема.
Софт конечно не состоит полностью из процессов — вы правы. Он состоит из процессов (поведения) и деклараций (UI например) - это просто модель :). Поведение обычно занимает значимую часть бизнеса приложение — чаще всего большую часть. Вышеописанные подходы актуальны прежде всего для поведения. Ваш пример про банки — это транзакции. Это не то же самое о чем говорю я. Транзакции подразумевают возможность отката. Тут же откат не нужен. Мы просто избегаем некотролируемого поведения вот и все. Не только в данной операции, но и во всех дальнейших, которые от нее могут так или иначе зависеть.
Fast Fail для интерпрайз решений — это настоящая best practic — он позволяет избежать рисков на продакшене и выявлять и фиксать проблемы быстрее. Чаще всего прежде чем это попадет к пользователю. Потому что чем позже выявляется дефект — тем он дороже.
Но я допускаю, что в наколеночных поделках это может быть не так важно.
Вы правы — в вебе часто работает Forgive — а вот хорошо это или плохо — вопрос хороший. Лично я считаю, что например в случае с HTML — это просто наследие, от которого мы не можем отказаться из-за уже созданных приложений. Для меня было бы сказкой — если бы разметка «падала» в случае поломки — тогда не понадобилось бы затрачивать такие усилия по определению UI проблемы в авто тестах на UI. Вообще дополнительные валидации динамического кода на статическую корректность — это необходимость.
В большинстве динамических языков (PHP, Javascript и т.д.) есть исключения останавливающие выполнение работы программы. И если они применяются для разработки интерпрайз решений — то уход от Forgive подхода — обычно необходимый и правильный шаг.
В оконном софте тоже есть поведение верно? И там тоже есть операции которые подразумевают какой то результат. Вот как раз Fast Fail и подразумевает что операция не будет завершена если произошло исключение. Я еще раз повторю — что это не значит что нужно убивать приложение. Забудьте уже про этот стереотип. Но обработка ошибок тут будет комплексная на уровне приложения, а не локализованная. Можно сделать так, что этом внешне это не затронет других фич. Это не проблема.
Софт конечно не состоит полностью из процессов — вы правы. Он состоит из процессов (поведения) и деклараций (UI например) - это просто модель :). Поведение обычно занимает значимую часть бизнеса приложение — чаще всего большую часть. Вышеописанные подходы актуальны прежде всего для поведения. Ваш пример про банки — это транзакции. Это не то же самое о чем говорю я. Транзакции подразумевают возможность отката. Тут же откат не нужен. Мы просто избегаем некотролируемого поведения вот и все. Не только в данной операции, но и во всех дальнейших, которые от нее могут так или иначе зависеть.
Fast Fail для интерпрайз решений — это настоящая best practic — он позволяет избежать рисков на продакшене и выявлять и фиксать проблемы быстрее. Чаще всего прежде чем это попадет к пользователю. Потому что чем позже выявляется дефект — тем он дороже.
Но я допускаю, что в наколеночных поделках это может быть не так важно.
Позвольте предложить довольно частый пример: если приложение содержит GUI и в нем присутствуют чисто отображающие (read-only) элементы, то невозможность работы одного или нескольких таких элементов не должна влиять на логику работы приложения. В идеале, падение кода одной картинки на экране должно приводить программу либо к игнорированию (с отправкой отчёта разработчикам), либо к перезапуску этого элемента.
При этом учитывая, что зачастую отображающие элементы имеют очень и очень сложное внутреннее устройство, вариант fail-fast для них плох — он дестабилизирует систему в целом.
При этом учитывая, что зачастую отображающие элементы имеют очень и очень сложное внутреннее устройство, вариант fail-fast для них плох — он дестабилизирует систему в целом.
Вы можете гарантировать что ваш «GIU элемент» в процессе краша не влез в память где хранится переменная с номером счета клиента и в итоге не привел к отправке денег к черту на куличики?
Если уверены то да, не надо падаться, надо обрабатывать и продолжать работу.
Если уверены то да, не надо падаться, надо обрабатывать и продолжать работу.
Прикол в том, что если обрабатывать все возможные проблемы всех элементов — то вам придется затратить куда больше ресурсов на реализацию. Это часто бывает очень не дешевым решением. И к тому же эти ресурсы трудно спрогнозировать. Да еще очень легко забыть что нибудь обработать. Потому что все возможные варианты крешей вы все равно не придумаете.
Простите, не уточнил — пишу на Java, где проблемы с памятью исключены, стремлюсь к полной инкапсуляции, то есть влияние одного объекта на другой исключено, если они не связаны функционально
Сам по себе подход Fast Fail и требование к «мягкому» поведению юая в случае падений вполне могут сосуществовать вместе. Они пересекаются постольку поскольку это является следствием особенностей архитектуры системы. Если она достаточно модульна — то использование Fast Fail не вызовет проблем. Иначе — ее можно улучшить.
Например у меня был как то проект новостного сайта — там было требование в случае падений каких то элементов на странице (серверные контролы) они должны просто пропадать с экрана не меняя или ломая верстку и сайт в целом. Решилось это простым наследованием всех контролов от от одного базового класса с обработкой ошибок и базовыми клиентскими механизмами. Конечно при этом легко было включить Fast Fail на девелоперском и тестовом окружении. И отключить его (включив обработку ошибок) на продакшене. То есть мы могли вылавливать ошибки рано и при этом выполнять требования бизнеса по стабильности на настоящем развернутом сайте.
Цена вопроса — несколько десяток строк кода и пару часов работы.
Конечно конкретное решение в каждом случае будет зависеть от архитектуры конкретно вашей системы.
Но общий подход к решению описанной вами проблемы такой: выделить модули (например ваши сложные видимо жаваскриптовые элементы) и внедрить комплексную обработку падений для всех таких модулей. Которую вы можете сконфигурировать на Fast Fail при девелопменте и определить более сложное поведение на другом окружении.
Однако это ваше специальное поведене в случае падений элементов нужно конечно тестировать отдельно — так как это тоже часть бизнеса.
Например у меня был как то проект новостного сайта — там было требование в случае падений каких то элементов на странице (серверные контролы) они должны просто пропадать с экрана не меняя или ломая верстку и сайт в целом. Решилось это простым наследованием всех контролов от от одного базового класса с обработкой ошибок и базовыми клиентскими механизмами. Конечно при этом легко было включить Fast Fail на девелоперском и тестовом окружении. И отключить его (включив обработку ошибок) на продакшене. То есть мы могли вылавливать ошибки рано и при этом выполнять требования бизнеса по стабильности на настоящем развернутом сайте.
Цена вопроса — несколько десяток строк кода и пару часов работы.
Конечно конкретное решение в каждом случае будет зависеть от архитектуры конкретно вашей системы.
Но общий подход к решению описанной вами проблемы такой: выделить модули (например ваши сложные видимо жаваскриптовые элементы) и внедрить комплексную обработку падений для всех таких модулей. Которую вы можете сконфигурировать на Fast Fail при девелопменте и определить более сложное поведение на другом окружении.
Однако это ваше специальное поведене в случае падений элементов нужно конечно тестировать отдельно — так как это тоже часть бизнеса.
Я в своих разработках придерживаюсь сбалансированного подхода. Если программа видит ошибку, которую возможно обработать без нарушения основных функций программы, и усложнение программы внедрением в нее обработчика оправдано — то обрабатываю. Во всех остальных случаях «падает» соответствующий уровень приложения. То есть прекращается выполнение запрошенной пользователем команды, освобождаются все связанные с этим ресурсы и выводится содержательное сообщение об ошибке. При этом все приложение не вылетает, оставляя пользователю возможность сделать повторную попытку или запросить какую-то другую функцию. Все приложение вылетает только, если на более высоком уровне обнаружена неисправимая ошибка.
А как связаны «информирование разработчика об исключительной ситуации» с «восстановлением после сбоя»? Это перпендикулярные понятия. Ничто не мешает показывать разработчику ошибку большими красными буквами, отсылать ему отчеты и тп, при этом сохраняя потребительские свойства насколько возможно. В примере с фонтаном в случае с быстрым падением предупреждающего сообщения вообще выведено не будет. Это сильно лучше, чем очевидно некорректное «Осторожно! Пожалуйста, пейте воду из фонтана»? Предупреждение с непонятным текстом как минимум насторожит. Отсутствие предупреждения — нет.
Вот за что я не люблю эти «постулаты» так это за то, что они решают одни проблемы за счет других. В результате оказывается, что все приложение оказывается неработоспособным из-за маленькой никому не нужной кнопочки в углу экрана. И самое печальное, что я так и не смог убедить «ведущего разработчика», что это не правильно, ибо «fail fast — best practice».
Вот за что я не люблю эти «постулаты» так это за то, что они решают одни проблемы за счет других. В результате оказывается, что все приложение оказывается неработоспособным из-за маленькой никому не нужной кнопочки в углу экрана. И самое печальное, что я так и не смог убедить «ведущего разработчика», что это не правильно, ибо «fail fast — best practice».
Проблема с forgive не только и не столько в отсутствии диагностики, сколько в безопасности и надёжности софта. Например, если ваше приложение — это редактор, и при неожиданной ошибке вы будете пытаться сохранять работоспособность максимально долго, вы вполне можете дать пользователю уникальный шанс затереть редактируемый документ мусором, сохранив текущее «сломанное» (т.е. с нарушенными инвариантами) состояние вашей модели. А если это браузер, то forgive легко и непринуждённо может превратить одну маленькую дыру в безопасности в много больших…
В нашем приложении мы используем следующий подход. При возникновении ошибки, высылается мейл админу с описанием ошибки, а пользователь получает сообщение «System busy, please try again later.». Пользователь не пугается и думает, что система работает как надо, просто в данный момент перегружена. А мы тем временем судорожно исправляем все ошибки :-)
Может быть я не правильно перевел?
Design by contract (TM) (also called Contract Programming) is another example of a Fail fast! feature. This is because invalid values for input/output arguments and object attributes are immediately detected and raise a program error at runtime.
There are many more Fail fast! features that can be built into a programming language.
А кстати, почему бы не продавать пользователям отдельно версию кода с Fail Fast за полцены? В итоге, кого бесят сообщения об ошибках и все эти «отправить репорт разработчикам?» — купят полную версию, желающие сэкономить — купят Fail Fast и будут репортить баги. Потока информации от второй группы будет достаточно, чтобы поддерживать в хорошем состоянии проект для всех.
ОБТ же и «Ранний доступ». Это в сфере игр. В сфере прикладного ПО не знаю, но уверен там есть аналогичные подходы.
Эм, ОБТ и «Ранний доступ» — это отнюдь не «Fail Fast» за полцены. ОБТ — это, вообще, о другом. ЗБТ и предшествующие тесты — это проверка различных гипотез (технических, игровых, прочих) на лояльных игроках, но при этом неразработчиках.
На счет игр. На стадии разработки: игровой сервер и игровой клиент должны быть максимально живучими, независимо от стадии готовности. Т.к. над их созданием трудится очень много людей.
В жизни сервер, например, имеет право упасть только во время старта — инициализации баз и прочее. Как только на сервер пошли игроки, он должен держаться до последнего (в рамках разумного).
На счет игр. На стадии разработки: игровой сервер и игровой клиент должны быть максимально живучими, независимо от стадии готовности. Т.к. над их созданием трудится очень много людей.
В жизни сервер, например, имеет право упасть только во время старта — инициализации баз и прочее. Как только на сервер пошли игроки, он должен держаться до последнего (в рамках разумного).
ОБТ — это, вообще, о другом.
О чем?
ЗБТ и предшествующие тесты
Про ЗБТ ничего не говорил.
ОБТ и «Ранний доступ» — это отнюдь не «Fail Fast» за полцены.
Что же это, как не продажа за полцены забагованного приложения?
В жизни сервер, например, имеет право упасть только во время старта
В идеальном мире.
Вспомните сколько раз падали сервера Diablo 3 за время с его старта.
ОБТ для игр — это, фактически, релиз. В ОБТ игровые проекты живут достаточно долго — годами. Warface в ОБТ уже два года, и ничего :) Так что, приставка «ОБТ» — это отнюдь не повод серверам или клиентам падать.
Насчёт падения сервера — речь шла о Fail first. Что на момент инициализации — Fail first, дальше — Forgive, пока возможно. От ОБТ, «полцены» или «забагованного приложения» это не зависит. Это просто подход к проектированию сервера игр.
Насчет Diablo 3 ничего сказать не могу, у меня нет данных о том, что сервера падали. Были недоступны — это да, падали — не факт. Возможно, разработчики Diablo не предусмотрели механизм, позволяющий дать доступ ограниченному количеству пользователей с достойным UX, и решили объявить профилактику. Или, наоборот, закрыли доступ, чтобы хотя бы часть игроков смогла играть нормально. В любом случае, это не было «Fail Fast» за полцены, о котором говорил tangro. Т.к. альтернативы доплатить и поиграть нормально не было.
Насчёт падения сервера — речь шла о Fail first. Что на момент инициализации — Fail first, дальше — Forgive, пока возможно. От ОБТ, «полцены» или «забагованного приложения» это не зависит. Это просто подход к проектированию сервера игр.
Насчет Diablo 3 ничего сказать не могу, у меня нет данных о том, что сервера падали. Были недоступны — это да, падали — не факт. Возможно, разработчики Diablo не предусмотрели механизм, позволяющий дать доступ ограниченному количеству пользователей с достойным UX, и решили объявить профилактику. Или, наоборот, закрыли доступ, чтобы хотя бы часть игроков смогла играть нормально. В любом случае, это не было «Fail Fast» за полцены, о котором говорил tangro. Т.к. альтернативы доплатить и поиграть нормально не было.
Я правильно понял, что все эти много букв можно сократить до «используйте assert() или аналогичную конструкцию»? :)
> Почини когда можешь — но когда ты должен упасть, падай тихо и как можно скорее.
Оригинал: Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
Правильный перевод «падай громко», и по логике это правильно, так как надо сообщить о проблеме
Оригинал: Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
Правильный перевод «падай громко», и по логике это правильно, так как надо сообщить о проблеме
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО