Принцип "Надежных систем не бывает, бывает готовность к сбоям"¶

В 2012 году Knight Capital потеряла 440 миллионов долларов и стала банкротом за 45 минут из-за сбоя в торговой системе.

В 2021 году упал Facebook вместе со всеми его сервисами на 6 часов. Компания, чей девиз когда-то был "Move fast and break things", обнаружила, что вещи действительно ломаются.

20 октября 2025 крупнейший и по совместительству старейший регион, обрабатывающий 35–40% всего глобального трафика AWS US-EAST-1 упал на 13 часов, парализовав тысячи сервисов и нарушив работу более тысячи компаний.

Здесь еще куча примеров.

Все эти организации имели команды талантливых инженеров, многомиллионные бюджеты и самые современные технологии. И все они потерпели крах.

Нужно запомнить на всю оставшуюся жизнь: надежность это не свойство системы, а непрерывный процесс. Нельзя "сделать надежную систему" так же, как нельзя "сделать здоровье", можно лишь практиковать здоровые привычки и быть готовым к болезням.

Современные системы - это не известный и не отлаженный механизм, где все известно и предсказуемо, это экосистемы: облачные провайдеры зависят от DNS, DNS зависит от BGP, BGP зависит от маршрутизаторов, которые обновляют прошивку в 3 часа ночи по чьему-то плану, о котором вы не знали и т.д. и т.п.

Например, тот же Facebook в 2021 году упал не из-за одной ошибки. Цепочка была изящна: 1. Инженеры запустили проверку состояния backbone-сети. 2. Команда проверки случайно отключила все BGP-анонсы. 3. DNS-серверы ушли в офлайн. 4. Инженеры не могли подключиться к системам для починки, потому что для аутентификации нужны были... те же недоступные DNS. 5. Всё легло.

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

Закон Конвея в действии (по ссылке - первоисточник):

Если у вас три команды работают над сервисом, получится три сервиса с неочевидными границами отказов.

Knight Capital потеряла полмиллиарда не потому, что код был плохой, а потому что: - новый код для торговли акциями переиспользовал кусок старого кода - деплой прошёл только на 7 из 8 серверов - дин "забытый" сервер начал торговать по старым правилам - система не имела "рубильника" для экстренной остановки

Да, у них был код-ревью. У них были тесты. Но у них не было культуры вопросов: "А что если деплой прервётся?", "А где kill switch?" и т.п.

Нужно быть вс егда готовым к любому сбою¶

и в этом нам помогут:¶

1. Наблюдаемость (Observability)

Нельзя реагировать на то, чего не видишь. Но метрики uptime это ложное чувство безопасности (и бесполезное, чаще всего). Настоящая наблюдаемость это способность ответить на вопросы, которые вы ещё не задали.

2. Контролируемость (Controllability)

Всегода должна быть возможность остановить деградацию быстрее, чем она распространяется. Это означает: - Circuit breakers - автоматическое отключение трафика в проблемную зону - Feature flags - возможность отключить функцию без деплоя - Emergency brakes - процедуры, которые работают даже когда автоматика сломана - и т.п.

AWS US-EAST-1 в октябре 2025 упал на 13 часов отчасти потому, что каскадный отказ затронул системы мониторинга и управления. Инженеры не могли увидеть масштаб проблемы и изолировать проблему.

3. Восстановимость (Recoverability)

Не "как предотвратить сбой", а "как вернуться к нормальной работе за 15 минут вместо 13 часов". - Предварительно протестированные процедуры отката. - Изолированные environment'ы для аварийного управления (out-of-band). - Данные, которые можно восстановить без работающего основного сервиса.

Основоположники chaos engineering Netflix не доверяют своей надёжности. Они её ломают намеренно и постоянно: Chaos Monkey случайно убивает инстансы в продакшене. Chaos Kong отключает целые регионы. Это не садизм — это тренировка иммунной системы.

Проводя эксперименты на регулярной основе, имитирующие региональные отключения, мы смогли на раннем этапе выявить различные системные недостатки и устранить их — блог Netflix

На сегодняшний день принципы хаос-инжиниринга формализованы и им дано следующее определение:

Хаос-инжиниринг — это подход, предусматривающий проведение экспериментов над production-системой, чтобы убедиться в ее способности выдерживать различные помехи, возникающие во время работы — principlesofchaos.org

Например, хорощая практика для облачного провайдера: - Еженедельно: случайная остановка 1% ВМ в тестовой среде. - Ежемесячно: имитация отказа хранилища в одной зоне. - Ежеквартально: полное отключение региона с переключением трафика.

Если не начать практиковать сбои, то первый реальный крупный настоящий сбой будет очень дорогим обучением.

Blameless Postmortems¶

Когда Knight Capital разорилась, нашли виноватого за 24 часа. Это гарантировало одно: в следующий раз инженер промолчит о риске, боясь карьерных последствий. Настоящая готовность требует психологической безопасности. Вопрос не "кто сломал?", а "почему система позволила сломаться?". В других главах очень много про постмортемы, не буду здесь повторяться.

Практический фреймворк: RASP¶

Для внедрения культуры готовности есть RASP. Нужно задать себе эти вопросы:

Redundancy (Избыточность) - Что произойдёт, если этот компонент откажет? - Есть ли у нас план Б, который не зависит от плана А?

Automation (Автоматизация) - Можем ли мы масштабировать/откатить/изолировать без ручных действий? - Сколько времени займёт ручное вмешательство нового инженера в 3 часа ночи?

Simulation (Симуляция) - Когда мы последний раз проверяли процедуру восстановления (проводили DRT)? - Работает ли она, если основная система мониторинга недоступна?

Preparedness (Подготовленность) - Знает ли команда, кто принимает решения во время инцидента? - Есть ли заранее определённые пороги для эскалации?

Knight Capital, Facebook, AWS не некомпетентные организации. Это организации, которые столкнулись с неизбежным: в достаточно сложной системе сбои случаются. Разница между катастрофой и инцидентом не в качестве кода, а в глубине подготовки.

Надёжность это не горизонт, к которому приближаешься. Это мышление. "Моя система сломается. Сегодня, завтра или через год. Что я сделаю в первые 5 минут? Кто узнает об этом первым? Как я пойму, что она починилась?". Надежность невозможно "достичь", это динамическая характеристика, требующая постоянного внимания, инвестиций и, самое главное, готовности принять, что сбои не просто возможны, они неизбежны.

Как сказал один из инженеров Google после крупного сбоя: "Мы не предотвратили аварию. Мы к ней готовились три года. И она прошла почти по плану."

Готовность к сбоям это не паранойя, это реализм. Это признание и понимание того, что сложные системы по своей природе ненадежны и чем больше в них компонентов, тем больше в них точек отказа. Что предусмотреть и, тем более, предотвратить все сбои невозможно, можно лишь уменьшить их вероятность и последствия. Что быстрое восстановление важнее, чем предотвращение, потому что предотвратить всё равно не получится. Что ошибки - это данные, а не провалы: каждая неудача содержит уроки для улучшения, или, как говорится, "на ошибках учатся".

Готовность к ним это то, что отличает профессиональные команды от любительских, устойчивые бизнесы от хрупких.

Это и есть SRE.