Как обновить Asterisk на Debian и не сорвать работу АТС

Обновить Asterisk на Debian без потери активных звонков одной командой нельзя: замена версии требует перезапуска, а он влияет на вызовы. Я готовлю проверенную копию конфигурации, собираю новую версию отдельно и заранее выбираю окно переключения. Ниже — порядок работ и проверки, которые помогают не превратить обновление в аварию.

1. Сначала инвентаризация, потом резервная копия

Перед апгрейдом я фиксирую текущую версию (asterisk -V), способ установки, список загруженных модулей и настройки службы. Сборка из исходников, пакет Debian и FreePBX — разные способы установки; смешивать их в одном регламенте опасно. Проверяю, откуда запускается демон, где лежат конфиги и модули, от какого пользователя работает служба, как устроены записи и CDR. Команда systemctl status asterisk покажет состояние службы, но имя юнита может отличаться в конкретной установке. Если сервер управляется FreePBX или сторонней панелью, сначала сверяю штатную процедуру обновления с её документацией. Иначе можно обновить один слой, а второй оставить в прежнем состоянии. Классический «у нас просто Asterisk» иногда оказывается довольно творческой сборкой. Для инвентаризации также выписываю версию Debian, архитектуру процессора, активный способ запуска и путь к каталогу модулей. При установке из исходников полезно найти прежний каталог сборки и сохранить menuselect.makeopts: без него новая сборка может включить другой набор функций, даже если конфигурационные файлы не менялись. Если происхождение установки неясно, сначала выясняю его по процессу, файлам службы и расположению модулей. Не удаляю старую сборку, пока новая не прошла испытания.

Конфигурация обычно находится в /etc/asterisk, но одной этой папки может быть мало. Записи разговоров, звуковые файлы, очереди, CDR/CEL и данные realtime могут храниться отдельно — я выясняю их фактические пути и источники до копирования. В дамп базы включаю только ту базу, которая действительно используется, и подходящей для неё штатной командой; mysqldump asterisk_db не универсальная команда, а выдуманное имя базы не создаст полезную копию. Для файловой части пример выглядит так: sudo tar -czf /backup/asterisk-config-$(date +%F).tgz /etc/asterisk. Затем проверяю список содержимого (tar -tzf ...) и отдельно читаю результат дампа. Резервную копию храню вне системного диска и проверяю восстановлением на тестовом узле. Архив, который никто ни разу не распаковал, — это надежда с расширением .tgz.

• asterisk -V
• systemctl status asterisk
• sudo tar -czf /backup/asterisk-config-$(date +%F).tgz /etc/asterisk
• tar -tzf /backup/asterisk-config-$(date +%F).tgz

2. Обновите зависимости и соберите новую версию отдельно

У Asterisk 22 — ветка LTS; точный выпуск выбираю из поддерживаемых релизов и проверяю на странице проекта перед работой. Архив asterisk-22-current.tar.gz ведёт к актуальной сборке этой ветки на момент скачивания, поэтому фиксирую фактический номер версии и контрольную сумму, а не записываю в план расплывчатое «22-current». Официальная документация проекта включает install_prereq в архив исходников: сначала обновляю индекс пакетов Debian (sudo apt update), затем запускаю скрипт contrib/scripts/install_prereq test, чтобы увидеть нужные зависимости, и только после сверки выполняю install. Набор меняется в зависимости от версии, дистрибутива и нужных функций Asterisk; длинный перечень -dev пакетов из случайной инструкции не является универсальным рецептом.

