9.7 Планирование мощностей и прогнозирование спроса

Обзор и мотивация

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

Эта глава стоит между двумя соседями и дополняет обоих. Глава 3.5 охватывает масштабируемость как архитектурное свойство: как система построена, чтобы вообще могла расти, через отсутствие состояния, шардирование и горизонтальное масштабирование. Глава 9.1 охватывает инженерию надёжности сайтов (SRE), задающую цели надёжности, которые мощность должна защищать. Здесь вы принимаете архитектуру как данность, а цели как фиксированные, затем отвечаете на количественный вопрос: сколько всего вам нужно купить, зарезервировать и держать в запасе, чтобы система выполняла свои цели уровня обслуживания (SLO, цели надёжности из главы 9.1) через прогнозируемый спрос и всплески, которые вы не прогнозировали. Автомасштабирование и инженерия производительности (глава 2.16) инструменты, которые вы здесь используете, но они не замена планированию, и принимать их за планирование частая и дорогая ошибка.

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

Ключевые принципы

Планируйте мощность на прогнозируемый спрос плюс намеренный запас; не работайте вблизи насыщения.
Разделяйте планирование мощностей, автомасштабирование и инженерию производительности; каждое решает свою задачу.
Прогнозируйте по тренду, сезонности, известным событиям и бизнес-росту, а не только по прошлой неделе.
Находите реальные пределы нагрузочным тестированием и эталонными испытаниями, а не догадками и не ожиданием, пока производство их найдёт.
Воспринимайте задержку вблизи насыщения как обрыв, а не склон; цели использования существуют из-за теории очередей.
Знайте свои жёсткие узкие места: пулы соединений, квоты и единые точки не масштабируются автоматически.
Балансируйте цену и надёжность намеренно и пересматривайте мощность регулярно, а не после инцидента.

Рекомендации

Разделяйте планирование мощностей, автомасштабирование и инженерию производительности

Эти три дисциплины нередко путают, и путаница ведёт к покупке неверного средства. Планирование мощностей это средне- и долгосрочный вопрос о том, сколько всего ресурсов нужно подготовить, зарезервировать и заложить в бюджет на недели, кварталы и годы. Автомасштабирование это краткосрочная автоматическая подстройка ресурсов под нагрузку минута за минутой: оно перемещает вас в пределах оболочки, подготовленной планированием, но не может сотворить квоту, которую вы не резервировали, прогреть холодную базу данных или промасштабировать компонент, работающий в единственном экземпляре. Инженерия производительности (глава 2.16) меняет форму задачи, делая каждую единицу работы дешевле, так что то же оборудование обслуживает больше спроса.

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

Прогнозируйте спрос по тренду, сезонности, событиям и бизнес-росту

Прогноз, построенный на среднем прошлой недели, пропустит каждый интересный момент. Стройте свой из четырёх различных составляющих. Тренд это базовое направление: спрос растёт, стоит или падает и как быстро? Сезонность это повторяющийся шаблон: суточный пик в 9 утра, недельный спад на выходных, годовой всплеск перед праздниками. Событийные всплески это разовые концентрации: запуск продукта, маркетинговая кампания, упоминание по телевидению, срок государственной подачи. Бизнес-рост это спрос, создаваемый вашей собственной дорожной картой: новый рынок, подключение крупного клиента, функция, утраивающая запросы на сеанс.

Используйте правильный приём для каждой. Временной ряд исторической нагрузки, разложенный на тренд и сезонность, даёт защитимую базовую линию для стабильного спроса. События нельзя экстраполировать из истории, потому что у них нет истории; они приходят из разговора с бизнесом, чтения дорожной карты и вопроса маркетингу и продукту, что они собираются запустить. Самые разрушительные сбои мощности почти всегда события, о которых инженерия никогда не слышала. Лекарство организационное, а не статистическое: постоянный канал, где продукт, маркетинг и эксплуатация объявляют предстоящие всплески достаточно заранее, чтобы подготовиться.

Задавайте цели использования и уважайте обрыв теории очередей

Инстинкт держать инфраструктуру «горячей» на 90 процентах использования ради экономии ловушка, и причина теория очередей, подробно рассмотренная в главе 11.3. По мере приближения ресурса к полному использованию время ожидания растёт не плавно и линейно, а взрывается. Сервер на 50 процентах использования имеет комфортный запас; тот же сервер на 90 может видеть задержку в несколько раз хуже, а на 95 очередь может убежать совсем. Задержка вблизи насыщения обрыв, а не склон, и ваши пользователи чувствуют обрыв как тайм-ауты, повторы и ошибки задолго до того, как ресурс технически «полон».

