![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Инжинерность
Я сейчас случайно увидел, что делает powershell, если указать несуществующую команду.
Это выглядит неприятно. Но, кроме "неприятно", что ещё можно сказать? Оно не хорошо спланировано.
Один из принципов инженерности, это правильная обработка sad path (vs bad path).
Сама идея: в программе есть три пути: happy path (что сказали, то сделали, получили результат), sad path (поведение при невозможности получить результат) и bad path (то, что случается, если результат нельзя получить, но никто не предусмотрел что делать).
Десятилетиями операционные системы и языки программирования давали свою интерпретацию "что делать если всё плохо". Первые версии просто игнорировали "всё плохо" (вот этот мем немного утрирует, но справа показано полное отсутствие обработки ошибок). В реальности, полное отсутствие обработки ошибок, это UB (undefined behavior) и процессор продолжает исполнять что-то, что уже не оригинальная программа. На практике это всегда заканчивается зависанием.
Потом добавили рудиментарные проверки на чтение по некорректному указателю (сама концепция "некорректный указатель" - это уже конструкция поверх возможности читать всё и всегда), сообщение от операционной системы (segmentation fault), etc.
Сверху добавили трейсы и т.д.
Это работа по превращению bad path в sad path с точки зрения ОС и языка программирования (точнее, среды исполнения, которую предоставляет компилятор).
Однако, это не отменяет необходимости делать такую же работу со стороны программиста. Программа на питоне, которая выдаёт трейс "не могу открыть файл" (вместо сообщения об ошибке "не могу открыть файл") - это пример bad path (который sad path с точки зрения питона). Полагаться на обработчик ошибок уровнем ниже - это неинжинерно.
В тот момент, когда программа отдаёт ошибку "наверх" (трейс, exception), она отказывается от своего домена и проблема перефомулируется на языке уровнем ниже.
Не "input file not found" (программа знает, что это input file), а "file not found exception at line xxx". В этот момент язык программирования не знает, является ли ошибка ожидаемой или нет, ошибка программы это (например, опечатка в имени файла) или ошибка отсутствия файла как параметра.
Язык программирования не знает, bad path это для программы или sad path. Отсутствие обработки ошибки, стирает её смысл.
К чему я это всё? На самом деле я не про sad/bad path. Я про инжинерность. Обработка ошибок - это один из признаков инжинерности, когда программа сохраняет свой понятийный домен (язык, на котором описывается, что делает программа) во всех ситуациях.
Сохранение семантического домена - это сохранение инварианта. Если программа А работает, то она всегда взаимодействует в рамках этого домена.
Плохая программа нарушает инвариант, давая вариативность: "иногда я делаю что сказали, в своём определении 'сказали', а иногда нет, и тогда проблема описывается в других терминах, операционной системы/рантайма".
Чем большая вариативность программы в семантических доменах, тем труднее с ней работать, тем хуже она написана. Иногда эта вариантивность оправдана (например, в любом языке программирования де-факто, в какой-то момент заканчивается язык программирования и начинаются регэкспы - у этого есть причины и польза). Но если вариантивность появляется "потому что так меньше писать", это признак плохой программы, то есть неинжинерной программы.
Это выглядит неприятно. Но, кроме "неприятно", что ещё можно сказать? Оно не хорошо спланировано.
Один из принципов инженерности, это правильная обработка sad path (vs bad path).
Сама идея: в программе есть три пути: happy path (что сказали, то сделали, получили результат), sad path (поведение при невозможности получить результат) и bad path (то, что случается, если результат нельзя получить, но никто не предусмотрел что делать).
Десятилетиями операционные системы и языки программирования давали свою интерпретацию "что делать если всё плохо". Первые версии просто игнорировали "всё плохо" (вот этот мем немного утрирует, но справа показано полное отсутствие обработки ошибок). В реальности, полное отсутствие обработки ошибок, это UB (undefined behavior) и процессор продолжает исполнять что-то, что уже не оригинальная программа. На практике это всегда заканчивается зависанием.
Потом добавили рудиментарные проверки на чтение по некорректному указателю (сама концепция "некорректный указатель" - это уже конструкция поверх возможности читать всё и всегда), сообщение от операционной системы (segmentation fault), etc.
Сверху добавили трейсы и т.д.
Это работа по превращению bad path в sad path с точки зрения ОС и языка программирования (точнее, среды исполнения, которую предоставляет компилятор).
Однако, это не отменяет необходимости делать такую же работу со стороны программиста. Программа на питоне, которая выдаёт трейс "не могу открыть файл" (вместо сообщения об ошибке "не могу открыть файл") - это пример bad path (который sad path с точки зрения питона). Полагаться на обработчик ошибок уровнем ниже - это неинжинерно.
В тот момент, когда программа отдаёт ошибку "наверх" (трейс, exception), она отказывается от своего домена и проблема перефомулируется на языке уровнем ниже.
Не "input file not found" (программа знает, что это input file), а "file not found exception at line xxx". В этот момент язык программирования не знает, является ли ошибка ожидаемой или нет, ошибка программы это (например, опечатка в имени файла) или ошибка отсутствия файла как параметра.
Язык программирования не знает, bad path это для программы или sad path. Отсутствие обработки ошибки, стирает её смысл.
К чему я это всё? На самом деле я не про sad/bad path. Я про инжинерность. Обработка ошибок - это один из признаков инжинерности, когда программа сохраняет свой понятийный домен (язык, на котором описывается, что делает программа) во всех ситуациях.
Сохранение семантического домена - это сохранение инварианта. Если программа А работает, то она всегда взаимодействует в рамках этого домена.
Плохая программа нарушает инвариант, давая вариативность: "иногда я делаю что сказали, в своём определении 'сказали', а иногда нет, и тогда проблема описывается в других терминах, операционной системы/рантайма".
Чем большая вариативность программы в семантических доменах, тем труднее с ней работать, тем хуже она написана. Иногда эта вариантивность оправдана (например, в любом языке программирования де-факто, в какой-то момент заканчивается язык программирования и начинаются регэкспы - у этого есть причины и польза). Но если вариантивность появляется "потому что так меньше писать", это признак плохой программы, то есть неинжинерной программы.
no subject
no subject
Отчёт про ошибку ECC (номер банка памяти, номер сервера, описание сервера, который это заметил (через netconsole, например) - 200кб.
Супервизор базы данных, который это нашёл - 300кб. (данные супервизора, аудит-трейл получения данных и т.д.)
Приложение - ещё 200кб (потому что трейс глубокий и есть контекст)
Это приложение вернуло ошибку фрод-системе (лог ещё 1Мб, потому что много обстоятельств).
Это приложение вернуло ошибку в код обработки транзации. (+500кб)
Это приложение вернуло ошибку банку-процессору (+2Мб, потому что чужая система и нам нужны полные данные)
Это приложение вернуло ошибку терминалу, к которому ты приложил карточку.
Терминал должен дать тебе квиток с ошибкой. Нам написно Rejected и ID транзакции.
Надо ли в терминале печатать эти 5 мегабайтов ошибки, из которой ты узнаешь, в какой планке памяти на каком сервере битая память.
Я утрирую, но идея именно та. Глубина трейса должна быть ограничена, иначе обработки ошибок не будет.
no subject
- простой rejected - подошедшему клиенту.
- "сервер вернул ошибку при обработке транзакции" + описание транзакции - оператору терминала
- детали ошибки - администратору терминала
- Детальные отчет об ошибке супервизора базы + железячной ошибке - администратору базы данных.
Можно обсуждать что и кому показывать, но потери информации быть не должно. В идеале. На практике, понятно, возможны варианты, когда приходится скрипя зубами что-то обрезать.
no subject
Представь себе трейс на обработку нехватки ресурсов (sad path), вызванный избыточным количеством трейсов.
В современном observability есть сэмплинг (в т.ч. ошибок) и backpressure.
no subject
no subject
Сколько такой сайт простоит и как легко его завалить? http://bad.url/get404 в цикле, и сайт сам себя ухайдокает.
А такое получить очень просто. Трейс надо написать. Куча интерполяции. Трейс надо отправить. Разумеется, по SSL. Минус энтропия, плюс установка соединения. Если там нет connection pool или socket reuse в систему логгинга, одно это сломает сервер, даже без доп. ухищрений.
Если же у тебя там observability в потолок, то 404 - это 300 байт, а трейс о нём - пара мегабайт. Вот у тебя самоDoS и образовался, с мультипликатором over 10k.
no subject
no subject
no subject