Fail Fast vs. Robustness

Question

Наш продукт является распределенной системой. Модули, над которыми я работаю, довольно новые, довольно строгие, хорошо протестированные. Они были разработаны с учетом последних лучших практик. Другие модули могут рассматриваться как устаревшее программное обеспечение.

Хотя я бдительно отношусь ко всему, что происходит внутри модулей, за которые я отвечаю, я постоянно вынужден работать с плохими данными, отправленными мне из других модулей. По сути, я разработчик принципа «Fail Fast», и в результате, когда возникают проблемы, я обычно могу исключить возможность ошибки в моих модулях. Речь идет не столько о вине, сколько о том, что мы тратим впустую усилия на поиск ошибок в неправильных местах.

Но аргумент, который я продолжаю выдвигать, звучит так: «Мы не можем допустить, чтобы этот материал потерпел неудачу в производстве, клиент ожидает, что это сработает, почему бы вам не обойти эту проблему». И это будет аргументом в пользу надежности: будьте либеральными в том, что вы принимаете, консервативными в том, что вы посылаете.

Я должен также отметить, что это в основном периодические проблемы. Мы видим их в интеграционных тестах, но их сложно воспроизвести. Сроки и параллелизм участвуют.

Мне трудно балансировать между двумя принципами. Отчасти это мое беспокойство, что если я начну разрешать и распространять исключительные данные, я буду предупреждать о проблемах, и у меня не будет такого большого доверия к моей системе. Но я не могу поспорить против сохранения работоспособности системы, даже если другие модули посылают мне неверные данные. Причина, по которой другие модули не исправляются, заключается в том, что они слишком сложны и хрупки, а мои все еще выглядят чистыми и безопасными. Но если я не выдержу давления, мои модули будут медленно обременены теми же проблемами, которые я отвергал до сих пор.

Я должен сказать, что система не "сбоит" в работе, но мой модуль может просто показать оператору ошибку и попросить его связаться со службой поддержки. Авария была бы большой проблемой, но если я четко сообщаю об ошибке, разве это не правильно? Я подозреваю, что мои коллеги просто не хотят, чтобы клиент видел какие-либо проблемы, точка. Но мой модуль отклоняет данные от других модулей нашего продукта, а не от клиентов. Поэтому мне кажется, что мы просто не решаем проблемы.

Итак, мне нужно быть более прагматичным или сохранять свою позицию?

Answer 1

Я разделяю принцип «быстро проваливаюсь». Не думайте об этом как о конфликте принципов, это скорее конфликт понимания. У вашего партнера есть негласное требование («не показывать пользователю плохое время»), которое подразумевает некоторое пропущенное требование. У вас не было возможности заранее продумать / выполнить это требование, поэтому оно оставило неприятный вкус во рту. Забудьте эту точку зрения, измените ее как новый проект с фиксированным требованием, с которым вы можете работать.

Возможно, лучшим результатом будет сообщение об ошибке, подобное тому, которое вы отображали. Но, похоже, вы реализовали это до того, как у вас был бай-ин от вашего партнера, когда у них был выбор принять его. Более раннее сообщение о том, что вы делали, могло касаться чего-то подобного.

Будьте осторожны в том, как вы предотвращаете идеи. Постоянное обращение к другим системам, «слишком сложным и хрупким», может привести к неправильному истиранию людей. Проще говоря, системы являются новыми для вас и требуют больше времени для понимания. Уделите время их пониманию, чтобы не снизить ожидания людей в отношении ваших возможностей.

Answer 2

Я бы сказал, что это зависит от того, что произойдет, если вы не остановитесь. Чья-то зарплата обрабатывается неправильно? Неправильный ли заказ отправлен? Это стоило бы остановиться.

Если возможно, принесите свой пирог и съешьте его - не сообщайте об ошибке пользователю, попросите клиента согласиться отправлять диагностические отчеты и сообщать о каждой неудаче обратно. Ошибка разработчика (ов), которые владеют неисправными модулями, чтобы исправить их. И под ошибкой я подразумеваю подать ошибку против них. Или, если руководство не считает, что это стоит затрат на исправление, не стоит.

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