Поэтому планировщики мощностей задают цели использования заметно ниже 100 процентов, обычно в диапазоне от 50 до 70 процентов для чувствительных к задержке сервисов, выше для пакетной работы, ориентированной на пропускную способность и терпящей очереди. Цель не потеря, а цена предсказуемой задержки. Выбирайте цель по SLO: если ваша цель по задержке строга, ваш потолок использования ниже, потому что хвостовая задержка, которую порождают очереди, именно то, что взрывает SLO. Запас и запас прочности та же идея с двух сторон. Запас это разрыв между нормальной нагрузкой и мощностью; запас прочности этот разрыв, выраженный как страховка от прогноза, оказавшегося завышенным, переключения на резерв, концентрирующего нагрузку, или всплеска, которого вы не ждали.

Находите реальные пределы нагрузочным тестированием и эталонными испытаниями

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

Проводите несколько различных тестов. Нагрузочный тест разгоняется до ожидаемого пика и подтверждает, что SLO держится с запасом. Стресс-тест проталкивает за точку излома, чтобы увидеть, как система отказывает, потому что система, деградирующая изящно, сильно отличается от рушащейся. Тест на выдержку держит умеренную нагрузку часы или дни, чтобы выявить утечки памяти, исчерпание соединений и проблемы заполнения диска, проявляющиеся только со временем. Тест всплеска внезапно обрушивает нагрузку, чтобы проверить, поглощают ли её автомасштабирование и буферы до того, как пользователи заметят. Тестируйте на близких к производственным данных и топологии, потому что предел, измеренный на игрушечном наборе данных, лжёт. Перезапускайте эти тесты при изменении системы, чтобы ваши числа описывали систему, которая у вас есть, а не ту, что была год назад.

Выбирайте стратегии подготовки намеренно

Облачные провайдеры позволяют покупать ту же мощность способами, меняющими цену на гибкость, и хорошее смешивание их то место, где экономятся реальные деньги. Мощность по требованию гибка и дорога: вы платите полную ставку за возможность запускать и останавливать когда угодно, что подходит непредсказуемой и недолгой нагрузке. Зарезервированная мощность (обязательства на один или три года или планы экономии) дешевле за единицу в обмен на обещание продолжать её использовать, что подходит вашей стабильной базовой нагрузке. Спотовые экземпляры продают свободную мощность с глубокой скидкой, но могут быть возвращены с малым предупреждением, что подходит отказоустойчивой, прерываемой работе вроде пакетной обработки и исполнителей без состояния.

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

Картируйте жёсткие узкие места, которые не масштабируются автоматически

Автомасштабирование порождает опасную уверенность, потому что множество пределов стоит ниже по течению от того, что масштабируется, и не сдвигается вместе с ним. Пулы соединений базы данных классический пример: промасштабируйте слой без состояния с 10 до 100 экземпляров, и каждый откроет соединения с той же базой данных, у которой жёсткий предел числа параллельных соединений, и она начнёт отказывать в новых. Облачные учётные записи несут квоты почти на всё: экземпляры на регион, IP-адреса, вызовы API в секунду, параллелизм функций. Любая единая точка архитектуры, основная база данных, ведущий узел, общий кэш, лицензируемое устройство, потолок, который горизонтальное масштабирование в других местах поднять не может.

Сделайте их явными. Ведите письменную опись каждого жёсткого предела между запросом и ответом: размеры пулов, значения квот, компоненты в единственном экземпляре, лимиты скорости третьих сторон, число лицензионных мест. Для каждого записывайте текущее значение, текущее использование и нагрузку, при которой он связывает. Эта опись разница между планом мощности, описывающим всю систему, и тем, что описывает только лёгкие эластичные части, пока пул соединений тихо ждёт конца вашего запуска. Поднимайте квоты заранее, потому что увеличение квоты провайдером может утверждаться днями.

Подготавливайтесь к пиковым событиям, а не только к среднему

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

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

