Historia Telekomunikacji – część 14

Wraz z nasycaniem się polskiego rynku telekomunikacyjnego Fastlinkiem, zaczęły się u nas wielkie przemiany w biznesie, przemiany, które w moim odczuciu były początkiem wieloletniej zapaści branży telekomunikacyjnej. Krótko mówiąc – dopadł nas korpowirus.
Znaczy, oczywiście, na pewno nie mam racji, nie rozumiem mechanizmów, jakimi się rządzi nowoczesny rynek, oceniam rzecz z subiektywnego, wąskiego punktu widzenia, nie dostrzegając szerszej perspektywy i tak dalej, niemniej… niemniej tak właśnie to widzę.

Przez ładnych kilka lat miałem okazję płynąć na fali świetnie funkcjonującego przedsięwzięcia, które oczywiście od strony technicznej kręciło się różnie, bywały mniejsze lub większe zacięcia, niemniej docierało się to wszystko i sądząc nawet po tym, że także i nam, pracownikom technicznym było coraz lepiej, musiało to funkcjonować dobrze także i w szerszej skali. Wtedy jednak przyszło do nas nowe: managerowie wysokiego szczebla nie mający co prawda żadnej wiedzy technicznej i zielonego pojęcia o sprzedawanych produktach, ale za to z dyplomami MBA i wielkim doświadczeniem w Organizacji i Zarządzaniu. Słupki, tabelki i wykresy w powerpoincie, które nagle stały się celem samym w sobie. Nagle się okazało, że nie będziemy już zatrudniać dłużej monterów, pracujących dla nas od lat i znających swoją robotę, tylko będziemy płacić firmom podwykonawczym, które to firmy będą zlecać robotę podnajętym przypadkowym ludziom za psie pieniądze, czasami pracującym od miesiąca i nie mającym pojęcia, co właściwie mają robić. I nie ważne, że firma podwykonawcza podobno kasowała nas za montaż sporo więcej, niż wynosiła pensja montera wcześniej pracującego dla nas bezpośrednio, ważne jest, że w tabelkach było widać, że firma zmniejszyła poziom zatrudnienia i koszty własne spadły, trzeba patrzeć w szerszej perspektywie!
Krótko mówiąc, wyoutsourcingowane zostało niemal wszystko, co tylko się wyoutsourcingować dało. Od elektryków począwszy na sprzątaczkach skończywszy. Cudem jakimś zostali się inżynierowie. No i kadra managerska, ci rzecz jasna nawet się rozbudowali, bo oczywistym jest, że ktoś tymi wszystkimi licznymi nowymi kooperantami musi zarządzać, nie? 😉

Dla jasności – ja w tej chwili nie jadę tylko po swoim ówczesnym pracodawcy, te przemiany miały miejsce chyba wszędzie, również w samej TPSA. Widziałem to na własne oczy jako człowiek stojący z boku, więc mogący spojrzeć na rzecz obiektywnie, jak nowoczesne zarządzanie bardzo popsuło naszego narodowego operatora telekomunikacyjnego. Były to dokładnie te same mechanizmy, co i u nas, a w TPSA było to najwyraźniej i najdobitniej widoczne chyba po stanach ulicznych szaf z krosowaniami. Wcześniej była lokalna komórka techniczna mająca pod sobą jakiś fragment sieci i tylko od nich zależało, jak ta sieć będzie funkcjonować. Oczywiście, różnie bywało, różni ludzie pracowali, ale na ogół było to oczywiste: im bardziej o sieć zadbacie, tym łatwiejsza będzie z nią robota. Monter jeżdżący do szafy zwykle wiedział, że jak sobie narobi bałaganu w krosówkach, to on przez ten bałagan będzie prędzej czy później płakał rzewnymi łzami. Przeciętny MDF w takiej szafie wtedy był czyściutki i ładnie prowadzony, krosówki były prowadzone równo, w prowadnicach, zbędne były usuwane, jeśli coś wisiało „w powietrzu”, to z karteczką informującą, co to jest i dlaczego wisi, a dodatkowo na obiekcie zwykle był ktoś w stylu opisywanego przeze mnie na początku tej telekomunikacyjnej sagi „Pana Henia”, który sieć znał na pamięć i doskonale wiedział, co w której szafie siedzi.
Gdy tylko TP pozwalniała własnych monterów, a zaczęła takie roboty zlecać podwykonawcom, do szaf zaczęli jeździć przypadkowi ludzie, zaczął się bałagan, krosówki puszczane na ukos, krosowane „na kupę”, wypięte połączenia były zostawiane ot tak (no chyba, że monter nie miał ze sobą krosówki, bo zapomniał zabrać, wtedy taką krosówkę wyrywał „siłom” [bywało, że rozwalając kilka innych połączeń] i używał ponownie). Jeździłem służbowo jako serwisant do takiej szafy stojącej obecnie w samym centrum warszawskiego „Mordoru”, szafa mocno wypchana abonentami, a z racji dużej dynamiki zmian w tym rejonie, dość często coś tam było przekrosowywane. Pamiętam tą szafę zarówno z czyściutkim, ładnie pokrosowanym MDFem, jak i (potem) w takim stanie, że drzwi od części kablowej ciężko było domknąć, bo wystający kłąb krosówek przeszkadzał. Może nie wyglądało to tak, jak na słynnym w branży zdjęciu z Bejrutu, ale wyraźnie w tą stronę zmierzało 🙂

