Capacity planning простым языком

Capacity planning часто откладывают до первого серьёзного перегруза. Дешевле считать заранее, даже грубо.

Проще говоря

Как считать запас по CPU/RAM/IO без сложных моделей и заранее видеть, где система упрётся в потолок. Ниже — что именно делать на практике и где чаще всего ошибаются.

Базовая формула

1. Определи целевой трафик на 3–6 месяцев.
2. Замерь текущую стоимость одного запроса/задачи.
3. Добавь запас на пики и деградацию зависимостей.

Реальная ситуация

Коротко про вводные.

Контекст: Сервис рос на 12% в месяц. После простого capacity-плана команда заранее расширила read pool и избежала пикового инцидента в сезонный трафик.

Что мерить регулярно

• saturation по CPU/IO,
• p95 latency на пиках,
• queue lag,
• error rate при росте нагрузки.

Короткая история из команды

В реальном проекте решение сработало только после того, как его закрепили в процессах команды, а не оставили на уровне договорённостей.

Вывод

Capacity planning не обязан быть сложным. Даже базовая модель спасает от дорогих аварий «внезапного роста».

Частая ошибка в оценке ёмкости

Команды часто считают только среднюю нагрузку. Но система падает на пиках и деградации внешних зависимостей. Поэтому в расчёт всегда надо закладывать стресс-сценарий: рост трафика + медленный зависимый сервис + повторные попытки.

Если capacity-план пересматривается раз в квартал, а не раз в год, прогноз обычно остаётся точным и даёт время на спокойные изменения инфраструктуры.

Почему это часто проваливается на практике

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

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