Доступность: обзор с выбором ответа
Синтез всего раздела доступности в формате с выбором ответа: SLI/SLO/SLA и девятки, бюджеты ошибок, размер резервирования и коррелированный отказ, а также ловушки failover/split-brain/retry-storm, что превращают восстановление в сбой.
Шесть вопросов через весь раздел. Каждый — суждение, которое ты выносишь, когда пишешь SLO, размеряешь резервирование, ревьюишь дизайн failover или читаешь постмортем: не определение для пересказа, а рассуждение о том, где ставить цель, что считается зарезервированным и почему failover превратился в сбой.
Подтверди, что умеешь поставить SLO под SLA, сделать арифметику девяток и сложения доступности, потратить бюджет ошибок, размерить резервирование до N+1 под пик, заметить коррелированный отказ за «зарезервированными» копиями и распознать split-brain и retry storm.
Клиентский SLA обещает 99,9% месячной доступности с кредитами за промахи. Где ставишь внутренний SLO и почему?
Твой SLO — 99,99% успешных запросов за 28 дней. Примерно сколько простоя/отказа это разрешает в месяц и что представляет остаток?
Путь запроса — четыре независимых последовательных компонента, каждый на 99,9% доступности. Какова доступность пути и урок дизайна?
Сервису нужно 4 сервера, чтобы нести пик, и он держит ровно 4, зовя себя зарезервированным. Один умирает в пик. Каков вердикт?
Две реплики БД гоняют «ради резервирования», но обе сидят в одной зоне доступности. AZ теряет питание. Что это вскрывает?
Сетевое разделение изолирует primary от резерва; резерв продвигает себя, пока primary жив и принимает записи. Что это и что это предотвращает?
- 01Почему «две реплики, обе в одной AZ» проваливают тест на резервирование?
- 02Какой единственный ход дизайна предотвращает split-brain при сетевом разделении?
Сквозная линия раздела — доступность это рассуждение, которое ты делаешь до инцидента. Ты ставишь SLO под SLA, чтобы внутренний пробой предупредил до того, как будешь должен кредиты; делаешь арифметику девяток (99,9% ≈ 43 мин/мес, 99,99% ≈ 4,3 мин, 99,999% ≈ 26 с) и помнишь, что доступность умножается по последовательным зависимостям, так что путь из четырёх звеньев по 99,9% — лишь ~99,6%. Бюджет ошибок (100% − SLO) превращает надёжность в тратимый ресурс. Ты размеряешь резервирование до N+1 под пик, а не среднее, и размещаешь копии в независимых доменах отказа, ведь две реплики, делящие AZ, — это коррелированный отказ, а не резервирование. И ты проектируешь failover под неверное обнаружение: кворум или fencing против split-brain, ограниченные таймауты и ограниченные ретраи с backoff-и-jitter против retry storm, чтобы восстановление не стало следующим сбоем — а доступность ≈ MTBF/(MTBF+MTTR) напоминает, что быстрое отрепетированное восстановление (MTTR) обычно бьёт погоню за более высоким MTBF.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.