Инструментируйте мощность и рецензируйте её по ритму

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

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Высокая цель использования	Ниже цена за единицу; меньше простаивающей мощности	Задержка взрывается вблизи насыщения; нет места для всплесков или переключения на резерв
Щедрый запас	Предсказуемая задержка; поглощает всплески и переключение	Выше стабильная цена; может скрывать неэффективность
Зарезервированная мощность	Наименьшая цена единицы для стабильной базы	Риск обязательства, если спрос падает или сдвигается
Мощность по требованию	Гибко; соответствует переменной нагрузке минута за минутой	Наивысшая цена единицы; может удивить бюджет
Спотовые экземпляры	Глубокая скидка для прерываемой работы	Возвращаются без предупреждения; непригодны для работы с состоянием или критичной к задержке
Автомасштабирование	Отслеживает нагрузку автоматически в пределах оболочки	Не может превысить зарезервированную квоту; холодные старты; маскирует нижестоящие пределы
Буферный пул (тёплая мощность)	Мгновенно поглощает внезапные всплески	Платит за простаивающую мощность между всплесками

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

Вопросы для обсуждения с командой

Знаем ли мы на самом деле нагрузку, при которой связывает каждое из наших жёстких узких мест, или предполагаем, что нас спасёт автомасштабирование? Большинство команд могут сказать, что их экземпляры автомасштабируются, и большинство не может назвать предел параллельных соединений на основной базе данных, лимит скорости API их важнейшей третьей стороны или квоту учётной записи, ограничивающую параллелизм функций. Это пределы, что заканчивают запуски, и они не двигаются, когда масштабируется слой без состояния. Принесите письменную опись жёстких пределов, если она есть, а если нет, это отсутствие и есть находка. Для каждого предела нужны три числа: потолок, сегодняшнее использование и уровень спроса, при котором они встречаются. Везде, где вы не можете назвать все три, у вас узкое место, которым вы управляете надеждой.
Когда мы в последний раз нагрузочно тестировали до уровня нашего худшего предстоящего пика, на близких к производственным данных, и держался ли SLO с запасом? План мощности набор утверждений о том, как система ведёт себя под нагрузкой, а непроверенное утверждение это догадка в костюме. Важный пик не среднее прошлого месяца, а следующий запуск, праздник или срок, и тест что-то значит, только если данные и топология напоминают производство, потому что предел, измеренный на игрушечном наборе данных, лжёт. Принесите результаты ваших последних стресс-тестов и тестов на выдержку, включая то, где система сломалась и как отказала. Если честный ответ в том, что вы никогда намеренно не гнали систему до точки излома, вы обнаружите эту точку в производстве, в худший момент, при наблюдающих пользователях.
Как продукт, маркетинг и эксплуатация сообщают инженерии о всплеске до его наступления и насколько заранее? Самые дорогие сбои мощности не ошибки моделирования; это события, о которых инженерия не слышала, пока не пришёл трафик. Прогноз может экстраполировать тренд и сезонность из истории, но у события нет истории, поэтому оно может прийти только от людей, которые его планируют. Принесите три последних всплеска спроса и спросите для каждого, за сколько дней инженерия получила предупреждение и хватило ли этого для резервирования мощности и нагрузочного тестирования. Свидетельство, которое вам нужно, постоянный канал с временем упреждения, достаточно долгим для подготовки, потому что одни только увеличения облачных квот могут занимать дни. Если канала нет, ваш план мощности слеп к тем самым моментам, которые призван защищать.
На какой цели использования на самом деле работает каждый чувствительный к задержке сервис и можем ли мы проследить это число до его SLO, а не до цели по цене? Это важно, потому что давление держать инфраструктуру горячей постоянно и идёт от той части организации, что видит счёт, но не обрыв очередей, поэтому, если цель не записана и не обоснована целью по задержке, она дрейфует вверх, пока всплеск не найдёт край. Конкурирующие соображения реальные деньги с одной стороны и хвостовая задержка с другой, и честная позиция в том, что запас ниже 100 процентов цена предсказуемой задержки, а не потери, которые нужно срезать. Принесите нынешнее использование ваших главных сервисов, SLO, который защищает каждый, и задержку, которую вы измерили при этом использовании под нагрузкой, чтобы обсуждение шло от свидетельств, а не инстинкта. На корпоративной или государственной платформе, где один общий пул обслуживает многие сервисы, согласуйте цель централизованно и запишите, кому позволено её менять, потому что одна команда, тихо поднявшая свой потолок, может столкнуть ресурс, от которого зависят другие, с обрыва для всех.
Какова наша смесь зарезервированной мощности, мощности по требованию и спотовой, когда мы последний раз её пересматривали и по-прежнему ли она соответствует форме нашего спроса? Смесь то место, где прячутся и самая большая устойчивая экономия, и самые большие устойчивые потери, потому что стабильная база, оплачиваемая по ставкам по требованию, сжигает деньги каждый час, тогда как переобязанная зарезервированная позиция платит за мощность, которую спрос с тех пор перерос или упал ниже. Напряжение между ценой и гибкостью и риском обязательства: зарезервированная мощность дешевле всего за единицу, но запирает, спот ещё дешевле, но может быть возвращён без предупреждения, а мощность по требованию покупает свободу с наценкой. Принесите нынешнее деление по цене, кривую спроса, которую оно призвано покрывать, и долю возврата и радиус поражения любых спотовых нагрузок, чтобы комната увидела, действительно ли прерываемая работа прерываема. В корпоративной и государственной среде привяжите зарезервированные обязательства к циклу закупок и бюджета, потому что многолетние обязательства и планы экономии финансовые обязательства, которые финансы и аудит захотят видеть оправданными против прогнозируемого спроса, а не против удобства прошлого квартала.
Когда близится именованное пиковое событие, кто владеет прогревом, повышением квот, заморозкой развёртываний и решением «идти или нет» и записано ли это как ранбук, который мы отрепетировали? Пиковые события те моменты, которые планирование мощностей призвано защищать, и они чаще всего проваливаются не потому, что план был неверен, а потому что никто не отвечал за его исполнение под давлением в тот день. Конкурирующие соображения скорость и автономия против координации: команды хотят продолжать отгружать, однако рискованное развёртывание в окно всплеска может свести на нет месяцы подготовки, поэтому кто-то должен иметь полномочия заморозить и остановить запуск. Принесите ранбук для вашего следующего крупного события, сроки увеличения квот и прогрева буферных пулов и запись того, кто занимал каждую роль в прошлый раз и держались ли передачи. Для государственного срока, самоназначенного, публично известного и неподвижного, назовите подотчётного владельца и путь эскалации явно, потому что нет варианта сбросить нагрузку или попросить граждан вернуться позже, а пик, которым никто не владеет, пик, который никто не будет защищать, когда он придёт.