mdf-bejrut

Przemiany w TP odbywały się tez i wyżej, nie tylko na poziomie instalacji. Lokalne centra nadzoru nagle okazały się być przeżytkiem, bowiem firma, w której są małe komórki, świetnie znające swój rejon oraz jego bolączki źle wypada w tabelkach. O wiele lepszym wyjściem jest zarządzanie centralne (co dobitnie nam przecież wykazało w skali kraju pół wieku centralnego zarządzania z ramienia komitetu centralnego), w którym anonimowi decydenci zarządzają wirtualną (dla nich) siecią, z pełnym przeświadczeniem, że właściwie mogą robić, co chcą, bo i tak jest więcej, jak pewne, że jeśli nawet problem wróci, to i tak trafi do kogoś innego.

Centralizacja nadzoru nad siecią przebiegła w TP dwuetapowo i dała nam dość ciekawą odmianę w naszej pracy. Etap pierwszy, to było utworzenie rejonowych centrów nadzoru (RONiU), skupiających pod sobą utrzymanie sieci z obszaru kilku województw. RONiU było pięć i w ten sposób to jeszcze przez jakiś czas funkcjonowało. Potem jednak dokonała się całkowita centralizacja, powstało ogólnopolskie centrum nadzoru i utrzymania mieszczące się w Poznaniu. Nie uprzedzajmy jednak faktów, najpierw RONiU.

Jak wspominałem, było ich pięć. W każdym z nich stała sobie ściana dość zdrowych (jak na owe czasy) serwerów Primergy wraz z łączącym je szkieletem. Na serwerach były poinstalowane nasze aplikacje nadzoru nad naszymi systemami, te właśnie wspominane już tutaj Access Integratory, wcześniej rozsiane po poszczególnych oddziałach, przykładowo wcześniejszy serwer z Raciborza (ten, na którym lokalne chłopaki w Duke Nukema grali) oraz drugi z Rybnika były teraz fizycznie zlikwidowane, zaś samo oprogramowanie wraz z przeniesioną bazą danych było postawione na serwerach w RONiU w Katowicach. Oczywiście potrzebne było tu połączenie między taką farmą serwerową a OLTami stojącymi tam, gdzie dotychczas, tu była wykorzystana mocno już rozbudowana w tamtych czasach ogólnopolska sieć teletransmisyjna TP, kwestia tylko przekonwertowania ethernetu na medium pośrednie, w roli którego wykorzystywaliśmy zwykłą „E1”.

