Historia Telekomunikacji – część 13a

Ponieważ część 13 miała być o wtopach i potknięciach, a nie zmieściło się w jednym wpisie, stąd ten nietypowy numerek. Bo jak ma być o pechu, to będzie. Konkretnie, będzie o anonsowanej już wczoraj największej i najgrubszej wtopie, z którą miałem do czynienia osobiście 🙂

Nie jestem pewien, czy dobrze lokalizuję zdarzenie w czasie, ale to chyba było zaraz na początku XXI wieku, w który to wiek warszawski Ursynów wszedł sobie w znacznej części obsługiwany jeszcze przez starą elektromechaniczną  centralę Pentaconta stojącą przy al. KEN. Duża centrala, dużo linii, ciężkie dziesiątki tysięcy abonentów (nie pamiętam dokładniejszych danych, ale wyżej 100tys. ), w tym dużo abonentów specjalnej troski typu pogotowie ratunkowe, czy szpital onkologiczny. TPSA robiła już wtedy cyfryzację Ursynowa, który miał być w całości przejęty przez nowoczesną centralę S12 Alcatela. Centrala już była, zbudowana na Natolinie, obsługiwała „swoich” abonentów na nowobudowanej stronie Ursynowa, docelowo jednak miała przejąć i tych wszystkich starych. Problemem był jednak drobiazg: „starzy” abonenci kończyli się w budynku Pentaconty, nowa centrala zaś stała w lokalizacji, która co prawda mieściła się niemalże przy tej samej ulicy, ale niestety na jej drugim końcu. A ulica – jedna z dłuższych w Warszawie. Jak połączyć jedno z drugim?

I tu weszli handlowcy. Nasi i „wasi”, znaczy tepsiani. Niewątpliwi znawcy sprzętu i systemów telekomunikacyjnych, świetnie rozumiejący temat i wiedzący, co do czego. Wykorzystanie do realizacji tego połączenia systemu Fastlink było dyskusyjne (o wiele prościej byłoby to zrobić po prostu stawiając tam wyniesiony fragment centrali), ale mogło mieć biznesowy sens, wynios centralowy byłby może prostszy technicznie, ale mógł mieć wyższy koszt od naszego Fastlinka. To jednak, w jaki sposób tego Fastlinka tam postawiono, wzbudzało przez długi czas dobry humor u wielu osób.
We wszystkich materiałach handlowych struktura Fastlinka była rysowana z naciskiem na możliwość jego rozprzestrzenienia w terenie, z obiektami łączonymi teletransmisją SDH, tu był cały smaczek, że światłowody, że ciężkie megabity można przesyłać, że och i ach.

h100_10_7618-pdf_-_adobe_reader_2016-10-20_10-21-58(źródło: materiały szkoleniowe Siemens)

Powyższy rysunek, na którym każda szafa ONU stoi sobie na swojej ulicy, w swoim biurowcu, czy też inaczej odizolowanym obszarze geograficznym ma sens jak najbardziej. Te szafy trzeba jakoś ze sobą połączyć, do tego SDH jest idealne. Tu jednak, na Ursynowie było niemal 200tys (orientacyjnie, jak pisałem, nie znam dokładnej liczby) abonentów zebranych w jednym miejscu. „Zrobić” ich przy pomocy fastlinka? A czemu nie, to raptem dwadzieścia wewnątrzbudynkowych ONU, po cztery półki abonenckie w każdym. Po co jednak, jeśli te ONU stały obok siebie, w jednej sali, robić tam ringi SDH? W dodatku w dużo droższym wydaniu STM-4, wymagającym specjalnych, bardzo drogich komponentów? Bo tak, własnie tak to zostało zrobione. Każda z tych stojących w dwóch rzędach obok siebie w jednej, wielkiej sali szaf ONU miała swoją osobną półkę SDH, a wszystkie one były połączone w mieszczący się w jednej sali ring STM 4, do którego nawet osobny system nadzoru był postawiony, bo fastlinkowy już tak zaawansowanych urządzeń nie obsługiwał. Sens tego rozwiązania był mniej więcej taki, jakby Miejski Zakład Komunikacji nagle w trasy zamiast autobusów i tramwajów wypuścił armię taksówek wyposażonych w kasowniki do biletów. Oczywiście, cena biletów bez zmian.
Tyle wiem, że handlowiec od nas, który doprowadził do podpisania tego kontraktu jakąś nagrodę dostał. Nie wiem, co dostał odpowiedzialny za zakup tego idiotyzmu przedstawiciel TP. Pewnie też nagrodę, jak znam życie…

