Администрирование БД в облаке

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

---

БД в облаке (Cloud Database) — это база данных, развернутая не на вашем физическом сервере, а на инфраструктуре облачного провайдера. Вы можете управлять ею сами (как VM с установленной БД) или использовать управляемый сервис.

Облако (Cloud) — это модель предоставления IT-ресурсов (вычислительных мощностей, хранилищ, сетей) по требованию через интернет, с оплатой по факту использования. Это не физический сервер у вас в офисе, а пул ресурсов в дата-центрах провайдера (Yandex, AWS, GCP).

VM (Virtual Machine / Виртуальная машина) — это программная эмуляция физического компьютера со своим CPU, RAM и диском. Она работает поверх гипервизора хоста и изолирована от других ВМ, но вы, как администратор, управляете ОС внутри нее полностью.

Фраза "мы переехали в облако — DBA больше не нужен" звучит привлекательно, но на практике ломается в первую пятницу с пиковой нагрузкой — диск забит, реплика отстаёт, миграция держит блокировку. Managed database (управляемая СУБД от провайдера) забирает рутину — патчи ОС, установка бинарников, базовый мониторинг, автоматические снимки. Схема, запросы, права, RPO/RTO, стоимость и безопасность данных остаются зоной ответственности вашей команды.

Зона ответственности команды — это четко очерченный круг задач и компонентов системы, за которые команда (разработчиков, админов или SRE) отвечает перед бизнесом. Включает в себя разработку, поддержку работоспособности, решение инцидентов и развитие своих сервисов. Все, что вне зоны — передается смежным командам или провайдеру.

DBA (Database Administrator) — классический администратор баз данных. Отвечает за установку СУБД, настройку параметров, создание пользователей, бэкапы, восстановление и оптимизацию "тяжелых" запросов. Работает близко к "железу" и конфигам.

Облачный DBA (Cloud DBA) — это DBA, который работает в облачной парадигме. Он почти не занимается установкой софта (это делает Managed Service), но глубоко разбирается в специфике облачных дисков (IOPS), сетевых задержках, политиках бэкапов провайдера и экономике (как сэкономить деньги, переключив класс инстанса). Часто это связующее звено между разработкой и платформой.

Platform Engineer (Инженер платформы) — инженер, который строит внутреннюю платформу для разработчиков. Он не пишет бизнес-логику, а создает инфраструктурный "фабрикат": шаблоны (Terraform), CI/CD пайплайны, мониторинг, единую службу аутентификации. Его задача — чтобы разработчик мог развернуть БД или микросервис одним нажатием кнопки, не вникая в сетевые настройки.

Что изменится в голове после чтения:

• поймёте shared responsibility — что чинит AWS/Google/Yandex, а что чините вы;
• отличите snapshot от pg_dump;
• поймёте, зачем не открывать порт 5432 в интернет;
• свяжете облачные бэкапы с RPO/RTO из роли БД в организации.

WAL (Write-Ahead Log — Журнал упреждающей записи) — это технология в БД, при которой любое изменение сначала записывается в специальный лог (журнал), и только потом — в основную таблицу. Это гарантирует целостность данных при сбоях: если сервер упал, при перезапуске БД «прокатывает» изменения из WAL, чтобы ничего не потерять.

Теория WAL и сбоев та же — см. Восстановление после сбоя. Меняется кто крутит диски и журналы под капотом.

---

Словарик облачной БД

Термин	Простыми словами
Managed / PaaS для БД	Вы заказываете "PostgreSQL 16, 4 CPU, 16 GB RAM" — провайдер поднимает кластер.
Endpoint	Адрес подключения: хост + порт + иногда только SSL.
Инстанс (instance)	Один работающий сервер БД (или кластер primary+standby).
Snapshot	Снимок диска на момент времени; основа PITR у провайдера.
Retention	Сколько дней хранятся автоматические бэкапы.
VPC / private network	База доступна из внутренней сети, а не из всего интернета.
Maintenance window	Окно, когда провайдер ставит патчи minor-версии.

PITR (Point-in-Time Recovery) — это технология восстановления базы данных на любой момент времени в прошлом (с точностью до секунды). Работает на основе полных бэкапов + архива WAL-логов. Позволяет откатить случайное удаление таблицы, произошедшее в 15:23:45, к состоянию 15:23:44.

Managed Database (Управляемая БД) — это сервис, где провайдер берет на себя администрирование: установку, патчинг (обновление версий), настройку бэкапов, репликацию и мониторинг. Вы получаете готовый DNS-адрес для подключения и занимаетесь только схемой данных и запросами.

Endpoint (Конечная точка) — это любое устройство или сервис, которое подключается к вашей сети или системе. Это может быть ноутбук пользователя, телефон, IoT-датчик или API вашего сервиса. В контексте безопасности — это точка входа, которую нужно защищать.

Snapshot (Снэпшот) — это «мгновенный снимок» состояния диска или всей виртуальной машины в конкретный момент времени. Технически это не копия файлов, а запись изменений (дельта), что позволяет быстро восстановить диск до этого состояния.

Retention (Срок хранения) — это политика, определяющая, как долго хранятся ваши бэкапы, снэпшоты или логи. Например, Retention = 30 дней означает, что старые копии автоматически удаляются через 30 дней.

VPC (Virtual Private Cloud) — это изолированный виртуальный сегмент сети внутри публичного облака. Это ваша «личная комната» в общем дата-центре, где вы сами задаете IP-адреса, подсети и правила маршрутизации.

Private network (Частная сеть) — сеть, доступ к которой имеют только авторизованные устройства (обычно через внутренние IP-адреса). В облаке это трафик между вашими сервисами, который не выходит в публичный интернет (быстрее и безопаснее).

RPO (Recovery Point Objective) — это максимальный объем данных, который вы готовы потерять при аварии. Измеряется во времени. Пример: если RPO = 15 минут, значит бэкапы делаются каждые 15 минут, и при крахе вы потеряете данные максимум за последние 15 минут.

RTO (Recovery Time Objective) — это максимально допустимое время, за которое система должна быть восстановлена после сбоя. Пример: если RTO = 2 часа, значит у вас есть 2 часа на то, чтобы поднять БД из бэкапа, иначе бизнес-процессы встанут.

Maintenance window (Окно обслуживания) — это заранее согласованный временной интервал, в течение которого провайдер или администратор может проводить технические работы (обновление ядра ОС, перезагрузка хоста). В это время сервис может быть недоступен или работать медленнее.

---

Managed-сервис — что это

Managed relational database (Управляемая реляционная БД) — тот же Managed Database, но строго для реляционных СУБД (PostgreSQL, MySQL, Oracle). Данные хранятся в таблицах со строгими связями (foreign keys) и поддерживается язык SQL.

Managed relational database — СУБД как сервис — вы заказываете экземпляр (класс CPU/RAM, объём диска, регион), получаете endpoint (хост, порт), логин и политики бэкапа. Провайдер обслуживает кластер, ОС (в границах модели), обновления minor/patch по политике.

Отличия от смежных моделей:

Модель	Что вы получаете	Контроль
Managed DB (RDS, Cloud SQL)	Готовый PostgreSQL/MySQL	Средний: параметры из whitelist, бэкапы кнопкой
Своя VM + apt install postgresql	Тот же PostgreSQL	Полный DBA — Управление реляционными СУБД
PaaS приложения (Heroku-style)	БД как приложение	Меньше настроек, быстрый старт
Serverless (Aurora Serverless, Neon)	Масштаб по нагрузке	Другая экономика и лимиты

PaaS (Platform as a Service) — модель, где провайдер предоставляет не просто «железо», а готовую платформу для разработки (среду выполнения кода, БД, очереди сообщений). Разработчик заливает только свой код, а масштабированием, ОС и серверами управляет провайдер. Ваш Managed Database — это классический пример PaaS.

