Управляемый хаос
 
Много лет информационные системы строились, да и строятся, по принципу борьбы с отказами. Давайте купим «надежное» брендовое серверное железо, аппаратный RAID с батарейкой, корпус с дублирующим блоком питания и т.д. и т.п.
 
Все это должно уберечь нас от отказа, который в нашей парадигме – чрезвычайное происшествие со всеми вытекающими последствиями и оргвыводами.
 
И самое печальное в этом, что нашему брату админу тут форменный цугцванг. Чтобы ты не делал, любой твой ход только ухудшает ситуацию.
 
Купил недостаточно брендовое или вообще десктопное железо? А мы говорили, а мы предупреждали, надо было…
 
Сделал ровно наоборот? И отказ таки приключился? А теперь поясни, дорогой наш друг, ради чего мы выделили на это все такие большие деньги…
 
Поэтому современный подход - Design for Failure (Проектирование с расчетом на сбои) – исходит совершенно из обратных посылов. Сбои – это неотъемлемая часть нашей жизни, как природные явления за окном, бороться с ними невозможно, тем более предотвращать.
 
Все что может сломаться – сломается, все что может упасть – упадет, любой кто может накосячить – накосячит.
 
И это не выдумки теоретиков, это то, к чему пришли гиганты индустрии: Google, Facebook или Netflix. Они честно признались в том, что не могут бороться с отказами, но могут бороться с их последствиями.
 
Отсюда были выведены основные принципы:

🔹 Сбои неизбежны (Assume Failure): Все, что может сломаться (железо, сеть, стороннее API, человеческий фактор), обязательно сломается. Это не баг, это закон природы.
 
🔹 Изоляция отказов (Bulkheading): Проблема в одном модуле не должна лавинообразно уничтожать всю систему. Если «легла» рекомендательная система, корзина и оплата должны продолжать работать.

🔹 Контролируемая деградация (Graceful Degradation): Если система не может отдать пользователю идеальный результат, она должна отдать «приемлемый». Например, вместо пустой страницы показать закешированные вчерашние данные.
 
🔹 Автоматическое восстановление (Self-Healing): Система должна уметь сама перезапускать упавшие контейнеры, переключаться на резервные копии баз данных и отсекать проблемные узлы без звонка дежурному админу в 3 часа ночи.
 
И все это легко переносится на админские будни. Мы не можем обеспечить 100% надежность, брендовое железо может оказаться бракованным, аппаратный RAID развалит массив из-за бага в прошивке, ПО ляжет из-за бага в обновлении. И, наконец, добро пожаловать самая неизвестная переменная – человек, которому свойственно ошибаться.
 
Попытка строить системы, которые почти никогда не упадут на таком фундаменте обречены на провал. А вот исходить из того, что все упадет и сломается (или будет сломано) – трезвый современный подход.
 
И все инструменты для этого у администратора есть: кластеризация, HA, виртуализация и контейнеризация, распределенные хранилища, инфраструктура как код.
 
Да, местами сложно, местами непривычно, но именно это современное IT,  с его управляемой деградацией и способностью к самовосстановлению.

Сервер СУБД сожрал всю память? Он не уронит весь стек, а просто упадет сам, а балансировщик переключит на вторую активную ноду. Сам же контейнер будет перезапущен или вообще пересоздан из эталона. И это лучше, чем слать алерт администратору в три часа ночи.
 
Резко выросла нагрузка? Кластер сам перераспределит нагрузку между нодами. Упала нода? Остальные подхватят упавший флаг, да сервис деградирует, но продолжит работать. Тормозит? Да! Но работает ведь! Клиенты не уходят, бизнес-процессы не останавливаются.
 
И админ спит ночами спокойно, упало – да и пес с ним, завтра в рабочее время разберется, нет необходимости вскакивать посреди ночи, брать такси (выпил вечером банку пива) и нестись, теряя ботинки в серверную.
 
Да и вообще в этой парадигме ломать полезно, у Netflix есть Chaos Monkey – специальный скрипт который в рабочее время в случайном порядке ломает ноды или виртуалки, что помогает инженерам найти слабые места в инфраструктуре и устранить их до тех пор, пока это станет проблемой.