Mniejsza jednak o to, jak to było zaplanowane. Postawione, uruchomione, przetestowane, czekało sobie na Wielki Dzień „P”. Czy też raczej Noc „P”. P jak Przełączenie. Cała numeracja, wszyscy abonenci działający na Pentaconcie, byli już równolegle wykreowani na S12, tejże nocy, o północy zaś miało nastąpić ich ostateczne przełączenie ze starego na nowe. Przełączenie polegało zarówno na „odblokowaniu” abonentów na nowej centrali i zestawieniu nowych marszrut (tak, by połączenia przychodzące z zewnątrz trafiały już na nową centralę), jak i na fizycznym odcięciu połączeń do starej centrali, a „włączeniu” tych nowych, prowadzących do Fastlinka. Byłem tam, jako przedstawiciel Siemensa, miałem nadzorować operację od strony naszego systemu i czuwać nad jej poprawnym przebiegiem.
Nie było to pierwsze moje przełączenie i choć żadne z wcześniejszych nie było związane z nawet 1/5 takiej liczby abonentów, nie spodziewałem się większych problemów. Bo i co mogło pójść nie tak, wszystko przecież 10x przetestowane, interfejsy podniesione, połączenia wykonane, realnie spodziewałem się scenariusza, w którym o północy  rozpoczną przełączenie, a o drugiej-trzeciej będę się zbierał do domu. Ech, naiwności…

Przełączenie rozpoczęło się, jak to zwykle z takimi pracami, równo o północy. Fizyczny proces zajmował trochę czasu, więc z początku było miło i przyjemnie, gadałem sobie z obecnymi na miejscu pracownikami TPSA, układałem windowsowego pasjansa, piłem herbatę, ogólnie było miło 🙂
Przestało być miło, gdy jakąś godzinę od rozpoczęcia operacji operator centrali stwierdził, że ma jakieś alarmy na interfejsie. Jednym, drugim, potem w zasadzie już na wszystkich (to był ogromny projekt, więc OLTów tam też było kilka, a do każdego o ile mnie pamięć nie myli, cztery interfejsy V5.2 szły). Ja ze swojej strony wszystko widzę pięknie podniesione, świeci się na zielono, żadnych alarmów nie ma. Na początku zresztą przy tym się upierałem, o co tobie chodzi, człowieku, wszystko stoi podniesione, bez alarmów, powinno działać. Czemu więc nie działało? Wszyscy abonenci, jak ich sprawdzałem w stanie „blocked”, centralowiec pytany o szczegóły tych jego alarmów mówi, że u niego wiele nie widać, o ile u mnie z alarmów związanych z interfejsem można byłoby szczegółowo się rozeznać co jest nie tak, u niego był tylko „remote alarm”, czyli alarm jakoby od naszej strony. Tyle, że u nas czysto.
Ale nic, bez nerwów, takie sytuacje to chleb powszedni pracownika serwisu, tu co prawda ciśnienie trochę większe, ale co tam, będzie dobrze. Podstawowa metoda postępowania w takich sytuacjach? Jak w windowsach: wyjść i wejść jeszcze raz. Ale u mnie czysto, na centrali coś jest nie tak, zatem mówię centralowcowi, żeby położył interfejs (któryś, na próbę) i go podniósł ponownie. Położył, podniósł, to samo. Dla odmiany więc ja położyłem u siebie. O, i mamy odmianę – interfejs nie chce się podnieść w ogóle. Jeszcze raz kładę i podnoszę, to samo. Resetuję karty – to samo. Proszę centralowca, by zresetował od swojej strony jeszcze raz, w efekcie uzyskaliśmy stan wyjściowy: u mnie podniesiony i bez alarmów, u niego z alarmami, abonenci leżą.