Я не переношу сборку сразу на рабочую систему. Для нового экземпляра готовлю отдельную виртуальную машину или изолированную среду с той же версией Debian, архитектурой, настройками сборки и нужными внешними модулями. Сборка должна использовать сохранённые параметры menuselect, если они есть; затем сравниваю набор включённых модулей со старой АТС. Установка исходников поверх работающего экземпляра заранее меняет исполняемые файлы и модули на диске, хотя процесс Asterisk ещё держит старый код в памяти. Это не аккуратное переключение, а состояние, в котором перезапуск может выявить несовместимость. После сборки новой версии читаю UPGRADE и CHANGES, не перезаписываю текущие конфиги образцами из make samples и отдельно проверяю сторонние модули: официальное руководство предупреждает, что их иногда нужно пересобирать или переустанавливать. Ветка LTS — не обещание, что любая сборка останется актуальной навсегда. Сверяю конкретный номер выпуска со страницей поддерживаемых версий и выбираю актуальное исправление внутри поддерживаемой ветки. Это особенно важно для систем, которые годами не получали обновлений: апгрейд с большим разрывом версий может потребовать отдельного разбора изменений конфигурации и поведения модулей. Перед работой сохраняю точные версии исходников и пакетов, чтобы повторить сборку и понимать, что именно проверялось на стенде.

• sudo apt update
• ./contrib/scripts/install_prereq test
• ./contrib/scripts/install_prereq install
• asterisk -V

3. Проверьте конфигурацию и сценарии звонков на стенде

Тестовая машина нужна не ради галочки. На ней проверяю, что конфигурация читается новой версией, требуемые модули загружены, телефоны и SIP-пиры регистрируются, внутренние и внешние маршруты работают, а очереди, голосовая почта, запись разговоров и расписания ведут себя как прежде. Точный набор зависит от функций именно этой АТС: если организация использует факс, конференции или интеграцию с CRM, они тоже входят в проверку. Данные для теста обезличиваю; производственные пароли, ключи и реальные записи разговоров не должны бесконтрольно разъезжаться по лабораторным VM. На условном стенде «Импульс-Строй» итогом такой проверки будет список сценариев со статусами, а не фраза «у меня команда запуска прошла». В тестовом плане я отмечаю ожидаемый результат каждого действия: кто звонит, куда должен попасть вызов, что услышит абонент и какая запись должна появиться. Проверяю и отрицательные сценарии, например отказ недоступного транка или возврат вызова в очередь, если это предусмотрено схемой. Параметры подключения к оператору и тестовые номера беру из согласованного плана, а не из производственного журнала с персональными данными. Так проверка остаётся воспроизводимой и не зависит от памяти администратора.

Для диагностики выбираю команду по используемому SIP-драйверу. В PJSIP применяется pjsip set logger on; sip set debug on относится к старому chan_sip и не подходит как универсальная команда для любой современной конфигурации. После проверки логирование выключаю (pjsip set logger off), чтобы лишний поток сообщений не мешал анализу. Смотрю module show и журналы запуска, затем сравниваю результат тестовых вызовов и регистрацию с исходным состоянием. Успешная компиляция означает только то, что компилятор собрал программу. Она не доказывает, что ваш сценарий набора, шлюз оператора и внешняя база пережили обновление. Вот где тестовый стенд окупает себя — до ночного окна, а не после первого звонка в поддержку.

• asterisk -rx "core show version"
• asterisk -rx "module show"
• asterisk -rx "pjsip show registrations"
• asterisk -rx "pjsip set logger on"

4. Переключите версию в согласованное окно

План переключения описывает, куда именно установится новая сборка, как вернуть предыдущую и кто проверит звонки. Я заранее подготавливаю проверенные файлы и конфигурацию, фиксирую владельца окна и согласую с ответственными, что в момент переключения часть вызовов может быть недоступна. Просто выполнить systemctl stop asterisk, перетащить бинарник и запустить службу — не план миграции. Остановка процесса завершает активные вызовы; сохранение SIP-трафика на сетевом интерфейсе не сохраняет состояние разговоров. Копировать один файл /usr/sbin/asterisk тоже недостаточно: бинарник зависит от модулей, библиотек, путей и параметров сборки. Нельзя обещать бесшовность, не проверив эти зависимости и способ установки.

