Отказоустойчивость

Девятки в часах

Проценты доступности ничего не значат, пока их не перевести во время. В году 8760 часов. 99 процентов - это 87,6 часа простоя, трое с половиной суток. 99,9 - 8,8 часа. 99,99 - 53 минуты. 99,999 - около пяти минут в год, и такое обещают единицы.

Каждая девятка стоит примерно на порядок дороже предыдущей: резервирование узлов, автоматическое переключение, дежурная смена, учения. Поэтому цифру называет бизнес, посчитав цену часа простоя, а не архитектор из вежливости.

// И сразу уточняют, что считается простоем и на каком окне. «Не оформляется заказ» и «медленно грузится карточка» - разные события с разной ценой; месячное окно и годовое дают разный запас на один инцидент.

Деградация вместо отказа

Упал сервис рекомендаций. Вариант первый: страница товара не открывается совсем. Вариант второй: открывается без блока «похожие товары», человек спокойно покупает. Разница между вариантами - одна строчка в требованиях, написанная заранее.

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

// Единая точка отказа - узел без резерва, чьё падение останавливает всё: одиночная база, единственный сервис авторизации, общая очередь. Их либо резервируют, либо явно принимают риск и пишут, что происходит при их падении.

деградация

осознанный отказ от второстепенных функций ради сохранения главного сценария

Как медленный сосед укладывает тебя

У сервиса пул на 200 одновременных обработчиков. Обычно сосед отвечает за 50 миллисекунд, приходит 100 запросов в секунду - занято около пяти обработчиков, запас огромный. Сосед начал отвечать за 30 секунд. Теперь каждый запрос держит обработчик тридцать секунд, приходит их сотня в секунду - пул кончается через две секунды. Дальше твой сервис не отвечает никому, включая тех, кому сосед вообще не нужен. Это каскадный отказ.

Таймаут превращает зависание в обычную ошибку, на которую можно ответить. Поставили две секунды - одновременно занято 100 умножить на 2, то есть 200 обработчиков, ровно весь пул. Значит нужен ещё и лимит на число параллельных вызовов соседа, скажем 50, а остальным сразу отдавать деградацию.

// Размыкатель цепи добавляет памяти: увидел подряд серию ошибок - перестал звонить соседу на минуту и сразу отдаёт запасной ответ. Соседу дают отдышаться, свой пул цел, пользователь видит понятное сообщение вместо тридцатисекундного ожидания.

размыкатель цепи

переключатель, который после серии ошибок перестаёт слать запросы отказавшему соседу и пробует снова через паузу

RPO, RTO и учения

Два числа, которые заказывает бизнес. RPO (recovery point objective) - какой объём данных не жалко потерять, выраженный временем: «не больше пяти минут записей». RTO (recovery time objective) - за сколько система обязана вернуться в строй: «полчаса».

Оба прямо превращаются в деньги. RPO в сутки - это ночная копия, дёшево и просто. RPO в пять минут - это журнал транзакций, непрерывно едущий на резервный контур. RTO в полчаса - заранее поднятый резерв и отрепетированное переключение, а не «поднимем из копии, когда найдём человека, который это умеет».

// Резервный контур, который ни разу не переключали, не работает - это правило, а не пессимизм. Конфигурация отстала, сертификат протух, права не выданы, порядок помнит один человек, и он в отпуске. Поэтому в требования кладут регулярные учения с реальным переключением и замером фактического времени: RTO без учений остаётся числом на бумаге.

RPO

допустимый объём потерянных данных, выраженный периодом

RTO

целевое время возврата системы в строй

Как отвечать: «Сформулируй проверяемое требование к отказоустойчивости»

Через три части: сценарий отказа, наблюдаемое поведение и порог времени. Например: при выходе из строя одного узла кластера обслуживание пользовательских запросов восстанавливается не позднее чем за 30 секунд, при этом теряется не больше одной минуты записанных данных. Такое требование воспроизводится на учениях - выключил узел, засёк время - и по нему можно принять работу. «Система должна быть отказоустойчивой» непроверяемо: нет сценария, нет порога, спроектировать под это нельзя и принять тоже. И я бы сразу зафиксировал, что считается простоем: недоступное оформление заказа и медленно грузящаяся карточка - события разной цены, иначе спорить о них будем уже после инцидента.

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

На чём валятся

• −− Пишут «система должна быть отказоустойчивой» без сценария и порога.
• −− Называют проценты доступности, не переведя их в часы простоя и в деньги.
• −− Не описывают поведение при недоступности внешнего сервиса.
• −− Вызывают внешние сервисы без таймаута и без лимита параллельных вызовов.
• −− Полагаются на резервный контур, который ни разу не проверяли переключением.
• −− Задают RPO и RTO, не посчитав, во что обойдётся их достижение.