scalability-reliability

Требования к масштабируемости и надежности

📚 22 вопросовПройти тест →
Лекция

Требования к масштабируемости и надежности

scalability-reliability

Требования к масштабируемости и надежности

Введение: супермаркет в час пик 🧺

В обычный день касс хватает. В час пик очередь растёт — и магазин теряет клиентов.
С продуктом так же: если нагрузка выросла, а система не тянет — пользователи уходят.
Требования к масштабируемости и надежности говорят сколько пользователей и как долго система должна выдерживать,
и что будет, если что‑то ломается.
💡 Совет: масштабируемость без надежности — это быстрый путь к большому падению.
✅ Вывод: эти требования защищают продукт от «пиков» и аварий.

Проблема: «на старте всё летает, а потом падает» ❌

Без требований:
  • инфраструктура не готова к росту;
  • один сбой «кладёт» весь сервис;
  • бизнес теряет деньги и доверие.
С требованиями:
  • понятно, сколько нагрузки нужно выдержать;
  • есть план резервирования и восстановления;
  • QA и DevOps могут проверить готовность.
✅ Вывод: без требований масштаб и надёжность невозможно контролировать.

Чем помогает и как работает

  • Помогает заранее согласовать пределы системы: сколько пользователей, какая задержка и какой объём отказов допустим.
  • Помогает QA и DevOps построить проверку: нагрузочные тесты, мониторинг и аварийные прогоны.
  • Помогает бизнесу считать риск: сколько стоит простой и сколько данных можно потерять.
Как это работает:
  • Шаг 1: фиксируем профиль нагрузки (база, пик, прогноз роста).
  • Шаг 2: задаём цели качества (p95, SLI/SLO/SLA, error rate).
  • Шаг 3: описываем отказоустойчивость (резервирование, failover, без SPOF).
  • Шаг 4: задаём параметры восстановления (RTO/RPO, бэкапы, DR-план).
  • Шаг 5: согласуем критерии приёмки и способ проверки.
✅ Вывод: требования превращают "должно быть стабильно" в проверяемые цифры.

Ключевые термины (простыми словами)

  • Scalability (масштабируемость) — способность системы расти по нагрузке.
  • Availability (доступность) — процент времени, когда сервис доступен.
  • Reliability (надёжность) — способность работать без сбоев в течение времени.
  • Fault tolerance (отказоустойчивость) — умение переживать сбои компонентов.
  • Redundancy (резервирование) — дублирование критичных частей.
  • Failover (переключение) — автоматический переход на резерв.
  • SLA / SLO / SLI — соглашение, цель и измеритель качества сервиса.
  • RTO / RPO — время восстановления и допустимая потеря данных.
  • Capacity (ёмкость) — сколько нагрузки выдержит система.
  • Load profile (профиль нагрузки) — пики и «обычная» нагрузка.
✅ Вывод: это базовые слова, которыми описывают устойчивость продукта.

Самое важное (must‑know)

  • Масштабируемость всегда задаётся числами: rps/concurrency + latency (например p95).
  • Надёжность и доступность не равны друг другу: reliability про сбои, availability про время доступности.
  • SLI -> SLO -> SLA должны быть связаны, иначе невозможно управлять качеством.
  • Без резервирования и failover остаётся единая точка отказа.
  • RTO/RPO обязательно согласуются с бизнесом и влияют на архитектуру бэкапов.
✅ Вывод: без этих пунктов требования будут неполными и плохо проверяемыми.

1. Масштабируемость: вертикальная и горизонтальная

Назначение: обеспечить рост нагрузки без деградации.
Простыми словами: система должна выдерживать рост пользователей без заметного ухудшения скорости.
Аналогия: добавить больше касс вместо того, чтобы ускорять одну.
Пример:
Система выдерживает 2000 одновременных пользователейпри p95 <= 400 мс на ключевых эндпоинтах.
🔎 Как это происходит на практике:
  1. Аналитик фиксирует целевой пик и задержку p95.
  2. DevOps готовит среду под ожидаемую нагрузку.
  3. QA запускает нагрузочный тест по сценарию пика.
  4. Команда смотрит метрики и корректирует узкие места.
Характеристики:
  • ✅ горизонтальная — добавляем серверы;
  • ✅ вертикальная — усиливаем один сервер;
  • ✅ измеряется rps, concurrency, latency.
Когда использовать: при росте аудитории или сезонных пиках.
✅ Вывод: масштабируемость = готовность к росту.

2. Надёжность и доступность (SLA/SLO/SLI)

Назначение: зафиксировать, сколько времени система должна быть доступна.
Простыми словами: мы заранее определяем, какой уровень стабильности обязаны держать в продакшене.
Аналогия: график работы магазина — сколько часов он открыт для клиентов.
Пример:
SLO: 99.9% uptime в месяц.SLI: доля успешных запросов к /api.SLA: штрафы, если SLO не выполнено.
🔎 Как это происходит на практике:
  1. Команда выбирает SLI: uptime, error rate, latency.
  2. Для каждого SLI задаётся целевая планка SLO.
  3. SLA оформляет внешние обязательства перед клиентом.
  4. Мониторинг регулярно проверяет выполнение SLO.