Serverless (в контексте БД) — модель, где вы не выделяете фиксированный размер CPU/RAM для БД. Ресурсы масштабируются автоматически от 0 до максимума в зависимости от нагрузки. Платите только за количество выполненных запросов (IOPS) и объем хранимых данных. Нет «вечно включенного» инстанса.

---

Модель shared responsibility

Shared Responsibility Model (Модель разделенной ответственности) — это правило безопасности в облаках: Провайдер отвечает за безопасность облака (физические дата-центры, сеть, гипервизоры), а Клиент отвечает за безопасность в облаке (настройки доступа, шифрование данных, пароли, конфигурация БД, обновления ОС на ВМ).

Удобная схема (одинаковая по смыслу у AWS, Azure, GCP):

Зона	Провайдер (платформа)	Клиент (вы)
Дата-центр, питание, сеть до хоста	✓
Установка и патч СУБД (по SLA)	✓
Диски, RAID, часть мониторинга железа	✓
Схема, индексы, SQL		✓
Учётные записи, least privilege		✓
Данные, целостность, миграции		✓
Выбор размера инстанса, autoscaling		✓
Тест восстановления из бэкапа	частично ✓	✓ (обязательно проверять)
Шифрование на лету / at rest	опции ✓	настройка ✓
Сетевая изоляция (VPC, firewall)	инструменты ✓	правила ✓

Вывод: облачный DBA / platform engineer — другой набор задач — IaC, секреты, стоимость, наблюдаемость, DR между регионами.

RAID (Redundant Array of Independent Disks) — это технология объединения нескольких физических дисков в один логический массив для повышения отказоустойчивости и/или производительности. В облаках редко используется напрямую (там софт-определяемое хранилище), но термины важны:

• RAID 1 (зеркало) — данные дублируются на 2 диска. Отказ одного диска не страшен.
• RAID 5/6 — данные и контрольные суммы распределяются по дискам, позволяя пережить отказ 1–2 дисков без потери информации.

Инстанс (Instance) — это единичный экземпляр ресурса. Применимо ко всему: виртуальная машина (VM instance), база данных (DB instance) или приложение. По сути, это «один запущенный сервер» со своим именем и конфигурацией в вашей облачной учетной записи.

Autoscaling (Автомасштабирование) — возможность системы автоматически увеличивать или уменьшать количество вычислительных ресурсов (или мощность CPU/RAM) в зависимости от текущей нагрузки (например, роста числа подключений к БД или повышения CPU). Цель — сэкономить деньги в часы затишья и не упасть под нагрузкой в часы пик.

Шифрование на лету / at rest (Encryption at rest) — это шифрование данных, когда они физически записаны на диск (SSD/HDD). Даже если злоумышленник украдет физический диск из дата-центра, без ключей расшифровки он ничего не прочитает. Обычно выполняется на уровне гипервизора или дискового массива (прозрачно для вашей БД).

Сетевая изоляция (Network isolation) — это набор правил (Security Groups, Network ACLs), который запрещает любые сетевые подключения к вашему ресурсу, кроме явно разрешенных. Например, ваша БД принимает соединения только с IP-адресов ваших серверов приложений и категорически недоступна из публичного интернета.

Least privilege (Принцип наименьших привилегий) — фундаментальное правило безопасности: выдавать пользователю, сервису или приложению ровно те права доступа, которые минимально необходимы для выполнения его работы, и ни на байт больше. Например, пользователю приложения для чтения данных не нужны права на удаление таблиц (DROP).

Тест восстановления из бэкапа — это не просто создание копии, а регулярная практическая проверка того, что ваш бэкап жизнеспособен. Инженеры поднимают БД из бэкапа в тестовой среде и выполняют запросы, чтобы убедиться, что файлы не повреждены и структура данных цела. Бэкап, который ни разу не тестировали, считается мусором.

---

Что обычно делает провайдер

• первичный запуск экземпляра и репликации (read replica по кнопке);
• автоматические снимки (snapshots) по расписанию;
• point-in-time recovery в окне хранения WAL (аналог PITR — см. Резервное копирование и восстановление PostgreSQL);
• failover на standby в multi-AZ / regional конфигурации;
• обновление minor-версии в maintenance window;
• базовые метрики — CPU, IOPS, connections, replication lag.

Read replica (Реплика для чтения) — это точная копия основной (мастер) БД, которая синхронизируется асинхронно (или синхронно, в зависимости от настроек). Она принимает только запросы SELECT (чтение). Используется, чтобы разгрузить мастер-сервер от тяжелых отчетов и аналитики.

Standby (Резервный / Стендбай) — это пассивный экземпляр БД, который постоянно получает поток изменений от мастера (репликацию). Он не обслуживает читающие запросы (в отличие от Read Replica). Его единственная задача — мгновенно стать мастером (при помощи failover), если основной сервер упал.

Multi-AZ (Multiple Availability Zones) — размещение вашего инстанса БД сразу в нескольких физически изолированных дата-центрах (зонах доступности) в пределах одного региона. Если один дата-центр сгорел — вторая копия БД (реплика) продолжает работать, обеспечивая High Availability (высокую доступность). Переключение происходит автоматически.

Regional конфигурации — это настройки ресурсов, которые завязаны на конкретный регион облака. Сюда входит выбор локации для хранения данных (чтобы соответствовать законам о персональных данных), привязка сетей (VPC региональны) и стоимость сервисов (она отличается в разных регионах).

Failover (Переключение отказа) — это автоматический или ручной процесс замены вышедшего из строя основного узла (мастера) на резервный (standby). При этом приложениям нужно перенастроить подключения на новый IP (или использовать DNS с коротким TTL).

Базовые метрики — это минимальный набор показателей здоровья системы, за которыми нужно следить всегда:

• CPU (загрузка процессора) — показывает, не "задыхается" ли ваш инстанс от вычислений.
• IOPS (Input/Output Operations Per Second) — количество операций чтения/записи в секунду к диску. Критично для БД: если диск не успевает обрабатывать запросы, БД будет тормозить (даже при пустом CPU).
• Connections (Количество подключений) — сколько активных сессий подключено к БД. Превышение лимита приводит к ошибкам отказа в подключении новых пользователей.
• Replication lag (Отставание репликации) — задержка (в секундах или байтах) между мастером и репликой (standby или read replica). Если лаг растет — при аварии вы потеряете больше данных, чем допустимо по RPO, и реплика не успеет за мастером. Это главный враг высокой доступности.

---

Что остаётся за командой

Производительность и ёмкость

• выбор класса (vCPU, RAM, IOPS);
• медленные запросы — оптимизация, индексы;
• connection pooling (PgBouncer, RDS Proxy) — лимит соединений в managed часто ниже, чем кажется;
• рост данных → scale up / partition / архив.

Выбор класса (vCPU, RAM, IOPS) — это процесс подбора «железной» конфигурации для вашего инстанса в облаке. Вы выбираете количество виртуальных ядер (vCPU) под вычислительную сложность, объем оперативной памяти (RAM) под кеши и сортировки, а также класс диска по показателю IOPS (операций ввода-вывода в секунду). Если у вас много тяжелых SELECT * FROM huge_table, вам нужно много IOPS; если много сложных джойнов — больше vCPU/RAM.

Connection pooling (Пул соединений) — это механизм, при котором приложение не создает новое подключение к БД на каждый запрос пользователя (это дорого и медленно), а берет уже готовое, открытое соединение из общего «бассейна» (пула) и возвращает его обратно после выполнения запроса. В облачных Managed БД часто есть встроенный прокси (например, PgBouncer), который делает эту работу за вас. Критично: если не настроить пулинг, вы быстро упретесь в лимит max_connections (обычно 100–400) при росте пользователей.

Scale up (Вертикальное масштабирование) — это увеличение мощности уже существующего инстанса. Вы просто меняете класс в консоли (например, с 2 vCPU на 8 vCPU). При этом, как правило, происходит перезагрузка БД (простой от 5 до 15 минут). Это самый простой способ «добавить лошадиных сил», но у него есть физический потолок (максимальный класс в регионе).