Взгляд по секторам

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

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

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

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

Примеры

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

Крупная организация. Глобальный ритейлер воспринимает свой самый большой день распродаж как событие мощности года. За месяцы вперёд межфункциональная команда строит прогноз спроса по тренду и сезонности прошлых лет плюс план мерчандайзинга, переводит прогноз в потребности ресурсов через модель мощности и подготавливает до проецируемого пика с щедрым запасом. Они нагрузочно, стресс-, на выдержку и всплеск тестируют весь путь на близких к производственным данных, поднимают каждую релевантную облачную квоту за недели вперёд, прогревают кэши и буферные пулы и замораживают рискованные развёртывания на окружающее окно. Зарезервированная мощность покрывает стабильную базу ради цены, автомасштабирование по требованию поглощает суточную кривую, а прерываемая пакетная работа идёт на споте. Наблюдаемость отслеживает каждый ограниченный ресурс относительно его предела в реальном времени во время события, с оповещениями о проецируемом насыщении, а не текущем значении. День проходит без драмы, а это именно тот исход, что купило планирование.

Государственный сектор. Национальное налоговое ведомство ведёт портал подачи, чей спрос юридически сконцентрирован в дни перед неподвижным сроком, когда вся страна подаёт разом. Ведомство планирует именно этот пик, а не годовое среднее, которое было бы бессмысленным. Оно оценивает число параллельных подающих по прошлым годам и данным о населении, подготавливает до этого пика с широким запасом прочности, потому что нет варианта сбросить нагрузку или попросить граждан вернуться позже, и нагрузочно тестирует до проецируемого параллелизма на реалистичных данных. Команда ведёт письменную опись каждой квоты и единой точки отказа, поднимает лимиты у провайдеров задолго до окна и задаёт цели использования достаточно низкими, чтобы обрыв очередей оставался далеко от всплеска срока. После каждого сезона подач они записывают истинный пик и сколько запаса осталось, питая модель следующего года. Общество видит портал, остающийся доступным в тот день, для которого он проектировался, а в этом весь смысл обещания учреждения.

Бизнес-обоснование: мотивы, ROI и TCO

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

