Capacity Planning

Auto-scaling в k8s сам по себе не заменяет планирование мощностей. Если в кластере нет запаса под все события масштабирования сразу, HPA увидит нагрузку на CPU, попробует добавить поды, упрётся в предел пула узлов или квоту облака — и сервис ляжет ровно так же, как лёг бы без всякого автомасштабирования. Я регулярно вижу команды, уверенные, что «у нас всё в k8s с HPA, планировать нечего». Capacity planning — про прогноз и время на приобретение: сколько ресурсов понадобится через квартал или четыре, сколько времени уходит на их получение, когда из-за этого надо начинать шевелиться. Соседний лист к SLO Engineering под L1 Reliability Engineering.

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

Главный навык на уровне L5 — выводить пороги насыщения из SLO, а не из «80% CPU — паника». У фонового обработчика, который упирается в процессор, 95% CPU — норма. У сервиса, который упирается в сеть и живёт с жёстким дедлайном, уже 50% означают нарушение SLO. Порог, за которым пора действовать, определяется эмпирически: при какой утилизации начинает деградировать нужный SLI — это и есть ваше число. Магические числа из чужих методичек не работают.

Понимает типы ресурсов (CPU, память, диск, сеть, файловые дескрипторы, соединения к базе, IOPS); знает, где смотреть текущую утилизацию.
Читает прогноз и план мощностей своего сервиса; понимает, что значит «запас 30%» и «текущих мощностей хватит на следующий квартал».

Считает запас (headroom): текущее потребление против целевого порога насыщения; прикидывает, когда упрёмся в предел при нынешних темпах роста.
Отрабатывает нехватку ресурсов: знает, как расширяться — триггеры автомасштабирования, ручная выдача, квоты облака, обращение к поставщику.

Проектирует модель мощностей: какие индикаторы насыщения брать (по методу USE), какие пороги выводить из SLO, каков явный бюджет запаса, сколько времени занимает получить ресурс в облаке, у управляемого сервиса и на своём железе.
Делает прогноз спроса на квартал-четыре вперёд: активные пользователи, профиль трафика, сезонность, раскатка фич, маркетинговые кампании, поглощения. Не «по ощущениям», а временные ряды плюс явно записанные допущения.
Связывает планирование с финансами: считает удельную стоимость — на запрос, на активного пользователя, на гигабайт — как метрику эффективности.

L6+

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

Материалы

Книги

Joe Beda et al. (ред. Beyer) — Site Reliability Engineering (O’Reilly, 2016), глава 18 «Software Engineering in SRE». Разбор Auxon — планирования мощностей в Google через декларацию намерения; описывает, чем плох традиционный подход и что даёт intent-based.
Alejandro Forero Cuervo (ред. Beyer) — Site Reliability Engineering (O’Reilly, 2016), глава 21 «Handling Overload». Что делать, когда прогноз ошибся: придушить клиентов, ввести уровни критичности, ограничить бюджет ретраев.

Статьи

Brendan Gregg — The USE Method. Канонический системный подход к производительности и мощностям: для каждого ресурса — Utilization, Saturation, Errors. «Solves 80% of server issues with 5% of the effort». Годится как способ выбрать индикаторы насыщения для модели.

Инструменты

Prometheus + Grafana — мониторинг утилизации и насыщения; recording rules для производных метрик; дашборд с текущим и прогнозным потреблением. Дополняется алертами на пороги насыщения.
Автомасштабирование в k8s — HPA по CPU, памяти или своим метрикам, VPA для рекомендаций по размеру запросов, Cluster Autoscaler на уровне узлов. Закрывает реактивную часть, но планирование не заменяет.
Облачные советчики — AWS Compute Optimizer, GCP Recommender, Azure Advisor. Дают рекомендации по подгонке размеров и резервированию.
Библиотеки прогноза — Prophet, statsmodels, простая линейная регрессия на pandas. По моим наблюдениям, большинству команд хватает линейной регрессии: Prophet избыточен, пока в трафике нет явной сезонности.
Свой дашборд мощностей — текущая утилизация, скользящее среднее за 28 дней, прогнозная кривая и бюджет запаса на одном экране.

Best practices

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

Пороги выводятся из SLO. Магические числа не работают: у фонового обработчика, упирающегося в процессор, и 95% CPU — норма, у сервиса с жёстким дедлайном 50% означают нарушение, и чужая методичка это за вас не решит. Способ один. Посмотреть эмпирически, при какой утилизации начинает деградировать нужный SLI, и взять это число.

И отдельно про автомасштабирование — путаница здесь самая частая. Реактивную часть оно закрывает, всплеск переживёт. Но на вопросы «хватит ли кластеру ресурсов на все события масштабирования сразу», «когда докупать узлы» и «во что обойдётся следующий всплеск» автомасштабирование не отвечает вообще. Оно работает поверх планирования, не вместо.

Бюджет запаса явный, а не «у нас есть запас». На «вроде есть» решения не принимаются. Запас — это N процентов мощности, обычно от трети до половины, зарезервированные под всплески, неожиданный рост и переключение нагрузки из соседних регионов. Опустились ниже — алерт. Я регулярно вижу команды, у которых запас — это просто «то, что осталось»; такое не бюджет, а случайность.

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

Удельная стоимость как метрика эффективности. «Мы растём, поэтому траты растут» — позиция, которая прячет неэффективность. Без удельных чисел не отличить здоровый рост, где стоимость пользователя стабильна, от ситуации, где она обгоняет выручку. Стоимость запроса, активного пользователя, гигабайта — это проверка для решений по мощностям, а не только строчка в финансовой отчётности.

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

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

SLO Engineering — запас мощности держит SLO достижимым; пороги насыщения выводятся из тех же SLO. Без явных целей числа по мощностям произвольны.
SLI-based Alerting — индикаторы насыщения (задержка, доля ошибок, глубина очереди) — отдельный класс SLI. Алерт на насыщение — раннее предупреждение перед инцидентом из-за нехватки ресурсов.
Toil Tracking — ручное расширение, аварийная выдача ресурсов и запросы квот — крупный класс toil.
Infrastructure as Code — выдача мощностей описывается кодом; решение по мощностям приезжает как PR в репозиторий с инфраструктурой.
Service Ownership — каталог сервиса содержит данные о мощностях: текущий бюджет ресурсов, горизонт прогноза, владелец.
Incident Response — инциденты из-за нехватки ресурсов — отдельный класс со своей реакцией: аварийное расширение, сброс части трафика, понижение критичности второстепенного.
Cloud Cost Control — мощности смотрят с двух сторон: «хватит ли» (этот лист) и «во что обходится» (Cloud Cost Control). Прогноз у них общий.
Performance & Profiling — две стороны одного ресурса: «хватит ли» здесь и «правильно ли используем то, что есть» там. Эффективность, найденная профилировщиком, — вход для решений по мощностям.

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

Два листа-соседа не написаны. Auto-scaling Patterns (TBD) — HPA, VPA, KEDA, Cluster Autoscaler, свои метрики, их тюнинг и антипаттерны. Load Testing (TBD) — как вообще проверять допущения модели: locust, k6, gatling, vegeta.

Дальше идут темы, по которым у меня нет собственного связного ответа. Multi-region Capacity Strategy — балансировка между регионами, запас под переключение, изоляция насыщения одним регионом. Handling Overload Patterns — плавная деградация, уровни критичности, придушивание нагрузки; отправная точка есть в SRE Book, глава 21.