Partition (Партиционирование / Секционирование) — это физическое разбиение одной большой логической таблицы на более мелкие «куски» (партиции) по определенному ключу (например, по датам: данные за 2024 год в одной партиции, за 2025-й — в другой). Это нужно, чтобы:

• Быстрее удалять старые данные (DROP партиции быстрее, чем DELETE).
• Повысить скорость выборки (поиск идет только по нужной партиции, а не по всей гигантской таблице).

Архив (в контексте БД) — это выгрузка "старых", редко используемых данных из основной таблицы в отдельное хранилище (часто в холодное объектное хранилище типа S3). Это делается, чтобы держать основную операционную БД "легкой" и быстрой, не удаляя данные насовсем (история сохраняется, но лежит отдельно и дешево).

---

Безопасность

• не открывать 5432 в интернет "для удобства";
• private endpoint, VPN, bastion;
• ротация паролей, IAM-аутентификация (где есть);
• разделение ролей app / migration / readonly analyst.

5432 — это стандартный сетевой порт, на котором по умолчанию «слушает» входящие подключения реляционная база данных PostgreSQL. Если вы видите этот номер в строке подключения (например, host=... port=5432), значит, это Postgres. (Для справки: у MySQL порт 3306, у MSSQL — 1433).

Private endpoint — это сетевая технология, которая позволяет вашему приложению в VPC подключаться к облачному сервису (например, Managed БД) по внутреннему IP-адресу, не выходя в публичный интернет. При этом трафик идет исключительно по магистральным сетям провайдера, минуя внешний шлюз. Это безопаснее (нет маршрута через интернет) и дешевле (не платите за исходящий трафик).

Bastion (Хост-бастион / Jumphost) — это специальный «буферный» сервер, который находится в публичной сети (имеет внешний IP). Доступ к вашей БД (которая спрятана в приватной подсети без внешнего IP) разрешен только через этот бастион. Чтобы подключиться к БД, вы сначала SSH-заходите на бастион, а оттуда — в БД. Это единая точка входа для администрирования и защиты от прямой атаки.

Ротация паролей — это плановая или экстренная смена паролей от пользователей БД (особенно администраторов) по расписанию (например, раз в 90 дней). В облаках это часто автоматизировано через сервисы секретов: приложение забирает новый пароль из защищенного хранилища (Vault) при перезапуске, чтобы смена пароля не привела к падению прод-сервисов.

IAM-аутентификация — это способ входа в БД без пароля (вообще!), используя механизмы самого облачного провайдера (Identity and Access Management). Например, сервису в AWS или Яндекс.Облаке выдается временный токен доступа к БД, который автоматически обновляется. Пароль физически нигде не хранится и не передается, что резко повышает безопасность (невозможно украсть пароль из кода или .env файла).

Разделение ролей app / migration / readonly analyst — это правило безопасности, согласно которому у каждого пользователя/сервиса должна быть своя, строго ограниченная роль:

• app (приложение) — имеет права только на SELECT, INSERT, UPDATE, DELETE по рабочим таблицам. Не может менять схему (ALTER TABLE).
• migration (мигратор) — используется деплой-пайплайном. Имеет права на изменение схемы (CREATE/ALTER/DROP), чтобы накатывать миграции. Работает только в моменты деплоя.
• readonly analyst (аналитик) — имеет права только на SELECT. Используется BI-инструментами (например, Tableau), чтобы строить отчеты и случайно не сломать продакшен. Часто подключается к Read Replica, чтобы не нагружать мастер.

---

Надёжность

• задать RPO (сколько данных можно потерять) и RTO (сколько простоя допустимо);
• проверять восстановление в отдельный инстанс раз в квартал;
• понимать, что удаление production инстанса в консоли — необратимо без бэкапа.

---

Соответствие и данные

DR между регионами (Disaster Recovery across regions) — стратегия аварийного восстановления, при которой резервная копия вашей инфраструктуры находится в другом географическом регионе облака (например, основной во Франкфурте, резервный в Москве). Используется для защиты от глобальных катастроф (землетрясения, отключения электричества в целой зоне доступности).

• резидентность (регион EU/RU);
• персональные данные — Governance.

Резидентность — это юридическое и физическое требование, согласно которому персональные данные граждан определенной страны должны храниться исключительно на серверах, расположенных на территории этой страны (в дата-центрах, находящихся под ее юрисдикцией). Например, 152-ФЗ в России или GDPR в Европе. Это жестко диктует, какой регион облачного провайдера вы обязаны выбрать. Вы не можете хранить российские паспортные данные в дата-центре во Франкфурте.

---

Типовые продукты (ориентиры)

Здесь у вас, по сути, два выбора:

• классическая Managed VM. БД работает на выделенной ВМ. Вы платите за vCPU/RAM/Диск. Предсказуемая цена. Это Amazon RDS, Cloud SQL, Azure Database (Flexible Server), Managed Service for PostgreSQL.
• специализированное хранилище. БД "обернута" в собственный распределенный слой хранения провайдера (отделяет вычисления от диска). Репликация и бэкапы идут на уровне стораджа. Быстрее восстанавливается и масштабируется. Это Aurora PostgreSQL, AlloyDB, Hyperscale, YDB.

Провайдер	Примеры managed PostgreSQL / SQL
AWS	Amazon RDS for PostgreSQL, Aurora PostgreSQL
Google Cloud	Cloud SQL for PostgreSQL, AlloyDB
Microsoft Azure	Azure Database for PostgreSQL, Azure SQL
Yandex Cloud	Managed Service for PostgreSQL
Другие	DigitalOcean, Aiven, Supabase (PG + платформа)

Supabase и Aiven — это не просто БД, а платформы с UI и дополнительными сервисами (аутентификация, API, брокеры). Вы платите не только за БД, но и за экосистему.

Когда вы открываете страницу продукта, вас не должны волновать красивые картинки. Вы должны смотреть на цифры и ограничения. Вот что искать в документации:

• А. Backup Retention (Срок хранения бэкапов). Можно ли включить долгосрочное хранение (Long-term retention) в S3-бакет на годы? (Это часто делается отдельным экспортом, а не через стандартный бэкап).
• Б. Maintenance Window (Окно обслуживания). Узнайте, перезагружается ли инстанс при применении обновлений безопасности?
• В. Extensions (Расширения). Это точка невозврата. Если вы выберете БД, где нет нужного расширения — вы не сможете переехать без переписывания кода.
  • PostGIS (геоданные) — есть везде, но версии отличаются! Убедитесь, что версия расширения совпадает с вашей библиотекой (например, версия 3.4, а не 2.5).
  • pg_cron (встроенный шедулер) — есть не у всех. Например, в стандартном RDS он доступен, но требует специальных прав (superuser). В Yandex Cloud он часто отключен.
  • pg_stat_statements (для анализа медленных запросов) — должен быть включен по умолчанию. Если нет — вы потеряете возможность мониторинга.

Документация любого провайдера содержит таблицу Instance Classes (Flavors). Ваша стратегия чтения:

• Сначала IOPS: Посмотрите, какой тип диска предлагается.
• Соотношение vCPU/RAM: Для PostgreSQL критично RAM. PostgreSQL кеширует таблицы в памяти (shared_buffers). Обычно стандартная пропорция 1:4 или 1:8.
• Network Bandwidth: В мелком тексте смотрите "Network performance". У дешевых классов (например, db.t4g.micro) пропускная способность сети ограничена 1 Гбит/с. Если у вас большой трафик репликации — это станет узким горлышком.

AWS RDS: Отличная стабильность, но вы не имеете доступа к базовой ОС (нет суперпользователя). Вы не сможете поставить расширение, если оно требует SUPERUSER прав. Альтернатива — Aurora, но она совместима не на 100% (есть отличия в поведении триггеров).

