Почему хорошие системы всё равно падают?

Обычно после серьёзного инцидента начинают искать техническую причину: база данных, сеть, балансировщик, очередь, приложение. И почти всегда её находят.

Но за несколько лет работы с крупными корпоративными системами я всё чаще прихожу к выводу: техническая причина аварии - это часто только последний элемент цепочки.

Настоящая проблема возникает гораздо раньше.

Например: - решили, что второй ЦОД «потом доделаем»; - мониторинг показывает CPU и память, но не бизнес-операции; - резервная БД есть, но переключение никто не проверял; - бэкапы делаются каждый день, но восстановление последний раз тестировали год назад; - архитектурное решение приняли временно, а оно прожило пять лет;

про отказ одного компонента подумали, а про комбинацию нескольких отказов - нет.

На схеме при этом всё может выглядеть прекрасно: F5 -> Nginx -> приложение -> MQ/Kafka -> backend -> PostgreSQL

Есть кластеры, репликация, несколько узлов, резервирование. Но отказоустойчивость - это не количество серверов. Она появляется только тогда, когда система умеет пережить отказ в реальности, а не только в архитектурной диаграмме.

Поэтому при проектировании я стараюсь задавать не вопрос: «Что здесь зарезервировано?»

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

Иногда пять таких вопросов дают для надёжности системы больше, чем ещё десять серверов.

Хорошая архитектура - это не архитектура, в которой ничего не ломается.

Хорошая архитектура - та, в которой заранее известно, что произойдёт, когда что-нибудь обязательно сломается.