У Asterisk есть режимы управляемой остановки и перезапуска. core restart gracefully прекращает приём новых вызовов и ждёт завершения текущих перед перезапуском; продолжительность ожидания зависит от длительности разговоров. core restart when convenient ждёт отсутствия активных вызовов, но не запрещает поступление новых — пауза может отодвигаться. Это способы снизить риск обрыва уже идущего разговора, а не гарантия непрерывности для новых звонков. Для реального переключения без заметного простоя нужна заранее спроектированная резервная схема: например, второй узел и маршрутизация вызовов, которые поддерживает оператор и ваша телефония. На одиночном сервере честный вариант — короткое согласованное окно и понятное уведомление. После перехода проверяю systemctl status, версию работающего процесса, регистрацию транков, тестовые входящие и исходящие, очередь и журналы. Если используется два узла, перед началом работ надо подтвердить, что провайдер действительно умеет направлять новые вызовы на резервный адрес или узел, а внутренняя маршрутизация и состояние очередей рассчитаны на такой режим. Наличие второй виртуальной машины само по себе отказоустойчивость не создаёт. Проверьте также, кто и как вернёт маршрут на исходный узел и что произойдёт с вызовами, которые уже направлены на обновляемую АТС. Без этой проверки безопаснее называть процедуру плановым перерывом и сообщать участникам окна, что новые вызовы временно могут не пройти.

• asterisk -rx "core restart gracefully"
• asterisk -rx "core restart when convenient"
• systemctl status asterisk
• asterisk -V

5. Проверьте результат и держите откат готовым

После переключения я не ограничиваюсь зелёным статусом systemd. Проверяю, что запущен нужный выпуск (asterisk -rx "core show version"), список модулей ожидаемый, а в журнале нет ошибок загрузки. Затем выполняю короткий набор контролируемых вызовов: внутренний-внутренний, входящий снаружи, исходящий наружу, вызов в очередь и завершение с записью — если эти функции используются. Сверяю регистрацию SIP-устройств и транков, звуковые файлы, CDR и работу критичных интеграций. Мониторинг Zabbix полезен, если проверяет конкретные признаки: доступность процесса, регистрацию и прохождение контрольного вызова. Одного ping до сервера недостаточно: компьютер может отвечать на сеть и при этом не обслуживать ни одного звонка.

Откат должен быть технически исполнимым и проверенным. Я сохраняю предыдущую сборку и конфигурацию отдельно, документирую обратный порядок переключения и задаю критерии, при которых останавливаю работы: например, не загружается необходимый модуль или не проходят контрольные сценарии. Откатываю только после понимания, какие изменения уже попали в базы и данные; возврат бинарников не отменяет автоматически миграцию схемы или изменение файлов. Обновление Debian — отдельная задача от обновления Asterisk. Если вместе с пакетами обновлялось ядро, план перезагрузки зависит от установленного оборудования и модулей: DAHDI нужен только при использовании соответствующих телефонных плат, а драйвер должен соответствовать запущенному ядру. Перезагрузка не является универсальным ритуалом после каждого обновления пакетов; если новое ядро нужно применить, включите перезапуск в отдельное окно и проверьте DAHDI после старта. До открытия окна записываю исходное состояние регистрации и результаты контрольных вызовов, чтобы после работ сравнить одинаковые показатели. В журнале отмечаю время начала и завершения каждого шага, а не только итог «связь есть». Если проверка не проходит, фиксирую конкретный симптом и возвращаюсь к заранее определённой точке отката. После успешного переключения оставляю старый экземпляр и копии доступными до окончания согласованного периода наблюдения, но не запускаю их одновременно в одной сети без плана: два процесса могут конфликтовать за порты, маршруты и подключение к оператору.

• asterisk -rx "core show version"
• asterisk -rx "module show"
• journalctl -u asterisk --since "30 minutes ago"

Частые вопросы