Capacity и Availability Management: управление мощностями и доступностью

Две практики: о чём каждая

Практики смежные, но отвечают на разные вопросы:

• Availability Management (управление доступностью) — обеспечивает, чтобы услуга была доступна тогда и настолько, насколько обещано в SLA. Ключевой вопрос: «работает ли услуга, когда она нужна?».
• Capacity Management (управление мощностями) — обеспечивает, чтобы ресурсов хватало под текущую и будущую нагрузку без избыточных трат. Ключевой вопрос: «выдержим ли мы нагрузку завтра и через год?».

Связь между ними прямая: нехватка мощности (capacity) почти всегда оборачивается падением доступности (availability) — перегруженный сервер начинает отказывать. Поэтому обе практики обычно ведут в связке.

Доступность и «девятки»

Доступность измеряют в процентах времени, когда услуга работала. На практике говорят о «девятках» — и разница между ними огромна по допустимому простою:

Доступность   Простой в год    Простой в месяц
99%   (две 9)     ~3.65 дня         ~7.2 часа
99.9% (три 9)     ~8.76 часа        ~43 минуты
99.95%            ~4.38 часа        ~22 минуты
99.99%(четыре 9)  ~52.6 минуты      ~4.3 минуты

Главный вывод: каждая дополнительная «девятка» дорожает кратно. Прыжок с 99.9% до 99.99% требует резервирования, автоматического failover, дежурств 24×7 — и осмыслен только там, где простой реально стоит этих денег. Обещать «четыре девятки» всему подряд — классическая ошибка Service Level Management: дорого и обычно не нужно.

Доступность напрямую считается из метрик надёжности: Availability = MTBF / (MTBF + MTTR) — см. разбор MTTR/MTBF.

Планирование мощностей на трендах

Capacity Management — это не «докупить серверов, когда затормозит», а проактивное планирование. Базовый подход:

1. Собрать историю. Как менялась нагрузка (запросы, объём данных, число пользователей) за последние периоды.
2. Найти тренд. Линейный рост, сезонность, скачки после релизов или маркетинговых акций.
3. Спрогнозировать. Когда при текущем тренде упрёмся в потолок ресурса.
4. Запланировать заранее. Нарастить мощность до того, как упрёмся, а не в режиме пожара.

Отдельно стоит учитывать сезонность: для многих сервисов нагрузка предсказуемо растёт в конце месяца/квартала (отчётность), в начале учебного года, в распродажи. Capacity-план должен закладывать пики, а не средние значения.

Capacity касается и операторов поддержки

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

Capacity-планирование для helpdesk означает:

• Следить за соотношением входящего потока и пропускной способности команды (по дашборду загрузки).
• Прогнозировать пики (онбординг новых сотрудников, миграции, релизы) и усиливать смены заранее.
• Снижать нагрузку через shift-left и self-service — это «масштабирование» без найма.
• Не путать разовый всплеск с трендом: первый закрывают сверхурочными, второй требует найма или автоматизации.

Так две «инфраструктурные» практики смыкаются с повседневной работой поддержки: и сервер, и команда — это ресурсы, которые надо планировать под нагрузку, иначе доступность услуги падает с обеих сторон.