В действительности все сводится к тому, чего хочет от вас человек, который проверяет ваши результаты, особенно после того, как вы объясните им проблему по электронной почте.

Answer 3

Я не буду вдаваться в причины, но вы правы.

По моему опыту, PHB не хватает той части мозга, которая необходима для понимания того, почему быстрый сбой имеет свои достоинства и «надежность», как это определено в «сделай все, что нужно, есть ошибки, если это необходимо» - плохая идея. Это безнадежно. У них просто нет оборудования, чтобы справиться с этим. Они, как правило, говорят «хорошо, вы делаете хорошую точку зрения, но как насчет пользователя» - это просто их версия «Думайте о детях» , и она сигнализирует об окончании конвертации со мной в любое время, когда это происходит.

Мой совет - постоять за себя. Вечно.

Answer 4

Проще говоря, это звучит как "не проверяйте то, с чем вы не можете справиться". Тот факт, что вы ловите ошибку и можете сообщить о ней, означает, что вы не распространяете ее. Но это также означает, что, поскольку вы можете сообщить об этом, у вас есть некоторый механизм, чтобы перехватить ошибку и, следовательно, потенциально обработать ее самостоятельно и исправить, а не сообщать об этом.

Имейте в виду, я предполагаю, что ваш отчет об ошибке интереснее случайного исключения, которое вы обнаружили в глубине системы. Но даже тогда, если вы проверяете это исключение и создаете его (т. Е. Вы проверяете, равен ли знаменатель нулю, и отправляете ошибку, а не просто ненамеренно делите на ноль и перехватываете исключение выше), это говорит о том, что вполне может иметь способ исправить проблему.

Итог, вам нужны оба. Вы должны попытаться сделать данные как можно более свободными от ошибок, а также сообщить о непредвиденных обстоятельствах.

Я не думаю, что вы можете запереть дверь и скрестить руки, говоря: "Это не моя проблема". Тот факт, что это происходит из «старых, хрупких систем», не имеет смысла. ВАШ код не является хрупким и явно эффективным местом, с точки зрения всей интегрированной системы, для «исправления» данных, как только вы обнаружили проблему. Да, старые модули будут продолжать GIGO для других, более мелких систем, но эти устаревшие модули, объединенные с вашим новым модулем, представляют собой единое целое и, следовательно, составляют «систему».

Типичная реальная проблема здесь - просто уравнение времени / значения написания всего этого кода исправления против новых функций. Это другая дискуссия. Но если у вас есть время и вы знаете, что вы можете сделать для очистки входящих данных, «быть либеральным в том, что вы принимаете», - это разумная политика.

Answer 5

Спасибо всем. Случай, который вызвал этот вопрос, закончился хорошо, и отчасти благодаря выводам, которые я получил из ответов выше.

Моей первоначальной реакцией было быстрое падение, но я подумал об этом еще немного и пришел к выводу, что одна из функций моего модуля заключается в обеспечении стабилизирующего якоря для остальной системы. Это не обязательно означает принятие неверных данных, но выявление проблем, их изоляцию и прозрачную обработку до тех пор, пока мы не найдем решение.

Я планировал добавить новый обработчик и путь к коду для этого случая, который бы правильно выполнялся, как если бы это был особый вариант использования, который ранее не имел документов.

У нас была дискуссия, в которой я повторял необходимость решения проблемы на границе, но также был готов помочь. Я изложил свой план другой стороне, потому что у меня было подозрение, что моя позиция была расценена как чрезмерно педантичная, и что решение было воспринято как то, что мне нужно было только отключить ложную проверку безвредных данных, даже если они были неверными. В действительности, однако, мой способ работы в значительной степени зависит от данных, поэтому я объяснил, почему он должен быть правильным, и как он управляет поведением, и как при размещении этих данных я буду реализовывать специальный путь кода.