Yandex Cloud Managed PG: Дает mdb_admin (почти суперпользователь), что удобно для настройки расширений. Но обратите внимание на резервирование диска: размер диска нельзя уменьшить, только увеличить.

Azure Flexible Server: Позволяет настраивать max_connections очень гибко, но реплики для чтения в некоторых тарифах оплачиваются как полноценные инстансы, а не как доля от мастера.

Supabase / Aiven: Это не просто БД, там жестко завязан autoscaling. Проверьте, не включен ли "Pause after inactivity" — если база простаивает, она отключается, и первый запрос после паузы возвращается с ошибкой timeout.

---

Отличия от "своего" сервера

Многие инженеры ошибочно полагают, что Managed Database — это "та же самая БД, только в облаке". На самом деле, это принципиально другой продукт с жесткими ограничениями, и понимание этих ограничений спасает от провальных миграций.

Тема	On-prem / своя VM	Managed
Доступ к postgresql.conf	полный	часто whitelist параметров
Файловая система / pg_wal	видите	скрыто
Суперпользователь	postgres	роль с ограничениями (rds_superuser и т.п.)
Установка расширений	любые	по списку провайдера
Стоимость	CapEx железа	OpEx по часам + диск + исходящий трафик

Перед выбором провайдера всегда смотрите "Supported parameters" в документации. Если вам нужен специфичный параметр (например, pg_trgm.similarity_threshold) — проверьте, есть ли он.

В Managed БД всегда включайте мониторинг метрики "Free disk space" и настраивайте алерт при 80% заполнения. Не надейтесь, что провайдер сам все почистит.

Забудьте про привычку делать всё под postgres. В Managed БД используйте выделенные роли с минимальными правами. Для миграций создавайте отдельного пользователя migration_user с правами на изменение схемы, но не давайте ему доступ к данным других пользователей.

Список расширений всегда публичный в документации. Проверьте его до начала разработки, а не на этапе деплоя в прод.

В Managed БД всегда смотрите тариф на исходящий трафик. Если ваше приложение часто выгружает большие объемы данных (например, отчеты для Excel), стоимость трафика может превысить стоимость самого инстанса.

Ваш выбор:

1. On-prem / свою VM - "Я хочу полный контроль. Я готов платить инженеров, которые будут настраивать postgresql.conf, чистить WAL и ставить кастомные расширения. Я покупаю железо на 5 лет вперед."
2. Managed Database - "Я хочу предсказуемость и быстроту. Я согласен жить в рамках ограничений провайдера (whitelist параметров, список расширений). Я плачу за гибкость (OpEx) и освобождаю своих инженеров от рутинного администрирования. Но я обязан мониторить диск, трафик и WAL, потому что провайдер не сделает это за меня."

Понимание WAL и recovery помогает читать SLA: "восстановление на точку во времени" — это про архив журнала, а не магию.

---

Первое подключение — что вы видите в консоли

Типичный путь (названия кнопок у провайдеров разные, логика одна):

1. Create instance — выбрать движок (PostgreSQL 16), регион (ближе к приложению), класс CPU/RAM, размер диска.

• Движок / Версия. Точка невозврата. Вы не сможете легко понизить версию. Мажорные апгрейды (например, с 14 на 15) в Managed БД — это всегда даунтайм (иногда до 30 минут), так как провайдер делает pg_upgrade со всеми рисками. Выбирайте LTS-версию, которая будет поддерживаться провайдером минимум 3-5 лет.
• Регион. Влияет на задержку (latency). Если ваше приложение в Москве, а БД в Ирландии, каждый запрос будет иметь +50-80 мс RTT. Для высоконагруженных систем это критично. Также влияет на резидентность (закон о данных).
• Класс CPU/RAM. Выбор класса определяет не только мощность, но и сетевую пропускную способность. У дешевых классов лимит на входящий/исходящий трафик ниже. Если у вас большой поток репликации — выбирайте класс с меткой "High Network Bandwidth".
• Размер диска. В большинстве Managed БД диск нельзя уменьшить, только увеличить. И увеличение часто требует перезагрузки (даунтайм 5-15 минут). Закладывайте размер с запасом на 1-2 года роста. Также смотрите на тип диска: gp2 (General Purpose SSD), gp3 (быстрее и дешевле) или io1/io2 (Provisioned IOPS — для высоконагруженных систем).
• Некоторые провайдеры (например, AWS Aurora) отделяют хранилище от вычислений. Вы выбираете класс CPU/RAM, а диск автоматически растет до 128 TB и платите только за использованные ГБ. Это удобно, но дороже при маленьких базах.

2. Credentials — мастер-пользователь и пароль (или IAM-аутентификация, где поддерживается).

• Имя пользователя. Это не настоящий postgres (суперпользователь). В Managed БД это роль с ограниченными правами (например, rds_superuser или mdb_admin). Вы не сможете выполнять некоторые системные команды (например, pg_reload_conf()).
• Пароль. Никогда не используйте простые пароли. Лучше сгенерируйте через менеджер паролей (например, openssl rand -base64 32). Пароль будет отображаться в строке подключения — убедитесь, что вы не коммитите его в Git.
• IAM-аутентификация. Вместо пароля вы используете временные токены IAM. Это безопаснее, потому что пароль не хранится нигде. Но требует дополнительной настройки приложения (подпись запросов через AWS API).
• В некоторых провайдерах (например, Yandex Cloud) можно создать несколько пользователей с разными правами прямо в консоли. Используйте это — не работайте под мастер-пользователем в приложении. Создайте отдельную роль app_user с правами только на нужные таблицы.

3. Network — VPC, подсеть, "публичный доступ: нет" для prod.

• VPC. БД должна находиться в той же VPC, что и ваши сервера приложений, чтобы трафик шел по приватным маршрутам (бесплатно и безопасно).
• Подсеть (Subnet). Для Production всегда выбирайте приватную подсеть. Это значит, что у БД нет публичного IP-адреса в интернете. Подключиться к ней можно только изнутри VPC (через private endpoint или бастион).
• Публичный доступ. Для Prod — строго Нет. Включайте публичный доступ только для тестовых баз, к которым нужно подключиться из дома. И даже тогда — ограничьте доступ по IP-адресу (Security Group).
• Security Group / Firewall. Добавьте правило: "Разрешить TCP порт 5432 только от серверов приложений (их CIDR или Security Group ID)". Это ваша основная защита от атак.
• Если ваша БД в приватной подсети, а разработчикам нужно подключаться к ней из IDE (например, DBeaver) — настройте SSH-туннель через бастион-хост. Никогда не открывайте публичный доступ для всей команды.

4. Backup — включить автоматические snapshot, retention (например 7 или 35 дней).

• Автоматические бэкапы. В Managed БД всегда включено (вы не можете отключить это). Бэкапы делаются обычно раз в сутки в рамках окна обслуживания.
• Retention (срок хранения). Это ваш RPO (Recovery Point Objective). Если Retention = 7 дней, вы можете восстановить базу на любой момент времени за последние 7 дней. Для продакшена рекомендуется 35 дней (максимум у многих провайдеров).
• Окно бэкапов. В это время провайдер создает полный снапшот. БД продолжает работать, но нагрузка на диск может вырасти (IOPS). Выбирайте окно, когда нагрузка минимальна (например, ночь по вашему часовому поясу).
• Долгосрочное хранение. Некоторые провайдеры позволяют экспортировать бэкапы в объектное хранилище (S3) на годы. Используйте это для соответствия регуляторным требованиям (например, хранить 5 лет).
• Бэкапы не бесплатны. Провайдер хранит их в своем хранилище, и вы платите за каждый ГБ, занятый бэкапами (обычно дешевле, чем основной диск, но все равно деньги). Если у вас база 500 ГБ и Retention = 35 дней, бэкапы могут занимать еще несколько сотен ГБ.

