Доступность: план SLO и failover с нуля
Практический проект: возьми бриф продукта, выведи его SLI/SLO и бюджет ошибок, выследи каждую единую точку отказа и спроектируй резервирование и failover, чтобы их убрать, затем докажи, что твой failover и деградация работают, малым chaos-тестом, что инъецирует отказы.
Прочитать, что надо определять SLO и убирать единые точки отказа, — не то же, что выдать дизайн доступности, под которым подпишется staff-инженер. Возьми реалистичный по форме бриф продукта, напиши его SLI и SLO с бюджетом ошибок, замапь и устрани каждый SPOF верным резервированием и failover, а затем докажи два самых рискованных утверждения — что failover реально восстанавливает и что система деградирует, а не темнеет — малым chaos-тестом, что напишешь сам.
Этот проект делает весь раздел операционным: ты выберешь SLI, ориентированные на пользователя, и поставишь SLO под SLA, выведешь бюджет ошибок, выследишь SPOF и спроектируешь резервирование и failover, что держатся под коррелированным отказом, а затем измеришь — инъецируешь отказы и подтвердишь, что система восстанавливается в пределах цели и деградирует плавно, а не отказывает целиком.
Сделай полный дизайн доступности для выбранного продукта (например сокращатель ссылок, платёжный API или чат-бэкенд): определи его SLI, SLO и бюджет ошибок; замапь и устрани каждую единую точку отказа уместно размеренным резервированием и планом failover; затем собери малый chaos-тест, что инъецирует отказы и эмпирически подтверждает, что failover восстанавливает в пределах цели и что система деградирует плавно — замыкая петлю между дизайном и отказами, которые он берётся пережить.
- Лист SLI/SLO/бюджета-ошибок: 2-3 ориентированных на пользователя SLI с тем, где каждый измеряется, SLO на SLI жёстче SLA, посчитанный бюджет ошибок за окно и политика для наполовину истраченного и исчерпанного бюджета — читается за две минуты.
- Таблица SPOF, что покрывает всю архитектуру (включая общую инфру и не-машинные SPOF), каждая строка с устранением: уровень резервирования (N+1/N+2), размещение по доменам отказа и active-active против active-passive с заявленным трейдоффом.
- План failover, называющий механизм обнаружения и его трейдофф таймаута, шаги продвижения/перенаправления, защиту от split-brain (кворум или fencing) и настройки таймаут/бюджет-ретраев/backoff-с-jitter, что удерживают восстановление от превращения в retry storm.
- Рабочий chaos-тест, чьё измеренное время восстановления после убийства активного узла отчитано против цели failover, плюс прожиг бюджета ошибок, что съел смоделированный инцидент.
- Демонстрация graceful degradation (принуждённая лечь зависимость даёт деградировавший-но-работающий ответ) и безопасности ретраев (тот же отказ с и без backoff-и-jitter, показывающий, что шторм предотвращён).
- Короткий разбор: один абзац о том, какой SPOF был наименее очевидным и как ты его нашёл, и один — где измеренное chaos-тестом восстановление разошлось с допущением дизайна и почему.
- Добавь тест коррелированного отказа: размести обе реплики в одном смоделированном домене отказа, положи домен и покажи, что «зарезервированная» пара отказывает вместе; затем перемести их в независимые домены и покажи, что переживает — оцифровав разницу в доступности.
- Добавь демонстрацию split-brain: раздели primary от резерва без fencing/кворума и покажи расхождение; затем включи fencing или кворум и покажи, что неверный вызов «мёртв» становится безвредным.
- Смоделируй девятки: из измеренного MTBF (инъецированной частоты отказов) и MTTR (измеренного восстановления) посчитай доступность ≈ MTBF/(MTBF+MTTR) и покажи, какая инвестиция — отказывать реже против восстанавливаться быстрее — двигает достижимый SLO сильнее.
- Добавь open-loop воспроизведение retry storm: держи зависимость медленной, прогони клиентов с наивными немедленными ретраями против бюджета ретраев с backoff-и-jitter и построй усиление нагрузки, что каждый производит на борющейся зависимости.
- 01Что дизайн доступности производит до любого chaos-теста и как каждая часть связана?
- 02Как подтвердить failover и graceful degradation в chaos-тесте и что измеряешь?
- 03Почему проектировать SLO и устранение SPOF сначала, а потом chaos-тестить, а не просто chaos-тестить?
Этот проект превращает раздел доступности в повторяемый воркфлоу: возьми бриф продукта, определи ориентированные на пользователя SLI (отношения хороших/валидных, измеренные близко к пользователю), поставь SLO жёстче SLA и посчитай бюджет ошибок с политикой траты. Затем выследи каждый SPOF мысленным экспериментом над каждым прямоугольником и линией — включая общую инфраструктуру и не-машинные SPOF — и убери каждый резервированием, размеренным до N+1 под пик, размещённым в независимых доменах отказа, выбирая active-active или active-passive с заявленным трейдоффом. Напиши план failover (обнаружение и его трейдофф таймаута, продвижение/перенаправление, защита от split-brain через кворум или fencing и storm-безопасные таймауты/ретраи/backoff-с-jitter) и поведения graceful degradation, чтобы смерть зависимости была пропавшей фичей, а не пустой страницей. Затем замкни петлю chaos-тестом: убей активный узел и измерь восстановление против цели, принуди зависимость лечь и подтверди деградацию, и воспроизведи retry storm с и без backoff-и-jitter. Дизайн сначала и chaos-тест вторым — вся дисциплина: бумажный дизайн говорит, что должно пережить, тест подтверждает, что переживает. Инженер, что построил это однажды, проектирует под отказ осознанно, а не обнаруживает свои SPOF и свой split-brain во время инцидента в 3 ночи.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.