W tym momencie już mi się zaczęło robić ciepło, bo znalazłem się w klasycznej czarnej dupie: jest źle, a ja nie wiem, dlaczego i co ważniejsze, nie mam pomysłów, co z tym zrobić. Centralowiec generalnie rozkłada ręce, jakiś wezwany do pomocy specjalista od S12 (nie pamiętam po latach, ale nie jestem pewien, czy to nie był aby mój odpowiednik z ramienia Alcatela) zapiera się rękami i nogami, że od jego strony jest wszystko dobrze i że to coś u nas nie tak, bo on alarm zdalny widzi. Cóż, dokładnie to samo ja mogłem powtarzać, że od mojej strony jest wszystko dobrze, ja mam interfejs podniesiony, a nie widzę komunikacji ze strony centrali…
Coś z tym jednak trzeba było robić. Kombinowaliśmy na wszystkie sposoby, całe interfejsy kreowaliśmy od początku, fizyczne połączenia sprawdzałem, karty podmieniałem, na centrali też przerzucili te interfejsy na inne wyposażenia, wszystko to zabierało od cholery czasu i w ten sposób wreszcie nas blady świt zastał. A potem słonko ujrzało leżących stu parudziesięciu tysięcy abonentów, pozbawiony łączności ze światem szpital, pogotowie bez działającego numeru zgłoszeniowego i sam nie wiem, co jeszcze. Począwszy od jakiejś siódmej rano właściwie komórki nie byłem w stanie z ręki wypuścić, dzwoniła na okrągło, jako do osoby odpowiedzialnej za przełączenie dzwonili do mnie chyba wszyscy możliwi tepsiani dyrektorzy, koordynatorzy i osoby usiłujące zaistnieć w temacie, każdy z osobna dopytywał się, co się stało, kazał sobie tłumaczyć, dlaczego to nie działa, usiłował udzielać porad (nie widząc sprzętu i nie mając zielonego pojęcia, jak działa, no takie typowe mądre rady pana dyrektora), bądź po prostu mnie opier…dzielać i grozić konsekwencjami, jeżeli „w ciągu godziny czegoś nie zrobię”. A i każdy z nich życzył sobie być informowanym o każdej zmianie sytuacji. Oczywiście, obsługa tych rozmów właściwie wykluczała robienie czegokolwiek innego, mi zresztą już też i nerwy i zmęczenie zaczęły się mocno dawać we znaki, dlatego w końcu ja też zadzwoniłem do swojego przełożonego i poprosiłem o wsparcie.

Dojechał przysłany dodatkowo kolega, telefon w międzyczasie po prostu przestałem odbierać, na spokojnie wspólnie uradziliśmy, że jeśli na samym początku w testach to wszystko działało, to należy spróbować sprawę doprowadzić do takiego stanu, jak na samym początku. Wyłączyliśmy zasilanie całości i włączyliśmy od nowa. Wiele to nie pomogło, ale kilka interfejsów wstało. Mieliśmy więc metodę choć częściowej poprawy sytuacji! W ten sposób, wykonując fizyczny restart całych oltów doprowadziliśmy w końcu jeszcze przed południem całość do stanu „na razie działa”. Całość zachowywała się cholernie niestabilnie, ale ogólnie wszystko zaczęło działać,można było się rozejść i jechać do domu spać. A w międzyczasie na miejsce zajechał nasz specjalista od protokołu V5.2 z analizatorem, przyjrzeć się sprawie dokładniej.

