Философия «let it crash» и отказоустойчивость

Контринтуитивный принцип, который делает системы надёжнее.

Let it crash («пусть падает») — стратегия, при которой процесс не пытается обработать каждую мыслимую ошибку, а аварийно завершается, доверяя восстановление отдельному процессу-супервизору.

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

Сразу оговоримся, чтобы снять главное недоразумение. «Let it crash» не означает «писать небрежно» или «забить на ошибки». Это означает осознанное перераспределение ответственности: рабочий код занимается только своей прямой задачей и не обвешивается проверками на все мыслимые беды, а обработка сбоев выносится в отдельный, специально для этого предназначенный слой архитектуры. Получается чистое разделение труда: одни процессы делают работу, другие следят за тем, чтобы работа в случае сбоя возобновилась.

Проблема защитного кода

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

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

Erlang говорит: пиши счастливый путь. Если данные не такие, как ожидалось, — пусть процесс упадёт. Это не катастрофа, потому что процессы изолированы. Парадокс в том, что отказавшись бороться с каждой отдельной ошибкой, мы получаем систему, которая в целом устойчивее, чем если бы мы героически пытались всё предусмотреть.

% "Счастливый путь": ждём ровно две цифры
parse_pair([A, B]) ->
    {ok, A, B}.
% Если придёт список другой длины — функция не подойдёт,
% процесс упадёт с ошибкой function_clause. И это нормально.

Почему падение — это безопасно

Ключевая идея: отказ одного процесса не должен влиять на остальные. Поскольку процессы Erlang не делят память, упавший процесс не может испортить данные соседа. Он просто исчезает. А специальный процесс — супервизор — замечает падение и запускает новый, чистый экземпляр.

          supervisor
          /    |    \
     worker  worker  worker
                |  (падает)
                v
        supervisor запускает
        новый worker на замену

Это похоже на то, как устроена надёжность в самой природе: отдельная клетка может погибнуть, но организм продолжает жить, заменяя её. Система самовосстанавливается. Хорошая бытовая аналогия — электрические предохранители. Когда в сети скачок, предохранитель намеренно «жертвует собой» и размыкает цепь, защищая всю проводку и приборы. Никто не считает сгоревший предохранитель провалом инженерной мысли — наоборот, это и есть его работа. Точно так же падение процесса в Erlang — это не баг, а штатный, спроектированный заранее способ локализовать проблему.

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

«Падать рано» лучше, чем «тащить мусор»

Если процесс получил некорректные данные, продолжать работу опасно: он может записать испорченное состояние, отправить неверное сообщение, заразить ошибкой соседей. Лучше остановиться немедленно, в точке обнаружения проблемы, пока ничего не испорчено. Erlang называет это «fail fast». Падение становится не позором, а механизмом защиты целостности.

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

Как работает под капотом

Когда процесс аварийно завершается, BEAM рассылает сигнал о его смерти всем связанным процессам (через механизм link) и отправляет сообщение тем, кто за ним наблюдает (через monitor). Супервизор как раз построен на этих сигналах: он связан со своими рабочими процессами и по сигналу о падении применяет стратегию перезапуска. Память упавшего процесса полностью освобождается сборщиком мусора — никаких «зомби».

У супервизоров есть и важный предохранитель от бесконечного цикла. Если процесс падает снова и снова — скажем, из-за недоступной базы данных, к которой он пытается подключиться при старте, — супервизор не будет перезапускать его вечно. У него настроены пределы: например, не больше пяти перезапусков за десять секунд. Превысив порог, супервизор сдаётся и сам аварийно завершается, передавая проблему своему супервизору уровнем выше. Так формируется дерево супервизоров, и сбой по нему поднимается всё выше, пока не найдётся слой, способный его пережить — вплоть до перезапуска целой подсистемы. Эта иерархия и есть инженерное воплощение фразы «let it crash»: падение не игнорируется, а организованно эскалируется.

Частые ошибки

Обрабатывать ошибки везде «на всякий случай». В Erlang ошибки обрабатывают в одном месте — в супервизоре, а не размазывают по всему коду.
Думать, что «let it crash» означает отсутствие обработки ошибок. Обработка есть, но она вынесена на уровень архитектуры (деревья супервизоров), а не отдельной функции.
Перезапускать процесс с тем же испорченным состоянием. Смысл перезапуска — вернуться в заведомо корректное начальное состояние.

Итоги

«Let it crash» — это перенос обработки ошибок с уровня функции на уровень архитектуры.
Изоляция процессов делает падение безопасным: сосед не пострадает.
Супервизоры замечают падение и запускают чистый экземпляр — система самовосстанавливается.
«Падать рано» защищает целостность данных лучше, чем защитный код.