Jak zaplanować migrację PBX bez niekontrolowanej przerwy

Najpierw zbuduj macierz, nie listę ekranów#

PBX to nie tylko użytkownicy i numery wewnętrzne. Produkcyjna platforma może zawierać tenanty, gatewaye, ring groups, kolejki, IVR, harmonogramy, nagrywanie, voicemail, fax, provisioning, klasy usług, numery alarmowe, WebRTC i integracje raportowe. Dwie konfiguracje wyglądające podobnie w GUI mogą mieć inne zachowanie w dialplanie.

Macierz migracyjna powinna mieć wiersz dla każdej funkcji lub klienta i kolumny:

• stan źródłowy,
• odpowiednik w systemie docelowym,
• sposób migracji,
• właściciel testu,
• kryterium akceptacji,
• zależności,
• plan rollback.

Dzięki temu wiadomo, które elementy można przenieść automatycznie, które wymagają transformacji, a które trzeba przeprojektować.

Inwentaryzacja ruchu ujawnia funkcje, których nie ma w dokumentacji#

Oprócz konfiguracji przeanalizuj CDR i trace z reprezentatywnego okresu. Szukaj:

• połączeń krajowych, międzynarodowych i specjalnych,
• przekierowań oraz transferów,
• tras zapasowych i failover,
• połączeń do kolejek, IVR i konferencji,
• faksów T.38 i passthrough,
• urządzeń rejestrujących się z nietypowych sieci,
• klientów WebRTC i TURN,
• nagłówków operatorskich zależnych od tenanta,
• numerów używanych rzadko, ale krytycznych.

Konfiguracja może zawierać nieużywane reguły, a ruch może ujawnić funkcję utworzoną poza standardowym procesem. Oba źródła trzeba zestawić.

Rozdziel warstwy migracji#

Bezpieczny plan dzieli pracę na warstwy:

Nie przechodź do cutover, jeżeli nie wiadomo, kto odpowiada za każdą warstwę i jak ją testować.

Zbuduj środowisko równoległe#

Nowy PBX powinien działać przed przełączeniem produkcji. Potrzebuje osobnego FQDN lub kontrolowanego host mappingu, testowego trunku albo prefiksu, dostępu do mediów i zestawu testowych urządzeń.

Równoległe środowisko pozwala sprawdzić:

• rejestrację po UDP/TCP/TLS/WSS,
• połączenia wewnętrzne i zewnętrzne,
• caller ID i PAI,
• przekierowania i Diversion,
• IVR, queue, voicemail oraz nagrywanie,
• DTMF, kodeki i RTP,
• failover gatewaya,
• provisioning konkretnych modeli telefonów,
• raporty i CDR.

Testy powinny obejmować oba kierunki. To, że połączenie wychodzące działa, nie potwierdza routingu DID ani zachowania po przekierowaniu.

Dane i sekrety wymagają osobnego planu#

Nie wszystkie elementy powinny być kopiowane jeden do jednego. Hasła SIP mogą być przechowywane jako hash niemożliwy do przeniesienia między platformami. W takim przypadku potrzebna jest rotacja credentials i kontrolowane reprovisioning urządzeń.

Nagrania i voicemail mogą mieć dużą objętość oraz wymagania retencyjne. Zdecyduj:

• czy są migrowane, archiwizowane czy pozostają read-only,
• jak użytkownik uzyska dostęp do historii,
• jak potwierdzisz kompletność,
• czy format plików i metadanych jest zgodny,
• kiedy można usunąć kopię źródłową.

Sekrety gatewayów, API i SMTP powinny trafić do nowego systemu bez umieszczania ich w paczce wydaniowej lub otwartym repozytorium.

DNS i rejestracje endpointów#

Jeżeli telefony rejestrują się do FQDN, obniż TTL i sprawdź zachowanie resolvera w urządzeniu. Niektóre telefony rozwiązują DNS tylko podczas startu, inne przy każdej rejestracji, a część cache'uje wynik niezależnie od TTL.

Strategie przełączenia:

• zmiana rekordu DNS,
• aktualizacja provisioning i restart falami,
• floating IP lub load balancer,
• równoległe SRV z kontrolą priorytetu,
• failover DNS z healthcheckiem.

