Облачные концепции и модель ответственности
Play ITЗагрузка интерактивного демо…
Эта глава углубляет модели и сервисы облака — здесь меньше имён продуктов и больше понятий, с которыми вы столкнётесь на собеседовании, в AZ-900 и в разговоре с админами. Если первая статья отвечает на "что за зверь облако", эта — на "как о нём думать при проектировании и кто за что платит головой".
Модели обслуживания (кратко и точно)
| Модель | Вы управляете | Провайдер управляет | Примеры |
|---|---|---|---|
| IaaS | ОС, runtime, приложение, данные | Физика, сеть, гипервизор | ВМ, диски, VPC |
| PaaS | Приложение и данные | ОС, масштабирование платформы | Managed SQL, App Service, control plane K8s |
| SaaS | Настройки и данные внутри приложения | Всё остальное | M365, Salesforce, корпоративная почта |
Чем выше уровень абстракции (ближе к SaaS), тем быстрее старт и тем меньше свободы: нельзя поставить произвольную версию ядра, поднять свой демон на хосте PaaS или перестроить сеть как в своём ЦОД.
FaaS / serverless — частный случай PaaS: вы приносите только функцию, провайдер скрывает даже выбор долгоживущего сервера. Подробнее с примером кода — в главе 1.
Модели развёртывания
Модель развёртывания отвечает на вопрос где физически крутятся ваши ВМ, базы и хранилища — в общем пуле провайдера, в своём ЦОД или в комбинации. Это отдельная ось от IaaS/PaaS/SaaS: внутри публичного облака вы всё равно можете арендовать IaaS (ВМ) или PaaS (managed SQL).
-
Публичное облако — ресурсы в общем пуле провайдера (AWS, Azure, GCP, Yandex Cloud). Оплата по использованию, максимальная эластичность, multi-tenant: соседи по железу — другие клиенты, изоляция на уровне гипервизора и политик. Стартап с непредсказуемым трафиком и MVP без закупки серверов — типичный кейс.
-
Частное облако — инфраструктура выделена под вас (свой ЦОД или dedicated у провайдера). Чаще выбирают из-за регуляторики, предсказуемой задержки или legacy, который нельзя вынести в public. Банк с жёстким контуром данных и завод с SCADA, где интернет в цех запрещён, — частые примеры.
-
Гибридное — связка on-prem и public — VPN, ExpressRoute, репликация AD, "взрыв" нагрузки в облако (burst). Например: 1С и архив документов остаются в офисе, а витрина интернет-магазина масштабируется в AWS на распродаже.
-
Мультиоблако — два и более public-провайдера. Плюс: меньше привязки к одному вендору, резерв при сбое региона у вендора A. Минус — разные API, биллинг, команда эксплуатации, сложнее единый мониторинг.
Выбор опирается на закон о данных, задержку до пользователя, навыки команды и TCO на 3–5 лет, а не на модные презентации. Смежно: системное администрирование, on-prem и сети.
Регионы, зоны и отказоустойчивость
- Регион (Region) — географическая площадка (например, "Западная Европа"). Данные и ВМ обычно привязаны к региону; между регионами — отдельный трафик и задержка.
- Зона доступности (Availability Zone, AZ) — изолированный дата-центр внутри региона. Production-сервисы для HA ставят в несколько AZ: падение одного ЦОД не должно убить продукт.
- Георепликация — копии данных в другом регионе на случай катастрофы целого региона (дороже и сложнее в compliance).
SLA (Service Level Agreement) — обещание провайдера по доступности одного сервиса (например, 99,9% для blob storage). Составной продукт из пяти сервисов не наследует лучший SLA автоматически: цепочка слабее звена с худшим показателем.
| SLA (доступность) | Допустимый простой в год (порядок) |
|---|---|
| 99% | ~3,65 суток |
| 99,9% | ~8,76 часов |
| 99,99% | ~52,6 минут |
Если сайт = CDN + балансировщик + три ВМ + managed БД + object storage, для заказчика важен сквозной показатель, который вы проектируете сами (health checks, резерв в другой AZ, runbook). Документ SLA провайдера покрыает отдельный продукт, а не ваш бизнес-URL целиком.
Регион и compliance: персональные данные граждан РФ часто требуют хранения в РФ — это влияет на выбор региона Yandex Cloud / VK Cloud, а не только "ближайший дата-центр". Юридическая часть — у юристов; технически вы фиксируете регион при создании ресурса, и перенос потом дорогой.
Экономика — CapEx и OpEx
CapEx (Capital Expenditure) — разовые вложения — серверы, стойки, свой ЦОД. OpEx (Operational Expenditure) — регулярные расходы — счёт за облако, лицензии, поддержка.
Облако переносит CapEx в OpEx и даёт гибкость, но без дисциплины OpEx растёт незаметно:
- забытые dev-ВМ круглосуточно;
- диски "на всякий случай" в 10 раз больше нужного;
- egress — исходящий трафик из облака (часто платный);
- неотключённые managed-сервисы.
Практики контроля:
- бюджеты и алерты по подписке/аккаунту;
- теги ресурсов (
project,env,owner); - автоостановка dev-сред по расписанию;
- reserved capacity / savings plans для стабильной базовой нагрузки.
Упрощённый пример счёта: три dev-ВМ t3.medium забыли выключить на выходные (~$30–50/мес каждая в EU), диск 500 ГБ "на всякий случай" (+$40), исходящий трафик с CDN в другой регион (+неожиданные $). Итого сотни долларов при "мы только экспериментировали". Тег env=dev и автоостановка по cron в пятницу — дисциплина, которая окупается без магии FinOps.
Связь с бухгалтерией: CapEx списывают как актив, OpEx — как ежемесячные расходы. Облако удобно стартапу без капитала на серверную, но при стабильной нагрузке 24/7 иногда выгоднее colocation — считаете под свою нагрузку, а не по мемам из Twitter.
Shared Responsibility Model
Модель совместной ответственности — кто за что отвечает в облаке. Граница сдвигается вверх по стеку от IaaS к SaaS: провайдер забирает больше слоёв, но данные и учётные записи почти всегда остаются на вас.
| Область | IaaS (ВМ) | PaaS (managed DB) | SaaS (почта) |
|---|---|---|---|
| Физическая безопасность | Провайдер | Провайдер | Провайдер |
| Сеть и гипервизор | Провайдер | Провайдер | Провайдер |
| ОС и патчи | Вы | Провайдер | Провайдер |
| Приложение | Вы | Вы | Провайдер |
| Учётные записи и MFA | Вы | Вы | Совместно |
| Данные и шифрование | Вы | Вы | Вы (политики доступа) |
Типичная ошибка: "мы в Azure — значит, Microsoft всё защитил". Нет — открытый порт 22 на весь интернет, ключи в GitHub и отсутствие MFA — ваша зона, не провайдера.
Разбор с точки зрения ИБ — 8.07 Zero Trust, идентичность — Entra ID, практики для аккаунта — безопасность в облаке.
Провайдер охраняет здание дата-центра.
Вы охраняете сейф — конфигурацию ВМ, секреты, доступ к данным и настройки приложения.
Хранилища на уровне концепций
| Тип | Единица | Типичное использование |
|---|---|---|
| Object | Объект + ключ в bucket | Статика, бэкапы, data lake |
| Block | Том как диск | Системный диск ВМ, БД на диске |
| File | Общая файловая шара (NFS/SMB) | Legacy, "общая папка" для ВМ |
Подробнее и с примерами CLI/SDK — глава 1.
Масштабирование и эластичность
- Вертикальное — увеличить CPU/RAM одной ВМ. Просто, но есть потолок железа и простой при перезагрузке.
- Горизонтальное — больше экземпляров за балансировщиком. Требует stateless-приложения или вынесения сессий (Redis и т.д.).
Эластичность — автоматически добавлять/убирать ресурсы по метрикам (CPU, длина очереди, RPS). Демо — в главе 1 (ScalingDemo).
Мифы об облаке — что ждать реалистично
Облако часто продают как "всё решено". На деле часть обещаний выполняет провайдер, часть — ваша команда.
| Миф | Реальность | Что делать |
|---|---|---|
| "Бэкап включён сам" | Резервные копии настраиваете вы или политики сервиса | Versioning, snapshots, тест restore — глава 11 |
| "GDPR из коробки" | Compliance совместный: регион, договор, процессы | Юристы + шифрование + журнал доступа |
| "Всегда дешевле своего ЦОД" | При стабильной 24/7 нагрузке TCO может быть выше | Считать 3–5 лет, reserved instances |
| "Провайдер защитил всё" | Открытый порт и ключи в Git — ваша зона | Shared responsibility, MFA, IAM |
Удаление bucket без versioning необратимо: облако честно выполняет команду удаления. Это повод включить политики и права "кто может DeleteBucket".
Мини-глоссарий
| Термин | Смысл |
|---|---|
| Tenant | Изоляция клиента в общем облаке |
| Egress | Исходящий трафик из облака наружу |
| Managed service | Провайдер патчит и обслуживает слой (БД, K8s control plane) |
| IAM | Кто кому что может в облаке (роли, политики) |
| Vendor lock-in | Зависимость от API и сервисов одного провайдера |
| Landing zone | Базовая "фабрика" аккаунтов, сетей и политик в enterprise |
Подробнее про сеть между регионами — сеть и интернет; про идентичность в Azure AD / Entra — Entra ID.
Практика Microsoft Learn
Рекомендуемый порядок:
Навигатор: /tools/documentation/6. Сертификаты: 1.26/12.
Итоги
Облако — модель потребления IT, а не синоним "чужого сервера". IaaS/PaaS/SaaS и shared responsibility показывают, где заканчивается провайдер и начинаетесь вы. Регионы, SLA и OpEx объясняют, почему "упало в одной зоне" и "счёт вырос втрое" — нормальные темы архитектора, а не сюрприз. Имена сервисов Azure/AWS — следующий шаг на Learn, не замена этой базы.