Co się okazało? Pech chciał, że ten ogromny projekt miał być jednocześnie naszym pierwszym, w którym Siemensowski Fastlink miał współpracować z Alcatelową centralą S12. Teoretycznie oczywiście nie powinno być żadnych problemów, w końcu jedno i drugie urządzenie miało się do komunikacji posługiwać interfejsem V5.2, którego sposób działania jest ściśle określony przez międzynarodowe normy i nie ma tam miejsca na żadne dowolności. Prawie żadne. Wygląda to podobnie, jak przy przepisach ruchu drogowego, niby wszystko jest jasne, odpowiednie paragrafy drobiazgowo tłumaczą, co wolno, a czego nie wolno, a jednak ilu kierowców, tyle czasem interpretacji tychże przepisów. Żeby daleko przykładów nie szukać, choćby sposób używania kierunkowskazów na skrzyżowaniu typu „rondo”…
Podobnie i tu. Normy ETSI określają szczegółowo, czym V5.2 jest, jak jest zbudowany, jak wygląda komunikacja w ramach interfejsu, jakie są zależności i niby wszystko tu powinno być jasne, a jednak pewne detale można było różnie interpretować. Tu rozeszło się o sposób numerowania fizycznych linków wchodzących w skład interfejsu. Numeracja ta ma charakter czysto wewnętrzny i w sumie jest mało istotna wobec faktu, że po obu stronach te linki są podłączone fizycznie, niemniej jednak standard precyzował tylko, że mają być numerowane i że te numery są wymieniane między stronami w trakcie komunikacji. Myśmy się tu posługiwali jakimś logicznym schematem tejże numeracji Alcatel zaś przyjął sobie ów schemat zupełnie inny, nie dość że względem norm ETSI dość naciągany, to jeszcze jakby tego było mało, z góry uznał tenże schemat za jedynie słuszny, bez żadnych szans na negocjacje. Interfejs się podnosił, po czym przy próbie zestawienia jakiegoś połączenia, gdy numery linków nie trafiały na siebie, nie próbował o tym poinformować obsługi stosownym alarmem, a jeszcze zatrzymywał działanie całego interfejsu. Stąd właśnie sytuacja, w której ja widziałem podniesiony interfejs bez żadnych alarmów, a S12 wskazywała interfejs leżący, z „alarmem zdalnym” jako jedynym wytłumaczeniem.

TPSA wymogła na nas wszystkich ekspresowe rozwiązanie problemu (trudno się zresztą dziwić) i zorganizowali nam spotkanie trójstronne: My-Siemens, Alcatel i TPSA jako rozjemca 🙂 Byłem na tym spotkaniu, bardzo po nim złe wrażenie o naszym konkurencie wyniosłem. Problem był niewątpliwy, czarno na białym było widać, że istnieje on na styku my-wy, a powodem były różnice w interpretacji protokołów. Na spotkanie przyszliśmy przygotowani, uzbrojeni w wydruki z analizatora, na których było to czarno na białym widać, co więcej palcem pokazywaliśmy, że konwencja przyjęta przez nas wynika wprost  z zapisów ETSI, podczas gdy implementacja Alcatela może nie jest jednoznacznie błędna, to jednak tak wprost z norm nie wynika. Ponadto, jak nasz specjalista przekonywał, niezrozumiałe jest, dlaczego S12 nie próbuje za wszelką cenę podtrzymać łączności, a kładzie cały interfejs po stwierdzeniu drobnej w sumie niezgodności. Odpowiedź alcatelowej pani inżynier mnie wtedy rozbawiła: jest to tak ważny błąd, że centrala specjalnie blokuje działanie interfejsu, by tym skuteczniej powiadomić o nim operatora. Ech, francuskim samochodem obecnie jeżdżę, mam nadzieję, że inni inżynierowie go projektowali i samochód nie zatrzyma mi się kiedyś na środku skrzyżowania, by tym skuteczniej powiadomić mnie o dramacie przepalonej żarówki światła stopu.
Wykazywaliśmy wtedy, na tamtym spotkaniu, że winien sytuacji jest Alcatel, ale jednocześnie mieliśmy otwarte stanowisko, nasze R&D stało w gotowości, byliśmy skłonni jakoś wspólnie zaradzić problemowi, by go skutecznie rozwiązać. Niestety, oficjalne stanowisko Alcatela było wtedy twarde i nieprzejednane: „a mówcie sobie, co chcecie, to nie jest nasza wina, u nas jest wszystko dobrze, amen”. Oficjalnie nie byli skłonni nie tylko przyznać, że coś z ich strony jest nie tak, ale nawet współpracą w rozwiązaniu problemów też nie byli zainteresowani w najmniejszym stopniu. Nieoficjalnie zaś – bardzo niedługo potem centrale S12 miały upgrade oprogramowania, po czym problemy (te podniesione przez nas interfejsy cały czas były niestabilne) nagle znikły jak ręką odjął. No ale to musiał być przypadek przecież…

