теория

Fault — не failure

Слово «надёжность» звучит абстрактно, пока не свести его к одной честной мысли: продолжать работать правильно, даже когда что-то идёт не так. А «не так» будет — гарантированно. Разведём два слова, которые вечно путают:

  • Fault — отказала часть системы: сгорел диск, упала машина, завис внешний API.
  • Failure — система целиком перестала делать обещанное, то есть нарушила SLO.

неизбежны, это просто статистика: диски умирают, сети рвутся, а люди ошибаются. И, кстати, именно люди с кривой конфигурацией роняют системы чаще, чем железо. Значит, инженерный вопрос ровно один: превратится ли очередной fault в failure. Система, где не превращается, называется .

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

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

И третье требование, самое недооценённое, — сопровождаемость. Удобно ли систему эксплуатировать; разберётся ли в ней новичок за недели, а не за годы; дёшево ли её менять. Большая часть стоимости софта — не написать его, а годами с ним жить.

← назад