Анализ потребностей и прогнозирование роста

Мы подошли к критической точке в администрировании корпоративной АТС. Ранее, в теме «Мониторинг и выявление узких мест», мы научились определять текущее состояние системы и находить ограничения по CPU, RAM и дисковому вводу-выводу. Однако опытный администратор отличается от новичка тем, что он не ждет, пока система «упрется в потолок», а планирует ресурсы заранее.

Анализ потребностей: от бизнеса к метрикам

Первый шаг — анализ потребностей. Ваша задача: перевести бизнес-планы компании на язык цифр Asterisk. В 2026 году АТС — это не только голос, но и поток данных от CRM-систем и AI-сервисов аналитики.

Разделите данные для сбора на три категории:

1. Количественные: сколько новых сотрудников придет в штат и станет активными абонентами.
2. Качественные: изменится ли профиль вызова. Например, переход на видеосвязь через WebRTC или внедрение шифрования.
3. Интеграционные: планируется ли речевая аналитика или автообзвон через AMI/ARI.

🛡️ Важно: В 2026 году TLS и SRTP — стандарт. Шифрование нагружает CPU на 20–30% сильнее, чем открытый трафик. Учитывайте это при выборе процессора.

Математика нагрузки: Эрланги и ЧНН

Чтобы расчеты были точными, используйте понятие ЧНН (Час наибольшей нагрузки). Это 60-минутный интервал в сутках, когда система загружена максимально.

Интенсивность трафика измеряется в Эрлангах (Erl). 1 Эрланг — это один канал, занятый на 100% в течение часа. Как показано на Схеме 1, анализ распределения нагрузки помогает не переплачивать за «железо», сохраняя стабильность в пики.

Формула интенсивности нагрузки ($A$): $A = \frac{n \times T}{60}$ Где:

• $n$ — количество вызовов в час;
• $T$ — средняя длительность разговора в минутах.

Если расчет дал 15 Эрланг, вам нужно минимум 15 одновременных линий. Чтобы пользователи не слышали «занято», закладывайте запас по формуле Эрланга-B (учитывает вероятность отказа).

Прогнозирование роста: метод экстраполяции

Прогнозирование роста — это создание модели будущего на основе истории мониторинга и стратегии компании.

Выделяют два типа роста:

• Линейный: штат растет плавно (например, +5 человек в месяц). Дату исчерпания ресурсов легко предсказать.
• Взрывной: запуск рекламы или открытие филиала. Нагрузка может подскочить в 10 раз за сутки.

Сопоставляйте планы бизнеса с техническими лимитами. Таблица ниже поможет сориентироваться при использовании PJSIP и записи разговоров:

Параметр	Сейчас (10 чел.)	Прогноз (50 чел.)	На что давит
Одновременные вызовы	3–5	20–25	Емкость SIP-транка
Запись разговоров	Низкая	Высокая	Дисковый ввод-вывод (IOPS)
Транскодинг (G.729/Opus)	Почти 0	Высокая	Мощность CPU (ядра)
База данных (CDR/CEL)	< 100 зап/час	> 500 зап/час	Индексы MariaDB

Планирование масштабирования: стратегия действий

Когда прогноз показывает, что через 3 месяца нагрузка достигнет 80% лимита, пора начинать планирование масштабирования. Выбирайте одну из двух стратегий:

1. Вертикальная: наращиваем мощность текущего сервера (CPU, RAM). Это быстро, но вы быстро упретесь в физический предел «железа».
2. Горизонтальная: распределяем нагрузку между несколькими серверами Asterisk.

Примеры подходов

• Плохо: Видеть рост нагрузки и просто увеличить диск, когда 100 одновременных записей «вешают» систему из-за медленного HDD. Итог — заикания в трубке.
• Хорошо: Увидеть в Grafana, что рост регистраций PJSIP съедает память. Заранее вынести базу данных на отдельный сервер и перейти на SSD-массивы для CDR, чтобы разгрузить основной процесс Asterisk.

💡 Совет: Умножайте расчеты на «коэффициент неопределенности» 1.5. В VoIP лучше иметь лишние ресурсы, чем бороться с джиттером в разгар рабочего дня.

Мы научились превращать цифры мониторинга в план развития. Но что делать, если один сервер FreePBX больше не справляется?

В следующей теме разберем, как выбрать архитектуру для крупных проектов и когда пора переходить от схемы «все в одном» к распределенным кластерам.