Osobiście przyczyniłem się do powstania dwóch RONiU: warszawskiego i olsztyńskiego, których pracowników niniejszym pozdrawiam serdecznie 🙂 Do snucia opowieści właściwie niewiele tutaj jest, ale przypomina mi się bardzo ciekawa sieciowa usterka, która mnie przyprawiła o kilka garści siwych włosów przy okazji budowy RONiU warszawskiego. Było ono już dość zaawansowane w budowie, nie wszystkie obiekty terenowe były jeszcze doń przeniesione, ale te już „zmigrowane” normalnie funkcjonowały i były używane przez pracowników TP w codziennej pracy. ,Gdy więc pewnego dnia zaczęli mi raportować, że cośtam im znika, rzecz potraktowałem poważnie. Wsiadłem w samochód, pojechałem na Konwiktorską, usiadłem przy stanowisku i patrzę, co się dzieje. No faktycznie, cały OLT Ochota, z wszystkimi podległymi obiektami poskreślany na czerwono. Dziwnie to wyglądało, ale ping na Ochotę przechodził, zresetowałem więc całość, poczekałem aż się zaciągnie od nowa, działa, sprawa załatwiona. Następnego dna jednak słyszę, że znów się wyłożył. Kolejnego skreśliło się coś innego. Jeszcze kolejnego – cały serwer leży. I tak co i rusz coś się chrzaniło. Początkowo dawało się w tym wychwycić jakieś zależności, np. znikały elementy wiszące pod jednym switchem. Potem jednak była to już czysta loteria, znikały rzecz całkowicie losowo.

Tu będzie drobinka teorii, tym razem już raczej z działki czystego IT, teorii dodam bardzo mocno uproszczonej, więc bardzo proszę osoby zorientowane w temacie, by mieli to na uwadze:
Jak działa typowa sieć „komputerowa”, w ramach jednego węzła, np. sieć, jaką obecnie chyba każdy ma w domu: jest sobie switch (w domowych warunkach wchodzi on w skład domowego routerka), do switcha zaś podłączonych jest kilka urządzeń:

switch-multi-1

Komunikację między urządzeniami można porównać do komunikacji między ludźmi w grupie. Wyobraźmy sobie dzieci w klasie. Kuba potrzebuje długopisu. Pyta więc głośno: KTO MA DŁUGOPIS? Zgłasza się Zosia (załóżmy na chwilę, że wszystkie dzieci są bardzo uczynne i skore do pomocy), podaje Kubie długopis. Kuba zapamiętuje, że Zosia ma zapasowy długopis i następnym razem potrzebując długopisu zwróci się szeptem wprost do Zosi, już nie absorbując reszty towarzystwa.
Niemal identycznie odbywa się to w naszym węźle tworzonym przez switch. Przychodzi jakaś informacja na port F, ma ona trafić np. do drukarki. Nie wiadomo jednak, gdzie jest drukarka. Mamy siedem wyjść i tyle. Najpierw więc leci zapytanie: GDZIE JEST DRUKARKA? Pytanie nie adresowane do nikogo szczególnego jest rozsyłane do wszystkich, wszystkie urządzenia nie będące drukarką zapytanie ignorują, natomiast podłączona do portu A drukarka słysząc, że ją wołają odpowiada: TU JESTEM! Odpowiedź słychać z portu A, switch zapamiętuje, że jeśli coś przyjdzie adresowane do drukarki, to należy to przesłać do portu A, załatwione.
Tak mniej więcej (zamiast „drukarka” trzebaby wstawić adres IP, zamiast literki adres fizyczny) działa każda sieć komputerowa, tak też działały nasze farmy serwerowe w każdym RONiU. Switche były dość spore, zwykle było ich kilka, sieć też nie była taka prosta, wszystko jednak sprowadzało się do tej prostej zasady. Farma serwerowa w RONiU składała się z kilkunastu serwerów, kilkunastu (co najmniej) komputerów będących stacjami roboczymi, przy których pracowała obsługa oraz urządzeń w rodzaju wspominanych OLTów podłączonych do switchów już nie bezpośrednio (bo za daleko), tylko za pośrednictwem konwerterów oraz tepsianej teletransmisji.

Wyobraźmy sobie teraz taką sytuacje w powyższym przykładzie z dziećmi: gdzieś wśród dzieci jedno jest złośliwe i zaczyna bawić się w „echo”: powtarza każde zdanie, które usłyszy. Pytanie Kuby „kto ma długopis?” jest natychmiast powielone przez złośliwca. Odpowiedź Zosi, że ona ma długopis kierowana jest więc albo do właściwego pytającego, albo do złośliwca, zależnie od tego, którego z nich Zosia usłyszała lepiej. Jeśli odpowiedź przechwytywał złośnik, Kuba się jej nie doczekiwał. Ponawiał więc pytanie, a to znów było powielane przez echo. I tak w koło Macieju. Jeśli Kuba miał pecha, długopisu nie doczekiwał się wcale bądź w najlepszym razie, dostawał go z dużym opóźnieniem.