5. Получить endpoint → прописать в приложении вместо localhost.

• После создания инстанса вы получаете DNS-имя (эндпоинт). Строка подключения выглядит так:

postgresql://app_user:****@mydb.abc123.eu-west-1.rds.amazonaws.com:5432/shop
         ^роль      ^секрет  ^хост провайдера                      ^порт ^БД

Разработчик подключается так же, как к "своему" серверу — через драйвер (psycopg, JDBC). Отличие — хост в интернете/VPC и политика SSL.

Что изменилось по сравнению с локальной БД?

• хост;
• порт;
• SSL/TLS обязателен;
• пользователь.

DNS-имя эндпоинта может резолвиться в разные IP-адреса при failover (переключении на реплику). Это значит, что если ваше приложение кеширует IP-адрес (например, через psycopg2 без hostaddr), то при переключении мастера подключения могут упасть. Всегда используйте DNS-имя, а не IP.

---

Бэкап в облаке — на что смотреть

Вопрос	Зачем спрашивать	Пример
Retention	Хватит ли окна для "удалили таблицу 3 недели назад"	7 дней — мало; 35 — чаще достаточно
Авто или ручной snapshot	Перед крупной миграцией — точка отката "здесь и сейчас"	Snapshot перед ALTER на 200 ГБ таблице
Cross-region copy	Падение целого региона AWS/GCP	Replica + snapshot в другом регионе
pg_dump	Перенос версии, одна таблица, аудит	Дополняет snapshot, не заменяет
Object storage (S3)	Дешёвое долгое хранение	Дольше восстановление

1. Retention и механика PITR

Указанное значение 35 дней соответствует верхнему пределу ряда провайдеров (AWS RDS, Yandex Managed PostgreSQL), однако лимиты различаются в зависимости от сервиса и тарифного плана. Важно разделять понятия:

• Автоматические снэпшоты создают базовую точку восстановления.
• PITR (Point-in-Time Recovery) требует непрерывной архивации WAL-журналов (Write-Ahead Log). Снэпшот + WAL-сегменты позволяют восстановить состояние БД до произвольной секунды в пределах retention-окна.

При настройке retention учитывайте объём WAL-архивов: он растёт пропорционально интенсивности записи (INSERT/UPDATE/DELETE/VACUUM). В управляемых сервисах WAL-архивация обычно включается автоматически вместе с резервным копированием; в self-hosted средах её необходимо конфигурировать вручную (wal_level = replica, archive_mode = on, archive_command).

2. Автоматические и ручные снэпшоты

Ручные снэпшоты не подчиняются политике retention и хранятся до явного удаления. В production-среках это приводит к неконтролируемым затратам, если не внедрён жизненный цикл:

• Используйте тегирование (например, env=prod, purpose=pre-migration, created=YYYY-MM-DD).
• Автоматизируйте удаление по расписанию или через встроенные lifecycle-правила провайдера.
• Интегрируйте создание/удаление ручных снэпшотов в CI/CD или миграционные скрипты, чтобы исключить человеческий фактор.

3. Cross-region copy и Disaster Recovery

Копирование бэкапов в другой регион снижает риск потери данных при отказе дата-центра, но не заменяет полноценную DR-архитектуру. Для соответствия RPO/RTO в часах требуется:

• Заранее подготовленная инфраструктура в целевом регионе (VPC, подсети, IAM-роли, секреты).
• Скрипты автоматического развёртывания или standby-реплика, способная принять трафик.
• Учёт стоимости исходящего трафика и хранения в целевом регионе.

Многие провайдеры предлагают нативные инструменты кросс-регионального резервирования. Их использование предпочтительнее ручной организации копирования, так как они гарантируют согласованность метаданных и WAL-архивов.

4. Логические бэкапы (pg_dump / pg_restore)

pg_dump формирует логическую копию схемы и данных. При объёмах от сотен ГБ восстановление занимает значительное время из-за последовательного выполнения SQL-операторов и перестройки индексов. Для оптимизации:

• Используйте формат custom (-Fc) или directory (-Fd) с флагом -j для параллельного восстановления.
• Учтите ограничения совместимости: pg_dump от версии N не гарантирует корректное восстановление в версию N-1 из-за изменений в системных каталогах и форматах хранения.
• Логические бэкапы не сохраняют физическую структуру файлов, настройки postgresql.conf, pg_hba.conf или расширения, установленные на уровне кластера.

5. Object Storage для архивации

Хранение бэкапов в S3-совместимом хранилище экономически оправдано для долгосрочного архива. Рекомендуется:

• Использовать классы холодного хранения (Glacier, Cold Storage, Archive) с автоматическим переходом через lifecycle-правила.
• Учитывать задержку retrieval: восстановление из архивных классов занимает от нескольких часов до суток.
• Не использовать Object Storage как единственную точку восстановления для систем с низким RTO.

6. Инженерные дополнения к стратегии

• Мониторинг: настройте алерты на статус создания бэкапов, объём WAL-архивов, отставание реплик и потребление хранилища.
• Тестирование: ежемесячное восстановление в изолированном окружении обязательно. Проверяйте целостность данных, работоспособность приложения и фактическое время восстановления.
• Безопасность: шифруйте бэкапы на стороне провайдера (KMS) и в объектном хранилище. Ограничьте доступ через IAM-политики, ведите аудит операций удаления.
• Документация: поддерживайте runbook с пошаговыми инструкциями по восстановлению, включая зависимости (сети, DNS, секреты, лицензии, внешние сервисы).

Snapshot и pg_dump простыми словами:

• Snapshot — фотография диска сервера БД целиком; быстро восстановить весь инстанс; нужен доступ к облачной консоли/API.
• pg_dump — логический экспорт SQL/архива; удобно перенести одну БД на ноутбук или в другую версию PG; восстановление может идти часами на больших объёмах.

В Справочник по Microsoft SQL Server — резервное копирование в облако для SQL Server; идеи те же.

---

Роль "облачного DBA"

Управляемые сервисы баз данных (Managed PostgreSQL, Aurora, Cloud SQL) снимают с команды рутину по обслуживанию инфраструктуры: установку патчей, настройку репликации, замену дисков. Однако они не устраняют необходимость в инженерном контроле над данными. Роль «облачного DBA» в этой модели трансформируется: от администрирования сервера — к управлению конфигурацией, надёжностью и взаимодействием с приложением.

Частые обязанности:

• Terraform / Pulumi / CloudFormation для воспроизводимых окружений;
• секреты в Vault / Parameter Store;
• алерты — disk full, replication lag, connections near max;
• runbook: "как поднять read replica", "как откатить миграцию";
• согласование с разработкой по конкурентному доступу и длинным транзакциям.

Разработчик в облаке всё равно должен знать SQL и транзакции — managed не прощает N+1 и блокировки на горячих строках.

Инфраструктура как код: воспроизводимость и контроль версий

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

• Terraform / Pulumi / CloudFormation описывают инстанс БД, параметры группы параметров (parameter group), правила бэкапов, сетевой доступ и политики шифрования в декларативном виде.
• Любое изменение проходит через code review, фиксируется в Git и может быть откатено.
• Одинаковые конфигурации для dev/stage/prod снижают риск «работает у меня, но не в продакшене».

Инженерный нюанс: параметры, влияющие на производительность (work_mem, max_connections, effective_cache_size), должны задаваться через IaC, а не вручную. Иначе после пересоздания инстанса (например, при масштабировании) настройки «уплывут», и поведение БД изменится непредсказуемо.

Управление секретами: безопасность без компромиссов

Пароли, строки подключения, TLS-сертификаты — критичные данные, утечка которых ведёт к компрометации всей системы. Хранить их в коде, .env-файлах или конфигурациях приложения недопустимо.

