Cloud Providers

«У нас AWS, всё управляемое, провайдер за это отвечает» — позиция, которая ломается на первом же региональном сбое или упёртой квоте в момент пиковой нагрузки. Облако — это не «дата-центр, который кто-то админит за тебя»: это платформа со своей моделью разделённой ответственности, своими режимами отказа (лёг регион, легла зона, придушили по квоте, упёрлись в лимит вызовов API) и своей моделью квот, которая живёт отдельно от вашего планирования мощностей. Я регулярно вижу команды, которые знают «AWS, GCP, Yandex Cloud», но не знают, где для конкретного сервиса проходит граница ответственности — где заканчивается доступность, за которую отвечает провайдер, и начинается зона команды. Этот лист — про эту границу: что облако делает за тебя, чего не делает и как строить надёжность с учётом обоих ответов.

У меня есть несколько своих проектов в Yandex Cloud: yccli — плагин для zsh с шестью десятками алиасов и восемью десятками функций поверх yc CLI, покрывает iam, vpc, managed-k8s, lockbox, KMS и управляемые базы; yc-quotas-exporter — экспортер квот Yandex Cloud для Prometheus (типичная эксплуатационная задача: квота — это не справочная информация, это жёсткий предел); evo-tf-argocd — демонстрационная инфраструктура под Cloud.ru Evolution Managed Kubernetes. Лист написан с упором на стек Yandex Cloud, но сами понятия — разделённая ответственность, управляемое против своего, квота как SLI, несколько регионов — переносятся на любое крупное облако.

Граница: Infrastructure as Code — про то, как выдавать облачные ресурсы (Terraform, Pulumi); этот лист — про то, как они устроены и как ломаются. Containerization & Orchestration — про k8s как абстракцию; здесь — про управляемый k8s как сервис провайдера. Cloud Cost Control — про экономику облака; здесь — про техническую сторону тех же сервисов.

Что должен уметь

Главный навык на уровне L4 — читать матрицу разделённой ответственности провайдера по каждому сервису, который команда использует. У AWS, GCP, Azure и Yandex Cloud есть публичная документация о том, кто за какой слой отвечает. Управляемый Kubernetes: провайдер держит control plane, вы — узлы, дополнения и сами нагрузки. Управляемый PostgreSQL: провайдер — резервные копии, обновления, переключение при отказе; вы — производительность запросов, пул соединений, целостность на уровне приложения. Объектное хранилище: провайдер — сохранность (те самые одиннадцать девяток), вы — политики доступа, шифрование, правила жизненного цикла. Эта матрица меняет и планирование мощностей, и реакцию на инциденты, и структуру runbook’ов. Я регулярно вижу команды, для которых «облако — значит надёжно», и границу они узнают через инцидент.

Понимает базовые кирпичики облака: вычисления (виртуальные машины, контейнеры, функции), хранение (блочное, объектное, файловое), сеть (VPC, подсети, группы безопасности, балансировщики), доступы (сервисные аккаунты, роли, политики). Знает, что у каждого провайдера для одних и тех же вещей свои названия.
Работает с CLI провайдера: aws, gcloud, az, yc. Мой yccli — пример обвязки yc алиасами под частые операции.

Различает управляемые сервисы и развёрнутые самостоятельно. Знает, какая часть операций уходит провайдеру (control plane, обновления, резервные копии), а какая остаётся у команды (конфигурация, мониторинг нагрузки, мощности).
Понимает модель квот: квота — жёсткий предел, а не справочная информация. Мой yc-quotas-exporter — как раз про это: вытащить квоты метрикой в Prometheus и алертить, когда осталось меньше пятой части.
Различает зональную и региональную архитектуру: что такое зона доступности, как сервис ведёт себя при её отказе, что значит «мульти-зональный» для конкретного сервиса конкретного провайдера. Знает, что у одного и того же провайдера разные сервисы изолируют отказы по-разному.
Работает с доступами осознанно: наименьшие привилегии, сервисные аккаунты вместо долгоживущих ключей, журнал аудита включён по умолчанию. Не пользуется корневой учётной записью для рутины.

Проектирует архитектуру на несколько зон: балансировщик и минимум две зоны, управляемые сервисы с автоматическим переключением, состояние не заперто в одной зоне. Различает, какие сервисы провайдера действительно работают в нескольких зонах, а какие зональны, и репликация докручивается сверху.
Проектирует план восстановления для облака: копии в другой регион (управляемые базы, объектное хранилище), runbook на полную потерю региона, RPO и RTO с учётом ограничений конкретного провайдера. См. DR Policy & Stakeholders.
Понимает модель тарификации: что списывается посекундно, что почасово, что фиксировано в месяц; исходящий трафик как скрытая статья; резервы, спот и прерываемые машины как размен (см. Cloud Cost Control).
Различает инциденты в control plane и в data plane. Когда лежит control plane, уже запущенные нагрузки часто живут, но выкатить или отмасштабировать ничего нельзя. Когда лежит data plane, лежат и сервисы. Мониторится это по-разному.

L6+