Характеристики:
  • ✅ доступность измеряется в процентах времени;
  • ✅ надёжность — отсутствие сбоев;
  • ✅ SLI → SLO → SLA задают логику контроля.
Когда использовать: для всех критичных сервисов.
✅ Вывод: без SLO невозможно управлять качеством сервиса.

3. Отказоустойчивость и резервирование

Назначение: пережить сбой без остановки сервиса.
Простыми словами: если один компонент упал, сервис продолжает работать за счёт резерва.
Аналогия: запасной генератор, который включается при отключении электричества.
Пример:
База данных имеет реплику; при отказе мастер‑ноды происходит failover за 1 минуту.
🔎 Как это происходит на практике:
  1. База работает в режиме primary + replica.
  2. Health-check обнаруживает отказ основной ноды.
  3. Orchestrator переключает трафик на резерв.
  4. Пользователь видит короткую деградацию, но не полный простой.
Характеристики:
  • ✅ нет единой точки отказа;
  • ✅ есть резервные компоненты;
  • ✅ failover описан и измерим.
Когда использовать: в платежах, логине, ключевых сервисах.
✅ Вывод: резервирование = страховка бизнеса.

4. Ёмкость и рост нагрузки

Назначение: понимать пределы и планировать масштаб.
Простыми словами: мы считаем, сколько система держит сейчас и когда потребуется расширение.
Аналогия: вместимость зала — сколько людей можно принять без давки.
Пример:
Пик 300 rps в 19:00–21:00, базовая нагрузка 80 rps.Рост аудитории: +30% за квартал.
🔎 Как это происходит на практике:
  1. Аналитик строит профиль дневной и сезонной нагрузки.
  2. Команда определяет пороги деградации по latency/error rate.
  3. Инфраструктура масштабируется заранее перед пиковым периодом.
  4. После пика параметры пересматриваются на следующий цикл.
Характеристики:
  • ✅ есть пиковая нагрузка;
  • ✅ есть план роста;
  • ✅ есть пороги деградации.
Когда использовать: при планировании инфраструктуры и бюджета.
✅ Вывод: без ёмкости система растёт «вслепую».

5. Восстановление: RTO и RPO

Назначение: описать, как быстро мы должны восстановиться.
Простыми словами: заранее фиксируем, сколько времени и данных можно потерять при аварии.
Аналогия: резервная копия телефона — сколько данных можно потерять и как быстро вернуть.
Пример:
RTO: 30 минут. RPO: 5 минут.
🔎 Как это происходит на практике:
  1. Бизнес определяет допустимый простой и потерю данных.
  2. Техкоманда подбирает стратегию бэкапов под эти лимиты.
  3. Регулярно проводится drill восстановления.
  4. Если фактический RTO/RPO хуже цели, архитектуру усиливают.
Характеристики:
  • ✅ RTO = сколько времени можно быть «вниз»;
  • ✅ RPO = сколько данных можно потерять;
  • ✅ влияет на бэкапы и архитектуру.
Когда использовать: для всех систем с данными и платежами.
✅ Вывод: RTO/RPO превращают «быстро восстановиться» в цифры.

Сравнение: масштабируемость, надёжность, доступность

ПараметрО чёмПример
Масштабируемостьрост нагрузки2000 пользователей без деградации
Надёжностьстабильность работыминимальный error rate
Доступностьвремя без простоев99.9% uptime

Часто спрашивают на собеседованиях

  • Разница между availability и reliability? доступность vs устойчивость к сбоям.
  • Что такое SLA/SLO/SLI? измерение и цели качества сервиса.
  • Что означают RTO и RPO? время восстановления и потеря данных.
  • Что такое failover и зачем он нужен? переключение на резерв.
  • Как измерять масштабируемость? через rps, concurrency, latency.
✅ Вывод: эти вопросы — база для интервью по надёжности.

Типичные ошибки

Ошибка 1: «будет справляться с ростом» без цифр

❌ «Система масштабируется»
✅ «2000 пользователей при p95 <= 400 мс»

Ошибка 2: нет SLO

❌ «Высокая доступность»
✅ «SLO 99.9% в месяц»

Ошибка 3: единая точка отказа

❌ один сервер/одна БД
✅ резервирование и реплика

Ошибка 4: нет RTO/RPO

❌ «восстановимся быстро»
✅ «RTO 30 мин, RPO 5 мин»

Ошибка 5: не описан профиль нагрузки

❌ «нагрузка средняя»
✅ пики + базовые значения

Best Practices

  • Фиксируйте цифры: rps, concurrency, p95.
  • Используйте SLI → SLO → SLA.
  • Проектируйте без единой точки отказа.
  • Обязательно описывайте failover и резервирование.
  • Согласуйте RTO/RPO с бизнесом.
  • Планируйте рост нагрузки заранее.

Заключение

Ключевые мысли

🎯 Масштабируемость отвечает за рост без деградации.
🎯 Надёжность и доступность защищают от простоев.
🎯 RTO/RPO делают восстановление управляемым.
Теперь вы умеете превращать «сервис должен выдержать рост» в проверяемые требования.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Требования к масштабируемости и надежности»

Пройти тест →