Насколько устойчивым должно быть мое веб-приложение?

Question

В последнее время я нашел несколько аргументов с моим начальником об обработке исключений в нашем веб-приложении (приложение C# asp.net MVC).

В основном разговоры идут что-то вроде этого:

Босса: «Существует что-то не так с нашей программой, базы данных клиента иксов пошли вниз сегодня, и каждый видит страницу ошибки.»

Me: «В основном каждая страница приложения использует базу данных для чего-то (кроме страницы с ошибкой), нет никакой разумной альтернативы, кроме как показать страницу с ошибкой».

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

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

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

Answer 1

Я бы оставил его боссу, чтобы решить. Расскажите ему, сколько часов потребуется, чтобы сделать приложение «упругим», и он решит, стоит ли инвестировать.

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

Для внешних служб, таких как попадание SMTP-сервера или базы данных, которая не используется большей частью остальной части app, мы обычно используем код, который просто отображает обратную связь на странице, если служба/база данных недоступна/недоступна.

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

Answer 5

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

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

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

Answer 6

Это, вероятно, более академический ответ, учитывая, что вы унаследовали этот код. Если вы используете, или, вернее, если кто-то использовал, шаблон Microsoft.Practices.EnterpriseLibrary.ExceptionHandling ExceptionPolicy, то действительно легко перейти от отображения страницы ошибки (путем исключения исключения) для использования исключений и отображения пустых сеток, списков и т. Д.

вы уже можете быть в курсе этой маленькой модели, но здесь это все равно:

 try 
     { 
      //get data 
     } 
     catch (Exception ex) 
     { 
      if (ExceptionPolicy.HandleException(ex, "Data Access Exception")) 
       throw ex; 
     } 

Answer 7

возможно, вы просто показывающий общую страницу ошибки, когда пустой набор данных с и «удобно "сообщение об ошибке будет.

Так, например, если вы показываете список пользователей/сообщений/дату, но служба, в которой вы ее собираете, отключена, возможно, вы можете показать пустой набор.

Таким образом, вместо того чтобы показывать:

500 Server Error 




. 

Вы могли бы показать что-то вроде:

User | Message  | Date 
------------------------------ 
    No data available* 




* Xyz service is be down. 

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

Это сильно варьирует в зависимости от того, что вы используете, но в общих чертах это может быть столь же просто, как:

List<Data> data = EmptyList<Data>(); 

try 
{ 
    data = service.GetData(); 
} catch(ServiceUnavailableException error) 
{ 
    errorPage.SetMessage(service.GetName() + " service is down "); 
    // log the error message 
    logger.doLog(error); 
} 

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

Answer 8

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

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

Чтобы сделать приложение пригодным для использования, оно должно быть доступным и надежным. Почти все приложения (кроме автономных утилит для настольных компьютеров) - это 2 или более многоуровневые приложения, что означает, что сетевой вызов будет там и все проблемы, связанные с n/w. Итак, как только вы начнете практиковать, вы начнете внедрять шаблоны отказоустойчивости во всех приложениях.