Технические ошибки и ошибки бизнес-логики

Технические ошибки

Введение

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

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

Организационные и продуктовые задачи

Процесс создания проудкта, от постановки требований до исполнения в виде готового решения, состоит из двух частей:

  • Организационная
  • Техническая

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

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

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

В веб-приложениях это решается согласно двум принципам:

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

Эти принципы реализуются следующими подходами:

  • Все ошибки проекта - это HTTP ошибки
  • Бизнес ошибки отдельно, технические ошибки отдельно

Подход "Все ошибки проекта - это HTTP ошикби"

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

  • Унификация - все ошибки обрабатываются единым образом
  • Упрощение отслеживания ошибок и их доставка до пользователя
  • Упрощения идентификации ошибок
  • Возможность дополнительной маршрутизации на основе кодов ошибок
  • Хорошо подходит для RESTFull сервисов

Обработка всего как технических ошибок

Основные коды HTTP ошибок

  • 1xx Status Codes [Informational]
  • 2xx Status Codes [Success]
  • 3xx Status Codes [Redirection]
  • 4xx Status Codes (Client Error)
  • 5xx Status Codes (Server Error)

Наиболее часто используются

200 OK Indicates that the request has succeeded. 201 Created Indicates that the request has succeeded and a new resource has been created as a result.

301 Moved Permanently The URL of the requested resource has been changed permanently. The new URL is given by the Location header field in the response. This response is cacheable unless indicated otherwise.

304 Not Modified Indicates the client that the response has not been modified, so the client can continue to use the same cached version of the response.

400 Bad Request The request could not be understood by the server due to incorrect syntax. The client SHOULD NOT repeat the request without modifications.

401 Unauthorized Indicates that the request requires user authentication information. The client MAY repeat the request with a suitable Authorization header field

403 Forbidden Unauthorized request. The client does not have access rights to the content. Unlike 401, the client’s identity is known to the server.

404 Not Found The server can not find the requested resource.

429 Too Many Requests The user has sent too many requests in a given amount of time (“rate limiting”).

500 Internal Server Error The server encountered an unexpected condition that prevented it from fulfilling the request.

503 Service Unavailable The server is not ready to handle the request.

Недостатки HTTP ошибок

  • HTTP разрабатывался для гетерогенных сред распространения информации, может содержать огромное количество промежуточных узлов
  • HTTP ошибки могут логироваться и способствовать утечке бизнес-информации
  • HTTP и Бизнес - это разные уровни астракции - протечка асбтракции
  • Логика ничего не знает о транспорте, усложняется обработка при использовании нескольких транспортов
  • Сопровождение HTTP ошибок могут выполнять люди, которые не понимают сути бизнес ошибок
  • Повышается уровень ложных срабатываний для подразделений сопровождения
  • Бизнес ошибки требуют обработки в клиенте, не всегда можно сделать обобщение
  • Ошибка может не дойти до конечной точки (клиента)

Особенности создания RFC

  • RFC означает Request for Comments (рабочее предложение)
  • RFC может содержать как описание стандартов, так и лучшие практики, просто информацию или что-то еще
  • стандарты размещаются в Standards Track
  • в самом начале стандарты являются просто предложениями "Proposed Standard"
  • если стандарт становится достаточно зрелым (т.е. широко применяется на практике и не вызывает проблем), его помечают как "Internet Standard"
  • с момента как стандарт получает статус Internet Standard ему также присваивается номер STDXX, который содержит набор RFC, относящихся к этому стандарту.

Из интересного: у RFC есть стадия обсуждения, в рамках которой в документ могут быть внесены изменения, затем наступает стадия AUTH48 когда автору RFC дается 48 часов (на самом деле около недели) на то, чтобы он окончательно сформировал и осмыслил документ. После этого документ либо публикуется, либо автор может отказаться от его публикации. После публикации документ получает номер RFC и уже не может быть изменен (к нему могут быть только добавлены сообщения об ошибках - Erratas). Но если ошибок слишком много, то можно выпустить еще один RFC.

RFC7807

RFC7808 скриншот

Предполагается, что ошибки передаются HTTP кодами:

`HTTP/1.1 403 Forbidden Content-Type: application/problem+json Content-Language: en

{ "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/msgs/abc", "balance": 30, "accounts": ["/account/12345", "/account/67890"] } `

Полезнгая информация содержится в BODY ` HTTP/1.1 400 Bad Request Content-Type: application/problem+json Content-Language: en

{ "type": "https://example.net/validation-error", "title": "Your request parameters didn't validate.", "invalid-params": [ { "name": "age", "reason": "must be a positive integer" }, { "name": "color", "reason": "must be 'green', 'red' or 'blue'"} ] } `

Подход "Бизнес ошибки отдельно, технические ошибки отдельно"

  • Правильное разделение на уровни абстракции
  • Грамотное удовлетворение потребностей в информации разных групп пользователей
  • Прозрачность к техническим способам доставки информации
  • Проще построить эффективный мониторинг и разграничить доступ к информации

Обработка бизнес-ошибок

Недостатки разделения ошибок от HTTP кодов

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