Вопросы по облакам на собеседовании DevOps

Облако на собесе проверяют не по названиям сервисов конкретного провайдера, а по принципам: где заканчивается зона ответственности провайдера, почему базу держат в приватной подсети, что не так с раздачей файлов через приложение и куда утекает счёт.

Что спрашивают

• +Модели: IaaS и PaaS, управляемые сервисы и их цена, зоны доступности против регионов
• +Сеть: группы безопасности, приватные подсети и NAT-шлюз, приватные эндпоинты вместо публичного маршрута
• +Вычисления: виртуалки, контейнеры и функции, прерываемые машины, что остаётся вашим в управляемом кластере
• +Хранилище и деньги: объектное хранилище и подписанные ссылки, политики жизненного цикла, метки и скрытые статьи расходов

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Модели облаков7
• Объектное хранилище S37
• Вычисления и автоскейл6
• Сеть в облаке6
• Стоимость и РФ-реальность6

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• Модели облаков: IaaS, PaaS, зоны7 вопросов
• Сеть в облаке: VPC, группы, NAT6 вопросов
• Вычисления в облаке: ВМ, spot, managed k8s6 вопросов
• Объектное хранилище S37 вопросов
• Стоимость облака и зеркала артефактов6 вопросов

Примеры вопросов с разбором

1. #dvo_cloud_compute1 / 9
   Прерываемые машины дешевле в разы. Какие нагрузки на них ставят?

   A)Базы данных: репликация всё равно защитит от потери узла

   B)Входные балансировщики: их легко пересоздать

   C)Управляющие узлы кластера: они не держат пользовательский трафик

   D)Пакетные задачи и обработчики очередей

   показать ответ и разбор

   +D)Пакетные задачи и обработчики очередей

   // разбор: Провайдер вправе отобрать такую машину за считанные секунды предупреждения. Значит, годится всё, что можно прервать и повторить: пересчёт отчётов, обработка очередей, сборки, тестовые окружения. Нагрузку с состоянием и точки входа туда не ставят. На практике держат смешанные группы: базовая часть на обычных машинах, пиковая — на прерываемых, с корректной обработкой сигнала об отзыве.

2. #dvo_cloud_cost2 / 9
   Машин стало меньше, а счёт почти не изменился. Что обычно съедает деньги незаметно?

   A)Лицензии на образы операционных систем

   B)Диски, снапшоты, адреса, трафик и логи

   C)Плата за простаивающие сетевые интерфейсы

   D)Наценка за использование нескольких зон доступности

   показать ответ и разбор

   +B)Диски, снапшоты, адреса, трафик и логи

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

3. #dvo_cloud_models3 / 9
   Базу можно взять управляемую у провайдера или поднять свою в кластере. Чем платят за управляемую?

   A)Ценой, ограниченным набором настроек и привязкой к провайдеру

   B)Потерей отказоустойчивости: реплики придётся строить самому

   C)Отсутствием резервного копирования в базовом тарифе

   D)Отсутствием доступа к ней из своего кластера

   показать ответ и разбор

   +A)Ценой, ограниченным набором настроек и привязкой к провайдеру

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

4. #dvo_cloud_network4 / 9
   Базу поместили в приватную подсеть без публичного адреса, но ей нужны обновления пакетов. Как это устроено?

   A)Исходящий доступ идёт через NAT-шлюз, входящий остаётся закрытым

   B)На машину вешают временный публичный адрес на время обновления

   C)Обновления приходят через балансировщик, стоящий перед подсетью

   D)Приватная подсеть выходит наружу напрямую, ограничен только вход

   показать ответ и разбор

   +A)Исходящий доступ идёт через NAT-шлюз, входящий остаётся закрытым

   // разбор: Приватная подсеть не маршрутизируется из интернета. Чтобы машины могли ходить наружу — за пакетами, к API провайдера, к внешним сервисам — ставят NAT-шлюз: он подменяет адрес источника и пропускает только исходящие соединения. Вход остаётся закрытым, доступ инженеров идёт через бастион или VPN. За трафик NAT-шлюза платят отдельно, и на объёмных выгрузках это заметная статья.