Przez jakiś czas jeszcze, gdy przychodziło mi uruchamiać Fastlinka podłączonego do S12, zdarzały mi się powtórki z rozrywki, niemniej wtedy już znałem schemat postępowania: głęboki reset wyłącznikiem zasilania i tak aż do skutku. Potem jednak, w miarę jak S12 przechodziły kolejne aktualizacje, rzecz zanikła całkowicie. Starsi stażem pracownicy potem mi opowiadali, że sprawa w sumie jest dość typowa, podobno na początku współpraca z Lucentowską centralą 5ESS też była problematyczna, ponieważ jednak obie strony miały wolę i współpracy i rozwiązania problemu, tenże został rozwikłany ekspresowo i bez żadnej szkody dla klienta. Tu, niestety, wygrała polityka zamiatania smrodu pod dywan i udawania, że to nie nasze. Od jakiegoś centralowca z TP też zresztą potem usłyszałem, że nie my pierwsi się z tą polityką spotkaliśmy, tak się przeważnie kończyły wszelakie problemy ze sprzętem tego producenta: to absolutnie nie ich wina i koniec, ale za kilka tygodni nowy soft się pojawia i problem nagle znika. Swoją drogą, obecnie obie te firmy tworzą jedną, szczęśliwą i kochającą się rodzinę, ciekaw jestem, kto tam gra pierwsze skrzypce 🙂

 

email
This entry was posted in , . Bookmark: permalink.

4 Responses to Historia Telekomunikacji – część 13a

Pawlo111
Commented:  20 października 2016 at 19:52

Znamy takie zachowanie. Niektóre firmy chyba mają taką politykę by poświęcić całą parę/energię w temacie udowodnienia że ich towar nigdy nie zawodzi…
Jakiś rok temu Tepsa wysłała do klienta biznesowego na kolejną usterkę młodego chłopaka który nie miał pojęcia żadnego o swojej pracy.
I jeszcze ktoś dzwonił do niego co 2-3 minuty dopytać się czy sprawę załatwił.
Zadanie miał proste ale pewnie nikt doświadczony nie chciał przyjechać by nie dostać opie…lu
a młodego to nawet nie mieli sumienia prześwięcić tylko wszyscy chcieli by umęczył swoje i nie przeszkadzał.
Nawet mu pomagali.

Alcatel i standardy? Coś mi się przypomniało z pracy obecnej.
Błąd zgłoszony był, że do naszego RNCa przychodził od Alcatelowego sygnał RNSAPowy który u nas nie dekodował się poprawnie.
Po analizie wyszło że w specyfikacji ASN.1 było jakoś tak:

coś-tam ::= { coś-tam-jeszcze }
coś-tam-jeszcze ::= { bebeszki }

Co my interpretowaliśmy jako
coś-tam ::= {{ bebeszki }}

a Alcatel jako:
coś-tam ::= { bebeszki }

Jakie były dalsze losy tej niezgodności to już nie wiem.
PS. skróty do znalezienia np na Wikipedii 🙂

Ryszard
Commented:  29 grudnia 2016 at 20:45

Centrala Pentaconta, to centrala krzyżowa, a nie biegowa.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Archiwum

  • 2018 (1)
  • 2017 (24)
  • 2016 (66)
  • 2015 (39)

Wyszukiwanie

Licznik odwiedzin

0123080
Visit Today : 18
Hits Today : 139
Total Hits : 451654
Who's Online : 1
Przejdź do paska narzędzi