Оценивает размен между одним провайдером и мультиоблаком для конкретной системы. Готов аргументировать, что для большинства команд мультиоблако — это рост операционной сложности без снижения зависимости от провайдера; знает сценарии, где выходит иначе.
Ведёт диалог с провайдером: заявки в корпоративную поддержку, эскалация по региональным инцидентам, разбор причин от провайдера к своему постмортему. Отличает «провайдер не отвечает» (заявка открыта) от «мы делаем плохо» (своя корневая причина).

Материалы

Книги

Mike Julian — Practical Cloud Security (O’Reilly, 2-е изд., 2023). Безопасность в облаке как самостоятельная дисциплина: доступы, изоляция сети, шифрование, аудит. Полезно, чтобы понять, что облако в модели угроз добавляет, а что убирает.
Sam Newman — Building Microservices (O’Reilly, 2-е изд., 2021). Не про облако, но главы про распределённые системы и их отказы — фундамент для архитектуры в облаке.
AWS, Google, Microsoft — Well-Architected Frameworks (см. ниже). Не книги в строгом смысле, но самые подробные публичные руководства.

Статьи и доклады

AWS — AWS Well-Architected Framework. Шесть «столпов»: эксплуатация, безопасность, надёжность, производительность, стоимость, устойчивое развитие. Прочитать по диагонали — несколько часов; отдача высокая даже для команд вне AWS, потому что принципы переносимые.
Google Cloud — Site Reliability Engineering (полные SRE Book и Workbook). Глава Workbook про надёжность в облаке — лучшее, что я видел о том, как практики SRE ложатся на облачный контекст.
Microsoft — Azure Architecture Center. Каталог референсных архитектур; искать в нём стоит по задаче, а не по названию сервиса.
Yandex Cloud — Архитектурные практики. Аналог Well-Architected для стека Yandex Cloud. Материала меньше, чем у крупных облаков, зато на русском и про конкретные сервисы.
AWS S3 outage 2017-02-28 postmortem — публичный разбор облачного инцидента, см. ниже.
Cindy Sridharan — Cloud Native Reliability (серия постов). Критический взгляд на тезис «cloud-native надёжен по умолчанию».

Инструменты

CLI провайдера — aws, gcloud, az, yc. По моим наблюдениям, разница между инженером, который свободно живёт в облаке, и тем, кто нет, — это привычка работать через CLI и API, а не через веб-консоль. Консоль хороша, чтобы осмотреться; всё, что делается повторно, уезжает в CLI и в код.
yccli — мой плагин для zsh с алиасами к yc. Покрывает iam, vpc, compute, managed-k8s, lockbox, KMS, управляемые базы. Держу его именно для того, чтобы не помнить наизусть длинные команды.
yc-quotas-exporter — экспортер квот Yandex Cloud для Prometheus. Образец подхода «квота как SLI»: тащим квоты метрикой, алертим на пороге.
Terraform / Pulumi — основной инструмент описания облака кодом. Подробнее — в Infrastructure as Code.
CloudFormation (AWS) / Deployment Manager (GCP) — родные средства провайдеров. По моим наблюдениям, чаще выбирают Terraform: он работает поверх нескольких облаков и вокруг него большое сообщество, а родные средства берут, когда нужны возможности конкретного провайдера.
CloudTrail / Cloud Audit Logs / Yandex Cloud Audit Trails — журнал вызовов API. Включать по умолчанию во всех окружениях; на инциденте это главный источник истины по вопросу «кто что сделал».
Steampipe / CloudQuery — SQL поверх API облака. Удобно для инвентаризации, проверок на соответствие и разовых аудитов.

Best practices

Главный публичный кейс облачного инцидента — отказ AWS S3 28 февраля 2017 года. Инженер запустил отладочную команду с опечаткой в параметре, и та вывела из работы больше серверов индексной подсистемы, чем предполагалось. Перезапуск подсистемы занял часы; всё это время лежал весь S3 в US-East-1, а с ним половина интернета, потому что на S3 в этом регионе висели консоль AWS, дашборды многих сервисов и раздача картинок. Постмортем публичен и разобран подробно. Я регулярно ссылаюсь на этот случай ради двух уроков: облако ломается — даже AWS, даже S3, даже в основном регионе; и зависимость от региона — это скрытая связность: команды, считавшие себя мультирегиональными, обнаружили, что их фронтенд всё равно ходит через US-East-1. Отсюда простое следствие: список зависимостей от провайдера по регионам и сервисам стоит иметь явным, а не жить с ощущением «всё управляемое, всё надёжно».

Короткие правила:

Квота — жёсткий предел, а не справочная информация. Я регулярно вижу инциденты «сервис не масштабируется под пиковой нагрузкой» из-за упёртой квоты на число машин, публичные адреса или сетевые связки, — а заявка на повышение, по моим наблюдениям, обрабатывается сутки-двое. Квоты метрикой плюс алерт на «осталось меньше пятой части» — обязательный минимум. В yc-quotas-exporter я сделал это для Yandex Cloud; для AWS и GCP есть Service Quotas API и готовые экспортеры поверх него.
Наименьшие привилегии — не «сделаем после MVP». Сервисный аккаунт с ролью владельца «для удобства» — типичный источник утечек в духе «тестовый ключ попал в git». У каждой роли — явный список прав, у каждого компонента — свой аккаунт. Сделать это сразу дёшево, разгребать потом дорого.
Журнал аудита включён по умолчанию во всех окружениях. CloudTrail, Cloud Audit Logs, Yandex Audit Trails — главный источник ответа на вопрос «кто и когда это сделал». Включается одной командой и стоит копейки на фоне пользы. Я регулярно вижу команды, у которых на вопрос «кто удалил бакет» ответ «никто не знает», потому что аудит включили после инцидента, а не до.

Подробнее:

Несколько зон и несколько регионов решают разные задачи. Зоны защищают от отказа одного дата-центра внутри региона; это относительно дёшево и у управляемых сервисов часто включено по умолчанию. Регионы защищают от отказа целого региона, как в случае с S3 в 2017-м, и это заметно дороже и сложнее в эксплуатации: задержка репликации, разрешение конфликтов, переключение DNS. По моим наблюдениям, две зоны для прода — стандартный минимум, а второй регион — осознанное решение под конкретные требования по времени восстановления. Команды, которые берут второй регион «на всякий случай», чаще получают сложность без выгоды, потому что runbook на переключение никогда не проверяется.

Управляемые сервисы — это удобство с налогом. Управляемый PostgreSQL экономит часы на обновлениях и резервных копиях, но добавляет привязку к поставщику, ограничивает версии и иногда не даёт нужных расширений. Здоровый порядок — взвешивать цену и выгоду по каждому сервису отдельно, а не включать «всё управляемое» по умолчанию. Для сервисов, где лежат основные данные, привязка особенно болезненна: переезд базы между провайдерами занимает месяцы. Я регулярно вижу, что выбор между управляемой базой и своей на виртуалке даже не обсуждается, а срабатывает как умолчание. Иногда это оправдано, иногда нет.

Отказ региона — не «провайдер виноват», а реальность. У каждого крупного облака публичная история региональных отказов: AWS в us-east-1 падал не раз, у GCP были заметные отказы в us-central1 в 2019 и 2022 годах, у Azure свой список. Регион — не атомарная единица: внутри него связанные службы (доступы, control plane, сеть) валятся каскадом. Здоровая позиция — у каждой критичной нагрузки есть явный план на отказ региона, даже если этот план звучит как «принимаем простой до четырёх часов, потому что второй регион нам не окупается». План с осознанным разменом лучше, чем надежда, что не случится.

CLI и API — основная поверхность, консоль — вспомогательная. «Сделаем через консоль, это же один раз» — фраза, после которой через год никто не помнит, что и зачем настроено. Любая нетривиальная операция оставляет след: коммит в Terraform, скрипт с командой, запись в журнале аудита. Веб-консоль остаётся для разведки и чтения. Свой yccli я держу ровно затем, чтобы CLI был удобнее кликанья: когда так, выбор делается сам.

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

Связанные листья

Infrastructure as Code — Terraform и Pulumi — основной способ управлять облачными ресурсами; CLI и консоль остаются для разведки, а не для повторяемых операций.
Containerization & Orchestration — управляемый Kubernetes (EKS, GKE, AKS, Yandex Managed Kubernetes) — частный случай сервиса провайдера со своей границей ответственности.
Networking — VPC, подсети, балансировщики, сетевые связки — сетевые кирпичики, у каждого провайдера свои абстракции.
Cloud Cost Control — модель тарификации провайдера — исходные данные для всего цикла FinOps.
Capacity Planning — квоты провайдера — отдельная ось планирования; «квота как SLI» — паттерн оттуда.
Backup & Restore — резервная копия от провайдера не заменяет ваш runbook; проверенное восстановление обязательно.
DR Policy & Stakeholders — второй регион и копии между регионами — стратегическое решение, а не техническое.
Secrets Management — родные KMS и хранилища секретов у провайдера обычно выигрывают у развёрнутых самостоятельно.

Открытые вопросы

Yandex Cloud как основной стек для русскоязычных команд. Личный опыт у меня преимущественно там, отсюда и примеры. Понятия переносимы, а вот конкретика — имена сервисов, лимиты, поведение — у каждого провайдера своя. Если у вас опыт в AWS, GCP или Azure и есть желание расширить лист, PR приветствуется.

Мультиоблако ради требований регулятора — отдельный класс задач, куда я не заходил. Некоторые регуляторы требуют не зависеть от единственного поставщика, и как это выглядит в живой эксплуатации, я не знаю. Если у вас такое работает в проде, расскажите через PR.

Cloud-native против cloud-agnostic — это спектр. На одном конце «только Kubernetes и PostgreSQL, чтобы в любой момент съехать», на другом — DynamoDB, S3 и Lambda везде, где можно. Где правильная точка для большинства команд, я не уверен; в моих проектах баланс смещался к cloud-native: беру сервисы провайдера там, где плата за них оправдана.