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

Начните с ответственной схемы работы с ИИ: ограниченный ввод, явная неопределённость, детерминированная арифметика и решение человека.

Ключевые выводы

Мощность имеет смысл только для конкретной услуги, очереди, единицы и периода.

Измерения отделяются от роста, сезонности, пиков и времени обслуживания.

Держите формулы и промежуточные результаты вне непрозрачных рассуждений модели.

Резервирование, лимиты зависимостей и срок поставки входят в сценарий.

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

Триггер пересмотра должен срабатывать до ухудшения услуги.

Что такое планирование операционной мощности?

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

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

Ведите устойчивую запись для каждой услуги или очереди:

Поле	Содержание
Service/queue	Точная операционная граница
Unit of demand	Запрос, заказ, обращение, задача или сессия
Baseline window	Период, зерно и часовой пояс
Peak factor	Проверенная связь пика с базой
Growth/seasonality	Источник, владелец, период и уверенность
Service time	Работа на единицу или распределение
Current capacity	Доступная производительность при заданных условиях
Utilization/headroom	Утверждённое ограничение и обоснование
Redundancy	Домены отказа и остаток после отказа
Provisioning lead time	Время от решения до полезного ресурса
Dependency limit	Лимит поставщика, системы, помещения или квоты
Scenario/formula	Входы, единицы, выражение и результат
Validation test	Проверка прошлых данных, нагрузочный тест, пробный запуск или операционное сравнение
Owner/trigger	Ответственный за решение и порог пересмотра

Как проходит проверка допущений мощности, на которых строится план мощности?

Шаг 1. Определите единицу и цель услуги

Выберите измеримую единицу, связанную с результатом пользователя. «Трафик» слишком расплывчат; «завершённые API-запросы за пять минут» или «решённые обращения на час смены» можно проверить. Укажите, считаются ли повторы, отмены, передачи, переделки и спрос, от которого отказались.

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

Шаг 2. Зафиксируйте историческое окно

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

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

Шаг 3. Разделите драйверы спроса

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

Совпадение по времени не доказывает причину. Рост вместе с кампанией требует сравнения подходящих периодов или групп. Определение KPI помогает сохранить знаменатель и владельца. Используйте операционные измерения, не показатели, выбранные ради стабильного вида отчёта.

Шаг 4. Постройте три сценария

Создайте как минимум три сценария:

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

В каждом сценарии перечисляйте изменённые входы, а не ограничивайтесь ярлыками вроде «оптимистичный» или «тяжёлый». Пиковый коэффициент должен опираться на наблюдаемые данные или ответственное плановое допущение. Для стрессового случая Назовите недоступный домен, уменьшенную поставку, увеличенное время обработки или иную границу. Пример Google Non-Abstract Large System Design показывает движение от конкретного спроса к ресурсам и проверке пределов.［2］ Его числа нельзя переносить в другой сервис.

Шаг 5. Рассчитайте план мощности детерминированно

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

Не просите «обычный запас 20%». Уместный запас зависит от изменчивости, времени масштабирования, поведения при отказах, целей обслуживания и цены решения; универсальный процент скрывает неопределённость, а не управляет ею. Запрещено скрывать окончательное количество ресурсов во внутреннем рассуждении модели.

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

Шаг 6. Добавьте отказ, зависимости и сроки

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

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

AWS Well-Architected рекомендует наблюдать спрос и предложение, применять эластичность там, где она подходит, и учитывать время получения ресурсов.［3］ Найм, помещение, оборудование, договор и согласование не мгновенны; триггер должен опережать дефицит.

Шаг 7. Проверьте каждое существенное допущение

Для каждого существенного допущения выберите самую сильную из осуществимых проверок:

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

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

Шаг 8. Проверьте уверенность и пути отказа

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

NIST AI RMF использует функции Govern, Map, Measure и Manage.［4］ Здесь они означают описание роли модели, проверку преобразований, оценку последствий ошибки и сохранение человеческого решения.

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

Шаг 9. Утвердите триггеры и сопровождение

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

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

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

Сценарии пикового спроса: проверка

Итоги

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

Часто задаваемые вопросы (FAQ)

Может ли ИИ рассчитать итоговый ресурс?

Он может оформить формулу и проверенные входы, но арифметика выполняется детерминированно и независимо проверяется. Решение утверждает владелец.

Какую целевую загрузку выбрать?

Универсального значения нет. Оно зависит от изменчивости, скорости масштабирования, отказоустойчивости, SLO, очереди и стоимости избыточной и недостаточной мощности.

Какой запас мощности нужен?

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

Как учитывать сезонность?

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

Заменяет ли автоматическое масштабирование планирование?

Нет. Масштабирование ограничено квотами, запуском, нижележащими системами, стоимостью, доменами отказа и сигналами; план мощности определяет ограничения и проверяет правила масштабирования.

Когда пересматривать план?

По графику и при существенном изменении спроса, SLO, архитектуры, поставщика, персонала или срока получения ресурса.

Что делать с периодом инцидента?

Сохранить и пометить его, решить, может ли он повториться, и включить в подходящий сценарий. Удаление такого периода занижает риск.

Чем план мощности отличается от проектного плана?

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

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

Источники

Google, Site Reliability Engineering: Introduction — https://sre.google/sre-book/introduction/
Google, The Site Reliability Workbook: Non-Abstract Large System Design — https://sre.google/workbook/non-abstract-design/
AWS, Well-Architected Framework — https://docs.aws.amazon.com/pdfs/wellarchitected/latest/framework/wellarchitected-framework.pdf
NIST, AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework

Sources checked 6 сентября 2026 г.

Как составить план мощности с ИИ и проверить допущения