Я думаю, что это придало вес моей позиции и привело к более тщательному обсуждению отвращения другой стороны к исправлению данных. Выяснилось, что справляться с устаревшей системой, подверженной ошибкам, было скорее утомлением, чем реальным препятствием. Было относительно простое решение, было просто страшно внести изменения, образ мышления довольно укоренился.

Но, сообщив о всех проблемах и возможных решениях, мы в конце концов согласились исправить данные, и пока, похоже, они решили нашу проблему. Наши интеграционные тесты в настоящее время проходят последовательно, но мы также добавили протоколирование и продолжим его отслеживать.

Таким образом, я думаю, что для меня синтез обоих принципов заключается в том, что быстрый провал необходим для решения проблем. Но как только они выходят на поверхность, надежность означает обеспечение прозрачного пути для продолжения работы таким образом, который не ставит под угрозу систему. Я смог это предложить, и благодаря этому добился некоторой доброй воли с другой стороны и в конце исправил данные.

Опять же, спасибо всем, кто ответил. Я слишком новичок, чтобы оценивать комментарии, но я ценю все представленные перспективы.

Answer 6

Вопрос от ваших коллег: «Почему бы вам не обойти эту проблему»

Вы говорите, что вы можете обнаружить неверные данные и сообщить об ошибке пользователю. Это нормальный подход - если вы знаете, что данные, поступающие в ваши функции, являются плохими, вы должны быстро потерпеть неудачу (и это рекомендация из других ответов, которые я прочитал здесь).

Однако в вашем вопросе не указан домен, в котором работает ваше программное обеспечение. Если вы знаете, что поступающие данные ошибочны, можете ли вы запросить эти данные еще раз? Реально ли выйти из ситуации?

Я упомянул, что «домен» здесь важен. Так что, если у вас есть приложение, которое отображает потоковые видеоданные, например, и, возможно, ваш беспроводной сигнал слабый, поэтому поток поврежден, должна ли система «быстро отказывать» и отображать сообщение об ошибке? Или должно отображаться более плохое изображение, и при необходимости предпринимается попытка переподключения, в зависимости от масштабов проблемы?

В зависимости от вашего домена, вы можете обнаружить неверные данные и сделать второй запрос данных, не причиняя неудобства пользователю. (Это очевидно только в тех случаях, когда вы ожидаете, что данные будут лучше во второй раз, но вы говорите, что проблемы, с которыми вы сталкиваетесь, периодически и могут быть связаны с параллелизмом) ...

Итак, быстрый отказ - это хорошо, и это определенно то, что вы должны сделать, если не можете восстановиться. И вы определенно не должны распространять плохие данные. Но если вы можете восстановить то, что в некоторых доменах вы можете, то сразу же произойдет сбой не обязательно.

Answer 7

Это зависит от класса ошибки, которую вы получаете. Если то, как система ломается, означает, что вы можете продолжать работать, не передавая неверные данные в другие части системы, вы должны сделать все возможное, чтобы работать с любым вводом данных.

На мой взгляд, хотя чистота данных превосходит рабочие системы, нельзя допустить, чтобы плохие данные распространялись в других местах и ​​повредили другие системы. Если вы можете массировать данные, чтобы они были правильными, а затем продолжать, вы должны делать это, полагая, что данные безопасны, и вы должны поддерживать работоспособность системы ...

Мне нравится думать о вещах с точки зрения потоков данных. Передача неверных данных загрязняет весь поток, и это плохо, потому что, как и при реальном загрязнении, капля может испортить целую реку данных (если один элемент плохой, чему еще можно доверять?). Но в равной степени плохо блокирует поток, не давая ничего пройти, потому что вы заметили что-то, что можно легко удалить. Отфильтруйте его, и если каждый на каждом этапе также будет фильтровать, вы получите чистые чистые данные на другом конце, даже если в середине появилось несколько примесей.

Answer 8

Это сложно. Если ваш модуль получает неверные данные, и вы можете ничего с ними не делать и возвращать, тогда я бы предложил записывать в журнал ошибок вместо того, чтобы показывать ошибку пользователю.