Właśnie taki złośliwiec spowodował opisywane problemy: w trakcie uruchamiania tego wszystkiego, poszczególne obiekty były przenoszone stopniowo, odbywało się to według jakiegośtam harmonogramu i często bywało tak, że fragment instalacji przygotowany do podłączenia jakiegoś obiektu, czekał sobie na przeniesienie tegoż obiektu, czasem nawet i po kilka tygodni. Tak też było i z podwarszawską, o ile mnie pamięć nie myli, Falenicą. To był nowy obiekt, świeżo uruchomiony i jeszcze bez abonentów, teletransmisja zestawiona, w RONiU na Konwiktorskiej elegancko podłączona do switcha, w samej Falenicy jednak kończyło się to na przełącznicy, nie było konwertera po drugiej stronie. Pech chciał jednak, że ktoś, kto to zestawiał, wysłał tam nadgorliwego montera. Nadgorliwiec ów zrobił tam pętelkę. Zwarł wejście z wyjściem inaczej mówiąc. W teletransmisji tak w ogóle jest to bardzo dobra praktyka, takie zapętlone zakończenie nie alarmuje w systemie, można je „zmierzyć”, same zalety. Tu jednak, z uwagi na to, że teletransmisja była dla nas jedynie medium pośrednim, spowodowało to w naszej sieci masakrę. Prócz normalnych urządzeń podłączonych do węzła mieliśmy w nim stworzonego przez ową pętlę chochlika, który co tylko do niego „weszło”, puszczał z powrotem jako swoje. W praktyce wyglądało to tak, że sieć niby działała, ale co i rusz jakieś jej elementy „znikały”, stawały się niedostępne, by za chwilę jak gdyby nigdy nic wrócić do życia, znikało zaś coś innego. Przyczynę odkryłem dopiero grzebiąc w statystykach portów i zwracając uwagę, że jeden port na switchu ma ruch dużo większy od pozostałych. Kiedy sprawdziłem, że ten port jest w dodatku oficjalnie jeszcze nie używany, byłem już w domu. Niemniej wcześniej zaliczyłem i wymianę switcha i wielokrotne sprawdzanie okablowania i na dokładkę doktoracik z protokołów routingu, bo rzecz się działa w sieci odrobinkę bardziej skomplikowanej, niż jeden switch z paroma urządzeniami wokół, więc w ramach szukania przyczyn analizę sieci musiałem prowadzić na poziomie wymagającym ekspresowego dokształcenia się z tematu, a początkowo podejrzenia przyczyn właśnie w zupełnie złą stronę szły.

Przebudowa systemów zarządzania była właściwie końcem Fastlinka dla nas, jego producenta. Telekomunikacja Polska uznała, że rynek się wysycił, to, co działa, to oni sobie obsłużą sami, w temacie nowego sprzętu zaś z przyczyn politycznych odwrócili się od nas, a nastawili raczej na sprzęt chiński oraz francuski (TP jeszcze wtedy się nie nazywała Orange, ale była już na prostej drodze ku temu), nawet bieżąca obsługa serwisowa tego co mieli też nie została przy nas, bowiem TP doszła do słusznego wniosku, że po co ma płacić nam, skoro może płacić połowę mniejsze pieniądze naszym podwykonawcom bezpośrednio. W ten sposób właśnie, wieloetapowo i małymi kroczkami i może nie ze wszystkim z własnej winy (w końcu nie mieliśmy wpływu na to, że TP stała się filią telekomunikacji francuskiej), zarżnęliśmy sobie kurę znoszącą złote jaja. Dla mnie oznaczało to pożegnanie z Fastlinkiem, po czym na krótko stałem się specem od radiolinii. O czym będzie w następnym odcinku 🙂

 

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

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 : 159
Total Hits : 451674
Who's Online : 1
Przejdź do paska narzędzi