• HashiCorp Vault, AWS Secrets Manager, Yandex Lockbox или Azure Key Vault предоставляют централизованное хранение с ротацией, аудитом и гранулярным доступом.
• Приложение получает доступ к секретам через IAM-роли или временные токены, а не статические учётные данные.
• Ротация паролей БД должна быть автоматизирована: вручную менять пароль в продакшене — источник простоев.

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

Алертинг: не ждать инцидента, а предвидеть его

Мониторинг без алертов — просто сбор метрик. Эффективная стратегия оповещений строится вокруг трёх принципов: значимость, действие, эскалация.

Метрика	Порог срабатывания	Действие инженера
DiskUsage > 85%	Критично	Очистка временных данных, масштабирование диска, анализ роста
ReplicationLag > 30s	Warning	Проверка нагрузки на реплику, сети, long-running запросов
ActiveConnections / MaxConnections > 90%	Критично	Поиск утечек соединений, настройка пула (PgBouncer), масштабирование
CheckpointTime > 30s	Warning	Настройка checkpoint_completion_target, анализ IOPS

Алерты должны быть привязаны к runbook: каждое уведомление содержит ссылку на инструкцию «что делать дальше». Без этого команда тратит время на диагностику в момент стресса, а не на восстановление.

Runbook: операционная память команды

Runbook — это пошаговая инструкция по выполнению рутинных или аварийных операций. Он снижает зависимость от «единственного эксперта» и ускоряет реакцию при инцидентах.

Примеры обязательных runbook для облачной БД:

• Как поднять read replica: от создания снэпшота до проверки репликации и переключения приложения.
• Как откатить миграцию: порядок действий при неудачном ALTER TABLE, включая восстановление из ручного снэпшота и применение pg_restore для частичного отката.
• Как диагностировать блокировки: запросы к pg_locks, pg_stat_activity, интерпретация wait_event_type.
• Как восстановить данные после DELETE без WHERE: использование PITR, извлечение таблицы из логического дампа, верификация целостности.

Runbook должен быть живым документом: обновляться после каждого инцидента и тестироваться в учебном окружении.

Согласование с разработкой: данные — общая ответственность

Managed-сервис не защищает от некорректных запросов. Блокировки, длительные транзакции, N+1-запросы — всё это влияет на доступность и производительность, независимо от того, кто администрирует инфраструктуру.

Облачный DBA должен участвовать в ревью архитектуры на ранних этапах:

• Конкурентный доступ: объяснять разработчикам разницу между ACCESS SHARE, ROW EXCLUSIVE, ACCESS EXCLUSIVE lock и последствиями LOCK TABLE в продакшене.
• Длинные транзакции: транзакция, открытая более нескольких минут, удерживает старые версии строк (в PostgreSQL — через MVCC), препятствуя VACUUM и раздувая таблицу.
• Пул соединений: приложение не должно открывать по соединению на каждый запрос. Используйте PgBouncer или аналог, настраивайте pool_mode = transaction.

Практическое правило: если разработчик не может объяснить, почему его запрос не заблокирует продакшен на 10 минут — такой запрос не попадает в релиз.

Почему разработчик всё равно должен знать SQL и транзакции

Managed-сервис абстрагирует инфраструктуру, но не логику данных. Ошибки на уровне приложения остаются ответственностью команды разработки:

• N+1-запросы создают нагрузку, которую не компенсирует даже мощный инстанс.
• Отсутствие индексов или неправильный порядок колонок в составном индексе ведёт к full scan и блокировкам.
• Транзакции без явного завершения (COMMIT/ROLLBACK) оставляют соединения в состоянии idle in transaction, исчерпывая лимиты.

