Перестали работать быстро по сравнению с устойчивостью
Нашим продуктом является распределенная система. Модули я продолжаю работать, являются довольно новыми, довольно строгими, хорошо протестированные. Они были разработаны с недавними лучшими практиками в памяти. Другие модули можно рассмотреть как унаследованное программное обеспечение.
В то время как я бдителен в отношении всего, что происходит в модулях, за которые я ответственен, я постоянно подвергаюсь принуждению работать с неправильными данными, отправленными мне от других модулей. В глубине души я - "Сбой Быстро" принципиальный разработчик и в результате когда проблемы возникают, я обычно в состоянии устранить возможность ошибки в моих модулях. Это не так о вине, просто экономя потраченные впустую усилия в преследовании ошибок в неправильных местах.
Но аргумент, на который я продолжаю наталкиваться: "Мы не можем позволить этому сбою материала в производстве, клиент ожидает, что это будет работать, почему Вы не работаете вокруг этой проблемы". И это было бы аргументом в пользу устойчивости: будьте либеральны в том, что Вы принимаете, консерватор в том, что Вы отправляете.
Я должен также отметить, что это главным образом неустойчивые проблемы. Мы видим их в интеграционных тестах, но их трудно воспроизвести. Синхронизация и параллелизм включена.
Мне нелегко балансироваться между этими двумя принципами. Часть его является моим беспокойством, что, если я начинаю позволять и распространять исключительные данные, я приглашаю проблему, и у меня не будет такой же уверенности в моей системе. Но я не могу привести доводы против хранения системной работы, даже если другие модули отправляют мне неправильно данные. Причина другие модули не становятся фиксированными, состоит в том, что они слишком сложны и хрупки, в то время как мои все еще кажутся ясными и безопасными. Но если я не буду сопротивляться давлению, то мои модули будут медленно обременяться теми же проблемами, которые я отклонял до сих пор.
Я должен сказать, что система не "отказывает" в производстве, но мой модуль может просто отобразить ошибку к оператору и попросить, чтобы они связались с поддержкой. Катастрофический отказ был бы большой проблемой, но если я сообщаю об ошибке ясно, затем разве это не правильный поступок? Я подозреваю, что мои коллеги просто не хотят, чтобы клиент видел любые проблемы, период. Но мой модуль отклоняет данные из других модулей в нашем продукте, не, клиент ввел. Таким образом, мне кажется, что мы просто не занимаемся проблемами.
Так, я должен быть более прагматически настроен или стоять на своем?
8 ответов
Спасибо всем. Дело, которое вызвало этот вопрос, закончилось хорошо, и отчасти благодаря прозрениям, которые я получил из ответов, приведенных выше.
Моей первоначальной реакцией было придерживаться быстрого провала, но я подумал об этом еще немного, и пришел к выводу, что одна из ролей моего модуля заключается в обеспечении стабилизирующего якоря для остальной части системы. Это вовсе не обязательно означает принятие плохих данных, но и постановку проблем на поверхность, их изоляцию и прозрачную обработку до тех пор, пока мы не найдем решение.
Я планировал добавить новый обработчик и путь к коду для этого случая, который будет корректно исполняться, как если бы это был специальный случай использования, который ранее не был документирован.
У нас была дискуссия, в которой я повторил необходимость решения проблемы на границе, но также был готов помочь. Я изложил свой план другой стороне, потому что у меня было подозрение, что моя позиция была воспринята как излишне педантичная, и что решение было воспринято только как необходимость отключить ложную валидацию безобидных данных, даже если они были неправильными. В реальности же то, как я работаю, в основном, управляется данными, поэтому я объяснил, почему они должны быть корректными, и как они управляют поведением, и как при размещении этих данных я буду реализовывать специальный путь к коду.
Я думаю, что это придало вес моей позиции, и это привело к более глубокому обсуждению отвращения другой стороны к исправлению данных. Оказалось, что это скорее усталость иметь дело с унаследованной системой, склонной к ошибкам, чем реальное препятствие. Существовало относительно простое решение, было просто страшно что-то менять, мышление, которое довольно укоренилось.
Но, выпустив в эфир все проблемы и возможные решения, мы, в конце концов, согласились исправить данные, и до сих пор, похоже, это решило нашу проблему. Наши интеграционные тесты сейчас проходят последовательно, но мы также добавили протоколирование и будем продолжать его отслеживать.
Подводя итог, я думаю, что для меня синтез обоих принципов заключается в том, что для решения проблем с поверхностью необходим быстрый отказ. Но после того, как они всплывут, робастность означает обеспечение прозрачного пути для продолжения работы таким образом, чтобы не скомпрометировать систему. Я смог предложить это, и, сделав это, выиграл некоторую добрую волю с другой стороны и получил данные исправлены в конце концов.
Еще раз, спасибо всем, кто ответил. Я слишком новичок, чтобы оценивать комментарии, но я ценю все представленные перспективы.
Я бы сказал, что это зависит от того, что произойдет, если вы не остановитесь. Кто-то зарплата обрабатывается неправильно? Неправильный заказ будет отправлен? Это было бы стоить прекратить.
Если возможно, у вас тоже есть свой пирог и съешьте его - не сообщайте о ошибке к пользователю, заставьте заказчику согласиться на отправку диагностических отчетов и сообщите о каждой отказе. Ошибка разработчика (ы), которые владеют неисправным модулем (ы), чтобы исправить их. И по ошибкам я имею в виду файл ошибок против них. Или, если руководство не считает, что стоит стоимость фиксации, нет.
Я также пишут тесты подразделения против этих модулей, которые не удаются, особенно если вы можете сказать, каким был исходный вход, который заставил их генерировать неправильный вывод.
То, к чему он действительно приходит к тому, что человек, который отзывает ваш производительность, желает от вас, особенно после того, как вы объясните их, по электронной почте.
Это сложно. Если ваш модуль принимает плохие данные, и это «нормально» для вас просто ничего не делать с ними и вернуться, то я бы предложил написать в журнал ошибок вместо того, чтобы отобразить ошибку пользователю.
Это зависит от класса ошибки, которую вы получаете. Если способ нарушения системы, означает, что вы можете продолжать не кормить плохие данные любым другим частям системы, вы должны делать все в вашей силе, чтобы работать с тем, какой вход.
На мой взгляд, хотя чистота данных превосходит рабочие системы, вы не можете разрешить плохие данные распространять в других местах и повредить другие системы. В той степени, в которой вы можете правильные данные массажирования, а затем продолжать идти, вы должны сделать это по теории, что данные безопасны, и вы должны держать систему бегать ...
Мне нравится думать о вещах с точки зрения данных потоки. Прохождение плохих данных вдоль загрязняет весь поток, и это плохо, потому что просто как реальное загрязнение, капля может испортить целую реку данных (если один элемент плохой, что еще вы можете доверять?). Но одинаково плохо блокирует поток, позволяя ничего не пройти, потому что вы заметили то, что вы могли легко удалить. Отфильтруйте его, и если все на каждом этапе также фильтруют, вы получаете четкие чистые данные из другого конца, даже если в середине запущены несколько примесей.
Вопрос ваших сверстников в том: "почему бы вам не поработать над этой проблемой"
Вы говорите, что можете обнаружить плохие данные и сообщить об ошибке пользователю. Это нормальный подход - как только вы знаете, что данные, поступающие в ваши функции, плохие, вы должны быстро провалиться (и это рекомендация из других ответов, которые я прочитал здесь).
Однако в вашем вопросе не указана область, в которой работает ваше программное обеспечение. Если вы знаете, что поступающие данные ошибочны, возможно ли вам снова запросить эти данные? Возможно ли на самом деле выйти из ситуации?
Я упомянул, что "домен" здесь важен. Итак, если у вас есть приложение, которое отображает, например, потоковые видеоданные, и, возможно, ваш беспроводной сигнал слабый, поэтому поток поврежден, должна ли система "быстро выходить из строя" и отображать сообщение об ошибке? Или следует отображать более плохое изображение, и попытка повторного подключения, если это необходимо, в зависимости от масштаба проблемы?
В зависимости от вашего домена, вы можете обнаружить плохие данные и сделать повторный запрос данных, не причиняя неудобств пользователю. (Очевидно, что это относится только к тем случаям, когда вы ожидаете, что данные будут лучше во второй раз, но вы все же говорите, что проблемы, с которыми вы сталкиваетесь, являются прерывистыми и возможными параллельными)....
Итак, отказоустойчивость - это хорошо, и это определенно то, что вы должны делать, если вы не можете восстановиться. И вы определенно не должны распространять плохие данные. Но если вы можете восстанавливаться, что в некоторых доменах можно сделать, то неудача сразу же не обязательно лучшее, что можно сделать.
Я разделяю "fail fast" привилегию/принцип. Но не думайте об этом как о конфликте принципов, это скорее конфликт понимания. У вашего контрагента есть некое невысказанное требование ("не показывать пользователю неудачное время"), которое подразумевает некоторое пропущенное требование. У Вас не было возможности заранее обдумать/выполнить это требование, поэтому оно оставило плохой вкус у Вас во рту. Забудьте об этой точке зрения, подойдите к ней как к новому проекту с фиксированным требованием, с которым Вы можете работать.
Может быть, лучшим результатом будет сообщение об ошибке, как вы показали. Но звучит так, как будто вы реализовали его до того, как были куплены у вашего контрагента, когда у них был выбор, чтобы принять его. Раннее сообщение о том, что Вы делали, могло быть адресовано к чему-то подобному.
Будьте осторожны в том, как предотвратить эти идеи. Постоянное обращение к другим системам "слишком сложным и хрупким" может привести к тому, что люди будут тереться о них неправильно. Просто говорите о том, что системы для вас новы, и на их понимание требуется больше времени. Уделите время их пониманию, чтобы не снизить ожиданий людей от ваших возможностей.
Проще говоря, это звучит как «не проверяйте то, с чем вы не можете справиться». Тот факт, что вы обнаруживаете ошибку и можете сообщить о ней, означает, что вы не распространяете ее. Но это также означает, что, поскольку вы можете сообщить об этом, у вас есть какой-то механизм, чтобы перехватить ошибку и, следовательно, потенциально обработать ее самостоятельно и исправить, а не сообщать о ней.
Учтите, я предполагаю, что ваш отчет об ошибке более интересен, чем случайное исключение, обнаруженное вами в каком-то месте глубоко в системе. Но даже тогда, если это исключение, которое вы тестируете и создаете (т.е. вы проверяете, равен ли знаменатель нулю, и отправляете ошибку, а не просто случайно делите на ноль и ловите исключение выше), то это предлагает вам вполне может иметь способ исправить проблему.
В итоге вам нужно и то, и другое. Вам нужно попытаться сделать данные как можно более безошибочными, но также сообщать о неожиданных.
Не думаю, что можно запереть дверь и скрестить руки со словами «это не моя проблема». Тот факт, что он исходит из «старых, хрупких систем», бессмыслен. ВАШ код не старый, хрупкий и явно эффективное место, с точки зрения всей интегрированной системы, для «исправления» данных, как только вы обнаружите проблему. Да, старые модули будут продолжать использовать GIGO в других, меньших системах, но эти устаревшие модули в сочетании с вашим новым модулем составляют единое целое и, таким образом, составляют «систему».
Типичная реальная проблема здесь - это просто уравнение времени / ценности написания всего этого исправляющего кода и новых функций. Это другой спор.Но если у вас есть время и вы знаете, что можно сделать для очистки входящих данных, «будьте либеральны в том, что вы принимаете», - это разумная политика.
Я не буду вдаваться в причины, но ты прав.
По моему опыту, PHB не хватает той части мозга, которая необходима для понимания того, почему быстрая неудача имеет заслугу, а "устойчивость", определяемая как "делать что угодно, что угодно, что угодно, что угодно, что угодно, что угодно, что угодно, что угодно, что угодно, что угодно, что угодно - это плохая идея. Это безнадежно. Просто у них нет аппаратуры, чтобы его прогнать. Они склонны говорить вещи "хорошо, что вы делаете хорошую точку зрения, но что насчёт пользователя" - это просто их версия думает о детях , и сигнализирует мне об окончании преобразования в любое время, когда оно всплывает.
Мой совет - стойте на своем. Вечно.