«Трагедия общин» в ИТ - это ситуация, когда несколько потребителей бесконтрольно используют общий ресурс, и он деградирует или полностью исчерпывается. Дисковый массив, пул IP-адресов, база данных - любой из этих компонентов выходит из строя не из-за аппаратного отказа, а из-за отсутствия лимитов. Результат: падение производительности, отказы в обслуживании и простой, которых можно избежать квотированием, мониторингом и автоматическими политиками.
Эта статья разбирает механизм проблемы на трёх типичных сценариях: деградация дисковых массивов, истощение пула IP-адресов и коллизии в базах данных. Для каждого сценария даны конкретные методы контроля - от настройки квот в ZFS до ResourceQuotas в Kubernetes. Вы получите проверенные на практике инструкции, которые сразу применимы в работе.
Что такое «трагедия общин» в ИТ-инфраструктуре
Экономическая теория «трагедии общин» описывает ситуацию, когда группа лиц действует рационально, но коллективный результат разрушителен. Классический пример: общее пастбище, где каждый пастух увеличивает поголовье скота для личной выгоды. Пастбище истощается - страдают все. В ИТ-инфраструктуре тот же механизм: общие ресурсы потребляются без оглядки на соседей, пока система не перестаёт работать.
Общие ресурсы в ИТ - это дисковое пространство и пропускная способность хранилищ, сетевые адреса, пулы соединений к базам данных, процессорное время на гипервизорах. Без контроля каждый тенант или сервис захватывает столько, сколько может. Когда лимит исчерпан, новые запросы получают отказ, а существующие - деградацию. Проблема усугубляется в виртуализированных и контейнеризированных средах, где границы между потребителями размыты.
Ключевое отличие от обычного отказа оборудования: ресурс физически исправен, но логически недоступен. Диски вращаются, сеть работает, база данных отвечает - но производительность упала на порядок. Причина не в «железе», а в архитектуре доступа. Поэтому решение лежит не в замене компонентов, а в изменении политик управления.
Реальные последствия отсутствия контроля общих ресурсов
Три сценария ниже - не гипотетические. Это обезличенные кейсы из практики администрирования, где отсутствие лимитов приводило к измеримым потерям. Каждый сценарий разбирается по цепочке: причина, механизм отказа, симптомы, время простоя.
Деградация дисковых массивов: когда один «съедает» всё
Виртуализированная среда на базе VMware с общим дисковым массивом. Десять виртуальных машин, одна из которых - сервер резервного копирования, запускающий полное копирование в рабочее время. Без ограничений на IOPS этот сервер захватывает до 90% пропускной способности хранилища. Остальные ВМ получают задержки ввода-вывода от 50 до 200 мс - против штатных 2-5 мс.
Механизм отказа: очередь ввода-вывода на контроллере массива переполняется запросами от одного инициатора. Контроллер честно обрабатывает их в порядке поступления. Остальные инициаторы ждут. Приложения на «тихих» ВМ начинают таймаутиться по операциям с диском. Базы данных переходят в режим восстановления. Пользователи видят ошибки 503.
Симптомы: график IOPS в мониторинге показывает ровное плато на максимуме возможностей массива, задержки растут экспоненциально. В логах гостевых ОС - сообщения о таймаутах SCSI-команд. Время до обнаружения: от 15 минут до нескольких часов, если нет алертов на задержку. Решение на стороне хранилища - включение квот на IOPS на уровне LUN или dataset. Подробнее о диагностике таких ситуаций - в статье Диагностика и устранение неполадок контроллера RAID/дискового массива.
Истощение пула IP-адресов: скрытая угроза оркестрации
Кластер Kubernetes из 10 узлов, подсеть для подов /21 (2048 адресов). Разработчики разворачивают микросервисы с репликацией 5-10 подов на сервис. Без ResourceQuotas и контроля за количеством подов в namespace пул адресов расходуется за несколько недель активной разработки. Новые поды не могут получить IP - они остаются в статусе ContainerCreating с ошибкой «failed to allocate IP address».
Механизм отказа: IPAM-плагин (например, Calico или Cilium) ведёт учёт выданных адресов в своём блоке. Когда блок исчерпан, новые аллокации невозможны. Проблема усугубляется тем, что «мёртвые» поды не всегда освобождают адреса вовремя - IP остаётся зарезервированным на время grace period. Пул фрагментируется, реально свободных адресов меньше, чем кажется.
Симптомы: в описании пода - событие «FailedCreatePodSandBox» с детализацией об ошибке IPAM. Команда kubectl get pods -A | grep ContainerCreating показывает растущий список. Время простоя: пока администратор не расширит подсеть или не очистит зависшие аллокации - новые сервисы не стартуют. Решение: настройка ResourceQuota на количество подов, мониторинг утилизации подсети через метрики CNI-плагина, автоматическое расширение пула через IPAM с несколькими подсетями.
Коллизии в базах данных: борьба за соединения
Микросервисная архитектура с 15 сервисами, использующими один кластер PostgreSQL. Каждый сервис открывает пул соединений через HikariCP, но параметр maximumPoolSize везде выставлен в значение по умолчанию - 10. Итог: 150 потенциальных соединений при max_connections на сервере = 100. Когда сервисы одновременно обрабатывают всплеск запросов, база данных отклоняет новые соединения с ошибкой «FATAL: sorry, too many clients already».
Механизм отказа: PostgreSQL порождает отдельный процесс на каждое соединение. Пул в 100 процессов - это не только память, но и конкуренция за блокировки таблиц. Когда лимит исчерпан, даже служебные соединения (мониторинг, репликация) могут быть отклонены. Сервисы, не получившие соединение, уходят в экспоненциальный backoff, каскадно увеличивая задержки ответа.
Симптомы: в логах приложений - ошибки пула соединений, в логах БД - «too many clients». График активных соединений в Grafana упирается в горизонтальную линию max_connections. Время до разрешения: от немедленного (убить часть соединений вручную) до часов (если нужно пересматривать архитектуру пулов). Решение: установка connection pooler (PgBouncer, Odyssey) перед базой данных, расчёт лимитов на сервис по формуле «max_connections / количество сервисов», мониторинг утилизации пула с алертом на 80%.
Практические методы предотвращения «трагедии общин»
Методы контроля общих ресурсов делятся на три уровня: квотирование (жёсткие лимиты), мониторинг (раннее обнаружение) и автоматические политики (проактивное управление). Все три должны работать вместе. Квоты без мониторинга дают ложное чувство безопасности. Мониторинг без квот - только констатирует аварию. Автоматика без первых двух - неуправляема.
Квотирование: как ограничить аппетиты
Квотирование - установка жёстких лимитов на потребление ресурса каждым потребителем. Работает на всех уровнях стека.
Хранилище - ZFS dataset quotas. ZFS поддерживает два типа квот: quota (жёсткий лимит на объём данных) и refquota (лимит без учёта дочерних snapshot'ов). Пример установки квоты в 100 ГБ на dataset:
zfs set quota=100G tank/vm/tenant-aПри достижении лимита запись блокируется, файловая система возвращает ошибку «Disk quota exceeded». Для контроля IOPS на уровне ZFS прямого механизма нет - лимитирование выполняется на уровне гипервизора или через NFS-сервер с настройкой rate limiting. В TrueNAS эти параметры задаются через веб-интерфейс в разделе Storage → Datasets.
Сеть - rate limiting в Nginx. Для ограничения пропускной способности на уровне приложения используется модуль ngx_http_limit_req_module. Пример конфигурации для ограничения API-эндпоинта до 100 запросов в секунду с бакетом на 200 запросов:
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
server {
location /api/ {
limit_req zone=api_limit burst=200 nodelay;
proxy_pass http://backend;
}
}Для ограничения bandwidth используется модуль ngx_http_limit_conn_module и директива limit_rate.
Вычислительные ресурсы - Kubernetes ResourceQuotas и LimitRanges. ResourceQuota ограничивает суммарное потребление ресурсов в namespace. Пример квоты на 20 подов, 100 CPU-ядер и 200 ГБ памяти:
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-quota
namespace: tenant-a
spec:
hard:
pods: "20"
requests.cpu: "100"
requests.memory: "200Gi"
limits.cpu: "200"
limits.memory: "400Gi"LimitRange задаёт значения по умолчанию и минимальные/максимальные лимиты для отдельных подов в namespace. Без LimitRange под без явных limits может захватить всю доступную память узла. Диагностика проблем с подами через метрики помогает быстро найти нарушителя при срабатывании квот.
Мониторинг: видеть проблему до того, как она станет катастрофой
Квоты задают границы, мониторинг показывает приближение к ним. Ключевые метрики для отслеживания:
- Дисковое пространство: процент использования файловой системы (метрика node_filesystem_avail_bytes / node_filesystem_size_bytes). Алерт на 80% и 90%.
- IOPS и задержки: метрики node_disk_reads_completed_total, node_disk_writes_completed_total для количества операций; node_disk_read_time_seconds_total и node_disk_write_time_seconds_total для расчёта средней задержки. Алерт на задержку выше 50 мс в течение 5 минут.
- Свободные IP-адреса: зависит от IPAM-плагина. Для Calico - метрика ipam_blocks_per_node, для Cilium - cilium_ipam_addresses_available. Алерт при падении ниже 10% пула.
- Соединения к БД: метрика pg_stat_database_numbackends для PostgreSQL, threads_connected для MySQL. Алерт на 80% от max_connections.
Стек Prometheus + Grafana + Alertmanager покрывает все перечисленные метрики. Prometheus собирает данные по HTTP с экспортёров (node_exporter для системных метрик, postgres_exporter для БД). Grafana визуализирует тренды - критично видеть не только текущее значение, но и скорость потребления. Alertmanager отправляет уведомления в Telegram, Slack или на email при выходе за пороги. Пример правила алерта для дискового пространства:
groups:
- name: storage
rules:
- alert: DiskSpaceLow
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.2
for: 5m
labels:
severity: warning
annotations:
summary: "Дисковое пространство на {{ $labels.instance }} ниже 20%"Статья Метрики производительности систем и сетей детально разбирает интерпретацию этих показателей и инструменты командной строки для оперативной диагностики.
Автоматические политики управления: переход от реакции к проактивности
Автоматические политики устраняют задержку между обнаружением проблемы и реакцией. Вместо того чтобы будить администратора ночью, система сама расширяет пул или очищает неиспользуемые ресурсы.
Автоматическое расширение пула IP-адресов. В Kubernetes с Calico можно заранее описать несколько IP-пулов и настроить автоматическое переключение при исчерпании первого:
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
name: pool-2
spec:
cidr: 10.20.0.0/21
blockSize: 26
nodeSelector: "all()"При исчерпании pool-1 новые поды автоматически получат адреса из pool-2. Важно: это не решает проблему фрагментации, а только откладывает её. Полное решение - регулярная очистка «мёртвых» аллокаций через CronJob, который принудительно удаляет поды в статусе Error или Completed старше N часов.
Динамическое квотирование через Kubernetes LimitRange. LimitRange с defaultRequest задаёт базовые лимиты для подов, у которых они не указаны явно. Это предотвращает ситуацию, когда «забывчивый» разработчик разворачивает под без limits и тот захватывает всю память узла:
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: tenant-a
spec:
limits:
- default:
memory: "512Mi"
cpu: "500m"
defaultRequest:
memory: "256Mi"
cpu: "250m"
type: ContainerАвтоматическая очистка неиспользуемых ресурсов. Временные окружения (feature branches, тестовые стенды) часто забывают удалить. TTL-контроллер в Kubernetes автоматически уничтожает ресурсы с истекшим сроком жизни. Для подов и namespace можно задать аннотацию с временем жизни. Инструмент kube-janitor реализует эту логику: он ищет ресурсы с аннотацией janitor/ttl и удаляет их по истечении указанного времени.
Инструменты и технологии для контроля общих ресурсов
Выбор инструмента зависит от уровня стека, на котором требуется контроль. Ниже - проверенные на практике решения, сгруппированные по категориям.
Хранилища данных.
- TrueNAS / ZFS: встроенные механизмы квотирования (dataset quotas, user quotas, group quotas). Настройка через веб-интерфейс или командную строку. Подходит для NAS-хранилищ, файловых шар, бэкап-серверов.
- NetApp ONTAP: QoS на уровне Storage Virtual Machine (SVM) - можно ограничить IOPS и пропускную способность для каждого тенанта. Актуально для крупных корпоративных сред.
- Ceph: поддержка пулов с квотами на количество объектов и объём данных. RBD-образы можно ограничивать по IOPS через механизм QoS на уровне пула.
Контейнерная оркестрация.
- Kubernetes: ResourceQuota, LimitRange, NetworkPolicy (для ограничения сетевого трафика между подами). Pod Priority и Preemption позволяют вытеснять низкоприоритетные поды при нехватке ресурсов.
- OpenShift: надстройка над Kubernetes с Project Quotas и ClusterResourceQuotas, применимыми на уровне кластера.
Сети и IPAM.
- NetBox: open-source решение для IPAM и DCIM. Ведёт учёт подсетей, VLAN, IP-адресов с историей изменений. Интегрируется с автоматизацией через API.
- Infoblox: коммерческий IPAM/DNS/DHCP с расширенным мониторингом и автоматическим восстановлением пулов.
- Nginx / HAProxy: rate limiting на уровне L7. Позволяет ограничить количество запросов от конкретного клиента или сервиса.
Базы данных.
- PgBouncer: пулер соединений для PostgreSQL. Поддерживает три режима: session, transaction, statement. Режим transaction оптимален для микросервисов - соединение занимается только на время транзакции.
- ProxySQL: пулер и балансировщик для MySQL. Позволяет задавать лимиты на пользователя, кэшировать запросы, маршрутизировать чтение/запись.
Для комплексного подхода к отказоустойчивости инфраструктуры изучите статью Отказоустойчивость IT-систем в 2026: базовые принципы и практика применения, где разбираются методы резервирования и устранения единых точек отказа.
Экономический эффект: почему контроль ресурсов выгоден бизнесу
Час простоя критичного сервиса стоит компании от 100 тысяч до миллиона рублей в зависимости от отрасли. Для e-commerce в высокий сезон эта цифра может достигать 10 миллионов. Деградация производительности - скрытый ущерб: пользователи уходят к конкурентам, не дожидаясь полного отказа. Исследование Google 2023 года показало: увеличение времени загрузки страницы с 1 до 3 секунд повышает показатель отказов на 32%.
Квотирование и мониторинг превращают непредсказуемые аварии в планируемые события. Вместо экстренной закупки дисков в 3 часа ночи по завышенной цене администратор получает алерт за неделю до исчерпания и спокойно заказывает оборудование по плановому бюджету. Разница в стоимости: экстренная закупка обычно на 20-40% дороже из-за срочности и отсутствия выбора поставщиков.
Концепция FinOps применяет эти принципы к облачным ресурсам. Автоматические политики управления снижают перерасход: неиспользуемые виртуальные машины выключаются по расписанию, dev-окружения удаляются через TTL, oversized инстансы автоматически понижаются до адекватного размера. Компании, внедрившие FinOps-практики, сокращают облачные затраты на 25-35% в первый год - данные FinOps Foundation за 2025 год.
Контроль общих ресурсов - не разовая акция, а процесс. Квоты пересматриваются при изменении нагрузки, алерты настраиваются под паттерны использования, автоматические политики корректируются по результатам инцидентов. Системный подход описан в статье База знаний IT в 2026: как систематизировать экспертизу и сократить простои команды - там же даны шаблоны для документирования инцидентов и регламентов.
Начните с аудита текущих ресурсов: составьте список общих компонентов, для каждого определите потребителей и текущие лимиты. Где лимитов нет - установите. Где есть - проверьте, не устарели ли они. Настройте мониторинг на 80% от лимита. Через месяц вы получите baseline потребления, на основе которого можно планировать расширение и оптимизацию. Это не требует капитальных затрат - только время администратора и корректная конфигурация уже имеющихся инструментов.