Основы облака
IAM-роли и least privilege, VPC и public/private подсети, security groups против NACL, группы автоскейлинга, регионы и зоны доступности, контроль затрат.
10 вопросов
JuniorТеорияОчень частоЧем облачный регион отличается от зоны доступности (availability zone)?
Чем облачный регион отличается от зоны доступности (availability zone)?
Регион — географическая область; зона доступности (AZ) — изолированный дата-центр внутри неё со своим питанием, охлаждением и сетью. AZ отказывают независимо, но связаны каналами с низкой задержкой, поэтому запуск по AZ — базовая единица высокой доступности. Multi-region дороже, в основном для disaster recovery.
Типичные ошибки
- ✗Думать, что один регион с множеством инстансов защищает от отказа зоны
- ✗Считать multi-region дешёвым выбором по умолчанию, а не дорогим DR
- ✗Считать, что AZ делят питание и сеть и потому отказывают вместе
Уточняющие вопросы
- →По скольким AZ вы бы распределили сервис для продакшен-доступности?
- →Какие лишние затраты появляются при добавлении второго региона для DR?
SeniorДизайнОчень частоСпроектируйте высокодоступный веб-слой в одном облачном регионе для stateless HTTP-сервиса, который должен пережить отказ целой зоны доступности без простоя. За ним — управляемая реляционная БД, трафик непредсказуемый и рваный. Опишите, как размещаете compute по зонам, как трафик доходит до здоровых инстансов, как слой скейлится под нагрузкой и что происходит с текущими и новыми запросами, когда одна зона гаснет. Явно про health-проверки, число зон, собственный failover БД и почему просто больше инстансов сами по себе не дают высокой доступности. Назовите устранённые точки отказа и те, что осознанно приняли.
Спроектируйте высокодоступный веб-слой в одном облачном регионе для stateless HTTP-сервиса, который должен пережить отказ целой зоны доступности без простоя. За ним — управляемая реляционная БД, трафик непредсказуемый и рваный. Опишите, как размещаете compute по зонам, как трафик доходит до здоровых инстансов, как слой скейлится под нагрузкой и что происходит с текущими и новыми запросами, когда одна зона гаснет. Явно про health-проверки, число зон, собственный failover БД и почему просто больше инстансов сами по себе не дают высокой доступности. Назовите устранённые точки отказа и те, что осознанно приняли.
Распределите stateless-инстансы по двум — лучше трём — зонам доступности за балансировщиком, который health-проверяет каждую цель и шлёт трафик только на здоровые. Поместите флот в группу автоскейлинга по этим зонам, чтобы она росла под нагрузкой и заменяла упавшие узлы. Держите БД в multi-AZ с failover. Много инстансов в одной зоне — не HA.
Типичные ошибки
- ✗Считать число инстансов в одной зоне высокой доступностью
- ✗Полагаться на round-robin DNS без балансировщика и health-проверок
- ✗Забывать, что самой БД нужен multi-AZ failover, а не только веб-слою
Уточняющие вопросы
- →Почему три зоны предпочтительнее двух для расчёта мощности ASG?
- →Как connection draining и health-проверки обрабатывают текущие запросы при failover?
JuniorТеорияЧастоЧто такое VPC и чем публичная подсеть отличается от приватной?
Что такое VPC и чем публичная подсеть отличается от приватной?
VPC — ваша изолированная виртуальная сеть в облаке, разбитая на подсети по зонам доступности. У публичной подсети есть маршрут к internet gateway, поэтому её инстансы смотрят в интернет; у приватной его нет, поэтому инстансы недостижимы снаружи и выходят через NAT. Security groups поверх — stateful-файрвол на инстанс.
Типичные ошибки
- ✗Менять местами определения публичной и приватной подсети
- ✗Считать VPC общей для арендаторов, а не изолированной на аккаунт
- ✗Называть security groups stateless, требующими ручных обратных правил
Уточняющие вопросы
- →Почему приватной подсети нужен NAT gateway для исходящих обновлений?
- →Чем security groups отличаются от network ACL на уровне подсети?
MiddleДебаггингЧастоГруппа автоскейлинга остаётся прежнего размера под высокой нагрузкой и не добавляет инстансы — почему?
Группа автоскейлинга остаётся прежнего размера под высокой нагрузкой и не добавляет инстансы — почему?
Мешают два. Первое: max равен desired на 4, поэтому группа не может добавить инстансы, даже если политика сработает, — поднимите max. Второе: политика следит за CPU 70%, но запросы I/O-bound и CPU на 34%, порог не срабатывает; скейльте по сигналу спроса — числу запросов или очереди. Cooldown активность не маскирует.
Открыть задачу →Типичные ошибки
- ✗Упустить, что max равен desired, не оставляя запаса для расширения
- ✗Скейлить по CPU на I/O-bound нагрузке, из-за чего порог не срабатывает
- ✗Считать, что desired может превысить max или что CPU — единственная метрика
Уточняющие вопросы
- →Какую метрику вы бы взяли для флота обработчиков очереди вместо CPU?
- →Как окна cooldown или warm-up мешают скейлингу осциллировать?
MiddleДизайнЧастоВам достаётся облачный счёт, удвоившийся за год. Обстановка: фиксированный флот крупных VM под прошлогодний пик, работающих 24/7 при ~15% средней загрузки CPU, база на три тира выше реальной нагрузки, терабайты старых логов и бэкапов на самом быстром классе хранилища и месячная строка egress, которую никто не может объяснить. Автоскейлинга нет нигде. Разберите проход по оптимизации затрат: как найти, куда уходят деньги, какие рычаги дёргать первыми и как срезать расходы, не роняя надёжность и не ловя пейджер. Конкретно про right-sizing, скейлинг, тиры хранилища и egress, и что вы измерите до и после.
Вам достаётся облачный счёт, удвоившийся за год. Обстановка: фиксированный флот крупных VM под прошлогодний пик, работающих 24/7 при ~15% средней загрузки CPU, база на три тира выше реальной нагрузки, терабайты старых логов и бэкапов на самом быстром классе хранилища и месячная строка egress, которую никто не может объяснить. Автоскейлинга нет нигде. Разберите проход по оптимизации затрат: как найти, куда уходят деньги, какие рычаги дёргать первыми и как срезать расходы, не роняя надёжность и не ловя пейджер. Конкретно про right-sizing, скейлинг, тиры хранилища и egress, и что вы измерите до и после.
Начните со счёта и метрик использования, чтобы найти крупные строки, а не гадать. Уменьшите переразмеренные VM и базу до реальной нагрузки и поставьте фиксированный флот за автоскейлинг, чтобы простой сжимался вне пика. Переместите холодные логи и бэкапы в архивные тиры, отследите egress и зарезервируйте базу.
Типичные ошибки
- ✗Гадать об экономии вместо старта со счёта и метрик использования
- ✗Размерять по пику, игнорируя низкую среднюю загрузку
- ✗Резать вслепую (удалять данные, жать до минимума), роняя надёжность
Уточняющие вопросы
- →Как резервирования или savings plans меняют гибкость на скидку?
- →Какое lifecycle-правило вы зададите для логов старше 30 дней?
MiddleДизайнЧастоВаша команда развивает веб-продукт на облачных VM, и нужна основная реляционная база. Один лагерь хочет полностью управляемый сервис БД; другой — self-host того же движка на своих инстансах внутри VPC ради экономии и без lock-in. Трафик рваный, команда небольшая, выделенного DBA нет, а нужны point-in-time recovery, multi-AZ failover и RPO в минуты. Разберите, как вы выбираете между управляемым сервисом и self-host: что каждая опция кладёт на вас операционно, где реальные затраты и риск и что склонит вас к тому или иному. Сформулируйте рекомендацию и условия, при которых верным был бы обратный выбор.
Ваша команда развивает веб-продукт на облачных VM, и нужна основная реляционная база. Один лагерь хочет полностью управляемый сервис БД; другой — self-host того же движка на своих инстансах внутри VPC ради экономии и без lock-in. Трафик рваный, команда небольшая, выделенного DBA нет, а нужны point-in-time recovery, multi-AZ failover и RPO в минуты. Разберите, как вы выбираете между управляемым сервисом и self-host: что каждая опция кладёт на вас операционно, где реальные затраты и риск и что склонит вас к тому или иному. Сформулируйте рекомендацию и условия, при которых верным был бы обратный выбор.
Управляемый сервис снимает большую часть операционной рутины — патчинг, бэкапы, point-in-time recovery, multi-AZ failover и мониторинг встроены — ценой цены и lock-in. Self-host дешевле по часам, но теперь на вас HA, бэкапы, апгрейды и on-call, что маленькая команда без DBA редко делает хорошо. Здесь рекомендую managed.
Типичные ошибки
- ✗Сравнивать лишь почасовую цену, игнорируя операционную стоимость self-host
- ✗Считать, что управляемый значит, что провайдер владеет вашими данными и целями
- ✗Думать, что маленькая команда сделает HA и PITR руками не хуже сервиса
Уточняющие вопросы
- →Какие конкретные виды lock-in создаёт управляемая БД и как их ограничить?
- →При каком размере команды или масштабе self-host начнёт окупаться?
JuniorТеорияИногдаЧто такое эластичность (elasticity) в облаке и чем она отличается от масштабируемости?
Что такое эластичность (elasticity) в облаке и чем она отличается от масштабируемости?
Масштабируемость — способность выдержать больше нагрузки, добавляя мощность; эластичность — делать это автоматически в обе стороны: расширяться при росте спроса и сжиматься при спаде. Горизонталь добавляет инстансы за балансировщиком, вертикаль увеличивает один. Автоскейл — по сигналу реального спроса.
Типичные ошибки
- ✗Считать эластичность и масштабируемость синонимами, упуская авто в обе стороны
- ✗Считать, что эластичность — только вертикаль, игнорируя горизонтальный scale-out
- ✗Скейлить по сигналу без связи со спросом вместо отражающего реальную нагрузку
Уточняющие вопросы
- →Когда вертикальное масштабирование уместнее горизонтального scale-out?
- →Почему автоскейлинг по CPU обманчив для I/O-bound сервиса?
MiddleТеорияИногдаКогда стоит идти в multi-region вместо multi-AZ, и чего это стоит?
Когда стоит идти в multi-region вместо multi-AZ, и чего это стоит?
Multi-AZ — единица HA: инстансы по изолированным зонам одного региона переживают отказ одного дата-центра при репликации с низкой задержкой. В multi-region идут только ради disaster recovery при отказе целого региона или ради задержки. Это дороже — межрегиональная репликация, egress, сложнее консистентность и failover.
Типичные ошибки
- ✗Считать multi-region дешёвым дефолтом, а не дорогим DR
- ✗Утверждать, что multi-AZ не переживает потерю одной зоны
- ✗Забывать про межрегиональную репликацию, egress и цену консистентности
Уточняющие вопросы
- →Какие проблемы консистентности возникают, когда БД охватывает два региона?
- →Как проверить план failover региона без реального отказа?
SeniorДебаггингИногдаПродакшен-сервис полностью упал, когда отказала одна зона доступности облака — в чём изъян дизайна?
Продакшен-сервис полностью упал, когда отказала одна зона доступности облака — в чём изъян дизайна?
Все слои жили в одной зоне, eu-1a, поэтому с её отказом упал весь стек — шесть инстансов в одной зоне это резерв против потери инстанса, а не зоны. Фикс: подсети и группа автоскейлинга по двум-трём зонам, балансировщик с health-проверками и БД в multi-AZ со standby и failover. Потеря зоны срежет мощность, а не доступность.
Открыть задачу →Типичные ошибки
- ✗Винить число инстансов, когда изъян — размещение в одной зоне
- ✗Утверждать, что регион всегда падает целиком, и спасает лишь multi-region
- ✗Винить софт балансировщика вместо одно-зонной топологии
Уточняющие вопросы
- →Какое минимальное изменение удержало бы сервис живым в эту аварию?
- →Как доказать, что перепроектированный сервис переживёт потерю зоны заранее?