Ответ
Тестирование отказоустойчивости (Failover Testing) — это тип нефункционального тестирования, который проверяет способность распределенной системы автоматически переключать нагрузку с отказавшего основного компонента (сервер, база данных, сетевое соединение) на резервный с минимальным временем простоя и без потери данных.
Основные цели:
- Верификация автоматического восстановления. Система должна обнаружить сбой и выполнить переключение без ручного вмешательства.
- Измерение ключевых метрик:
- RTO (Recovery Time Objective): Максимально допустимое время восстановления работы после сбоя.
- RPO (Recovery Point Objective): Максимальный объем данных (по времени), допустимый к потере (например, транзакции за последние 5 секунд).
- Проверка целостности данных и сессий после переключения.
Типичный сценарий для веб-приложения с балансировщиком нагрузки:
# 1. Система в нормальном состоянии: трафик идет на Primary Server.
# 2. Имитация сбоя:
sudo systemctl stop nginx # Остановка веб-сервера на основном узле
# или
sudo iptables -A INPUT -p tcp --dport 80 -j DROP # Блокировка порта
# 3. Ожидаемое поведение системы:
# - Мониторинг (например, Health Check от Load Balancer) обнаруживает недоступность Primary.
# - Load Balancer исключает узел из пула и перенаправляет трафик на Standby Server.
# - Пользователи могут испытывать короткую задержку, но не теряют активные сессии.
# - Критичные транзакции не теряются (журналируются или реплицируются).Что тестируется:
- Отказ сервера приложения или базы данных.
- Обрыв сетевого соединения или сбой DNS.
- Отказ диска или аппаратного компонента.
- Перегрузка одного из узлов кластера.
Инструменты: Для автоматизации таких тестов используются Chaos Engineering инструменты (Chaos Monkey, Gremlin), средства оркестрации (Kubernetes, который может перезапускать поды) и скрипты для имитации сбоев.
Ответ 18+ 🔞
А, слушай, вот эта вся хуйня про отказоустойчивость! Это ж надо же, какие умные слова придумали: «фейловер тестинг». А по-нашему, по-простому — «а что будет, если вот эту хреновину посреди работы вырубить?».
Суть-то, блядь, проще пареной репы. Есть у тебя система, на ней народ работает, деньги считает, котиков лайкает. И тут — хрясь! — основной сервак накрылся медным тазом. И что? Все в пизду, сессия потерялась, корзина с заказом испарилась, а пользователь сидит и думает: «Ну и нахуй я сюда заходил?». Так вот, чтобы этого не было, умные дядьки и придумали эту самую «отказоустойчивость». То есть система должна быть хитрожопой: почуяв, что один узел загнулся, она должна, не спрашивая ни у кого разрешения, перекинуть всю движуху на запасной. Автоматом, блядь! Чтобы юзер даже не успел матюгнуться.
И главное, что нам надо проверить, ёпта:
- Самостоятельность системы. Чтобы она сама, как взрослая, поняла, что её кусок сдох, и переключилась. Без наших криков «ой, бля, ребята, врубайте резерв!».
- Циферки, блядь! Надо засечь, сколько времени она тупит, пока переключается. Это и есть RTO — время, за которое всё должно ожить. И сколько данных нахуячится — RPO. Допустим, если сбой случился, можно потерять транзакции за последние пару секунд, но не за последний час, иначе это пиздец, а не система.
- Чтобы ничего не потерялось. Зашел ты в личный кабинет, положил в корзину слона, а после переключения корзина пуста, а вместо слона — ошибка 500. Вот это — полный ахтунг и доверия ебать ноль.
Вот, смотри, как это примерно выглядит на практике, представь веб-приложение:
# 1. Всё спокойно, трафик пыхтит на основном серваке.
# 2. А мы, злые гении, ему впендюрим сбой:
sudo systemctl stop nginx # Ёбнем веб-сервер на главной тачке
# Или, для верности, можно сеть ему порвать:
# sudo iptables -A INPUT -p tcp --dport 80 -j DROP
# 3. И наблюдаем, что будет. В идеале:
# - Балансировщик, который постоянно стучится к серваку (Health Check), понимает: «Э, сука, тут труп».
# - Он молча, по-английски, вычёркивает этот сервер из списка и начинает гнать трафик на запасной.
# - Пользователь может моргнуть разок от удивления, но его сессия жива, корзина на месте.А что вообще ломать будем? Да всё, что плохо лежит!
- Сервер приложения взял и лег.
- База данных решила отдохнуть.
- Сеть — хуй с горы — пропала.
- Диск треснул, блядь.
- Один узел в кластере так нагрузили, что он просто сдох от натуги.
Чем это всё автоматизировать? Да есть же целая куча инструментов для бардака! Chaos Monkey, например, который специально в продакшене хуйню вытворяет, чтобы проверить, не развалится ли всё. Или всякие оркестраторы вроде Kubernetes — они сами умеют поды перезапускать, если те загнулись. Короче, создают управляемый пиздец, чтобы в будущем не получить пиздец неуправляемый.
Вот и вся наука. Сделать так, чтобы система была не как однорукий очкарик, а как гидру: отрубишь одну голову — вырастет другая, и всё продолжает работать. А то без этого — чих-пых тебя в сраку, и бизнес накрылся.