Цена принятия в основном дисциплина, а не инструменты. Вы строите прогноз спроса, записываете жёсткие пределы, проводите нагрузочные тесты по ритму, смешиваете стратегии подготовки и проводите регулярные рецензии мощности. Совокупная стоимость владения (TCO) улучшается с обеих сторон разом: меньше инцидентов, вызванных мощностью, снижают цену простоя и аварийного реагирования, а непрерывный подбор размера плюс разумная смесь зарезервированной и спотовой мощности снижают стабильный счёт за инфраструктуру. Чтобы обосновать перед руководством, свяжите мощность с числами, за которыми оно уже следит. Привяжите недоподготовку к выручке, потерянной за час пикового простоя, и к нарушениям SLO с договорными штрафами, а переподготовку к отчёту о потерях FinOps из главы 9.4. Довод не абстрактная осмотрительность; это деньги по обе стороны циферблата, который вы можете настроить намеренно.

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1, Начальный: Мощность реактивна и стихийна. Команды добавляют ресурсы после того, как они кончились, доверяют автомасштабированию всё, и у них нет ни прогноза, ни описи жёстких пределов, ни нагрузочного тестирования. Пиковые события встречаются с надеждой, а сбои во время запусков и сроков воспринимаются как невезение.
Уровень 2, Развитие: Появляются базовые практики, различающиеся по командам. Некоторый мониторинг показывает использование, перед крупными событиями проводится некоторое нагрузочное тестирование, основные квоты известны, а грубый прогноз существует кое-где, но модель не сопровождается, нижестоящие узкие места часто пропускаются, а запас задаётся эмпирическим правилом, а не из SLO.
Уровень 3, Стандартизация: Планирование мощностей документированная дисциплина, принуждаемая по организации. Прогноз спроса сочетает тренд, сезонность, события и бизнес-рост; ведётся письменная опись жёстких пределов; цели использования выводятся из SLO; нагрузочные, стресс-тесты, тесты на выдержку и всплеска идут по ритму против близких к производственным данных; а подготовка намеренно смешивает зарезервированную, по требованию и спотовую мощность. Постоянный канал несёт предупреждения о событиях от продукта и маркетинга инженерии.
Уровень 4, Управление: Мощность измеряется и контролируется относительно базовых значений. Прогноз сравнивается с фактическим спросом каждый цикл, а ошибка отслеживается и снижается; использование, сигналы насыщения и запас относительно каждого жёсткого предела отслеживаются по тренду и оповещаются как проекции, а не текущие значения; пиковые события рецензируются потом относительно истинного наблюдаемого пика; а смесь подготовки, покрытие зарезервированными обязательствами и цена на SLO сообщаются как метрики, ограничивающие решения «пускать или нет». Данные, а не интуиция, решают, что резервировать, поднимать или выводить.
Уровень 5, Оркестрация: Планирование мощностей непрерывно улучшается и интегрировано по организации. Прогнозы проверяются и уточняются автоматически, насыщение проецируется и подготавливается заранее до прихода, смеси подготовки оптимизируются против живых цен, пиковые события идут по отрепетированным ранбукам, а цена и надёжность намеренно балансируются относительно SLO по всей платформе. Модель мощности общий адаптивный актив, перебалансирующий парк по мере сдвигов формы спроса и цен провайдера.

Идеи для обсуждения

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

Главные выводы

Планирование мощностей согласует предложение с прогнозируемым спросом с намеренным запасом; оно отлично от автомасштабирования (краткосрочного, в пределах оболочки) и инженерии производительности (более дешёвые единицы работы).
Прогнозируйте по тренду, сезонности, известным событиям и бизнес-росту и получайте предупреждения о событиях от продукта и маркетинга, потому что у событий нет истории для экстраполяции.
Уважайте обрыв теории очередей (глава 11.3): задержка взрывается вблизи насыщения, поэтому задавайте цели использования из вашего SLO и держите настоящий запас.
Находите пределы нагрузочным, стресс-тестированием, тестами на выдержку и всплеска на близких к производственным данных и ведите письменную опись жёстких узких мест, которые не масштабируются автоматически.
Смешивайте зарезервированную, по требованию и спотовую мощность с тёплыми буферными пулами, планируйте именованные пиковые события по отдельности и рецензируйте мощность по ритму, а не после сбоев.

Источники и дополнительное чтение

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management