Облачный DBA не пишет бизнес-логику за разработчиков. Но он обязан предоставлять инструменты для самопроверки: slow query log, объяснение планов выполнения (`EXPLAIN ANALYZE»), шаблоны корректных миграций.

---

Высокая доступность (HA) в облаке

Типовые паттерны (названия у провайдеров разные, смысл общий):

Паттерн	Что даёт	На что смотреть
Multi-AZ / зона доступности	Standby в другой зоне; failover при падении AZ	Время переключения, потеря ли последних секунд (RPO)
Read replica	Масштаб чтения, отчёты не бьют по primary	Lag реплики, что replica не для emergency write
Cross-region replica	DR при падении региона	Стоимость, задержка, конфликт при split-brain (редко)
Connection pooler (RDS Proxy, PgBouncer)	Стабильнее при множестве коротких коннектов от Lambda/K8s	Лимит max_connections на маленьких инстансах

Failover — не "магия" — приложение должно переподключаться (pool с retry), DNS/endpoint меняется у провайдера, возможен краткий разрыв сессий.

1. Multi-AZ / зона доступности

• Механизм репликации: в большинстве современных managed-сервисов (AWS RDS, Yandex Managed PostgreSQL, Google Cloud SQL) используется синхронная или полусинхронная репликация между primary и standby в разных зонах. Это гарантирует RPO = 0: коммит подтверждается только после записи WAL на оба узла.
• Влияние на производительность: синхронная запись увеличивает задержку INSERT/UPDATE на 1–5 мс на каждую операцию в зависимости от расстояния между зонами и качества сети.
• Время failover: обычно 30–120 секунд. Включает: детекцию недоступности primary, остановку старого узла, раскрутку standby до primary, обновление DNS/endpoint, прогрев shared buffers.
• На что смотреть: стоимость (обычно +40–100% к базовому инстансу), влияние на write latency, автоматическое переключение без потери зафиксированных данных, но с разрывом активных сессий.

2. Read replica

• Механизм: асинхронная потоковая репликация на уровне WAL. Primary не ожидает подтверждения от реплики перед коммитом.
• Назначение: масштабирование чтения, вынос аналитических запросов, создание бэкапов без нагрузки на primary. Не предназначен для автоматического failover в стандартной конфигурации.
• Репликационный лаг: зависит от скорости записи на primary, пропускной способности сети, нагрузки на реплику (VACUUM, аналитические запросы). При лаге > N секунд данные на реплике неконсистентны с primary.
• Продвижение (promote): превращение реплики в primary — операция, требующая ручного или полуавтоматического подтверждения. После продвижения реплика теряет связь с исходным primary и становится самостоятельным кластером.

3. Cross-region replica

• Назначение: Disaster Recovery (DR). Позволяет восстановить инфраструктуру в другом географическом регионе при потере целого региона.
• RPO/RTO: RPO обычно составляет от нескольких секунд до минут из-за асинхронности и расстояния. RTO зависит от готовности инфраструктуры в целевом регионе: если VPC, IAM, секреты и CI/CD уже подготовлены — часы; если нет — дни.
• Стоимость: исходящий трафик между регионами, отдельная оплата хранилища и вычислительных ресурсов, затраты на поддержку инфраструктуры в двух регионах.
• Split-brain: в managed-средах исключён архитектурно, так как promotion контролируется через API/консоль. При ручном вмешательстве возможна рассинхронизация, поэтому рекомендуется строгая процедура DR-drill и изоляция сетей.

4. Connection pooler

• Назначение: стабилизация соединений при множестве коротких запросов от serverless-функций (AWS Lambda, Cloud Functions), K8s-подов или микросервисной архитектуры.
• Режимы работы:
  • session — соединение привязано к клиенту до закрытия. Подходит для приложений, использующих временные таблицы, переменные сессии, prepared statements.
  • transaction — соединение возвращается в пул после COMMIT/ROLLBACK. Оптимально для stateless-приложений и serverless.
• На что смотреть: лимиты на количество соединений со стороны пулера и БД, время ожидания в очереди (queue timeout), обработка таймаутов, совместимость с prepared statements и транзакционными паттернами. Неправильная настройка режима может приводить к ERROR: prepared statement "..." does not exist или потере контекста сессии.

Failover: требования к приложению

Failover — это не прозрачное переключение. Приложение должно быть спроектировано с учётом следующих фактов:

• DNS/endpoint: провайдер обновляет CNAME или внутренний DNS. Клиенты кешируют IP-адреса до истечения TTL. Современные SDK и пулы соединений разрешают имя заново при потере соединения.
• Разрыв сессий: все активные транзакции откатываются. Временные таблицы, session variables, prepared statements теряются.
• Retry-логика: пул соединений на стороне приложения (HikariCP, Npgsql, SQLAlchemy, Prisma, Go database/sql) должен автоматически переподключаться с экспоненциальной задержкой и ограниченным числом попыток.
• Идемпотентность: операции повторного выполнения после разрыва не должны приводить к дублированию данных или нарушению бизнес-логики. Используйте идемпотентные ключи, INSERT ... ON CONFLICT, транзакционные барьеры.

Операционные аспекты HA

• Мониторинг: статус репликации, лаг (в секундах и байтах WAL), состояние standby, события failover, время переключения, загрузка пулера.
• Тестирование: регулярные drills в staging-окружении. Имитация падения primary, проверка времени восстановления, целостности данных, поведения приложения при разрыве соединений.
• Документация: runbook по ручному failover, откату, диагностике лага, настройке пулера, проверке консистентности после восстановления.
• Баланс стоимости и надёжности: HA увеличивает стоимость на 40–100%, cross-region DR — кратно дороже. Выбор должен основываться на SLA, RPO/RTO, регуляторных требованиях и бюджете, а не на «общепринятых практиках».

---

Стоимость — за что платите

Managed-счёт обычно складывается из:

• инстанс (vCPU, RAM) × часы;
• хранилище (ГБ/месяц, тип диска gp3/io2);
• IOPS сверх базового лимита;
• исходящий трафик и бэкапы в object storage;
• лицензии (Oracle/SQL Server в облаке дороже open-source PG).

"Подняли db.t3.micro" дешево, пока не выросли данные и не включили HA + 35 дней PITR. FinOps и DBA вместе смотрят стоимость на запрос (CPU wait, disk queue depth), а не только размер инстанса.

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

Компоненты счёта: что влияет на итоговую сумму

Компонент	Единица измерения	Что увеличивает стоимость	Инженерный нюанс
Вычислительные ресурсы	vCPU + RAM × часы	Выбор инстанса «с запасом», отсутствие автоскейлинга, простаивающие dev-окружения	Burstable-инстансы (t3/t4g) дешевы, но при длительной нагрузке > baseline CPU получают штраф в виде снижения производительности. Для стабильной нагрузки выгоднее фиксированные инстансы (m6g, c6g).
Хранилище	ГБ/месяц, тип диска	Рост данных, хранение бэкапов, логи, временные файлы, неочищенные архивы	gp3 (AWS) или network-ssd (Yandex) дают предсказуемую производительность. io2/io1 — только для workload с экстремальными требованиями к IOPS. Не платите за премиум-диск, если нагрузка не требует 16 000+ IOPS.
IOPS сверх лимита	Запрос/сек сверх базового	Всплески записи, отсутствие кэширования, неоптимальные индексы, full scan	На gp3 вы платите за выделенные IOPS отдельно от объёма. На gp2 IOPS привязаны к размеру диска — иногда выгоднее увеличить диск, чем покупать IOPS.
Исходящий трафик	ГБ исходящих данных	Репликация в другой регион, выгрузка бэкапов в S3, доступ извне облака	Входящий трафик обычно бесплатен. Исходящий — платный, особенно межрегиональный. Cross-region replica и бэкапы в другой регион могут добавить 10–30% к счёту.
Резервное копирование	ГБ × дни retention	Длительный retention, хранение ручных снэпшотов, WAL-архивы	Автоматические бэкапы часто включены в базовую стоимость до определённого лимита (например, 100% от размера БД). Всё сверх — платно. Ручные снэпшоты не удаляются автоматически — источник «тихих» расходов.
Лицензии СУБД	Почасовая надбавка	Использование Oracle, SQL Server вместо PostgreSQL/MySQL	Лицензия SQL Server на RDS может стоить в 3–5× дороже самого инстанса. Open-source СУБД (PostgreSQL, MySQL) не имеют лицензионных наценок.
Дополнительные сервисы	Почасовая или помесячная оплата	RDS Proxy, PgBouncer как сервис, мониторинг, аудит, шифрование KMS	Connection pooler как managed-сервис удобен, но добавляет 10–20% к стоимости инстанса. Self-hosted PgBouncer на отдельном микро-инстансе может быть в 5× дешевле.

Скрытые драйверы затрат

1. Бэкапы и PITR: включение Point-in-Time Recovery требует хранения WAL-архивов за весь период retention. При интенсивной записи объём WAL может достигать 20–50% от размера данных в сутки. Это не всегда очевидно в интерфейсе провайдера.

2. Ручные снэпшоты: созданный перед миграцией снэпшот «на всякий случай» остаётся в хранилище бессрочно, если его не удалить явно. В крупных проектах накопленные «забытые» снэпшоты могут превышать стоимость активных инстансов.

3. Read replica для аналитики: реплика масштабирует чтение, но каждая реплика — это полный инстанс с оплатой за вычисления, диск и трафик репликации. Три реплики = +300% к инфраструктурной стоимости.

4. Dev/Staging окружения: часто развёртываются как копии продакшена, но используются 8 часов в день. Без автостопа/автостарта по расписанию они потребляют 70% бюджета при 30% полезной нагрузки.

5. Неоптимальные запросы: высокий CPU wait, disk queue depth, blk_read_time в pg_stat_statements — индикаторы того, что вы платите за вычисления, которые можно устранить индексом или рефакторингом запроса.

FinOps для баз данных: метрики и практики

Сотрудничество FinOps и DBA смещает фокус с «сколько стоит инстанс» на «сколько стоит бизнес-операция».

Ключевые метрики:

• Cost per query: общая стоимость инстанса / количество запросов в секунду. Позволяет оценить эффективность оптимизаций.
• CPU utilization per ruble: насколько эффективно используются оплаченные vCPU. Низкая утилизация при высокой стоимости — сигнал к даунсайзингу или консолидации.
• Storage efficiency: отношение полезных данных к общему объёму диска. Включает bloat от VACUUM, неиспользуемые индексы, логи.
• Backup cost ratio: стоимость хранения бэкапов / стоимость активных данных. Значение >30% требует пересмотра retention-политики или перехода на холодное хранение.

Практики оптимизации:

• Автоскейлинг по нагрузке: настройка правил масштабирования vCPU/RAM/диска на основе метрик CloudWatch / Yandex Monitoring. Важно: тестировать пороги срабатывания, чтобы избежать «пилы» (частых переключений).
• Расписание для non-prod: автоматический останов dev/staging инстансов в нерабочее время (например, 20:00–08:00 и выходные). Экономия до 60% на окружениях, не требующих 24/7.
• Холодное хранение бэкапов: экспорт долгосрочных архивов в S3 Glacier / Cold Storage через lifecycle-правила. Стоимость хранения падает в 5–10×.
• Консолидация инстансов: несколько небольших БД с низкой нагрузкой можно объединить на одном инстансе с изоляцией через схемы/роли. Снижает накладные расходы на базовую инфраструктуру.
• Регулярный аудит: ежемесячный review счёта с детализацией по сервисам, тегам, окружениям. Выявление «зомби-ресурсов» (остановленные, но не удалённые инстансы, откреплённые диски).

---

Runbook — три частых инцидента

1. Диск заполнен

Симптомы: could not extend file, алерт 95% disk. Действия — найти рост WAL (долгий checkpoint, архив не уходит), логи, временные файлы; расширить том; VACUUM/очистка bloat — не паника DELETE без анализа.

---

2. Слишком много подключений

Симптомы: too many connections. Действия — PgBouncer / RDS Proxy, уменьшить пул в приложении, найти утечку "забыли закрыть connection", не поднимать max_connections бесконечно.

---

3. Отставание реплики

Симптомы: replication lag растёт. Действия — тяжёлый DDL на primary, долгая транзакция, медленный диск на replica; не гонять отчёты на отстающую реплику с "свежими" цифрами.

Каждый пункт должен быть заранее в Confluence/runbook, а не импровизацией в 3 ночи.

---

Синий/зелёный релиз и миграции схемы

При крупных миграциях в облаке иногда поднимают новый инстанс с новой схемой, переключают приложение DNS/secret, старый гасят — аналог blue-green на уровне БД. Это снижает риск "долгого ALTER на prod", но требует продуманной синхронизации данных на переходный период (dual write, CDC).

---

Managed (RDS и аналоги) и своя VM с PostgreSQL

Критерий	Своя VM / on-prem	Managed (RDS, Cloud SQL, …)
Время до prod	Дольше: ОС, патчи, мониторинг	Быстрее: endpoint за минуты
Контроль параметров	Почти полный postgresql.conf	Whitelist + тикет в поддержку
Ответственность за ОС	Ваша	Провайдера
Ответственность за SQL/схему	Ваша	Ваша
DR между регионами	Сами строите	Кнопки + доп. плата
Стоимость при стабильной нагрузке 3+ года	Иногда ниже (CapEx)	OpEx, рост с диском и HA
Аудит "мы не трогали файлы PG"	Сами	Провайдер + ваши миграции

Выбор где провести границу shared responsibility: команда сильна в IaC и слаба в железе — managed; нужен PostGIS + экзотика + тюнинг ядра — чаще своя установка или гибрид.

---

Когда облако не панацея

Решение должно приниматься на основе:

1. Требований (регуляторика, SLA, latency);
2. Экономики (TCO на 3 года, а не месячная стоимость);
3. Компетенций команды (готовность эксплуатировать инфраструктуру);
4. Стратегии (скорость выхода на рынок vs долгосрочный контроль).

1. Регуляторные ограничения: только on-premises

Контекст: отрасли с жёсткими требованиями к локализации данных (финансы, госсектор, здравоохранение, телеком) часто запрещают хранение и обработку данных вне периметра организации.

Требование	Почему облако может не подойти	Альтернатива
ФЗ-152, 187-ФЗ (РФ), GDPR (ЕС), HIPAA (США)	Провайдер может не иметь сертификатов для конкретного класса данных; аудит доступа к физическим носителям невозможен	On-prem кластер с шифрованием на уровне диска, изолированной сетью и локальным HSM
Отраслевые стандарты (ПК СБ, ФСТЭК, ЦБ РФ)	Требуется контроль над всеми уровнями стека, включая гипервизор и firmware	Виртуализация на собственном железе с сертифицированными компонентами
Суверенитет данных	Данные не должны покидать географические границы объекта	Локальный ЦОД или приватное облако с гарантией резидентности

Инженерный нюанс: даже если провайдер предлагает «локальную зону» (local zone, dedicated region), юридически данные могут считаться переданными третьей стороне. Требуется согласование с юристами и службой информационной безопасности до начала проектирования.

2. Предсказуемая высокая нагрузка: экономика dedicated-железа

Контекст: при стабильной нагрузке 24/7 с высоким потреблением CPU/RAM/IOPS облачная модель «оплата по факту» может проигрывать капитальным затратам на собственное оборудование.

Сравнительная модель (упрощённо):

Параметр	Managed Cloud (3 года)	On-prem / Dedicated (3 года)
Вычисления	$0.50/час × 24 × 365 × 3 = ~$13 140	Покупка сервера: $8 000 + поддержка 15% = ~$11 600
Хранилище	$0.10/ГБ/мес × 2 ТБ × 36 = ~$7 200	Диски RAID: $2 000 (единовременно)
Лицензия ПО	Включено в тариф	PostgreSQL: $0; Enterprise-инструменты: опционально
Операционные расходы	Включено (патчи, бэкапы, мониторинг)	Зарплата DBA/инженера: ~$60 000/год × 3 = $180 000
Итого	~$20 340 + труд команды	~$193 600 + капитальные вложения

Вывод: облако выигрывает при переменной нагрузке, быстром старте и ограниченной команде. On-prem может быть выгоднее при:

• Стабильной утилизации >70% в течение 2–3 лет;
• Наличии квалифицированной команды эксплуатации;
• Требовании к максимальной производительности без «шумных соседей».

Инженерный нюанс: в облаке вы платите за изоляцию и гибкость. На dedicated-железе вы получаете «голое железо», но несёте полную ответственность за отказ диска, замену блока питания и обновление микрокода.

3. Экзотические расширения и низкоуровневая настройка PostgreSQL

Контекст: Managed-сервисы ограничивают доступ к системным параметрам и расширяемости ради стабильности и безопасности.

Потребность	Ограничение в Managed	Решение on-prem
Кастомные расширения (pg_partman, hypopg, pg_cron, собственные C-модули)	Установка только из whitelist провайдера	Сборка из исходников, установка в shared_preload_libraries
Тонкая настройка ядра (huge_pages, transparent_hugepages, vm.dirty_ratio, I/O scheduler)	Параметры ОС недоступны	Полный контроль через sysctl, systemd, kernel parameters
Патчинг PostgreSQL между минорными версиями	Только по графику провайдера	Применение security-патчей в течение 24 часов после релиза
Модификация ядра PG под специфику workload	Невозможно	Fork исходников, кастомные планировщики, индексные методы

Инженерный нюанс: если ваш workload требует max_parallel_workers_per_gather > 8, work_mem > 256MB или кастомного checkpoint_timeout — Managed-сервис может не позволить такие значения. В on-prem вы платите за гибкость риском ошибки конфигурации.

4. Edge-сценарии: неприемлемая задержка до облака

Контекст: промышленные системы, банкоматы, медицинские устройства, транспорт требуют реакции в миллисекундах и работы при потере связи с центром.

Требование	Проблема облака	Архитектурный паттерн
Latency < 10 мс	Сетевая задержка до региона: 20–100 мс	Локальная БД на edge-устройстве (Raspberry Pi, industrial PC)
Работа offline	Зависимость от интернет-канала	Локальная запись + асинхронная репликация в центр при восстановлении связи
Детерминизм	«Шумные соседи», throttling в облаке	Выделенное железо с RT-ядром или изолированный hypervisor

Паттерн «Edge + Cloud sync»:

1. На edge-устройстве развёртывается легковесная PostgreSQL (или SQLite для простых случаев).
2. Данные записываются локально с гарантией durability.
3. Фоновый процесс реплицирует изменения в центральное облако через защищённый канал (mTLS, VPN).
4. При конфликтах применяется стратегия «edge wins» или «central wins» в зависимости от бизнес-логики.

Инженерный нюанс: синхронизация в двунаправленном режиме требует разрешения конфликтов (CRDTs, timestamp-based, operational transformation). Это добавляет сложность на уровне приложения.

Гибридные подходы: компромисс без крайностей

Не всегда выбор стоит между «только облако» и «только on-prem». Гибридные архитектуры позволяют совместить преимущества:

Сценарий	Архитектура	Преимущества
Регулятор + аналитика	On-prem primary для OLTP + реплика в облако для аналитики	Соответствие требованиям + масштабируемость чтения
Edge + централизация	Локальная БД на устройстве + async-реплика в Managed PG	Низкая задержка + централизованное резервное копирование
Пиковая нагрузка	On-prem база + burst в облако через read replica	Экономия на базовой нагрузке + эластичность при пиках

Ключевые технологии: логическая репликация PostgreSQL, CDC-инструменты (Debezium, Wal2JSON), VPN/Direct Connect для безопасного канала.

---

См. также

• Управление реляционными СУБД
• Справочник PostgreSQL
• Роль базы данных в организации
• Основы NoSQL — managed (сравнение подходов к эксплуатации)

---