Każda strategia ma inny czas zbieżności. Podczas przejścia stary i nowy PBX mogą jednocześnie obsługiwać rejestracje. Trzeba uniknąć sytuacji, w której połączenie przychodzące trafia na nowy system, a telefon nadal jest zarejestrowany wyłącznie na starym.

Trunki operatorskie i kolejność zmian#

Operator może autoryzować po IP, credentials albo obie metody. Przy zmianie publicznego adresu uzgodnij allowlistę wcześniej. Jeżeli operator pozwala na dwa adresy równolegle, możesz przetestować nowy trunk bez wyłączania starego.

Zweryfikuj:

• adresy sygnalizacji i mediów operatora,
• transport i port,
• format numeracji,
• PAI, From, Diversion i nagłówki wymagane przez operatora,
• kodeki i DTMF,
• timeouty oraz session timers,
• zachowanie przy 4xx/5xx i trasie zapasowej,
• limity kanałów i CPS.

Połączenie testowe powinno być zapisane jako trace referencyjny. Będzie podstawą porównania po cutover.

Migracja falami ogranicza blast radius#

Dobierz pierwszą falę tak, aby była reprezentatywna, ale nie krytyczna. Powinna zawierać różne typy urządzeń i funkcji. Po migracji obserwuj co najmniej jeden pełny cykl biznesowy: połączenia w godzinach pracy, nocny harmonogram, raporty i backup.

Przykładowe fale:

1. tenant testowy i użytkownicy techniczni,
2. mały klient z typowymi funkcjami,
3. klient z kolejką, IVR i przekierowaniami,
4. klient z WebRTC lub MPLS,
5. największe i najbardziej krytyczne środowiska.

Każda fala powinna kończyć się aktualizacją runbooka. Jeżeli pierwszy tenant ujawnił problem provisioningowy, popraw proces przed następnymi, zamiast wykonywać ręczne obejście wielokrotnie.

Runbook cutover#

1. Zamroź zmiany w starym PBX.
2. Wykonaj finalny eksport konfiguracji i danych.
3. Zaimportuj różnice do nowego systemu.
4. Uruchom walidację spójności: liczba extensions, DID, gatewayów i reguł.
5. Potwierdź trunki i media z operatorem.
6. Przełącz DNS, IP lub provisioning.
7. Monitoruj rejestracje endpointów.
8. Wykonaj testy przychodzące, wychodzące, transfer, DTMF i audio.
9. Potwierdź CDR, nagrania, voicemail i alerty.
10. Otwórz okres obserwacji i utrzymuj gotowy rollback.

W runbooku zapisz limit czasu na osiągnięcie oczekiwanej liczby rejestracji. Jeżeli po 15 minutach aktywnych jest 40% urządzeń zamiast oczekiwanych 90%, potrzebna jest decyzja, a nie dalsze czekanie bez planu.

Rollback musi odtworzyć routing i rejestracje#

Powrót to nie tylko cofnięcie DNS. Jeżeli endpointy dostały nowy provisioning albo operator zmienił allowlistę, trzeba odtworzyć wszystkie elementy. Przygotuj:

• poprzednie rekordy DNS i TTL,
• kopię konfiguracji provisioning,
• możliwość ponownego uruchomienia starego PBX,
• aktywny stary trunk lub procedurę jego przywrócenia,
• sposób zatrzymania nowych zapisów,
• komunikat dla użytkowników i helpdesku.

Zdefiniuj punkt bez powrotu. Migracja voicemail, zmiana haseł lub nowy schemat danych mogą sprawić, że rollback wymaga dodatkowej synchronizacji.

Stabilizacja i dowody po migracji#

Po przełączeniu porównaj metryki ze stanem bazowym:

• answer-seizure ratio i przyczyny niepowodzeń,
• liczbę rejestracji,
• opóźnienie zestawienia,
• udział kodeków,
• utratę i jitter RTP,
• liczbę porzuconych kolejek,
• błędy provisioning i auth,
• wykorzystanie CPU, RAM i portów RTP.

Zbieraj przykładowe good calls dla najważniejszych scenariuszy. Staną się materiałem referencyjnym dla późniejszych incydentów.

Migracja PBX bez niekontrolowanej przerwy nie oznacza obietnicy absolutnego zera sekund niedostępności. Oznacza, że czas i zakres ryzyka są znane, przełączenie jest mierzone, a powrót możliwy zanim presja wymusi improwizację.