Время от времени происходят разные вещи. Например, ошибки. Они столь же неизбежны, как зима в Сибири, дождь во Львове, и фото кота в вашей ленте новостей на Facebook. Признайтесь, проверили, правда?
Неизбежность ошибки 404 привела к возникновению новой фишки в веб-дизайне -- добавлять забавную страницу ошибки. Потому что смотреть на обычную на самом деле надоело.
Разумеется, мы создаем системы, чтобы они выходили из строя. Точнее, чтобы мастерски справляться со сбоями. Но в какой-то момент система "проваливается" с таким треском, что пользователи это чувствуют. В какой-то момент приложение не может справиться с ошибкой -- из-за самой ошибки.
Тогда сеть -- или инфраструктура -- обязана безопасно устранить ошибку. То есть, не выбрасывая на экран по-настоящему противную текстовую ошибку 503, которая приведет в замешательство 99% пользователей сайта или приложения.
Умение "ловить" ошибки на выходном канале передачи данных не является новым, как и умение устранять ошибку программным путем, чтобы попытаться оперативно исправить ситуацию или обеспечить для пользователя такой результат, который не содержит ошибки HTTP или кодов ошибок.
Достаточно хотя бы просто предоставить максимум информации о невыполненной транзакции, но в таком случае нужно уметь правильно определить ошибку и затем принять соответствующие меры. Я говорю о видимости и программируемости в сети.
Именно здесь, но на уровне приложений, обитает DevOps. Вот где проявляется ценность DevOps, помимо ежемесячных отчетов и графики, показывающих количество релизов и продолжительность развертывания.
Именно в сети на уровне приложений DevOps способен ликвидировать разрыв между операциями и приложениями, а также обеспечить информацию и сервисы, необходимые для отлаженного развертывания приложений. Частично, это значит решать ошибки конструктивно. Логи, уведомления и предоставление четкой информации о состоянии приложения являются составляющими процесса устранения сбоев.
Учитывая обилие доступных программируемых сервисов, пользователь больше не должен получать сообщений об ошибке от неисправного приложения.
источник
Неизбежность ошибки 404 привела к возникновению новой фишки в веб-дизайне -- добавлять забавную страницу ошибки. Потому что смотреть на обычную на самом деле надоело.
Разумеется, мы создаем системы, чтобы они выходили из строя. Точнее, чтобы мастерски справляться со сбоями. Но в какой-то момент система "проваливается" с таким треском, что пользователи это чувствуют. В какой-то момент приложение не может справиться с ошибкой -- из-за самой ошибки.
Тогда сеть -- или инфраструктура -- обязана безопасно устранить ошибку. То есть, не выбрасывая на экран по-настоящему противную текстовую ошибку 503, которая приведет в замешательство 99% пользователей сайта или приложения.
Умение "ловить" ошибки на выходном канале передачи данных не является новым, как и умение устранять ошибку программным путем, чтобы попытаться оперативно исправить ситуацию или обеспечить для пользователя такой результат, который не содержит ошибки HTTP или кодов ошибок.
Достаточно хотя бы просто предоставить максимум информации о невыполненной транзакции, но в таком случае нужно уметь правильно определить ошибку и затем принять соответствующие меры. Я говорю о видимости и программируемости в сети.
Именно здесь, но на уровне приложений, обитает DevOps. Вот где проявляется ценность DevOps, помимо ежемесячных отчетов и графики, показывающих количество релизов и продолжительность развертывания.
Именно в сети на уровне приложений DevOps способен ликвидировать разрыв между операциями и приложениями, а также обеспечить информацию и сервисы, необходимые для отлаженного развертывания приложений. Частично, это значит решать ошибки конструктивно. Логи, уведомления и предоставление четкой информации о состоянии приложения являются составляющими процесса устранения сбоев.
Учитывая обилие доступных программируемых сервисов, пользователь больше не должен получать сообщений об ошибке от неисправного приложения.
источник
Комментариев нет:
Отправить комментарий