5. #dvo_object_storage5 / 9
   Чем объектное хранилище отличается от сетевой файловой системы?

   A)Оно быстрее на мелких файлах за счёт кэша на клиенте

   B)Оно поддерживает права как в POSIX и блокировки файлов

   C)Это хранилище ключ-значение по HTTP, без каталогов и дозаписи

   D)Оно монтируется в систему как обычный диск и работает так же

   показать ответ и разбор

   +C)Это хранилище ключ-значение по HTTP, без каталогов и дозаписи

   // разбор: Объект кладут и забирают целиком по ключу через HTTP-API. Каталогов нет — есть префиксы в имени; частичной перезаписи нет — объект заменяется полностью; блокировок и семантики файловой системы тоже нет. Взамен получают дешёвое хранение практически без предела по объёму, версионирование, политики жизненного цикла и раздачу напрямую клиентам. Монтировать это как диск можно, но поведение будет обманчивым.

6. #dvo_cloud_compute6 / 9
   Перешли на управляемый Kubernetes. Что всё равно остаётся вашей заботой?

   A)Обновление версий, ресурсы и лимиты, сетевые политики, стоимость

   B)Доступность управляющего слоя и резервные копии его состояния

   C)Установка и обновление компонентов управляющего слоя

   D)Ничего существенного: провайдер отвечает за кластер целиком

   показать ответ и разбор

   +A)Обновление версий, ресурсы и лимиты, сетевые политики, стоимость

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

7. #dvo_cloud_cost7 / 9
   Инфраструктура в РФ зависит от зарубежных реестров, образов и сервисов. Как снижают этот риск?

   A)Держат два зарубежных провайдера и переключаются между ними

   B)Переносят всё на отечественные аналоги разом, одним проектом

   C)Зеркалируют артефакты внутрь периметра

   D)Хранят копии образов на ноутбуках инженеров как резерв

   показать ответ и разбор

   +C)Зеркалируют артефакты внутрь периметра

   // разбор: Главный риск — не цена, а внезапная недоступность: реестр перестаёт отдавать образы, репозиторий пакетов режет адреса, лицензия меняется. Лечится зеркалами внутри периметра (образы, пакеты, провайдеры IaC, базовые дистрибутивы), фиксацией версий и регулярной проверкой, что сборка и выкатка проходят при отключённом внешнем доступе. Миграция на отечественные платформы идёт отдельно и по частям, начиная с самого зависимого слоя.

8. #dvo_cloud_models8 / 9
   Сервис держат в трёх зонах доступности одного региона. Зачем не разнести его по регионам?

   A)Между регионами приватной сети у провайдеров нет

   B)Задержка ломает синхронную запись

   C)Балансировщики работают лишь в пределах одного региона

   D)Разные регионы дают разный набор сервисов и версий

   показать ответ и разбор

   +B)Задержка ломает синхронную запись

   // разбор: Зоны в регионе связаны быстрым каналом: синхронная репликация и общий кластер работают без заметных потерь. Между регионами счёт идёт на десятки миллисекунд и выше — синхронная запись становится дорогой, а асинхронная означает потерю данных при переключении. Потому межрегиональную схему строят осознанно, ради катастрофоустойчивости или близости к пользователю, и почти всегда с разделением данных.

9. #dvo_cloud_network9 / 9
   Сервисы одного облака общаются по публичным адресам через интернет-шлюз. Чем это плохо?

   A)Провайдер ограничивает число соединений между своими сервисами

   B)Публичные адреса меняются при перезапуске машин

   C)Задержка, плата за трафик, лишняя открытость

   D)Такой трафик проходит мимо журналов расследования

   показать ответ и разбор

   +C)Задержка, плата за трафик, лишняя открытость

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

Частые вопросы

• Что остаётся на команде при переходе на управляемый Kubernetes?

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

• Как в российском контуре снижают зависимость от зарубежных сервисов?

  Зеркалируют внутрь периметра всё, от чего зависит сборка и выкатка: образы, пакеты, провайдеры инфраструктуры как кода. Фиксируют версии и регулярно проверяют, что пайплайн проходит при отключённом внешнем доступе.